'da küme yönetimi Orleans

Orleans , bazen Küme üyeliği olarak da adlandırılan 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.

Üyelik protokolü yapılandırması

Üyelik protokolü aşağıdaki varsayılan yapılandırmayı kullanır:

• Her silo 10 silo daha tarafından izlenir
• Siloların öldüğünü bildirmek için 2 şüphe gerekiyor
• Şüpheler 3 dakika geçerlidir
• Yoklamalar her 10 saniyede bir gönderilir
• 3 cevapsız yoklama şüpheyi tetikliyor

Bu varsayılanlarla, tipik hata algılama süresi yaklaşık 15 saniyedir. Siloların düzgün temizlenmeden çöktüğü olağanüstü durum kurtarma senaryolarında, küme kurtarma için IAmAlive zaman damgası (varsayılan olarak her 30 saniyede bir güncellenir) kullanır. Birkaç süredir zaman damgalarını güncellemeyen silolar, başlangıç bağlantı kontrolleri sırasında görmezden gelinir. Yanıt vermeyen bu siloları atlayarak, yeni silolar başlatılabilir ve başarısız silolar grubunu ölü olarak ilan ederek hızlı bir şekilde temizleyebilir.

Konfigürasyon

kullanarak üyelik protokolü ayarlarını ClusterMembershipOptionsyapılandırabilirsiniz:

siloBuilder.Configure<ClusterMembershipOptions>(options =>
{
    // Number of silos each silo monitors (default: 10)
    options.NumProbedSilos = 10;

    // Number of suspicions required to declare a silo dead (default: 2)
    options.NumVotesForDeathDeclaration = 2;

    // Time window for suspicions to be valid (default: 180 seconds)
    options.DeathVoteExpirationTimeout = TimeSpan.FromSeconds(180);

    // Interval between probes (default: 10 seconds)
    options.ProbeTimeout = TimeSpan.FromSeconds(10);

    // Number of missed probes before suspecting a silo (default: 3)
    options.NumMissedProbesLimit = 3;
});

Ayarların ne zaman ayarlanması gerekir?

Çoğu durumda varsayılan ayarlar uygundur. Ancak, bu senaryolarda düzeltmeleri göz önünde bulundurabilirsiniz:

• Yüksek gecikme süreli ağlar: Silolarınız yüksek ağ gecikme süresine sahip bölgeler arasında dağıtılıyorsa artırın ProbeTimeout .
• Kritik kullanılabilirlik gereksinimleri: Daha hızlı hata algılama için azaltın DeathVoteExpirationTimeout , ancak hatalı pozitiflere karşı dikkatli olun.

Üyelik protokolü yapılandırması

Üyelik protokolü aşağıdaki varsayılan yapılandırmayı kullanır:

• Her silo 3 silo daha tarafından izlenir
• Siloların öldüğünü bildirmek için 2 şüphe gerekiyor
• Şüpheler 3 dakika geçerlidir
• Yoklamalar her 10 saniyede bir gönderilir
• 3 cevapsız yoklama şüpheyi tetikliyor

Üyelik protokolü yapılandırması

Üyelik protokolü aşağıdaki varsayılan yapılandırmayı kullanır:

• Her silo 3 silo daha tarafından izlenir
• Siloların öldüğünü bildirmek için 2 şüphe gerekiyor
• Şüpheler 3 dakika geçerlidir

Protokol, soyutlama IMembershipTablesağlamak için bir dış hizmete dayanır. IMembershipTable iki amaçla kullanılan düz ve dayanıklı bir tablodur. İlk olarak, siloların birbirini bulması ve istemcilerin siloları bulması için Orleans bir buluşma noktası görevi görür. İkincisi, geçerli üyelik görünümünü (etkin siloların listesi) depolar ve bu görünümde anlaşmanın koordinesine yardımcı olur.

Mevcut olan resmi IMembershipTable uygulamaları şunlardır:

• ADO.NET (PostgreSQL, MySQL/MariaDB, SQL Server, Oracle),
• AWS DynamoDB,
• Apache Cassandra,
• Apache ZooKeeper,
• Azure Cosmos DB,
• Azure Tablo Depolama,
• HashiCorp Consul
• Redis,
• ve geliştirme için bellek içi bir uygulama.

Redis kümelemsini yapılandırma

Uzantı yöntemini kullanarak Redis'i UseRedisClustering kümeleme sağlayıcısı olarak yapılandırın:

using StackExchange.Redis;

var builder = Host.CreateApplicationBuilder(args);

builder.UseOrleans(siloBuilder =>
{
    siloBuilder.UseRedisClustering(options =>
    {
        options.ConfigurationOptions = new ConfigurationOptions
        {
            EndPoints = { "localhost:6379" },
            AbortOnConnectFail = false
        };
    });
});

Alternatif olarak, bir bağlantı dizesi kullanabilirsiniz:

siloBuilder.UseRedisClustering("localhost:6379");

RedisClusteringOptions sınıfı aşağıdaki yapılandırma seçeneklerini sağlar:

Mülkiyet	Türü	Description
ConfigurationOptions	ConfigurationOptions	StackExchange.Redis istemci yapılandırması. Gerekli.
EntryExpiry	TimeSpan?	Girişler için isteğe bağlı son kullanma süresi. Bunu yalnızca test gibi kısa ömürlü ortamlar için ayarlayın. Varsayılan null değeridir.
CreateMultiplexer	Func<RedisClusteringOptions, Task<IConnectionMultiplexer>>	Redis bağlantı çoklayıcısını oluşturmak için özel fabrika.
CreateRedisKey	Func<ClusterOptions, RedisKey>	Üyelik tablosu için Redis anahtarını oluşturmak için özel işlev. Varsayılan biçim şeklindedir {ServiceId}/members/{ClusterId}.

Önemli

Arabirimin IMembershipTable uygulamaları dayanıklı bir veri deposu kullanmalıdır. Örneğin, Redis kullanıyorsanız kalıcılığın açıkça etkinleştirildiğinden emin olun. Geçici yapılandırmalar kümenin kullanılamamasıyla sonuçlanabilir.

Aspire kümeleme için tümleştirme

Aspire kullanırken, AppHost projenizde Orleans kümelemeyi bildirimsel olarak yapılandırabilirsiniz. Aspire ortam değişkenleri aracılığıyla gerekli yapılandırmayı silo projelerinize otomatik olarak ekler.

Aspire ile Redis kümeleme

AppHost projesi (Program.cs):

var builder = DistributedApplication.CreateBuilder(args);

var redis = builder.AddRedis("redis");

var orleans = builder.AddOrleans("cluster")
    .WithClustering(redis);

builder.AddProject<Projects.MySilo>("silo")
    .WithReference(orleans)
    .WithReference(redis);

builder.Build().Run();

Silo projesi (Program.cs):

var builder = Host.CreateApplicationBuilder(args);

builder.AddServiceDefaults();
builder.AddKeyedRedisClient("redis");
builder.UseOrleans();

builder.Build().Run();

Azure Tablo Depolaması kümeleme ile Aspire

AppHost projesi (Program.cs):

var builder = DistributedApplication.CreateBuilder(args);

var storage = builder.AddAzureStorage("storage")
    .RunAsEmulator();  // Use Azurite for local development
var tables = storage.AddTables("clustering");

var orleans = builder.AddOrleans("cluster")
    .WithClustering(tables);

builder.AddProject<Projects.MySilo>("silo")
    .WithReference(orleans)
    .WaitFor(storage);

builder.Build().Run();

Silo projesi (Program.cs):

var builder = Host.CreateApplicationBuilder(args);

builder.AddServiceDefaults();
builder.AddKeyedAzureTableServiceClient("clustering");
builder.UseOrleans();

builder.Build().Run();

Tip

Yerel geliştirme için Azurite simülatörünü kullanmak üzere Azure Depolama kaynağında .RunAsEmulator() komutunu çalıştırın. Bu çağrı olmadan, Aspire gerçek bir Azure Depolama bağlantısı bekler.

Azure Cosmos DB ile kümeleme

AppHost projesi (Program.cs):

var builder = DistributedApplication.CreateBuilder(args);

var cosmos = builder.AddAzureCosmosDB("cosmos")
    .RunAsEmulator();  // Use emulator for local development
var database = cosmos.AddCosmosDatabase("orleans");

var orleans = builder.AddOrleans("cluster")
    .WithClustering(database);

builder.AddProject<Projects.MySilo>("silo")
    .WithReference(orleans)
    .WaitFor(cosmos);

builder.Build().Run();

Silo projesi (Program.cs):

var builder = Host.CreateApplicationBuilder(args);

builder.AddServiceDefaults();
builder.AddKeyedAzureCosmosClient("cosmos");
builder.UseOrleans();

builder.Build().Run();

Uyarı

Aspireiçin Cosmos DB tümleştirmesi Orleans şu anda yalnızca kümeleme desteği sağlar. Cosmos DB ile tahıl depolama ve anımsatıcılar için, bu sağlayıcıları silo projesinde manuel olarak yapılandırmanız gerekir.

Önemli

Yedek kaynağı bağımlılık ekleme kapsayıcısına kaydetmek için uygun AddKeyed* yöntemini (örneğin, AddKeyedRedisClient, AddKeyedAzureTableServiceClient veya AddKeyedAzureCosmosClient) çağırmalısınız. Orleans sağlayıcılar kaynakları anahtarlı hizmet adlarına göre arar; bu adımı atlarsanız, Orleans kaynağı çözümleyemez ve çalışma zamanında bağımlılık çözümleme hatası oluşturur.

Orleans ve Aspire tümleştirmesi hakkında daha fazla bilgi için Orleans ve Aspire tümleştirmesine bakın.

Cassandra kümelemsini yapılandırma

UseCassandraClustering uzantı metodunu kullanarak kümeleme sağlayıcısı olarak Apache Cassandra'yı yapılandırın. Microsoft'u yükleyin.Orleans. Clustering.Cassandra NuGet paketi:

dotnet add package Microsoft.Orleans.Clustering.Cassandra

Cassandra kümelemesini bir bağlantı dizesiyle yapılandırın:

using Orleans.Clustering.Cassandra.Hosting;

var builder = Host.CreateApplicationBuilder(args);

builder.UseOrleans(siloBuilder =>
{
    siloBuilder.UseCassandraClustering(
        connectionString: "Contact Points=localhost;Port=9042",
        keyspace: "orleans");
});

Alternatif olarak, daha fazla denetim için seçenekler tabanlı yapılandırmayı kullanın:

siloBuilder.UseCassandraClustering(options =>
{
    options.ConfigureClient("Contact Points=cassandra-node1,cassandra-node2;Port=9042", "orleans");
    options.UseCassandraTtl = true;
    options.InitializeRetryMaxDelay = TimeSpan.FromSeconds(30);
});

Veya gelişmiş senaryolar için özel bir oturum fabrikası sağlayın:

using Cassandra;

siloBuilder.UseCassandraClustering(async serviceProvider =>
{
    var cluster = Cluster.Builder()
        .AddContactPoints("cassandra-node1", "cassandra-node2")
        .WithPort(9042)
        .WithCredentials("username", "password")
        .WithQueryOptions(new QueryOptions().SetConsistencyLevel(ConsistencyLevel.Quorum))
        .Build();

    return await cluster.ConnectAsync("orleans");
});

CassandraClusteringOptions sınıfı aşağıdaki yapılandırma seçeneklerini sağlar:

Mülkiyet	Türü	Varsayılan	Description
UseCassandraTtl	bool	false	Cassandra'daki üyelik tablosu satırlarının geçerlilik süresini true ile yapılandırarak, küme artık çalışmıyor olsa bile işe yaramaz durumdaki silo temizliği yapılmasını sağlar. DefunctSiloExpiration'den ClusterMembershipOptions kullanır.
InitializeRetryMaxDelay	TimeSpan	20 saniye	Başlatma sırasında çekişmeyle karşılaşılırken yeniden denemeler arasındaki en uzun gecikme. Bu genellikle çok sayıda silonun birden çok veri merkezi Cassandra kümesine aynı anda bağlanmasıyla gereklidir.

Cassandra kümeleme ne zaman kullanılır?

Aşağıdaki durumlarda kümeleme için Cassandra'ya göz atmalısınız:

• Kuruluşunuzda zaten bir Cassandra altyapınız var
• Ayarlanabilir tutarlılığı olan birden çok veri merkezinde çalışan bir kümeleme sağlayıcısına ihtiyacınız var
• Küme çalışmadığında bile, işlevsiz siloların temizliği için Cassandra TTL özellikle gereklidir.
• Büyük kümeler için yüksek yazma aktarım hızına ihtiyacınız var

Azure Cosmos DB kümelemsini yapılandırma

Uzantı yöntemini kullanarak Azure Cosmos DB'yi UseCosmosClustering kümeleme sağlayıcısı olarak yapılandırın. Microsoft'u yükleyin.Orleans. Clustering.Cosmos NuGet paketi:

dotnet add package Microsoft.Orleans.Clustering.Cosmos

Cosmos DB kümelemesini bir bağlantı dizesiyle yapılandırın:

using Azure.Identity;

var builder = Host.CreateApplicationBuilder(args);

builder.UseOrleans(siloBuilder =>
{
    siloBuilder.UseCosmosClustering(options =>
    {
        options.ConfigureCosmosClient(
            "https://myaccount.documents.azure.com:443/",
            new DefaultAzureCredential());
        options.DatabaseName = "Orleans";
        options.ContainerName = "OrleansCluster";
        options.IsResourceCreationEnabled = true;
    });
});

Alternatif olarak, bir bağlantı dizesi kullanabilirsiniz:

siloBuilder.UseCosmosClustering(options =>
{
    options.ConfigureCosmosClient("AccountEndpoint=https://myaccount.documents.azure.com:443/;AccountKey=...");
});

CosmosClusteringOptions sınıfı öğesinden CosmosOptions devralır ve aşağıdaki yapılandırma seçeneklerini sağlar:

Mülkiyet	Türü	Varsayılan	Description
DatabaseName	string	"Orleans"	Cosmos DB veritabanının adı.
ContainerName	string	"OrleansCluster"	Küme üyeliği verileri için kapsayıcının adı.
IsResourceCreationEnabled	bool	false	true olduğunda, veritabanı ve kapsayıcı yoksa otomatik olarak oluşturulur.
DatabaseThroughput	int?	null	Veritabanı için sağlanan aktarım hızı. ise nullsunucusuz modu kullanır.
ContainerThroughputProperties	ThroughputProperties?	null	Kapsayıcının aktarım hızı özellikleri.
ClientOptions	CosmosClientOptions	new()	Cosmos DB istemcisine geçirilen seçenekler.
CleanResourcesOnInitialization	bool	false	Başlatma işleminde veritabanını siler. Yalnızca test için.

Cosmos DB kümeleme ne zaman kullanılır?

Aşağıdaki durumlarda kümeleme için Azure Cosmos DB'yi göz önünde bulundurun:

• Uygulamanızda zaten Azure Cosmos DB kullanıyorsunuz
• Çok bölgeli yazma özelliklerine sahip genel olarak dağıtılmış bir veritabanına ihtiyacınız var
• Otomatik ölçeklendirme ile tam olarak yönetilen, sunucusuz bir seçenek istiyorsunuz
• Garantili SLA'larla düşük gecikme süreli okuma ve yazma işlemlerine ihtiyacınız var

Orleans istemcileri için ağ geçidi bulmayı yapılandırmak için UseCosmosGatewayListProvider kullanın.

builder.UseOrleansClient(clientBuilder =>
{
    clientBuilder.UseCosmosGatewayListProvider(options =>
    {
        options.ConfigureCosmosClient(
            "https://myaccount.documents.azure.com:443/",
            new DefaultAzureCredential());
    });
});

IMembershipTable ek olarak, her silo, başarısız siloları algılayan ve canlı silolar kümesi üzerinde bir anlaşmaya varan tam dağıtılmış eşler arası bir üyelik protokolüne katılır. 'nin üyelik protokolünün Orleansiç uygulaması aşağıda açıklanmıştır.

Üyelik protokolü

1. Başlangıçta her silo, IMembershipTable kullanarak iyi bilinen, paylaşılan bir tabloya kendi girdisini ekler. Orleans tabloda benzersiz anahtarlar olarak silo kimliği (ip:port:epoch) ve hizmet dağıtım kimliği (küme kimliği) birleşimini kullanır. Başlangıç dönemi, bu silonun başladığı zaman dilimini basitçe ifade eder ve bu da ip:port:epoch dağıtımı içinde Orleans'nın benzersiz olmasını sağlar.

2. Silolar, uygulama yoklamaları ("yaşıyor musunuz" heartbeats) aracılığıyla birbirlerini doğrudan izler. Yoklamalar, normal iletişim için kullanılan TCP yuvaları üzerinden silodan siloya doğrudan ileti olarak 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 kimliklerinde tutarlı karmaları hesaplayarak, tüm kimliklerin sanal halkasını oluşturarak ve halkadaki X ardıl siloları seçerek kimlerin yoklanacağı 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. Eğer bir silo S, izlenen P sunucusundan Y yoklama yanıtları almazsa, zaman damgalı şüphesini P’nin satırına yazarak P’den şüphelenir.

4. P'nin K saniye içinde Z'den fazla güvensizliği varsa S, P'nin satırına P'nin öldüğünü yazar ve şu anki üyelik tablosunun bir görüntüsünü diğer tüm silolara yayar. 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ısaltan bir iyileştirmedir.

5. Daha ayrıntılı olarak:

   1. Şüphe, IMembershipTable öğesine, P'ye karşılık gelen satırdaki özel bir sütuna yazılır. S, P'den şüphelendiğinde şöyle yazar: "TTT zamanında S, P'den şüphelendi".

   2. Bir şüphe P'nin öldüğünü bildirmek için yeterli değildir. P'nin öldüğünü bildirmek için yapılandırılabilir bir zaman penceresi T (genellikle 3 dakika) içinde farklı silolardan Z şüpheleri almanız gerekir. Şü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 belirtildiği gibi T döneminde Z-1 şüphelileri zaten var), S, P'nin öldüğünü 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, eğer S son şüphelenen değilse, S sadece kendisini şüphecinin sütununa ekler.

   6. Her iki durumda da, geri yazma, sürüm numarasını veya daha önce okunan ETag'i kullanır ve bu satırdaki güncelleştirmeleri serileştirir. Sürüm/ETag uyuşmazlığı nedeniyle yazma işlemi başarısız olursa, S yeniden denenir (P zaten ölü olarak işaretlenmediği sürece yeniden okunur ve yazmaya çalışır).

   7. Yüksek düzeyde, bu "okuma, yerel değişiklik, geri yazma" dizisi bir işlemdir. Ancak, depolama işlemleri her zaman kullanılmaz. "transaction" kodu bir sunucuda yerel olarak yürütülür ve IMembershipTable tarafından sağlanan iyimser eşzamanlılık, yalıtım ve bölünmezlik sağlar.

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

7. Anlık görüntü yayını: Düzenli tablo okuma sıklığını azaltmak için, bir silo tabloya her yazıldığı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. Felaket kurtarma senaryolarında bir istisna için aşağıdaki nota IAmAlive bakın.

   2. Tutarlı dizin güncelleştirmeleri: Dağıtılmış tanecik dizini gibi üst 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 Grain dizini belgelerine 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.
      • Bunu, veritabanı işlemlerini (SQL Server'da olduğu gibi) veya ETag'leri kullanarak atomik karşılaştırma ve değiştirme işlemlerini kullanarak (Azure Tablo Depolama'da olduğu gibi) elde edin.
      • 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ırası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üncelleme başarısız olursa (örneğin, eşzamanlı değişiklikler nedeniyle), işlem üstel geri çekilme 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 etkili olduğunu kanıtlamış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 ve şüpheler yalnızca son üç dakika içinde dikkate alınır (aksi takdirde eskidir). Probeler her on saniyede bir gönderilir ve bir silodan şüphelenmeniz için üç probeyi 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. Bu iki avantaj sağlar:

    • 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 devre dışı bırakmadan önce ö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: Cankurtaran'dan esinlenen başka bir özellik, iyi durumda olmayan veya bölümlenmiş bir silonun hatalı bir şekilde sağlıklı bir silo ölü ilan etme olasılığını azaltarak hata algılama doğruluğunu artırır. İ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ı, hedef siloyla iletişim kurmaya çalışır.
    • Hedef zaman aşımı süresi içinde yanıt vermezse, aracı olumsuz bir bildirim gönderir.
    • İzleme silosu aracıdan olumsuz bir bildirim alırsa ve aracı kendini sağlıklı olarak bildirirse (yukarıda açıklanan kendi kendine izleme yoluyla), izleme silosu hedefin öldüğünü bildirmek için bir oy gönderir.
    • Varsayılan yapılandırmada iki oy gerekli olduğu durumda, dolaylı yoklamadan gelen olumsuz bir geri bildirim her iki oy olarak sayılır ve birden çok perspektif hatayı onayladığında ölü siloların daha hızlı ilan edilmesine olanak tanır.

12. Mükemmel hata algılamayı zorunlu tutma: Bir silo, tabloda ölü olarak bildirildikten sonra, gerçekten ölü olmasa bile herkes onu ölü olarak kabul eder (örneğin, geçici olarak bölümlenmiş olabilir veya sinyal iletileri kaybolmuş olabilir). Herkes onunla iletişim kuramaya son verdi. Silo öldüğünü öğrendikten sonra (yeni durumunu tablodan okuyarak) işlemini sonlandırır. Sonuç olarak, siloyu yeni bir işlem olarak yeniden başlatmak için bir altyapının bulunması gerekir (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 iletişim sorunları yaşadığında Orleans protokol yanlışlıkla siloların öldüğünü BILDIRMEZ. İşletim siloları sorunsuz çalışmaya devam eder. Ancak, Orleans bir silonun öldüğünü bildiremez (kaçırılan yoklamalar aracılığıyla ölü bir silo algılarsa, bu gerçeği tabloya yazamaz) ve yeni siloların katılmasına izin vermez. Bu nedenle, tamlık zarar görse de doğruluk zarar görmez; tablodan bölümleme, hiçbir zaman yanlışlıkla bir silonun öldüğünü bildirmeye neden olmaz. Ayrıca, kısmi bir ağ bölümünde (bazı silolar tabloya erişebilirken bazılarının erişemediği durumlarda) Orleans bir siloyu ölü ilan edebilir, ancak diğer tüm siloların bunu öğrenmesi zaman alacaktır. Algılama gecikebilir, ancak Orleans hiçbir zaman tablo kullanılabilir olmadığında yanlışlıkla bir siloyu sonlandırmaz.

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

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

    1. Tanılama: 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ı varsayılan olarak her 30 saniyede bir güncelleştirilir.

    2. Olağanüstü durum kurtarma: Eğer bir silo zaman damgasını birkaç dönem boyunca güncellememişse (varsayılan: 3, NumMissedTableIAmAliveLimit ile yapılandırılır), yeni silolar başlangıç bağlantı kontrolleri sırasında bunu yoksayar. Bu, kümenin siloların düzgün temizlik yapmadan çöktüğü senaryolardan kurtulmasını sağlar.

Üyelik tablosu

Belirtildiği gibi, IMembershipTable siloların birbirlerini bulması ve istemcilerin siloları bulması için Orleans bir randevu noktası görevi görür. Ayrıca üyelik görüşünde mutabakat sağlanmasına yardımcı olur.

Aşağıdaki listede, resmi uygulamalarından bazıları için uygulama notları yer alır IMembershipTable:

1. Azure Tablo Depolama: Bu uygulamada, Azure dağıtım kimliği bölüm anahtarı olarak görev yapar ve silo kimliği (ip:port:epoch) satır anahtarı olarak görev yapar. 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 denetimi kullanılır. Tablodan veriler her okunduğunda, her okuma satırı için ETag depolanır ve geri yazmaya çalışırken kullanılır. Azure Tablo hizmeti her yazmada otomatik olarak ETag'ler atar ve denetler. Çok satırlı işlemler için Azure Tablosu tarafından sağlanan toplu işlemler desteği kullanılır ve aynı bölüm anahtarına sahip satırlar üzerinde serileştirilebilir işlemler garanti edilir.

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 eder. 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'leri kullanmaya benzer şekilde iyimser eşzamanlılık denetimi ve işlemleri kullanır. İlişkisel uygulama, veritabanı altyapısının ETag'i oluşturmasını bekler. SQL Server 2000 için, oluşturulan ETag, bir NEWID() çağrısından 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 verilerini eklemek için kullanılan UNION ALL'i kullanarak çok satırlı eklemeleri destekler (Oracle için, DUAL dahil). SQL Server için tam uygulama ve gerekçe CreateOrleansTables_SqlServer.sql dosyasında mevcuttur.

3. Apache ZooKeeper: Bu uygulamada, yapılandırılan dağıtım kimliği kök düğüm ve silo kimliği (ip:port@epoch) alt düğümü olarak kullanılır. 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 denetimi kullanılır. Dağıtım kök düğümünden her veri okunduğunda, okunan her alt silo düğümünün sürümü depolanır ve ardından geri yazma işlemi sırasında kullanılır. Bir düğümün verileri her değiştiğinde ZooKeeper hizmeti sürüm sayısını atomik olarak artırır. Ç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 çoklu yöntem kullanılır.

4. HashiCorp Consul: Üyelik tablosunu uygulamak için Konsolos'un Anahtar/Değer deposu kullanıldı. Diğer ayrıntılar için bkz. Konsolos dağıtımı .

5. AWS DynamoDB: Bu uygulamada küme Dağıtım Kimliği Bölüm Anahtarı ve Silo Kimliği (ip-port-generation) olarak RangeKey olarak kullanılır ve kaydı benzersiz hale getirir. İyimser eşzamanlılık, DynamoDB'de koşullu yazma işlemleri yapılarak özniteliği kullanılarak ETag elde edilir. Uygulama mantığı, Azure Tablo Depolama'ya oldukça benzer.

6. Apache Cassandra: Bu uygulamada Hizmet Kimliği ve Küme Kimliği bileşimi bölüm anahtarı, silo kimliği (ip:port:epoch) ise satır anahtarı olarak görev alır. 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 denetimi kullanılır. Bu sürüm sütunu, bölüm/kümedeki tüm satırlar için paylaşılır ve her kümenin üyelik tablosu için tutarlı bir artımlı 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ılır. Bu tahıl, yalnızca geliştirme kurulumu için kullanılan, belirlenen birincil siloda bulunur. Gerçek üretim kullanımlarında birincil silo gerekli değildir.

Tasarım mantığı

Doğal bir soru, küme üyeliği uygulaması için neden Apache ZooKeeper veya etcd'ye tamamen güvenilip ZooKeeper'ın kısa ömürlü düğümlerle grup üyeliği için sunduğu doğrudan desteği kullanılmadığı olabilir? Üyelik protokolümüzü neden uygulayasın? Başlıca üç neden vardır:

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

   Zookeeper barındırılan bir hizmet değildir. Bu, Orleans bulut ortamında müşterilerin bir ZK kümesi örneğini dağıtması, çalıştırması ve yönetmesi gerekeceği anlamına gelir. Bu, müşterilere yüklenmemiş gereksiz bir yüktür. Azure Tablosu'nu Orleans kullanarak barındırılan, yönetilen bir hizmete dayanır ve müşterilerin yaşamlarını çok daha basit hale getirir. Temel olarak, Bulutta Altyapı olarak değil, Platform olarak Bulut kullanın. Öte yandan şirket içinde çalışırken ve sunucularınızı yönetirken ZK'yi uygulaması IMembershipTable olarak kullanma uygun bir seçenektir.

2. Doğrudan hata algılama:

   Geçici düğümlerle ZK'nin grup üyeliği kullanılırken, Orleans sunucular (ZK istemcileri) ile ZK sunucuları arasında hata algılama gerçekleşir. Bunun sunucular arasındaki Orleans gerçek ağ sorunlarıyla bağıntılı olması şart olmayabilir. İstek, hata algılamanın iletişimin küme içi durumunu doğru şekilde yansıtmasıydı. Özellikle, bu tasarımda, bir Orleans silo ile IMembershipTableiletişim kuramıyorsa, ölü olarak kabul edilmez ve çalışmaya devam edebilir. Buna karşılık, kısa ömürlü düğümlerle ZK grup üyeliği kullanıldıysa, ZK sunucusuyla bağlantı kesilmesi bir Orleans silo'nun (ZK istemcisi) ölü olarak bildirilmesine neden olabilir, oysa silo aslında canlı ve tamamen işlevsel durumda olabilir.

3. Taşınabilirlik ve esneklik:

   Felsefesinin Orleansbir parçası olarak, Orleans belirli bir teknolojiye güçlü bir bağımlılığı zorlamaz, bunun yerine farklı bileşenlerin farklı uygulamalarla kolayca değiştirilebileceği esnek bir tasarım sağlar. Soyutlamanın IMembershipTable amacı tam olarak budur.

Üyelik protokolünün özellikleri

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

   Bu algoritma, tam küme yeniden başlatma dahil olmak üzere herhangi bir sayıda hatayı (f<=n) işleyebilir. Bu, oybirliği (genellikle çoğunluk) gerektiren "geleneksel" Paxos tabanlı çözümler ile tezat oluşturur. Üretim durumlarında siloların yarısından fazlasının devre dışı olduğu senaryolar gösterilmiştir. Bu sistem çalışır durumda kalırken Paxos tabanlı üyelik ilerleme kaydedemez.

2. Tabloya veri akışı çok az

   Gerçek yoklamalar tabloya değil doğrudan sunucular arasında gider. Tablo üzerinden probelerin yönlendirilmesi büyük miktarda trafik oluşturacaktır ve hata algılama perspektifinden daha az doğru olacaktır. Eğer bir silo tabloya ulaşamazsa "Hayattayım" sinyalini yazmayı başaramaz ve diğerleri onu ölü olarak ilan eder.

3. Ayarlanabilir doğruluk ve tamlık:

   Hem mükemmel hem de doğru hata algılamayı sağlayamasanız da, genellikle doğruluk (canlı bir silonun ölü olduğunun yanlış bir şekilde ilan edilmesini istememek) ile eksiksizlik (ölü bir silonun mümkün olan en kısa sürede ölü olduğunun ilan edilmesini istemek) arasında bir denge kurabilmeyi tercih edersiniz. Ölü ve cevapsız yoklamaları bildirmek için yapılandırılabilir oylar, bu iki durumu yönetme esnekliği sağlar. Daha fazla bilgi için bkz . Yale Üniversitesi: Bilgisayar Bilimi Hata Algılayıcıları.

4. Ölçek:

   Protokol binlerce, hatta muhtemelen on binlerce sunucuyu işleyebilir. Bu, onlarca düğümün ötesine ölçeklendirilmediği bilinen grup iletişim protokolleri gibi geleneksel Paxos tabanlı çözümlerle karşıttır.

5. Tanılama:

   Tablo tanılama ve sorun giderme için de çok uygundur. Sistem yöneticileri, tablodaki geçerli canlı siloların listesini 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ı IMembershipTableiçin neden güvenilir kalıcı depolama gereklidir?

   Kalıcı depolama, iki amaç için IMembershipTable kullanılır. İlk olarak, siloların birbirini bulması ve istemcilerin siloları bulması için Orleans bir buluşma noktası görevi görür. İkinci olarak, güvenilir depolama, üyelik görünümüne ilişkin anlaşmanın koordinasyonuna yardımcı olur. Hata algılama silolar arasında doğrudan eşten eşe gerçekleşirken, üyelik görünümü bilgisi güvenilir bir depolama biriminde saklanır ve bu birimin sağladığı eşzamanlılık kontrol mekanizması, kimlerin hayatta olduğu ve kimlerin olmadığı konusunda bir anlaşmaya varmak için kullanılır. Bir anlamda, bu protokol zorlu dağıtılmış konsensüs problemini buluta devreder. Bunu yaparken, temel alınan bulut platformunun tüm gücü, gerçekten Hizmet Olarak Platform (PaaS) olarak kullanılarak kullanılır.

7. Yalnızca tanılama için tabloya doğrudan IAmAlive yazma işlemleri:

   Silolar arasında gönderilen sinyallere ek olarak, her silo tablo satırındaki bir "Hayattayım" sütununu da 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 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 öğrenmesi 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ılarından dolayı onaylar. 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, Konsolos tabanlı IMembershipTable uygulama Paul North tarafından yapıldı ve son olarak Apache Cassandra IMembershipTable uygulaması OrleansCassandraUtils tarafından uyarlandı.