IBM i: Hochverfügbarkeit - Technologien...„Bemerkungen” auf Seite 41 gelesen wer den. Dieses...

IBM iVersion 7 Release 3

VerfügbarkeitHochverfügbarkeit - Technologien

IBM

HinweisVor Verwendung dieser Informationen und des darin beschriebenen Produkts sollten die Informationen unter„Bemerkungen” auf Seite 41 gelesen werden.

Dieses Dokument kann Verweise auf den lizenzierten internen Code enthalten. Lizenzierter interner Code ist Ma-schinencode und wird unter den Bedingungen der IBM Lizenzvereinbarung für Maschinencode lizenziert.

Diese Veröffentlichung ist eine Übersetzung des HandbuchsIBM i Version 7 Release 3, Availability High availability technologies,herausgegeben von International Business Machines Corporation, USA

© Copyright International Business Machines Corporation 2002,, 2015

Informationen, die nur für bestimmte Länder Gültigkeit haben und für Deutschland, Österreich und die Schweiznicht zutreffen, wurden in dieser Veröffentlichung im Originaltext übernommen.

Möglicherweise sind nicht alle in dieser Übersetzung aufgeführten Produkte in Deutschland angekündigt und ver-fügbar; vor Entscheidungen empfiehlt sich der Kontakt mit der zuständigen IBM Geschäftsstelle.

Änderung des Textes bleibt vorbehalten.

Herausgegeben von:TSC GermanyKst. 2877April 2016

© Copyright IBM Corporation 2002, 2015.

Inhaltsverzeichnis

Hochverfügbarkeit - Technologien . . . 1Neuerungen bei IBM i 7.3 . . . . . . . . . . 1PDF-Datei für Hochverfügbarkeit - Technologien . . 2IBM i-Clustertechnologie . . . . . . . . . . 3

Clusterkonzepte . . . . . . . . . . . . 3Clusterknoten . . . . . . . . . . . . 3Clusterressourcengruppe (CRG) . . . . . . 4

Anwendungs-CRG . . . . . . . . . 4Daten-CRG . . . . . . . . . . . . 5Einheiten-CRG. . . . . . . . . . . 5Peer-CRG . . . . . . . . . . . . 5Wiederherstellungsdomäne . . . . . . 6Exitprogramme für Clusterressourcengruppe 7

Clusterversion . . . . . . . . . . . . 8Einheitendomäne . . . . . . . . . . . 9Clusterjobs . . . . . . . . . . . . . 9

Basisclusterfunktionen . . . . . . . . . . 11Heartbeatüberwachung . . . . . . . . 11Zuverlässige Nachrichtenübertragungsfunkti-on . . . . . . . . . . . . . . . 12

Clusterereignisse . . . . . . . . . . . 13Switchover . . . . . . . . . . . . 13Failover . . . . . . . . . . . . . 13

Clusternachrichtenwarteschlange . . . . 14Failover-Nachrichtenwarteschlange . . . 15

Clusterpartition . . . . . . . . . . . 16Zusammenfügung . . . . . . . . . . 16

Beispiel: Zusammenfügung . . . . . . 17Wiederaufnahme . . . . . . . . . . 19

Beispiel: Wiederaufnahme . . . . . . 20Erweiterte Knotenausfallerkennung . . . . . . 21

Clusterverwaltungsdomäne . . . . . . . . . 23PowerHA-Datenreplikationstechnologien . . . . 24

Geographische Spiegelung . . . . . . . . 25Metro Mirror . . . . . . . . . . . . . 26Global Mirror. . . . . . . . . . . . . 26Umschaltbare logische Einheiten . . . . . . 27FlashCopy . . . . . . . . . . . . . . 27DS8000 Full System HyperSwap . . . . . . 27DS8000 HyperSwap mit unabhängigen Zusatz-speicherpools (IASPs) . . . . . . . . . . 28

Verwaltung der Hochverfügbarkeit . . . . . . 28Schnittstellen bei IBM PowerHA SystemMirrorfür i . . . . . . . . . . . . . . . . 28

Grafische Oberfläche von PowerHA . . . . 29PowerHA-Befehle . . . . . . . . . . 29PowerHA-APIs . . . . . . . . . . . 30Richtlinien im High Availability Solutions Ma-nager . . . . . . . . . . . . . . 30

Unterstützung für Versionssteuerung bei IBMPowerHA SystemMirror für i . . . . . . . 32Option 41 (HA Switchable Resources) . . . . 37Hochverfügbarkeitsfunktion im Basisbetriebssys-tem . . . . . . . . . . . . . . . . 38

Referenzinformationen für Hochverfügbarkeit -Technologien . . . . . . . . . . . . . . 38Resource Monitoring and Control (RMC) . . . . 39

Bemerkungen. . . . . . . . . . . . 41Informationen zu Programmierschnittstellen . . . 43Marken . . . . . . . . . . . . . . . . 43Bedingungen . . . . . . . . . . . . . . 43

© Copyright IBM Corp. 2002, 2015 iii

|||||||

|||||||

iv IBM i: Hochverfügbarkeit - Technologien

Hochverfügbarkeit - Technologien

Ob Sie Hochverfügbarkeit für Ihre Geschäftsanwendungen benötigen oder nach einer Möglichkeit suchen,den Zeitaufwand für die täglichen Sicherungen zu reduzieren, IBM® i-Hochverfügbarkeitstechnologienstellen sowohl die Infrastruktur als auch die Tools zur Verfügung, mit denen Sie Ihre Ziele erreichen kön-nen.

Alle IBM PowerHA SystemMirror für i-Technologien, einschließlich einiger HA-Produkte von BusinessPartnern, basieren auf den IBM i Cluster Resource Services, oder einfacher ausgedrückt, auf Clustern.Cluster bilden die zugrundeliegende Infrastruktur, die ein automatisches oder manuelles Umschalten aus-fallsicherer Ressourcen, wie beispielsweise Daten, Einheiten und Anwendungen, zwischen Systemen er-möglicht. Diese Infrastruktur ermöglicht die Fehlererkennung und -intervention, sodass die Cluster Re-source Services im Falle einer Betriebsunterbrechung entsprechend reagieren können, wobei die SicherheitIhrer Daten gewahrt und der Geschäftsbetrieb fortgesetzt wird.

Die zweite Schlüsseltechnologie im Rahmen der PowerHA-Technologien stellen unabhängige Plattenpoolsdar. Mithilfe unabhängiger Plattenpools können Daten und Anwendungen auf Platten gespeichert wer-den, die während des Systembetriebs zugeschaltet sein können oder nicht. Wenn unabhängige Platten-pools Bestandteil eines Clusters sind, können die in den Pools gespeicherten Daten und Anwendungenauf andere Systeme oder logische Partitionen umgeschaltet werden. Mehrere unterschiedliche Technologi-en, wie beispielsweise umschaltbare Platten, geographische Spiegelung, Metro Mirror, Global Mirror undDS8000 HyperSwap mit unabhängigen Zusatzspeicherpools, basieren auf unabhängigen Plattenpools. DieEntscheidung darüber, welche dieser Technologien die Grundlage für Ihre HA-Lösung bilden soll, hängtvon mehreren Faktoren ab. Das Thema "Hochverfügbarkeit - Überblick" enthält einen problemorientiertenVergleich dieser Technologien sowie Kriterien, mit deren Hilfe Sie feststellen können, welche Technologi-en für Ihre Zwecke am besten geeignet sind.

Im IBM Knowledge Center haben die Begriffe IASP und unabhängiger Plattenpool dieselbe Bedeutung.

Im vorliegenden Thema werden die wichtigsten HA-Technologien und -Konzepte sowie die verschiede-nen HA-Verwaltungsschnittstellen beschrieben, die von IBM i-Systemen unterstützt werden.

Neuerungen bei IBM i 7.3Im Folgenden finden Sie die neuen und geänderten Informationen für die Themensammlung "Hochver-fügbarkeit - Technologien".

Erweiterte Funktionen in IBM PowerHA SystemMirror für i 7.2

Das Lizenzprogramm IBM PowerHA SystemMirror für i 7.2 wurde durch DS8000 HyperSwap mit IASPserweitert. Zur Unterstützung dieser neuen Funktion wurden die Befehlszeilenschnittstelle und die APIsfunktional erweitert. Weitere Einzelheiten zu diesem Feature sind in Hochverfügbarkeit - Implementie-rung zu finden.

Das Lizenzprogramm IBM PowerHA SystemMirror für i enthält die folgenden erweiterten oder neuen Be-fehle:v Erweiterter Befehl ASP-Kopienbeschreibung hinzufügenv Erweiterter Befehl ASP-Kopienbeschreibung ändernv Erweiterter Befehl ASP-Kopienbeschreibung abrufenv Erweiterter Befehl ASP-Sitzung abrufenv Neuer Befehl SVC-Kopienbeschreibung abrufen

© Copyright IBM Corp. 2002, 2015 1

|||||||||||

|

|

|

||||

||

|

|

|

|

|

v Neuer Befehl SVC-Sitzung abrufenv Erweiterter Befehl HyperSwap-Status ändernv Erweiterter Befehl HyperSwap-Status anzeigenv Neuer Befehl Mit HyperSwap-Status arbeitenv Neuer Befehl HA-Konfigurationsbeschreibung hinzufügenv Neuer Befehl HA-Konfigurationsbeschreibung ändernv Neuer Befehl HA-Konfigurationsbeschreibung anzeigenv Neuer Befehl HA-Konfigurationsbeschreibung entfernenv Neuer Befehl Mit HA-Konfigurationsbeschreibung arbeitenv Erweiterter Befehl Clusterwiederherstellung ändern

Das Lizenzprogramm IBM PowerHA SystemMirror für i enthält die folgenden erweiterten oder neuenAPIs:v Erweiterte API Retrieve ASP Copy Informationv Neue API Retrieve HA Configuration Descriptionv Neue API Retrieve HA Status

PDF-Datei für Hochverfügbarkeit - TechnologienDiese Informationen können als PDF-Datei angezeigt und gedruckt werden.

Wählen Sie zum Anzeigen oder Herunterladen der PDF-Version dieses Dokuments Hochverfügbarkeit -Technologien aus.

Sie können die folgenden PDF-Dateien mit Referenzinformationen anzeigen oder herunterladen:v Hochverfügbarkeit - Überblick

enthält die folgenden Themen:– Vorteile der Hochverfügbarkeit– Kriterien der Hochverfügbarkeit– Komponenten der Hochverfügbarkeit– IBM PowerHA SystemMirror für i - Überblick

v Hochverfügbarkeit - Implementierung

enthält die folgenden Themen:– Lizenzprogramm IBM PowerHA SystemMirror für i (iHASM), 5770-HAS, installieren– Lizenzprogramm IBM PowerHA SystemMirror für i (iHASM), 5770-HAS, deinstallieren– Hochverfügbarkeitslösung planen– PowerHA implementieren– PowerHA verwalten– Fehlerbehebung für HA-Lösung

PDF-Dateien speichern

So können Sie eine PDF-Datei zum Anzeigen oder Drucken auf Ihrer Workstation speichern:1. Klicken Sie im Browser mit der rechten Maustaste auf den Link für die PDF-Datei.

2 IBM i: Hochverfügbarkeit - Technologien

|

|

|

|

|

|

|

|

|

|

||

|

|

|

|

|

|

2. Klicken Sie auf die Auswahl zum lokalen Speichern der PDF-Datei.3. Navigieren Sie zu dem Verzeichnis, in dem die PDF-Datei gespeichert werden soll.4. Klicken Sie auf Speichern.

Adobe Reader herunterladen

Auf Ihrem System muss Adobe Reader installiert sein, damit Sie die PDF-Dateien anzeigen und druckenkönnen. Sie können das Programm kostenlos von der Adobe-Website

(www.adobe.com/products/acrobat/readstep.html)

herunterladen.

IBM i-ClustertechnologieBei dem zunehmenden Konkurrenzkampf in der heutigen Zeit ist Hochverfügbarkeit für viele Unterneh-men zum entscheidenden Kriterium geworden. Die IBM i-Clustertechnologie kann eingesetzt werden, umHochverfügbarkeit in IBM i-Umgebungen zu erreichen. Die Clustertechnologie bietet Mechanismen, mitdenen kritische Ressourcen automatisch auf Ausweichsystemen verfügbar gemacht werden können. Zudiesen Ressourcen zählen Daten, Anwendungsprogramme und Umgebungsvariablen.

Es können mehrere Systeme erforderlich sein, um die Hochverfügbarkeit der betreffenden Geschäftsan-wendungen zu gewährleisten. Die Verwaltung einer solchen Umgebung für verteilte Datenverarbeitungkann zu einer komplexen Angelegenheit werden. Ein Cluster kann solche komplexen Abläufe vereinfa-chen. In IBM i ist ein Cluster ein Verbund mehrerer Systeme oder logischer Partitionen, die als Cluster-knoten bezeichnet werden. Ein Cluster bietet eine Möglichkeit, die Umgebung zu überwachen und zuverwalten, die Hochverfügbarkeit für eine Geschäftsanwendung sicherstellt. Bei einem Cluster kann essich um eine einfache HA-Umgebung aus zwei Knoten für eine bestimmte Geschäftsanwendung oder umeine komplexere Mehrsystemumgebung für mehrere voneinander unabhängige Anwendungen handeln.Ein Cluster kann aus zahlreichen Knoten bestehen, während eine bestimmte Anwendung nur auf einigedieser Knoten angewiesen sein kann. Eine Anwendung auf einem Knoten kann fehlschlagen, ohne da-durch den Ausfall des gesamten Knotens zu verursachen. Die Clustertechnologie stellt die Mechanismenzur Verfügung, mit denen ausfallsichere Ressourcen in einer Umgebung definiert, Betriebsunterbrechun-gen erkannt und auf die entsprechenden Störungen reagiert werden kann. Sie stellt die entscheidende Inf-rastruktur bereit, die HA-Lösungen erst möglich macht.Zugehörige Informationen:Cluster planenCluster konfigurierenCluster verwalten

ClusterkonzepteEin IBM i-Cluster ist ein Verbund von Systemen (mindestens eines) oder logischen Partitionen, die so zu-sammenarbeiten, als wären sie ein einzelnes System. Lernen Sie die einzelnen Elemente und ihre Bezie-hungen untereinander anhand der vorliegenden Informationen kennen.

ClusterknotenEin Clusterknoten ist ein IBM i-System oder eine logische Partition, die zu einem Cluster gehört.

Beim Erstellen eines Clusters werden die Systeme oder logischen Partitionen angegeben, die als Knoten inden Cluster aufgenommen werden sollen. Jeder Clusterknoten wird mit einem Namen von 8 ZeichenLänge angegeben. Der Clusterknotenname ist einer oder mehreren IP-Adressen zugeordnet, die ein Sys-tem oder eine logische Partition darstellen. Bei der Konfiguration eines Clusters kann einem Clusterkno-ten ein beliebiger Name zugeordnet werden. Es wird jedoch empfohlen, als Knotennamen den Host- oderden Systemnamen zu verwenden.

Hochverfügbarkeit - Technologien 3

http://www.adobe.com/products/acrobat/readstep.html

Bei der Clusterkommunikation werden die Kommunikationspfade zwischen den Cluster-Services auf deneinzelnen Knoten des Clusters von der TCP/IP-Protokollgruppe bereitgestellt. Die als Bestandteil einesClusters konfigurierten Clusterknoten werden als Liste der Clustermitglieder bezeichnet.Zugehörige Informationen:Knoten konfigurierenKnoten verwalten

Clusterressourcengruppe (CRG)Eine Clusterressourcengruppe (CRG) ist ein IBM i-Systemobjekt, das eine Gruppe von Clusterressourcendarstellt, die zur Verwaltung Ereignissen verwendet werden, die in einer HA-Umgebung auftreten.

Bei einer Clusterressource handelt es sich um eine Ressource, die für den Geschäftsbetrieb hoch verfügbarsein muss. Clusterressourcen können entweder auf einen oder mehrere Knoten innerhalb eines Clustersverschoben oder repliziert werden. Eine Anwendung zur Lohnbuchhaltung, eine Datenbibliothek oderPlatteneinheiten sind Beispiele für Clusterressourcen. Eine Sammlung von Clusterressourcen kann von ei-ner Clusterressourcengruppe überwacht und verwaltet werden. Eine Clusterressourcengruppe definiertaußerdem die Beziehungen zwischen den Knoten, die der Clusterressource zugeordnet sind. Dazu gehö-ren die Angaben darüber, auf welchen Knoten sich die Ressourcen befinden können, welcher Knoten dieRessourcen derzeit besitzt und auf welchen Knoten die Ressourcen bei einem Ausfall übertragen werdensollen.

In einem IBM i-Cluster können vier Arten von Clusterressourcengruppen definiert sein: Einheiten-, Da-ten-, Anwendungs- und Peer-CRGs. Diese sind jeweils für die Überwachung und Verwaltung einer be-stimmten Art von Clusterressource konzipiert. So verfügt z. B. eine Geschäftsanwendung in der Regelüber zwei Clusterressourcen, eine Anwendung und die zugehörigen Anwendungsdaten. Zur Verwaltungder Anwendungsressource könnte eine Anwendungs-CRG verwendet werden. Zur Verwaltung der Datenkönnte entweder eine Einheiten-CRG verwendet werden, sofern die Daten auf umschaltbaren Platten ge-speichert sind, oder es könnte eine Daten-CRG verwendet werden, die die Daten mithilfe einer HA-An-wendung eines Geschäftspartners zwischen den Knoten repliziert.

Die genannten CRG-Arten haben zwei Elemente gemeinsam: eine Wiederherstellungsdomäne und einExitprogramm. Zur Verwaltung der Ressourcenverfügbarkeit verwendet die Clusterressourcengruppe eineUntergruppe von Knoten innerhalb des Clusters, die als Wiederherstellungsdomäne bezeichnet wird.

Das Exitprogramm führt Aktionen aus, wenn die Clusterressourcengruppe bestimmte Ereignisse feststellt.Zu diesen Ereignissen kann beispielsweise das Hinzufügen eines neuen Knotens zur Wiederherstellungs-domäne oder der Ausfall des aktuellen Primärknotens gehören.Zugehörige Informationen:Clusterressourcengruppen konfigurierenClusterressourcengruppen verwalten

Anwendungs-CRG:

In IBM i-Hochverfügbarkeitsumgebungen wird die Ausfallsicherheit von Anwendungen, womit die Mög-lichkeit bezeichnet wird, eine Anwendung auf einem Ausweichsystem erneut zu starten, durch die An-wendungs-CRG unterstützt. Die Übernahme-IP-Adresse ermöglicht den Zugriff auf eine Anwendungohne Rücksicht darauf, auf welchem System die Anwendung derzeit aktiv ist. Auf diese Weise könnenausfallsichere Anwendungen bei einem Systemausfall von einem Knoten auf einen anderen umgeschaltetwerden.

Eine Anwendungs-CRG kann eine Anwendung sowohl starten als auch überwachen, um Anwendungs-fehler festzustellen. Eine Anwendung ist als Programm oder Programmgruppe definiert, das/die zur Be-reitstellung einer unternehmensweiten Lösung aufgerufen werden kann. Die Verwaltung der Daten, dieeiner Anwendung zugeordnet sind, wird nicht von der Anwendungs-CRG sondern von einer Daten- oderEinheiten-CRG übernommen. Das Exitprogramm in einer Anwendungs-CRG hat zwei Aufgaben. Zu-


nächst wird es bei Clusterereignissen aufgerufen, damit die anwendungsspezifische Verarbeitung dieserEreignisse stattfinden kann. Die zweite Aufgabe des Exitprogramms besteht darin, das eigentliche An-wendungsprogramm zu starten und dann dessen ordnungsgemäßen Betrieb zu überwachen. Obwohl ei-nige Geschäftsanwendungen intern erstellt werden, werden andere wiederum von Fremdanbietern bezo-gen. Ein Anbieter, der seine Anwendung hoch verfügbar gestaltet hat, wird außer der Anwendung auchdas CRG-Exitprogramm liefern. Dieses ist dann so konzipiert, dass es angemessen auf Clusterereignissereagiert und die Verwaltung der Anwendung übernimmt.Zugehörige Informationen:Ausfallsichere Anwendungen planenAnwendungs-Clusterressourcengruppen erstellen

Daten-CRG:

Eine Daten-CRG ist ein IBM i-Systemobjekt, das bei der Datenreplikation zwischen Primär- und Aus-weichknoten in der Wiederherstellungsdomäne behilflich ist. Eine Daten-CRG führt die Replikation nichtselbst aus, sondern verwendet das Exitprogramm, um ein Replikationsprogramm darüber zu informieren,wann die Replikation gestartet oder beendet werden soll und auf welche Knoten repliziert werden soll.Eine Daten-CRG kontrolliert nicht, ob ein Datenressourcenfehler auftritt.

Daten-CRGs werden hauptsächlich bei Anwendungen für logische Replikation verwendet, die von mehre-ren IBM Business Partnern, die HA-Lösungen anbieten, zur Verfügung gestellt werden.Zugehörige Informationen:Daten-Clusterressourcengruppen erstellen

Einheiten-CRG:

Eine Einheiten-CRG unterstützt die Ausfallsicherheit von Einheiten in IBM i-Hochverfügbarkeitsumge-bungen. Eine Einheiten-CRG enthält einen unabhängigen Zusatzspeicherpool (IASP) oder eine Liste unab-hängiger Zusatzspeicherpools, die zwischen Systemen repliziert oder umgeschaltet werden. IASPs könnennur zwischen Knoten in der Wiederherstellungsdomäne für die Einheiten-CRG umgeschaltet oder repli-ziert werden. Der Zugriff auf die gesamte Liste der IASPs in der Einheiten-CRG wird im Falle einer Be-triebsunterbrechung, ob geplant oder ungeplant, auf den Ausweichknoten umgeschaltet. Bei der Erstel-lung der Umgebung können Sie entweder einen neuen IASP erstellen oder einen vorhandenen IASPverwenden.

Ihnen stehen IBM PowerHA SystemMirror für i-Technologien zur Verfügung, um die Daten in den IASPsumzuschalten oder zu replizieren. Mit der LUN-Technologie wird der Zugriff auf eine Kopie des IASPvom primären Server auf den Ausweichserver umgeschaltet. Mit Replikationstechnologien wie geographi-sche Spiegelung, Metro Mirror oder Global Mirror werden Daten vom IASP am Produktionsstandort aufeinen anderen IASP am Ausweichstandort gespiegelt. Normalerweise sind beide Standorte geographischvoneinander getrennt, was dem Katastrophenschutz dient, d. h. die Wiederherstellung nach einem Katast-rophenfall ermöglicht. In diesen Umgebungen steuert die Einheiten-CRG das Umschalten des Zugriffszwischen den gespiegelten Kopien des IASP. Wenn es am Produktionsstandort zu einer Betriebsunterbre-chung kommt, wird der Zugriff auf den IASP von der Einheiten-CRG auf den Ausweichstandort umge-schaltet.Zugehörige Informationen:Einheiten-Clusterressourcengruppen (Einheiten-CRGs) erstellen

Peer-CRG:

Eine Peer-CRG ist eine nicht umschaltbare Clusterressourcengruppe, in der alle IBM i-Knoten in der Wie-derherstellungsdomäne gleichermaßen an der Wiederherstellung des Knotens beteiligt sind. Die Peer-CRGsorgt für die Peerausfallsicherheit von Objekt- und Servicegruppen.


||||||||

||||||||||

Im Unterschied zu den übrigen CRG-Arten, bei denen die Arbeitsleistung ausschließlich vom Primärkno-ten erbracht wird, arbeiten in einer Peer-CRG alle Knoten in der Wiederherstellungsdomäne zusammen.Zweck einer Peer-CRG ist die Bereitstellung eines allgemeinen Rahmens für die verteilte Datenverarbei-tung, für den Programmierer Anwendungen erstellen können. Die Peer-CRG sorgt für die Peerausfallsi-cherheit von Objekt- und Servicegruppen. Dabei wählen die Endbenutzer, die Endbenutzeranwendungenund die Anwendungen von Geschäftspartnern die Objektgruppen aus, und nicht das System.Zugehörige Informationen:Peer-CRGs erstellen

Wiederherstellungsdomäne:

Innerhalb der IBM i-Clustertechnologie ist eine Wiederherstellungsdomäne eine Untergruppe von Cluster-knoten, die zu einer Clusterressourcengruppe (CRG) zusammengeschlossen sind und einem gemeinsamenZweck dienen, z. B. zur Ausführung einer Wiederherstellungsaktion oder zur Synchronisation von Ereig-nissen.

Für Hochverfügbarkeitsumgebungen eignen sich hauptsächlich zwei Wiederherstellungsdomänenmodelle.Diese Modelle richten sich danach, welche Art von Clusterressourcengruppe erstellt wird und welcheRollen in der Wiederherstellungsdomäne definiert sind. Beim Modell aus Primär- und Ausweichknotenmüssen Benutzer dem Knoten entweder die Rolle als Primär-, als Ausweich- oder als Replikationsknotenzuweisen. Diese Rollendefinitionen werden von Einheiten-, Anwendungs- und Daten-CRGs unterstützt.Die Rollen werden innerhalb der Wiederherstellungsdomäne definiert und verwaltet.

Wenn ein Knoten als primärer Zugriffspunkt für die Ressource definiert wurde, übernehmen andere Kno-ten die Rolle der Ausweichknoten, wenn der Primärknoten ausfällt. Knoten, die als Ausweichknoten de-finiert sind, können als Zugriffspunkt für die Ressource dienen. Für die Ausweichknoten gilt eine be-stimmte Reihenfolge, die festlegt, welcher Ausweichknoten als erster an der Reihe ist, falls derPrimärknoten ausfallen sollte. Bei Modellen aus Primär- und Ausweichknoten reagieren IBM i-Cluster au-tomatisch auf der Basis dieser Rollendefinitionen, wenn ein Knoten ausfällt oder umgeschaltet wird. Bei-spiel: Wenn der als Primärknoten definierte Knoten A ausfällt, wird der als erster Ausweichknoten defi-nierte Knoten B zum neuen Primärknoten. Die Reihenfolge der übrigen als Ausweichknoten definiertenKnoten wird entsprechend neu geordnet.

Ein Replikationsknoten ist mit einem Ausweichknoten vergleichbar, kann jedoch nicht als Zugriffspunktfür eine Ressource dienen (kann also nicht zum Primärknoten werden). Das Haupteinsatzgebiet eines Re-plikationsknotens ist eine Daten-CRG, in der die Daten zwecks Berichterstellung auf einem Replikations-knoten bereitgestellt werden können, obwohl dieser Knoten nie zum Primärknoten werden kann.

Das zweite Wiederherstellungsdomänenmodell ist das Peermodell. Beim Peermodell gibt es keine be-stimmte Reihenfolge der Clusterknoten. Bei diesem Modell können Knoten entweder als Peer- oder alsReplikationsknoten definiert werden. Diese Rollendefinitionen werden von Peer-CRGs unterstützt. Kno-ten, die als Peer in der Wiederherstellungsdomäne definiert sind, sind alle gleichrangig und können alsZugriffspunkt für die Ressource dienen. Beim Ausfall eines Peerknotens gibt es jedoch keine bestimmteReihenfolge für die übrigen. Die Knoten in der Wiederherstellungsdomäne werden zwar benachrichtigt,wenn andere Knoten ganz oder vorübergehend ausfallen, da aber keine automatische Reaktion erfolgt,muss eine Anwendung entsprechende Aktionen für derartige Ereignisse bereitstellen.

Einem Knoten in einer Wiederherstellungsdomäne können die folgenden vier Rollen zugewiesen werden:

PrimärknotenDer Clusterknoten, der als primärer Zugriffspunkt für die Clusterressource dient.v In einer Daten-CRG enthält der Primärknoten die Hauptkopie einer Ressource.v In einer Anwendungs-CRG ist der Primärknoten das System, auf dem die Anwendung momen-

tan ausgeführt wird.v In einer Einheiten-CRG ist der Primärknoten der aktuelle Eigner des IASP.


|

v In einer Peer-CRG wird kein Primärknoten unterstützt.

Wenn der Primärknoten einer Clusterressourcengruppe ausfällt oder ein manueller Switchovereingeleitet wird, wird der primäre Zugriffspunkt für diese Clusterressourcengruppe auf den ers-ten Ausweichknoten übertragen.

AusweichknotenDer Clusterknoten, der die Rolle des primären Zugriffspunkts übernimmt, wenn der aktuelle Pri-märknoten ausfällt oder ein manueller Switchover eingeleitet wird.v In einer Daten-CRG enthält dieser Clusterknoten eine Kopie der Ressource, die durch Replikati-

on auf dem neuesten Stand gehalten wird.v In einer Peer-CRG wird kein Ausweichknoten unterstützt.

ReplikationsknotenEin Clusterknoten, der Kopien von Clusterressourcen besitzt, aber nicht die Rolle eines Primär-oder Ausweichknotens annehmen kann. Ein Failover oder Switchover auf einen Replikationskno-ten ist nicht zulässig. Sollte es dennoch einmal erforderlich sein, einen Replikationsknoten zumPrimärknoten zu machen, muss die Rolle des Replikationsknotens zunächst in die eines Aus-weichknotens geändert werden.v In Peer-CRGs bilden Knoten, die als Replikationsknoten definiert sind, den inaktiven Zugriffs-

punkt für Clusterressourcen.

PeerknotenEin Clusterknoten ohne festgelegte Rangfolge, der als aktiver Zugriffspunkt für Clusterressourcendienen kann. Beim Starten der Clusterressourcengruppe sind alle als Peer definierten Knoten akti-ve Zugriffspunkte.v In einer Peer-CRG wird der Zugriffspunkt gänzlich von der Verwaltungsanwendung gesteuert,

nicht vom System. Die Rolle des Peerknotens wird nur von der Peer-CRG unterstützt.

Exitprogramme für Clusterressourcengruppe:

In IBM i-Hochverfügbarkeitsumgebungen werden Exitprogramme für die Clusterressourcengruppe (CRG-Exit-programme) beim Auftreten clusterbezogener Ereignisse für eine Clusterressourcengruppe aufgerufenund reagieren auf das Ereignis.

Ein Exitprogramm wird aufgerufen, wenn eine Clusterressourcengruppe bestimmte Ereignisse feststellt.Zu diesen Ereignissen kann beispielsweise das Hinzufügen eines neuen Knotens zur Wiederherstellungs-domäne oder der Ausfall des aktuellen Primärknotens gehören. Das Exitprogramm wird mit einem Akti-onscode aufgerufen, der darauf hinweist, um welches Ereignis es sich handelt. Weiterhin kann das Exit-programm angeben, ob das Ereignis verarbeitet werden soll oder nicht. Benutzerdefiniert bedeutet, dassdas Exitprogramm nicht von der IBM i-Clustertechnologie zur Verfügung gestellt wird. Das Exitpro-gramm wird normalerweise vom Anbieter der Anwendung oder Datenreplikation zur Verfügung gestellt.Eine Clusterressourcengruppe benutzt das Exitprogramm, um dessen Anbieter über Clusterereignisse zuinformieren. Auf der Basis des jeweiligen Ereignisses kann das Exitprogramm die entsprechende Aktionausführen, die beispielsweise darin bestehen könnte, das Verschieben eines Ressourcenzugriffspunkts aufeinen anderen Knoten zuzulassen. Für ausfallsichere Einheiten-CRGs ist das Exitprogramm optional, fürdie übrigen CRG-Arten ist es jedoch erforderlich. Wenn ein CRG-Exitprogramm verwendet wird, wird esbeim Auftreten clusterweiter Ereignisse aufgerufen. Dies können folgende Ereignisse sein:v Ein Knoten verlässt den Cluster unerwartet.v Ein Knoten verlässt den Cluster, weil die API QcstEndClusterNode (End Cluster Node) oder QcstRe-

moveClusterNodeEntry (Remove Cluster Node Entry) aufgerufen wurde.v Der Cluster wird gelöscht, weil die API QcstDeleteCluster (Delete Cluster) aufgerufen wurde.v Ein Knoten wird durch Aufrufen der API QcstStartClusterNode (Start Cluster Node) aktiviert.v Die Kommunikation mit einem partitionierten Knoten wird wiederhergestellt.


Exitprogramme werden von IBM Business Partnern für Cluster-Middleware und Anbietern clustersensiti-ver Anwendungsprogramme erstellt oder bereitgestellt.

Ausführliche Informationen über CRG-Exitprogramme sowie darüber, welche Informationen für die ein-zelnen Aktionscodes an die Exitprogramme übermittelt werden, finden Sie unter Cluster Resource GroupExit Program in der API-Dokumentation.

ClusterversionEine Clusterversion stellt die in einem Cluster zur Verfügung stehende Funktionsstufe dar.

Die Versionssteuerung ist ein Verfahren, das die Aufnahme von Knoten verschiedener Release-Level in ei-nen Cluster zulässt und durch Festlegung der zu verwendenden Übertragungsprotokollversion ermög-licht, dass diese uneingeschränkt zusammenwirken können.

Anmerkung: Wenn Sie mit IBM PowerHA SystemMirror für i, Lizenzprogrammnummer 5770-HAS, ar-beiten, ist Clusterversion 6 oder höher erforderlich.

Es gibt zwei Clusterversionen:

Potenzielle ClusterversionDie potenzielle Clusterversion ist die höchstmögliche Versionsstufe einer Clusterfunktion, die füreinen bestimmten Knoten verfügbar ist. Dies ist der Versionsstand, auf dem der Knoten mit denübrigen Clusterknoten kommunizieren kann.

Aktuelle ClusterversionDie aktuelle Clusterversion ist die Version, die momentan für alle Clusteroperationen verwendetwird. Dies ist der Versionsstand, auf dem alle Knoten im Cluster miteinander kommunizieren.

Die potenzielle Clusterversion wird bei jedem Release von IBM i erhöht, das wichtige neue Funktionenenthält, die in älteren Clusterversionen nicht verfügbar sind. Wenn die aktuelle Clusterversion niedrigerist als die potenzielle Clusterversion, kann die entsprechende Funktion nicht verwendet werden, weilmanche Knoten die Anforderung nicht erkennen oder verarbeiten können. Um die neuen Funktionen nut-zen zu können, müssen alle Knoten im Cluster dieselbe potenzielle Version aufweisen, und auch die ak-tuelle Clusterversion muss auf diesen Stand gesetzt sein.

Wenn ein Knoten versucht, an einem Cluster teilzunehmen, wird die potenzielle Clusterversion mit deraktuellen Clusterversion verglichen. Wenn der Wert der potenziellen Clusterversion nicht mit der aktuel-len Version (N) identisch ist oder nicht dem nächsten Versionsstand (N+2) entspricht, darf der Knotennicht am Cluster teilnehmen. Beachten Sie, dass die aktuelle Clusterversion zunächst vom ersten Knotenfestgelegt wird, der im Cluster definiert wird; dabei wird der Wert verwendet, der im Befehl oder derAPI zur Clustererstellung angegeben wurde.

Wenn z. B. 7.2-Knoten zusammen mit 7.3-Knoten vorhanden sein sollen, können Sie folgendermaßen vor-gehen:v Erstellen Sie den Cluster auf einem 7.2-Knoten und fügen Sie den 7.3-Knoten hinzu.v Erstellen Sie den Cluster auf einem 7.3-Knoten und geben Sie an, dass Knoten vorheriger Versionen

dem Cluster hinzugefügt werden dürfen. Fügen Sie anschließend die 7.2-Knoten hinzu.

In einem Cluster, der Knoten verschiedener Release-Level enthält, werden Clusterprotokolle immer aufdem niedrigsten Knoten-Release-Level der aktuellen Clusterversion ausgeführt. Diese wird beim Erstellendes Clusters definiert. Für N kann entweder die potenzielle Knotenversion angegeben werden, die aufdem Knoten ausgeführt wird, der die Clustererstellung veranlasst hat, oder es kann die Clusterversionangegeben werden, die um eine Stufe niedriger als die potenzielle Knotenversion des Veranlassers ist. DieKnoten im Cluster dürfen um höchstens zwei Clusterversionsstände voneinander abweichen.


||

|

||

Sobald alle Knoten im Cluster auf das nächste Release aktualisiert wurden, kann auch die Clusterversionaktualisiert werden, damit die neuen Funktionen verfügbar werden. Dies kann durch Anpassen der Clus-terversion erfolgen.

Achtung: Wenn die neue Clusterversion nicht mit der aktuellen Clusterversion übereinstimmt odernicht eine oder zwei Versionen höher als diese ist, kommt es beim Neustart des Clusterknotens zu einemFehler. Zur Fehlerbehebung muss der Cluster auf diesem Knoten gelöscht und die Clusterversion ange-passt werden, bevor der Knoten erneut dem Cluster hinzugefügt werden kann.

Achtung: Wenn Sie in Ihrem Cluster mit unabhängigen Zusatzspeicherpools (IASPs) arbeiten, bestehenEinschränkungen beim Switchover zwischen Releases. Wird ein unabhängiger Plattenpool von einemKnoten mit einem früheren Release von IBM i auf einen Knoten mit dem aktuellen Release von IBM iumgeschaltet, wird sein interner Inhalt geändert, sobald er auf dem Knoten mit dem aktuellen Releaseverfügbar ist, und er kann nicht mehr für den Knoten mit dem früheren Release verfügbar gemacht wer-den.

Weitere Informationen über Clusterversionen finden Sie in der Dokumentation zu den verfügbaren Clus-ter-APIs. Dort finden Sie auch Informationen über Einschränkungen und den Zusammenhang zwischenClusterversionen und IBM i-Releases.Zugehörige Informationen:Cluster mit verschiedenen Releases planenClusterversion anpassenSzenario: Betriebssystemupgrades in einer HA-Umgebung ausführen

EinheitendomäneEine Einheitendomäne ist eine Untergruppe von Knoten in einem IBM i-Cluster, die Einheitenressourcengemeinsam nutzen. Die Knoten in einer Einheitendomäne können darüber hinaus an einem Switchoverfür eine Gruppe von ausfallsicheren Einheitenressourcen teilnehmen.

Einheitendomänen werden von mehreren Schnittstellen identifiziert und verwaltet, mit deren Hilfe Sie ei-nen Knoten zu einer Einheitendomäne hinzufügen oder aus dieser entfernen können.

Einheitendomänen werden zur Verwaltung bestimmter globaler Informationen verwendet, die erforder-lich sind, um eine ausfallsichere Einheit von einem Knoten auf einen anderen umzuschalten. Alle Knotenin der Einheitendomäne benötigen diese Informationen, damit beim Switchover der Einheiten keine Kon-flikte auftreten. Beispielsweise müssen bei einer Gruppe umschaltbarer Platten die Kennzeichnung derunabhängigen Plattenpools sowie die Zuordnungen von Platteneinheiten und virtuellen Adressen in dergesamten Einheitendomäne eindeutig sein.

Ein Clusterknoten darf nur einer einzigen Einheitendomäne angehören. Bevor ein Knoten zur Wiederher-stellungsdomäne für eine Einheiten-CRG hinzugefügt werden kann, muss er zunächst als Mitglied einerEinheitendomäne definiert werden. Alle Knoten, die einer Wiederherstellungsdomäne für eine Einheiten-CRG angehören sollen, müssen sich in derselben Einheitendomäne befinden.

Sie können Einheitendomänen nur dann erstellen und verwalten, wenn Option 41 (IBM i - HA SwitchableResources) und ein gültiger Lizenzschlüssel auf Ihrem System installiert sind.Zugehörige Informationen:Knoten zu einer Einheitendomäne hinzufügen

ClusterjobsDie Verwaltung eines IBM i-Clusters setzt Kenntnisse über die Strukturen von Clusterjobs und deren Or-ganisation auf dem System voraus.


||||||

Cluster Resource Services-Jobs

Die Cluster Resource Services bestehen aus einer Reihe von Multithread-Jobs. Kritische Cluster ResourceServices-Jobs sind Systemjobs, die unter dem Benutzerprofil QSYS ausgeführt werden. Zahlreiche Funkti-onen, die die Ablaufsteuerung betreffen, wie beispielsweise das Beenden eines Jobs (ENDJOB), sind fürSystemjobs nicht zulässig. Das bedeutet, dass ein Benutzer nicht versehentlich einen dieser Clustersys-temjobs beenden kann, was zu Problemen im Cluster und in der HA-Umgebung führen würde. Wenndas Clustering auf einem System aktiv ist, werden folgende Jobs als Systemjobs ausgeführt:v Clustersteuerungsjob: ein Job mit der Bezeichnung QCSTCTL.v CRG-Manager: ein Job mit der Bezeichnung QCSTCRGM.

Anmerkung: Die Jobs QCSTCTL und QCSTCRGM sind clusterkritische Jobs. Das heißt, dass diese Jobsaktiv sein müssen, damit der Knoten im Cluster aktiv ist.

v Jede Clusterressourcengruppe besteht aus einem Job pro CRG-Objekt. Der Jobname ist mit dem Namender Clusterressourcengruppe identisch.

v Clusterverwaltungsdomänenjobs bestehen aus einem Systemjob, der auf allen Knoten im Cluster aktivist. Der Name des Systemjobs ist mit dem Namen der Clusterverwaltungsdomäne identisch.

Es ist unbedingt zu beachten, dass diese Clustersystemjobs von einigen Aktionen zur Ablaufsteuerung be-endet werden, wodurch ein Failover ausgelöst wird. Während dieser Aktionen wird das Clustering been-det und ein Failover durchgeführt. Wie dies geschieht, richtet sich danach, wie der betreffende Knoten inder Clusterressourcengruppe definiert ist. Das Thema "Beispiel: Ausfälle, die ein Failover verursachen"enthält eine vollständige Liste der systembezogenen Ereignisse, die ein Failover verursachen.

Mit dem Befehl CHGCLURCY (Clusterwiederherstellung ändern) kann der beendete CRG-Job erneut ge-startet werden, ohne dass das Clustering auf einem Knoten beendet und erneut gestartet werden muss.

Weitere weniger kritische clusterbezogene Jobs sind Bestandteil des Subsystems QSYSWRK. Mit dem Be-enden des Subsystems QSYSWRK werden diese Jobs beendet, ohne ein Failover zu verursachen. DieseJobs können jedoch Clusterprobleme verursachen, die eine Wiederherstellungsaktion erforderlich machenkönnten. Einige dieser Jobs werden unter dem Benutzerprofil QSYS ausgeführt.

Die meisten Clusterressourcengruppen-APIs führen zur Übergabe eines separaten Jobs, der das Benutzer-profil verwendet, das beim Aufruf der API angegeben wurde. Das in der Clusterressourcengruppe defi-nierte Exitprogramm wird in dem übergebenen Job aufgerufen. Standardmäßig werden die Jobs an dieJobwarteschlange QBATCH übergeben. Im Allgemeinen wird diese Jobwarteschlange für Produktionssta-peljobs verwendet und führt zur Verzögerung oder Verhinderung der Exitprogramme. Damit die APIs er-folgreich ausgeführt werden können, erstellen Sie ein Benutzerprofil, eine Jobbeschreibung und eine Job-warteschlange ausschließlich für Clusterressourcengruppen. Geben Sie für alle von Ihnen erstelltenClusterressourcengruppen das neue Benutzerprofil an. Auf allen Knoten innerhalb der Wiederherstel-lungsdomäne, die für die Clusterressourcengruppe definiert ist, wird ein und dasselbe Programm verar-beitet.

Außerdem wird ein separater Stapeljob für eine Clusterverwaltungsdomäne übergeben, wenn eine Clus-terressourcengruppen-API aufgerufen wird. Das von IBM gelieferte Programm QCSTADEXTP wird aufge-rufen. Der übergebene Job wird unter dem Benutzerprofil QCLUSTER und unter Verwendung der Jobbe-schreibung QCSTJOBD ausgeführt.Zugehörige Informationen:Beispiel: Failover bei Ausfallereignissen verwaltenCluster APIs Use of User QueuesSystemjobs


BasisclusterfunktionenDie Systeme in einem Cluster werden von mehreren IBM i-Basisclusterfunktionen überwacht, die poten-zielle Ausfälle in der HA-Umgebung erkennen und entsprechend reagieren.

Die Cluster Resource Services stellen integrierte Services zur Verwaltung der Clustertopologie, Ausfüh-rung der Heartbeatüberwachung sowie zum Erstellen und Verwalten von Clusterkonfigurationen undClusterressourcengruppen zur Verfügung. Die Cluster Resource Services beinhalten außerdem zuverlässi-ge Nachrichtenübertragungsfunktionen, die alle Knoten im Cluster überwachen und sicherstellen, dassalle Knoten über konsistente Informationen hinsichtlich des Status der Clusterressourcen verfügen.

HeartbeatüberwachungDie Heartbeatüberwachung ist eine IBM i-Basisclusterfunktion, die sicherstellt, dass die einzelnen Knoten ineinem Cluster aktiv sind. Bei der Heartbeatüberwachung sendet jeder Knoten im Cluster ein Signal analle übrigen Knoten im Cluster, das besagt, dass alle noch aktiv sind.

Wenn der Heartbeat für einen Knoten nicht bestätigt wird, ergreifen die Cluster Resource Services dieentsprechenden Maßnahmen.

Die folgenden Beispiele sollen die Funktionsweise der Heartbeatüberwachung erläutern:

Beispiel 1

Ne t z we r k 1

RV4C102-1

A

C

B

Gemäß den Standardeinstellungen (den normalen Einstellungen) sendet jeder Knoten im Cluster alle dreiSekunden eine Heartbeatnachricht an seinen vorgeordneten Nachbarknoten. Beispiel: Wenn Sie Knoten A,Knoten B und Knoten C in Netzwerk 1 konfigurieren, sendet Knoten A eine Nachricht an Knoten B, Kno-ten B sendet eine Nachricht an Knoten C, und Knoten C sendet eine Nachricht an Knoten A. Knoten A er-wartet sowohl eine Empfangsbestätigung des Heartbeat von Knoten B als auch einen eingehenden Heart-beat vom nachgeordneten Knoten C. Tatsächlich verläuft also der ringförmige Heartbeataustausch inbeiden Richtungen. Wenn Knoten A keinen Heartbeat von Knoten C empfangen hat, senden Knoten Aund Knoten B weiterhin alle drei Sekunden einen Heartbeat. Wenn bei Knoten C vier aufeinanderfolgen-de Heartbeats nicht angekommen sind, wird ein Heartbeatfehler gemeldet.


Beispiel 2

Re la i s -

k no t en

Re l a i s -

k no te n

R ou te r

Re la i s -

k n o t e n

Re la i s -

k n o t e n

Ne t z we r k 1

L o g i s che s N e tz we rk N e tz we rk 2

RV4C101-1

A

D

C

F

B

DA E

In diesem Beispiel wird ein weiteres Netzwerk hinzugefügt, um die Verwendungsweise von Routern undRelaisknoten zu verdeutlichen. Sie konfigurieren Knoten D, Knoten E und Knoten F auf Netzwerk 2, dasüber einen Router mit Netzwerk 1 verbunden ist. Bei dem Router kann es sich um eine weitere IBM i-Maschine oder eine Routerbox handeln, die die Kommunikation an einen anderen Router weiterleitet. Je-dem lokalen Netzwerk ist ein Relaisknoten zugeordnet. Dieser Relaisknoten ist der Knoten mit der nied-rigsten Knoten-ID im Netzwerk. Knoten A ist als Relaisknoten auf Netzwerk 1 und Knoten D alsRelaisknoten auf Netzwerk 2 zugeordnet. Anschließend wird ein logisches Netzwerk erstellt, das dieKnoten A und D enthält. Durch den Einsatz von Routern und Relaisknoten können sich diese beidenNetzwerke gegenseitig überwachen und etwaige Knotenausfälle melden.

Zuverlässige NachrichtenübertragungsfunktionDie zuverlässige Nachrichtenübertragungsfunktion der Cluster Resource Services überwacht alle Knoten in ei-nem IBM i-Cluster und stellt sicher, dass alle Knoten über konsistente Informationen hinsichtlich des Sta-tus der Clusterressourcen verfügen.

Bei der zuverlässigen Nachrichtenübertragungsfunktion werden clustering-spezifische Wiederholungs-und Zeitlimitwerte verwendet. Diese Werte sind so voreingestellt, dass sie für die meisten Umgebungengeeignet sein sollten. Sie können jedoch auch über die Schnittstelle zum Ändern der Einstellungen derCluster Resource Services geändert werden. Mithilfe der Nachrichtenwiederholungs- und Zeitlimitwertewird festgelegt, wie oft eine Nachricht an einen Knoten gesendet werden soll, bis ein Fehler oder einePartitionssituation gemeldet wird. Unter Verwendung der Standardeinstellungen für die Wiederholungs-und Zeitlimitwerte dauert es bei einem LAN (lokales Netzwerk) etwa 45 Sekunden, bis eine Fehler- oder


Partitionsbedingung gemeldet wird. Einem fernen Netzwerk wird mehr Zeit zugestanden, um festzustel-len, ob eine Fehler- oder Partitionsbedingung vorliegt. Bei einem fernen Netzwerk ist mit ungefähr 4Minuten und 15 Sekunden zu rechnen.

ClusterereignisseClusterereignisse sind Aktionen und Ereignisse, die in einer IBM i-Hochverfügbarkeitsumgebung vorkom-men können und auf die die Cluster Resource Services reagieren.

Die Cluster Resource Services erkennen bestimmte Ereignisse in einer Hochverfügbarkeitsumgebung undreagieren entsprechend.

SwitchoverEin Switchover erfolgt, wenn der Zugriff auf eine Ressource manuell von einem IBM i-System auf ein an-deres umgeschaltet wird.

Ein manueller Switchover wird normalerweise im Rahmen der Systemwartung eingeleitet, beispielsweise,wenn vorläufige Programmkorrekturen (PTFs) angelegt, ein neues Release installiert oder ein Systemup-grade durchgeführt wird. Im Gegensatz dazu erfolgt ein Failover automatisch, wenn der Primärknotenausfällt.

Bei einem Switchover wird der Zugriff von dem Clusterknoten, der momentan als Primärknoten in derCRG-Wiederherstellungsdomäne fungiert, auf den Clusterknoten umgeschaltet, der als erster Ausweich-knoten festgelegt wurde. Unter "Wiederherstellungsdomäne" finden Sie Informationen darüber, wie dieSwitchover-Reihenfolge festgelegt wird.

Wenn Sie einen administrativen Switchover mehrerer Clusterressourcengruppen durchführen, müssen Siebei der Angabe der Reihenfolge die Beziehungen zwischen den Clusterressourcengruppen beachten. Bei-spiel: Bei einer Anwendungs-CRG, die von Daten abhängig ist, die einer Einheiten-CRG zugeordnet sind,führen Sie folgende Schritte aus, um einen geordneten Switchover durchzuführen:1. Versetzen Sie die Anwendung auf dem alten Primärknoten in den Wartemodus (um Änderungen an

den Daten stillzulegen).2. Schalten Sie die Einheiten-CRG auf den neuen Primärknoten um.3. Schalten Sie die Anwendungs-CRG auf den neuen Primärknoten um.

FailoverEin Failover erfolgt, wenn ein IBM i-System in einem Cluster bei einem Systemausfall automatisch auf ei-nen oder mehrere Ausweichknoten umgeschaltet wird.

Im Gegensatz dazu erfolgt ein Switchover, wenn der Zugriff von einem Server auf einen anderen manuellumgeschaltet wird. Nach dem Auslösen ist die Funktionsweise von Switchover und Failover identisch;der einzige Unterschied besteht in der Art und Weise des Auslösens.

Bei einem Failover wird der Zugriff von dem Clusterknoten, der momentan als Primärknoten in der Wie-derherstellungsdomäne der Clusterressourcengruppe fungiert, auf den Clusterknoten umgeschaltet, derals erster Ausweichknoten festgelegt wurde.

Wenn mehrere Clusterressourcengruppen an einem Failover beteiligt sind, werden vom System zuerst dieEinheiten-CRGs, dann die Daten-CRGs und zum Schluss die Anwendungs-CRGs verarbeitet.

Bei der Failover-Verarbeitung von Einheiten-CRGs werden die Einheiten abgehängt, die der Clusterres-sourcengruppe zugeordnet sind. Dies geschieht auch dann, wenn der Failover über die Cluster- oder dieFailover-Nachrichtenwarteschlange abgebrochen wird. Einige Systemaktionen, die einen Failover verursa-chen, wie beispielsweise das Beenden von TCP/IP, betreffen nicht das gesamte System, sodass Benutzerund Jobs möglicherweise immer noch Zugriff auf die Einheit benötigen. Es könnte folgende Gründe ha-


ben, warum Sie die Clusterressourcengruppe erst beenden möchten, bevor Sie die genannten Systemakti-onen ausführen, und die Einheiten angehängt lassen möchten:v Wenn Sie nach Beenden aller Subsysteme (ENDSBS *ALL) eine Sicherung mit Option 21 ausführen.v Wenn Sie routinemäßige Programmkorrekturen durch Beenden von Subsystemen oder Beenden von

TCP/IP vornehmen und keine Zeit mit dem Ab- und Anhängen von Einheiten verschwenden möchten.v Wenn nicht das gesamte System beendet wird, benötigen möglicherweise andere Jobs noch Zugriff auf

die Einheit.

Die Failover-Nachrichtenwarteschlange empfängt für alle im Cluster definierten Clusterressourcengrup-pen Nachrichten hinsichtlich der Failover-Aktivität. In der Clusternachrichtenwarteschlange können Sieauch für alle Clusterressourcengruppen, für die ein Failover auf denselben Knoten erfolgt, gleichzeitigeine einzige Nachricht empfangen. Beide Nachrichtenwarteschlangen geben Ihnen die Möglichkeit, dieFailover-Verarbeitung von Clusterressourcengruppen und Knoten zu steuern. Wenn sowohl die Cluster-nachrichtenwarteschlange als auch die Failover-Nachrichtenwarteschlange konfiguriert sind, hat die Clus-ternachrichtenwarteschlange Priorität. Wenn Sie lieber für jede einzelne Clusterressourcengruppe in einemCluster Failover-Nachrichten wünschen, sollten Sie die Clusternachrichtenwarteschlange nicht konfigurie-ren. Die Aktivitäten beider Nachrichtenwarteschlangen können Sie mithilfe der IBM i-Überwachungsun-terstützung überwachen.Zugehörige Konzepte:„Wiederherstellungsdomäne” auf Seite 6Innerhalb der IBM i-Clustertechnologie ist eine Wiederherstellungsdomäne eine Untergruppe von Cluster-knoten, die zu einer Clusterressourcengruppe (CRG) zusammengeschlossen sind und einem gemeinsamenZweck dienen, z. B. zur Ausführung einer Wiederherstellungsaktion oder zur Synchronisation von Ereig-nissen.

Clusternachrichtenwarteschlange:

In IBM i-Hochverfügbarkeitsumgebungen kann eine Clusternachrichtenwarteschlange für das Empfangenund Beantworten von Nachrichten angegeben werden, die Einzelheiten zu Failover-Ereignissen im Clus-ter enthalten. Diese Nachrichtenwarteschlange enthält Informationen über alle Clusterressourcengruppen,für die ein Failover auf denselben Knoten durchgeführt wird, wenn der Primärknoten für die Clusterres-sourcengruppen beendet wird oder ausfällt.

Clusternachrichtenwarteschlange und Failover-Nachrichtenwarteschlange sind annähernd gleich aufge-baut, doch empfängt die Clusternachrichtenwarteschlange statt einer Nachricht pro Clusterressourcen-gruppe eine einzige Nachricht für sämtliche Clusterressourcengruppen, für die ein Failover auf denselbenKnoten durchgeführt wird. Wenn sowohl die Clusternachrichtenwarteschlange als auch die Failover-Nachrichtenwarteschlange konfiguriert ist, hat die Clusternachrichtenwarteschlange Priorität. Wenn Sielieber für jede einzelne Clusterressourcengruppe in einem Cluster Failover-Nachrichten erhalten möchten,sollten Sie die Clusternachrichtenwarteschlange nicht konfigurieren. Die Aktivitäten beider Nachrichten-warteschlangen können Sie mithilfe der IBM i-Überwachungsunterstützung überwachen.

In der folgenden Tabelle werden die Aktionen für beide Nachrichtenwarteschlangen beschrieben:

Tabelle 1. Aktionen für Cluster- und Failover-Nachrichtenwarteschlange

DefinierteClusternachrichtenwarteschlange

Definierte Failover-Nachrichtenwarteschlange Reaktion

Nein Nein Failover wird ohne Benutzeraktionfortgesetzt

Nein Ja An die Failover-Nachrichtenwarteschlangen allerCRGs auf dem erstenAusweichknoten wird eine Nachricht(CPABB01) gesendet


Tabelle 1. Aktionen für Cluster- und Failover-Nachrichtenwarteschlange (Forts.)

DefinierteClusternachrichtenwarteschlange

Definierte Failover-Nachrichtenwarteschlange Reaktion

Ja Nein Für Failover auf Knotenebene wirdeine Nachricht (CPABB02) an dieClusternachrichtenwarteschlange aufdem ersten Ausweichknoten gesen-det, der alle CRGs steuert, für die einFailover auf diesen Knoten durchge-führt wird. Für Failover auf CRG-Ebene wird pro CRG eine Nachricht(CPABB01) an dieClusternachrichtenwarteschlange aufdem ersten Ausweichknoten gesen-det, der die eine CRG steuert, für dieein Failover auf diesen Knoten durch-geführt wird.

Ja Ja CRG-Failover-Nachrichtenwarteschlange wird igno-riert. Für Failover auf Knotenebenewird eine Nachricht (CPABB02) andie Clusternachrichtenwarteschlangeauf dem ersten Ausweichknoten ge-sendet, der alle CRGs steuert, für dieein Failover auf diesen Knoten durch-geführt wird. Für Failover auf CRG-Ebene wird pro CRG eine Nachricht(CPABB01) an dieClusternachrichtenwarteschlange aufdem ersten Ausweichknoten gesen-det, der die eine CRG steuert, für dieein Failover auf diesen Knoten durch-geführt wird.

Eine Clusternachrichtenwarteschlange wird durch Angabe des Warteschlangennamens und der Bibliothekdefiniert, in der sich die Warteschlange befindet. Sie können auch angeben, wie lange (in Minuten) aufeine Beantwortung der Failover-Nachricht gewartet werden soll. Sobald dieser Zeitraum überschrittenwird, wird die angegebene Standardaktion für den Failover ausgeführt.Zugehörige Konzepte:„Failover-Nachrichtenwarteschlange”Die Failover-Nachrichtenwarteschlange empfängt für alle in einem IBM i-Cluster definierten Clusterres-sourcengruppen Nachrichten hinsichtlich der Failover-Aktivität.Zugehörige Informationen:Überwachung starten (STRWCH)

Failover-Nachrichtenwarteschlange:

Die Failover-Nachrichtenwarteschlange empfängt für alle in einem IBM i-Cluster definierten Clusterres-sourcengruppen Nachrichten hinsichtlich der Failover-Aktivität.

Mithilfe der Failover-Nachrichtenwarteschlange kann der Administrator über einen bevorstehenden Failo-ver benachrichtigt werden. Der Administrator hat so die Möglichkeit, den Failover abzubrechen, wenndas zum gegebenen Zeitpunkt gewünscht wird. Die Failover-Nachrichtenwarteschlange enthält Nachrich-ten für alle in einem Cluster definierten Clusterressourcengruppen. Die Failover-Nachrichtenwarteschlan-ge können Sie mithilfe der IBM i-Überwachungsunterstützung überwachen.


Die Failover-Nachrichtenwarteschlange wird definiert, wenn eine Clusterressourcengruppe über die grafi-sche Oberfläche der Cluster Resource Services in IBM Navigator for i erstellt wird. Eine Failover-Nach-richtenwarteschlange kann außerdem mit den Befehlen CRTCRG (CRG erstellen) und CHGCRG (CRGändern) angegeben werden.

Anmerkung: Um die grafische Oberfläche der Cluster Resource Services oder die CL-Befehle benutzenzu können, muss das Lizenzprogramm IBM PowerHA SystemMirror für i installiert sein.

Die Nachrichtenwarteschlange kann auch mithilfe der nativen IBM i APIs für Clusterressourcengruppengeändert werden. Einzelheiten zu diesen APIs finden Sie in den Informationen zu den APIs für Cluster-ressourcengruppen.Zugehörige Konzepte:„Clusternachrichtenwarteschlange” auf Seite 14In IBM i-Hochverfügbarkeitsumgebungen kann eine Clusternachrichtenwarteschlange für das Empfangenund Beantworten von Nachrichten angegeben werden, die Einzelheiten zu Failover-Ereignissen im Clus-ter enthalten. Diese Nachrichtenwarteschlange enthält Informationen über alle Clusterressourcengruppen,für die ein Failover auf denselben Knoten durchgeführt wird, wenn der Primärknoten für die Clusterres-sourcengruppen beendet wird oder ausfällt.Zugehörige Informationen:CRG erstellen (CRTCRG)CRG ändern (CHGCRG)Cluster Resource Group APIs

ClusterpartitionIn IBM i-Hochverfügbarkeitsumgebungen versteht man unter einer Clusterpartition eine Untergruppe akti-ver Clusterknoten, die als Folge eines Kommunikationsfehlers gebildet wird. Die Mitglieder einer Partiti-on bleiben miteinander in Verbindung.

In einem Cluster kommt es immer dann zur Bildung einer Partition, wenn die Kommunikation zwischenKnoten im Cluster unterbrochen wird, ein Ausfall der verloren gegangenen Knoten aber nicht bestätigtwerden kann. Wenn die Bildung einer Clusterpartition festgestellt wird, lassen die Cluster Resource Servi-ces nur noch bestimmte Aktionen für die Knoten in der Clusterpartition zu. Diese Einschränkung desFunktionsumfangs geschieht, damit die Cluster Resource Services die Partitionen wieder zusammenfügenkann, sobald die Ursache für die Partitionsbildung beseitigt wurde.

In einem partitionierten Cluster sind bestimmte CRG-Operationen nur eingeschränkt möglich. Einzelhei-ten darüber, welche Operationen für die einzelnen Partitionsarten nur eingeschränkt möglich sind, findenSie unter Cluster Resource Group APIs.

Wenn eine Clusterverwaltungsdomäne partitioniert wird, werden Änderungen nach wie vor zwischenden aktiven Knoten in jeder Partition synchronisiert. Wenn die Knoten wieder zusammengefügt werden,werden alle in den einzelnen Partitionen erfolgten Änderungen von der Clusterverwaltungsdomäne wei-tergegeben, sodass die Ressourcen innerhalb der aktiven Domäne konsistent sind. Sie können auch ange-ben, wie die Wiederaufnahme von Knoten in die Clusterverwaltungsdomäne erfolgen soll.

ZusammenfügungEine Zusammenfügung ist mit einer Wiederaufnahme in einen Cluster vergleichbar, findet jedoch statt,wenn partitionierte Knoten wieder mit der Kommunikation beginnen.

Bei der Partition kann es sich um eine echte Partition handeln, bei der die Cluster Resource Services im-mer noch auf allen Knoten aktiv sind. Wegen eines Fehlers auf der Übertragungsleitung können einigeKnoten jedoch nicht mit anderen kommunizieren. Das Problem kann auch dadurch verursacht werden,dass ein Knoten tatsächlich ausgefallen ist, dieser Ausfall aber nicht erkannt wurde.


Im ersten Fall werden die Partitionen automatisch wieder zusammengeführt, sobald der Übertragungs-fehler behoben wurde. Dies geschieht, wenn beide Partitionen regelmäßig versuchen, mit den partitionier-ten Knoten zu kommunizieren und schließlich wieder Kontakt miteinander aufnehmen. Im zweiten Fallmüssen Sie den Status des partitionierten Knotens auf dem aktiven Knoten in "Ausgefallen" ändern. An-schließend können Sie die Cluster Resource Services auf diesem Knoten von einem beliebigen Knoten in-nerhalb des Clusters aus erneut starten.

Beispiel: Zusammenfügung:

In der IBM i-Clustertechnologie findet eine Zusammenfügung in unterschiedlichsten Situationen statt.

Folgende Konstellationen sind möglich:

Tabelle 2. Zusammenfügung einer primären und einer sekundären Partition

Zusammenfügung

Primäre Partition Sekundäre Partition

Tabelle 3. Zusammenfügung zweier sekundärer Partitionen

Zusammenfügung

Sekundäre Partition Sekundäre Partition

Primäre und sekundäre Partitionen gibt es ausschließlich in Clusterressourcengruppen. In einer Cluster-ressourcengruppe mit Primär- und Ausweichknoten ist eine primäre Partition als diejenige definiert, dieden als primären Zugriffspunkt angegebenen Knoten enthält. Eine sekundäre Partition ist als diejenigedefiniert, die den als primären Zugriffspunkt angegebenen Knoten nicht enthält.

Wenn sich die Knoten der Wiederherstellungsdomäne einer Peer-CRG allesamt in einer Partition befin-den, dann ist dies die primäre Partition. Wenn sich die Knoten der Wiederherstellungsdomäne nicht allein einer Partition befinden, gibt es keine primäre Partition. Beide Partitionen gelten dann als sekundärePartitionen.

Unter Synchronisation überwachter Ressourcen finden Sie Informationen über das Verhalten einer Clus-terverwaltungsdomäne während der Wiederaufnahme von Knoten.

Tabelle 4. Zusammenfügung einer primären und einer sekundären Partition

Zusammenfügung

Primäre Partition Sekundäre Partition

Enthält CRG-Kopie Enthält KEINE CRG-Kopie Enthält CRG-Kopie Enthält KEINE CRG-Kopie

(1) (2) (3) (4)

Für die Zusammenfügung einer primären und einer sekundären Partition (siehe vorheriges Diagramm)ergeben sich folgende Möglichkeiten:1. 1 und 32. 1 und 43. 2 und 3 (kann nicht vorkommen, da bei einer Mehrheitspartition der Primärknoten aktiv ist und eine

CRG-Kopie enthalten muss)4. 2 und 4 (kann nicht vorkommen, da bei einer Mehrheitspartition der Primärknoten aktiv ist und eine

CRG-Kopie enthalten muss)


Zusammenfügung einer primären und einer sekundären Partition

An alle Knoten in der sekundären Partition wird eine Kopie des CRG-Objekts gesendet. Auf den Knotenin der sekundären Partition kann dies zu folgenden Aktionen führen:v Keine Aktion, da sich der sekundäre Knoten nicht in der Wiederherstellungsdomäne der Clusterres-

sourcengruppe befindet.v Die CRG-Kopie auf einem Sekundärknoten wird mit den Daten aus der primären Partition aktualisiert.v Das CRG-Objekt wird aus dem Sekundärknoten gelöscht, da sich dieser nicht mehr in der Wiederher-

stellungsdomäne der Clusterressourcengruppe befindet.v Das CRG-Objekt wird auf dem Sekundärknoten erstellt, da das Objekt nicht vorhanden ist. Der Knoten

befindet sich jedoch in der Wiederherstellungsdomäne der CRG-Kopie, die von der primären Partitiongesendet wird.

Tabelle 5. Zusammenfügung zweier sekundärer Partitionen

Zusammenfügung

Sekundäre Partition Sekundäre Partition

Enthält CRG-Kopie Enthält KEINE CRG-Kopie Enthält CRG-Kopie Enthält KEINE CRG-Kopie

(1) (2) (3) (4)

Für eine Zusammenfügung zweier sekundärer Partitionen (siehe vorheriges Diagramm) ergeben sich fol-gende Möglichkeiten:1. 1 und 32. 1 und 43. 2 und 34. 2 und 4

Zusammenfügung zweier sekundärer Partitionen - Möglichkeit 1

Bei einer Clusterressourcengruppe mit Primär- und Ausweichknoten wird der Knoten mit der letzten Än-derung an der CRG ausgewählt, um eine Kopie des CRG-Objekts an alle Knoten in der anderen Partitionzu senden. Wenn mehrere Knoten ausgewählt werden, weil sie alle die letzte Änderung zu enthaltenscheinen, wird der Knoten anhand der Reihenfolge in der Wiederherstellungsdomäne ausgewählt.

Wenn zwei sekundäre Partitionen für eine Peer-CRG zusammengefügt werden, wird die Version mit demStatus "Aktiv" auf die anderen Knoten in der zweiten Partition kopiert. Wenn beide Partitionen den glei-chen Status haben, wird der Knoten kopiert, der als erster in der Wiederherstellungsdomäne der Cluster-ressourcengruppe aufgeführt ist.

Sowohl in einer Clusterressourcengruppe mit Primär- und Ausweichknoten als auch in einer Peer-CRGkönnen beim Empfang von Partitionsknoten die folgenden Aktionen stattfinden:v Keine Aktion, da sich der Knoten nicht in der Wiederherstellungsdomäne der Clusterressourcengruppe

befindet.v Die Clusterressourcengruppe wird auf dem Knoten erstellt, da sich dieser in der Wiederherstellungsdo-

mäne der empfangenen Kopie des CRG-Objekts befindet.v Die Clusterressourcengruppe wird aus dem Knoten gelöscht, da sich dieser nicht in der Wiederherstel-

lungsdomäne der empfangenen Kopie des CRG-Objekts befindet.

Zusammenfügung zweier sekundärer Partitionen - Möglichkeiten 2 und 3

Ein Knoten aus der Partition, die eine Kopie des CRG-Objekts enthält, wird ausgewählt, um die Objekt-daten an alle Knoten in der anderen Partition zu senden. Das CRG-Objekt kann auf Knoten in der emp-


fangenden Partition erstellt werden, wenn sich der Knoten in der Wiederherstellungsdomäne der Cluster-ressourcengruppe befindet.

Zusammenfügung zweier sekundärer Partitionen - Möglichkeit 4

Es werden interne Daten ausgetauscht, um die Konsistenz im Cluster zu wahren.

Anschließend kann eine primäre Partition in eine primäre und eine sekundäre Partition untergliedertwerden. Wenn der Primärknoten ausfällt, wird dies von den Cluster Resource Services (CRS) als Knoten-fehler erkannt. Die primäre Partition wird dann zu einer sekundären Partition. Dies geschieht auch, wennSie den Primärknoten mit der API "End Cluster Node" beendet haben. Eine sekundäre Partition kann zueiner primären Partition werden, wenn der Primärknoten durch eine Wiederaufnahme- oder eine Zusam-menfügungsoperation in der Partition aktiv wird.

Bei einer Zusammenfügung wird das Exitprogramm auf allen Knoten in der Wiederherstellungsdomäneder Clusterressourcengruppe aufgerufen; dabei spielt es keine Rolle, in welcher Partition sich der Knotenbefindet. Es wird der Aktionscode verwendet, der auch für "Wiederaufnahme" verwendet wird. Als Folgeder Zusammenfügung werden keine Rollen gewechselt, doch der Mitgliederstatus der Knoten in der Wie-derherstellungsdomäne der Clusterressourcengruppe wird von Partition in Aktiv geändert. Sobald allePartitionen zusammengefügt wurden, wird die Partitionsbedingung aufgehoben, und alle Clusterressour-cengruppen-APIs können verwendet werden.

WiederaufnahmeBei der Wiederaufnahme wird ein bis dahin nicht teilnehmendes Mitglied zu einem aktiven Mitglied einesIBM i-Clusters.

Wenn beispielsweise das Clustering auf einem zuvor inaktiven Knoten erneut gestartet wird, dann wirddieser Clusterknoten wieder in den Cluster aufgenommen. Die Cluster Resource Services werden auf ei-nem Knoten gestartet, indem sie von einem bereits im Cluster aktiven Knoten aus gestartet werden. AbClusterversion 3 kann sich ein Knoten selbst starten und in den derzeit aktiven Cluster wieder aufgenom-men werden, vorausgesetzt, er kann einen aktiven Knoten im Cluster finden. Weitere Informationen fin-den Sie unter "Clusterknoten starten".

Angenommen, die Knoten A, B und C bilden einen Cluster. Knoten A fällt aus. Die Knoten B und C bil-den jetzt den aktiven Cluster. Sobald der ausgefallene Knoten wieder betriebsbereit ist, kann er wieder inden Cluster aufgenommen werden, wenn er von einem anderen Clusterknoten aus (einschließlich ihmselbst) gestartet wird. Die Wiederaufnahme erfolgt auf der Basis von Clusterressourcengruppen, was be-deutet, dass die einzelnen Clusterressourcengruppen unabhängig voneinander in den Cluster aufgenom-men werden.

Die Hauptfunktion der Wiederaufnahme stellt sicher, dass das CRG-Objekt auf alle aktiven Knoten derWiederherstellungsdomäne repliziert wird. Sowohl der wieder aufzunehmende Knoten als auch alle vor-handenen aktiven Clusterknoten müssen über eine identische Kopie des CRG-Objekts verfügen. Außer-dem müssen sie über eine identische Kopie einiger interner Daten verfügen.

Wenn ein Knoten ausfällt, kann das fortgesetzte Aufrufen der Cluster Resource Services auf den restli-chen Knoten im Cluster zu einer Änderung der Daten in einem CRG-Objekt führen. Die Änderung mussaufgrund eines API-Aufrufs oder eines nachfolgenden Knotenfehlers erfolgen. Bei einfachen Clusternwird der wieder aufzunehmende Knoten mit einer Kopie der Clusterressourcengruppe von einem derderzeit aktiven Knoten im Cluster aktualisiert. Dies trifft jedoch möglicherweise nicht in allen Fällen zu.

Das Thema "Synchronisation überwachter Ressourcen" enthält Informationen über das Verhalten einerClusterverwaltungsdomäne während der Wiederaufnahme.


Beispiel: Wiederaufnahme:

Unter diesem Thema werden die Aktionen beschrieben, die bei der Wiederaufnahme eines Knotens in ei-nen IBM i-Cluster ausgeführt werden.

Das folgende Diagramm beschreibt die Aktionen, die jedesmal ausgeführt werden, wenn ein Knoten wie-der in einen Cluster aufgenommen wird. Außerdem wird der Status der wieder aufzunehmenden Kno-tens im Feld für den Mitgliederstatus in der CRG-Wiederherstellungsdomäne von inaktiv in aktiv geän-dert. Das Exitprogramm wird auf allen Knoten in der CRG-Wiederherstellungsdomäne aufgerufen, undes wird ihm der Aktionscode für "Wiederaufnahme" übergeben.

Tabelle 6. Wiederaufnahmeoperation

Wiederaufnahmeoperation

Wiederaufzunehmender Knoten Clusterknoten

Enthält CRG-Kopie Enthält keine CRG-Kopie Enthalten CRG-Kopie Enthalten keine CRG-Kopie

(1) (2) (3) (4)

Unter Verwendung des obigen Diagramms ergeben sich folgende Möglichkeiten:1. 1 und 32. 1 und 43. 2 und 34. 2 und 4

Wenn ein Knoten im Cluster über eine Kopie der Clusterressourcengruppe verfügt, gilt die allgemeineRegel, dass die Clusterressourcengruppe von einem aktiven Knoten im Cluster auf den wieder aufzuneh-menden Knoten kopiert wird.

Wiederaufnahme - Möglichkeit 1Eine Kopie des CRG-Objekts wird von einem Knoten im Cluster an den aufzunehmenden Knotengesendet. Ergebnis:v Das CRG-Objekt wird auf dem aufzunehmenden Knoten mit den vom Cluster gesendeten Da-

ten aktualisiert.v Das CRG-Objekt wird möglicherweise aus dem aufzunehmenden Knoten gelöscht. Das kann

passieren, wenn der aufzunehmende Knoten aus der CRG-Wiederherstellungsdomäne entferntwurde, während sich der aufzunehmende Knoten außerhalb des Clusters befand.

Wiederaufnahme - Möglichkeit 2Eine Kopie des CRG-Objekts wird vom aufzunehmenden Knoten an alle Clusterknoten gesendet.Ergebnis:v Es ändert sich nichts, wenn sich keiner der Clusterknoten in der CRG-Wiederherstellungsdo-

mäne befindet.v Das CRG-Objekt kann auf einem oder mehreren Clusterknoten erstellt werden. Das kann im

folgenden Szenario passieren:– Die Knoten A, B, C und D bilden einen Cluster.– Alle vier Knoten befinden sich in der CRG-Wiederherstellungsdomäne.– Während sich Knoten A außerhalb des Clusters befindet, wird die Clusterressourcengruppe

dahingehend geändert, dass Knoten B aus der Wiederherstellungsdomäne entfernt wird.– Die Knoten C und D fallen aus.– Der Cluster wird jetzt nur noch von Knoten B gebildet, der nicht über eine Kopie der Clus-

terressourcengruppe verfügt.– Knoten A wird wieder in den Cluster aufgenommen.


– Knoten A verfügt über die Clusterressourcengruppe (obwohl momentan niederwertig), Kno-ten B nicht. Die Clusterressourcengruppe wird auf Knoten B erstellt. Wenn die Knoten Cund D wieder in den Cluster aufgenommen werden, werden sie mit der im Cluster vorhan-denen Kopie der Clusterressourcengruppe aktualisiert, und die vorherige Änderung (dasEntfernen von Knoten B aus der Wiederherstellungsdomäne) geht verloren.

Wiederaufnahme - Möglichkeit 3Eine Kopie des CRG-Objekts wird von einem Knoten im Cluster an den aufzunehmenden Knotengesendet. Ergebnis:v Es ändert sich nichts, wenn sich der aufzunehmende Knoten nicht in der CRG-Wiederherstel-

lungsdomäne befindet.v Das CRG-Objekt wird möglicherweise auf dem aufzunehmenden Knoten erstellt. Das kann

passieren, wenn die Clusterressourcengruppe auf dem aufzunehmenden Knoten gelöscht wur-de, als die Cluster Resource Services nicht auf dem Knoten aktiv waren.

Wiederaufnahme - Möglichkeit 4Möglicherweise werden Informationen über den aufzunehmenden Knoten mithilfe interner Infor-mationen von einem der Knoten im Cluster aktualisiert, aber es geschieht nichts, was für denBenutzer sichtbar ist.

Erweiterte KnotenausfallerkennungDie erweiterte Knotenausfallerkennungsfunktion wird zur Verfügung gestellt, um die Anzahl der Aus-fallszenarios, die zu Clusterpartitionen führen, zu verringern.

Es gibt einige Ausfallsituationen, in denen die Heartbeatüberwachung nicht feststellen kann, wo genauein Ausfall aufgetreten ist. Der Ausfall kann das Ergebnis eines Kommunikationsfehlers zwischen Cluster-knoten sein oder ein Clusterknoten kann komplett ausgefallen sein. Angenommen, ein Clusterknoten fälltaus, weil in einer kritischen Hardwarekomponente, wie z. B. einem Prozessor, ein Fehler aufgetreten ist.Die gesamte Maschine kann heruntergefahren werden, ohne dass die Cluster Resource Services auf die-sem Knoten die Gelegenheit hatten, andere Clusterknoten über den Ausfall zu benachrichtigen. Die ande-ren Clusterknoten sehen nur, dass ein Fehler in der Heartbeatüberwachung aufgetreten ist. Sie könnennicht feststellen, ob der Fehler auf einen Knotenausfall zurückzuführen oder im Kommunikationspfad(Leitung, Router oder Adapter) aufgetreten ist.

Wenn ein Fehler dieser Art auftritt, nehmen die Cluster Resource Services an, dass der Knoten, der nichtantwortet, noch betriebsbereit sein könnte und den Cluster partitioniert.

In 7.1 wird eine erweiterte Knotenausfallerkennungsfunktion zur Verfügung gestellt, die verwendet wer-den kann, um die Anzahl der Ausfallszenarios, die zu Clusterpartitionen führen, zu verringern. Durch einzusätzliches Überwachungsverfahren werden weitere Informationsquellen bereitgestellt, die den ClusterResource Services ermöglichen, den Ausfall eines Clusterknotens festzustellen.

Diese erweiterte Funktion verwendet die Hardware Management Console (HMC) für IBM Systeme, dieüber eine HMC oder eine VIOS-Partition (Virtual I/O Server = virtueller E/A-Server) auf einem verwalte-ten IVM-Server (IVM = Integrated Virtualization Manager) verwaltet werden können. In beiden Fällen istdie HMC oder der IVM in der Lage, den Status der logischen Partitionen oder des gesamten Systems zuüberwachen und die Cluster Resource Services zu benachrichtigen, wenn Statusänderungen in der Partiti-on oder im System auftreten. Anhand der Informationen über die Statusänderungen können die ClusterResource Services feststellen, ob ein Clusterknoten ausgefallen ist und die Partitionierung des Clustersausschließlich anhand der Informationen aus einer Heartbeatüberwachung verhindern.


In diesem Beispiel wird eine HMC zur Verwaltung von zwei verschiedenen IBM Systemen eingesetzt. DieHMC kann beispielsweise jedes System einschalten und logische Partitionen auf jedem System konfigu-rieren. Darüber hinaus überwacht die HMC den Status jedes Systems und der logischen Partitionen aufjedem System. Angenommen, jedes System ist ein Clusterknoten und die Cluster Resource Services über-wachen den Heartbeat zwischen den beiden Clusterknoten.

Mit der erweiterten Knotenausfallerkennungsfunktion können die Cluster Resource Services für die Ver-wendung der HMC konfiguriert werden. Zum Beispiel kann Knoten A mit einer Clusterüberwachungkonfiguriert werden, die die HMC verwendet. Wenn die HMC den Ausfall von Knoten B feststellt (ent-weder des Systems oder der logischen Partition für Knoten B), informiert sie die Cluster Resource Servi-ces auf Knoten A über den Ausfall. Die Cluster Resource Services auf Knoten A markieren daraufhinKnoten B als ausgefallen und führen Failover-Maßnahmen durch statt den Cluster zu partitionieren.

Knoten B kann ebenfalls mit Clusterüberwachung konfiguriert werden. In diesem Beispiel würde dannein Ausfall von entweder Knoten A oder Knoten B dazu führen, dass der jeweils andere Knoten von derHMC eine entsprechende Benachrichtigung erhält.

Weitere Informationen über Ausfallszenarios, die zu einer Clusterpartition führen, wenn die erweiterteKnotenausfallerkennungsfunktion nicht verwendet wird, und die zu einem Knotenausfall führen, wenndie erweiterte Erkennungsfunktion verwendet wird, sind unter Failover bei Ausfallereignissen verwaltenzu finden.

Benachrichtigungen über Ausfälle durch eine HMC oder einen IVM sind davon abhängig, ob ein TCP/IP-Anwendungsserver auf dem Clusterknoten aktiv ist, der die Benachrichtigungen erhalten soll. Ist der An-wendungsserver nicht aktiv, wird die erweiterte Knotenausfallerkennungsfunktion nicht über Knotenaus-fälle informiert. Der Anwendungsserver muss gestartet werden und weiterlaufen, solange derClusterknoten aktiv ist. Verwenden Sie zum Starten des Anwendungsservers den CL-Befehl STRTCPSVR*CIMOM.


ClusterverwaltungsdomäneEine Clusterverwaltungsdomäne ist ein Mechanismus zur Aufrechterhaltung einer knotenübergreifendenkonsistenten Betriebsumgebung innerhalb einer IBM i-Hochverfügbarkeitsumgebung. Eine Clusterverwal-tungsdomäne garantiert, dass sich hoch verfügbare Anwendungen und Daten erwartungsgemäß verhal-ten, wenn sie mittels Switchover oder Failover auf Ausweichknoten umgeschaltet werden.

Häufig sind Anwendungen oder Anwendungsdaten Konfigurationsparameter oder Daten zugeordnet, diein ihrer Gesamtheit als Betriebsumgebung der Anwendung bezeichnet werden. Zu diesem Datentyp ge-hören beispielsweise Benutzerprofile für den Zugriff auf die Anwendung oder deren Daten oder System-umgebungsvariablen zur Steuerung des Anwendungsverhaltens. In einer Hochverfügbarkeitsumgebungmuss die Betriebsumgebung auf allen Systemen identisch sein, auf denen die Anwendung ausgeführtwerden kann oder auf denen sich die Anwendungsdaten befinden. Wenn Konfigurationsparameter oderDaten auf einem System geändert werden, müssen die entsprechenden Änderungen auch auf allen übri-gen Systemen erfolgen. Eine Clusterverwaltungsdomäne wird zur Angabe von Ressourcen verwendet, dieauf den Systemen in einer IBM i-Hochverfügbarkeitsumgebung konsistent verwaltet werden müssen. DieClusterverwaltungsdomäne überwacht diese Ressourcen anschließend, um Änderungen festzustellen unddiese innerhalb der gesamten aktiven Domäne zu synchronisieren.

Wenn eine Clusterverwaltungsdomäne erstellt wird, erstellt das System eine Peer-CRG gleichen Namens.Die Knoten, aus denen sich die Clusterverwaltungsdomäne zusammensetzt, werden von der Wiederher-stellungsdomäne der CRG definiert. Die Knotenzugehörigkeit zur Clusterverwaltungsdomäne kann durchHinzufügen und Entfernen von Knoten zu bzw. aus der Wiederherstellungsdomäne mit dem BefehlADDCADNODE (KNT-Eintrag zu Domäne hinzufügen) und RMVCADNODE (KNT-Eintrag aus Domäne entfernen)oder mit dem Befehl WRKCLU (Mit Cluster arbeiten) geändert werden. Jeder Clusterknoten kann nur ineiner einzigen Clusterverwaltungsdomäne innerhalb des Clusters definiert werden.

Nachdem die Clusterverwaltungsdomäne erstellt wurde, kann sie unter Verwendung von CL-Befehlenoder über die grafische Oberfläche von IBM PowerHA SystemMirror für i in IBM Navigator for i verwal-tet werden.

Anmerkung: Um mit PowerHA-Befehlen oder der grafischen Oberfläche von PowerHA arbeiten zu kön-nen, muss das Lizenzprogramm IBM PowerHA SystemMirror für i installiert sein.

Überwachte Ressourcen

Eine überwachte Ressource ist eine Systemressource, die von einer Clusterverwaltungsdomäne verwaltetwird. Änderungen, die an einer überwachten Ressource vorgenommen werden, werden knotenübergrei-fend in der Clusterverwaltungsdomäne synchronisiert und auf die Ressource auf allen aktiven Knoten an-gewendet. Überwachte Ressourcen können Systemobjekte sein, wie beispielsweise Benutzerprofile oderJobbeschreibungen. Eine überwachte Ressource kann auch eine Systemressource sein, die nicht durch einSystemobjekt dargestellt wird, z. B. ein einzelner Systemwert oder eine Systemumgebungsvariable. Dieseüberwachten Ressourcen werden in der Clusterverwaltungsdomäne als Einträge für überwachte Ressourcen(MREs) dargestellt.

Die Clusterverwaltungsdomäne unterstützt überwachte Ressourcen mit einfachen und mit zusammenge-setzten Attributen. Ein zusammengesetztes Attribut enthält keinen oder mehrere Werte, während ein ein-faches Attribut immer nur einen Einzelwert enthält. Subsystembeschreibungen (*SBSD) und Netzwerkser-verbeschreibungen (*NWSD) sind Beispiele für überwachte Ressourcen, die zusammengesetzte Attributeenthalten.

Um MREs hinzufügen zu können, muss die Ressource auf dem Knoten vorhanden sein, von dem aus dieMREs hinzugefügt werden sollen. Wenn die Ressource noch nicht auf allen Knoten in der Verwaltungsdo-mäne vorhanden ist oder wenn ein Knoten später zur Clusterverwaltungsdomäne hinzugefügt wird, wirddie überwachte Ressource erstellt. Der Clusterverwaltungsdomäne können keine MREs hinzugefügt wer-den, wenn sich die Domäne im Status Partitioniert befindet.


Der Status der Clusterverwaltungsdomäne und der Status der Knoten in der Domäne kann über die gra-fischen Oberflächen von PowerHA in IBM Navigator for i oder mit den Befehlen DSPCRGINF(CRG-Informationen anzeigen) und WRKCLU (Mit Cluster arbeiten) festgestellt werden.

Anmerkung: Um die grafische Oberfläche von PowerHA oder die PowerHA-Befehle benutzen zu kön-nen, muss das Lizenzprogramm IBM PowerHA SystemMirror für i installiert sein.Der Status einer Clusterverwaltungsdomäne kann auch mithilfe der Cluster-APIs ermittelt werden.

Sobald der Clusterverwaltungsdomäne ein MRE hinzugefügt wurde, werden Änderungen an der Res-source auf einem der aktiven Knoten in der Domäne an sämtliche Knoten in der aktiven Domäne weiter-gegeben. Wenn ein Knoten innerhalb einer Clusterverwaltungsdomäne inaktiv ist, steuert die Synchroni-sationsoption, wie Änderungen innerhalb des Clusters weitergeleitet werden. Lautet dieSynchronisationsoption "Aktive Domäne", werden alle Änderungen an der Ressource auf dem inaktivenKnoten gelöscht, sobald der Knoten wieder in den Cluster aufgenommen wird. Lautet die Synchronisati-onsoption "Letzte Änderung", werden Änderungen an der Ressource auf dem inaktiven Knoten nur danngelöscht, wenn in der Clusterverwaltungsdomäne eine aktuellere Änderung an der Ressource weitergege-ben wurde. Wenn die Clusterverwaltungsdomäne gelöscht wird, werden alle MREs, die in der Domänedefiniert sind, entfernt; die eigentliche Ressource wird jedoch aus keinem Knoten in der aktiven Domänegelöscht.

Zur Unterstützung bei der Verwaltung einer Verwaltungsdomäne mit vielen MREs können die BefehlePRTCADMRE (MRE der Verwaltungsdomäne drucken) und WRKCADMRE (Mit MREs arbeiten) verwendet wer-den. Informationen können gedruckt oder an eine Datenbankausgabedatei übertragen und zum Schreibenzusätzlicher Tools, zum Durchführen von Abfragen oder zum Verwalten der überwachten Ressource inder Verwaltungsdomäne verwendet werden. Werden die überwachten Ressourcen zu irgendeinem Zeit-punkt in den globalen Status "Inkonsistent" versetzt, kann mit dem Befehl PRTCADMRE oder WRK-CADMRE festgestellt werden, welche MREs nicht konsistent sind und auf welchen Systemen sie sich be-finden.Zugehörige Informationen:Attribute, die überwacht werden könnenClusterverwaltungsdomäne planenClusterverwaltungsdomäne erstellenEinträge für überwachte Ressourcen hinzufügenClusterverwaltungsdomäne verwaltenCluster APIsPowerHA-Befehle

PowerHA-DatenreplikationstechnologienPowerHA bietet mehrere unterschiedliche Technologien für die Datenreplikation an. Diese Technologienkönnen einzeln oder mitunter in Kombination verwendet werden, um ein höheres Schutzniveau bei Sys-temausfällen zu gewährleisten.

Die geographische Spiegelung ist eine IBM i-Replikationstechnologie, die mit jeder Art von Speicher ein-gesetzt werden kann. Die Daten werden zwischen zwei Kopien des unabhängigen ASP repliziert, wobeisynchrone und asynchrone Replikation unterstützt wird. Die geographische Spiegelung bietet Schutz so-wohl bei Server- als auch bei Speicherausfällen.

Für Kunden mit externem Speicher stehen mehrere Technologien zur Auswahl. Umschaltbare logischeEinheiten ermöglichen das Umschalten einer Kopie der Daten von einem System auf ein anderes und bie-ten Schutz bei Serverausfällen. Metro Mirror und Global Mirror sind die synchronen und asynchronenReplikationstechnologien für externen Speicher und bieten Schutz bei Server- und bei Speicherausfällen,indem die Daten von der primären Kopie des IASP auf eine Sicherungskopie repliziert werden. HyperS-wap ist eine DS8000-Technologie mit einer Ausfallzeit nahe null im Fall von Speicherausfällen. FlashCopy


ist ein Verfahren für die Erstellung von Zeitpunktkopien, das in Verbindung mit einer der Sicherungs-technologien und für andere Verwendungszwecke genutzt werden kann.

Geographische Spiegelung

Im Rahmen der IBM i-Clustertechnologie stellt die geographische Spiegelung eine HA-Lösung dar, beider eine konsistente Kopie der Daten, die in einem unabhängigen Plattenpool auf dem Produktionssys-tem gespeichert sind, in Form einer gespiegelten Kopie erzeugt wird. Bei der geographischen Spiegelungwird unter Verwendung interner oder externer Speichereinheiten eine konsistente Sicherungskopie einesunabhängigen Plattenpools vorgehalten.

Kommt es am Produktionsstandort zu einer Betriebsunterbrechung, wird die Produktion auf den Aus-weichstandort umgeschaltet, der die spiegelgleiche Kopie der Daten enthält und sich in der Regel an ei-nem anderen Standort befindet. Beim synchronen Übermittlungsmodus erfolgt die Datenspiegelung,bevor die Schreiboperation auf dem Produktionssystem beendet ist, und wird normalerweise für Anwen-dungen eingesetzt, bei denen im Fehlerfall keinerlei Datenverlust hingenommen werden kann. Beimasynchronen Übermittlungsmodus werden die Daten ebenfalls an die Spiegelkopie gesendet, bevor dieSchreiboperation beendet ist, die Steuerung wird jedoch an die Anwendung zurückgegeben, bevor diespiegelgleiche Schreiboperation tatsächlich auf der Spiegelkopie ankommt.

Soll die Anwendung sicherstellen, dass alle abgeschlossenen Schreiboperationen am Produktionsstandortauch am Standardort der Spiegelkopie angekommen sind, ist dies ein guter Grund für die Verwendungdes synchronen Übermittlungsmodus.

Die geographische Spiegelung ist eine logische Spiegelung auf Seitenebene zwischen unabhängigen Plat-tenpools, bei der die Datenportservices genutzt werden. Datenportservices verwalten Verbindungen fürmehrere IP-Adressen, was zur Redundanz und einer höheren Bandbreite in Umgebungen mit geographi-scher Spiegelung führt.

Bei der geographischen Spiegelung sind Produktions- und Spiegelkopie geographisch voneinander ge-trennt, was als Schutzmaßnahme für den Fall eines Komplettausfalls an einem Standort vorgesehen ist.Bei der Planung einer Lösung mit geographischer Spiegelung sollte berücksichtigt werden, dass sich dieEntfernung zwischen dem unabhängigen Plattenpool am Produktionsstandort und dem gespiegelten un-abhängigen Plattenpool auf die Antwortzeit der Anwendung auswirken kann. Größere Entfernungen zwi-schen Produktions- und Spiegelkopie können längere Antwortzeiten zur Folge haben. Bevor Sie eine HA-Lösung mit geographischer Spiegelung implementieren, sollten Sie wissen, welche Entfernungen in IhremFall notwendig sind und welche Auswirkungen diese auf die Leistung Ihrer Anwendungen haben.

Beim asynchronen Übermittlungsmodus sind die Auswirkungen auf die Antwortzeiten der Anwendunggeringer als beim synchronen Übermittlungsmodus. Große Latenzzeiten können einen höheren Bedarf anHauptspeicher- und CPU-Ressourcen für den asynchronen Übermittlungsmodus zur Folge haben.

Die geographische Spiegelung ist eine Technologie, die mit IBM PowerHA SystemMirror für i zur Verfü-gung gestellt wird.

Geographische Spiegelung mit asynchronem Übermittlungsmodus steht nur in PowerHA Version 2.0 oderhöheren Versionen zur Verfügung.Zugehörige Informationen:Geographische Spiegelung planenGeographische Spiegelung konfigurierenGeographische Spiegelung verwaltenSzenario: Geographische Spiegelung


|

|||||

||||||||

|||

||||

||||||||

|||

||

||

|

|

|

|

|

Metro MirrorSie können eine IBM i-Hochverfügbarkeitslösung in Form von Metro Mirror konfigurieren. Bei MetroMirror wird eine konsistente Datenkopie auf zwei externen IBM System Storage-Speichereinheiten vorge-halten.

In Verbindung mit der Clustertechnologie bietet Metro Mirror eine HA-Lösung mit Wiederherstellungs-funktion. Ebenso wie bei der geographischen Spiegelung werden auch bei dieser Technologie Daten ge-spiegelt, die in unabhängigen Plattenpools gespeichert sind. Bei Metro Mirror befinden sich die Plattenjedoch in externen IBM System Storage-Speichereinheiten. Das Spiegeln erfolgt von den externen Quellen-speichereinheiten, die sich normalerweise am Produktionsstandort befinden, auf eine Reihe externer Ziel-speichereinheiten, die sich normalerweise am Ausweichstandort befinden. Durch das Spiegeln der Datenzwischen den externen Speichereinheiten ist die Verfügbarkeit sowohl bei geplanten als auch ungeplantenBetriebsunterbrechungen gewährleistet.

Metro Mirror ist eine Funktion der externen Speichereinheit, bei der die Zielkopie eines Datenträgersständig aktualisiert wird, damit sie immer mit dem Änderungsstand des Quellendatenträgers überein-stimmt. Diese Funktion wird normalerweise für Anwendungen eingesetzt, bei denen im Fehlerfall keiner-lei Datenverlust hingenommen werden kann. Quellen- und Zieldatenträger können sich auf derselbenoder auf unterschiedlichen externen Speichereinheiten befinden. Bei unterschiedlichen Einheiten kann sichdie Zieleinheit an einem bis zu 300 Kilometer entfernten Standort befinden. Bei der synchronen Übertra-gung über eine solche Entfernung hinweg kann es jedoch zu Auswirkungen auf die Leistung kommen,sodass es sinnvoller ist, die Entfernung zu verkürzen, um die negativen Auswirkungen auf die Leistungzu minimieren.Zugehörige Informationen:Metro Mirror planenMetro Mirror konfigurierenMetro Mirror verwaltenSzenario: Metro MirrorVon PowerHA unterstützte Speicherserver

Global MirrorSie können eine IBM i-Hochverfügbarkeitslösung in Form von Global Mirror konfigurieren. Bei GlobalMirror wird eine konsistente Datenkopie auf zwei externen IBM System Storage-Speichereinheiten vorg

IBM i: Hochverfügbarkeit - Technologien...„Bemerkungen” auf Seite 41 gelesen wer den. Dieses...

Documents

Transcript of IBM i: Hochverfügbarkeit - Technologien...„Bemerkungen” auf Seite 41 gelesen wer den. Dieses...