Bagikan melalui

Implementasi direktori butir

  • Artikel

Gambaran umum dan arsitektur

Direktori biji-bijian di Orleans adalah penyimpanan kunci-nilai di mana kuncinya adalah pengidentifikasi biji-bijian dan nilainya adalah entri pendaftaran yang menunjuk ke silo aktif yang (berpotensi) menghosting biji-bijian.

Meskipun Orleans menyediakan implementasi direktori terdistribusi dalam memori default (dijelaskan dalam artikel ini), sistem direktori grain dirancang agar dapat dicolokkan. Pengembang dapat menerapkan direktori mereka sendiri dengan cara mengimplementasikan antarmuka IGrainDirectory dan mendaftarkannya dengan kumpulan layanan dari silo. Hal ini memungkinkan implementasi direktori kustom yang mungkin menggunakan backend penyimpanan atau model konsistensi yang berbeda agar lebih sesuai dengan persyaratan aplikasi tertentu. Karena pengenalan direktori konsistensi yang kuat yang baru, ada sedikit kebutuhan untuk implementasi direktori eksternal, tetapi API tetap untuk kompatibilitas mundur dan fleksibilitas. Direktori biji-bijian dapat dikonfigurasi berdasarkan jenis per butir.

Untuk mengoptimalkan performa, pencarian direktori di-cache secara lokal dalam setiap silo. Ini berarti bahwa pembacaan direktori yang berpotensi jarak jauh hanya diperlukan ketika entri cache lokal hilang atau tidak valid. Mekanisme penembolokan ini mengurangi overhead jaringan dan latensi yang terkait dengan pencarian lokasi grain.

Awalnya, Orleans menerapkan direktori yang akhirnya konsisten yang disusun sebagai tabel hash terdistribusi. Ini digantikan oleh direktori yang sangat konsisten di Orleans v9.0, berdasarkan metodologi dua fase Virtually Synchronous dan juga disusun sebagai tabel hash terdistribusi tetapi dengan penyeimbangan beban yang ditingkatkan melalui penggunaan simpul virtual. Artikel ini menjelaskan implementasi direktori grain yang terakhir dan lebih baru.

Direktori grain terdistribusi

Direktori biji-bijian terdistribusi di Orleans menawarkan konsistensi yang kuat, bahkan penyeimbangan beban, performa tinggi, dan toleransi kesalahan. Implementasinya mengikuti desain dua fase berdasarkan metodologi Virtual Synchrony dengan kesamaan dengan Vertikal Paxos.

Partisi direktori memiliki dua mode operasi:

  1. Operasi normal: partisi memproses permintaan secara lokal tanpa koordinasi dengan host lain.
  2. Lihat perubahan: host berkoordinasi satu sama lain untuk mentransfer kepemilikan rentang direktori.

Direktori ini memanfaatkan Orleans' sistem keanggotaan kluster konsistensi yang kuat, di mana konfigurasi yang disebut "tampilan" telah meningkatkan nomor versi secara monoton. Saat silo bergabung dan meninggalkan kluster, tampilan berturut-turut dibuat, menghasilkan perubahan pada kepemilikan rentang.

Semua operasi direktori mencakup koordinasi tampilan:

  • Permintaan membawa nomor tampilan penelepon.
  • Respons mencakup nomor tampilan partisi.
  • Lihat ketidakcocokan angka yang memicu sinkronisasi.
  • Permintaan secara otomatis dicoba kembali pada perubahan tampilan.

Ini memastikan bahwa semua permintaan diproses oleh pemilik partisi direktori yang benar.

Strategi pemartisian

Direktori dipartisi menggunakan cincin hash yang konsisten dengan rentang yang ditetapkan ke silo aktif dalam kluster. Pengidentifikasi biji-bijian di-hash untuk menemukan silo yang memiliki bagian cincin yang sesuai dengan hash-nya.

Setiap silo aktif memiliki jumlah rentang yang telah dikonfigurasi sebelumnya, dengan setelan default 30 rentang per silo. Ini mirip dengan skema yang digunakan oleh Amazon Dynamo dan Apache Cassandra, di mana beberapa "simpul virtual" (rentang) dibuat untuk setiap simpul (host).

Ukuran partisi ditentukan oleh jarak antara hash-nya dan hash partisi berikutnya. Dimungkinkan bagi rentang untuk dibagi di antara beberapa silo selama perubahan tampilan, yang menambah kompleksitas pada prosedur perubahan tampilan karena setiap partisi harus berpotensi berkoordinasi dengan beberapa partisi lain.

Lihat prosedur perubahan

Partisi direktori (diimplementasikan dalam GrainDirectoryPartition) menggunakan kunci rentang versi untuk mencegah akses ke rentang yang tidak valid selama perubahan tampilan. Kunci rentang dibuat selama perubahan tampilan dan dirilis saat perubahan tampilan selesai. Kunci ini dianalogikan dengan 'wedges' yang digunakan dalam metodologi Sinkronisasi Virtual.

Saat perubahan tampilan terjadi, partisi dapat bertambah atau menyusut:

  • Jika silo baru telah bergabung dengan kluster, maka partisi yang ada dapat menyusut untuk memberi ruang.
  • Jika sebuah silo keluar dari kluster, maka partisi yang tersisa dapat membesar untuk menguasai rentang yang ditinggalkan.

Pendaftaran direktori harus ditransfer dari pemilik lama ke pemilik baru sebelum permintaan dapat dilayani. Proses transfer mengikuti langkah-langkah berikut:

  1. Pemilik sebelumnya mengunci rentang dan membuat cuplikan entri direktorinya.
  2. Pemilik baru meminta dan menerapkan snapshot.
  3. Pemilik baru mulai melayani permintaan untuk rentang tersebut.
  4. Pemilik sebelumnya diberi tahu dan menghapus rekam jepret.

Proses pemulihan

Ketika host mengalami crash tanpa menyerahkan partisi direktorinya dengan benar, pemilik partisi berikutnya harus melakukan pemulihan. Ini melibatkan:

  1. Mengkueri semua silo aktif dalam kluster untuk pendaftaran biji-bijian mereka.
  2. Membangun kembali status direktori untuk rentang yang terpengaruh.
  3. Memastikan tidak ada aktivasi biji-bijian duplikat yang terjadi.

Pemulihan juga diperlukan ketika perubahan keanggotaan kluster terjadi dengan cepat. Meskipun keanggotaan kluster menjamin monotonisitas, dimungkinkan bagi silo untuk melewatkan tampilan keanggotaan menengah. Dalam kasus seperti itu:

  • Transfer snapshot dibatalkan.
  • Pemulihan dilakukan sebagai pengganti serah terima partisi yang normal.
  • Sistem mempertahankan konsistensi meskipun status menengah hilang.

Peningkatan keanggotaan kluster di masa mendatang dapat mengurangi atau menghilangkan skenario ini dengan memastikan semua tampilan dilihat oleh semua silo.