Katalogserverquorum

Wenn der Quorummechanismus aktiviert ist, müssen alle Katalogserver im Quorum verfügbar sein, damit Verteilungsoperationen im Datengrid stattfinden können.

Wichtige Begriffe

Überwachungssignale und Fehlererkennung

Container-Server und Stammgruppen

Der Katalogservice verteilt Container-Server auf Stammgruppen begrenzter Größe. Eine Stammgruppe versucht, den Ausfall ihrer Member zu erkennen. Ein einziges Member jeder Stammgruppe wird als führendes Member der Stammgruppe bestimmt. Das führende Member der Stammgruppe teilt dem Katalogservice in regelmäßigen Abständen den Aktivitätsstatus der Stammgruppe und alle Änderungen der Stammgruppenzugehörigkeiten mit. Eine Zugehörigkeitsänderung kann beispielsweise der Ausfall einer JVM oder das Hinzufügen einer neuen JVM sein, die in die Stammgruppe aufgenommen wird.

Wenn der Socket einer JVM geschlossen wird, wird diese JVM als nicht mehr verfügbar eingestuft. Außerdem sendet jedes Member der Stammgruppe in einem in der Konfiguration festgelegten Intervall Überwachungssignale über diese Sockets. Wenn eine JVM nicht innerhalb eines konfigurierten maximalen Zeitraums auf diese Überwachungssignale reagiert, wird die JVM als nicht mehr verfügbar eingestuft, woraufhin eine Fehlererkennung ausgelöst wird.

Wenn der Katalogservice eine Container-JVM als ausgefallen markiert und der Container-Server später als wieder verfügbar gemeldet wird, wird die Container-JVM angewiesen, die Container-Server von WebSphere eXtreme Scale zu beenden. Eine JVM in diesem Status ist in den Befehlsabfragen des Dienstprogramms xscmd nicht sichtbar. Die Nachrichten in den Protokollen der Container-JVM weisen darauf hin, dass die Container-JVM ausgefallen ist. Sie müssen diese JVM manuell erneut starten.

Wenn das führende Member der Stammgruppe zu einem Member eine Verbindung herstellen kann, setzt das führende Member seine Versuche, die Verbindung zu diesem Member herzustellen, fort.

Der vollständige Ausfall aller Member einer Stammgruppe ist auch möglich. Wenn die vollständige Stammgruppe ausfällt, muss der Katalogservice diesen Verlust erkennen.

Austausch von Überwachungssignalen in einer Katalogservicedomäne

Die Katalogservicedomäne gleicht einer privaten Stammgruppe mit einer statischen Zugehörigkeit und einem Quorummechanismus. Sie erkennt Ausfälle auf dieselbe Weise wie eine normale Stammgruppe. Das Verhalten ist jedoch anders und umfasst eine Quorum-Logik. Außerdem verwendet der Katalogservice eine weniger aggressive Konfiguration für den Austausch von Überwachungssignalen.

Ausfallerkennung

WebSphere eXtreme Scale erkennt, wenn Prozesse durch abnormale Socketschließungen beendet werden. Der Katalogservice wird sofort benachrichtigt, wenn ein Prozess beendet wird.

Weitere Einzelheiten zum Konfigurieren des Austauschs von Überwachungssignalen finden Sie in Einstellung für das Intervall der Überwachungssignale für Failover-Erkennung optimieren.

Quorumverhalten

Normalerweise haben die Member des Katalogservice vollständige Konnektivität. Die Katalogservicedomäne ist eine statische Gruppe von JVMs. WebSphere eXtreme Scale erwartet, dass alle Member des Katalogservice online sind. Wenn alle Member online sind, hat der Katalogservice das Quorum. Der Katalogservice reagiert nur auf Containerereignisse, wenn der Katalogservice das Quorum hat.

Ursache für Quorumverlust

WebSphere eXtreme Scale erwartet in den folgenden Szenarien einen Quorumverlust:

  • Das Member mit der Katalogservice-JVM fällt aus.
  • Es tritt ein Netz-Brownout ein.
  • Es tritt ein Ausfall des Rechenzentrums ein.
WebSphere eXtreme Scale verliert das Quorum im folgenden Szenario nicht:
  • Eine Katalogserverinstanz wird mit dem Befehl stopOgServer oder einer anderen Verwaltungsaktion gestoppt. Das System weiß, dass die Serverinstanz gestoppt wurde, was bei einem JVM-Fehler oder Brownout anders ist.

Verliert der Katalogservice ein Quorum, wartet er, bis das Quorum wiederhergestellt ist. Während der Katalogservice kein Quorum hat, ignoriert er Ereignisse von Container-Servern. Container-Server wiederholen alle Anforderungen, die vom Katalogserver in der Zeit zurückgewiesen werden. Der Austausch von Überwachungssignalen wird ausgesetzt, bis das Quorum wiederhergestellt ist.

Quorumverlust nach JVM-Ausfall

Ein Katalogserver, der ausfällt, führt zu einem Quorum-Verlust. Wenn eine JVM ausfällt, müssen Sie das Quorum so schnell wie möglich wiederherstellen. Ein ausgefallener Katalogservice kann dem Datengrid erst dann wieder beitreten, wenn das Quorum wiederhergestellt ist.

Quorumverlust aufgrund eines Netz-Brownouts

WebSphere eXtreme Scale ist auf die Möglichkeit von Brownouts vorbereitet. Ein Brownout ist ein temporärer Verlust der Konnektivität zwischen Rechenzentren. Brownouts sind gewöhnlich transient und innerhalb von Sekunden oder Minuten bereinigt. WebSphere eXtreme Scale versucht während eines Brownouts den normalen Betrieb aufrecht zu erhalten. Ein Brownout wird als einzelnes Fehlereignis betrachtet. Es wird davon ausgegangen, dass der Fehler behoben und der normale Betrieb anschließend fortgesetzt wird, ohne dass Aktionen von erforderlich sind.

Ein langer Brownout kann nur durch Benutzereingriff als Blackout klassifiziert werden. Das Quorum muss auf einer Seite des Brownouts wiederhergestellt werden, damit das Ereignis als als Blackout klassifiziert werden kann.

JVM des Katalogservice stoppen und erneut starten

Wenn ein Katalogserver mit dem Befehl stopOgServer gestoppt wird, sinkt das Quorum um einen Server. Die verbleibenden Server haben weiterhin das Quorum. Bei einem Neustart des Katalogservers steigt das Quorum wieder auf die vorherige Zahl.

Konsequenzen eines Quorum-Verlusts

Wenn eine Container-JVM ausfällt und das Quorum verloren gegangen ist, findet erst dann eine Wiederherstellung statt, wenn die Brownout-Bedingung behoben ist. In einem Blackout-Szenario findet die Wiederherstellung erst statt, wenn Sie den Befehl zum Überschreiben des Quorums ausführen. Der Quorumverlust und eine Containerausfall werden als doppelter Fehler gewertet, was aber nur selten vorkommt. Aufgrund des doppelten Fehlers können Anwendungen den Schreibzugriff auf Daten verlieren, die in der ausgefallenen JVM gespeichert waren. Wenn das Quorum wiederhergestellt ist, findet die normale Wiederherstellung statt.

Wenn Sie versuchen, einen Container zu starten, während das Quorum verloren ist, wird der Container nicht gestartet.

Während eines Quorum-Verlusts ist eine vollständige Clientkonnektivität zulässig. Wenn während des Quorum-Verlusts keine Containerausfälle oder Konnektivitätsprobleme auftreten, können die Clients weiterhin vollständig mit den Container-Servern interagieren.

Wenn ein Brownout auftritt, haben einige Clients möglicherweise erst dann wieder Zugriff auf die primären Kopieren oder Replikatkopien der Daten, wenn die Brownout-Bedingung behoben ist.

Neue Clients können gestartet werden, weil eine Katalogservice-JVM in jedem Rechenzentrum vorhanden sein muss. Deshalb kann selbst während eines Brownouts mindestens ein Katalogserver von einem Client erreicht werden.

Wiederherstellung des Quorums

Wenn das Quorum aus irgendeinem Grund verloren geht, wird zur Wiederherstellung des Quorums ein Wiederherstellungsprotokoll ausgeführt. Beim Verlust des Quorums wird die Aktivitätsprüfung für die Stammgruppen ausgesetzt, und alle Ausfallberichte werden ignoriert. Nach der Wiederherstellung des Quorums überprüft der Katalogservice alle Stammgruppen, um deren Zugehörigkeit unverzüglich zu bestimmen. Alle zuvor in Container-JVMs gehosteten Shards, die als ausgefallen gemeldet wurden, werden wiederhergestellt. Wenn primäre Shards verloren gegangen sind, werden die noch aktiven Replikate zu primären Shards hochgestuft. Wenn Replikat-Shards verloren gegangen sind, werden zusätzliche Replikate in den noch aktiven JVMs erstellt.

Quorum überschreiben

Das Quorum sollte überschrieben werden, wenn ein Rechenzentrum ausfällt. Ein Quorumverlust aufgrund des Ausfalls einer Container-Service-JVM oder eines Netz-Brownouts wird automatisch behoben, sobald die Katalogservice-JVM erneut gestartet bzw. das Netz-Brownout behoben ist.

Nur Administratoren haben Kenntnis von einem Ausfall eines Rechenzentrums. WebSphere eXtreme Scale behandelt Brownouts und Blackouts ähnlich. Sie müssen die Umgebung von WebSphere eXtreme Scale über solche Ausfälle mit dem Befehl xscmd -c overrideQuorum informieren. Auf diese Weise wird dem Katalogservice mitgeteilt, davon auszugehen, dass das Quorum mit den aktuellen Zugehörigkeiten erreicht ist und eine vollständige Wiederherstellung stattfindet. Wenn Sie einen Befehl zum Überschreiben des Quorums absetzen, bestätigen Sie, dass die JVMs im ausgefallenen Rechenzentrum wirklich ausgefallen sind und nicht wiederhergestellt werden.

In der folgenden Liste sind einige Szenarien für das Überschreiben des Quorums beschrieben. In diesem Szenario haben Sie drei Katalogserver: A, B und C.
  • Brownout: Der Katalogserver C wird vorübergehend isoliert. Der Katalogservice verliert das Quorum und wartet auf die Behebung des Brownouts. Nach Behebung des Brownout wird der Katalogserver C wieder in die Katalogservicedomäne eingebunden, und das Quorum wird wiederhergestellt. Ihre Anwendung stellt während dieser Zeit keine Probleme fest.
  • Temporärer Ausfall: Während eines temporären Ausfalls fällt der Katalogserver C aus, und der Katalogservice verliert das Quorum. Sie müssen das Quorum überschreiben. Nach der Wiederherstellung des Quorums können Sie den Katalogserver C erneut starten. Der Katalogserver C wird nach dem Neustart wieder in die Katalogservicedomäne eingebunden. Ihre Anwendung stellt während dieser Zeit keine Probleme fest.
  • Ausfall eines Rechenzentrums: Sie verifizieren, dass das Rechenzentrum wirklich ausgefallen und vom Netz isoliert ist. Anschließend setzen Sie den Befehl xscmd -c overrideQuorum ab. Die anderen beiden noch aktiven Rechenzentren führen eine vollständige Wiederherstellung durch, indem sie Shards, die sich im ausgefallenen Rechenzentrum befinden, ersetzen. Der Katalogservice wird jetzt mit vollständigem Quorum der Katalogserver A und B ausgeführt. Die Anwendung kann Verzögerungen oder Ausnahmen während des Zeitraums zwischen dem Start des Blackouts und Überschreiben des Quorums feststellen. Nach dem Überschreiben des Quorums wird das Datengrid wiederhergestellt, und der normale Betrieb wird fortgesetzt.
  • Wiederherstellung des Rechenzentrums: Die noch aktiven Rechenzentren werden bereits mit überschriebenem Quorum ausgeführt. Wenn das Rechenzentrum, in dem Katalogserver C enthalten ist, erneut gestartet wird, müssen alle JVMs im Rechenzentrum erneut gestartet werden. Anschließend wird Katalogserver C wieder in die vorhandene Katalogservicedomäne eingebunden, und das Quorum wird ohne Benutzereingriff wiederhergestellt.
  • Ausfall des Rechenzentrums und Brownout: Das Rechenzentrum, das den Katalogserver C enthält, fällt aus. Das Quorum wird überschrieben und in den verbleibenden Rechenzentren wiederhergestellt. Wenn ein Brownout zwischen den Katalogservern A und B auftritt, werden die normalen Wiederherstellungsregeln bei Brownouts angewendet. Nach der Behebung des Brownouts wird das Quorum wiederhergestellt, und die erforderliche Wiederherstellung nach einem Quorum-Verlust findet statt.

Containerverhalten während des Quorumverlusts

Container enthalten einen oder mehrere Shards. Shards sind primäre Kopien oder Replikatkopien für eine bestimmte Partition. Der Katalogservice ordnet Shards einem Container zu, und der Container berücksichtigt diese Zuordnung so lange, bis er neue Anweisungen vom Katalogservice erhält. Ein primäres Shard setzt seine Kommunikationsversuche mit seinen Replikat-Shards beispielsweise während Netz-Brownouts fort, bis der Katalogservice dem primären Shard weitere Anweisungen bereitstellt.

Verhalten synchroner Replikate

Das primäre Shard kann neue Transaktionen akzeptieren, während die Verbindung unterbrochen ist, wenn die Anzahl der Online-Replikate mindestens so hoch ist wie der Wert der Eigenschaft minsync für das MapSet. Wenn neue Transaktionen im primären Shard verarbeitet werden, während die Verbindung zum synchronen Replikat unterbrochen ist, wird der Replikatinhalt gelöscht und nach Wiederherstellung der Verbindung mit dem aktuellen Status des primären Shards synchronisiert.

Die synchrone Replikation zwischen Rechenzentren und die synchrone Replikation über WAN-Verbindungen wird nicht empfohlen.

Verhalten asynchroner Replikate

Wenn eine Verbindung unterbrochen ist, kann das primäre Shard neue Transaktionen akzeptieren. Das primäre Shard puffert die Änderungen bis zu einem bestimmten Grenzwert. Wenn die Verbindung mit dem Replikat wiederhergestellt wird, bevor der Grenzwert erreicht ist, wird das Replikat mit den gepufferten Änderungen aktualisiert. Beim Erreichen des Grenzwerts löscht das primäre Shard die gepufferte Liste, und bei der Wiederherstellung der Verbindung zum Replikat wird der Replikatinhalt gelöscht und neu mit dem primären Shard synchronisiert.

Clientverhalten während des Quorumverlusts

Unabhängig davon, ob die Katalogservicedomäne das Quorum hat oder nicht, können Clients für das Bootstrapping des Datengrids immer eine Verbindung zum Katalogserver herstellen. Der Client versucht, eine Verbindung zu einer Katalogserverinstanz herzustellen, um eine Routentabelle anzufordern und anschließend mit dem Datengrid zu interagieren. Die Netzkonnektivität kann die Interaktion des Clients mit einigen Partitionen aufgrund der Netzkonfiguration verhindern. Der Client kann für den Abruf ferner Daten eine Verbindung zu lokalen Replikaten herstellen, sofern er entsprechend konfiguriert ist. Clients können keine Daten aktualisieren, wenn die primäre Partition für diese Daten nicht verfügbar ist.