Lezen in het Engels

Delen via

Clusterbeheer in Orleans

  • Artikel

Orleans biedt clusterbeheer via een ingebouwd lidmaatschapsprotocol, dat soms wordt aangeduid als clusterlidmaatschap. Het doel van dit protocol is voor alle silo's (Orleans servers) om akkoord te gaan met de set momenteel levende silo's, het detecteren van mislukte silo's en het toestaan van nieuwe silo's om het cluster te koppelen.

Het protocol is afhankelijk van een externe service om een abstractie van IMembershipTablete bieden. IMembershipTable is een platte duurzame tabel die we voor twee doeleinden gebruiken. Ten eerste wordt het gebruikt als een rendez-vouspunt voor silo's om elkaar en Orleans clients te vinden om silo's te vinden. Ten tweede wordt het gebruikt om de huidige lidmaatschapsweergave (lijst met levende silo's) op te slaan en helpt de overeenkomst over de lidmaatschapsweergave te coördineren.

We hebben momenteel 6 implementaties van de IMembershipTable: op basis van Azure Table Storage-, Azure Cosmos DB, ADO.NET (PostgreSQL, MySQL/MariaDB, SQL Server, Oracle), Apache ZooKeeper, Consul IO-, AWS DynamoDB-, MongoDB-, Redis-, Apache Cassandra-en een in-memory implementatie voor ontwikkeling.

Naast elke IMembershipTable silo neemt deel aan een volledig gedistribueerd peer-to-peer-lidmaatschapsprotocol dat mislukte silo's detecteert en een overeenkomst bereikt over een set levende silo's. Hieronder wordt de interne implementatie van het lidmaatschapsprotocol van Orleansbeschreven.

Het lidmaatschapsprotocol

  1. Bij het opstarten voegt elke silo een vermelding voor zichzelf toe aan een bekende, gedeelde tabel met behulp van een implementatie van IMembershipTable. Een combinatie van silo-identiteit (ip:port:epoch) en service-implementatie-id (cluster-id) wordt gebruikt als unieke sleutels in de tabel. Epoch is slechts tijd in tikken wanneer deze silo is gestart en als zodanig ip:port:epoch gegarandeerd uniek is in een bepaalde Orleans implementatie.

  2. Silo's bewaken elkaar rechtstreeks via toepassingstests ('leef je' heartbeats). probes worden als directe berichten van silo naar silo verzonden, via dezelfde TCP-sockets waarmee silo's communiceren. Op die manier worden tests volledig gecorreleerd met werkelijke netwerkproblemen en serverstatus. Elke silo onderzoekt een configureerbare set van andere silo's. Een silo bepaalt wie er moet worden onderzocht door consistente hashes op de identiteit van andere silo's te berekenen en door een virtuele ring van alle identiteiten te vormen, waarna X opvolgende silo's op de ring worden geselecteerd (dit is een bekende gedistribueerde techniek genaamd consistente hashing en wordt veel gebruikt in veel gedistribueerde hashtabellen, zoals Chord DHT).

  3. Als silo S geen Y antwoorden van de gemonitorde server P ontvangt, noteert het zijn verdenking met tijdstempel in de rij van P in de IMembershipTable.

  4. Als P meer dan Z vermoedens binnen K seconden heeft, schrijft S dat P dood is in de rij van P en stuurt een momentopname van de huidige lidmaatschapstabel naar alle andere silo's. Silo's vernieuwen periodiek de tabel, dus de momentopname is een optimalisatie om de snelheid te verhogen waarmee alle silo's leren over de nieuwe lidmaatschapsweergave.

  5. In meer details:

    1. Vermoeden wordt naar de IMembershipTable, in een speciale kolom in de rij die overeenkomt met P geschreven. Wanneer S vermoedt P, schrijft het: "op het moment dat TTT S verdachte P".

    2. Eén vermoeden is niet genoeg om P als dood te verklaren. U hebt Z-vermoedens van verschillende silo's nodig in een configureerbaar tijdvenster T, meestal 3 minuten, om P als dood te declareren. Het vermoeden wordt geschreven met behulp van optimistische gelijktijdigheidscontrole die wordt verstrekt door de IMembershipTable.

    3. De verdachte silo S leest P's rij.

    4. Als S dit de laatste verdachte is (er zijn al Z-1 verdachten binnen een periode van T, zoals geschreven in de verdenkingskolom), besluit S P als Dood te declareren. In dit geval voegt S zichzelf toe aan de lijst met verdachten en schrijft ze ook in de kolom Status van P dat P dood is.

    5. Als S niet de laatste verdachte is, voegt S zichzelf alleen toe aan de kolom van de verdachte.

    6. In beide gevallen gebruikt de write-back het versienummer of de ETag die is gelezen, zodat de updates voor deze rij worden geserialiseerd. Als de schrijfbewerking is mislukt vanwege niet-overeenkomende versie/ETag, probeert S opnieuw te proberen (opnieuw te lezen en te schrijven, tenzij P al is gemarkeerd als dood).

    7. Op hoog niveau is deze reeks 'lezen, lokaal wijzigen, terugschrijven' een transactie. We gebruiken echter niet noodzakelijkerwijs opslagtransacties om dat te doen. Transactiecode wordt lokaal uitgevoerd op een server en we gebruiken optimistische gelijktijdigheid die wordt geleverd door de IMembershipTable server om isolatie en atomiciteit te garanderen.

  6. Elke silo leest periodiek de volledige lidmaatschapstabel voor de implementatie. Op die manier leren silo's over nieuwe silo's die worden toegevoegd en over andere silo's die dood worden verklaard.

  7. Momentopname uitzenden: Om de frequentie van periodieke tabellezingen te verminderen, wordt elke keer dat een silo naar de tabel schrijft (bij vermoeden, nieuwe samenvoeging, enzovoort) een momentopname van de huidige tabelstatus naar alle andere silo's verzonden. Omdat de lidmaatschapstabel consistent en monotonisch is, produceert elke update een uniek versiebeheerde momentopname die veilig kan worden gedeeld. Hierdoor kunnen lidmaatschapswijzigingen onmiddellijk worden doorgegeven zonder te wachten op de periodieke leescyclus. De periodieke leesbewerking wordt nog steeds onderhouden als een terugvalmechanisme voor het geval de distributie van momentopnamen mislukt.

  8. Geordende lidmaatschapsweergaven: Het lidmaatschapsprotocol zorgt ervoor dat alle lidmaatschapsconfiguraties globaal zijn gerangschikt. Deze volgorde biedt twee belangrijke voordelen:

    1. Gegarandeerde connectiviteit: wanneer een nieuwe silo aan het cluster wordt toegevoegd, moet deze tweerichtingsconnectiviteit met elke andere actieve silo valideren. Als een bestaande silo niet reageert (mogelijk een probleem met de netwerkverbinding aangeeft), mag de nieuwe silo niet worden samengevoegd. Dit zorgt voor volledige connectiviteit tussen alle silo's in het cluster tijdens het opstarten. Zie de opmerking over IAmAlive hieronder voor een uitzondering in het geval van herstel na noodgevallen.

    2. consistente directory-updates: protocollen op een hoger niveau, zoals de gedistribueerde adreslijst, zijn afhankelijk van alle silo's die een consistente, monotone weergave van het lidmaatschap hebben. Hierdoor kunnen dubbele graanactiveringen slimmer worden opgelost. Zie de grain directory documentatie voor meer informatie.

    Implementatiedetails:

    1. De IMembershipTable vereist atomische updates om een globale totale volgorde van wijzigingen te garanderen:

      • Implementaties moeten zowel de tabelvermeldingen (lijst met silo's) als het versienummer atomisch bijwerken
      • Dit kan worden bereikt met behulp van databasetransacties (zoals in SQL Server) of atomische vergelijkings- en wisselbewerkingen met behulp van ETags (zoals in Azure Table Storage)
      • Het specifieke mechanisme is afhankelijk van de mogelijkheden van het onderliggende opslagsysteem

    2. In een speciale rij met lidmaatschapsversies in de tabel worden wijzigingen bijgehouden:

      • Elke schrijfbewerking naar de tabel (vermoedens, doodsdeclaraties, joins) verhogen dit versienummer
      • Alle schrijfbewerkingen worden geserialiseerd via deze rij met atomische updates
      • De monotonisch toenemende versie zorgt voor een totale volgorde van alle lidmaatschapswijzigingen

    3. Wanneer silo S de status van silo P bijwerken:

      • S leest eerst de meest recente tabelstatus
      • In één atomische bewerking wordt zowel de rij van P bijgewerkt als wordt het versienummer verhoogd
      • Wanneer de atomische update mislukt (bijvoorbeeld vanwege gelijktijdige wijzigingen), wordt de bewerking opnieuw geprobeerd met exponentiële terugloop.

    overwegingen voor schaalbaarheid:

    Het serialiseren van alle schrijfbewerkingen via de versierij kan van invloed zijn op schaalbaarheid vanwege toegenomen conflicten. Het protocol is bewezen in productie met maximaal 200 silo's, maar kan tot meer dan duizend silo's uitdagingen ondervinden. Voor zeer grote implementaties blijven andere onderdelen van Orleans (messaging, grain directory, hosting) schaalbaar, zelfs als lidmaatschapsupdates een knelpunt worden.

  9. standaardconfiguratie: de standaardconfiguratie is handmatig afgestemd tijdens het productiegebruik in Azure. Standaard: elke silo wordt bewaakt door drie andere silo's, twee vermoedens zijn voldoende om een silo dood te verklaren, vermoedens alleen uit de afgelopen drie minuten (anders zijn ze verouderd). er worden elke tien seconden tests verzonden en u moet drie tests missen om een silo te vermoeden.

  10. zelfcontrole: de foutdetector bevat ideeën uit het Lifeguard onderzoek van Hashicorp (paper, talk, blog) om de clusterstabiliteit te verbeteren tijdens catastrofale gebeurtenissen waarbij een groot deel van het cluster gedeeltelijke storingen ondervindt. Het LocalSiloHealthMonitor onderdeel beoordeelt de status van elke silo met behulp van meerdere heuristieken:

    • Actieve status in lidmaatschapstabel
    • Geen vermoedens van andere silo's
    • Recente geslaagde testreacties
    • Recente testaanvragen ontvangen
    • Reactiesnelheid van threadpool (werkitems die binnen 1 seconde worden uitgevoerd)
    • Timernauwkeurigheid (binnen 3 seconden na planning)

    De statusscore van een silo beïnvloedt de testtime-outs: beschadigde silo's (score 1-8) hebben een verhoogde time-out ten opzichte van gezonde silo's (score 0). Dit heeft twee voordelen:

    • Geeft meer tijd voor onderzoeken om te slagen wanneer het netwerk of systeem onder belasting staat.
    • Maakt het waarschijnlijker dat ongezonde silo's worden weggestemd voordat ze ten onrechte gezonde silo's kunnen wegstemmen.

    Dit is met name waardevol tijdens scenario's zoals de uitputting van threadpools, waarbij trage knooppunten verkeerd kunnen vermoeden dat gezonde knooppunten problemen hebben, simpelweg omdat ze de reacties niet snel genoeg kunnen verwerken.

  11. Indirecte beproeving: Een andere door Lifeguardgeïnspireerde functie die de foutdetectienauwkeurigheid verbetert door de kans te verkleinen dat een beschadigde of gepartitioneerde silo een gezonde silo ten onrechte als overleden verklaart. Wanneer een bewakingssilo nog twee testpogingen voor een doelsilo over heeft voordat er wordt gestemd om het dood te verklaren, wordt er indirect onderzoek uitgevoerd:

    • De bewakingssilo selecteert willekeurig een andere silo als intermediair en vraagt deze om het doel te onderzoeken.
    • De tussenpersoon probeert contact te maken met de doelsilo
    • Als het doel niet binnen de time-outperiode reageert, verzendt de intermediair een negatieve bevestiging
    • Als de bewakingssilo een negatieve bevestiging van de intermediair heeft ontvangen en de intermediair zichzelf gezond verklaart (door middel van zelfcontrole, zoals hierboven beschreven), voert de bewakingssilo een stem uit om het doel dood te verklaren
    • Met de standaardconfiguratie van twee vereiste stemmen telt een negatieve bevestiging van een indirecte test als beide stemmen, waardoor snellere declaratie van dode silo's mogelijk wordt wanneer de fout door meerdere perspectieven wordt bevestigd

  12. Perfecte foutdetectie afdwingen: Zodra een silo dood wordt verklaard in de tabel, wordt hij door iedereen als dood beschouwd, zelfs als hij niet dood is. Hij kan bijvoorbeeld tijdelijk gepartitioneerd zijn, of heartbeat-berichten kunnen verloren zijn gegaan. Iedereen stopt met communiceren en zodra het ontdekt dat het dood is (door de nieuwe status van de tabel te lezen) voert het zelfmoord uit en sluit het proces af. Als gevolg hiervan moet er een infrastructuur zijn om de silo opnieuw op te starten als een nieuw proces (er wordt een nieuw epochnummer gegenereerd bij het starten). Wanneer deze wordt gehost in Azure, gebeurt dat automatisch. Als dit niet het probleem is, is een andere infrastructuur vereist, zoals een Windows-service die is geconfigureerd om automatisch opnieuw op te starten bij een fout of een Kubernetes-implementatie.

  13. Wat gebeurt er als de tabel enige tijd niet toegankelijk is:

    Wanneer de opslagservice niet beschikbaar is of er communicatieproblemen zijn, declareert het Orleans protocol niet per ongeluk silo's als dood. Operationele silo's blijven werken zonder problemen. Orleans kan echter geen silo dood verklaren (als er wordt gedetecteerd dat een silo dood is via gemiste tests, kan deze niet naar de tabel worden geschreven) en kunnen er ook geen nieuwe silo's worden samengevoegd. Volledigheid zal dus lijden, maar nauwkeurigheid niet — het partitioneren van de tabel zal er nooit toe leiden dat Orleans silo per ongeluk als niet meer actief verklaart. In het geval van een gedeeltelijke netwerkpartitie (als sommige silo's toegang hebben tot de tabel en sommige niet), kan het gebeuren dat Orleans een dode silo als dood wordt verklaard, maar het enige tijd duurt totdat alle andere silo's erover leren. Detectie kan dus worden vertraagd, maar Orleans zal nooit ten onrechte een silo doden vanwege de onbeschikbaarheid van de tabel.

  14. IAmAlive schrijft voor diagnostiek en rampenherstel:

    Naast heartbeats die tussen de silo's worden uitgewisseld, werkt elke silo periodiek een 'Ik Ben Levend' tijdstempel bij in zijn rij in de tabel. Dit dient twee doeleinden:

    1. Voor diagnostische doeleinden bieden systeembeheerders een eenvoudige manier om de status van het cluster te controleren en te bepalen wanneer een silo voor het laatst actief was. De tijdstempel wordt doorgaans elke 5 minuten bijgewerkt.
    2. Voor herstel na noodgevallen, als een silo de tijdstempel gedurende verschillende perioden (geconfigureerd via NumMissedTableIAmAliveLimit) niet heeft bijgewerkt, zullen nieuwe silo's deze tijdens de opstartconnectiviteitscontroles negeren, zodat het cluster kan herstellen van scenario's waarin silo's zijn vastgelopen zonder de juiste opschoonbewerking.

Lidmaatschapstabel

Zoals reeds vermeld, IMembershipTable wordt gebruikt als een rendez-vous punt voor silo's om elkaar te vinden en Orleans clients te vinden silo's en helpt ook de overeenkomst over de lidmaatschapsweergave te coördineren. De belangrijkste Orleans-opslagplaats bevat implementaties voor veel systemen, zoals Azure Table Storage, Azure Cosmos DB, PostgreSQL, MySQL/MariaDB, SQL Server, Apache ZooKeeper, Consul IO, Apache Cassandra, MongoDB, Redis, AWS DynamoDB en een in-memory implementatie voor ontwikkeling.

  1. Azure Table Storage : in deze implementatie gebruiken we de Azure-implementatie-id als partitiesleutel en de silo-identiteit (ip:port:epoch) als rijsleutel. Samen garanderen ze een unieke sleutel per silo. Voor gelijktijdigheidsbeheer gebruiken we optimistisch gelijktijdigheidsbeheer op basis van Azure Table ETags. Telkens wanneer we uit de tabel lezen, slaan we de ETag op voor elke leesrij en gebruiken we die ETag wanneer we proberen terug te schrijven. ETags worden automatisch toegewezen en gecontroleerd door de Azure Table-service op elke schrijfbewerking. Voor transacties met meerdere rijen gebruiken we de ondersteuning voor batchtransacties die worden geleverd door de Azure-tabel, waardoor serialiseerbare transacties via rijen met dezelfde partitiesleutel worden gegarandeerd.

  2. SQL Server: in deze implementatie wordt de geconfigureerde implementatie-id gebruikt om onderscheid te maken tussen implementaties en welke silo's bij welke implementaties horen. De silo-identiteit wordt gedefinieerd als een combinatie van deploymentID, ip, port, epoch in de juiste tabellen en kolommen. De relationele back-end maakt gebruik van optimistisch gelijktijdigheidsbeheer en transacties, vergelijkbaar met de procedure voor het gebruik van ETags in Azure Table-implementatie. De relationele implementatie verwacht dat de database-engine de gebruikte ETag genereert. In het geval van SQL Server wordt op SQL Server 2000 de gegenereerde ETag verkregen van een aanroep naar NEWID(). In SQL Server 2005 en hoger wordt ROWVERSION gebruikt. Orleans leest en schrijft relationele ETags als ondoorzichtige VARBINARY(16) tags en slaat deze op in het geheugen als met base64 gecodeerde tekenreeksen. Orleans ondersteunt inserts met meerdere rijen ( UNION ALL voor Oracle inclusief DUAL), die momenteel worden gebruikt om statistiekengegevens in te voegen. De exacte implementatie en logica voor SQL Server zijn te zien op CreateOrleansTables_SqlServer.sql.

  3. Apache ZooKeeper : in deze implementatie gebruiken we de geconfigureerde implementatie-id als een hoofdknooppunt en de silo-identiteit (ip:port@epoch) als het onderliggende knooppunt. Samen garanderen ze een uniek pad per silo. Voor gelijktijdigheidsbeheer gebruiken we optimistisch gelijktijdigheidsbeheer op basis van de knooppuntversie. Telkens wanneer we lezen uit het hoofdknooppunt van de implementatie slaan we de versie op voor elk knooppunt van het leesliggende onderliggende silo en gebruiken we die versie wanneer we proberen terug te schrijven. Telkens wanneer de gegevens van een knooppunt worden gewijzigd, wordt het versienummer atomisch verhoogd door de ZooKeeper-service. Voor transacties met meerdere rijen gebruiken we de multimethode, die serialiseerbare transacties garandeert via siloknooppunten met hetzelfde bovenliggende implementatie-id-knooppunt.

  4. Consul IO - we hebben het sleutel-/waardearchief van Consul gebruikt om de lidmaatschapstabel te implementeren. Raadpleeg Consul-Deployment voor meer informatie.

  5. AWS DynamoDB - In deze implementatie gebruiken we de clusterimplementatie-id als partitiesleutel en silo-identiteit (ip-port-generation) als de RangeKey die de record-eenheid maakt. De optimistische gelijktijdigheid wordt gemaakt door het ETag kenmerk door voorwaardelijke schrijfbewerkingen te maken op DynamoDB. De implementatielogica is vergelijkbaar met Azure Table Storage.

  6. Apacha Cassandra- - In deze implementatie gebruiken we het samengestelde van service-id en cluster-id als partitiesleutel en de silo-identiteit (ip:port:epoch) als rijsleutel. Samen garanderen ze een unieke rij per silo. Voor gelijktijdigheidsbeheer gebruiken we optimistisch gelijktijdigheidsbeheer op basis van een statische kolomversie met behulp van een Lightweight Transaction. Deze versiekolom wordt gedeeld voor alle rijen in de partitie/cluster, waardoor het een consistent oplopend versienummer biedt voor de lidmaatschapstabel van elk cluster. Er zijn geen transacties met meerdere rijen in deze implementatie.

  7. Emulatie in het geheugen voor het instellen van ontwikkeling. We gebruiken een speciaal systeemkorrel voor die implementatie. Dit graan leeft op een aangewezen primaire silo, die alleen wordt gebruikt voor een ontwikkelinstallatie. In een primaire silo voor echt productiegebruik is niet vereist.

Ontwerpredenering

Een natuurlijke vraag die kan worden gesteld, is waarom niet volledig afhankelijk zijn van Apache ZooKeeper- of etcd voor de implementatie van het clusterlidmaatschap, mogelijk met behulp van de kant-en-klare ondersteuning van ZooKeeper voor groepslidmaatschap met tijdelijke knooppunten? Waarom hebben we ons lidmaatschapsprotocol niet geïmplementeerd? Er waren voornamelijk drie redenen:

  1. Implementatie/hosting in de cloud:

    Zookeeper is geen gehoste service. Dit betekent dat klanten in de cloudomgeving Orleans hun exemplaar van een ZK-cluster moeten implementeren/uitvoeren/beheren. Dit is nog een onnodige last, die we onze klanten niet willen dwingen. Door Azure Table te gebruiken, vertrouwen we op een gehoste, beheerde service, waardoor het leven van onze klant veel eenvoudiger wordt. In principe gebruikt u cloud als platform in de cloud, niet als infrastructuur. Aan de andere kant, bij het uitvoeren van on-premises en het beheren van uw servers, is het vertrouwen op ZK als een implementatie van de IMembershipTable oplossing een haalbare optie.

  2. Directe foutdetectie:

    Wanneer u het groepslidmaatschap van ZK met tijdelijke knooppunten gebruikt, wordt de foutdetectie uitgevoerd tussen de Orleans servers (ZK-clients) en ZK-servers. Dit kan niet noodzakelijkerwijs correleren met de werkelijke netwerkproblemen tussen Orleans servers. Onze wens was dat de foutdetectie de status van de communicatie binnen het cluster nauwkeurig zou weerspiegelen. In ons ontwerp, als een Orleans silo niet kan communiceren met het IMembershipTable niet als dood beschouwd en kan blijven werken. In tegenstelling tot dat, hebben we ZK-groepslidmaatschap gebruikt met tijdelijke knooppunten een verbinding met een ZK-server kan ertoe leiden dat een Orleans silo (ZK-client) wordt gedeclareerd als dood, terwijl het mogelijk actief en volledig functioneel is.

  3. Draagbaarheid en flexibiliteit:

    Als onderdeel van Orleansde filosofie willen we geen sterke afhankelijkheid van een bepaalde technologie forceren, maar hebben we liever een flexibel ontwerp waarbij verschillende componenten eenvoudig kunnen worden geschakeld met verschillende implementaties. Dit is precies het doel dat IMembershipTable abstractie dient.

Eigenschappen van het lidmaatschapsprotocol

  1. Kan een willekeurig aantal fouten verwerken:

    Ons algoritme kan elk aantal fouten (dat wil gezegd f<=n) verwerken, inclusief het volledig opnieuw opstarten van het cluster. Dit is in tegenstelling tot traditionele op Paxos gebaseerde oplossingen, waarvoor een quorum is vereist, wat meestal een meerderheid is. We hebben in productiesituaties gezien wanneer meer dan de helft van de silo's uitvalt. Ons systeem bleef functioneel, terwijl het op Paxos gebaseerde lidmaatschap niet in staat zou zijn om vooruitgang te boeken.

  2. Verkeer naar de tabel is erg licht:

    De daadwerkelijke probes gaan rechtstreeks tussen servers en niet naar de tabel. Dit zou veel verkeer genereren en zou minder nauwkeurig zijn vanuit het perspectief van de foutdetectie- als een silo de tabel niet kon bereiken, zou het missen om zijn ik levend hartbeat te schrijven, en anderen zouden hem doden.

  3. Nauwkeurigheid ten opzichte van volledigheid:

    Hoewel u niet zowel perfecte als nauwkeurige foutdetectie kunt bereiken, wil men meestal een mogelijkheid hebben om de nauwkeurigheid van de handel te drijven (wil geen silo declareren die leeft als dood) met volledigheid (wil dood een silo declareren die inderdaad zo snel mogelijk dood is). Met de configureerbare stemmen om dode en gemiste sondes te verklaren, kunnen die twee worden uitgewisseld. Zie Yale University: Computer Science Failure Detectors voor meer informatie.

  4. Scale:

    Het protocol kan duizenden en waarschijnlijk zelfs tienduizenden servers verwerken. Dit is in tegenstelling tot traditionele op Paxos gebaseerde oplossingen, zoals groepscommunicatieprotocollen, die niet meer dan tientallen kunnen worden geschaald.

  5. Diagnostiek:

    De tabel is ook erg handig voor diagnostische gegevens en probleemoplossing. De systeembeheerders kunnen direct in de tabel de huidige lijst met levende silo's vinden, evenals de geschiedenis van alle vermoorde silo's en vermoedens zien. Dit is vooral handig bij het diagnosticeren van problemen.

  6. Waarom hebben we betrouwbare permanente opslag nodig voor de implementatie van het IMembershipTablevolgende:

    We gebruiken permanente opslag voor de IMembershipTable voor twee doeleinden. Ten eerste wordt het gebruikt als een rendez-vouspunt voor silo's om elkaar en Orleans clients te vinden om silo's te vinden. Ten tweede gebruiken we betrouwbare opslag om ons te helpen de overeenkomst over de lidmaatschapsweergave te coördineren. Hoewel we foutdetectie rechtstreeks uitvoeren op een peer-to-peer-manier tussen de silo's, slaan we de lidmaatschapsweergave op in betrouwbare opslag en gebruiken we het gelijktijdigheidscontrolemechanisme dat door deze opslag wordt geboden om een overeenkomst te bereiken van wie er leeft en wie dood is. Op die manier besteedt ons protocol het harde probleem van gedistribueerde consensus aan de cloud uit. In dat we volledig gebruikmaken van de kracht van het onderliggende cloudplatform, waarbij het echt als PaaS (Platform as a Service) wordt gebruikt.

  7. Directe IAmAlive-schrijfbewerkingen in de tabel voor alleen diagnostische gegevens:

    Naast heartbeats die tussen de silo's worden verzonden, werkt elke silo ook periodiek een kolom 'I Am Alive' bij in zijn rij in de tabel. Deze kolom 'I Am Alive' wordt alleen gebruikt voor handmatige probleemoplossing en diagnostische gegevens en wordt niet gebruikt door het lidmaatschapsprotocol zelf. Het wordt meestal geschreven met een veel lagere frequentie (eenmaal om de 5 minuten) en fungeert als een zeer nuttig hulpmiddel voor systeembeheerders om de levensduur van het cluster te controleren of gemakkelijk erachter te komen wanneer de silo voor het laatst actief was.

Bevestigingen

We willen de bijdrage van Alex Kogan aan het ontwerp en de implementatie van de eerste versie van dit protocol erkennen. Dit werk is gedaan als onderdeel van een zomerstage in Microsoft Research in de zomer van 2011. De implementatie van Op ZooKeeper gebaseerde IMembershipTable werd uitgevoerd door Shay Hazor, de implementatie van SQL IMembershipTable werd uitgevoerd door Veikko Eeva, de implementatie van AWS DynamoDB IMembershipTable werd uitgevoerd door Gutemberg en de implementatie van consul IMembershipTable werd uitgevoerd door Paul North, en ten slotte werd de implementatie van de Apache Cassandra-IMembershipTable aangepast van OrleansCassandraUtils door Arshia001.