Hohe Verfügbarkeit

Mit hoher Verfügbarkeit unterstützt WebSphere eXtreme Scale zuverlässige Datenredundanz und Fehlererkennung.

WebSphere eXtreme Scale organisiert JVM-Datengrids eigenständig in einem losen baumähnlichen Verbund. Der Katalogservice im Stammverzeichnis und die Stammgruppen, die die Container enthalten, sind die Blätter des Baums. Weitere Informationen finden Sie im Abschnitt Caching-Architektur: Maps, Container, Clients und Kataloge.

Jede Stammgruppe wird vom Katalogservice automatisch in Gruppen von ungefähr 20 Servern unterteilt. Die Stammgruppen-Member überwachen die anderen Member der Gruppe auf ihre Vitalität. Außerdem wählt jede Stammgruppe ein Member als führendes Member aus, das für die Kommunikation der Gruppeninformation an den Katalogservice zuständig ist. Eine Begrenzung der Stammgruppengröße sorgt für eine effektive Vitalitätsüberwachung und eine hoch skalierbare Umgebung.
Anmerkung: In einer Umgebung mit WebSphere Application Server, in der die Stammgruppengröße geändert werden kann, unterstützt eXtreme Scale maximal 50 Member pro Stammgruppe.

Austausch von Überwachungssignalen

  1. Sockets werden zwischen Java Virtual Machines bleiben offen, und wenn ein Socket unerwartet geschlossen wird, wird dieses unerwartete Schließen als Fehler von der Peer-JVM erkannt. Bei dieser Erkennung werden Fehlerfälle wie beispielsweise das sehr schnelle Beenden der Java Virtual Machine abgefangen. Außerdem unterstützt dieser Erkennungstyp die Wiederherstellung nach solchen Fehlern in gewöhnlich weniger als einer Sekunde.
  2. Weitere Typen von Fehlern sind Betriebssystempanik, physischer Ausfall eines Servers und Netzfehler. Diese Fehler werden über den Austausch von Überwachungssignalen erkannt.
Überwachungssignale werden in regelmäßigen Abständen von zwei Prozessen ausgetauscht. Wenn eine festgelegte Anzahl an Überwachungssignalen verpasst wird, wird von einem Fehler ausgegangen. Mit diesem Ansatz werden Fehler in N*M Sekunden erkannt. N steht für die Anzahl entgangener Überwachungssignale und M für das Intervall der Überwachungssignale (auch Heartbeatintervall). Die direkte Angabe von M und N wird nicht unterstützt. Es wird ein Reglermechanismus verwendet, damit ein Bereich getesteter M/N-Kombinationen verwendet werden kann.

Fehler

Ein Prozess kann auf verschiedene Arten fehlschlagen. Ein Prozess kann fehlschlagen, weil eine Ressourcengrenze erreicht wurde, wie z. B. die maximale Größe des Heapspeichers, oder weil eine Prozesssteuerungslogik den Prozess beendet hat. Das Betriebssystem kann ausfallen, was dazu führt, dass alle auf dem System ausgeführten Prozesse verloren gehen. Die Hardware, wie z. B. die Netzschnittstellenkarte, kann (wenn auch weniger häufig) ausfallen, was zur Trennung des Betriebssystems vom Netz führen kann. Es gibt viele weitere Fehlerquellen, die die Nichtverfügbarkeit des Prozesses zur Folge haben können. In diesem Kontext können all diese Fehler in zwei Kategorien eingeteilt werden: Prozessfehler und Konnektivitätsverlust.

Prozessfehler

WebSphere eXtreme Scale reagiert schnell auf Prozessfehler. Wenn ein Prozess fehlschlägt, ist das Betriebssystem für die Bereinigung aller übrig gebliebenen Ressourcen verantwortlich, die vom Prozess verwendet wurden. Diese Bereinigung umfasst die Portzuordnung und die Konnektivität. Wenn ein Prozess fehlschlägt, wird ein Signal über die von diesem Prozess verwendeten Verbindungen gesendet, um jede einzelne Verbindung zu schließen. Mit Hilfe dieser Signale kann ein Prozessfehler in kürzester Zeit von einem anderen Prozess, der mit dem fehlgeschlagenen verbunden ist, erkannt werden.

Konnektivitätsverlust

Ein Konnektivitätsverlust tritt auf, wenn die Verbindung des Betriebssystems zum Netz getrennt wird. Infolgedessen kann das Betriebssystem keine Signale an andere Prozesse senden. Es gibt mehrere Gründe für einen Konnektivitätsverlust, die jedoch in zwei Kategorien eingeteilt werden können: Hostausfall und Isolierung.

Hostausfall

Wenn der Netzstecker der Maschine gezogen wird, geht die Konnektivität sofort verloren.

Isolierung

Dieses Szenario stellt die komplizierteste Fehlerbedingung für Software dar. Die Behebung einer solchen Fehlerbedingung stellt sich so schwierig dar, weil davon ausgegangen wird, dass der Prozess nicht verfügbar ist, obwohl dies gar nicht der Fall ist. Für das System scheint ein Server oder ein anderer Prozess ausgefallen zu sein, obwohl er in Wirklichkeit ordnungsgemäß ausgeführt wird.

Containerfehler

Containerausfälle werden im Allgemeinen von Peer-Containern über den Stammgruppenmechanismus erkannt. Wenn ein Container oder eine Gruppe von Containern ausfällt, migriert der Katalogservice die Shards aus den betroffenen Containern. Der Katalogservice sucht zuerst nach einem synchronen Replikat, bevor er die Migration auf ein asynchrones Replikat durchführt. Nach der Migration der primären Shards in die neuen Hostcontainer durchsucht der Katalogservice die neuen Hostcontainer nach den Replikaten, die jetzt fehlen.

Anmerkung: Containerisolierung - Der Katalogservice migriert Shards aus Containern, wenn der Container als nicht verfügbar erkannt wird. Wenn diese Container wieder verfügbar werden, berücksichtigt der Katalogservice sie bei der Verteilung wie beim normalen Startablauf.

Latenzzeit für Erkennung von Containerfehlern

Ausfälle können in die folgenden beiden Kategorien eingeteilt werden: temporäre Ausfälle und permanente Ausfälle. Temporäre Ausfälle werden gewöhnlich durch einen Prozessfehler verursacht. Solche Ausfälle werden vom Betriebssystem erkannt, das genutzte Ressourcen, wie z. B. Netz-Sockets, schnell wiederherstellen kann. Gewöhnlich werden temporäre Ausfälle in weniger als einer Sekunde erkannt. Die Erkennung permanenter Ausfälle kann unter Verwendung der Standardoptimierung für Überwachungssignale bis zu 200 Sekunden dauern. Zu solchen Ausfällen gehören physische Ausfälle von Maschinen, das Ziehen von Netzkabeln und Betriebssystemausfälle. Die Laufzeitumgebung verlässt sich darauf, dass permanente Fehler durch den Austausch von Überwachungssignalen erkannt werden, der konfiguriert werden kann.

Ausfall des Katalogservice

Da das Katalog-Service-Grid ein eXtreme-Scale-Grid ist, wird der Stammgruppenmechanismus auch hier auf dieselbe Weise wie beim Containerausfallprozess verwendet. Der Hauptunterschied besteht darin, dass die Katalogservicedomäne einen Peer-Auswahlprozess für die Definition des primären Shards an Stelle des Katalogservicealgorithmus verwendet, der für die Container verwendet wird.

Der Verteilungsservice und der Stammgruppierungsservice sind Services vom Typ "1 von N" sind, der Positionsservice und die Verwaltung hingegen überall ausgeführt werden. Ein Service vom Typ "1 von N" wird nur in einem einzigen Member der HA-Gruppe ausgeführt. Der Positionsservice und der Verwaltungsservice werden in allen Membern der HA-Gruppe ausgeführt. Der Verteilungsservice und der Stammgruppierungsservice sind Singletons, weil sie für das Layout des Systems verantwortlich sind. Der Positionsservice und die Verwaltung sind Services, die ausschließlich im Lesezugriff arbeiten und zur Unterstützung der Skalierbarkeit überall vorhanden sind.

Der Katalogservice verwendet die Replikation für seine eigene Fehlertoleranz. Wenn ein Katalogserviceprozess fehlschlägt, wird der Service erneut gestartet um das System in einem Zustand wiederherzustellen, der die gewünschte Stufe der Verfügbarkeit bietet. Schlagen alle Prozesse, in denen der Katalogservice ausgeführt wird, fehl, verliert das Datengrid kritische Daten. Dieser Fehler führt zu einem erforderlichen Neustart aller Container-Server. Da der Katalogservice in vielen Prozessen ausgeführt werden kann, ist das Auftreten dieses Fehlers eher unwahrscheinlich. Wenn Sie jedoch alle Prozesse auf einer einzigen Maschine, in einem einzigen Blade-Gehäuse oder über einen einzigen Netz-Switch ausführen, ist die Wahrscheinlich eines Fehlers hoch. Versuchen Sie, bekannte Fehlermodi auf Maschinen, auf denen der Katalogservice ausgeführt wird, zu beseitigen, um die Fehlerwahrscheinlichkeit zu reduzieren.

Mehrere Containerausfälle

Ein Replikat wird niemals in demselben Prozess wie das primäre Shard ausgeführt, da dies beim Verlust des Prozesses zu einem Verlust des primären Shards und des Replikats führen würde. In einer Entwicklungsumgebung auf einer einzigen Maschine können Sie zwei Container verwenden und die Daten des einen Containers im jeweils anderen replizieren. Sie können das Attribut für den Entwicklungsmodus in der Implementierungsrichtlinie definieren, um zu konfigurieren, dass ein Replikat an dieselbe Maschine wie das primäre Shard verteilt wird. In einer Produktionsumgebung reicht die Verwendung einer einzige Maschine jedoch nicht aus, weil ein Verlust dieses Hosts zum Verlust beider Container-Server führt. Zum Wechsel vom Entwicklungsmodus auf einer einzigen Maschine in den Produktionsmodus mit mehreren Maschinen müssen Sie den Entwicklungsmodus in der Konfigurationsdatei der Implementierungsrichtlinie inaktivieren.

Tabelle 1. Zusammenfassung der Fehlererkennung und Wiederherstellung
Verlusttyp Erkennungsmechanismus Wiederherstellungsmethode
Prozessverlust Ein-/Ausgabe Neustart
Serververlust Überwachungssignal Neustart
Netzausfall Überwachungssignal Netz und Verbindung wiederherstellen
Serverseitige Blockierung Überwachungssignal Server stoppen und erneut starten
Server ausgelastet Überwachungssignal Warten, bis Server wieder verfügbar ist