Aracılığıyla paylaş

'da küme yönetimi Orleans

  • Makale

Orleans, bazen Silo Üyeliği olarak 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 bir No-SQL benzeri dayanıklı 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 Azure Tablo Depolama, SQL sunucusu, Apache ZooKeeper, Consul IO, AWS DynamoDB ve geliştirme için bellek içi öykünme temelinde 6 uygulamasına IMembershipTablesahibiz.

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. 'nin üyelik protokolünün Orleansiç uygulamasını aşağıda açıklayarak başlıyoruz ve daha sonra uygulamasını açıklıyoruz IMembershipTable.

Temel Ü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ğinin 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 ping'leri ("yaşıyor musunuz" heartbeats) aracılığıyla birbirlerini doğrudan izler. Ping'ler silodan siloya doğrudan ileti olarak, siloların iletişimde olduğu TCP yuvaları üzerinden gönderilir. Bu şekilde, ping işlemleri gerçek ağ sorunları ve sunucu durumu ile tamamen bağıntılı olur. Her silo, yapılandırılabilir bir diğer silo kümesine ping atabilir. Silo, diğer siloların kimliğindeki tutarlı karmaları hesaplayarak, tüm kimliklerin sanal halkasını oluşturarak ve halkada X ardıl siloları seçerek kime ping göndereceğini seçer (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 P sunucularından Y ping yanıtları almazsa, zaman damgası şüphesini içindeki P'nin satırına IMembershipTableyazarak bundan şüphelenir.

  4. P'nin K saniye içinde Z'den fazla şüphesi varsa, S P'nin yerine P'nin öldüğünü yazar ve tüm siloların üyelik tablosunu yeniden okuması için bir istek yayınlar (yine de düzenli aralıklarla yapar).

  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 kullanmıyoruz. "İş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. Yapılandırma: Azure'da üretim kullanımımız sırasında el ile ayarlanmış bir varsayılan yapılandırma sağlarız. Şu anda varsayılan değer şudur: 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). Pingler on saniyede bir gönderilir ve silodan şüphelenmek için üç ping'i kaçırmanız gerekir.

  8. Mükemmel Hata algılamayı zorunlu tutma – Silo işleminin kendisi çalışmaya devam ederken, diğer silolarla iletişimi kaybettiğinde bir silonun öldüğü bildirilmesi teorik olarak mümkündür. Silo tabloda ölü olarak bildirildikten sonra bu sorunu çözmek için, ölü olmasa bile herkes tarafından ölü olarak kabul edilir (yalnızca geçici olarak bölümlendi veya sinyal iletileri kayboldu). 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. Gerekli olmadığında başka bir altyapı gerekir. Örneğin, hata veya Kubernetes dağıtımında otomatik olarak yeniden başlatılmak üzere yapılandırılmış bir Windows Hizmeti.

  9. Düzenli aralıklarla tablo okuma sıklığını azaltmak ve yeni birleştirme siloları ve ölü silolar hakkında bilgi edinen tüm siloları hızlandırmak için iyileştirme. Her silo tabloya başarılı bir şekilde bir şey yazdığında (şüphe, yeni katılım vb.) diğer tüm silolara da yayınlar: "Git ve tabloyu şimdi yeniden oku". Silo, tabloya yazdıklarını başkalarına SÖYLEMEZ (bu bilgiler zaten eski/yanlış olabileceğinden), yalnızca tabloyu yeniden okumalarını söyler. Bu şekilde, tam düzenli okuma döngüsünü beklemeye gerek kalmadan üyelik değişiklikleri hakkında çok hızlı bir şekilde bilgi ediniriz. "Tabloyu yeniden oku" iletisinin kaybolması durumunda düzenli olarak okunmasını istiyoruz.

Temel ü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 ping'ler tabloya değil sunucular arasında doğrudan gider. 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 pingleri bildirmek için yapılandırılabilir oylar bu ikisinin alım satımına izin verir. Daha fazla bilgi için bkz . Yale Üniversitesi: Bilgisayar Bilimi Hata Algılayıcıları.

  4. Ölçek:

    Temel 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?

    Kalıcı depolamayı (Azure tablosu, SQL Server, AWS DynamoDB, Apache ZooKeeper veya Consul IO KV) IMembershipTable 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. 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 (bazı siloların yanıtsız pingler aracılığıyla ö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örür, ancak doğruluk olmaz; tablodan bölümleme, silonun yanlışlıkla ölü olarak bildirilmesine neden Orleans 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.

  8. 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.

Üyelik görünümlerini sıralamak için uzantı

Yukarıda açıklanan temel üyelik protokolü daha sonra sıralı üyelik görünümlerini destekleyecek şekilde genişletilmişti. Bu uzantının nedenlerini ve nasıl uygulandığını kısaca açıklayacağız. Uzantı yukarıdaki tasarımda hiçbir şeyi değiştirmez, yalnızca tüm üyelik yapılandırmalarının genel olarak tamamen sıralanmış olduğu özelliğini ekler.

Üyelik görünümlerini sıralamak neden yararlıdır?

  • Bu, kümeye yeni siloların birleştirilmesini serileştirmeye olanak tanır. Bu şekilde, yeni bir silo kümeye katıldığında, zaten başlamış olan diğer tüm silolara iki yönlü bağlantıyı doğrulayabilir. Bunlardan bazıları zaten katılmış silolara yanıt vermiyorsa (potansiyel olarak yeni siloyla ilgili bir ağ bağlantısı sorunu olduğunu gösteriyorsa), yeni silonun katılmasına izin verilmez. Bu, en azından bir silo başlatıldığında kümedeki tüm silolar arasında tam bağlantı olmasını sağlar (bu uygulanır).

  • Silodaki dağıtılmış tanecik dizini gibi daha üst düzey protokoller, üyelik görünümlerinin sıralı olduğu gerçeğini kullanabilir ve daha akıllı yinelenen etkinleştirme çözümlemesi gerçekleştirmek için bu bilgileri kullanabilir. Özellikle, dizin üyelik flux olduğunda 2 etkinleştirme oluşturulduğunu öğrendiğinde, artık güncel olmayan üyelik bilgilerine göre oluşturulan eski etkinleştirmeyi devre dışı bırakma kararı verebilir.

Genişletilmiş üyelik protokolü:

  1. Bu özelliğin uygulanması için tarafından MembershipTablesağlanan birden çok satırdaki işlemler için destek kullanırız.

  2. Tabloya, tablo değişikliklerini izleyen bir üyelik sürümü satırı ekleriz.

  3. Silo S, S silo P için şüphe veya ölüm bildirimi yazmak istediğinde:

    1. S, en son tablo içeriğini okur. Eğer P zaten öldüyse, hiçbir şey yapma. Yoksa
    2. Aynı işlemde, değişiklikleri P'nin satırına yazın ve sürüm numarasını artırıp tabloya geri yazın.
    3. Her iki yazma da ETag'ler ile koşullandırılır.
    4. P satırında veya sürüm satırında ETag uyuşmazlığı nedeniyle işlem durdurulırsa yeniden deneyin.

  4. Tabloya yapılan tüm yazma işlemleri sürüm satırını değiştirir ve artırır. Bu şekilde tabloya yapılan tüm yazma işlemleri serileştirilir (sürüm satırındaki güncelleştirmeler seri hale getirilerek) ve silolar yalnızca sürüm numarasını artırdığından, yazma işlemleri de artan düzende sıralanır.

Genişletilmiş üyelik protokolünün ölçeklenebilirliği:

Protokolün genişletilmiş sürümünde, tüm yazma işlemleri tek bir satır aracılığıyla serileştirilir. Bu durum, eşzamanlı tablo yazma işlemleri arasındaki çakışma riskini artırdığından küme yönetimi protokolünün ölçeklenebilirliğine zarar verebilir. Bu sorunu kısmen azaltmak için silolar, üstel geri alma kullanarak tabloya yapılan tüm yazma işlemlerini yeniden dener. Genişletilmiş protokollerin 200 siloya kadar Azure'daki bir üretim ortamında sorunsuz çalıştığını gözlemledik. Ancak protokolün bin silonun ötesine ölçeklendirme sorunları olabileceğini düşünüyoruz. Bu tür büyük kurulumlarda, sürüm satırındaki güncelleştirmeler kolayca devre dışı bırakılabilir ve temelde küme yönetimi protokolünün geri kalanı korunur ve toplam sıralama özelliğinden vazgeçilebilir. Burada, geri kalanına Orleansdeğil küme yönetimi protokolünün ölçeklenebilirliğine başvurduğunu da unutmayın. Çalışma zamanının diğer bölümlerinin Orleans (mesajlaşma, dağıtılmış dizin, tahıl barındırma, istemciden ağ geçidine bağlantı) yüzlerce silonun ötesinde ölçeklenebilir bir yol olduğuna inanıyoruz.

Ü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. Şu anda azure tablosu, SQL sunucusu, Apache ZooKeeper, Consul IO, AWS DynamoDB ve geliştirme için bellek içi öykünme temelinde altı uygulamasına IMembershipTablesahibiz.

  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. Geliştirme kurulumu için bellek içi öykünme. Bu uygulama için adlı MembershipTableGrainö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.

Yapılandırma

Üyelik protokolü, OrleansConfiguration.xml dosyasının Liveness Globals bölümündeki öğesi aracılığıyla yapılandırılır. Varsayılan değerler Azure'daki üretim kullanım yıllarına göre ayarlanmıştır ve bunların iyi varsayılan ayarları temsil ettiklerine inanıyoruz. Genel olarak bunları değiştirmeye gerek yoktur.

Örnek yapılandırma öğesi:

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

Uygulanan 4 canlılık türü vardır. Canlılık protokolünün türü, OrleansConfiguration.xml dosyasındaki bölümündeki öğesinin Globals özniteliği SystemStore aracılığıyla SystemStoreType yapılandırılır.

  1. MembershipTableGrain: üyelik tablosu birincil silodaki bir tanecikte depolanır. Bu yalnızca bir geliştirme kurulumudur.
  2. AzureTable: üyelik tablosu Azure tablosunda depolanır.
  3. SqlServer: üyelik tablosu ilişkisel veritabanında depolanır.
  4. ZooKeeper: üyelik tablosu bir ZooKeeper grubunda depolanır.
  5. Consul: ile MembershipTableAssembly = "OrleansConsulUtils"Özel sistem deposu olarak yapılandırıldı. Diğer ayrıntılar için Bkz. Konsoloslu Dağıtım .
  6. DynamoDB: ile MembershipTableAssembly = "OrleansAWSUtils"Özel sistem deposu olarak yapılandırılır.

Tüm canlılık türleri için ortak yapılandırma değişkenleri öğesinde Globals.Liveness tanımlanır:

  1. ProbeTimeout: Diğer siloların canlılıkları veya silonun kendisi hakkında "Yaşıyorum" sinyal iletileri göndermesi için yoklama saniye sayısı. Varsayılan değer 10 saniyedir.
  2. TableRefreshTimeout: Üyelik tablosundan güncelleştirmelerin getirilme saniye sayısı. Varsayılan değer 60 saniyedir.
  3. DeathVoteExpirationTimeout: Üyelik tablosunda ölüm oylaması için saniye olarak süre sonu. Varsayılan değer 120 saniyedir
  4. NumMissedProbesLimit: Silodan gelen cevapsız "Yaşıyorum" sinyal iletilerinin sayısı veya bu silonun ölü olduğundan şüphelenmeye neden olan yanıtlanmamış yoklama sayısı. Varsayılan değer 3'dür.
  5. NumProbedSilos: Canlılık için her silo sondasının silo sayısı. Varsayılan değer 3'dür.
  6. NumVotesForDeathDeclaration: Bazı siloların ölü olarak bildirilmesi için gereken süresi dolmamış oyların sayısı (en fazla NumMissedProbesLimit olmalıdır). Varsayılan değer 2'dir.
  7. UseLivenessGossip: Canlılık bilgilerinin yayılmasını hızlandırmak için dedikodu iyileştirmesinin kullanılıp kullanılmaymayacağı. Varsayılanı doğrudur
  8. IAmAliveTablePublishTimeout: Bu silonun etkin olduğu üyelik tablosuna düzenli aralıklarla yazılması gereken saniye sayısı. Yalnızca tanılama için kullanılır. Varsayılan değer 5 dakikadır.
  9. NumMissedTableIAmAliveLimit: Bir uyarının günlüğe kaydedilmesine neden olan silodan tablodaki yanıtsız "Hayattayım" güncelleştirmelerinin sayısı. Canlılık protokollerini etkilemez. Varsayılan değer 2'dir.
  10. MaxJoinAttemptTime: Vazgeçmeden önce bir silo kümesine katılmayı deneyecek saniye sayısı. Varsayılan değer 5 dakikadır.
  11. ExpectedClusterSize: Kümenin beklenen boyutu. Çok doğru olması gerekmez, aşırı tahmin olabilir. Azure tablosuna yazmak için yeniden denemelerin üstel geri alma algoritmasını ayarlamak için kullanılır. Varsayılan değer 20'dir.

Tasarım mantığı

Sorulabilecek doğal bir soru, kısa ömürlü düğümlerle grup üyeliği için kullanıma hazır desteğini kullanarak küme üyeliği uygulaması için neden tamamen Apache ZooKeeper'a güvenilmediğidir? Ü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 (en azından temmuz 2015'in bu yazısında ve kesinlikle bu protokolü 2011 yazında ilk kez uyguladığımızda, herhangi bir büyük bulut sağlayıcısı tarafından barındırılan hizmet olarak çalışan zookeeper sürümü yoktu). 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 .

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 uygulama Shay Hazor tarafından, SQL IMembershipTable uygulaması Veikko Eeva tarafından, AWS DynamoDB IMembershipTable uygulaması Gutemberg Ribeiro tarafından ve Konsolos tabanlı IMembershipTable uygulama Paul North tarafından yapıldı.