Megosztás a következőn keresztül:

Fürtkezelés a következő helyen: Orleans

  • Cikk

Orleansa fürtkezelést egy beépített tagsági protokollon keresztül biztosítja, amelyet néha silótagságnak nevezünk. A protokoll célja, hogy minden siló (Orleans kiszolgáló) megállapodjon a jelenleg élő silók készletéről, észlelje a sikertelen silókat, és engedélyezze az új silók csatlakozását a fürthöz.

A protokoll egy külső szolgáltatásra támaszkodik, amely absztrakciót biztosít a IMembershipTable. IMembershipTable egy sima, nem SQL-szerű tartós tábla, amelyet két célra használunk. Először is a silók találkozópontjaként használják, hogy megtalálják egymást és Orleans az ügyfeleket a silók megtalálásához. Másodszor az aktuális tagsági nézet (élő silók listája) tárolására szolgál, és segít koordinálni a megállapodást a tagsági nézetben. Jelenleg 6 implementációval rendelkezünk: az Azure Table Storage, az SQL Server, az Apache ZooKeeper, a Consul IO, az AWS DynamoDB és a memóriabeli emuláció fejlesztéshez.IMembershipTable

Az egyes silók mellett IMembershipTable egy teljes mértékben elosztott társközi tagsági protokollban is részt vesz, amely észleli a sikertelen silókat, és megállapodásra jut egy élő silók készletéről. Először a tagsági protokoll belső implementációját Orleansismertetjük az alábbiakban, majd később ismertetjük a IMembershipTable.

Az alapszintű tagsági protokoll

  1. Az indításkor minden siló hozzáad egy bejegyzést egy jól ismert, megosztott táblához, a következő implementációval IMembershipTable: . A silódentitás (ip:port:epoch) és a szolgáltatástelepítési azonosító kombinációja egyedi kulcsként használatos a táblában. A korszak csak a siló elindulásakor eltelt idő, és mint ilyen ip:port:epoch , garantáltan egyedi lesz egy adott Orleans üzembe helyezésben.

  2. A silók közvetlenül figyelik egymást az alkalmazás pingelésével ("élsz" heartbeats). A pingeket közvetlen üzenetként küldi el a silótól a silóig ugyanazon TCP-szoftvercsatornákon keresztül, amelyeket a silók kommunikálnak. Így a pingelések teljes mértékben korrelálnak a tényleges hálózati problémákkal és a kiszolgáló állapotával. Minden siló más silók konfigurálható készletét pingeli. A siló kiválasztja, hogy ki pingeljen, ha konzisztens kivonatokat számít ki más silók identitásán, létrehoz egy virtuális gyűrűt az összes identitásból, és kiválasztja az X követő silókat a gyűrűn (ez egy jól ismert elosztott módszer, amelyet konzisztens kivonatolásnak neveznek, és széles körben használják számos elosztott kivonattáblában, például a Chord DHT-ben).

  3. Ha egy siló S nem kap Y ping választ egy figyelt kiszolgálóról P, gyanítja, hogy az időbélyegzett gyanút a P sorába írja a IMembershipTable.

  4. Ha P-nek több mint Z gyanúja van K másodpercen belül, akkor S azt írja, hogy P halott a P sorába, és egy kérést küld minden silónak, hogy olvassa újra a tagsági táblát (amit egyébként rendszeresen meg fognak tenni).

  5. További részletek:

    1. A gyanú a IMembershipTableP sor egy speciális oszlopában van megírva. Amikor S gyanítja P azt írja: "abban az időben TTT S gyanított P".

    2. Az egyik gyanú nem elég ahhoz, hogy P-t halottnak nyilvánítsuk. A P halottként való deklarálásához egy konfigurálható T időablakban A különböző silókból származó Z gyanúra van szüksége, általában 3 perc alatt. A gyanút optimista egyidejűség-vezérléssel írják meg, amelyet a IMembershipTable.

    3. A gyanús S siló felolvassa P sorát.

    4. Ha S az utolsó gyanúsított (már volt Z-1 gyanúsított a T időszakon belül, ahogy a gyanú oszlopban meg van írva), S úgy dönt, hogy A-t halottnak nyilvánítja. Ebben az esetben az S hozzáadja magát a gyanúsítottak listájához, és azt is írja a P Állapot oszlopába, hogy P halott.

    5. Ellenkező esetben, ha S nem az utolsó gyanúsított, S csak hozzáadja magát a gyanúsított oszlopához.

    6. A visszaírás mindkét esetben az olvasott verziószámot vagy ETaget használja, így a sor frissítései szerializálva lesznek. Abban az esetben, ha az írás a verzió/ETag eltérése miatt meghiúsult, az S újrapróbálkozik (olvassa újra, és próbálkozzon az írással, kivéve, ha P már halottként lett megjelölve).

    7. Magas szinten az "olvasás, helyi módosítás, visszaírás" sorozat egy tranzakció. Ehhez azonban nem használunk tárolási tranzakciókat. A "Transaction" kód helyileg fut egy kiszolgálón, és az elkülönítés és az atomiság biztosításához az IMembershipTable általa biztosított optimista egyidejűséget használjuk.

  6. Minden siló rendszeresen felolvassa a teljes tagsági táblát az üzembe helyezéshez. Így a silók megismerkednek az új silók csatlakozásáról, és arról, hogy a többi silót halottnak nyilvánították.

  7. Konfiguráció: az Azure-beli éles használat során kézzel hangolt alapértelmezett konfigurációt biztosítunk. Jelenleg az alapértelmezett érték a következő: minden silót három másik siló figyel, két gyanú elég ahhoz, hogy halottnak nyilvánítsa a silót, a gyanúk csak az utolsó három percből származnak (különben elavultak). A pingeket 10 másodpercenként küldjük el, és három pinget kell kihagynia, hogy gyanítsunk egy silót.

  8. A tökéletes hiba észlelésének kényszerítése – elméletileg lehetséges, hogy egy siló halottnak lesz nyilvánítva, ha megszakad a kommunikáció más silókkal, miközben maga a silófolyamat még mindig fut. A probléma megoldásához, miután a silót halottnak nyilvánították a táblában, mindenki halottnak tekinti, még akkor is, ha nem halott (csak ideiglenesen particionálva, vagy a szívverési üzenetek elvesznek). Mindenki abbahagyja a kommunikációt vele, és amint megtudja, hogy halott (az új állapotot a táblázatból olvasva) öngyilkosságot követ el, és leállítja a folyamatot. Ennek eredményeképpen létre kell hozni egy infrastruktúrát a siló új folyamatként való újraindításához (az indításkor új korszakszám jön létre). Ha az Azure-ban van üzemeltetve, az automatikusan megtörténik. Ha nem, egy másik infrastruktúrára van szükség. Például egy Windows-szolgáltatás, amely úgy van konfigurálva, hogy hiba esetén automatikusan újrainduljon, vagy kubernetes-telepítést.

  9. Optimalizálás a rendszeres táblázatolvasások gyakoriságának csökkentése és az új silók és a halott silók megismerésének felgyorsítása érdekében. Minden alkalommal, amikor egy siló sikeresen ír valamit az táblába (gyanú, új illesztés stb.), akkor az összes többi silónak is közvetít – "menj, és olvasd újra a táblázatot most". A siló NEM mondja el másoknak, hogy mit írt a táblában (mivel ezek az információk már elavultak vagy helytelenek lehetnek), csak azt jelzi nekik, hogy olvassák újra a táblázatot. Így nagyon gyorsan megismerjük a tagság változásait anélkül, hogy meg kellene várni a teljes időszakos olvasási ciklust. Továbbra is szükség van a rendszeres olvasásra, arra az esetre, ha a "táblázat újraolvasása" üzenet elveszne.

Az alapszintű tagsági protokoll tulajdonságai

  1. Tetszőleges számú hibát képes kezelni:

    Az algoritmus tetszőleges számú hibát (azaz f<=n) képes kezelni, beleértve a fürt teljes újraindítását is. Ez ellentétben áll a "hagyományos" Paxos-alapú megoldásokkal, amelyek kvórumot igényelnek, ami általában többség. Éles helyzetekben láttuk, amikor a silók több mint fele leállt. A rendszer működőképes maradt, míg a Paxos-alapú tagság nem tudott előrehaladni.

  2. A táblázat forgalma nagyon világos:

    A tényleges pingek közvetlenül a kiszolgálók között haladnak, nem pedig a táblába. Ez sok forgalmat generálna, plusz a hibaészlelés szempontjából kevésbé lenne pontos - ha egy siló nem érné el az asztalt, akkor kihagyná az élő szívverés írását, és mások megölnék.

  3. A pontosság és a teljesség összehasonlítása:

    Bár nem lehet tökéletes és pontos hibaészlelést elérni, az ember általában azt szeretné, hogy a pontosság (ne akarjon halottként élő silót deklarálni) teljességgel (halottnak szeretne nyilvánítani egy olyan silót, amely a lehető leghamarabb halott). A konfigurálható szavazatok, hogy deklarálják halott és kihagyott pingek lehetővé teszik a kereskedelem e kettő. További információ: Yale University: Computer Science Failure Detectors.

  4. Scale (Méretezés):

    Az alapprotokoll több ezer, de akár több tízezer kiszolgálót is képes kezelni. Ez ellentétben áll a hagyományos Paxos-alapú megoldásokkal, például a csoportkommunikációs protokollokkal, amelyekről ismert, hogy nem lépik túl a tízes skálázást.

  5. Diagnosztika:

    A táblázat diagnosztikai és hibaelhárítási célokra is nagyon kényelmes. A rendszergazdák azonnal megtalálhatják a táblázatban az élő silók aktuális listáját, valamint megtekinthetik az összes megölt siló és gyanú előzményeit. Ez különösen hasznos a problémák diagnosztizálásakor.

  6. Miért van szükségünk megbízható állandó tárolóra a IMembershipTablekövetkezők végrehajtásához:

    Két célra állandó tárolót (Azure table, SQL Server, AWS DynamoDB, Apache ZooKeeper vagy Consul IO KV) IMembershipTable használunk. Először is a silók találkozópontjaként használják, hogy megtalálják egymást és Orleans az ügyfeleket a silók megtalálásához. Másodszor, megbízható tárterületet használunk a tagsági nézetről szóló megállapodás koordinálásához. Bár a hibák észlelését közvetlenül a silók közötti társközi módon hajtjuk végre, a tagsági nézetet megbízható tárolóban tároljuk, és a tároló által biztosított egyidejűség-vezérlési mechanizmussal megállapodásra jutunk, hogy ki él és ki halt meg. Így bizonyos értelemben a protokoll kiszervezi az elosztott konszenzus nehéz problémáját a felhőben. Ebben teljes mértékben kihasználjuk a mögöttes felhőplatform erejét, és valóban szolgáltatásként (PaaS) használjuk.

  7. Mi történik, ha a tábla egy ideig nem érhető el:

    Ha a tárolási szolgáltatás le van kapcsolva, nem érhető el, vagy kommunikációs problémák merülnek fel vele kapcsolatban, a Orleans protokoll nem deklarálja a silókat tévedésből halottnak. Az operatív silók problémamentesen működnek tovább. Azonban nem lesz képes halott silót deklarálni (ha azt észleli, Orleans hogy néhány siló elhalt a kihagyott pingekkel, nem fogja tudni írni ezt a tényt a táblába), és nem fogja tudni engedélyezni az új silók csatlakozását. Így a teljesség szenvedni fog, de a pontosság nem lesz – a táblából való particionálás soha nem fogja azt okozni Orleans , hogy a silót tévedésből halottnak minősítse. Részleges hálózati partíció esetén (ha egyes silók hozzáférhetnek a táblához, és néhány nem), előfordulhat, hogy Orleans egy halott silót halottként deklarálnak, de egy ideig tart, amíg az összes többi siló meg nem tanul róla. Így az észlelés késleltethető, de Orleans a táblázat elérhetetlensége miatt soha nem öl meg helytelenül egy silót.

  8. A közvetlen IAmAlive csak a diagnosztikához ír a táblába:

    A silók között küldött szívverések mellett minden siló rendszeresen frissíti az "I Am Alive" oszlopot a táblázat sorában. Ez a "I Am Alive" oszlop csak manuális hibaelhárításhoz és diagnosztikahoz használható, és magát a tagsági protokollt nem használja. Általában sokkal alacsonyabb gyakorisággal (5 percenként) írják, és nagyon hasznos eszközként szolgál a rendszergazdák számára a fürt élőségének ellenőrzéséhez, vagy könnyen kideríthetik, hogy a siló mikor élt utoljára.

Bővítmény tagságnézetek megrendeléséhez

A fent ismertetett alapszintű tagsági protokollt később kiterjesztették a rendezett tagsági nézetek támogatására. Röviden ismertetjük a bővítmény okait és megvalósításának módját. A bővítmény nem módosít semmit a fenti kialakításban, csak hozzáadja azt a tulajdonságot, hogy az összes tagsági konfiguráció globálisan teljesen rendezett.

Miért hasznos a tagsági nézetek megrendelése?

  • Ez lehetővé teszi az új silók fürthöz való csatlakoztatásának szerializálását. Így amikor egy új siló csatlakozik a fürthöz, ellenőrizheti a kétirányú kapcsolatot minden olyan silóval, amely már elindult. Ha néhányuk már csatlakozott silók nem válaszolnak rá (ami hálózati kapcsolati problémát jelezhet az új silóval), az új siló nem csatlakozhat. Ez biztosítja, hogy legalább egy siló indításakor teljes kapcsolat legyen a fürt összes silója között (ez implementálva van).

  • A silóban lévő magasabb szintű protokollok, például az elosztott szemcsés címtár kihasználhatják azt a tényt, hogy a tagságnézetek rendezettek, és ezen információk segítségével intelligensebb duplikált aktiválási megoldásokat hajthatnak végre. Különösen, amikor a címtár rájön, hogy 2 aktiválás jött létre, amikor a tagság fluxusban volt, dönthet úgy, hogy inaktiválja a régebbi aktiválást, amelyet a már elavult tagsági adatok alapján hoztak létre.

Kiterjesztett tagsági protokoll:

  1. Ennek a funkciónak a megvalósításához a tranzakciók támogatását használjuk több sorban, amelyeket a MembershipTablerendszer biztosít.

  2. Hozzáadunk egy tagsági verziós sort a táblához, amely nyomon követi a tábla változásait.

  3. Amikor siló S akar írni gyanút vagy halál nyilatkozatot siló P:

    1. S felolvassa a legújabb táblázattartalmat. Ha P már halott, ne tegyen semmit. Egyébként
    2. Ugyanabban a tranzakcióban írja be a módosításokat A P sorába, valamint növelje a verziószámot, és írja vissza a táblába.
    3. Mindkét írás e-címkékkel van kondicionálva.
    4. Ha a tranzakció megszakad, mert az ETag nem egyezik a P sorában vagy a verziósorban, próbálkozzon újra.

  4. A táblába írt összes írás módosítja és növeli a verziósort. Így a táblába írt összes írás szerializálva lesz (a verziósor frissítéseinek szerializálásával), és mivel a silók csak növelik a verziószámot, az írások is teljesen sorrendbe vannak rendezve a növekvő sorrendben.

A kiterjesztett tagsági protokoll méretezhetősége:

A protokoll kiterjesztett verziójában minden írás egy sorban szerializálódik. Ez potenciálisan ronthatja a fürtfelügyeleti protokoll méretezhetőségét, mivel növeli az egyidejű táblaírások közötti ütközések kockázatát. A probléma részleges megoldásához a silók exponenciális visszalépéssel próbálkozzon újra az összes írásukkal a táblába. Megfigyeltük a kiterjesztett protokollokat, amelyek gördülékenyen működnek az Azure-beli éles környezetben akár 200 silóval. Úgy gondoljuk azonban, hogy a protokollnak több mint ezer siló skálázási problémái lehetnek. Ilyen nagy beállítások esetén előfordulhat, hogy a verziósor frissítései egyszerűen le lesznek tiltva, lényegében fenntartva a fürtkezelési protokoll többi részét, és lemondanak a teljes rendelési tulajdonságról. Vegye figyelembe azt is, hogy itt a fürtkezelési protokoll méretezhetőségére hivatkozunk, nem pedig a többire Orleans. Úgy gondoljuk, hogy a Orleans futtatókörnyezet más részei (üzenetkezelés, elosztott címtár, grain hosting, ügyfél-átjáró kapcsolat) több száz silónál is méretezhetőek.

Tagsági tábla

Ahogy már említettük, IMembershipTable a silók találkozóhelyként használják, hogy megtalálják egymást és Orleans az ügyfeleket a silók megtalálásához, és segít koordinálni a tagsági nézettel kapcsolatos megállapodást. Jelenleg hat implementációnk van: az Azure Table, az SQL Server, az IMembershipTableApache ZooKeeper, a Consul IO, az AWS DynamoDB és a memóriabeli emuláció fejlesztésre.

  1. Azure Table Storage – ebben a implementációban az Azure üzembehelyezési azonosítóját használjuk partíciókulcsként, a silódentitást (ip:port:epoch) pedig sorkulcsként. Együtt garantálják a silónkénti egyedi kulcsot. Az egyidejűség-vezérléshez optimista egyidejűségi vezérlőt használunk az Azure Table ETags alapján. Minden alkalommal, amikor a táblából olvasunk, minden olvasási sorhoz tároljuk az ETaget, és ezt az ETaget használjuk, amikor megpróbáljuk visszaírni. Az ETag-eket az Azure Table szolgáltatás minden íráskor automatikusan hozzárendeli és ellenőrzi. Többsoros tranzakciók esetén az Azure-tábla által biztosított kötegtranzakciók támogatását használjuk, amely garantálja a szerializálható tranzakciókat ugyanazon partíciókulcsú sorokon.

  2. SQL Server – ebben a megvalósításban a konfigurált üzembehelyezési azonosítóval különböztetjük meg az üzemelő példányokat, és hogy mely silók tartoznak az üzemelő példányokhoz. A silódentitás a megfelelő táblák és oszlopok kombinációjaként deploymentID, ip, port, epoch van definiálva. A relációs háttérrendszer optimista egyidejűség-vezérlést és tranzakciókat használ, hasonlóan az ETags Azure Table-implementációban való használatához. A relációs implementáció elvárja, hogy az adatbázismotor létrehozza a használt ETaget. AZ SQL Server esetében az SQL Server 2000-en a létrehozott ETag egy, a hívásból NEWID()beolvasva. Az SQL Server 2005-ös és újabb ROWVERSION-t használja. Orleansátlátszatlan VARBINARY(16) címkékként olvassa és írja a relációs ETag-eket, és base64 kódolású sztringekként tárolja őket a memóriában. Orleans támogatja a többsoros beszúrásokat a statisztikai adatok beszúrására jelenleg használt (az Oracle és a DUAL esetében is) használatával UNION ALL . Az SQL Server pontos implementációja és indoklása a LétrehozásOrleansTables_SqlServer.sql című témakörben tekinthető meg.

  3. Apache ZooKeeper – ebben a implementációban a konfigurált üzembehelyezési azonosítót használjuk gyökércsomópontként, a silódentitást (ip:port@epoch) pedig gyermekcsomópontként. Együtt garantálják a silónkénti egyedi útvonalat. Az egyidejűség-vezérléshez optimista egyidejűségi vezérlőt használunk a csomópontverzió alapján. Minden alkalommal, amikor az üzembe helyezési gyökércsomópontról olvasunk, minden olvasási gyermek silócsomópont verzióját tároljuk, és ezt a verziót használjuk, amikor megpróbáljuk visszaírni. Minden alkalommal, amikor egy csomópont adatai megváltoznak, a verziószám a ZooKeeper szolgáltatás által atomi módon növekszik. Többsoros tranzakciók esetén a többsoros metódust használjuk, amely garantálja a szerializálható tranzakciókat ugyanazon szülő üzembehelyezési azonosító csomóponttal rendelkező silócsomópontokon.

  4. Consul IO – a consul kulcs-érték tárolójával implementáltuk a tagsági táblát. További részletekért tekintse meg a Consul-Deployment webhelyet.

  5. AWS DynamoDB – Ebben az implementációban a fürt üzembehelyezési azonosítóját használjuk partíciókulcsként és Silo-identitásként (ip-port-generation) a Rekordegységet létrehozó RangeKey-ként. Az optimista egyidejűséget az ETag attribútum úgy teszi lehetővé, hogy feltételes írást végez a DynamoDB-n. A megvalósítási logika meglehetősen hasonlít az Azure Table Storage-hoz.

  6. Memóriabeli emuláció a fejlesztés beállításához. Ehhez a megvalósításhoz egy speciális rendszerszemcsét használunk MembershipTableGrain. Ez a gabona egy kijelölt elsődleges silón él, amelyet csak fejlesztési beállításokhoz használnak. Valós éles használat esetén nincs szükség elsődleges silóra.

Konfiguráció

A tagsági protokoll a Liveness Configuration.xml fájl szakaszánakOrleansGlobals elemével van konfigurálva. Az alapértelmezett értékek az Azure-beli éles használat éveiben lettek hangolva, és úgy gondoljuk, hogy jó alapértelmezett beállításokat jelentenek. Ezek módosítására általában nincs szükség.

Minta konfigurációelem:

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

Az élőségnek 4 típusa van implementálva. Az élőségi protokoll típusa a SystemStoreType Configuration.xml fájlban Orleanstalálható Globals szakasz elemének attribútumán SystemStore keresztül van konfigurálva.

  1. MembershipTableGrain: a tagsági tábla az elsődleges silón lévő szemcsében van tárolva. Ez csak fejlesztési beállítás.
  2. AzureTable: a tagsági tábla az Azure-táblában van tárolva.
  3. SqlServer: a tagsági tábla egy relációs adatbázisban van tárolva.
  4. ZooKeeper: a tagsági tábla egy ZooKeeper-együttesben van tárolva.
  5. Consul: egyéni rendszertárolóként konfigurálva a következővel MembershipTableAssembly = "OrleansConsulUtils": . További részletekért tekintse meg a Consul-Deployment webhelyet.
  6. DynamoDB: egyéni rendszertárolóként konfigurálva a következővel MembershipTableAssembly = "OrleansAWSUtils": .

Az összes élőségi típus esetében a gyakori konfigurációs változók az elemben Globals.Liveness vannak definiálva:

  1. ProbeTimeout: A másodpercek száma, hogy mintavétel más silók az élőség vagy a siló küldeni "Élek" szívverési üzenetek magáról. Az alapértelmezett érték 10 másodperc.
  2. TableRefreshTimeout: A tagsági táblából a frissítések lekéréséhez másodpercek száma. Az alapértelmezett érték 60 másodperc.
  3. DeathVoteExpirationTimeout: Elévülési idő másodpercben a halál szavazás a tagsági táblázatban. Az alapértelmezett érték 120 másodperc
  4. NumMissedProbesLimit: Az elmulasztott "Élek" szívverési üzenetek száma egy silóból, vagy a nem megválaszolt mintavételek száma, amelyek arra utalnak, hogy ez a siló halott. Az alapértelmezett érték 3.
  5. NumProbedSilos: Az egyes silók élőképesség-mintavételeinek száma. Az alapértelmezett érték 3.
  6. NumVotesForDeathDeclaration: Azoknak a nem lejárt szavazatoknak a száma, amelyek egy siló halottként való deklarálásához szükségesek (legfeljebb NumMissedProbesLimitnek kell lennie). Az alapértelmezett érték 2.
  7. UseLivenessGossip: Azt, hogy a pletykaoptimalizálással felgyorsítsa-e az élőségi információk terjesztését. Alapértelmezett érték: true (igaz).
  8. IAmAliveTablePublishTimeout: A siló életben lévő tagsági táblában rendszeres időközönként írandó másodpercek száma. Csak diagnosztikához használható. Az alapértelmezett érték 5 perc.
  9. NumMissedTableIAmAliveLimit: A táblában egy olyan silóból származó kihagyott "Élek" frissítések száma, amely figyelmeztetés naplózását okozza. Nincs hatással az élőségi protokollra. Az alapértelmezett érték 2.
  10. MaxJoinAttemptTime: A silók fürtjéhez való csatlakozáshoz a feladás előtt megkísérlendő másodpercek száma. Az alapértelmezett érték 5 perc.
  11. ExpectedClusterSize: A fürt várható mérete. Nem kell nagyon pontos, lehet túlbecsülni. Az újrapróbálkozások exponenciális háttéralgoritmusának finomhangolására szolgál az Azure-táblába való íráshoz. Az alapértelmezett érték 20.

Tervezési indokok

Természetes kérdés lehet, hogy miért nem támaszkodik teljesen az Apache ZooKeeperre a fürttagság implementálásához, esetleg a rövid élettartamú csomópontokkal rendelkező csoporttagság beépített támogatásának használatával? Miért foglalkoztunk a tagsági protokoll implementálásával? Ennek elsősorban három oka volt:

  1. Üzembe helyezés/üzemeltetés a felhőben:

    A Zookeeper nem üzemeltetett szolgáltatás (legalábbis az írás idején, 2015 júliusában, és határozottan amikor 2011 nyarán először implementáltuk ezt a protokollt, a Zookeeper egyik fő felhőszolgáltató által üzemeltetett szolgáltatásként sem futott). Ez azt jelenti, hogy a felhőkörnyezetben Orleans az ügyfeleknek üzembe kell helyezniük/futtatniuk/kezelniük kell egy ZK-fürt példányát. Ez egy újabb szükségtelen teher, amelyet nem kívántunk az ügyfeleinkre kényszeríteni. Az Azure Table használatával egy üzemeltetett, felügyelt szolgáltatásra támaszkodunk, amely sokkal egyszerűbbé teszi az ügyfeleink életét. A felhőben alapvetően a Felhőt használja platformként, nem infrastruktúraként. Másrészt a helyszíni üzemeltetés és a kiszolgálók kezelése esetén a ZK-ra támaszkodni a IMembershipTable megoldás implementálásaként életképes megoldás.

  2. Közvetlen hibaészlelés:

    Ha a ZK csoporttagságát rövid élettartamú csomópontokkal használja, a hibaészlelés a kiszolgálók (ZK-ügyfelek) és a Orleans ZK-kiszolgálók között történik. Ez nem feltétlenül korrelál a kiszolgálók közötti Orleans tényleges hálózati problémákkal. Az volt a célunk, hogy a hibaészlelés pontosan tükrözze a kommunikáció fürtön belüli állapotát. Pontosabban, a tervünkben, ha egy Orleans siló nem tud kommunikálni a IMembershipTable vele, akkor nem tekinthető halottnak, és továbbra is működik. Ezzel szemben használtunk-e ZK-csoporttagságot rövid élettartamú csomópontokkal, a ZK-kiszolgálóról való leválasztás miatt egy Orleans siló (ZK-ügyfél) halottnak minősülhet, miközben lehet, hogy életben van és teljesen működőképes.

  3. Hordozhatóság és rugalmasság:

    A filozófia részeként Orleansnem szeretnénk erős függőséget kényszeríteni egy adott technológiától, hanem rugalmas kialakítással rendelkezünk, ahol a különböző összetevők könnyen válthatók különböző implementációkkal. Pontosan ezt a célt IMembershipTable szolgálja az absztrakció.

Köszönetnyilvánítás

Szeretnénk elismerni Alex Kogan hozzájárulását a protokoll első verziójának kialakításához és megvalósításához. Ez a munka a Microsoft Researchben 2011 nyarán végzett nyári szakmai gyakorlat részeként történt. A ZooKeeper-alapú IMembershipTable implementációt Shay Hazor, az SQL IMembershipTable implementálását Veikko Eeva, az AWS DynamoDB IMembershipTable implementációját Gutemberg Ribeiro, a Consul-alapú IMembershipTable implementációt Pedig Paul North végezte.