Sdílet prostřednictvím

Správa clusteru v Orleans

  • Článek

Orleans poskytuje správu clusteru prostřednictvím integrovaného protokolu členství, který někdy označujeme jako členství Vilo. Cílem tohoto protokolu je, aby všechny sila (Orleans servery) souhlasily se sadou aktuálně živého sila, detekovala neúspěšná sila a umožnila novým sila připojit se ke clusteru.

Protokol spoléhá na externí službu, která poskytuje abstrakci IMembershipTable. IMembershipTable je plochá odolná tabulka typu No-SQL, kterou používáme pro dva účely. Za prvé, používá se jako rendezvous bod pro sila najít navzájem a Orleans klienty najít sila. Za druhé se používá k ukládání aktuálního zobrazení členství (seznam živých sila) a pomáhá koordinovat dohodu o zobrazení členství. V současné době máme 6 implementací : založených IMembershipTablena Azure Table Storage, SQL Serveru, Apache ZooKeeper, Consul IO, AWS DynamoDB a emulaci v paměti pro vývoj.

Kromě IMembershipTable každého sila se účastní plně distribuovaný protokol členství peer-to-peer, který detekuje neúspěšná sila a dosáhne dohody o sadě živých sila. Začneme tím, že popíšeme interní implementaci níže uvedeného Orleansprotokolu členství a později popíšeme implementaci IMembershipTableprotokolu .

Protokol základního členství

  1. Při spuštění každého sila přidá položku pro sebe do dobře známé sdílené tabulky pomocí implementace IMembershipTable. Kombinace identity sila (ip:port:epoch) a ID nasazení služby se v tabulce používá jako jedinečné klíče. Epocha je jen čas v klíštěcích, kdy se toto silo spustilo, a proto ip:port:epoch je zaručeno, že v daném Orleans nasazení bude jedinečný.

  2. Sila navzájem monitorují přímo prostřednictvím příkazů ping aplikací ("jste naživu" heartbeats). Příkazy Ping se odesílají jako přímé zprávy ze sil do silo přes stejné sokety TCP, které sila komunikují. Příkazy ping tak plně korelují se skutečnými problémy se sítí a stavem serveru. Každý silo ping nastaví konfigurovatelnou sadu dalších sil. Silo vybere, koho ping tím, že vypočítá konzistentní hodnoty hash na jiné identitě sila, vytvoří virtuální okruh všech identit a vybere sila X následníků v okruhu (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 nedostane Y ping odpovědi z monitorovaných serverů P, má podezření, že napíše své časové razítko podezření do P řádku v IMembershipTable.

  4. Pokud P má v řádu K více než Z podezření, pak S napíše, že P je mrtvý do řádku P, a vysílá žádost o všechna sila, aby znovu přečetla členskou tabulku (kterou stejně budou dělat pravidelně).

  5. Další podrobnosti:

    1. Podezření je zapsáno IMembershipTabledo , ve speciálním sloupci v řádku odpovídající P. Když S podezřívá P, napíše: "at time TTT S podezření P".

    2. Jedno podezření nestačí k deklaraci P jako mrtvého. K deklaraci P jako mrtvého potřebujete podezření z různých sil v konfigurovatelném časovém intervalu 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 se jedná o poslední podezřelého (v období od T, jak je napsané ve sloupci podezření), S se rozhodne deklarovat P jako 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 zpětný zápis používá číslo verze nebo značku ETag, která byla přečtena, takže aktualizace tohoto řádku jsou serializovány. V případě, že zápis selhal z důvodu neshody verze nebo značky ETag, S se pokusí znovu přečíst a pokusit se o zápis, pokud nebyl P již označený jako mrtvý).

    7. Na vysoké úrovni je tato posloupnost "čtení, místní úpravy, zpětný zápis" transakce. K tomu však nepoužíváme transakce úložiště. Kód "Transakce" se provádí místně na serveru a používáme optimistickou souběžnost, kterou IMembershipTable poskytuje k zajištění izolace a atomicity.

  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. Konfigurace: Poskytujeme výchozí konfiguraci, která byla ručně vyladěna během našeho produkčního využití v Azure. V současné době je výchozí hodnota: každé silo je monitorováno třemi dalšími sily, dva podezření jsou dost k deklaraci sila mrtvé, podezření pouze z posledních tří minut (jinak jsou zastaralé). Příkazy Ping se odesílají každých deset sekund a budete muset vynechat tři příkazy ping, abyste měli podezření na sila.

  8. Vynucení dokonalé detekce selhání – teoreticky je možné, že silo bude deklarováno mrtvé, pokud ztratí komunikaci s jinými silami, zatímco samotný proces sila je stále spuštěný. Pokud chcete tento problém vyřešit, jakmile je silo deklarováno mrtvý v tabulce, považuje se za mrtvé všemi, i když není mrtvý (pouze dělené dočasně nebo se ztratily zprávy prezenčních signálů). Všichni s ním přestanou komunikovat a jakmile se naučí, že je mrtvý (čtením nového stavu z tabulky), spáchá sebevraždu a ukončí svůj proces. V důsledku toho musí existovat infrastruktura, aby bylo možné restartovat silo jako nový proces (při spuštění se vygeneruje nové číslo epochy). Když je hostovaná v Azure, stane se to automaticky. Pokud není, vyžaduje se jiná infrastruktura. Například služba systému Windows nakonfigurovaná tak, aby se automaticky restartovala při selhání nebo nasazení Kubernetes.

  9. Optimalizace, která snižuje četnost pravidelných čtení tabulek a urychlí učení všech sil o nových spojování sila a mrtvých sila. Pokaždé, když jakýkoli silo napíše cokoli úspěšně do tabulky (podezření, nové spojení atd.), bude také vysílat do všech ostatních sil – "jít a znovu přečíst tabulku nyní". Silo neřekne ostatním, co v tabulce napsal (protože tyto informace už můžou být zastaralé nebo nesprávné), jen jim řekne, aby tabulku znovu přečetli. Díky tomu se velmi rychle dozvíme o změnách členství bez nutnosti čekat na celý periodický cyklus čtení. Stále potřebujeme pravidelné čtení, pokud se zpráva "znovu přečte tabulku" ztratí.

Vlastnosti základního protokolu členství

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

    Náš algoritmus dokáže zpracovat libovolný počet selhání (tj. f<=n), včetně úplného restartování clusteru. To je na rozdíl od "tradičních" řešení založených na Paxos , která vyžadují kvorum, což je obvykle většina. Viděli jsme v produkčních situacích, kdy byla více než polovina sila dole. Náš systém zůstal funkční, zatímco členství založené na Paxosu by nebylo schopno postupovat.

  2. Provoz do tabulky je velmi světlý:

    Skutečné příkazy ping se přecházejí přímo mezi servery a ne do tabulky. To by vygenerovalo velké množství provozu plus by bylo méně přesné z hlediska detekce selhání - pokud silo nemohlo dosáhnout tabulky, chybělo by napsat jeho jsem živý prezenční signál a ostatní by ho zabili.

  3. Nastavitelná přesnost versus úplnost:

    I když nemůžete dosáhnout dokonalé i přesné detekce selhání, jeden obvykle chce mít možnost kompromisu přesnosti (nechcete deklarovat silo, které je živé jako mrtvé) s úplností (chcete deklarovat mrtvý silo, který je skutečně mrtvý co nejdříve). Konfigurovatelné hlasy, které deklarují mrtvé a zmeškané ping umožňují obchodování těchto dvou. Další informace naleznete v tématu Yale University: Computer Science Failure Detectors.

  4. Scale (Měřítko):

    Základní protokol dokáže zpracovat tisíce a pravděpodobně i desítky tisíc serverů. To je na rozdíl od tradičních řešení založených na Paxosu, jako jsou komunikační protokoly skupiny, které se ví, že se nemají škálovat nad desítky.

  5. Diagnostika:

    Tabulka je také velmi pohodlná pro diagnostiku a řešení potíží. Správci systému mohou okamžitě najít v tabulce aktuální seznam živého sila, stejně jako 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č potřebujeme spolehlivé trvalé úložiště pro implementaci IMembershipTable:

    Pro dva účely používáme trvalé úložiště (azure table, SQL Server, AWS DynamoDB, Apache ZooKeeper nebo Consul IO KV).IMembershipTable Za prvé, používá se jako rendezvous bod pro sila najít navzájem a Orleans klienty najít sila. Zadruhé používáme spolehlivé úložiště, abychom mohli koordinovat dohodu o zobrazení členství. I když provádíme detekci selhání přímo mezi silami, ukládáme zobrazení členství ve spolehlivém úložišti a používáme mechanismus řízení souběžnosti, který toto úložiště poskytuje, abychom dosáhli dohody o tom, kdo je živý a kdo je mrtvý. Tímto způsobem náš protokol vysoudí pevný problém distribuovaného konsensu s cloudem. V tom, že plně využíváme sílu základní cloudové platformy a skutečně ji používáme jako platformu jako službu (PaaS).

  7. Co se stane, když není tabulka po určitou dobu přístupná:

    Pokud je služba úložiště mimo provoz, není k dispozici nebo je s ní problémy s komunikací, Orleans protokol nehlásí sila jako mrtvá omylem. Provozní sila budou fungovat bez jakýchkoli problémů. Orleans Nebude ale moct deklarovat silo mrtvé (pokud zjistí, že je nějaký silo mrtvý přes zmeškané příkazy ping, nebude moct napsat tento fakt do tabulky) a nebude také moct povolit připojení nových sila. Takže úplnost bude trpět, ale přesnost ne – dělení z tabulky nikdy nezpůsobí Orleans deklaraci sila jako mrtvé omylem. Také v případě částečného síťového oddílu (pokud některé sila mají přístup k tabulce a některé ne), může se stát, že Orleans deklaruje mrtvé silo jako mrtvé, ale bude to nějakou dobu trvat, než se o tom všechny ostatní sila dozví. Detekce by tedy mohla být zpožděná, ale Orleans kvůli nedostupnosti tabulky nikdy nespravuje silo.

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

    Kromě prezenčních signálů, které se odesílají mezi silami, každý silo také pravidelně aktualizuje sloupec "I Am Alive" v jeho řádku v tabulce. Tento sloupec "I Am Alive" se používá pouze pro ruční řešení potíží a diagnostiku a nepoužívá se samotným protokolem členství. Obvykle se píše s mnohem nižší frekvencí (jednou za 5 minut) a slouží jako velmi užitečný nástroj pro správce systému ke kontrole živého clusteru nebo snadné zjištění, kdy silo bylo naživu.

Rozšíření pro seřazení zobrazení členství

Protokol základního členství popsaný výše byl později rozšířen tak, aby podporoval seřazená zobrazení členství. Stručně popíšeme důvody tohoto rozšíření a způsob jeho implementace. Rozšíření nemění nic ve výše uvedeném návrhu, pouze přidává vlastnost, že všechny konfigurace členství jsou globálně seřazené.

Proč je užitečné uspořádat zobrazení členství?

  • To umožňuje serializaci spojení nových sil ke clusteru. Když se tedy nový silo připojí ke clusteru, může ověřit obousměrné připojení ke každému druhému silu, který už začal. Pokud některá z nich již připojená sila neodpoví (potenciálně značí problém s připojením k síti s novým silem), nový silo se nesmí připojit. Tím se zajistí, že alespoň při spuštění sila dojde k úplnému připojení mezi všemi silami v clusteru (to se implementuje).

  • Protokoly vyšší úrovně v silu, jako je distribuovaný adresář agregace, můžou využívat skutečnost, že zobrazení členství jsou seřazená, a pomocí těchto informací provádět inteligentnější řešení duplicitních aktivací. Konkrétně když adresář zjistí, že při vytváření členství v fluxu došlo k vytvoření 2 aktivací, může se rozhodnout deaktivovat starší aktivaci vytvořenou na základě aktuálně zastaralých informací o členství.

Protokol rozšířeného členství:

  1. Pro implementaci této funkce používáme podporu pro transakce přes více řádků, které poskytuje MembershipTable.

  2. Do tabulky, která sleduje změny tabulky, přidáme řádek verze členství.

  3. Když silo S chce napsat podezření nebo prohlášení o smrti pro sila P:

    1. S čte nejnovější obsah tabulky. Pokud už je P mrtvý, nic nedělejte. Jinak
    2. Ve stejné transakci zapište změny na řádek P a také zvýšit číslo verze a zapsat ho zpět do tabulky.
    3. Oba zápisy jsou podmíněny značkami ETag.
    4. Pokud transakce přeruší kvůli neshodě značky ETag na řádku P nebo řádku verze, zkuste to znovu.

  4. Všechny zápisy do tabulky upraví a zvýší řádek verze. Tímto způsobem se všechny zápisy do tabulky serializují (prostřednictvím serializace aktualizací řádku verze) a vzhledem k tomu, že sila pouze zvýší číslo verze, zápisy jsou také zcela seřazeny v rostoucím pořadí.

Škálovatelnost rozšířeného protokolu členství:

V rozšířené verzi protokolu jsou všechny zápisy serializovány přes jeden řádek. To může potenciálně poškodit škálovatelnost protokolu pro správu clusteru, protože zvyšuje riziko konfliktů mezi souběžnými zápisy tabulek. Pokud chcete tento problém částečně zmírnit, zkuste všechny své zápisy do tabulky zopakovat pomocí exponenciálního zpochybnění. Zjistili jsme, že rozšířené protokoly fungují hladce v produkčním prostředí v Azure s až 200 silami. Myslíme si ale, že protokol může mít problémy s škálováním nad rámec tisíc sil. V takových rozsáhlých nastaveních se aktualizace řádku verzí můžou snadno zakázat, v podstatě udržovat zbytek protokolu pro správu clusteru a vzdát se celkové vlastnosti řazení. Upozorňujeme také, že zde odkazujeme na škálovatelnost protokolu pro správu clusteru, nikoli na zbytek Orleansprotokolu . Věříme, že další části modulu runtime (zasílání zpráv, distribuovaný Orleans adresář, hostování zrnitosti, připojení klienta k bráně) jsou škálovatelné mimo stovky sil.

Tabulka členství

Jak už bylo zmíněno, IMembershipTable používá se jako redezvous bod pro sila najít navzájem a Orleans klienty najít sila a také pomáhá koordinovat dohodu o zobrazení členství. V současné době máme šest implementací : založených IMembershipTablena Azure Table, SQL Serveru, Apache ZooKeeper, Consul IO, AWS DynamoDB a emulaci v paměti pro vývoj.

  1. Azure Table Storage – v této implementaci používáme ID nasazení Azure jako klíč oddílu a identitu sila (ip:port:epoch) jako klíč řádku. Společně zaručují jedinečný klíč na silo. Pro řízení souběžnosti používáme optimistické řízení souběžnosti založené na značkách tabulky Azure. Pokaždé, když čteme z tabulky, uložíme značku ETag pro každý řádek pro čtení a použijeme tuto značku ETag při pokusu o zápis zpět. Značky ETag se automaticky přiřazují a kontrolují službou Azure Table Service při každém zápisu. U transakcí s více řádky využíváme podporu 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 se nakonfigurované ID nasazení používá k rozlišení mezi nasazeními a silami, do kterých nasazení patří. Identita sil 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 postup použití ETags v implementaci tabulky Azure. Relační implementace očekává, že databázový stroj vygeneruje použitou značku ETag. V případě SQL Serveru, na SQL Server 2000 vygenerovaná ETag je jeden získaný z volání NEWID(). Používá se SQL Server 2005 a novější 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í statistických dat. Přesná implementace a odůvodnění SQL Serveru najdete na webu CreateOrleansTables_SqlServer.sql.

  3. Apache ZooKeeper – v této implementaci používáme nakonfigurované ID nasazení jako kořenový uzel a identitu sila (ip:port@epoch) jako podřízený uzel. Společně zaručují jedinečnou cestu na silo. Pro řízení souběžnosti používáme optimistické řízení souběžnosti na základě verze uzlu. Pokaždé, když načteme z kořenového uzlu nasazení, uložíme verzi pro každý uzel silo pro čtení a tuto verzi použijeme při pokusu o zápis zpět. Pokaždé, když se data uzlu změní, se číslo verze atomicky zvýší službou ZooKeeper. U transakcí s více řádky používáme víceřádkové transakce, které zaručuje serializovatelné transakce nad uzly silo se stejným nadřazeným ID nasazení uzel.

  4. Consul V/V – k implementaci tabulky členství jsme použili úložiště klíč/hodnota consul. Další podrobnosti najdete v části Consul-Deployment .

  5. AWS DynamoDB – V této implementaci používáme ID nasazení clusteru jako klíč oddílu a identitu Silo (ip-port-generation) jako RangeKey, který vytváří jednotu záznamu. Optimistická souběžnost se provádí atributem ETag tak, že v DynamoDB vytvoří podmíněné zápisy. Logika implementace je poměrně podobná službě Azure Table Storage.

  6. Emulace v paměti pro nastavení vývoje Pro tuto implementaci používáme speciální systémovou zrnitost, která se nazývá MembershipTableGrain. Toto zrno se nachází na určeném primárním silu, který se používá pouze pro nastavení vývoje. V jakémkoli skutečném využití primárního sila produkčního prostředí se nevyžaduje.

Konfigurace

Protokol členství je nakonfigurován prostřednictvím Liveness elementu v oddílu Globals v Orleanssouboru Configuration.xml . Výchozí hodnoty byly vyladěny v letech produkčního využití v Azure a věříme, že představují dobrá výchozí nastavení. Není třeba je obecně měnit.

Ukázkový konfigurační element:

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

Implementují se 4 typy živé aktivity. Typ protokolu liveness je nakonfigurován prostřednictvím atributu SystemStore prvku v oddílu Globals v Orleanssouboru Configuration.xml.SystemStoreType

  1. MembershipTableGrain: Tabulka členství je uložena v agregačním intervalu na primárním silu. Toto je pouze nastavení vývoje.
  2. AzureTable: Tabulka členství je uložená v tabulce Azure.
  3. SqlServer: Tabulka členství je uložena v relační databázi.
  4. ZooKeeper: Členská tabulka je uložena v souboru ZooKeeper.
  5. Consul: nakonfigurováno jako vlastní systémové úložiště s MembershipTableAssembly = "OrleansConsulUtils". Další podrobnosti najdete v části Consul-Deployment .
  6. DynamoDB: nakonfigurováno jako vlastní systémové úložiště s MembershipTableAssembly = "OrleansAWSUtils".

Pro všechny typy živých hodnot jsou společné konfigurační proměnné definovány v Globals.Liveness elementu:

  1. ProbeTimeout: Počet sekund pro sondu jiných sila pro jejich liveness nebo pro silo odeslat "Jsem naživu" prezenční signál zprávy o sobě. Výchozí hodnota je 10 sekund.
  2. TableRefreshTimeout: Počet sekund pro načtení aktualizací z tabulky členství. Výchozí hodnota je 60 sekund.
  3. DeathVoteExpirationTimeout: Doba vypršení platnosti v sekundách pro hlasování o smrti v tabulce členství. Výchozí hodnota je 120 sekund.
  4. NumMissedProbesLimit: Počet zmeškaných zpráv prezenčních signálů ze sil nebo počtu neodpovídajících sond, které vedou k podezření, že je toto silo mrtvé. Výchozí hodnota je 3.
  5. NumProbedSilos: Počet silových sond pro živost. Výchozí hodnota je 3.
  6. NumVotesForDeathDeclaration: Počet hlasů, jejichž platnost nevypršela, které jsou potřeba k deklaraci určitého silo jako mrtvého (by mělo být maximálně NumMissedProbesLimit). Výchozí hodnota je 2.
  7. UseLivenessGossip: Zda použít optimalizaci gossip k urychlení šíření informací o živém životě. Výchozí hodnota je true.
  8. IAmAliveTablePublishTimeout: Počet sekund, které se mají pravidelně zapisovat do tabulky členství, že je toto silo naživu. Používá se pouze pro diagnostiku. Výchozí hodnota je 5 minut.
  9. NumMissedTableIAmAliveLimit: Počet zmeškanýchaktualizacích Nemá vliv na protokol liveness. Výchozí hodnota je 2.
  10. MaxJoinAttemptTime: Počet sekund pokusu o připojení clusteru sila před předáním. Výchozí hodnota je 5 minut.
  11. ExpectedClusterSize: Očekávaná velikost clusteru. Nemusí být příliš přesné, může to být nadlimitní. Používá se k ladění exponenciálního algoritmu opakování opakování pro zápis do tabulky Azure. Výchozí hodnota je 20.

Principy návrhu

Přirozeným dotazem, který by mohl být kladen, je, proč nespoléhejte na Apache ZooKeeper na implementaci členství v clusteru, a to potenciálně pomocí jeho předpřirozené podpory pro členství ve skupinách s dočasnými uzly? Proč jsme obtěžovali implementaci našeho protokolu členství? Existují především tři důvody:

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

    Zookeeper není hostovaná služba (alespoň v době psaní tohoto článku červenec 2015 a rozhodně, když jsme tento protokol poprvé implementovali v létě 2011, nebyla žádná verze Zookeeper spuštěna jako hostovaná služba žádným hlavním poskytovatelem cloudu). To znamená, že zákazníci v cloudovém prostředí Orleans by museli nasazovat, spouštět a spravovat svou instanci clusteru ZK. To je jen další zbytečná zátěž, kterou jsme nechtěli vynutit na naše zákazníky. Pomocí tabulky Azure spoléháme na hostované spravované služby, díky čemuž je život zákazníka mnohem jednodušší. V podstatě v cloudu používejte Cloud jako platformu, ne jako infrastrukturu. Na druhé straně při spouštění místních a správě serverů se spoléhá na ZK jako na implementaci IMembershipTable této možnosti.

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

    Při použití členství ve skupině ZK s dočasnými uzly se detekce selhání provádí mezi Orleans servery (klienty ZK) a servery ZK. Nemusí to nutně souviset se skutečnými problémy se sítí mezi Orleans servery. Naším přáním bylo, aby detekce selhání přesně odrážela stav komunikace uvnitř clusteru. Konkrétně v našem návrhu, pokud Orleans silo nemůže komunikovat s IMembershipTable ním není považováno za mrtvé a může pokračovat v práci. Na rozdíl od toho jsme použili členství ve skupině ZK s dočasnými uzly, které odpojí od serveru ZK, může způsobit Orleans , že je neaktivní silo (klient ZK), zatímco může být aktivní a plně funkční.

  3. Přenositelnost a flexibilita:

    V rámci Orleansfilozofie nechceme vynucovat silnou závislost na žádné konkrétní technologii, ale spíše mít flexibilní návrh, kde lze různé komponenty snadno přepínat s různými implementacemi. Toto je přesně účel, který IMembershipTable abstrakce slouží.

Poděkování

Uznáváme příspěvek Alexe Kogana 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. Implementaci ZooKeeper založené IMembershipTable na Shay Hazor, implementace SQL IMembershipTable byla provedena Veikko Eeva, implementace AWS DynamoDB IMembershipTable byla provedena Gutemberg Ribeiro a implementace consul založené IMembershipTable na Paul North.