Správa clusteru v Orleans

Orleans poskytuje správu clusteru prostřednictvím integrovaného protokolu členství, který se někdy označuje jako členství v clusteru. Cílem tohoto protokolu je, aby všechna sila (Orleans servery) souhlasila se sadou aktuálně živých sil, detekovala selhání sil a umožnila novým silům připojit se ke klastru.

Konfigurace protokolu členství

Protokol členství používá následující výchozí konfiguraci:

• Každé silo je monitorováno 10 dalšími sily.
• K prohlášení sila za mrtvé jsou vyžadována 2 podezření
• Podezření jsou platná po dobu 3 minut
• Sondy se odesílají každých 10 sekund.
• 3 zmeškané sondy vyvolávají podezření

U těchto výchozích hodnot je typická doba detekce selhání přibližně 15 sekund. Ve scénářích zotavení po havárii, ve kterých dojde k chybovému ukončení sila bez správného vyčištění, cluster používá IAmAlive časové razítko (ve výchozím nastavení se aktualizuje každých 30 sekund) k obnově. Sila, která neaktualizovala časové razítko po několik intervalů, se ignorují během kontrol připojení při spouštění. Když tyto nereagující sila přeskočíte, můžou se nová sila spustit a rychle vymazat shluk neaktivních sila tím, že je deklaruje jako mrtvou.

Konfigurace

Nastavení protokolu členství můžete nakonfigurovat pomocí ClusterMembershipOptions:

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;
});

Kdy upravit nastavení

Ve většině případů jsou výchozí nastavení vhodná. V těchto scénářích ale můžete zvážit úpravy:

• Sítě s vysokou latencí: Zvyšte ProbeTimeout, pokud jsou vaše sila distribuována napříč oblastmi s vysokou latencí.
• Kritické požadavky na dostupnost: Snižte DeathVoteExpirationTimeout rychlost detekce selhání, ale buďte opatrní vůči falešně pozitivním výsledkům.

Konfigurace protokolu členství

Protokol členství používá následující výchozí konfiguraci:

• Každé silo je monitorováno 3 dalšími silami.
• K prohlášení sila za mrtvé jsou vyžadována 2 podezření
• Podezření jsou platná po dobu 3 minut
• Sondy se odesílají každých 10 sekund.
• 3 zmeškané sondy vyvolávají podezření

Konfigurace protokolu členství

Protokol členství používá následující výchozí konfiguraci:

• Každé silo je monitorováno 3 dalšími silami.
• K prohlášení sila za mrtvé jsou vyžadována 2 podezření
• Podezření jsou platná po dobu 3 minut

Protokol spoléhá na externí službu, která poskytuje abstrakci IMembershipTable. IMembershipTable je plochá, odolná tabulka používaná pro dva účely. Za prvé slouží jako setkávací bod pro sila, aby se našla navzájem, a pro Orleans klienty, aby našli sila. Za druhé, ukládá aktuální pohled na členství (seznam živých sil) a pomáhá koordinovat dosažení dohody o tomto zobrazení.

V současné době jsou k dispozici následující oficiální implementace IMembershipTable :

• ADO.NET (PostgreSQL, MySQL/MariaDB, SQL Server, Oracle),
• AWS DynamoDB,
• Apache Cassandra,
• Apache ZooKeeper,
• Azure Cosmos DB,
• Azure Table Storage,
• HashiCorp Consul,
• Redis,
• a implementaci v paměti pro vývoj.

Konfigurace klastru Redis

Nakonfigurujte Redis jako zprostředkovatele clusteringu UseRedisClustering pomocí metody rozšíření:

using StackExchange.Redis;

var builder = Host.CreateApplicationBuilder(args);

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

Případně můžete použít připojovací řetězec:

siloBuilder.UseRedisClustering("localhost:6379");

Třída RedisClusteringOptions poskytuje následující možnosti konfigurace:

Vlastnictví	Typ	Description
ConfigurationOptions	ConfigurationOptions	Konfigurace klienta StackExchange.Redis. Povinné.
EntryExpiry	TimeSpan?	Nepovinný čas vypršení platnosti položek Nastavte ho jenom pro dočasné prostředí, jako je testování. Výchozí hodnota je null.
CreateMultiplexer	Func<RedisClusteringOptions, Task<IConnectionMultiplexer>>	Vlastní továrna pro vytvoření multiplexeru připojení Redis
CreateRedisKey	Func<ClusterOptions, RedisKey>	Vlastní funkce pro vygenerování klíče Redis pro tabulku členství Výchozí formát je {ServiceId}/members/{ClusterId}.

Důležité

IMembershipTable Implementace rozhraní musí používat trvalé úložiště dat. Pokud například používáte Redis, ujistěte se, že je explicitně povolena perzistence. Nestálé konfigurace můžou vést k nedostupnosti clusteru.

Integrace .NET Aspire pro seskupení

Při použití .NET Aspire můžete nakonfigurovat Orleans clustering deklarativním způsobem v projektu AppHost. Aspire automaticky vloží potřebnou konfiguraci do silo projektů pomocí proměnných prostředí.

Clustering s využitím Redis Aspire

Projekt AppHost (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();

Projekt Silo (Program.cs):

var builder = Host.CreateApplicationBuilder(args);

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

builder.Build().Run();

Shlukování Azure Table Storage s Aspire

Projekt AppHost (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();

Projekt Silo (Program.cs):

var builder = Host.CreateApplicationBuilder(args);

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

builder.Build().Run();

Návod

Pokud chcete pro místní vývoj použít emulátor Azurite, zavolejte .RunAsEmulator() prostředek služby Azure Storage. Bez tohoto volání Aspire očekává skutečné připojení Azure Storage.

Azure Cosmos DB clusteringu s Aspire

Projekt AppHost (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();

Projekt Silo (Program.cs):

var builder = Host.CreateApplicationBuilder(args);

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

builder.Build().Run();

Poznámka:

AspireIntegrace Cosmos DB pro Orleans aktuálně podporuje pouze klastrování. Pro ukládání zrn a připomenutí ve službě Cosmos DB budete muset tyto poskytovatele nakonfigurovat ručně v projektu silo.

Důležité

K registraci záložního prostředku v kontejneru injektáže závislostí musíte volat příslušnou AddKeyed* metodu (například AddKeyedRedisClient, AddKeyedAzureTableServiceClientnebo AddKeyedAzureCosmosClient). Orleans poskytovatelé vyhledávají prostředky podle přiřazeného názvu služby – pokud tento krok přeskočíte, Orleans nebude schopen prostředek vyřešit a za běhu vyvolá chybu řešení závislostí.

Další informace o integraci Orleans a .NET Aspire najdete v tématu Orleans a .NET Aspire integrace.

Konfigurace clusteringu Cassandra

Nakonfigurujte Apache Cassandra jako zprostředkovatele clusteringu UseCassandraClustering pomocí metody rozšíření. Nainstalujte balíček Microsoft.Orleans.Clustering.Cassandra NuGet.

dotnet add package Microsoft.Orleans.Clustering.Cassandra

Konfigurace clusteringu Cassandra s připojovacím řetězcem:

using Orleans.Clustering.Cassandra.Hosting;

var builder = Host.CreateApplicationBuilder(args);

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

Případně můžete použít konfiguraci založenou na možnostech pro větší kontrolu:

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

Nebo můžete poskytnout vlastní objekt pro vytváření relací pro pokročilé scénáře:

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");
});

Třída CassandraClusteringOptions poskytuje následující možnosti konfigurace:

Vlastnictví	Typ	Výchozí	Description
UseCassandraTtl	bool	false	Když true nakonfiguruje time-to-live pro řádky tabulky členství v Cassandře, umožní to vyčištění neaktivního sila, i když cluster už není spuštěný. Používá DefunctSiloExpiration z ClusterMembershipOptions.
InitializeRetryMaxDelay	TimeSpan	20 sekund	Maximální prodleva mezi opakovanými pokusy při výskytu kolizí během inicializace Obvykle se to vyžaduje s velkým počtem sil, které se připojují současně ke clusterům Cassandra s více datovými centry.

Kdy použít clustering „Cassandra“

Zvažte použití Cassandry pro seskupování, když:

• Ve vaší organizaci už máte infrastrukturu Cassandra.
• Potřebujete poskytovatele clusteringu, který funguje v několika datových centrech s nastavitelnou konzistencí.
• Vyžadujete, aby neaktivní sila byla automaticky vyčištěna prostřednictvím TTL v Cassandra, i když není cluster Orleans spuštěný.
• Pro velké clustery potřebujete vysokou propustnost zápisu.

Konfigurace clusterování Azure Cosmos DB

Nakonfigurujte službu Azure Cosmos DB jako zprostředkovatele clusteringu UseCosmosClustering pomocí metody rozšíření. Nainstalujte Microsoft.OrleansClustering.Cosmos NuGet balíček:

dotnet add package Microsoft.Orleans.Clustering.Cosmos

Konfigurace clusteringu Cosmos DB s připojovacím řetězcem:

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;
    });
});

Případně můžete použít připojovací řetězec:

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

Třída CosmosClusteringOptions dědí z CosmosOptions a poskytuje následující možnosti konfigurace:

Vlastnictví	Typ	Výchozí	Description
DatabaseName	string	"Orleans"	Název databáze Cosmos DB.
ContainerName	string	"OrleansCluster"	Název kontejneru pro data členství v clusteru.
IsResourceCreationEnabled	bool	false	Pokud true, systém automaticky vytvoří databázi a kontejner, pokud neexistují.
DatabaseThroughput	int?	null	Poskytnutá propustnost pro databázi. Pokud nullpoužíváte bezserverový režim.
ContainerThroughputProperties	ThroughputProperties?	null	Vlastnosti propustnosti kontejneru.
ClientOptions	CosmosClientOptions	new()	Možnosti předané klientovi Cosmos DB.
CleanResourcesOnInitialization	bool	false	Odstraní databázi při inicializaci. Pouze pro testování.

Kdy použít clustering Cosmos DB

Zvažte službu Azure Cosmos DB pro clustering v případech, kdy:

• Azure Cosmos DB už ve své aplikaci používáte.
• Potřebujete globálně distribuovanou databázi s možnostmi zápisu do více oblastí.
• Chcete plně spravovanou bezserverovou možnost s automatickým škálováním.
• Potřebujete nízkou latenci čtení a zápisů s garantovanými úrovněmi SLA.

Pro Orleans klienty použijte UseCosmosGatewayListProvider ke konfiguraci zjišťování brány:

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

Kromě IMembershipTable se každé silo účastní plně distribuovaného peer-to-peer protokolu členství, který detekuje selhaná sila a dosahuje dohody o sadě funkčních sil. Interní implementace Orleansprotokolu členství je popsaná níže.

Protokol členství

1. Při spuštění přidá každý silo položku pro sebe do dobře známé sdílené tabulky pomocí implementace IMembershipTable. Orleans používá kombinaci identity silo (ip:port:epoch) a ID nasazení služby (ID clusteru) jako jedinečné klíče v tabulce. Epocha je jednoduše čas v tikách, kdy bylo toto silo spuštěno, což zajišťuje jedinečnost ip:port:epoch v rámci daného nasazení Orleans.

2. Sily navzájem monitorují přímo prostřednictvím aplikací kontrol ("jste naživu" heartbeats). Sondy se odesílají jako přímé zprávy z jednoho sila do druhého přes stejné sokety TCP, které jsou používány pro pravidelnou komunikaci. Tímto způsobem sondy plně korelují se skutečnými problémy se sítí a stavem serveru. Každé silo prozkoumává konfigurovatelnou sadu dalších sil. Silo vybere, koho zkoumat, výpočtem konzistentních hodnot hash na identitách jiných sil, vytvoří virtuální okruh všech identit a vybere v okruhu X následujících sil. (Jedná se o dobře známou distribuovanou techniku označovanou jako konzistentní hashování a je široce používána v mnoha distribuovaných tabulkách hash, jako je Chord DHT).

3. Pokud silo S neobdrží odpovědi sondy Y z monitorovaného serveru P, pojme podezření o serveru P tím, že zapíše své časové razítko podezření do řádku P v IMembershipTable.

4. Pokud má P více než Z podezření během K sekund, S zapíše do řádku P, že P je mrtvý, a odešle snímek aktuální tabulky členství do všech ostatních sil. Servery pravidelně aktualizují tabulku, takže snímek slouží jako optimalizace zkracující dobu potřebnou k tomu, aby se všechny servery dozvěděly o novém zobrazení členství.

5. Další podrobnosti:

   1. Podezření je zapsáno do IMembershipTable, ve speciálním sloupci v řádku odpovídajícím P. Když S podezřívá P, píše: "v čase TTT S podezíral P".

   2. Jedno podezření nestačí k deklaraci P mrtvého. Pro potřebnou deklaraci úmrtí P potřebujete mít Z podezření z různých sil v konfigurovatelném časovém rozmezí T (obvykle 3 minuty). Podezření je zapsáno pomocí optimistického řízení souběžnosti poskytovaného IMembershipTable.

   3. Podezřelý silo S přečte řádek P.

   4. Pokud S je poslední podezřelý (bylo již Z-1 podezřelých v období T, jak je zaznamenáno ve sloupci podezření), S se rozhodne prohlásit P za mrtvého. V tomto případě se S přidá do seznamu podezřelých a také píše ve sloupci Stav P, že P je mrtvý.

   5. V opačném případě, pokud S není posledním podezřelým, S se jenom přidá do sloupce podezřelého.

   6. V obou případech použije zápis zpět číslo verze nebo dříve přečtený ETag, aby serializoval aktualizace tohoto řádku. Pokud se zápis nezdaří kvůli neshodě verze nebo ETag, S se pokusí znovu přečíst a zapsat, pokud již P není označen jako mrtvý.

   7. Na vysoké úrovni je tato posloupnost "čtení, místní úpravy, zpětný zápis" transakce. Transakce úložiště se ale nemusí nutně používat. Kód "transaction" se spouští místně na serveru a optimistická souběžnost poskytovaná IMembershipTable zajišťuje izolaci a atomicitu.

6. Každý silo pravidelně čte celou tabulku členství pro své nasazení. Tímto způsobem se sila učí o nových silach, které se připojují, a o dalších silach, které jsou deklarovány mrtvé.

7. Vysílání snímku: Aby se snížila frekvence periodických čtení tabulek, pokaždé, když silo zapíše do tabulky (podezření, nové připojení atd.), odešle snímek aktuálního stavu tabulky všem ostatním silům. Vzhledem k tomu, že je tabulka členství konzistentní a monotonicky verzovaná, každá aktualizace vytvoří jedinečný verzovaný snímek, který lze bezpečně sdílet. To umožňuje okamžité šíření změn členství bez čekání na periodický cyklus čtení. Pravidelné čtení je stále zachováno jako záložní mechanismus v případě, že distribuce snímků selže.

8. Seřazená zobrazení členství: Protokol členství zajišťuje, že všechny konfigurace členství jsou globálně seřazené. Toto řazení poskytuje dvě klíčové výhody:

   1. zaručené připojení: Když se ke clusteru připojí nové silo, musí ověřit obousměrné připojení ke všem ostatním aktivním silům. Pokud některé existující silo nereaguje (což potenciálně naznačuje problém s připojením k síti), nový silo se nemůže připojit. Tím se zajistí úplné připojení mezi všemi silami v clusteru při spuštění. Viz poznámku o IAmAlive níže pro výjimku ve scénářích zotavení po havárii.

   2. Konzistentní aktualizace adresářů: Protokoly vyšší úrovně, jako je distribuovaný adresář zrní, spoléhají na to, že všechna sila mají konzistentní a monotónní pohled na členství. To umožňuje chytřejší řešení duplicitních aktivací zrnek. Další podrobnosti najdete v dokumentaci k adresáři Grain .

   podrobnosti implementace:

   1. IMembershipTable vyžaduje atomické aktualizace, aby se zajistilo globální celkové pořadí změn:

      • Implementace musí aktualizovat položky tabulky (seznam sila) i číslo verze atomicky.
      • Dosáhnete toho pomocí databázových transakcí (jako v SQL Serveru) nebo atomických operací compare-and-swap s etagy (jako v Azure Table Storage).
      • Konkrétní mechanismus závisí na možnostech základního systému úložiště.

   2. Zvláštní řádek verze členství v tabulce sleduje změny:

      • Každý zápis do tabulky (podezření, deklarace smrti, spojení) zvýší toto číslo verze.
      • Všechny zápisy jsou serializovány prostřednictvím tohoto řádku pomocí atomických aktualizací.
      • Monotonicky se zvyšující verze zajišťuje celkové řazení všech změn členství.

   3. Když silo S aktualizuje stav silo P:

      • S nejprve přečte nejnovější stav tabulky.
      • V jedné atomické operaci aktualizuje řádek P a zvýší číslo verze.
      • Pokud atomická aktualizace selže (například kvůli souběžným úpravám), operace se opakuje s exponenciálním zpožděním.

   aspekty škálovatelnosti:

   Serializování všech zápisů přes verzový řádek může mít vliv na škálovatelnost kvůli zvýšeným konfliktům. Protokol se osvědčil v praxi při použití až 200 sil, ale může čelit problémům při překročení tisíce sil. U velmi rozsáhlých nasazení zůstávají ostatní části Orleans (zasílání zpráv, složkový adresář, hostování) škálovatelné i v případě, že se aktualizace členství stanou úzkým hrdlem.

9. výchozí konfigurace: Výchozí konfigurace byla ručně vyladěna během produkčního využití v Azure. Ve výchozím nastavení: každé silo je monitorováno třemi dalšími sila, dvě podezření stačí k prohlášení sila za mrtvé a podezření se zohledňují pouze za poslední tři minuty (jinak jsou zastaralé). Sondy se odesílají každých deset sekund a musíte vynechat tři sondy, abyste mohli mít podezření na silo.

10. samoobslužné monitorování: Detektor chyb zahrnuje nápady z lifeguarda Hashicorp výzkumu (papírový, talk, blog) ke zlepšení stability clusteru během katastrofických událostí, kdy velká část clusteru dochází k částečnému selhání. Komponenta LocalSiloHealthMonitor hodnotí stav každého sila pomocí několika heuristik.

    • Aktivní stav v tabulce členství
    • Žádné podezření z jiných sil
    • Nedávné úspěšné odpovědi sondy
    • Přijaté nedávné požadavky sondy
    • Rychlost odezvy fondu vláken (pracovní položky spouštěné během 1 sekundy)
    • Přesnost časovače (spuštění do 3 sekund od rozvrhu)

    Skóre stavu silo má vliv na vypršení časového limitu sondy: sila není v pořádku (bodování 1–8) mají ve srovnání se zdravými silami vyšší časové limity (skóre 0). To poskytuje dvě výhody:

    • Poskytuje více času, aby sonda mohla uspět, když je síť nebo systém ve stresu.
    • Zvyšuje pravděpodobnost, že nezdravá sila budou odsouzena k zániku dříve, než mohou nesprávně hlasovat o odstranění zdravých sil.

    To je obzvláště užitečné ve scénářích, jako je vyhladovění poolu vláken, kdy pomalé uzly můžou jinak nesprávně podezřívat zdravé uzly, jednoduše proto, že nedokážou zpracovat odpovědi dostatečně rychle.

11. Nepřímá sonda: Další funkce inspirovaná Lifeguardem vylepšuje přesnost detekce selhání snížením pravděpodobnosti, že nezdravý nebo dělený uzel nesprávně deklaruje jako mrtvý uzel, který je ve skutečnosti v pořádku. Když má monitorovací silo dva pokusy o sondu zbývající pro cílové silo před odesláním hlasu, aby bylo deklarováno, že je mrtvé, využívá nepřímé sondování:

    • Silo monitorování náhodně vybere další silo jako prostředníka a požádá ho, aby prozkoumalo cíl.
    • Zprostředkovatel se pokusí kontaktovat cílové silo.
    • Pokud cíl během časového limitu neodpoví, zprostředkující odešle záporné potvrzení.
    • Pokud silo monitorování obdrží negativní potvrzení od zprostředkovatele a zprostředkovatel deklaruje, že je v pořádku (prostřednictvím samokontroly, jak je popsáno výše), silo monitorování hlasuje prohlásit cíl za mrtvý.
    • Při výchozí konfiguraci dvou požadovaných hlasů se záporná potvrzení z nepřímé sondy počítá jako oba hlasy, což umožňuje rychlejší deklaraci mrtvých sila, když několik perspektiv potvrdí selhání.

12. Vynucení dokonalé detekce selhání: Jakmile je silo deklarováno jako mrtvé v tabulce, všichni jej považují za mrtvé, i když není skutečně mrtvé (například pouze dočasně oddělené nebo pokud byly ztraceny heartbeatové zprávy). Všichni s ním přestanou komunikovat. Jakmile se silo naučí, že je mrtvé (čtením jeho nového stavu z tabulky), ukončí svůj proces. Proto musí být infrastruktura připravená k restartování sila jako nového procesu (při spuštění se vygeneruje nové číslo epochy). Když je hostovaný v Azure, stane se to automaticky. V opačném případě se vyžaduje jiná infrastruktura, například služba windows nakonfigurovaná tak, aby se automaticky restartovala při selhání nebo nasazení Kubernetes.

13. Co se stane, když je tabulka nějakou dobu nepřístupná:

    Pokud je služba úložiště mimo provoz, není k dispozici nebo dochází k problémům s komunikací, Orleans protokol silos omylem za mrtvé neprohlásí. Provozní sila nadále pracují bez problémů. Orleans Nebude ale moct deklarovat mrtvé silo (pokud přes zmeškané sondy detekuje mrtvé silo, nepůjde do tabulky napsat tento fakt) a nebude moct povolit připojení nových sila. Úplnost tedy trpí, ale přesnost ne – dělení z tabulky nikdy nezpůsobí, že by Orleans omylem deklarovalo silo jako mrtvé. Také v částečném síťovém segmentu (kde některé sila mají přístup k tabulce a jiná nemohou) může Orleans deklarovat silo mrtvým, ale trvá to nějaký čas, než se to ostatní sila dozvědí. Detekce může být zpožděná, ale Orleans kvůli nedostupnosti tabulky nikdy nesprávně nezabíjí silo.

14. IAmAlive píše pro diagnostiku a obnovu po havárii:

    Kromě signálů srdečního tepu odesílaných mezi sily každý silo pravidelně aktualizuje časové razítko "I Am Alive" ve svém řádku tabulky. Slouží k dvěma účelům:

    1. Diagnostika: Poskytuje správcům systému jednoduchý způsob, jak zkontrolovat dostupnost clusteru a zjistit, kdy bylo silo naposledy aktivní. Časové razítko se ve výchozím nastavení aktualizuje každých 30 sekund.

    2. Zotavení po havárii: Pokud silo neaktualizovalo časové razítko po dobu několika období (nakonfigurovaných prostřednictvím NumMissedTableIAmAliveLimit, výchozí: 3), nová sila ho při startu ignorují během kontrol připojení. Cluster se tak může zotavit ze scénářů, kdy došlo k pádu sil aniž by proběhlo správné vyčištění.

Tabulka členství

Jak už bylo zmíněno, IMembershipTable slouží jako rendezvous bod, aby si sila mohla navzájem najít a aby Orleans klienti mohli najít sila. Pomáhá také koordinovat dohodu o pohledu na členství.

Následující seznam obsahuje poznámky k implementaci některých oficiálních implementací:IMembershipTable

1. Azure Table Storage: V této implementaci slouží ID nasazení Azure jako klíč oddílu a identita sila (ip:port:epoch) funguje jako klíč řádku. Společně zaručují jedinečný klíč na silo. Pro řízení souběžnosti se používá optimistické řízení souběžnosti založené na ETags tabulky Azure. Při každém čtení dat z tabulky se ETag každého přečteného řádku uloží a použije při zpětném zápisu. Služba Azure Table Service automaticky přiřazuje a kontroluje značky ETag při každém zápisu. U transakcí s více řádky se využívá podpora dávkových transakcí poskytovaných tabulkou Azure, která zaručuje serializovatelné transakce přes řádky se stejným klíčem oddílu.

2. SQL Server: V této implementaci nakonfigurované ID nasazení rozlišuje mezi jednotlivými nasazeními a určuje, které sily k nim patří. Identita silo je definována jako kombinace deploymentID, ip, port, epoch v odpovídajících tabulkách a sloupcích. Relační back-end používá optimistické řízení souběžnosti a transakce, podobně jako použití značek ETag v implementaci tabulky Azure. Relační implementace očekává, že databázový stroj vygeneruje značku ETag. Pro SQL Server 2000 je vygenerovaný ETag získán z volání NEWID(). Na SQL Serveru 2005 a novějším se používá ROWVERSION . Orleans čte a zapisuje relační značky ETag jako neprůzné VARBINARY(16) značky a ukládá je do paměti jako řetězce kódované v base64 . Orleans podporuje vkládání s více řádky pomocí UNION ALL (pro Oracle, včetně DUAL), která se v současné době používá k vkládání dat statistiky. Přesná implementace a odůvodnění SQL Serveru je k dispozici na CreateOrleansTables_SqlServer.sql.

3. Apache ZooKeeper: V této implementaci se nakonfigurované ID nasazení používá jako kořenový uzel a identifikátor sila (ip:port@epoch) jako jeho podřízený uzel. Společně zaručují jedinečnou cestu pro každé silo. Pro řízení souběžnosti se používá optimistické řízení souběžnosti na základě verze uzlu . Pokaždé, když se data čtou z kořenového uzlu nasazení, uloží se verze každého podřízeného uzlu čtení a použije se při pokusu o zpětný zápis. Pokaždé, když se data uzlu změní, služba ZooKeeper atomicky zvýší číslo verze. U transakcí s více řádky se využívá vícenásobná metoda , která zaručuje serializovatelné transakce přes uzly silo se stejným uzlem ID nadřazeného nasazení.

4. HashiCorp Consul: Úložiště klíč/hodnota Consul bylo použito k implementaci tabulky členství. Další podrobnosti najdete v tématu Consul Deployment .

5. AWS DynamoDB: V této implementaci se ID nasazení clusteru používá jako klíč oddílu a identita sila (ip-port-generation) jako RangeKey a záznam je jedinečný. Optimistická souběžnost se dosahuje pomocí atributu ETag tak, že v DynamoDB vytváří podmíněné zápisy. Logika implementace je poměrně podobná službě Azure Table Storage.

6. Apache Cassandra: V této implementaci slouží složenina ID služby a ID clusteru jako klíč oddílu a identita sila (ip:port:epoch) jako klíč řádku. Společně zaručují jedinečný řádek pro každé silo. Pro řízení souběžnosti se používá optimistické řízení souběžnosti na základě verze statického sloupce pomocí zjednodušené transakce. Tento sloupec verze je sdílen pro všechny řádky v oddílu nebo clusteru a poskytuje konzistentně rostoucí číslo verze pro tabulku členů každého clusteru. V této implementaci nejsou žádné transakce s více řádky.

7. Emulace v paměti pro nastavení vývoje: Tato implementace používá speciální systémové zrno. Toto zrno se nachází na určeném primárním silu, který se používá pouze pro nastavení vývoje. Při jakémkoli skutečném produkčním použití není vyžadováno primární silo.

Principy návrhu

Přirozenou otázkou může být, proč se úplně nespoléhat na Apache ZooKeeper nebo etcd k implementaci členství v clusteru a potenciálně využít vestavěnou podporu ZooKeeperu pro členství ve skupinách s dočasnými uzly? Proč implementovat náš protokol členství? Existují především tři důvody:

1. Nasazení / hostování v cloudu:

   Zookeeper není hostovaná služba. To znamená, Orleans že v cloudovém prostředí by zákazníci museli nasazovat, spouštět a spravovat svou instanci clusteru ZK. To je zbytečná zátěž, která nebyla vynucena pro zákazníky. Pomocí tabulky Orleans Azure se spoléhá na hostované spravované služby, což zákazníkům výrazně zjednodušuje život. V podstatě v cloudu používejte cloud jako platformu, nikoli infrastrukturu. Na druhou stranu, při provozování místní infrastruktury a správě serverů je spoléhání na ZK jako na implementaci IMembershipTable životaschopnou možnost.

2. Přímá detekce selhání:

   Při použití členství ve skupině ZK s dočasnými uzly dochází k detekci selhání mezi Orleans servery (klienty ZK) a servery ZK. Nemusí to nutně souviset se skutečnými problémy se sítí mezi Orleans servery. Přání bylo, aby detekce selhání přesně odrážela stav komunikace uvnitř clusteru. Konkrétně v tomto návrhu, pokud silo Orleans nemůže komunikovat s IMembershipTable, není považováno za mrtvé a může pokračovat v práci. Naopak, pokud by bylo využito členství ve skupině ZK s dočasnými uzly, může odpojení od serveru ZK způsobit, že silo (klient ZK) je označeno jako neaktivní, zatímco může být stále aktivní a plně funkční.

3. Přenositelnost a flexibilita:

   V rámci filozofie Orleans neklade Orleans silnou závislost na žádnou konkrétní technologii, ale spíše poskytuje flexibilní návrh, kde se různé komponenty dají snadno vyměňovat za různé implementace. Toto je přesně účel, který IMembershipTable abstrakce slouží.

Vlastnosti protokolu členství

1. Dokáže zpracovat libovolný počet selhání:

   Tento algoritmus dokáže zpracovat libovolný počet selhání (f<=n), včetně úplného restartování clusteru. To kontrastuje s "tradičními" řešeními založenými na Paxosu, která vyžadují kvorum (obvykle většinou). Produkční situace ukázaly scénáře, ve kterých více než polovina sil nefungovala. Tento systém zůstal funkční, zatímco členství založené na Paxosu by nemohlo postupovat.

2. Provoz k tabulce je velmi slabý

   Skutečné sondy jdou přímo mezi servery, a ne do tabulky. Směrování sond přes tabulku by generovalo významný datový provoz a snížilo přesnost detekce selhání – pokud silo nemůže dosáhnout k tabulce, nemůže zapsat svůj prezenční signál "Jsem naživu" a ostatní systémy by ho označily jako nefunkční.

3. Nastavitelná přesnost versus úplnost:

   I když nemůžete dosáhnout jak dokonalé, tak přesné detekce selhání, obvykle chcete mít možnost vyvažovat přesnost (nechcete chybně označit živé silo jako mrtvé) s úplností (chcete označit mrtvé silo jako mrtvé co nejdříve). Konfigurovatelné hlasy pro deklaraci mrtvých a zmeškaných sond umožňují obchodování těchto dvou aspektů. Další informace naleznete v tématu Yale University: Computer Science Failure Detectors.

4. Měřítko:

   Protokol dokáže zpracovat tisíce serverů, pravděpodobně i desítky tisíc serverů. To kontrastuje s tradičními řešeními založenými na Paxosu, jako jsou skupinové komunikační protokoly, které se ví, že se nedají škálovat nad desítky uzlů.

5. Diagnostika:

   Tabulka je také velmi pohodlná pro diagnostiku a řešení potíží. Správci systému mohou okamžitě najít aktuální seznam živých sila v tabulce a také vidět historii všech zabitých sila a podezření. To je užitečné zejména při diagnostice problémů.

6. Proč je spolehlivé trvalé úložiště potřebné pro implementaci IMembershipTable:

   Trvalé úložiště se používá pro IMembershipTable dva účely. Za prvé slouží jako setkávací bod pro sila, aby se našla navzájem, a pro Orleans klienty, aby našli sila. Za druhé, spolehlivé úložiště pomáhá usnadnit dohodu o stavu členství. Zatímco k detekci selhání dochází přímo mezi silo, zobrazení členství je uloženo ve spolehlivém úložišti a mechanismus řízení souběžnosti poskytnutý tímto úložištěm se používá k dosažení shody o tom, kdo je aktivní a kdo není. V tomto smyslu tento protokol outsourcuje těžký problém distribuovaného konsensu do cloudu. Při tom se využívá plný výkon základní cloudové platformy a používá se skutečně jako platforma jako služba (PaaS).

7. Přímé IAmAlive zápisy do tabulky pouze pro diagnostiku:

   Kromě srdečních tepů odeslaných mezi silami také každý silo pravidelně aktualizuje sloupec „I Am Alive“ ve svém řádku tabulky. Tento "I Am Alive" sloupec se používá pouze pro ruční řešení potíží a diagnostiku, a nikoliv samotným protokolem členství. Obvykle se zaznamenává s mnohem nižší frekvencí (jednou za 5 minut) a slouží jako velmi užitečný nástroj pro správce systému ke kontrole funkčnosti clusteru nebo ke snadnému zjištění, kdy bylo silo naposledy naživu.

Poděkování

Potvrzení o příspěvku Alex Kogan k návrhu a implementaci první verze tohoto protokolu. Tato práce byla provedena jako součást letního stáže v Microsoft Research v létě roku 2011. Implementace založená na ZooKeeper IMembershipTable byla provedena Shay Hazorem, implementace SQL IMembershipTable byla provedena Veikko Eevou, implementace AWS DynamoDB IMembershipTable byla provedena Gutemberg Ribeirem, implementace založená na Consul IMembershipTable byla provedena Paulem Northem, a nakonec byla implementace Apache Cassandra IMembershipTable přizpůsobena z OrleansCassandraUtilsArshiou001.