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.
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.
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.
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.
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.
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.
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.
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.
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 |