Clusterverwaltung in Orleans

2025-05-29

Orleans stellt die Clusterverwaltung über ein integriertes Mitgliedschaftsprotokoll bereit, das manchmal als Clustermitgliedschaft bezeichnet wird. Das Ziel dieses Protokolls besteht darin, dass sich alle Silos (Orleans-Server) auf die Gruppe der derzeit aktiven Silos einigen, fehlerhafte Silos erkennen und neuen Silos den Beitritt zum Cluster gestatten.

Das Protokoll basiert auf einem externen Dienst, um eine Abstraktion von IMembershipTable bereitzustellen. IMembershipTable ist ein flacher, langlebiger Tisch, der für zwei Zwecke verwendet wird. Erstens dient es als Treffpunkt für Silos, sich zu finden, und damit Orleans Kunden Silos finden können. Zweitens speichert sie die aktuelle Mitgliedschaftsansicht (Liste der aktiven Silos) und hilft bei der Koordinierung dieser Ansicht.

Derzeit gibt es mehrere Implementierungen von IMembershipTable: basierend auf Azure Table Storage, Azure Cosmos DB, ADO.NET (PostgreSQL, MySQL/MariaDB, SQL Server, Oracle), Apache ZooKeeper, Consul IO, AWS CacheDB, MongoDB, Redis, Apache Cassandra und einer In-Memory-Implementierung für die Entwicklung.

Darüber hinaus IMembershipTablenimmt jeder Silo an einem vollständig verteilten Peer-to-Peer-Mitgliedschaftsprotokoll teil, das fehlgeschlagene Silos erkennt und eine Einigung über den Satz lebendiger Silos erreicht. Die interne Implementierung des OrleansMitgliedschaftsprotokolls wird unten beschrieben.

Das Mitgliedschaftsprotokoll

Beim Start fügt jedes Silo einen Eintrag für sich selbst in eine bekannte, freigegebene Tabelle unter Verwendung einer Implementierung von IMembershipTable. Orleans verwendet eine Kombination aus Siloidentität (ip:port:epoch) und Dienstbereitstellungs-ID (Cluster-ID) als eindeutige Schlüssel in der Tabelle. Die Epoche bezeichnet die Zeit in Ticks, zu der dieses Silo gestartet wurde, um sicherzustellen, dass ip:port:epoch innerhalb einer bestimmten Orleans Bereitstellung einzigartig ist.
Silos überwachen sich direkt über Anwendungssonden ("leben Sie noch" heartbeats). Probes werden als direkte Nachrichten von Silo zu Silo über dieselben TCP-Sockets gesendet, die für die regelmäßige Kommunikation verwendet werden. Auf diese Weise korrelieren Prüfungen vollständig mit tatsächlichen Netzwerkproblemen und dem Serverzustand. Jedes Silo testet eine konfigurierbare Gruppe anderer Silos. Ein Silo wählt aus, wen überprüft werden soll, indem es konsistente Hashes auf den Identitäten anderer Silos berechnet, einen virtuellen Ring aller Identitäten bildet und dann X Nachfolgersilos auf dem Ring auswählt. (Dies ist eine bekannte verteilte Technik, die als konsistentes Hashing bezeichnet wird und häufig in vielen verteilten Hashtabellen verwendet wird, z. B. Chord DHT).
Wenn ein Silo S keine Y-Probeantworten von einem überwachten Server P empfängt, verdächtigt es P, indem es seinen mit einem Zeitstempel versehenen Verdacht in die Zeile von P in der IMembershipTable schreibt.
Wenn P innerhalb von K Sekunden mehr als Z Verdachtsmomente hat, schreibt S in Ps Zeile, dass P tot ist, und sendet einen Schnappschuss der aktuellen Mitgliedstabelle an alle anderen Silos. Silos aktualisieren die Tabelle regelmäßig, sodass die Momentaufnahme eine Optimierung ist, um die Zeit zu reduzieren, die für alle Silos benötigt wird, um mehr über die neue Mitgliedschaftsansicht zu erfahren.
Im Detail:
1. Der Verdacht wird in IMembershipTableeiner speziellen Spalte in der Zeile geschrieben, die P entspricht. Wenn S P vermutet, schreibt es: "zur Zeit TTT S verdächtigt P".
2. Ein Verdacht reicht nicht aus, um P tot zu deklarieren. Sie benötigen Z-Verdachtsfälle aus verschiedenen Silos innerhalb eines konfigurierbaren Zeitfensters T (in der Regel 3 Minuten), um P tot zu deklarieren. Der Verdacht wird unter Verwendung der optimistischen Nebenläufigkeitssteuerung geschrieben, die von der IMembershipTable bereitgestellt wird.
3. Das verdächtigende Silo S liest die Zeile von P.
4. Wenn S der letzte Verdachter ist (es gab bereits Z-1 Verdachter innerhalb des Zeitraums T, wie in der Verdachtsspalte vermerkt), beschließt S, P für tot zu erklären. In diesem Fall fügt sich S selbst der Liste der Verdächtigenden hinzu und schreibt außerdem in die „Status“-Spalte von P, dass P inaktiv (Dead) ist.
5. Andernfalls, wenn S nicht der letzte Verdächtiger ist, fügt S sich einfach in die Spalte des Verdächtigen ein.
6. In beiden Fällen verwendet der Rückschreibvorgang die Versionsnummer oder das zuvor gelesene ETag, wobei Aktualisierungen für diese Zeile serialisiert werden. Wenn der Schreibvorgang aufgrund eines Versions-/ETag-Konflikts fehlschlägt, versucht S es erneut (liest nochmals und versucht zu schreiben, es sei denn, P wurde bereits als tot markiert).
7. Auf hoher Ebene ist diese Sequenz von "Lesen, lokales Ändern, Zurückschreiben" eine Transaktion. Speichertransaktionen werden jedoch nicht unbedingt verwendet. Der "transaction"-Code wird lokal auf einem Server ausgeführt, und die optimistische Parallelität durch IMembershipTable gewährleistet Isolation und Atomarität.
Jedes Silo liest regelmäßig die gesamte Mitgliedschaftstabelle für seine Bereitstellung. Auf diese Weise erfahren die Silos von neuen Silos, die beitreten, und von anderen Silos, die als tot erklärt werden.
Snapshot-Übertragung: Um die Häufigkeit regelmäßiger Tabellenlesevorgänge zu reduzieren, sendet ein Silo jedes Mal, wenn ein Silo in die Tabelle schreibt (Verdacht, neuer Beitritt usw.), eine Momentaufnahme des aktuellen Tabellenzustands an alle anderen Silos. Da die Mitgliedschaftstabelle konsistent und monoton versioniert ist, erzeugt jedes Update eine eindeutig versionsierte Momentaufnahme, die sicher geteilt werden kann. Dies ermöglicht die umgehende Verbreitung von Mitgliedschaftsänderungen, ohne auf den regulären Lesezyklus zu warten. Der regelmäßige Lesevorgang wird weiterhin als Fallbackmechanismus beibehalten, falls die Momentaufnahmeverteilung fehlschlägt.
Sortierte Mitgliedschaftsansichten: Das Mitgliedschaftsprotokoll stellt sicher, dass alle Mitgliedschaftskonfigurationen global vollständig sortiert sind. Diese Sortierung bietet zwei wichtige Vorteile:
1. Garantierte Konnektivität: Wenn ein neues Silo dem Cluster beitritt, muss es die bidirektionale Konnektivität zu jedem anderen aktiven Silo validieren. Wenn ein bestehendes Silo nicht reagiert (möglicherweise ein Netzwerkverbindungsproblem angibt), darf der neue Silo nicht beitreten. Dadurch wird die vollständige Verbindung zwischen allen Silos im Cluster beim Start sichergestellt. Siehe den untenstehenden Hinweis IAmAlive für eine Ausnahme in Notfallwiederherstellungsszenarien.
2. Konsistente Verzeichnisaktualisierungen: Protokolle auf höherer Ebene, z. B. das verteilte Getreideverzeichnis, basieren auf allen Silos mit einer konsistenten, monotonen Ansicht der Mitgliedschaft. Dies ermöglicht eine intelligentere Auflösung doppelter Grain-Aktivierungen. Weitere Informationen finden Sie in der Grain-Verzeichnisdokumentation .
Implementierungsdetails:
1. Die IMembershipTable erfordert atomare Aktualisierungen, um eine globale Gesamtreihenfolge von Änderungen zu gewährleisten.
  - Implementierungen müssen sowohl die Tabelleneinträge (Liste der Silos) als auch die Versionsnummer atomar aktualisieren.
  - Verwenden Sie dazu Datenbanktransaktionen (wie in SQL Server) oder atomische Vergleichs- und Swapvorgänge mithilfe von ETags (wie in Azure Table Storage).
  - Der spezifische Mechanismus hängt von den Funktionen des zugrunde liegenden Speichersystems ab.
2. Eine spezielle Mitgliedschaftsversion-Zeile in der Tabelle verzeichnet Änderungen.
  - Jeder Eintrag in die Tabelle (Verdacht, Toderklärungen, Zusammenführungen) erhöht diese Versionsnummer.
  - Alle Schreibvorgänge werden mithilfe von Atomaktualisierungen durch diese Zeile serialisiert.
  - Die monoton zunehmende Version sorgt für eine Gesamtordnung aller Mitgliedschaftsänderungen.
3. Wenn Silo S den Status von Silo P aktualisiert:
  - S liest zuerst den aktuellen Tabellenstatus.
  - Bei einem einzelnen atomischen Vorgang werden sowohl die Zeile von P aktualisiert als auch die Versionsnummer erhöht.
  - Wenn das Atomupdate fehlschlägt (z. B. aufgrund gleichzeitiger Änderungen), wird der Vorgang mit exponentieller Verzögerung erneut ausgeführt.
Überlegungen zur Skalierbarkeit:

Durch die Serialisierung aller Schreibvorgänge über die Versionszeile kann die Skalierbarkeit aufgrund erhöhter Konkurrenz beeinträchtigt werden. Das Protokoll hat sich bei der Produktion mit bis zu 200 Silos bewährt, könnte aber vor Herausforderungen stehen, die über tausend Silos hinausgehen. Bei sehr großen Bereitstellungen bleiben andere Teile von Orleans (Messaging, Grain Directory, Hosting) auch dann skalierbar, wenn Mitgliedschaftsupdates zu einem Engpass werden.
Standardkonfiguration: Die Standardkonfiguration wurde unter Produktionsbedingungen in Azure manuell optimiert. Standardmäßig wird jeder Silo von drei anderen Silos überwacht, zwei Verdachtsmomente genügen, um einen Silo als tot zu erklären, und Verdachtsmomente werden nur aus den letzten drei Minuten berücksichtigt (andernfalls sind sie veraltet). Sonden werden alle zehn Sekunden gesendet, und Sie müssen drei Sonden verpassen, um einen Silo zu vermuten.
Selbstüberwachung: Der Fehlerdetektor umfasst Ideen aus der HashiCorp-Lifeguard-Forschung (Dokument, Vortrag, Blog) zur Verbesserung der Clusterstabilität während katastrophaler Ereignisse, bei denen ein großer Teil des Clusters teilweise ausfällt. Die LocalSiloHealthMonitor-Komponente bewertet die Integrität jedes Silos anhand mehrerer Heuristiken:
- Aktiver Status in der Mitgliederübersicht
- Keine Verdachtsfälle aus anderen Silos
- Letzte erfolgreiche Testantworten
- Zuletzt empfangene Testanforderungen
- Reaktionsfähigkeit des Thread-Pools (Arbeitsaufgaben, die innerhalb einer Sekunde ausgeführt werden)
- Timer-Genauigkeit (Auslösung innerhalb von 3 Sekunden nach Zeitplan)
Die Integritätsbewertung eines Silos wirkt sich auf seine Test-Timeouts aus: ungesunde Silos (Punktzahl 1-8) haben im Vergleich zu gesunden Silos (Punktzahl 0) längere Timeouts. Dies bietet zwei Vorteile:
- Gibt den Sonden mehr Zeit, erfolgreich abzuschließen, wenn das Netzwerk oder System unter Stress steht.
- Macht es wahrscheinlicher, dass ungesunde Silos totgewählt werden, bevor sie fälschlicherweise gesunde Silos auswählen können.
Dies ist besonders wertvoll in Szenarien wie dem Mangel an Thread-Pools, wo langsame Knoten sonst fälschlicherweise gesunde Knoten unter Verdacht stellen könnten, nur weil sie Antworten nicht schnell genug verarbeiten können.
Indirektes Probing: Ein weiteres lifeguard-inspiriertes Feature verbessert die Fehlererkennungsgenauigkeit, indem die Wahrscheinlichkeit reduziert wird, dass ein ungesundes oder partitioniertes Silo fälschlicherweise ein gesundes Silo tot erklärt. Wenn ein Überwachungssilo noch zwei Testversuche für ein Zielsilo hat, bevor darüber abgestimmt wird, ob es für inaktiv erklärt werden soll, wird indirektes Testen verwendet:
- Das Überwachungssilo wählt zufällig ein anderes Silo als Vermittler aus und fordert es auf, das Ziel zu überprüfen.
- Der Zwischenhändler versucht, Kontakt mit dem Zielsilo aufzunehmen.
- Wenn das Ziel nicht innerhalb des Timeoutzeitraums reagiert, sendet der Vermittler eine negative Bestätigung.
- Wenn das Überwachungssilo eine negative Bestätigung des Vermittlers erhält und der Vermittler sich selbst gesund erklärt (durch Selbstüberwachung, wie oben beschrieben), gibt das Überwachungssilo eine Abstimmung ab, um das Ziel als tot zu erklären.
- Mit der Standardkonfiguration von zwei erforderlichen Stimmen zählt eine negative Bestätigung einer indirekten Probe als beide Stimmen, was eine schnellere Deklaration von toten Silos ermöglicht, wenn mehrere Perspektiven den Fehler bestätigen.
Erzwingen der perfekten Fehlererkennung: Sobald ein Silo in der Tabelle tot erklärt wurde, betrachtet jeder es als tot, auch wenn es nicht wirklich tot ist (z. B. nur vorübergehend partitioniert ist oder Taktnachrichten verloren gegangen sind). Jeder hört auf, damit zu kommunizieren. Sobald das Silo lernt, dass es tot ist (indem er seinen neuen Status aus der Tabelle liest), beendet er seinen Prozess. Folglich muss eine Infrastruktur eingerichtet sein, um das Silo als neuen Prozess neu zu starten (eine neue Epochenzahl wird zu Beginn generiert). Wenn sie in Azure gehostet wird, geschieht dies automatisch. Andernfalls ist eine andere Infrastruktur erforderlich, z. B. ein Windows-Dienst, der für den automatischen Neustart bei Einem Ausfall oder eine Kubernetes-Bereitstellung konfiguriert ist.
Was geschieht, wenn auf die Tabelle einige Zeit nicht zugegriffen werden kann:

Wenn der Speicherdienst nicht verfügbar ist oder Kommunikationsprobleme auftreten, deklariert das Orleans Protokoll nicht versehentlich Silos tot. Betriebssilos funktionieren ohne Probleme weiter. Orleans kann jedoch ein totes Silo nicht markieren (wenn es ein totes Silo über verpasste Proben erkennt, kann es diese Information nicht in die Tabelle schreiben) und kann keine neuen Silos beitreten lassen. Die Vollständigkeit leidet also, aber die Genauigkeit nicht – durch die Trennung von der Tabelle wird niemals fälschlicherweise festgestellt, dass ein Silo tot ist. Außerdem kann in einer teilweisen Netzwerkpartition (bei der einige Silos auf die Tabelle zugreifen können und andere nicht) Orleans möglicherweise ein Silo für tot erklären, aber es dauert eine Weile, bis alle anderen Silos davon Kenntnis nehmen. Die Erkennung kann verzögert werden, aber Orleans tötet niemals ein Silo aufgrund fehlender Tabellenverfügbarkeit.
IAmAlive Schreibt für Diagnose und Notfallwiederherstellung:

Zusätzlich zu Herzschlägen, die zwischen Silos gesendet werden, aktualisiert jedes Silo regelmäßig einen "I Am Alive"-Zeitstempel in seiner Tabellenzeile. Dies dient zwei Zwecken:
1. Diagnose: Bietet Systemadministratoren eine einfache Möglichkeit, die Cluster-Liveität zu überprüfen und zu bestimmen, wann ein Silo zuletzt aktiv war. Der Zeitstempel wird in der Regel alle 5 Minuten aktualisiert.
2. Notfallwiederherstellung: Wenn ein Silo den Zeitstempel für mehrere Zeiträume (konfiguriert über NumMissedTableIAmAliveLimit) nicht aktualisiert hat, ignorieren neue Silos sie während der Startkonnektivitätsprüfungen. Dadurch kann der Cluster aus Szenarien wiederhergestellt werden, in denen Silos ohne ordnungsgemäße Bereinigung abgestürzt sind.

Mitgliedschaftstabelle

Wie erwähnt dient IMembershipTable als Treffpunkt für Silos, um einander zu finden, und für Orleans Kunden, um Silos zu finden. Sie hilft auch bei der Koordinierung der Vereinbarung über die Mitgliedschaftsansicht. Das Haupt-Repository Orleans enthält Implementierungen für viele Systeme, darunter Azure Table Storage, Azure Cosmos DB, PostgreSQL, MySQL/MariaDB, SQL Server, Apache ZooKeeper, Consul IO, Apache Cassandra, MongoDB, Redis, AWS TableDB und eine In-Memory-Implementierung für die Entwicklung.

Azure Table Storage: In dieser Implementierung dient die Azure-Bereitstellungs-ID als Partitionsschlüssel, und die Siloidentität (ip:port:epoch) fungiert als Zeilenschlüssel. Gemeinsam garantieren sie einen einzigartigen Schlüssel pro Silo. Für die Parallelitätskontrolle wird eine optimistische Parallelitätskontrolle basierend auf Azure Table ETags verwendet. Jedes Mal, wenn Daten aus der Tabelle gelesen werden, wird das ETag für jede gelesene Zeile gespeichert und beim Versuch, zurückzuschreiben, verwendet. Der Azure Table-Dienst weist ETags automatisch jedem Schreibvorgang zu und überprüft diese. Bei Transaktionen mit mehreren Zeilen wird die Unterstützung für Batchtransaktionen verwendet, die von Azure Table bereitgestellt werden , um serialisierbare Transaktionen über Zeilen mit demselben Partitionsschlüssel zu garantieren.
SQL Server: In dieser Implementierung unterscheidet die konfigurierte Bereitstellungs-ID zwischen Bereitstellungen und welchen Silos zu welchen Bereitstellungen gehören. Die Siloidentität wird als Kombination von deploymentID, ip, port, epoch in entsprechenden Tabellen und Spalten definiert. Das relationale Back-End verwendet optimistische Parallelitätssteuerung und Transaktionen, ähnlich wie die Verwendung von ETags in der Azure-Tabellenimplementierung. Die relationale Implementierung erwartet, dass das Datenbankmodul das ETag generiert. Für SQL Server 2000 wird das generierte ETag von einem Aufruf an NEWID()abgerufen. In SQL Server 2005 und höher wird ROWVERSION verwendet. Orleans liest und schreibt relationale ETags als opake VARBINARY(16)-Tags und speichert sie als base64-codierte Zeichenfolgen im Arbeitsspeicher. Orleans unterstützt Mehrzeileneinfügungen mit UNION ALL (für Oracle, einschließlich DUAL), die zurzeit zum Einfügen von Statistikdaten verwendet werden. Die genaue Implementierung und Begründung für SQL Server finden Sie unter CreateOrleansTables_SqlServer.sql.
Apache ZooKeeper: In dieser Implementierung wird die konfigurierte Bereitstellungs-ID als Stammknoten und die Siloidentität (ip:port@epoch) als untergeordneter Knoten verwendet. Gemeinsam garantieren sie einen einzigartigen Weg pro Silo. Bei der Nebenläufigkeitssteuerung wird optimistische Nebenläufigkeitssteuerung basierend auf der Knotenversion verwendet. Jedes Mal, wenn Daten aus dem Bereitstellungsstammknoten gelesen werden, wird die Version für jeden gelesenen untergeordneten Siloknoten gespeichert und verwendet, wenn versucht wird, zurückzuschreiben. Jedes Mal, wenn sich die Daten eines Knotens ändern, erhöht der ZooKeeper-Dienst atomisch die Versionsnummer. Bei Transaktionen mit mehreren Zeilen wird die Multi-Methode verwendet, um serialisierbare Transaktionen über Siloknoten mit demselben übergeordneten Bereitstellungs-ID-Knoten zu gewährleisten.
Konsul IO: Der Schlüssel-/Wertspeicher des Konsuls wurde verwendet, um die Mitgliedschaftstabelle zu implementieren. Weitere Details finden Sie unter Consul Deployment .
AWS DynamoDB: In dieser Implementierung wird die Clusterbereitstellungs-ID als Partitionsschlüssel und Silo-Identität (ip-port-generation) als Range-Key verwendet, wodurch der Datensatz eindeutig wird. Die optimistische Nebenläufigkeit wird mithilfe des ETag Attributs erreicht, indem bedingte Schreibvorgänge auf DynamoDB vorgenommen werden. Die Implementierungslogik ist der von Azure Table Storage sehr ähnlich.
Apache Cassandra: In dieser Implementierung dient die Kombination aus Dienst-ID und Cluster-ID als Partitionsschlüssel und der Siloidentität (ip:port:epoch) als Zeilenschlüssel. Gemeinsam garantieren sie eine einzigartige Reihe pro Silo. Für die Nebenläufigkeitskontrolle wird die optimistische Nebenläufigkeitskontrolle basierend auf einer statischen Spaltenversion mit einer Lightweight-Transaktion verwendet. Diese Versionsspalte wird für alle Zeilen in der Partition/des Clusters freigegeben und stellt eine konsistente inkrementierende Versionsnummer für die Mitgliedschaftstabelle jedes Clusters bereit. In dieser Implementierung gibt es keine Transaktionen mit mehreren Zeilen.
In-Memory-Emulation für die Entwicklungsumgebung: Für diese Implementierung wird eine spezielle Systemkomponente verwendet. Dieses Grain existiert in einem bestimmten primären Silo, das nur für ein Entwicklungssetup verwendet wird. In jedem realen Produktionseinsatz ist kein primärer Silo erforderlich.

Entwurfskonzept

Eine naheliegende Frage wäre, warum man sich nicht vollständig auf Apache ZooKeeper oder etcd für die Implementierung der Clustermitgliedschaft verlässt, indem man möglicherweise ZooKeepers out-of-the-box-Unterstützung für die Gruppenmitgliedschaft mit ephemeren Knoten verwendet. Warum implementieren Sie unser Mitgliedschaftsprotokoll? Dafür gab es in erster Linie drei Gründe:

Bereitstellung/Hosting in der Cloud:

Zookeeper ist kein gehosteter Dienst. Dies bedeutet, Orleans dass Kunden in einer Cloudumgebung ihre Instanz eines ZK-Clusters bereitstellen, ausführen und verwalten müssen. Dies ist eine unnötige Belastung, die nicht für Kunden erzwungen wurde. Durch die Nutzung von Azure Table Orleans wird auf einen gehosteten, verwalteten Dienst zurückgegriffen, wodurch das Leben der Kunden erheblich vereinfacht wird. Im Grunde sollten Sie in der Cloud die Cloud als Plattform nutzen, nicht als Infrastruktur. Andererseits, wenn Sie lokal arbeiten und Ihre Server verwalten, ist die Verwendung von ZK als Implementierung von IMembershipTable eine praktikable Option.
Direkte Fehlererkennung:

Beim Verwenden der Gruppenmitgliedschaft von ZK mit ephemeralen Knoten erfolgt die Fehlererkennung zwischen Orleans-Servern (ZK-Clients) und ZK-Servern. Dies korreliert möglicherweise nicht unbedingt mit tatsächlichen Netzwerkproblemen zwischen Orleans Servern. Der Wunsch war, dass die Fehlererkennung den Kommunikationszustand innerhalb des Clusters genau widerspiegelt. Wenn ein Orleans Silo nicht mit IMembershipTablediesem Design kommunizieren kann, wird er nicht als tot betrachtet und kann weiterarbeiten. Im Gegensatz dazu, wenn die ZK-Gruppenmitgliedschaft mit kurzlebigen Knoten verwendet würde, könnte eine Trennung von einem ZK-Server dazu führen, dass ein Orleans Silo (ZK-Client) als tot deklariert wird, obwohl es lebendig und voll funktionsfähig ist.
Portabilität und Flexibilität:

Im Rahmen der Philosophie von Orleans erzwingt Orleans keine starke Abhängigkeit von einer bestimmten Technologie, sondern bietet vielmehr ein flexibles Design, bei dem unterschiedliche Komponenten problemlos mit verschiedenen Implementierungen ausgetauscht werden können. Dies ist genau der Zweck, den die IMembershipTable Abstraktion dient.

Eigenschaften des Mitgliedschaftsprotokolls

Kann eine beliebige Anzahl von Fehlern behandeln:

Dieser Algorithmus kann eine beliebige Anzahl von Fehlern (f<=n) verarbeiten, einschließlich des vollständigen Clusterneustarts. Dies steht im Gegensatz zu "traditionellen" Paxos-basierten Lösungen, die ein Quorum erfordern (in der Regel eine Mehrheit). Produktionssituationen haben Szenarien gezeigt, in denen mehr als die Hälfte der Silos abstürzte. Dieses System blieb funktionsfähig, während die Mitgliedschaft auf der Grundlage von Paxos keine Fortschritte machen konnte.
Datenverkehr an die Tabelle ist sehr niedrig:

Tatsächliche Messpunkte gehen direkt zwischen die Server, nicht zur Tabelle. Routingsonden über die Tabelle würden einen erheblichen Datenverkehr generieren und aus einer Fehlererkennungsperspektive weniger genau sein – wenn ein Silo die Tabelle nicht erreichen konnte, würde es das Schreiben seines Takts "Ich bin am Leben" verpassen, und andere würden ihn tot deklarieren.
Optimierbare Genauigkeit im Vergleich zu Vollständigkeit:

Sie können zwar nicht sowohl die perfekte als auch die genaue Fehlererkennung erreichen, aber sie möchten in der Regel die Möglichkeit haben, die Genauigkeit abzuhandeln (nicht möchten, dass ein lebender Silo tot deklariert werden soll) mit Vollständigkeit (wenn Sie einen toten Silo so schnell wie möglich deklarieren möchten). Die konfigurierbaren Stimmen zum Deklarieren von toten und verpassten Proben ermöglichen den Austausch dieser beiden Aspekte. Weitere Informationen finden Sie unter Yale University: Computer Science Failure Detectors.
Skalieren:

Das Protokoll kann tausende, wahrscheinlich sogar Zehntausende von Servern verarbeiten. Dies steht im Gegensatz zu herkömmlichen Paxos-basierten Lösungen wie Gruppenkommunikationsprotokollen, die bekanntermaßen nicht über zehn Knoten hinaus skaliert werden.
Diagnosen:

Die Tabelle ist auch sehr praktisch für Diagnosen und Problembehandlungen. Systemadministratoren können sofort die aktuelle Liste der lebendigen Silos in der Tabelle finden sowie die Geschichte aller getöteten Silos und Verdächtigungen sehen. Dies ist besonders nützlich bei der Diagnose von Problemen.
Warum ist zuverlässiger persistenter Speicher für die Implementierung von IMembershipTable:

Beständiger Speicher wird für IMembershipTable zu zwei Zwecken verwendet. Erstens dient es als Treffpunkt für Silos, sich zu finden, und damit Orleans Kunden Silos finden können. Zweitens hilft zuverlässige Speicherung bei der Koordinierung der Vereinbarung über die Mitgliedschaftsansicht. Während die Fehlererkennung direkt peer-to-peer zwischen Silos auftritt, wird die Mitgliedsansicht im zuverlässigen Speicher gespeichert, und der von diesem Speicher bereitgestellte Parallelitätskontrollmechanismus wird verwendet, um eine Vereinbarung darüber zu erreichen, wer lebt und wer tot ist. In einem Sinne überlagert dieses Protokoll das schwierige Problem des verteilten Konsenses an die Cloud aus. Dabei wird die volle Leistungsfähigkeit der zugrunde liegenden Cloudplattform genutzt, wobei sie wirklich als Platform as a Service (PaaS) verwendet wird.
Direktes IAmAlive Schreiben in die Tabelle nur zu Diagnosezwecken:

Zusätzlich zu Herzschlägen, die zwischen Silos gesendet werden, aktualisiert jedes Silo in regelmäßigen Abständen eine Spalte "Ich bin am Leben" in seiner Tabellenzeile. Diese Spalte "I Am Alive" wird nur für manuelle Problembehandlung und Diagnose verwendet und wird nicht vom Mitgliedschaftsprotokoll selbst verwendet. Es wird in der Regel mit einer viel niedrigeren Häufigkeit (einmal alle 5 Minuten) geschrieben und dient als sehr nützliches Tool für Systemadministratoren, um die Liveität des Clusters zu überprüfen oder leicht herauszufinden, wann das Silo zuletzt lebendig war.

Danksagung

Anerkennung für den Beitrag von Alex Kogan zur Gestaltung und Implementierung der ersten Version dieses Protokolls. Diese Arbeit wurde im Rahmen eines Sommerpraktikums bei Microsoft Research im Sommer 2011 durchgeführt. Die Implementierung von ZooKeeper IMembershipTable wurde von Shay Hazor durchgeführt, die Implementierung von SQL IMembershipTable wurde von Veikko Eeva durchgeführt, die Implementierung von AWS DynamoDB IMembershipTable wurde von Gutemberg Ribeiro durchgeführt, die Implementierung von Consul IMembershipTable wurde von Paul North durchgeführt, und schließlich wurde die Implementierung des Apache Cassandra IMembershipTable basierend auf OrleansCassandraUtils von Arshia001 angepasst.