Bagikan melalui

Manajemen kluster di Orleans

  • Artikel

Orleans menyediakan manajemen kluster melalui protokol keanggotaan bawaan, yang terkadang kami sebut sebagai keanggotaan Kluster . Tujuan dari protokol ini adalah untuk semua silo (Orleans server) untuk menyetujui set silo yang saat ini hidup, mendeteksi silo yang gagal, dan memungkinkan silo baru untuk bergabung dengan kluster.

Protokol bergantung pada layanan eksternal untuk memberikan abstraksi IMembershipTable. IMembershipTable adalah tabel tahan lama datar yang kami gunakan untuk dua tujuan. Pertama, digunakan sebagai titik pertemuan bagi silo untuk menemukan satu sama lain dan Orleans klien untuk menemukan silo. Kedua, ini digunakan untuk menyimpan tampilan keanggotaan saat ini (daftar silo hidup) dan membantu mengoordinasikan perjanjian pada tampilan keanggotaan.

Saat ini kami memiliki 6 implementasi IMembershipTable: berdasarkan Azure Table Storage, Azure Cosmos DB, ADO.NET (PostgreSQL, MySQL/MariaDB, SQL Server, Oracle), Apache ZooKeeper, Consul IO, AWS DynamoDB, MongoDB, Redis, Apache Cassandra, dan implementasi dalam memori untuk pengembangan.

Selain itu, IMembershipTable setiap silo berpartisipasi dalam protokol keanggotaan peer-to-peer yang terdistribusi sepenuhnya yang mendeteksi silo yang gagal dan mencapai perjanjian pada satu set silo hidup. Kami menjelaskan implementasi internal protokol keanggotaan Orleansdi bawah ini.

Protokol keanggotaan

  1. Setelah startup, setiap silo menambahkan entri untuk dirinya sendiri ke dalam tabel bersama yang terkenal, menggunakan implementasi .IMembershipTable Kombinasi identitas silo (ip:port:epoch) dan id penyebaran layanan (id kluster) digunakan sebagai kunci unik dalam tabel. Epoch hanyalah waktu dalam kutu ketika silo ini dimulai, dan dengan demikian ip:port:epoch dijamin unik dalam penyebaran tertentu Orleans .

  2. Silos memantau satu sama lain secara langsung, melalui pemeriksaan aplikasi ("apakah Anda hidup" heartbeats). sinyal dikirim sebagai pesan langsung dari silo ke silo, melalui soket TCP yang sama yang digunakan silo untuk berkomunikasi. Dengan begitu, pengujian sepenuhnya berkorelasi dengan masalah jaringan aktual dan kesehatan server. Setiap silo memeriksa sekumpulan silo lain yang dapat dikonfigurasi. Silo memilih siapa yang akan diperiksa dengan menghitung hash yang konsisten pada identitas silo lain, membentuk cincin virtual dari semua identitas, dan memilih silo penerus X pada cincin (ini adalah teknik terdistribusi terkenal yang disebut hashing yang konsisten dan banyak digunakan dalam banyak tabel hash terdistribusi, seperti Chord DHT).

  3. Jika silo S tidak mendapatkan balasan pemeriksaan Y dari server P yang dipantau, silo S mencurigainya dengan menuliskan kecurigaan beserta penanda waktunya ke dalam baris P di IMembershipTable.

  4. Jika P memiliki lebih dari Z kecurigaan dalam waktu K detik, maka S menulis bahwa P telah mati ke dalam baris P dan mengirimkan cuplikan tabel anggota saat ini ke semua silo lainnya. Silo memperbarui tabel secara berkala, sehingga cuplikan adalah pengoptimalan untuk mengurangi waktu yang dibutuhkan bagi semua silo untuk mempelajari tampilan keanggotaan baru.

  5. Dalam detail selengkapnya:

    1. Kecurigaan ditulis ke IMembershipTable, dalam kolom khusus dalam baris yang sesuai dengan P. Ketika S mencurigai P ia menulis: "pada saat TTT S dicurigai P".

    2. Satu kecurigaan tidak cukup untuk menyatakan P sebagai mati. Anda memerlukan kecurigaan Z dari silo yang berbeda dalam jendela waktu yang dapat dikonfigurasi T, biasanya 3 menit, untuk menyatakan P sebagai mati. Kecurigaan ditulis menggunakan kontrol konkurensi optimis yang disediakan oleh IMembershipTable.

    3. Silo S yang mencurigai membaca baris P.

    4. Jika S adalah tersangka terakhir (sudah ada tersangka Z-1 dalam jangka waktu T, seperti yang ditulis dalam kolom kecurigaan), S memutuskan untuk menyatakan P sebagai Mati. Dalam hal ini, S menambahkan dirinya ke daftar tersangka dan juga menulis di kolom Status P bahwa P adalah Mati.

    5. Jika tidak, jika S bukan tersangka terakhir, S hanya menambahkan dirinya ke kolom tersangka.

    6. Dalam kedua kasus, write-back menggunakan nomor versi atau ETag yang dibaca, sehingga pembaruan untuk baris ini diserialisasikan. Jika penulisan gagal karena ketidakcocokan versi/ETag, coba lagi S (baca lagi, dan coba tulis, kecuali P sudah ditandai mati).

    7. Pada tingkat tinggi urutan "baca, modifikasi lokal, tulis balik" ini adalah transaksi. Namun, kami belum tentu menggunakan transaksi penyimpanan untuk melakukannya. Kode "Transaksi" dijalankan secara lokal di server dan kami menggunakan konkurensi optimis yang disediakan oleh IMembershipTable untuk memastikan isolasi dan atomitas.

  6. Setiap silo secara berkala membaca seluruh tabel keanggotaan untuk penyebarannya. Dengan begitu silo belajar tentang silo baru bergabung dan tentang silo lain yang dinyatakan mati.

  7. Siaran rekam jepret: Untuk mengurangi frekuensi pembacaan tabel berkala, setiap kali silo menulis ke tabel (kecurigaan, gabungan baru, dll.) silo mengirimkan rekam jepret status tabel saat ini ke semua silo lainnya. Karena tabel keanggotaan konsisten dan diberi versi monoton, setiap pembaruan menghasilkan rekam jepret versi unik yang dapat dibagikan dengan aman. Ini memungkinkan penyebaran segera perubahan keanggotaan tanpa menunggu siklus baca berkala. Pembacaan berkala masih dipertahankan sebagai mekanisme cadangan jika distribusi cuplikan gagal.

  8. Pandangan keanggotaan yang diurutkan: Protokol keanggotaan memastikan bahwa semua konfigurasi keanggotaan diurutkan sepenuhnya secara global. Pemesanan ini memberikan dua manfaat utama:

    1. Konektivitas terjamin: Ketika silo baru bergabung dengan kluster, konektivitas dua arah harus divalidasi ke setiap silo aktif lainnya. Jika ada silo yang ada tidak merespons (berpotensi menunjukkan masalah konektivitas jaringan), silo baru tidak diizinkan untuk bergabung. Ini memastikan konektivitas penuh antara semua silo dalam kluster pada waktu mulai. Lihat catatan tentang IAmAlive di bawah ini untuk pengecualian dalam kasus pemulihan bencana.

    2. Pembaruan direktori konsisten: Protokol tingkat yang lebih tinggi, seperti direktori biji-bijian terdistribusi, mengandalkan semua silo yang memiliki tampilan keanggotaan yang konsisten dan monotonik. Ini memungkinkan resolusi aktivasi biji-bijian duplikat yang lebih cerdas. Untuk detail selengkapnya, lihat dokumentasi untuk direktori grain .

    Rincian implementasi:

    1. IMembershipTable memerlukan pembaruan atom untuk menjamin urutan keseluruhan perubahan secara global.

      • Implementasi harus memperbarui entri tabel (daftar silo) dan nomor versi secara atomik
      • Ini dapat dicapai menggunakan transaksi database (seperti di SQL Server) atau operasi perbandingan dan pertukaran atomik menggunakan ETags (seperti dalam Azure Table Storage)
      • Mekanisme khusus tergantung pada kemampuan sistem penyimpanan yang mendasar

    2. Baris versi keanggotaan khusus dalam tabel melacak perubahan:

      • Setiap penulisan ke tabel (kecurigaan, deklarasi kematian, penggabungan) menaikkan nomor versi ini.
      • Semua tulisan diserialisasikan melalui baris ini menggunakan pembaruan atom
      • Versi yang meningkat secara monoton memastikan urutan total dari semua perubahan keanggotaan

    3. Ketika silo S memperbarui status silo P:

      • S pertama kali membaca status tabel terbaru
      • Dalam satu tindakan sekaligus, langkah ini memperbarui baris P, dan menaikkan nomor versi.
      • Jika pembaruan atom gagal (misalnya, karena modifikasi bersamaan), operasi dicoba kembali dengan penundaan bertahap.

    pertimbangan skalabilitas :

    Mengatur urutan semua penulisan data melalui baris versi dapat memengaruhi skalabilitas karena peningkatan persaingan. Protokol telah terbukti dalam produksi dengan hingga 200 silo, tetapi mungkin menghadapi tantangan di luar seribu silo. Untuk penyebaran yang sangat besar, bagian lain dari Orleans (pesan, direktori grain, hosting) tetap dapat diskalakan bahkan jika pembaruan keanggotaan menjadi faktor penghambat.

  9. Konfigurasi default: Konfigurasi default telah disetel dengan tangan selama penggunaan produksi di Azure. Secara default: setiap silo dipantau oleh tiga silo lainnya, dua kecurigaan sudah cukup untuk menyatakan silo mati, kecurigaan hanya dari tiga menit terakhir (jika tidak, mereka sudah kedaluarsa). sinyal dikirim setiap sepuluh detik dan Anda perlu melewatkan tiga sinyal untuk mencurigai silo.

  10. Pemantauan mandiri : Detektor kesalahan menggabungkan ide-ide dari riset Hashicorp Lifeguard (makalah, presentasi, blog) untuk meningkatkan stabilitas kluster selama peristiwa bencana di mana sebagian besar kluster mengalami kegagalan parsial. Komponen LocalSiloHealthMonitor menilai kesehatan setiap silo menggunakan beberapa heuristik:

    • Status aktif dalam tabel keanggotaan
    • Tidak ada kecurigaan dari silo lain
    • Respons pemeriksaan terbaru yang berhasil
    • Permintaan pemeriksaan terbaru diterima
    • Responsivitas kumpulan utas (item kerja yang dijalankan dalam waktu 1 detik)
    • Akurasi timer (berfungsi dalam 3 detik dari jadwal)

    Skor kesehatan silo mempengaruhi batas waktu pemeriksaannya: silo yang tidak sehat (skor 1-8) memiliki batas waktu yang lebih lama dibandingkan dengan silo sehat (skor 0). Ini memiliki dua manfaat:

    • Memberikan lebih banyak waktu bagi upaya agar berhasil ketika jaringan atau sistem sedang dalam kondisi stres.
    • Lebih mungkin bahwa silo yang tidak sehat akan dieliminasi sebelum mereka dapat salah memilih silo yang sehat.

    Ini sangat berharga selama skenario seperti kelaparan kumpulan utas, di mana simpul lambat mungkin salah mencurigai simpul sehat hanya karena mereka tidak dapat memproses respons dengan cukup cepat.

  11. Pemeriksaan Tidak Langsung: Fitur lain yang diilhami oleh Lifeguard, yang meningkatkan akurasi deteksi kegagalan dengan mengurangi kemungkinan silo yang tidak sehat atau dipartisi salah menyatakan silo sehat sebagai tidak berfungsi. Ketika silo pemantauan memiliki dua upaya pemeriksaan yang tersisa untuk silo target sebelum memberikan suara untuk menyatakannya mati, ia menggunakan pemeriksaan tidak langsung:

    • Silo pemantauan secara acak memilih silo lain sebagai perantara dan memintanya untuk menyelidiki target
    • Perantara mencoba menghubungi silo yang ditarget
    • Jika target gagal merespons dalam periode waktu habis, perantara mengirimkan pengakuan negatif
    • Jika silo pemantauan menerima pengakuan negatif dari perantara dan perantara menyatakan dirinya sehat (melalui pemantauan mandiri, dijelaskan di atas), silo pemantauan memberikan suara untuk menyatakan target mati
    • Dengan konfigurasi default dua suara yang diperlukan, pengakuan negatif dari probe tidak langsung dihitung sebagai kedua suara, memungkinkan deklarasi silo mati yang lebih cepat saat kegagalan tersebut dikonfirmasi dari beberapa perspektif.

  12. Menegakkan deteksi kegagalan sempurna: Setelah silo dinyatakan mati dalam tabel, itu dianggap mati oleh semua orang, bahkan jika tidak benar-benar mati (hanya terpisah sementara atau pesan heartbeat yang hilang). Semua orang berhenti berkomunikasi dengannya dan setelah mengetahui bahwa ia mati (dengan membaca status barunya dari tabel) ia melakukan bunuh diri dan mematikan prosesnya. Akibatnya, harus ada infrastruktur untuk memulai ulang silo sebagai proses baru (nomor epoch baru dihasilkan setelah awal). Saat dihosting di Azure, itu terjadi secara otomatis. Jika tidak, diperlukan infrastruktur lain, seperti Layanan Windows yang dikonfigurasi agar restart otomatis saat terjadi kegagalan atau penyebaran Kubernetes.

  13. Apa yang terjadi jika tabel tidak dapat diakses selama beberapa waktu:

    Ketika layanan penyimpanan tidak berfungsi, tidak tersedia, atau ada masalah komunikasi dengannya, Orleans protokol TIDAK menyatakan silo sebagai mati secara tidak sengaja. Silo operasional akan terus bekerja tanpa masalah. Namun, Orleans tidak akan dapat menyatakan silo mati (jika mendeteksi beberapa silo mati melalui pemeriksaan yang terlewatkan, itu tidak akan dapat menulis fakta ini ke tabel) dan juga tidak akan dapat mengizinkan silo baru untuk bergabung. Jadi kelengkapan akan terpengaruh, tetapi akurasi tidak akan - partisi dari tabel tidak akan pernah menyebabkan Orleans secara tidak sengaja menyatakan silo yang mati. Juga, dalam kasus partisi jaringan parsial (jika beberapa silo dapat mengakses tabel dan beberapa tidak), itu bisa terjadi yang Orleans akan menyatakan silo mati mati, tetapi akan memakan waktu sampai semua silo lain mempelajarinya. Jadi deteksi dapat tertunda, tetapi Orleans tidak akan pernah salah membunuh silo karena tabel tidak tersedia.

  14. IAmAlive menulis untuk diagnostik dan pemulihan bencana:

    Selain heartbeat yang dikirim di antara silo, setiap silo secara berkala memperbarui tanda waktu "I Am Alive" di barisnya dalam tabel. Ini melayani dua tujuan:

    1. Untuk diagnostik, ia menyediakan administrator sistem dengan cara sederhana untuk memeriksa keaktifan kluster dan menentukan kapan silo terakhir aktif. Tanda waktu biasanya diperbarui setiap 5 menit.
    2. Untuk pemulihan bencana, jika silo belum memperbarui tanda waktunya selama beberapa periode (dikonfigurasi melalui NumMissedTableIAmAliveLimit), silo baru akan mengabaikannya selama pemeriksaan konektivitas saat startup, untuk memungkinkan kluster pulih dari skenario di mana silo mengalami crash tanpa pembersihan yang tepat.

Tabel keanggotaan

Seperti yang telah disebutkan, IMembershipTable digunakan sebagai titik pertemuan untuk silo untuk menemukan satu sama lain dan Orleans klien untuk menemukan silo dan juga membantu mengoordinasikan perjanjian pada tampilan keanggotaan. Repositori Orleans utama berisi implementasi untuk banyak sistem, seperti Azure Table Storage, Azure Cosmos DB, PostgreSQL, MySQL/MariaDB, server SQL, Apache ZooKeeper, Consul IO, Apache Cassandra, MongoDB, Redis, AWS DynamoDB, dan implementasi dalam memori untuk pengembangan.

  1. Azure Table Storage - dalam implementasi ini kami menggunakan ID penyebaran Azure sebagai kunci partisi dan identitas silo (ip:port:epoch) sebagai kunci baris. Bersama-sama mereka menjamin kunci unik per silo. Untuk kontrol konkurensi, kami menggunakan kontrol konkurensi optimis berdasarkan Azure Table ETags. Setiap kali kita membaca dari tabel, kita menyimpan ETag untuk setiap baris baca dan menggunakan ETag itu ketika kita mencoba menulis kembali. ETag secara otomatis ditetapkan dan diperiksa oleh layanan Azure Table pada setiap tulisan. Untuk transaksi multi-baris, kami menggunakan dukungan untuk transaksi batch yang disediakan oleh tabel Azure, yang menjamin transaksi yang dapat diserialisasikan melalui baris dengan kunci partisi yang sama.

  2. SQL Server - dalam implementasi ini, ID penyebaran yang dikonfigurasi digunakan untuk membedakan antara penyebaran dan silo mana yang termasuk dalam penyebaran mana. Identitas silo didefinisikan sebagai kombinasi deploymentID, ip, port, epoch dalam tabel dan kolom yang sesuai. Backend relasional menggunakan kontrol dan transaksi konkurensi optimis, mirip dengan prosedur penggunaan ETag pada implementasi Azure Table. Implementasi relasional mengharapkan mesin database menghasilkan ETag yang digunakan. Dalam kasus SQL Server, pada SQL Server 2000 ETag yang dihasilkan adalah satu diperoleh dari panggilan ke NEWID(). Pada SQL Server 2005 dan ROWVERSION yang lebih baru digunakan. Orleans membaca dan menulis ETag relasional sebagai tag buram VARBINARY(16) dan menyimpannya dalam memori sebagai string yang dikodekan base64 . Orleans mendukung penyisipan multi-baris menggunakan UNION ALL (untuk Oracle termasuk DUAL), yang saat ini digunakan untuk menyisipkan data statistik. Implementasi dan alasan yang tepat untuk SQL Server dapat dilihat pada CreateOrleansTables_SqlServer.sql.

  3. Apache ZooKeeper - dalam implementasi ini kami menggunakan ID penyebaran yang dikonfigurasi sebagai simpul akar dan identitas silo (ip:port@epoch) sebagai simpul anaknya. Bersama-sama mereka menjamin jalur unik per silo. Untuk kontrol konkurensi, kami menggunakan kontrol konkurensi optimis berdasarkan versi node. Setiap kali kita membaca dari node akar penyebaran, kita menyimpan versi untuk setiap simpul silo anak baca dan menggunakan versi itu ketika kita mencoba menulis kembali. Setiap kali data node berubah, nomor versi meningkat secara atomik oleh layanan ZooKeeper. Untuk transaksi multibaris, kami menggunakan metode multi, yang menjamin transaksi yang dapat diserialisasikan melalui simpul silo dengan node ID penyebaran induk yang sama.

  4. Consul IO - kami menggunakan penyimpanan Kunci/Nilai Consul untuk mengimplementasikan tabel keanggotaan. Lihat Consul-Deployment untuk detail selengkapnya.

  5. AWS DynamoDB - Dalam implementasi ini, kami menggunakan ID Penyebaran kluster sebagai Kunci Partisi dan Identitas Silo (ip-port-generation) sebagai RangeKey yang membuat kesatuan rekaman. Konkurensi optimis dibuat oleh atribut dengan ETag membuat penulisan kondisional di DynamoDB. Logika implementasinya cukup mirip dengan Azure Table Storage.

  6. Apacha Cassandra - Dalam implementasi ini kami menggunakan komposit Id Layanan dan Id Kluster sebagai kunci partisi dan identitas silo (ip:port:epoch) sebagai kunci baris. Mereka bersama-sama menjamin satu baris unik per silo. Untuk pengendalian konkurensi, kami menggunakan kontrol konkurensi optimis yang didasarkan pada versi kolom statis dengan menggunakan Transaksi Ringan. Kolom versi ini dibagikan untuk semua baris dalam partisi/kluster sehingga menyediakan nomor versi yang meningkat secara konsisten untuk setiap tabel keanggotaan kluster. Tidak ada transaksi multi-baris dalam implementasi ini.

  7. Emulasi dalam memori untuk penyiapan pengembangan. Kami menggunakan butir sistem khusus untuk implementasi tersebut. Biji-bijian ini hidup pada silo utama yang ditunjuk, yang hanya digunakan untuk penyiapan pengembangan. Dalam silo primer penggunaan produksi nyata tidak diperlukan.

Alasan desain

Pertanyaan yang mungkin muncul secara alami adalah mengapa tidak sepenuhnya mengandalkan Apache ZooKeeper atau etcd untuk implementasi keanggotaan kluster, dengan memanfaatkan dukungan bawaan ZooKeeper untuk keanggotaan grup menggunakan simpul-simpul sementara? Mengapa kita repot-repot menerapkan protokol keanggotaan kita? Terutama ada tiga alasan:

  1. Penyebaran/Hosting di cloud:

    Zookeeper bukan layanan yang dihosting. Ini berarti bahwa di lingkungan Orleans Cloud pelanggan harus menyebarkan/menjalankan/mengelola instans kluster ZK mereka. Ini baru beban lain yang tidak perlu, bahwa kami tidak ingin memaksa pelanggan kami. Dengan menggunakan Azure Table, kami mengandalkan layanan terkelola yang dihosting yang membuat kehidupan pelanggan kami jauh lebih sederhana. Pada dasarnya, di Cloud, gunakan Cloud sebagai Platform, bukan sebagai Infrastruktur. Di sisi lain, saat menjalankan lokal dan mengelola server Anda, mengandalkan ZK sebagai implementasi dari IMembershipTable adalah opsi yang layak.

  2. Deteksi kegagalan langsung:

    Saat menggunakan keanggotaan grup ZK dengan simpul ephemeral, deteksi kegagalan dilakukan antara Orleans server (klien ZK) dan server ZK. Ini mungkin belum tentu berkorelasi dengan masalah jaringan aktual antar Orleans server. Keinginan kami adalah bahwa deteksi kegagalan akan secara akurat mencerminkan status komunikasi intra-kluster. Secara khusus, dalam desain kami, jika Orleans silo tidak dapat berkomunikasi dengan IMembershipTable itu tidak dianggap mati dan dapat terus bekerja. Dibandingkan dengan itu, apakah kami telah menggunakan keanggotaan grup ZK dengan simpul sementara pemutusan dari server ZK dapat menyebabkan Orleans silo (klien ZK) dinyatakan mati, sementara itu mungkin hidup dan berfungsi penuh.

  3. Portabilitas dan fleksibilitas:

    Sebagai bagian Orleansdari filosofi , kami tidak ingin memaksa ketergantungan yang kuat pada teknologi tertentu, melainkan memiliki desain yang fleksibel di mana komponen yang berbeda dapat dengan mudah dialihkan dengan implementasi yang berbeda. Ini persis tujuan abstraksi yang IMembershipTable berfungsi.

Properti protokol keanggotaan

  1. Dapat menangani sejumlah kegagalan:

    Algoritma kami dapat menangani sejumlah kegagalan (yaitu, f<=n), termasuk mulai ulang kluster penuh. Ini berbeda dengan solusi berbasis Paxos "tradisional", yang membutuhkan kuorum, yang biasanya mayoritas. Kami telah melihat dalam situasi produksi ketika lebih dari setengah silo tidak berfungsi. Sistem kami tetap berfungsi, sementara keanggotaan berbasis Paxos tidak akan dapat membuat kemajuan.

  2. Lalu lintas ke meja sangat ringan:

    Probes sebenarnya langsung di antara server dan bukan ke tabel. Ini akan menghasilkan banyak lalu lintas ditambah akan kurang akurat dari perspektif deteksi kegagalan - jika silo tidak dapat mencapai meja, itu akan melewatkan menulis detak jantung saya hidup, dan yang lain akan membunuhnya.

  3. Akurasi yang dapat disetel versus kelengkapan:

    Meskipun Anda tidak dapat mencapai deteksi kegagalan yang sempurna dan akurat, seseorang biasanya menginginkan kemampuan untuk menukar akurasi (tidak ingin menyatakan silo yang hidup sebagai mati) dengan kelengkapan (ingin menyatakan mati silo yang memang mati sesegera mungkin). Pemungutan suara yang dapat disesuaikan untuk menyatakan probe gagal dan terlewat memungkinkan penyesuaian keduanya. Untuk informasi selengkapnya, lihat Yale University: Detektor Kegagalan Ilmu Komputer.

  4. Skala:

    Protokol ini dapat menangani ribuan dan bahkan mungkin puluhan ribu server. Hal ini berbeda dengan solusi tradisional berbasis Paxos, seperti protokol komunikasi grup, yang dikenal tidak menskalakan melebihi puluhan.

  5. Diagnostik:

    Tabel ini juga sangat nyaman untuk diagnostik dan pemecahan masalah. Administrator sistem dapat secara instan menemukan dalam tabel daftar silo hidup saat ini, serta melihat sejarah semua silo dan kecurigaan yang terbunuh. Ini sangat berguna saat mendiagnosis masalah.

  6. Mengapa kita membutuhkan penyimpanan persisten yang andal untuk implementasi IMembershipTable:

    Kami menggunakan penyimpanan persisten untuk IMembershipTable untuk dua tujuan. Pertama, digunakan sebagai titik pertemuan bagi silo untuk menemukan satu sama lain dan Orleans klien untuk menemukan silo. Kedua, kami menggunakan penyimpanan yang andal untuk membantu kami mengoordinasikan perjanjian tentang tampilan keanggotaan. Meskipun kami melakukan deteksi kegagalan langsung dengan cara peer-to-peer antara silo, kami menyimpan tampilan keanggotaan dalam penyimpanan yang andal dan menggunakan mekanisme kontrol konkurensi yang disediakan oleh penyimpanan ini untuk mencapai perjanjian siapa yang hidup dan siapa yang mati. Dengan begitu, dalam arti tertentu, protokol kami mengalihdayakan masalah keras konsekuensi terdistribusi ke cloud. Karena itu kami sepenuhnya menggunakan kekuatan platform cloud yang mendasar, menggunakannya benar-benar sebagai Platform as a Service (PaaS).

  7. IAmAlive langsung menulis ke dalam tabel hanya untuk diagnostik:

    Selain heartbeat yang dikirim di antara silo, setiap silo juga secara berkala memperbarui kolom "I Am Alive" di barisannya di tabel. Kolom "I Am Alive" ini hanya digunakan untuk pemecahan masalah manual dan diagnostik dan tidak digunakan oleh protokol keanggotaan itu sendiri. Biasanya ditulis pada frekuensi yang jauh lebih rendah (sekali setiap 5 menit) dan berfungsi sebagai alat yang sangat berguna bagi administrator sistem untuk memeriksa keaktivan kluster atau dengan mudah mengetahui kapan silo itu terakhir hidup.

Pengakuan

Kami ingin mengakui kontribusi Alex Kogan terhadap desain dan implementasi versi pertama protokol ini. Pekerjaan ini dilakukan sebagai bagian dari magang musim panas di Microsoft Research pada musim panas 2011. Implementasi IMembershipTable berbasis ZooKeeper dilakukan oleh Shay Hazor, implementasi SQL IMembershipTable dilakukan oleh Veikko Eeva, implementasi AWS DynamoDB IMembershipTable dilakukan oleh Gutemberg Ribeiro dan implementasi IMembershipTable berbasis Consul dilakukan oleh Paul North, dan akhirnya implementasi Apache Cassandra IMembershipTable diadaptasi dari OrleansCassandraUtils oleh Arshia001.