Aracılığıyla paylaş

'da küme yönetimi Orleans

  • Makale

Orleans, bazen Küme üyeliğiolarak adlandırdığımız yerleşik üyelik protokolü aracılığıyla küme yönetimi sağlar. Bu protokolün amacı, tüm siloların (Orleans sunucuların) şu anda etkin olan silolar kümesi üzerinde anlaşmaya varmasına, başarısız siloları algılamasına ve yeni siloların kümeye katılmasına izin vermesine yöneliktir.

Protokol, soyutlama IMembershipTablesağlamak için bir dış hizmete dayanır. IMembershipTable iki amaçla kullandığımız düz dayanıklı bir tablodur. İlk olarak, siloların birbirini Orleans bulması ve istemcilerin siloları bulması için bir randevu noktası olarak kullanılır. İkincisi, geçerli üyelik görünümünü (etkin siloların listesi) depolamak için kullanılır ve üyelik görünümünde sözleşmenin koordinesine yardımcı olur.

Şu anda 6 uygulamasına sahibiz: Azure Tablo DepolamaAzure Cosmos DBADO.NET (PostgreSQL, MySQL/MariaDB, SQL Server, Oracle), Apache ZooKeeper, Consul IO, AWS DynamoDB, MongoDB, Redis, Apache Cassandrave geliştirme için bellek içi uygulama.

Her siloya IMembershipTable ek olarak, başarısız siloları algılayan ve bir dizi canlı silo üzerinde anlaşmaya varan tam olarak dağıtılmış eşler arası üyelik protokolüne katılır. aşağıda Orleansüyelik protokolünün iç uygulamasını açıklıyoruz.

Üyelik protokolü

  1. Başlangıçtan sonra her silo, uygulamasını IMembershipTablekullanarak iyi bilinen, paylaşılan bir tabloya kendisi için bir girdi ekler. Tabloda benzersiz anahtarlar olarak silo kimliği (ip:port:epoch) ve hizmet dağıtım kimliği (küme kimliği) birleşimi kullanılır. Dönem, bu silo başlatıldığında kenelerin tam zamanıdır ve bu nedenle ip:port:epoch belirli Orleans bir dağıtımda benzersiz olması garanti edilir.

  2. Silolar, uygulama yoklamaları aracılığıyla birbirlerini doğrudan izler ("yaşıyor musunuz" heartbeats). yoklamalar silodan siloya doğrudan ileti olarak, siloların iletişimde olduğu TCP yuvaları üzerinden gönderilir. Bu şekilde, yoklamalar gerçek ağ sorunları ve sunucu durumu ile tamamen bağıntılı olur. Her bir silo, yapılandırılabilir diğer silolar kümesini denetler. Silo, diğer siloların kimliğinde tutarlı karmaları hesaplayarak, tüm kimliklerin sanal halkasını oluşturarak ve halkada X ardıl siloları seçerek kimin yoklanacağına ilişkin bir seçim gerçekleştirir (bu, tutarlı karma olarak adlandırılan iyi bilinen bir dağıtılmış tekniktir ve Chord DHT) gibi birçok dağıtılmış karma tabloda yaygın olarak kullanılır.

  3. Bir silo S, izlenen bir sunucu P'den Y yoklama yanıtları almazsa, bundan şüphelenir ve zaman damgalı kuşkusunu IMembershipTable'de P'nin satırına yazar.

  4. P'nin K saniye içinde Z'den fazla şüphesi varsa S, P'nin satırına P'nin öldüğünü yazar ve geçerli üyelik tablosunun anlık görüntüsünü diğer tüm silolara gönderir. Silolar tabloyu düzenli aralıklarla yeniler, bu nedenle anlık görüntü, tüm siloların yeni üyelik görünümü hakkında bilgi edinme süresini kısaltmaya yönelik bir iyileştirmedir.

  5. Daha ayrıntılı bilgi:

    1. Şüphe, satırda P'ye IMembershipTablekarşılık gelen özel bir sütunda öğesine yazılır. S, P'ye şüphelendiğinde şöyle yazar: "O sırada TTT S şüpheli P".

    2. Bir şüphe P'yi ölü olarak bildirmek için yeterli değildir. P'yi ölü olarak bildirmek için yapılandırılabilir bir zaman penceresi T'de (genellikle 3 dakika) farklı silolardan Z şüphelerine ihtiyacınız vardır. Şüphe, tarafından IMembershipTablesağlanan iyimser eşzamanlılık denetimi kullanılarak yazılır.

    3. Şüpheli silo S, P'nin satırını okuyor.

    4. Son şüpheli ise S (şüphe sütununda yazıldığı gibi T döneminde zaten Z-1 şüphelileri vardı), S, P'yi Ölü olarak bildirmeye karar verir. Bu durumda, S kendisini şüpheliler listesine ekler ve P'nin Durum sütununa P'nin Ölü olduğunu yazar.

    5. Aksi takdirde, son şüpheli S değilse, S yalnızca kendisini şüphelinin sütununa ekler.

    6. Her iki durumda da geri yazma işlemi okunan sürüm numarasını veya ETag'i kullandığından, bu satırdaki güncelleştirmeler seri hale getirilir. Sürüm/ETag uyuşmazlığı nedeniyle yazma işleminin başarısız olması durumunda, S yeniden denemeleri (P zaten ölü olarak işaretlenmediği sürece yeniden okuyun ve yazmayı deneyin).

    7. Yüksek düzeyde bu "okuma, yerel değişiklik, geri yazma" dizisi bir işlemdir. Ancak bunu yapmak için depolama işlemlerini kullanmamız şart değildir. "İşlem" kodu bir sunucuda yerel olarak yürütülür ve yalıtım ve bölünmezlik sağlamak için tarafından IMembershipTable sağlanan iyimser eşzamanlılığı kullanırız.

  6. Her silo, dağıtımı için üyelik tablosunun tamamını düzenli aralıklarla okur. Bu şekilde silolar, yeni siloların birleşip ölü olarak bildirildiği diğer silolar hakkında bilgi edinir.

  7. Anlık görüntü yayını: Düzenli aralıklarla tablo okuma sıklığını azaltmak için, bir silo tabloya her yazdığında (şüphe, yeni birleşim vb.) geçerli tablo durumunun anlık görüntüsünü diğer tüm silolara gönderir. Üyelik tablosu tutarlı ve monoton sürüme sahip olduğundan, her güncelleştirme güvenli bir şekilde paylaşılabilen benzersiz sürüme sahip bir anlık görüntü oluşturur. Bu, düzenli okuma döngüsünü beklemeden üyelik değişikliklerinin hemen yayılmasını sağlar. Anlık görüntü dağıtımının başarısız olması durumunda düzenli okuma hala bir geri dönüş mekanizması olarak korunur.

  8. Sıralı üyelik görünümleri: Üyelik protokolü, tüm üyelik yapılandırmalarının genel olarak tamamen sıralanmasını sağlar. Bu sıralama iki temel avantaj sağlar:

    1. Garantili bağlantı: Kümeye yeni bir silo katıldığında, diğer tüm etkin silolara iki yönlü bağlantıyı doğrulamalıdır. Mevcut silo yanıt vermezse (potansiyel olarak bir ağ bağlantısı sorunu olduğunu gösterir), yeni silonun katılmasına izin verilmez. Bu, başlangıç zamanında kümedeki tüm silolar arasında tam bağlantı sağlar. Olağanüstü durum kurtarma durumunda bir özel durum için aşağıdaki IAmAlive hakkındaki nota bakın.

    2. Tutarlı dizin güncelleştirmeleri: Dağıtılmış grain dizini gibi daha yüksek düzey protokoller, tutarlı, monoton üyelik görünümüne sahip tüm siloları kullanır. Bu, yinelenen tanecik etkinleştirmelerinin daha akıllıca çözülmesini sağlar. Daha fazla ayrıntı için tahıl dizini belgesine bakın.

    Uygulama ayrıntıları:

    1. IMembershipTable, değişikliklerin genel toplam sırasını garanti etmek için atomik güncelleştirmeler gerektirir:

      • Uygulamalar hem tablo girdilerini (silo listesi) hem de sürüm numarasını atomik olarak güncelleştirmelidir
      • Bu, veritabanı işlemleri (SQL Server'da olduğu gibi) veya ETag'ler kullanılarak atomik karşılaştırma ve değiştirme işlemleri kullanılarak gerçekleştirilebilir (Azure Tablo Depolama'da olduğu gibi)
      • Belirli mekanizma, temel alınan depolama sisteminin özelliklerine bağlıdır

    2. Tablodaki özel üyelik sürümü satırı değişiklikleri izler:

      • Tabloya yapılan her yazma işlemi (şüpheler, ölüm bildirimleri, birleştirmeler) bu sürüm numarasını artırır
      • Tüm yazma işlemleri atomik güncelleştirmeler kullanılarak bu satırda seri hale getirilir
      • Monoton olarak artan sürüm, tüm üyelik değişikliklerinin toplam sıralamasını sağlar

    3. Silo S silo P'nin durumunu güncelleştirdiğinde:

      • S ilk olarak en son tablo durumunu okur
      • Tek bir atomik işlemde hem P'nin satırını güncelleştirir hem de sürüm numarasını artırır
      • Atomik güncelleştirme başarısız olursa (örneğin, eşzamanlı değişiklikler nedeniyle), işlem üstel geri alma ile yeniden denenir

    Ölçeklenebilirlik konuları:

    Sürüm satırı aracılığıyla tüm yazmaların seri hale getirilmesi, artan çekişme nedeniyle ölçeklenebilirliği etkileyebilir. Protokol, 200 siloya kadar üretimde kanıtlanmıştır, ancak bin silonun ötesinde zorluklarla karşılaşabilir. Çok büyük dağıtımlar için, üyelik güncelleştirmeleri bir performans sorunu haline gelse bile Orleans diğer bölümleri (mesajlaşma, tahıl dizini, barındırma) ölçeklenebilir olmaya devam eder.

  9. Varsayılan yapılandırma: Azure'da üretim kullanımı sırasında varsayılan yapılandırma el ile ayarlanmıştır. Varsayılan olarak: her silo üç silo daha tarafından izlenir, bir silonun öldüğünü bildirmek için iki şüphe yeterlidir, yalnızca son üç dakikadaki şüpheler (aksi takdirde eskidir). sondalar her on saniyede bir gönderilir ve bir silodan şüphelenmek için üç sondayı kaçırmanız gerekir.

  10. Kendi kendine izleme: Hata algılayıcısı, kümenin büyük bir bölümünün kısmi hatayla karşılaştığı yıkıcı olaylar sırasında küme kararlılığını geliştirmek için Hashicorp'un Cankurtaran araştırmasından (makale, talk, blog) fikirleri içerir. LocalSiloHealthMonitor bileşeni, birden çok buluşsal çözüm kullanarak her silonun durumunu puanlar:

    • Üyelik tablosunda aktif durum
    • Diğer silolardan şüphe yok
    • Son başarılı yoklama yanıtları
    • Alınan son yoklama istekleri
    • İş parçacığı havuzunun yanıt verme hızı (1 saniyede yürütülen iş öğeleri)
    • Zamanlayıcı doğruluğu (zamanlamadan sonra 3 saniye içinde tetikleniyor)

    Silo'nun sağlık puanı yoklama zaman aşımlarını etkiler: sağlıksız silolar (puankademe 1-8), sağlıklı silolarla (puankademe 0) kıyaslandığında daha uzun zaman aşımlarına sahiptir. Bunun iki avantajı vardır:

    • Ağ veya sistem stres altında olduğunda yoklamaların başarılı olması için daha fazla zaman verir
    • Sağlıksız siloların sağlıklı siloları yanlış bir şekilde elemesine izin vermeden ölü olarak oylanma olasılığını artırır.

    Bu, özellikle iş parçacığı havuzu yetersizliği gibi senaryolarda, yavaş düğümlerin yanıtları yeterince hızlı işleyemediği için iyi durumdaki düğümlerden yanlışlıkla şüphelenebileceği durumlarda değerlidir.

  11. Dolaylı yoklama: İyi durumda olmayan veya bölümlenmiş bir silonun hatalı bir şekilde sağlıklı silo ölü ilan etme olasılığını azaltarak hata algılama doğruluğunu geliştiren başka bir Cankurtaranilham verici özellik. İzleme silosunda hedef silo için iki yoklama denemesi kaldığında, ölü ilan etmek için oy vermeden önce dolaylı yoklamaya başvurur.

    • İzleme silosu rastgele başka bir siloyu aracı olarak seçer ve hedefi araştırmasını ister
    • Aracı, hedefteki siloyla iletişim kurmaya çalışır
    • Hedef zaman aşımı süresi içinde yanıt vermezse, aracı olumsuz bir onay gönderir
    • İzleme silosu aracıdan olumsuz bir onay alırsa ve aracı kendini iyi durumda olarak bildirirse (yukarıda açıklanan kendi kendine izleme yoluyla), izleme silosu hedefin ölü olduğunu bildirmek için oylama yapar
    • Varsayılan yapılandırmada gerekli olan iki oy ile, dolaylı yoklamadan gelen olumsuz bir yanıt her iki oy olarak sayılır ve başarısızlık birden çok perspektif tarafından onaylandığında ölü siloların daha hızlı bildirilmesine olanak tanır.

  12. Mükemmel hata algılamayı zorlama: Bir silo tabloda ölü olarak bildirildikten sonra, ölü olmasa bile herkes tarafından ölü olarak kabul edilir (yalnızca geçici olarak bölümlenmiş veya sinyal iletileri kaybolmuş olabilir). Herkes onunla iletişim kurmaktan durur ve öldüğünü öğrendiğinde (tablodan yeni durumunu okuyarak) intihar eder ve sürecini kapatır. Sonuç olarak, siloyu yeni bir işlem olarak yeniden başlatmak için bir altyapı bulunmalıdır (başlangıçta yeni bir dönem numarası oluşturulur). Azure'da barındırıldığında bu otomatik olarak gerçekleşir. Aksi takdirde, hata durumunda otomatik olarak yeniden başlatılmak üzere yapılandırılmış bir Windows Hizmeti veya Kubernetes dağıtımı gibi başka bir altyapı gerekir.

  13. Tabloya bir süre erişilemezse ne olur:

    Depolama hizmeti kapalı, kullanılamıyor veya bununla ilgili iletişim sorunları olduğunda protokol siloları Orleans yanlışlıkla ölü olarak bildirmeZ. operasyonel silolar sorunsuz çalışmaya devam edecektir. Ancak, Orleans bir silonun öldüğünü bildiremez (eksik yoklamalar aracılığıyla bazı siloların öldüğünü algılarsa, bu gerçeği tabloya yazamaz) ve yeni siloların katılmasına izin vermez. Bu nedenle tamlık zarar görecek, ancak doğruluk zarar görmez — tablodan bölümlendirme, Orleans'ın yanlışlıkla siloyu ölü ilan etmesine neden olmaz. Ayrıca, kısmi bir ağ bölümü olması durumunda (bazı silolar tabloya erişebiliyorsa ve bazıları erişemiyorsa), Orleans ölü siloyu ölü olarak bildirecek, ancak diğer tüm siloların bunu öğrenmesi biraz zaman alacaktır. Bu nedenle algılama gecikebilir, ancak Orleans tablo kullanılamazlığı nedeniyle hiçbir zaman yanlışlıkla bir silo öldürmez.

  14. IAmAlive, tanılama ve olağanüstü durum kurtarma için yazılar yazar:

    Silolar arasında gönderilen kalp atışlarına ek olarak, her silo tablodaki satırındaki "Hayattayım" zaman damgasını düzenli aralıklarla günceller. Bu iki amaca hizmet eder:

    1. Tanılama için sistem yöneticilerine küme canlılığını denetlemenin ve siloların en son ne zaman etkin olduğunu belirlemenin basit bir yolunu sağlar. Zaman damgası genellikle 5 dakikada bir güncelleştirilir.
    2. Afet kurtarma için, bir silo birkaç dönem boyunca zaman damgasını güncellemediyse (NumMissedTableIAmAliveLimitaracılığıyla yapılandırılır), yeni silolar başlangıç bağlantı kontrolleri sırasında bunu yoksayar ve kümenin, siloların düzgün temizlenmeden çökmesi gibi durumlarda toparlanmasını sağlar.

Üyelik tablosu

Daha önce de belirtildiği gibi, IMembershipTable siloların birbirini Orleans bulması ve istemcilerin siloları bulması için bir buluşma noktası olarak kullanılır ve ayrıca üyelik görünümünde sözleşmenin koordine olmasına yardımcı olur. Ana Orleans deposu, Azure Tablo Depolama, Azure Cosmos DB, PostgreSQL, MySQL/MariaDB, SQL Sunucusu, Apache ZooKeeper, Consul IO, Apache Cassandra, MongoDB, Redis, AWS DynamoDB gibi birçok sistem için uygulamalar ve geliştirme için bellek içi bir uygulama içerir.

  1. Azure Tablo Depolama : Bu uygulamada bölüm anahtarı olarak Azure dağıtım kimliğini ve satır anahtarı olarak silo kimliğini (ip:port:epoch) kullanırız. Birlikte silo başına benzersiz bir anahtar garanti ederler. Eşzamanlılık denetimi için Azure Tablo ETag'lerini temel alan iyimser eşzamanlılık denetimini kullanırız. Tablodan her okuma yaptığımızda, her okuma satırı için ETag'i depolar ve geri yazmaya çalışırken bu ETag'i kullanırız. ETag'ler her yazmada Azure Tablo hizmeti tarafından otomatik olarak atanır ve denetlenır. Çok satırlı işlemler için Azure tablosu tarafından sağlanan ve aynı bölüm anahtarına sahip satırlar üzerinde serileştirilebilir işlemleri garanti eden toplu işlemler desteğini kullanırız.

  2. SQL Server - Bu uygulamada, yapılandırılan dağıtım kimliği dağıtımları ve hangi siloların hangi dağıtımlara ait olduğunu ayırt etmek için kullanılır. Silo kimliği, uygun tablo ve sütunların deploymentID, ip, port, epoch birleşimi olarak tanımlanır. İlişkisel arka uç, Azure Tablo uygulamasında ETag kullanma yordamına benzer şekilde iyimser eşzamanlılık denetimi ve işlemleri kullanır. İlişkisel uygulama, veritabanı altyapısının kullanılan ETag'i oluşturmasını bekler. SQL Server söz konusu olduğunda, SQL Server 2000'de oluşturulan ETag bir çağrısından NEWID()alınır. SQL Server 2005 ve sonraki sürümlerde ROWVERSION kullanılır. Orleansilişkisel ETag'leri opak VARBINARY(16) etiketler olarak okur ve yazar ve base64 kodlanmış dizeler olarak bellekte depolar. Orleans , şu anda istatistik verileri eklemek için kullanılan kullanarak (DUAL dahil Oracle için) çok satırlı eklemeleri UNION ALL destekler. SQL Server için tam uygulama ve gerekçe CreateOrleansTables_SqlServer.sql görülebilir.

  3. Apache ZooKeeper - Bu uygulamada, yapılandırılan dağıtım kimliğini kök düğüm olarak ve silo kimliğini (ip:port@epoch) alt düğümü olarak kullanırız. Birlikte silo başına benzersiz bir yol garanti ederler. Eşzamanlılık denetimi için düğüm sürümünü temel alan iyimser eşzamanlılık denetimini kullanırız. Dağıtım kök düğümünden her okuduğumuz zaman, her okuma alt silosu düğümü için sürümü depolar ve geri yazmaya çalışırken bu sürümü kullanırız. Bir düğümün verileri her değiştiğinde, sürüm numarası ZooKeeper hizmeti tarafından atomik olarak artar. Çok satırlı işlemler için, aynı üst dağıtım kimliği düğümüne sahip silo düğümleri üzerinden serileştirilebilir işlemleri garanti eden çok satırlı yöntemi kullanırız.

  4. Konsolos GÇ - Üyelik tablosunu uygulamak için Consul'un Anahtar/Değer depounu kullandık. Diğer ayrıntılar için Bkz. Konsoloslu Dağıtım .

  5. AWS DynamoDB - Bu uygulamada küme Dağıtım Kimliği'ni Bölüm Anahtarı olarak ve Silo Kimliği (ip-port-generation), kaydı birleştiren RangeKey olarak kullanırız. İyimser eşzamanlılık, DynamoDB'de koşullu yazmalar yapılarak özniteliği tarafından ETag yapılır. Uygulama mantığı, Azure Tablo Depolama'ya oldukça benzer.

  6. Apacha Cassandra - Bu uygulamada bölüm anahtarı olarak Hizmet Kimliği ve Küme Kimliği bileşimini, satır anahtarı olarak silo kimliğini (ip:port:epoch) kullanırız. Birlikte silo başına benzersiz bir satır garanti ederler. Eşzamanlılık denetimi için Basit İşlem kullanan statik sütun sürümünü temel alan iyimser eşzamanlılık denetimini kullanırız. Bu sürüm sütunu, bölüm/kümedeki tüm satırlar için paylaşılır, bu nedenle her kümenin üyelik tablosu için tutarlı bir artan sürüm numarası sağlar. Bu uygulamada çok satırlı transaksiyon yok.

  7. Geliştirme kurulumu için bellek içi öykünme. Bu uygulama için özel bir sistem dilimi kullanırız. Bu tahıl, yalnızca geliştirme kurulumu için kullanılan, belirlenen birincil siloda bulunur. Herhangi bir gerçek üretim kullanımda birincil silo gerekli değildir.

Tasarım mantığı

Doğal olarak sorulabilecek bir soru, neden küme üyeliği uygulaması için tamamen Apache ZooKeeper veya etcd'e güvenilmediğidir; potansiyel olarak ZooKeeper'ın kısa ömürlü düğümlerle grup üyeliği için kullanıma hazır desteği kullanılabilir mi? Üyelik protokolümüzü uygulamaya neden zahmet ettik? Başlıca üç neden vardır:

  1. Bulutta dağıtım/barındırma:

    Zookeeper barındırılan bir hizmet değildir. Bu, Bulut ortamında Orleans müşterilerin bir ZK kümesi örneğini dağıtması/çalıştırması/yönetmesi gerekeceği anlamına gelir. Bu, müşterilerimizi zorlamak istemediğimiz başka bir gereksiz yüktür. Azure Tablosu'nu kullanarak, müşterilerimizin hayatını çok daha basit hale getiren barındırılan, yönetilen bir hizmete güveniriz. Temel olarak, Bulutta Bulutu Altyapı olarak değil Platform olarak kullanın. Öte yandan, şirket içinde çalışırken ve sunucularınızı yönetirken, uygulamasının ZK'sine IMembershipTable güvenmek uygulanabilir bir seçenektir.

  2. Doğrudan hata algılama:

    Kısa ömürlü düğümlerle ZK'nin grup üyeliği kullanılırken, sunucular (ZK istemcileri) ile ZK sunucuları arasında Orleans hata algılama gerçekleştirilir. Bunun sunucular arasındaki Orleans gerçek ağ sorunlarıyla bağıntılı olması şart olmayabilir. İsteklerimiz, hata algılamanın iletişimin küme içi durumunu doğru şekilde yansıtmasıydı. Özellikle, tasarımımızda, bir Orleans silo ile IMembershipTable iletişim kuramazsa ölü olarak kabul edilmez ve çalışmaya devam edebilir. Bunun aksine, kısa ömürlü düğümlerle ZK grup üyeliği kullandık mı bir ZK sunucusu bağlantısı kesildiğinde silo Orleans (ZK istemcisi) ölü olarak bildirilebilirken, canlı ve tamamen işlevsel olabilir.

  3. Taşınabilirlik ve esneklik:

    'nin felsefesinin Orleansbir parçası olarak, belirli bir teknolojiye güçlü bir bağımlılığı zorlamak istemiyoruz, farklı bileşenlerin farklı uygulamalarla kolayca değiştirilebileceği esnek bir tasarıma sahip olmak istiyoruz. Soyutlamanın tam olarak amacı budur IMembershipTable .

Üyelik protokolünün özellikleri

  1. Herhangi bir sayıda hatayı işleyebilir:

    Algoritmamız tam küme yeniden başlatma dahil olmak üzere herhangi bir sayıda hatayı (f<=n) işleyebilir. Bu, genellikle çoğunluğu olan bir çekirdek gerektiren "geleneksel" Paxos tabanlı çözümlerin aksinedir. Siloların yarısından fazlasının devre dışı olduğu üretim durumlarında gördük. Sistemimiz çalışır durumda kalırken Paxos tabanlı üyelik ilerleme kaydedemez.

  2. Tabloya trafik çok hafiftir:

    Gerçek yoklamalar doğrudan sunucular arasında gider ve tabloya gitmez. Bu, hata algılama perspektifinden çok fazla trafik artı daha az doğru olacaktır - eğer bir silo tabloya ulaşamazsa, canlıyım sinyalini yazmayı kaçırır ve diğerleri onu öldürür.

  3. Ayarlanabilir doğruluk ve tamlık:

    Hem mükemmel hem de doğru hata algılamayı başaramasanız da, genellikle doğruluk (ölü olarak yaşayan bir silo bildirmek istemiyorum) ile denge yeteneği ister (ölü olarak yaşayan bir silo bildirmek istemez) (gerçekten de ölü olan bir silo'yu mümkün olan en kısa sürede bildirmek istiyor). Ölü ve cevapsız sondaları bildirmek için yapılandırılabilir oylar, bu ikisi arasında değişim yapılmasına olanak tanır. Daha fazla bilgi için bkz . Yale Üniversitesi: Bilgisayar Bilimi Hata Algılayıcıları.

  4. Ölçek:

    Protokol binlerce ve hatta muhtemelen on binlerce sunucuyu işleyebilir. Bu, onlarcadan fazla ölçeklendirilmediği bilinen grup iletişim protokolleri gibi geleneksel Paxos tabanlı çözümlerin aksinedir.

  5. Tanılama:

    Tablo tanılama ve sorun giderme için de çok uygundur. Sistem yöneticileri, mevcut canlı silo listesini tabloda anında bulabilir ve tüm ölen siloların ve şüphelerin geçmişini görebilir. Bu, özellikle sorunları tanılarken yararlıdır.

  6. uygulamasının uygulanması için neden güvenilir kalıcı depolamaya IMembershipTableihtiyacımız var?

    IMembershipTable için kalıcı depolamayı iki amaçla kullanırız. İlk olarak, siloların birbirini Orleans bulması ve istemcilerin siloları bulması için bir randevu noktası olarak kullanılır. İkincisi, sözleşmeyi üyelik görünümünde koordine etmemize yardımcı olması için güvenilir depolamayı kullanırız. Silolar arasında doğrudan eşler arası bir şekilde hata algılama gerçekleştirirken, üyelik görünümünü güvenilir depolamada depolar ve bu depolama tarafından sağlanan eşzamanlılık denetim mekanizmasını kullanarak kimin yaşadığını ve kimin öldüğünü belirtiriz. Bu şekilde protokolümüz, buluta dağıtılmış konsensüs sorununu dış kaynak olarak kullanır. Bu nedenle temel alınan bulut platformunun gücünden tam olarak yararlanır ve bunu gerçekten Hizmet Olarak Platform (PaaS) olarak kullanırız.

  7. Doğrudan IAmAlive yalnızca tanılama için tabloya yazar:

    Silolar arasında gönderilen sinyallere ek olarak, her silo da tablodaki satırındaki bir "Yaşıyorum" sütununu düzenli aralıklarla güncelleştirir. Bu "Ben Hayattayım" sütunu yalnızca el ile sorun giderme ve tanılama için kullanılır ve üyelik protokollerinin kendisi tarafından kullanılmaz. Genellikle çok daha düşük bir sıklıkta (5 dakikada bir) yazılır ve sistem yöneticilerinin kümenin canlılığını denetlemesi veya silonun en son ne zaman canlı olduğunu kolayca bulması için çok yararlı bir araç olarak hizmet eder.

Bildirimler

Alex Kogan'ın bu protokolün ilk sürümünün tasarımına ve uygulanmasına katkısını kabul etmek istiyoruz. Bu çalışma, 2011 Yazında Microsoft Research'te yaz stajı kapsamında yapılmıştır. ZooKeeper tabanlı IMembershipTable uygulaması Shay Hazortarafından, SQL IMembershipTable uygulaması Veikko Eevatarafından, AWS DynamoDB IMembershipTable uygulaması ise Gutem tarafından yapıldı Ribeiro ve Konsolos tabanlı IMembershipTable uygulaması Paul Northtarafından yapıldı ve son olarak Apache Cassandra IMembershipTable uygulaması Arshia001tarafından OrleansCassandraUtils'dan uyarlandı.