Manajemen kluster di Orleans

Artikel
03/25/2023

Orleans menyediakan manajemen kluster melalui protokol keanggotaan bawaan, yang terkadang kami sebut sebagai Keanggotaan Silo. 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 seperti No-SQL 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, server SQL, Apache ZooKeeper, Consul IO, AWS DynamoDB, dan emulasi 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. Kita mulai dengan menjelaskan implementasi Orleansinternal protokol keanggotaan di bawah ini dan kemudian menjelaskan implementasi IMembershipTable.

Protokol Keanggotaan Dasar

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 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 .
Silos memantau satu sama lain secara langsung, melalui ping aplikasi ("apakah Anda hidup" heartbeats). Ping dikirim sebagai pesan langsung dari silo ke silo, melalui soket TCP yang sama yang dikomunikasikan silo. Dengan begitu, ping sepenuhnya berkorelasi dengan masalah jaringan aktual dan kesehatan server. Setiap silo ping set yang dapat dikonfigurasi dari silo lain. Silo memilih siapa yang akan melakukan ping dengan menghitung hash yang konsisten pada identitas silo lainnya, 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).
Jika silo S tidak mendapatkan balasan ping Y dari server yang dipantau P, silo S mencurigainya dengan menulis kecurigaan tanda waktunya ke dalam baris P di IMembershipTable.
Jika P memiliki lebih dari kecurigaan Z dalam beberapa detik, maka S menulis bahwa P mati ke baris P, dan menyiarkan permintaan untuk semua silo untuk membaca ulang tabel keanggotaan (yang akan mereka lakukan secara berkala).
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 tidak menggunakan transaksi penyimpanan untuk melakukan itu. Kode "Transaksi" dijalankan secara lokal di server dan kami menggunakan konkurensi optimis yang disediakan oleh IMembershipTable untuk memastikan isolasi dan atomitas.
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.
Konfigurasi: kami menyediakan konfigurasi default, yang disetel dengan tangan selama penggunaan produksi kami di Azure. Saat ini, defaultnya adalah: setiap silo dipantau oleh tiga silo lainnya, dua kecurigaan sudah cukup untuk menyatakan silo mati, kecurigaan hanya dari tiga menit terakhir (jika tidak, mereka kedaluarsa). Ping dikirim setiap sepuluh detik dan Anda harus melewatkan tiga ping untuk mencurigai silo.
Menegakkan deteksi Kegagalan Sempurna - secara teoritis mungkin bahwa silo akan dinyatakan mati jika kehilangan komunikasi dengan silo lain, sementara proses silo itu sendiri masih berjalan. Untuk mengatasi masalah ini setelah silo dinyatakan mati dalam tabel dianggap mati oleh semua orang, bahkan jika tidak mati (hanya dipartisi sementara atau pesan heartbeat tersesat). 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, infrastruktur lain diperlukan. Misalnya, Layanan Windows yang dikonfigurasi untuk memulai ulang otomatis pada kegagalan atau penyebaran Kubernetes.
Pengoptimalan untuk mengurangi frekuensi pembacaan tabel berkala dan mempercepat semua silo yang belajar tentang silo gabungan baru dan silo mati. Setiap kali silo menulis apa pun dengan sukses ke tabel (kecurigaan, gabungan baru, dan sebagainya) siaran juga ke semua silo lain - "buka dan baca ulang tabel sekarang". Silo TIDAK memberi tahu orang lain apa yang ditulis dalam tabel (karena informasi ini sudah kedaluarsa/salah), itu hanya memberi tahu mereka untuk membaca ulang tabel. Dengan begitu kita belajar dengan sangat cepat tentang perubahan keanggotaan tanpa perlu menunggu siklus baca berkala penuh. Kita masih memerlukan bacaan berkala, jika pesan "baca ulang tabel" hilang.

Properti protokol keanggotaan dasar

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.
Lalu lintas ke meja sangat ringan:

Ping aktual 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.
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). Suara yang dapat dikonfigurasi untuk menyatakan ping mati dan terlewat memungkinkan perdagangan keduanya. Untuk informasi selengkapnya, lihat Yale University: Detektor Kegagalan Ilmu Komputer.
Skala:

Protokol dasar dapat menangani ribuan dan mungkin bahkan puluhan ribu server. Hal ini berbeda dengan solusi tradisional berbasis Paxos, seperti protokol komunikasi grup, yang dikenal tidak menskalakan melebihi puluhan.
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.
Mengapa kita membutuhkan penyimpanan persisten yang andal untuk implementasi IMembershipTable:

Kami menggunakan penyimpanan persisten (tabel Azure, SQL Server, AWS DynamoDB, Apache ZooKeeper, atau Consul IO KV) untuk IMembershipTable 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).
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 ping yang terlewat, itu tidak akan dapat menulis fakta ini ke tabel) dan juga tidak akan dapat memungkinkan silo baru untuk bergabung. Jadi kelengkapan akan menderita, tetapi akurasi tidak akan—pemartisian dari tabel tidak akan pernah menyebabkan Orleans untuk menyatakan silo sebagai mati secara tidak sengaja. 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.
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.

Ekstensi untuk memesan tampilan keanggotaan

Protokol keanggotaan dasar yang dijelaskan di atas kemudian diperluas untuk mendukung tampilan keanggotaan yang dipesan. Kami akan menjelaskan secara singkat alasan ekstensi ini dan bagaimana penerapannya. Ekstensi tidak mengubah apa pun dalam desain di atas, hanya menambahkan properti yang semua konfigurasi keanggotaan diurutkan secara global.

Mengapa berguna untuk memesan tampilan keanggotaan?

Ini memungkinkan serialisasi gabungan silo baru ke kluster. Dengan begitu, ketika silo baru bergabung dengan kluster, ia dapat memvalidasi konektivitas dua arah ke setiap silo lain yang telah dimulai. Jika beberapa dari mereka sudah bergabung dengan silo tidak menjawabnya (berpotensi menunjukkan masalah konektivitas jaringan dengan silo baru), silo baru tidak diizinkan untuk bergabung. Ini memastikan bahwa setidaknya ketika silo dimulai, ada konektivitas penuh antara semua silo dalam kluster (ini diimplementasikan).
Protokol tingkat yang lebih tinggi dalam silo, seperti direktori biji-bijian terdistribusi, dapat menggunakan fakta bahwa tampilan keanggotaan diurutkan dan menggunakan informasi ini untuk melakukan resolusi aktivasi duplikat yang lebih cerdas. Secara khusus, ketika direktori mengetahui bahwa 2 aktivasi dibuat ketika keanggotaan dalam fluks, itu dapat memutuskan untuk menonaktifkan aktivasi lama yang dibuat berdasarkan informasi keanggotaan yang sekarang kedaluarsa.

Protokol keanggotaan yang diperluas:

Untuk implementasi fitur ini, kami menggunakan dukungan untuk transaksi melalui beberapa baris yang disediakan oleh MembershipTable.
Kami menambahkan baris versi keanggotaan ke tabel yang melacak perubahan tabel.
Ketika silo S ingin menulis kecurigaan atau deklarasi kematian untuk silo P:
1. S membaca konten tabel terbaru. Jika P sudah mati, jangan lakukan apa-apa. Sebaliknya
2. Dalam transaksi yang sama, tulis perubahan pada baris P serta tingkatkan nomor versi dan tulis kembali ke tabel.
3. Kedua tulisan dikondisikan dengan ETags.
4. Jika transaksi dibatalkan karena ketidakcocokan ETag pada baris P atau baris versi, coba lagi.
Semua penulisan ke tabel memodifikasi dan menaikkan baris versi. Dengan begitu semua penulisan ke tabel diserialisasikan (melalui serialisasi pembaruan ke baris versi) dan karena silo hanya menambah nomor versi, penulisan juga benar-benar diurutkan dalam urutan yang meningkat.

Skalabilitas protokol keanggotaan yang diperluas:

Dalam versi protokol yang diperluas, semua tulisan diserialisasikan melalui satu baris. Ini berpotensi merusak skalabilitas protokol manajemen kluster karena meningkatkan risiko konflik antara penulisan tabel bersamaan. Untuk mengurangi sebagian silo masalah ini, coba lagi semua tulisan mereka ke tabel dengan menggunakan backoff eksponensial. Kami telah mengamati protokol yang diperluas untuk bekerja dengan lancar di lingkungan produksi di Azure dengan hingga 200 silo. Namun, kami pikir protokol mungkin memiliki masalah penskalaan melebihi seribu silo. Dalam pengaturan besar seperti itu, pembaruan pada baris versi dapat dengan mudah dinonaktifkan, pada dasarnya mempertahankan sisa protokol manajemen kluster dan menyerah pada total properti pemesanan. Harap perhatikan juga bahwa kami merujuk ke sini untuk skalabilitas protokol manajemen kluster, bukan sisa .Orleans Kami percaya bahwa bagian lain dari Orleans runtime (olahpesan, direktori terdistribusi, hosting biji-bijian, konektivitas klien ke gateway) adalah cara yang dapat diskalakan di luar ratusan silo.

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. Saat ini kami memiliki enam implementasi IMembershipTable: berdasarkan Azure Table, SQL server, Apache ZooKeeper, Consul IO, AWS DynamoDB, dan emulasi dalam memori untuk pengembangan.

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.
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 di CreateOrleansTables_SqlServer.sql.
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.
Consul IO - kami menggunakan penyimpanan Kunci/Nilai Consul untuk mengimplementasikan tabel keanggotaan. Lihat Consul-Deployment untuk detail selengkapnya.
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.
Emulasi dalam memori untuk penyiapan pengembangan. Kami menggunakan butir sistem khusus, yang disebut MembershipTableGrain, 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.

Konfigurasi

Protokol keanggotaan dikonfigurasi melalui Liveness elemen di bagian Globals dalam Orleansfile Configuration.xml . Nilai default disetel dalam penggunaan produksi bertahun-tahun di Azure dan kami yakin nilai tersebut mewakili pengaturan default yang baik. Tidak perlu secara umum untuk mengubahnya.

Elemen konfigurasi sampel:

<Liveness ProbeTimeout="5s"
    TableRefreshTimeout="10s"
    DeathVoteExpirationTimeout="80s"
    NumMissedProbesLimit="3"
    NumProbedSilos="3"
    NumVotesForDeathDeclaration="2" />

Ada 4 jenis keakuratan yang diimplementasikan. Jenis protokol liveness dikonfigurasi melalui SystemStoreType atribut elemen di bagian Globals dalam Orleansfile Configuration.xmlSystemStore.

MembershipTableGrain: tabel keanggotaan disimpan dalam biji-bijian pada silo utama. Ini hanya penyiapan pengembangan.
AzureTable: tabel keanggotaan disimpan dalam tabel Azure.
SqlServer: tabel keanggotaan disimpan dalam database relasional.
ZooKeeper: tabel keanggotaan disimpan dalam ansambel ZooKeeper.
Consul: dikonfigurasi sebagai Penyimpanan sistem kustom dengan MembershipTableAssembly = "OrleansConsulUtils". Lihat Consul-Deployment untuk detail selengkapnya.
DynamoDB: dikonfigurasi sebagai penyimpanan sistem Kustom dengan MembershipTableAssembly = "OrleansAWSUtils".

Untuk semua jenis keakuratan, variabel konfigurasi umum didefinisikan dalam Globals.Liveness elemen:

ProbeTimeout: Jumlah detik untuk menyelidiki silo lain untuk hidup mereka atau untuk silo untuk mengirim pesan heartbeat "Saya masih hidup" tentang dirinya sendiri. Defaultnya adalah 10 detik.
TableRefreshTimeout: Jumlah detik untuk mengambil pembaruan dari tabel keanggotaan. Defaultnya adalah 60 detik.
DeathVoteExpirationTimeout: Waktu kedaluwarsa dalam hitungan detik untuk pemungutan suara kematian dalam tabel keanggotaan. Defaultnya adalah 120 detik
NumMissedProbesLimit: Jumlah pesan heartbeat "Saya masih hidup" yang terlewatkan dari silo atau jumlah pemeriksaan yang tidak dibalas yang menyebabkan menduga silo ini mati. Defaultnya adalah 3.
NumProbedSilos: Jumlah silo setiap pemeriksaan silo untuk keaktifan. Defaultnya adalah 3.
NumVotesForDeathDeclaration: Jumlah suara yang tidak kedaluwarsa yang diperlukan untuk mendeklarasikan beberapa silo sebagai mati (harus paling banyak NumMissedProbesLimit). Defaultnya adalah 2.
UseLivenessGossip: Apakah akan menggunakan pengoptimalan gosip untuk mempercepat penyebaran informasi keaktifan. Default-nya adalah true.
IAmAliveTablePublishTimeout: Jumlah detik untuk menulis secara berkala dalam tabel keanggotaan bahwa silo ini masih hidup. Digunakan hanya untuk diagnostik. Defaultnya adalah 5 menit.
NumMissedTableIAmAliveLimit: Jumlah pembaruan "Saya masih hidup" yang terlewatkan dalam tabel dari silo yang menyebabkan peringatan dicatat. Tidak berdampak pada protokol liveness. Defaultnya adalah 2.
MaxJoinAttemptTime: Jumlah detik untuk mencoba bergabung dengan kluster silo sebelum menyerah. Defaultnya adalah 5 menit.
ExpectedClusterSize: Ukuran kluster yang diharapkan. Tidak perlu sangat akurat, bisa menjadi overestimate. Digunakan untuk menyetel algoritma backoff eksponensial dari percobaan ulang untuk menulis ke tabel Azure. defaultnya adalah 20.

Alasan desain

Pertanyaan alami yang mungkin ditanyakan adalah mengapa tidak sepenuhnya mengandalkan Apache ZooKeeper untuk implementasi keanggotaan kluster, berpotensi dengan menggunakan dukungan out-of-the-box untuk keanggotaan grup dengan simpul sementara? Mengapa kita repot-repot menerapkan protokol keanggotaan kita? Terutama ada tiga alasan:

Penyebaran/Hosting di cloud:

Zookeeper bukan layanan yang dihosting (setidaknya pada saat penulisan ini Juli 2015 dan pasti ketika kami pertama kali menerapkan protokol ini pada musim panas 2011 tidak ada versi Zookeeper yang berjalan sebagai layanan yang dihosting oleh penyedia cloud utama apa pun). 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.
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.
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.

Pengakuan

Kami akan 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. Penerapan berbasis IMembershipTable ZooKeeper dilakukan oleh Shay Hazor, implementasi SQL IMembershipTable dilakukan oleh Veikko Eeva, implementasi AWS DynamoDB IMembershipTable dilakukan oleh Gutemberg Ribeiro dan pelaksanaan berbasis IMembershipTable Consul dilakukan oleh PaulUs Utara.

Bagikan melalui