Implementasi direktori butir

Gambaran umum dan arsitektur

Direktori biji-bijian di Orleans adalah penyimpanan kunci-nilai di mana kunci 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. Anda dapat mengimplementasikan direktori Anda sendiri dengan mengimplementasikan IGrainDirectory antarmuka dan mendaftarkannya dengan koleksi layanan 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 baru yang konsistensi kuat, ada lebih sedikit kebutuhan untuk implementasi direktori eksternal, tetapi API tetap untuk kompatibilitas dan fleksibilitas ke belakang. Anda dapat mengonfigurasi direktori grain untuk tiap jenis grain.

Untuk mengoptimalkan performa, Orleans mencache pencarian direktori secara lokal di dalam setiap silo. Ini berarti pembacaan direktori jarak jauh yang berpotensi hanya diperlukan ketika entri cache lokal hilang atau tidak valid. Mekanisme penyimpanan sementara 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 Virtually Synchronous dua fase. Ini juga disusun sebagai tabel hash terdistribusi tetapi menawarkan peningkatan penyeimbangan beban melalui 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. Melihat 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 mencoba kembali jika terjadi perubahan tampilan.

Ini memastikan pemilik yang benar dari partisi direktori memproses semua permintaan.

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 fisik (host).

Ukuran partisi ditentukan oleh jarak antara hash-nya dan hash partisi berikutnya. Dimungkinkan bagi jangkauan untuk dibagi di antara beberapa silo selama perubahan pandangan. Ini 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 telah selesai. Kunci ini dianalogikan dengan 'wedges' yang digunakan dalam metodologi Sinkronisasi Virtual.

Saat perubahan tampilan terjadi, partisi dapat bertambah atau menyusut:

• Jika silo baru bergabung dengan kluster, partisi yang ada mungkin menyusut untuk memberi ruang.
• Jika silo meninggalkan kluster, partisi yang tersisa mungkin tumbuh 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 keanggotaan kluster berubah dengan cepat. Meskipun keanggotaan kluster menjamin monotonisitas, dimungkinkan bagi silo untuk melewatkan tampilan keanggotaan menengah. Dalam kasus seperti itu:

• Transfer snapshot dibatalkan.
• Pemulihan dilakukan alih-alih penyerahan antar 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 silo melihat semua sudut pandang.