IBM i Verfügbarkeit Hochverfügbarkeit - Technologien...Informationen, die nur für bestimmte...

IBM i

Verfügbarkeit Hochverfügbarkeit - Technologien7.1

��

HinweisVor Verwendung dieser Informationen und des darin beschriebenen Produkts sollten die Informati-onen unter „Bemerkungen”, auf Seite 43 gelesen werden.

Diese Ausgabe bezieht sich auf IBM i 7.1 (Produktnummer 5770-SS1) und alle nachfolgenden Releases und Modifi-kationen, bis dieser Hinweis in einer Neuausgabe geändert wird. Diese Version kann nicht auf allen RISC-Modellen(RISC = Reduced Instruction Set Computer) ausgeführt werden. Auf CICS-Modellen ist sie nicht ausführbar.

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

© Copyright International Business Machines Corporation 2008, 2010© Copyright IBM Deutschland GmbH 2010

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:SW TSC GermanyKst. 2877Februar 2010

Inhaltsverzeichnis

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

Clusterkonzepte . . . . . . . . . . . . 4Basisclusterfunktionen . . . . . . . . . . 12Clusterereignisse . . . . . . . . . . . 15

Erweiterte Knotenausfallerkennung . . . . . . 23Clusterverwaltungsdomäne . . . . . . . . . 25Umschaltbare Platten . . . . . . . . . . . 26Umschaltbare logische Einheiten . . . . . . . 27Umschaltbare Einheiten . . . . . . . . . . 27Standortübergreifende Spiegelung . . . . . . . 28

Geographische Spiegelung . . . . . . . . 28Metro Mirror . . . . . . . . . . . . . 29Global Mirror. . . . . . . . . . . . . 30

FlashCopy . . . . . . . . . . . . . . . 30

Verwaltung der Hochverfügbarkeit . . . . . . 31Schnittstellen des IBM PowerHA für i . . . . 31Versionsunterstützung für IBM PowerHA für i . 33Option 41 (HA Switchable Resources) . . . . 38Hochverfügbarkeitsfunktion im Basisbetriebssys-tem . . . . . . . . . . . . . . . . 38IBM Business Partner für Cluster-Middlewareund verfügbare Clustering-Produkte . . . . . 39

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

Anhang. Bemerkungen . . . . . . . . 43Informationen zu Programmierschnittstellen . . . 45Marken . . . . . . . . . . . . . . . . 45Bedingungen . . . . . . . . . . . . . . 45

iii

||

||

|

iv IBM i: Verfügbarkeit 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 i-Hochverfügbarkeitslösungen, einschließlich der meisten Implementierungen von Geschäfts-partnern, basieren auf den IBM i Cluster Resource Services oder, einfacher gesagt, Clustern. Cluster bil-den die zugrunde liegende Infrastruktur, die ein automatisches oder manuelles Umschalten ausfallsiche-rer Ressourcen, wie beispielsweise Daten, Einheiten und Anwendungen, zwischen Systemen ermöglicht.Diese Infrastruktur ermöglicht die Fehlererkennung und -intervention, so dass die Cluster Resource Servi-ces im Falle einer Betriebsunterbrechung entsprechend reagieren können, wobei die Sicherheit Ihrer Da-ten gewahrt und der Geschäftsbetrieb fortgesetzt wird.

Die zweite Schlüsseltechnologie im Rahmen der IBM i-Hochverfügbarkeit stellen unabhängige Platten-pools dar. Mithilfe unabhängiger Plattenpools können Daten und Anwendungen auf Platten gespeichertwerden, die während des Systembetriebs gegenwärtig sein können oder nicht. Wenn unabhängige Plat-tenpools Bestandteil eines Clusters sind, können die in den Pools gespeicherten Daten und Anwendungenauf andere Systeme oder logische Partitionen umgeschaltet werden. Unterschiedliche Technologien, wiebeispielsweise umschaltbare Platten, standortübergreifende Spiegelung sowie Metro Mirror und GlobalMirror, basieren auf unabhängigen Plattenpools. Die Entscheidung darüber, welche dieser Technologiendie Grundlage für Ihre HA-Lösung bilden soll, hängt von mehreren Faktoren ab. Das Thema "Hochver-fügbarkeit - Überblick" enthält einen problemorientierten Vergleich dieser Technologien sowie Kriterien,mit deren Hilfe Sie feststellen können, welche Technologien für Ihre Zwecke am besten geeignet sind.

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.1Im Folgenden finden Sie die Informationen zur Themensammlung "Hochverfügbarkeit - Technologien",die neu hinzugekommen sind oder erheblich geändert wurden.

Erweiterte Funktionalität bei IBM PowerHA für i, Lizenzprogrammnummer 5770-HAS

Das Lizenzprogramm IBM PowerHA für i wurde für 7.1 funktional erweitert. Sowohl den grafischenOberflächen als auch der Befehlszeilenschnittstelle und den APIs wurden Funktionen hinzugefügt. Dieseneuen Funktionen unterstützen Administratoren bei der Konfiguration und Verwaltung von Hochverfüg-barkeitslösungen. Details zu den Features der einzelnen Schnittstellen finden Sie unter den folgendenThemen:v Grafische Oberfläche des High Availability Solutions Managerv Grafische Oberfläche der Cluster Resource Servicesv Befehle von IBM PowerHA für iv APIs für IBM PowerHA für i

Erweiterte Knotenausfallerkennung

Die IBM i Cluster Resource Services können jetzt mithilfe der Hardware Management Console (HMC)oder einer VIOS-Partition (Virtual I/O Server) erkennen, wenn ein Clusterknoten ausfällt. Diese neue

1

||||||||||

|||||

|

|

|

|

||

Funktionalität ermöglicht es, eine größere Anzahl von Ausfallszenarios eindeutig zu identifizieren undClusterpartitionen zu vermeiden. Details finden Sie unter den folgenden Themen:v Erweiterte Cluster Resource Services-Schnittstellenv Cluster Control APIsv Befehle

– Neuer Befehl Clusterüberwachung hinzufügen (ADDCLUMON)– Neuer Befehl Clusterüberwachung ändern (CHGCLUMON)– Neuer Befehl Clusterüberwachung entfernen (RMVCLUMON)

Asynchroner Übermittlungsmodus bei der geographischen Spiegelung

Die geographische Spiegelung unterstützt jetzt den neuen asynchronen Übermittlungsmodus, der dieLaufzeitleistung von Anwendungen verbessern und größere Entfernungen zwischen zwei Systemen un-terstützen kann. Die meisten Anwendungen, die geographische Spiegelung verwenden, können den asyn-chronen Übermittlungsmodus tolerieren. Details finden Sie unter den folgenden Themen:v Geographische Spiegelungv Erweiterter Befehl ASP-Sitzung ändern (CHGASPSSN)v Erweiterter Befehl ASP-Sitzung anzeigen (DSPASPSSN)

Neue Befehle für Hochverfügbarkeit

Die folgenden Befehle wurden dem Lizenzprogramm IBM PowerHA für i hinzugefügt.v Neuer Befehl MRE der Verwaltungsdomäne drucken (PRTCADMRE)v Neuer Befehl Cluster abrufen (RTVCLU)v Neuer Befehl CRG abrufen (RTVCRG)v Neuer Befehl Retrieve ASP Session (RTVASPSSN)v Neuer Befehl ASP-Kopienbeschreibung abrufen (RTVASPCPYD)

Unterstützung für Versionssteuerung bei PowerHA

In i 7.1 wurde dem PowerHA-Lizenzprogramm Versionssteuerung hinzugefügt. Eine PowerHA-Versionstellt die Stufe der IBM PowerHA für i-Funktion dar, die in einem Cluster zur Verfügung steht. Vom Kon-zept her und nach der Implementierungsweise entspricht sie der Clusterversion.

Neuer PowerHA-Server-Job

Wenn Clustering aktiv und die aktuelle PowerHA-Version 2.0 oder eine höhere Version ist, ist der Pow-erHA-Server-Job aktiv. Der Jobname ist QHASVR und der Job wird im Subsystem QSYSWRK unter demBenutzerprofil QHAUSRPRF ausgeführt.

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 (ca. 580 KB).

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

(ca. 50 KB) enthält die folgenden Themen:

2 IBM i: Verfügbarkeit Hochverfügbarkeit - Technologien

||

|

|

|

|

|

|

||||

|

|

|

|

|

|

|

|

|

|

|

|

|

|||

– Vorteile der Hochverfügbarkeit– Komponenten der Hochverfügbarkeit– Kriterien der Hochverfügbarkeit– Vergleich von verschiedenen HA-Technologien

v Hochverfügbarkeit - Implementierung

(ca. 4123 KB) enthält die folgenden Themen:– Lizenzprogramm IBM PowerHA für i (iHASM), 5770-HAS, installieren– Hochverfügbarkeit - Implementierung mit lösungsbasiertem Ansatz– Hochverfügbarkeit - Implementierung mit taskbasiertem Ansatz– Hochverfügbarkeit verwalten– Fehlerbehebung für HA-Lösung

v Hochverfügbarkeit - Implementierung mit lösungsbasiertem Ansatz

(ca. 794 KB) enthält die folgenden Themen:– HA-Lösung auswählen– HA-Lösung prüfen– HA-Lösung konfigurieren– HA-Lösung verwalten

v Hochverfügbarkeit - Implementierung mit taskbasiertem Ansatz

(ca. 3441 KB) enthält die folgenden Themen:– Hochverfügbarkeit planen– Hochverfügbarkeit konfigurieren– Szenarios: HA-Lösungen konfigurieren– Hochverfügbarkeit verwalten– Szenarios: Hochverfügbarkeit verwalten– Fehlerbehebung für HA-Lösung

PDF-Dateien speichern

So können Sie eine PDF-Datei zum Anzeigen oder folgendermaßen Drucken auf Ihrer Workstation spei-chern:1. Klicken Sie mit der rechten Maustaste auf den PDF-Link in Ihrem Browser.2. Klicken Sie auf die Option, mit die PDF-Datei lokal gespeichert wird.3. Navigieren Sie zu dem Verzeichnis, in dem Sie die PDF-Datei speichern möchten.4. Klicken Sie auf Speichern.

Adobe® Reader herunterladen

Zum Anzeigen oder Drucken der PDF-Dateien muss auf Ihrem System Adobe Reader installiert sein. Von

der Adobe-Website (www.adobe.com/products/acrobat/readstep.html) können Sie eine kostenloseKopie dieses Programms herunterladen.

Hochverfügbarkeit - Technologien 3

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

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

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 IP-Übernahmeadresse ermöglicht den Zugriff auf eine Anwendung ohneRücksicht darauf, auf welchem System die Anwendung derzeit aktiv ist. Auf diese Weise können ausfall-sichere Anwendungen bei einem Systemausfall von einem Knoten auf einen anderen umgeschaltet wer-den.

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

Logische Replikation planenDaten-Clusterressourcengruppen erstellen

Einheiten-CRG:

Eine Einheiten-CRG unterstützt die Ausfallsicherheit von Einheiten in IBM i-Hochverfügbarkeitsumge-bungen. Eine Einheiten-CRG besteht aus einem Pool von Hardwareressourcen, die als eine Entität umge-schaltet werden können. Die Ressourcennamen für alle Einheiten, die sich in einer Einheiten-CRG befin-den, sind auf den Knoten in der Wiederherstellungsdomäne reserviert. Einheiten können nur auf Knotenumgeschaltet werden, die sich in der Wiederherstellungsdomäne für die Einheiten-CRG befinden.

Mit Einheiten-CRGs können umschaltbare Ressourcen in einer IBM i-Hochverfügbarkeitsumgebung ge-steuert werden. Die Einheiten-CRG enthält eine Liste mit umschaltbaren Einheiten. Zu den umschaltbarenEinheiten gehören Einheitenbeschreibungen, wie z. B. für einen unabhängigen Plattenpool, eine Band-oder optische Einheit, eine Leitung oder einen Netzwerkserver. Im Falle einer Betriebsunterbrechung, obgeplant oder ungeplant, wird der gesamte Einheitenverbund auf den Ausweichknoten umgeschaltet. Op-tional können die Einheiten auch im Rahmen des Switchover- oder Failoverprozesses verfügbar gemacht(angehängt) werden. Wenn Sie unabhängige Plattenpools verwenden, können Sie entweder einen neuenPlattenpool erstellen oder einen vorhandenen Plattenpool verwenden. Wenn Sie andere umschaltbare Ein-heiten als Plattenpools verwenden, müssen Sie vorhandene Einheiten verwenden.

Einheiten-CRGs werden auch in Umgebungen mit standortübergreifender Spiegelung verwendet. BeiTechnologien für standortübergreifende Spiegelung, wie z. B. geographische Spiegelung oder Metro Mir-ror, werden Daten von einem unabhängigen Plattenpool am Produktionsstandort auf einen unabhängigenPlattenpool am Ausweichstandort gespiegelt (kopiert). Normalerweise sind beide Standorte geographischvoneinander getrennt, was dem Katastrophenschutz dient, d. h. die Wiederherstellung nach einem Katas-trophenfall ermöglicht. In diesen Umgebungen steuert die Einheiten-CRG das Umschalten zwischen dengespiegelten Kopien eines unabhängigen Plattenpools. Wenn es am Produktionsstandort zu einem Sys-temausfall kommt, wird die Produktion von der Einheiten-CRG auf die gespiegelte Kopie des unab-hängigen Plattenpools umgeschaltet.

Ein Exitprogramm ist für eine Einheiten-CRG zwar nicht erforderlich, könnte jedoch eingesetzt werden,um das Anhängen einzelner Einheiten zu steuern. Bei einigen Einheiten kann das Anhängen viel Zeit inAnspruch nehmen; sofern diese Einheiten für die Geschäftsanwendung nicht kritisch sind, könnten sieasynchron über das Exitprogramm angehängt werden.

Eine Einheiten-CRG unterstützt mehrere Arten von umschaltbaren Einheiten. Die folgende Liste enthältdas Konfigurationsobjekt und den Einheitentyp der einzelnen unterstützten umschaltbaren Einheiten.


|||||||||

Tabelle 1. Von Einheiten-CRGs unterstützte Einheiten

Konfigurationsobjekt Einheitentyp Wert

Einheitenbeschreibung Verschlüsselungseinheit CRP

Plattenpool ASP

Netzwerk-Server-Host-Adapter NWSH

Optische Einheit OPT

Bandeinheit TAP

Leitungsbeschreibung Asynchrone Leitung ASC

Bisynchrone Leitung BSC

DDI-Leitung DDI

Ethernet-Leitung ETH

Faxleitung FAX

PPP-Leitung (Point-to-Point Protocol) PPP

SDLC-Leitung (Synchronous DataLink Control)

SDLC

Token-Ring-Leitung TRN

Drahtlose Leitung WLS

X.25-Leitung X25

Steuereinheitenbeschreibung Lokale Datenstationssteuereinheit LWS

Bandsteuereinheit TAP

Netzwerk-Server-Beschreibung Netzwerk-Server NWS


Einheiten-Clusterressourcengruppen erstellenDaten-Clusterressourcengruppen 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.

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 Ausweichknoten


mü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 der Primär-knoten ausfallen sollte. Bei Modellen aus Primär- und Ausweichknoten reagieren IBM i-Cluster automa-tisch auf der Basis dieser Rollendefinitionen, wenn ein Knoten ausfällt oder umgeschaltet wird. Beispiel:Wenn der als Primärknoten definierte Knoten A ausfällt, wird der als erster Ausweichknoten definierteKnoten B zum neuen Primärknoten. Die Reihenfolge der übrigen als Ausweichknoten definierten Knotenwird 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 der Einheitenressource.v In einer Peer-CRG wird kein Primärknoten unterstützt.

Wenn der Primärknoten einer Clusterressourcengruppe ausfällt oder ein manuelles 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 manuelles 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 für i, Lizenzprogrammnummer 5770-HAS, arbeiten, ist Clus-terversion 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+1) entspricht, darf der Knotennicht am Cluster teilnehmen. Beachten Sie, dass die aktuelle Clusterversion zuerst 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. 5.4-Knoten zusammen mit 6.1-Knoten vorhanden sein sollen, können Sie folgendermaßen vor-gehen:v Erstellen Sie den Cluster auf einem 5.4-Knoten und fügen Sie den 6.1-Knoten hinzu.v Erstellen Sie den Cluster auf einem 6.1-Knoten und geben Sie an, dass Knoten vorheriger Versionen

dem Cluster hinzugefügt werden dürfen. Fügen Sie anschließend 5.4-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 einen Clusterversionsstand voneinander abweichen.

Sobald alle Knoten im Cluster auf das nächste Release aufgerüstet wurden, kann auch die Clusterversionaufgerüstet 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 oder eineVersion höher als diese ist, kommt es beim Neustart des Clusterknotens zu einem Fehler. Als Fehlerbehe-bungsmaßnahme muss der Cluster auf diesem Knoten gelöscht und die Clusterversion angepasst werden,bevor der Knoten erneut dem Cluster hinzugefügt werden kann.

Achtung: Wenn Sie in Ihrem Cluster mit umschaltbaren unabhängigen Plattenpools arbeiten, gibt esEinschränkungen beim Switchover zwischen den Releases. Sie müssen einen unabhängigen Plattenpoolaus einem früheren Release auf einen Knoten umschalten, auf dem das aktuelle Release von IBM i ausge-führt wird, und ihn verfügbar machen. Sobald der Plattenpool auf dem Knoten mit dem aktuellen Re-lease von IBM i verfügbar ist, wird sein interner Inhalt geändert, und er kann nicht mehr für den Knotenmit dem Vorgängerrelease verfügbar gemacht werden.

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.


||

|

||


Cluster mit verschiedenen Releases planenClusterversion eines Clusters ändernSzenario: 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 Clustersystem-jobs beenden kann, was zu Problemen im Cluster und in der HA-Umgebung führen würde. Wenn dasClustering 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 QDFTJOBD ausgeführt.Zugehörige Informationen

Beispiel: Failover bei AusfallereignissenCluster 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

Netzwerk 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 skno ten

Re la i s -kno ten

Rou te r

Re la i s -kno ten

R e la i s -kno ten

Netzwerk 1

Log isches Ne tzwerk Ne tzwerk 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 System 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 manuelles 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 dieSwitchoverreihenfolge festgelegt wird.

Wenn Sie ein administratives 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 ein geordnetes 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 Failoververarbeitung von Einheiten-CRGs werden die Einheiten abgehängt, die der Clusterres-sourcengruppe zugeordnet sind. Dies geschieht auch dann, wenn das Failover über die Cluster- oder dieFailovernachrichtenwarteschlange abgebrochen wird. Einige Systemaktionen, die ein Failover verursa-chen, wie beispielsweise das Beenden von TCP/IP, betreffen nicht das gesamte System, so dass 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 Failovernachrichtenwarteschlange empfängt für alle im Cluster definierten ClusterressourcengruppenNachrichten hinsichtlich der Failoveraktivität. In der Clusternachrichtenwarteschlange können Sie auchfür alle Clusterressourcengruppen, für die ein Failover auf denselben Knoten erfolgt, gleichzeitig eine ein-zige Nachricht empfangen. Beide Nachrichtenwarteschlangen geben Ihnen die Möglichkeit, die Failover-verarbeitung von Clusterressourcengruppen und Knoten zu steuern. Wenn sowohl die Clusternachrich-tenwarteschlange als auch die Failovernachrichtenwarteschlange konfiguriert sind, hat die Cluster-nachrichtenwarteschlange Priorität. Wenn Sie lieber für jede einzelne Clusterressourcengruppe in einemCluster Failovernachrichten wünschen, sollten Sie die Clusternachrichtenwarteschlange nicht konfigurie-ren. Die Aktivitäten beider Nachrichtenwarteschlangen können Sie mithilfe der IBM i-Überwachungs-unterstützung überwachen.Zugehörige Konzepte

„Wiederherstellungsdomäne” auf Seite 7Innerhalb 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 Failoverereignissen im Clusterenthalten. Diese Nachrichtenwarteschlange enthält Informationen über alle Clusterressourcengruppen, fürdie ein Failover auf denselben Knoten durchgeführt wird, wenn der Primärknoten für die Clusterressour-cengruppen beendet wird oder ausfällt.

Clusternachrichtenwarteschlange und Failovernachrichtenwarteschlange sind annähernd gleich aufgebaut,doch empfängt die Clusternachrichtenwarteschlange statt einer Nachricht pro Clusterressourcengruppeeine einzige Nachricht für sämtliche Clusterressourcengruppen, für die ein Failover auf denselben Knotendurchgeführt wird. Wenn sowohl die Clusternachrichtenwarteschlange als auch die Failovernachrichten-warteschlange konfiguriert ist, hat die Clusternachrichtenwarteschlange Priorität. Wenn Sie lieber für jedeeinzelne Clusterressourcengruppe in einem Cluster Failovernachrichten erhalten möchten, sollten Sie dieClusternachrichtenwarteschlange nicht konfigurieren. Die Aktivitäten beider Nachrichtenwarteschlangenkönnen Sie mithilfe der IBM i-Überwachungsunterstützung überwachen.

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

Tabelle 2. Aktionen für Cluster- und Failovernachrichtenwarteschlange

DefinierteClusternachrichtenwarteschlange

DefinierteFailovernachrichtenwarteschlange Reaktion

Nein Nein Failover wird ohne Benutzeraktionfortgesetzt

Nein Ja An die Failovernachrichtenwarte-schlangen aller CRGs auf demersten Ausweichknoten wird eineNachricht (CPABB01) gesendet


Tabelle 2. Aktionen für Cluster- und Failovernachrichtenwarteschlange (Forts.)

DefinierteClusternachrichtenwarteschlange

DefinierteFailovernachrichtenwarteschlange 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 die Clusternach-richtenwarteschlange auf dem erstenAusweichknoten gesendet, der dieeine CRG steuert, für die ein Failoverauf diesen Knoten durchgeführt wird.

Ja Ja CRG-Failovernachrichtenwarte-schlange wird ignoriert. Für Failoverauf Knotenebene wird eine 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 die Clusternach-richtenwarteschlange auf dem erstenAusweichknoten gesendet, der dieeine CRG steuert, für die ein Failoverauf diesen Knoten durchgefü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 Failovernachricht gewartet werden soll. Sobald dieser Zeitraum überschrittenwird, wird die angegebene Standardaktion für das Failover ausgeführt.Zugehörige Konzepte

„Failovernachrichtenwarteschlange”Die Failovernachrichtenwarteschlange empfängt für alle in einem IBM i-Cluster definierten Clusterres-sourcengruppen Nachrichten hinsichtlich der Failoveraktivität.Zugehörige Informationen

Start Watch (STRWCH)

Failovernachrichtenwarteschlange:

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

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


Die Failovernachrichtenwarteschlange wird definiert, wenn eine Clusterressourcengruppe über die grafi-sche Oberfläche der Cluster Resource Services in IBM Systems Director Navigator for i5/OS erstellt wird.Eine Failovernachrichtenwarteschlange kann außerdem mit den Befehlen CRTCRG (CRG erstellen) undCHGCRG (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 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 16In IBM i-Hochverfügbarkeitsumgebungen kann eine Clusternachrichtenwarteschlange für das Empfangenund Beantworten von Nachrichten angegeben werden, die Einzelheiten zu Failoverereignissen im Clusterenthalten. Diese Nachrichtenwarteschlange enthält Informationen über alle Clusterressourcengruppen, fürdie ein Failover auf denselben Knoten durchgeführt wird, wenn der Primärknoten für die Clusterressour-cengruppen 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, so dass 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 3. Zusammenfügung einer primären und einer sekundären Partition

Zusammenfügung

Primäre Partition Sekundäre Partition

Tabelle 4. 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 5. 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 6. 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 empfangenden Partition erstellt werden, wenn sich der Knotenin der Wiederherstellungsdomäne der Clusterressourcengruppe 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 7. 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.


Die 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 verwaltet werden können, oder eine VIOS-Partition (Virtual I/O Server) für IBM Syste-me, die über den VIOS verwaltet werden können. In beiden Fällen ist die HMC oder der VIOS in derLage, den Status der logischen Partitionen oder des gesamten Systems zu überwachen und die ClusterResource Services zu benachrichtigen, wenn Statusänderungen in der Partition oder im System auftreten.Anhand der Informationen über die Statusänderungen können die Cluster Resource Services feststellen,ob ein Clusterknoten ausgefallen ist und die Partitionierung des Clusters ausschließlich anhand der Infor-mationen 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 Failovermaß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.

Ob eine Benachrichtigung über Ausfälle durch einen HMC oder einen VIOS erfolgt, ist davon abhängig,ob ein TCP/IP-Anwendungsserver auf dem Clusterknoten ausgeführt wird, der die Benachrichtigung er-halten soll. Ist der Anwendungsserver nicht aktiv, wird die erweiterte Knotenausfallerkennungsfunktionüber Knotenausfälle nicht informiert. Der Anwendungsserver muss gestartet werden und weiterlaufen,solange der Clusterknoten aktiv ist. Verwenden Sie zum Starten des Anwendungsservers den CL-BefehlSTRTCPSVR *CIMOM.


|

|

|||||

||||||

|||

||||

||||||

Clusterverwaltungsdomäne

Eine 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 Syste-mumgebungsvariablen 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 (Knoteneintrag Domäne hinzufügen) und RMVCADNODE (Knoteneintrag Domäne ent-fernen) oder mit dem Befehl WRKCLU (Mit Cluster arbeiten) geändert werden. Jeder Clusterknoten kannnur in einer einzigen Clusterverwaltungsdomäne innerhalb des Clusters definiert werden.

Nachdem die Clusterverwaltungsdomäne erstellt wurde, kann sie mithilfe von CL-Befehlen oder der gra-fischen Oberfläche der Cluster Resource Services in IBM Systems Director Navigator for i verwaltet wer-den.

Anmerkung: Um mit CL-Clusterbefehlen oder der grafischen Oberfläche der Cluster Resource Servicesarbeiten zu können, muss das Lizenzprogramm IBM PowerHA 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.

Damit MREs hinzugefügt werden können, muss die Ressource auf dem Knoten vorhanden sein, von demaus die MREs hinzugefügt werden sollen. Wenn die Ressource noch nicht auf allen Knoten in der Verwal-tungsdomäne vorhanden ist, wird die überwachte Ressource erstellt. Wenn ein Knoten später zur Cluster-verwaltungsdomäne hinzugefügt wird, wird die überwachte Ressource erstellt. MREs können der Cluster-


||||

|||||||||||

|||

||

|||||

||||

verwaltungsdomäne nur dann hinzugefügt werden, wenn alle Knoten in der Domäne aktiv und an derGruppe beteiligt sind. MREs können der Clusterverwaltungsdomäne nicht hinzugefügt werden, wennsich die Domäne im Status Partitioniert befindet.

Der Status der Clusterverwaltungsdomäne und der beteiligten Knoten kann mithilfe der grafischen Ober-fläche der Cluster Resource Services in IBM Systems Director Navigator for i oder der Befehle DSPCR-GINF (CRG-Informationen anzeigen) und WRKCLU (Mit Cluster arbeiten) ermittelt werden.

Anmerkung: Um die grafische Oberfläche der Cluster Resource Services oder den CL-Befehl DSPCR-GINF (CRG-Informationen anzeigen) verwenden zu können, muss das LizenzprogrammIBM PowerHA 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 die Synchronisa-tionsoption "Aktive Domäne", werden alle Änderungen an der Ressource auf dem inaktiven Knoten ge-löscht, sobald der Knoten wieder in den Cluster aufgenommen wird. Lautet die Synchronisationsoption"Letzte Änderung", werden Änderungen an der Ressource auf dem inaktiven Knoten nur dann gelöscht,wenn in der Clusterverwaltungsdomäne eine aktuellere Änderung an der Ressource weitergegeben wur-de. Wenn die Clusterverwaltungsdomäne gelöscht wird, werden alle MREs, die in der Domäne definiertsind, entfernt; die eigentliche Ressource wird jedoch aus keinem Knoten in der aktiven Domäne gelöscht.

Zur Unterstützung bei der Verwaltung einer Verwaltungsdomäne mit vielen MREs kann der Befehl PRT-CADMRE (MRE der Verwaltungsdomäne drucken) verwendet werden. Informationen können gedrucktoder an eine Datenbankausgabedatei übertragen werden und zum Schreiben zusätzlicher Tools, zumDurchführen von Abfragen oder zum Verwalten der überwachten Ressource in der Verwaltungsdomäneverwendet werden. Werden die überwachten Ressourcen zu irgendeinem Zeitpunkt in den globalen Sta-tus "Inkonsistent" versetzt, kann mit dem Befehl PRTCADMRE festgestellt werden, welche MREs nichtkonsistent sind und auf welchen Systemen sie sich befinden.Zugehörige Informationen

Attribute, die überwacht werden könnenClusterverwaltungsdomäne planenClusterverwaltungsdomäne erstellenEinträge für überwachte Ressourcen hinzufügenClusterverwaltungsdomäne verwaltenCluster APIsIBM System i High Availability Solutions Manager commands

Umschaltbare PlattenEine umschaltbare Platte ist ein unabhängiger Plattenpool, der von einer Einheiten-CRG gesteuert wirdund zwischen den Knoten innerhalb eines Clusters umgeschaltet werden kann. Die Kombination aus um-schaltbaren Platten und IBM i-Clustertechnologie ermöglicht die Erarbeitung einer einfachen und kosten-effizienten HA-Lösung für geplante und ungeplante Betriebsunterbrechungen.

Der unabhängige Plattenpool wird von der Einheiten-CRG gesteuert; im Fall einer ungeplanten Betriebs-unterbrechung kann er automatisch umgeschaltet werden, ansonsten ist auch eine manuelle Umschaltungper Switchover möglich.

Die Möglichkeit des Switchover kann von einer Gruppe von Systemen in einem Cluster genutzt werden,um den Zugriff auf den umschaltbaren Plattenpool von einem System auf ein anderes zu verschieben. Indieser Umgebung kann ein unabhängiger Plattenpool umschaltbar sein, wenn er sich auf einer umschalt-


|||

|||

||||||||||

|||||||

baren Einheit befindet. Eine umschaltbare Einheit kann eine externe Erweiterungseinheit (Tower), einEin-/Ausgabeprozessor auf dem von den logischen Partitionen gemeinsam genutzten Bus oder ein Ein-/Ausgabeprozessor sein, der einem Ein-/Ausgabepool zugeordnet ist. Hardware, die keinen physischenEin-/Ausgabeprozessor hat, verfügt über eine virtuelle logische Darstellung des Ein-/Ausgabeprozessors.Zugehörige Konzepte

Independent disk pools„Umschaltbare logische Einheiten”Eine umschaltbare logische Einheit ist ein unabhängiger Plattenpool. Die Kombination aus umschaltbaren lo-gischen Einheiten und IBM i-Clustertechnologie ermöglicht die Erarbeitung einer einfachen und kostenef-fizienten HA-Lösung für geplante und ungeplante Betriebsunterbrechungen.

Umschaltbare logische EinheitenEine umschaltbare logische Einheit ist ein unabhängiger Plattenpool. Die Kombination aus umschaltbaren lo-gischen Einheiten und IBM i-Clustertechnologie ermöglicht die Erarbeitung einer einfachen und kostenef-fizienten HA-Lösung für geplante und ungeplante Betriebsunterbrechungen.

Der unabhängige Plattenpool wird von der Einheiten-CRG gesteuert; im Fall einer ungeplanten Betriebs-unterbrechung kann er automatisch umgeschaltet werden, ansonsten ist auch eine manuelle Umschaltungper Switchover möglich.

Die Möglichkeit des Switchover kann von einer Gruppe von Systemen in einem Cluster genutzt werden,um den Zugriff auf die umschaltbare logische Einheit von einem System auf ein anderes zu verschieben.Die umschaltbare logische Einheit muss sich in einem IBM System Storage DS8000 oder DS6000 befinden,zu dem eine Verbindung über ein Speicherbereichsnetz besteht. Umschaltbare logische Einheiten funktio-nieren wie umschaltbare Platten, es wird aber keine Hardware zwischen logischen Partitionen umgeschal-tet. Beim Umschalten des unabhängigen Plattenpools werden die logischen Einheiten in der IBM SystemStorage-Einheit zwischen den logischen Partitionen neu zugeordnet.Zugehörige Konzepte

„Umschaltbare Platten” auf Seite 26Eine umschaltbare Platte ist ein unabhängiger Plattenpool, der von einer Einheiten-CRG gesteuert wirdund zwischen den Knoten innerhalb eines Clusters umgeschaltet werden kann. Die Kombination aus um-schaltbaren Platten und IBM i-Clustertechnologie ermöglicht die Erarbeitung einer einfachen und kosten-effizienten HA-Lösung für geplante und ungeplante Betriebsunterbrechungen.

Umschaltbare EinheitenIn Hochverfügbarkeitsumgebungen unterstützt IBM i neben unabhängigen Plattenpools auch andere um-schaltbare Einheiten.

Vor 6.1 unterstützte IBM i nur das Umschalten unabhängiger Plattenpooleinheiten. Wenn ein Switchoveroder ein Failover durchgeführt wird, wird die unabhängige Plattenpooleinheit vom Primär- auf den Aus-weichknoten umgeschaltet. Ab 6.1 können neben den unabhängigen Plattenpooleinheiten auch andereHardwareeinheiten umgeschaltet werden. Auf dem Ausweichknoten garantiert das Clustering, dass dieunabhängigen Plattenpools unter denselben Ressourcennamen geführt werden; die übrigen Einheiten (diekeine unabhängigen Plattenpools sind) können jedoch mit abweichenden Ressourcennamen geführt wer-den.

Das Clustering garantiert, dass die Ressourcennamen und zugrunde liegenden physischen Einheiten fürsonstige Einheiten (die keine unabhängigen Plattenpools sind), die von einer Einheiten-CRG gesteuertwerden, auf allen Knoten in der Einheitendomäne identisch sind. Informationen, die die physische Ein-heit betreffen, wie beispielsweise Ressourcenname und -typ, werden von dem Knoten, der Eigner derHardware ist, gesichert und auf den übrigen Knoten in der Wiederherstellungsdomäne wiederhergestellt.Dies geschieht, wenn das Konfigurationsobjekt für die Einheit in eine Einheiten-CRG aufgenommen wird,oder wenn der Wiederherstellungsdomäne ein Knoten hinzugefügt wird. Wenn Sie der Wiederherstel-


|

|||

|||

|||||||

|

|||||

lungsdomäne einen Einheiteneintrag oder einen Knoten hinzufügen, muss der Ressourcenname für diephysische Einheit auf allen Knoten in der Wiederherstellungsdomäne identisch sein, andernfalls misslin-gen diese Operationen. Das Hinzufügen kann manuell oder automatisch über die Clusterverwaltungsdo-mäne erfolgen, damit die Ressourcennamen für diese Einheiten auf allen Knoten in der Wiederherstel-lungsdomäne konsistent sind.

Wenn Sie MREs für Konfigurationsobjekte und Ressourcennamen erstellen, die den Einheiten zugeordnetsind, werden Änderungen an diesen Ressourcen von der Clusterverwaltungsdomäne überwacht. Dienachfolgende Tabelle enthält die unterstützten Einheiten und zugeordneten überwachten Ressourcen so-wie die den Einheiten zugeordneten Ressourcenarten, die in der Clusterverwaltungsdomäne überwachtwerden können.

Tabelle 8. Unterstützte Einheiten, zugeordnete überwachte Ressourcen und Ressourcenarten

Unterstützte Einheit Überwachte Ressource Überwachte Ressourcenart

Unabhängiger Plattenpool Unabhängiger Plattenpool *ASPDEV

Netzwerk-Server-Host-Adapter Netzwerk-Server-Host-Adapter *NWSHDEV

Optische Einheit Optische Einheit *OPTDEV

Bandeinheit Bandeinheit *TAPDEV

Ethernet-Leitung Ethernet-Leitung *ETHLIN

Token-Ring-Leitung Token-Ring-Leitung *TRNLIN

Netzwerk-Server Netzwerk-Server *NWSD

Zugehörige Konzepte

„Clusterverwaltungsdomäne” auf Seite 25Eine 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.Zugehörige Informationen

Szenario: Einheit hochverfügbar machen

Standortübergreifende SpiegelungStandortübergreifende Spiegelung (Cross-site Mirroring, XSM) ist ein Sammelbegriff für mehrere von IBMi unterstützte HA-Spiegelungstechnologien, die eine gespiegelte Kopie der Daten erzeugen und damitWiederherstellungsmaßnahmen und Hochverfügbarkeit ermöglichen. Diese Technologien verwalten au-ßerdem den Replikationsprozess und steuern den Zugriffspunkt auf die Daten. Bei einem Ausfall desQuellen- oder Produktionssystems können die auf dem Zielsystem gespeicherten gespiegelten Daten ver-fügbar gemacht werden, was entweder automatisch oder manuell geschehen kann.

Geographische SpiegelungIm 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 einem Systemausfall, wird die Produktion auf die spiegelgleicheKopie der Daten umgeschaltet, die sich in der Regel an einem anderen Standort befindet. Beim synchro-nen Übermittlungsmodus erfolgt die Datenspiegelung, bevor die Schreiboperation auf dem Produktions-system beendet ist, und wird normalerweise für Anwendungen eingesetzt, bei denen im Fehlerfall keiner-lei Datenverlust hingenommen werden kann. Beim asynchronen Übermittlungsmodus werden die Daten


|||||

ebenfalls an die Spiegelkopie gesendet, bevor die Schreiboperation beendet ist, die Steuerung wird jedochan die Anwendung zurückgegeben, bevor die spiegelgleiche Schreiboperation tatsächlich auf der Spiegel-kopie 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 Unterfunktion der standortübergreifenden Spiegelung (XSM), diewiederum Bestandteil von IBM i Option 41, High Availability Switchable Resources, ist.

Geographische Spiegelung mit asynchronem Übermittlungsmodus steht nur in PowerHA Version 2.0 zurVerfügung.Zugehörige Informationen

Geographische Spiegelung planenSzenario: Umschaltbare Platte mit geographischer SpiegelungSzenario: Standortübergreifende Spiegelung mit geographischer 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.

Im Rahmen der Clustertechnologie bietet Metro Mirror eine HA-Lösung mit Wiederherstellungsfunktion.Ebenso wie bei der geographischen Spiegelung werden auch bei dieser Technologie Daten gespiegelt, diein unabhängigen Plattenpools gespeichert sind. Bei Metro Mirror befinden sich die Platten jedoch in denexternen IBM System Storage-Speichereinheiten DS6000 oder DS8000. Das Spiegeln erfolgt von den exter-nen Quellenspeichereinheiten, die sich normalerweise am Produktionsstandort befinden, auf eine Reihevon externen Zielspeichereinheiten, die sich normalerweise am Ausweichstandort befinden. Das Spiegelnder Daten zwischen den externen Speichereinheiten erfolgt, um die Verfügbarkeit sowohl bei geplantenals auch ungeplanten Betriebsunterbrechungen zu gewährleisten.

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 derselben


|||

|||

||||||||

|||

||

oder 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 Leistung zuminimieren.Zugehörige Informationen

Metro Mirror planenSzenario: Standortübergreifende Spiegelung mit Metro Mirror

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

Global Mirror ist eine Platten-E/A-Spieglung auf Subsystemebene zwischen zwei externen Speicherein-heiten. Diese asynchrone Lösung zeigt ein besseres Leistungsverhalten bei uneingeschränkten Entfernun-gen, da die Aktualität der Daten am Zielstandort ein paar Sekunden hinter der am Ausgangsstandort hin-terherhinken darf.

Auf der Basis asynchroner Technologie ermöglicht Global Mirror eine Remote Copy zwischen zwei Stand-orten über eine große Entfernung hinweg. Global Mirror wird über Hochgeschwindigkeitsverbindungenmit Glasfaserkabeln betrieben und wurde konzipiert, um asynchron eine vollständige und konsistente fer-ne Spiegelung von Daten über uneingeschränkte Entfernungen hinweg ohne erhebliche Auswirkungenauf die Anwendungsantwortzeit zu erstellen.

Größere Entfernungen zwischen Rechenzentren tragen zum Schutz vor den Gefahren regionaler Ausfällebei. Dieses asynchrone Verfahren führt zu einem besseren Leistungsverhalten bei uneingeschränkten Ent-fernungen. Zwischen der Aktualität der Daten, die mit Global Mirror auf den Ausweichstandort kopiertwurden, und der Daten am Produktionsstandort liegen nur Sekunden. Global Mirror bietet für die Wie-derherstellung nach einem Katastrophenfall eine Lösung mit einem leistungsstarken und kosteneffizientenAnsatz zur Datenreplikation über große Entfernungen hinweg.Zugehörige Informationen

Global Mirror planenSzenario: Standortübergreifende Spiegelung mit Global Mirror

FlashCopyIn IBM i-Hochverfügbarkeitsumgebungen, die mit externen IBM System Storage-Speichereinheiten arbei-ten, kann FlashCopy verwendet werden. Mit FlashCopy wird eine nahezu zeitgleiche Zeitpunktkopie un-abhängiger Plattenpools auf externen Speichereinheiten hergestellt, wodurch die Zeitdauer verkürzt wer-den kann, die zum Erstellen der täglichen Sicherungen erforderlich ist.

Zeitpunktgesteuerte Kopierfunktionen erstellen eine Momentaufnahme der Originaldaten, wie sie sich zueinem bestimmten Zeitpunkt dargestellt haben. Die Zielkopie ist völlig unabhängig vom unabhängigenQuellenplattenpool und steht unmittelbar nach Verarbeitung des FlashCopy-Befehls für den Lese- undSchreibzugriff zur Verfügung.



FlashCopy planenSzenario: FlashCopy ausführenFlashCopy verwalten

Verwaltung der HochverfügbarkeitFür die Planung, Konfiguration und Verwaltung einer vollständigen HA-Lösung ist eine Reihe von Ver-waltungstools und -angeboten erforderlich. IBM i-Systeme bieten mehrere Auswahlmöglichkeiten für dieVerwaltung der Hochverfügbarkeit.

Für die Verwaltung der Hochverfügbarkeit stehen Ihnen grafische Oberflächen, Befehle und APIs zur Ver-fügung, mit denen Sie Ihre Umgebung ganz nach Ihrem Bedarf und Ihren Anforderungen erstellen undverwalten können. Sie haben auch die Möglichkeit, eine Anwendung eines IBM Business Partners zuwählen. Die einzelnen Verwaltungstools für die Hochverfügbarkeit haben alle ihre Vorteile und auchNachteile.

Schnittstellen des IBM PowerHA für iIBM PowerHA für i, Lizenzprogrammnummer 5770-HAS, ist ein End-to-End-Angebot für Hochverfügbar-keit. In Verbindung mit unabhängigen Zusatzspeicherpools (iASPs) und HA Switchable Resources (HASR- Option 41) kann damit über den Speicherserver IBM DS8000 oder eine interne Platte eine komplette Lö-sung implementiert werden. PowerHA enthält zahlreiche Schnittstellen für die Konfiguration und Verwal-tung von HA-Lösungen und -Technologien.

Das Lizenzprogramm IBM PowerHA für i ist ein End-to-End-Angebot für Hochverfügbarkeit. In Verbin-dung mit unabhängigen Zusatzspeicherpools (iASPs) und HA Switchable Resources (HASR - Option 41)kann damit eine komplette Lösung über den Speicherserver IBM DS8000 oder eine interne Platte imple-mentiert werden.

Das Lizenzprogramm IBM PowerHA für i enthält zwei grafische Oberflächen, mit deren Hilfe eine HA-Lösung konfiguriert und verwaltet werden kann. Dieses Produkt enthält außerdem die entsprechendenBefehle und APIs für Funktionen, die Hochverfügbarkeitstechnologien betreffen. Dieses Lizenzprogrammbietet den verantwortlichen Administratoren die Möglichkeit, über Schnittstellen, die ihrem Know-howund ihren Vorgaben entsprechen, eine HA-Lösung für die eigenen Geschäftsanforderungen zu erstellenund zu verwalten. Es kann auch mit mehreren Schnittstellen gleichzeitig gearbeitet werden, wobei für ei-nige Tasks grafische Oberflächen und für andere Befehle und APIs verwendet werden.

Das Lizenzprogramm IBM PowerHA für i enthält die folgenden Schnittstellen:

Grafische Oberfläche des High Availability Solutions ManagerDiese grafische Oberfläche bietet Ihnen die Möglichkeit, aus mehreren von IBM i unterstütztenHA-Lösungen auszuwählen. Diese Schnittstelle prüft alle technologischen Voraussetzungen fürdie von Ihnen ausgewählte Lösung, konfiguriert die Lösung und die zugehörigen Technologienund bietet eine vereinfachte Verwaltung für alle HA-Technologien, die zu Ihrer Lösung gehören.

Grafische Oberfläche der Cluster Resource ServicesDiese grafische Oberfläche ermöglicht einem erfahrenen Benutzer eine höhere Flexibilität beimAnpassen einer HA-Lösung. Mithilfe dieser Schnittstelle können Clustertechnologien, wie bei-spielsweise Clusterressourcengruppen (CRGs), konfiguriert und verwaltet werden. Über dieseSchnittstelle können außerdem unabhängige Plattenpools konfiguriert werden, wenn sie als Be-standteil einer HA-Lösung verwendet werden.

Befehle von IBM PowerHA für iDiese Befehle bieten ähnliche Funktionen, sind jedoch über eine Befehlszeilenschnittstelle verfüg-bar.


|

|

|

|

|

|

|

APIs für IBM PowerHA für iDiese APIs ermöglichen das Arbeiten mit Funktionen, die unabhängige Plattenpools, PowerHA-Versionsinformationen, Spiegelungstechnologien und standortübergreifende Spiegelung betreffen.


Lizenzprogramm IBM PowerHA für i installieren

Grafische Oberfläche des High Availability Solutions ManagerDas Lizenzprogramm IBM PowerHA für i stellt einen lösungsbasierten Ansatz für die Konfiguration undVerwaltung der Hochverfügbarkeit in Form der grafischen Oberfläche des High Availability SolutionsManager zur Verfügung. Mithilfe dieser Schnittstelle können die für die Hochverfügbarkeit verantwortli-chen Administratoren eine vordefinierte HA-Lösung auswählen, konfigurieren und verwalten, die aufIBM i-Hochverfügbarkeitstechnologien basiert, wie beispielsweise unabhängige Plattenpools und Cluster.

Die grafische Oberfläche des High Availability Solutions Manager führt den Benutzer schrittweise durchden Prozess des Auswählens, Konfigurierens und Verwaltens einer HA-Lösung. Der Benutzer muss einenSchritt immer erst abschließen, bevor er mit dem nächsten fortfahren kann. Wenn PowerHA installiert ist,kann der Zugriff auf die grafische Oberfläche des High Availability Solutions Manager über die IBM Sys-tems Director Navigator for i5/OS-Konsole erfolgen. Die grafische Oberfläche des High Availability So-lutions Manager bietet folgende Features:v Eine Flashdemo in englischer Sprache, die eine Übersicht über die einzelnen Lösungen bietet.v Eine Auswahl vordefinierter IBM i-Lösungen auf der Basis der IBM i-Hochverfügbarkeitstechnologien.v Überprüfung der Hardware- und Softwarevoraussetzungen, bevor die ausgewählte HA-Lösung konfi-

guriert wird.v Eine angepasste Liste der fehlenden Voraussetzungen.v Einfache Konfiguration der ausgewählten HA-Lösung.v Vereinfachte Verwaltung der ausgewählten HA-Lösung.

Die grafische Oberfläche des High Availability Solutions Manager bietet einen benutzerfreundlichenschrittweisen Ansatz für die Konfiguration der Hochverfügbarkeit. Die Schnittstelle prüft die Vorausset-zungen, konfiguriert alle notwendigen Technologien für die ausgewählte Lösung und testet die Konfigu-ration. Diese Oberflache für Managementlösungen ist für kleinere Unternehmen geeignet, die einfachereLösungen mit weniger Ressourcen wünschen.Zugehörige Informationen

Hochverfügbarkeit - Implementierung mit lösungsbasiertem Ansatz

Grafische Oberfläche der Cluster Resource ServicesDas Lizenzprogramm IBM PowerHA für i stellt eine grafische Oberfläche zur Verfügung, mit der Tasksauf der Basis der IBM i-Hochverfügbarkeitstechnologien ausgeführt werden können, um eine HA-Lösungzu konfigurieren und zu verwalten.

Mithilfe der grafischen Oberfläche der Cluster Resource Services können Sie eine HA-Lösung erstellenund anpassen, die Ihrem individuellen Bedarf entspricht. Diese Schnittstelle bietet einen taskbasierten An-satz für die Konfiguration und Verwaltung Ihrer HA-Lösung. Sie müssen sich nicht für eine einzige vor-definierte Lösung entscheiden sondern können eine angepasste HA-Lösung erarbeiten, bei der Sie jedesElement einzeln erstellen können. Mit der grafischen Oberfläche der Cluster Resource Services können SieCluster, Clusterressourcengruppen, Einheitendomänen und Clusterverwaltungsdomänen erstellen undverwalten sowie Switchover durchführen.

Je nachdem welche Art von HA-Lösung Sie erstellen, müssen Sie ggf. weitere Technologien, z. B. die geo-graphische Spiegelung oder unabhängige Plattenpools konfigurieren, die nicht zum Umfang der grafi-schen Oberfläche der Cluster Resource Services gehören. Sie können Ihre HA-Lösung auch mit einerKombination aus Befehlen und Funktionen der grafischen Oberfläche erstellen und verwalten.


|||

|

||||||

|

|

||

|

|

|

|


Hochverfügbarkeit - Implementierung mit taskbasiertem Ansatz

Befehle von IBM PowerHA für i

Das Lizenzprogramm IBM PowerHA für i stellt IBM i-Befehlszeilenschnittstellen für die Konfigurationund Verwaltung Ihrer HA-Lösung zur Verfügung.

Die PowerHA-Befehle sind in die folgenden Kategorien unterteilt:v Befehle für die Clusterverwaltungsdomänev Befehle für MREsv Clusterbefehlev Befehle und APIs für das Arbeiten mit Kopien unabhängiger PlattenpoolsZugehörige Informationen

Befehle von IBM PowerHA für i

APIs für IBM PowerHA für iIBM PowerHA für i stellt APIs für die Implementierung von IBM System Storage-Spiegelungstechnologi-en und standortübergreifenden Spiegelungsfunktionen zur Verfügung, die von IBM i-Anwendungsprovi-dern oder Kunden eingesetzt werden können, um ihre Anwendungsverfügbarkeit zu verbessern.

Um diese APIs verwenden zu können, muss das Lizenzprogramm IBM PowerHA für i auf den Systemenin Ihrer HA-Umgebung installiert sein. Die folgenden APIs werden zur Verfügung gestellt:v Change High Availability Version (QhaChangeHAVersion) APIv List High Availability Information (QhaListHAInfo) APIv Retrieve High Availability Information (QhaRetrieveHAInfo) APIv Retrieve ASP Copy Information (QyasRtvInf) API

Versionsunterstützung für IBM PowerHA für iEine PowerHA-Version stellt die Stufe der PowerHA für i-Funktion dar, die in einem Cluster zur Verfü-gung steht.

Erweiterte Funktionalität bei IBM PowerHA für i, Lizenzprogrammnummer 5770-HAS

Das Lizenzprogramm IBM PowerHA für i wurde für 7.1 funktional erweitert. Sowohl den grafischenOberflächen als auch der Befehlszeilenschnittstelle und den APIs wurden Funktionen hinzugefügt. Dieseneuen Funktionen unterstützen Administratoren bei der Konfiguration und Verwaltung von Hochverfüg-barkeitslösungen. Details zu den Features der einzelnen Schnittstellen finden Sie unter den folgendenThemen:v Grafische Oberfläche des High Availability Solutions Managerv Grafische Oberfläche der Cluster Resource Servicesv Befehle von IBM PowerHA für iv APIs für IBM PowerHA für i


Die IBM i Cluster Resource Services können jetzt mithilfe der Hardware Management Console (HMC)oder einer VIOS-Partition (Virtual I/O Server) erkennen, wenn ein Clusterknoten ausfällt. Diese neueFunktionalität ermöglicht es, eine größere Anzahl von Ausfallszenarios eindeutig zu identifizieren undClusterpartitionen zu vermeiden. Details finden Sie unter den folgenden Themen:v Erweiterte grafische Oberfläche der Cluster Resource Services


|

||

|

|

|

|

|

|

|

|

|

|||||

|

|

|

|

||||

|

v Cluster Control APIsv Befehle von IBM PowerHA für i

– Neuer Befehl Clusterüberwachung hinzufügen (ADDCLUMON)– Neuer Befehl Clusterüberwachung ändern (CHGCLUMON)– Neuer Befehl Clusterüberwachung entfernen (RMVCLUMON)

Asynchroner Übermittlungsmodus bei der geographischen Spiegelung

Die geographische Spiegelung unterstützt jetzt den neuen asynchronen Übermittlungsmodus, der dieLaufzeitleistung von Anwendungen verbessern und größere Entfernungen zwischen zwei Systemen un-terstützen kann. Die meisten Anwendungen, die geographische Spiegelung verwenden, können den asyn-chronen Übermittlungsmodus tolerieren. Details finden Sie unter den folgenden Themen:v Geographische Spiegelungv Erweiterter Befehl ASP-Sitzung ändern (CHGASPSSN)v Erweiterter Befehl ASP-Sitzung anzeigen (DSPASPSSN)

Neue Befehle für Hochverfügbarkeit

Die folgenden Befehle wurden dem Lizenzprogramm PowerHA für i hinzugefügt.v Neuer Befehl MRE der Verwaltungsdomäne drucken (PRTCADMRE)v Neuer Befehl Cluster abrufen (RTVCLU)v Neuer Befehl CRG abrufen (RTVCRG)v Neuer Befehl ASP-Sitzung abrufen (RTVASPSSN)v Neuer Befehl ASP-Kopienbeschreibung abrufen (RTVASPCPYD)

Unterstützung für Versionssteuerung bei IBM PowerHA für i

Eine PowerHA-Version stellt die Stufe der IBM PowerHA für i-Funktion dar, die in einem Cluster zurVerfügung steht. Sie wird im Format x.y angezeigt. Zum Beispiel ist Version 2.0 eine gültige PowerHA-Version.

Momentan werden zwei PowerHA-Versionen unterstützt:

Potenzielle PowerHA-VersionDie potenzielle Version von IBM PowerHA für i ist die auf einem Knoten installierte Version. Diepotenzielle PowerHA-Version ist die höchste PowerHA-Version, die vom Knoten momentan un-terstützt werden kann. Die potenzielle PowerHA-Version wird aktualisiert, wenn eine neue Versi-on von IBM PowerHA für i installiert wird.

Aktuelle PowerHA-VersionDie aktuelle Version ist die Version, die momentan für alle Clusteroperationen verwendet wird.Dies ist der Versionsstand, auf dem alle Knoten im Cluster miteinander kommunizieren. Um alleverfügbaren neuen PowerHA-Funktionen nutzen zu können, müssen alle Knoten im Cluster dieneueste potenzielle PowerHA-Version aufweisen und die aktuelle PowerHA-Version muss aufdiesen Stand gebracht werden.

Kompatibilität der PowerHA-Versionen

IBM PowerHA für i unterstützt Abweichungen von bis zu zwei Versionen zwischen den Knoten.Knoten,uderen potenzielle PowerHA-Version mindestens der aktuellen PowerHA-Version entspricht, dieaber nicht mehr als zwei Versionen höher ist als die aktuelle PowerHA-Version, sind kompatibel. Ist dieaktuelle PowerHA-Version beispielsweise 2.1, sind Knoten mit einer potenziellen PowerHA-Version vonmindestens 2.1 und niedriger als 5.0 kompatibel.


|

|

|

|

|

||||

|

|

|

|

|

|

|

|

|

|

|

|||

|

|||||

||||||

|

|||||

Aktuelle PowerHA-Version festlegen

Die aktuelle PowerHA-Version wird ursprünglich bei der Erstellung des Clusters mit dem Befehl CRTC-LU (Cluster erstellen) festgelegt. Wenn der Cluster bei der Installation von IBM PowerHA für i vorhan-den ist, wird die aktuelle PowerHA-Version auf die niedrigste aktuelle PowerHA-Version gesetzt, die vondem Knoten unterstützt wird. Die Anpassung der aktuellen PowerHA-Version erfolgt mit dem BefehlCHGCLUVER (Clusterversion ändern). Die aktuelle PowerHA-Version kann nur angepasst werden, wenndie potenzielle PowerHA-Version aller Knoten im Cluster die Version unterstützt. Die aktuelle PowerHA-Version kann nicht auf eine niedrigere Version zurückgeändert werden. Sobald die aktuelle PowerHA-Version an eine höhere Version angepasst wurde, stehen neue IBM PowerHA für i-Funktionen zur Verfü-gung.

Zusammenfassung der neuen Funktionen nach PowerHA-Version

Verfügbare Funktionen enthalten die Funktionen, die bereits in älteren Versionen zur Verfügung standen.

Funktionen, die in PowerHA Version 1.0 zur Verfügung stehen, erfordern Clusterversion 6.0.

Neue Funktionen, die in PowerHA Version 2.0, zur Verfügung stehen, erfordern Clusterversion 7.0.

Verfügbare Funktionen in PowerHA Version 1.0

Verfügbare Funktionen in PowerHA Version 1.0, für die die aktuelle Clusterversion 6 erforderlich ist,sind:

Unterstützung für standortübergreifende Spiegelung (Cross Site Mirroring, XSM):v Geographische Spiegelungv Metro Mirrorv Global Mirrorv FlashCopy

Befehle von IBM PowerHA für i:v ASP-Kopienbeschreibung hinzufügen (ADDASPCPYD)v MRE zu Verwaltungsdomäne hinzufügen (ADDCADMRE)v KNT-Eintrag zu Domäne hinzufügen (ADDCADNODE)v CST-Knoteneintrag hinzufügen (ADDCLUNODE)v CRG-Einheiteneintrag hinzufügen (ADDCRGDEVE)v CRG-Knoteneintrag hinzufügen (ADDCRGNODE)v Einheitendomäneneintrag hinzufügen (ADDDEVDMNE)v ASP-Kopienbeschreibung ändern (CHGASPCPYD)v ASP-Sitzung ändern (CHGASPSSN)v CST-Verwaltungsdomäne ändern (CHGCAD)v Cluster ändern (CHGCLU)v CST-Knoteneintrag ändern (CHGCLUNODE)v Clusterversion ändern (CHGCLUVER)v CRG ändern (CHGCRG)v CRG-Einheiteneintrag ändern (CHGCRGDEVE)v CRG-Primärknoten ändern (CHGCRGPRI)v CST-Verwaltungsdomäne erstellen (CRTCAD)v Cluster erstellen (CRTCLU)


|

|||||||||

|

|

|

|

|

||

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

v CRG erstellen (CRTCRG)v CST-Verwaltungsdomäne löschen (DLTCAD)v Cluster löschen (DLTCLU)v CRG aus Cluster löschen (DLTCRGCLU)v ASP-Kopienbeschreibung anzeigen (DSPASPCPYD)v ASP-Sitzung anzeigen (DSPASPSSN)v Clusterinformationen anzeigen (DSPCLUINF)v CRG-Informationen anzeigen (DSPCRGINF)v ASP-Sitzung beenden (ENDASPSSN)v CST-Verwaltungsdomäne beenden (ENDCAD)v Clusterknoten beenden (ENDCLUNOD)v CRG beenden (ENDCRG)v ASP-Kopienbeschreibung entfernen (RMVASPCPYD)v MRE aus Verwaltungsdomäne entfernen (RMVCADMRE)v KNT-Eintrag aus Domäne entfernen (RMVCADNODE)v CST-Knoteneintrag entfernen (RMVCLUNODE)v CRG-Einheiteneintrag entfernen (RMVCRGDEVE)v CRG-Knoteneintrag entfernen (RMVCRGNODE)v Einheitendomäneneintrag entfernen (RMVDEVDMNE)v ASP-Sitzung starten (STRASPSSN)v CST-Verwaltungsdomäne starten (STRCAD)v Clusterknoten starten (STRCLUNOD)v CRG starten (STRCRG)v Mit ASP-Kopienbeschreibungen arbeiten (WRKASPCPYD)v Mit Cluster arbeiten (WRKCLU)

Anwendungsprogrammierschnittstellen von IBM PowerHA für i:v Change Device Domain Data (QYASCHGDDD)v Retrieve ASP Copy Information (QYASRTVINF)v Retrieve Device Domain Data (QYASRTVDDD)

Grafische Benutzerschnittstellen von IBM PowerHA für i:v Cluster Resource Servicesv High Availability Solutions Manager

Verfügbare Funktionen in PowerHA Version 2.0

Verfügbare Funktionen in PowerHA Version 2.0, für die die aktuelle Clusterversion 7 erforderlich ist,sind:

Unterstützung für PowerHA-Versionen:

v Erweiterter Befehl Clusterversion ändern (CHGCLUVER)v Neue API Change High Availability Version (QhaChangeHAVersion)v Erweiterter Befehl Cluster erstellen (CRTCLU)v Erweiterter Befehl Clusterinformationen anzeigen (DSPCLUINF)v Neue API List High Availability Information (QhaListHAInfo)v Neuer Befehl Cluster abrufen (RTVCLU)


|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

v Neuer Befehl CRG abrufen (RTVCRG)v Neue API Retrieve High Availability Information (QhaRetrieveHAInfo)v Erweiterter Befehl Mit Cluster arbeiten (WRKCLU)

Unterstützung für asynchrone geographische Spiegelung:

v Erweiterter Befehl ASP-Sitzung ändern (CHGASPSSN)v Erweiterter Befehl ASP-Sitzung anzeigen (DSPASPSSN)v Erweiterter Befehl ASP-Sitzung abrufen (RTVASPSSN)v Erweiterter Befehl ASP-Kopienbeschreibung abrufen (RTVASPCPYD)

Unterstützung für erweiterter Clusterknotenausfallerkennung:

v Neuer Befehl Clusterüberwachung hinzufügen (ADDCLUMON)v Neuer Befehl Clusterüberwachung ändern (CHGCLUMON)v Erweiterte grafische Oberfläche der Cluster Resource Servicesv Neuer Befehl Clusterüberwachung entfernen (RMVCLUMON)

Hinzugefügte Unterstützung für IPv6

Die folgenden Funktionen wurde funktional erweitert und unterstützen jetzt IPv6.v Erweiterter Befehl CST-Knoteneintrag hinzufügen (ADDCLUNODE)v Erweiterter Befehl CRG-Einheiteneintrag hinzufügen (ADDCRGDEVE)v Erweiterter Befehl CRG-Knoteneintrag hinzufügen (ADDCRGNODE)v Erweiterter Befehl CST-Knoteneintrag ändern (CHGCLUNODE)v Erweiterter Befehl CRG ändern (CHGCRG)v Erweiterter Befehl CRG-Einheiteneintrag ändern (CHGCRGDEVE)v Erweiterter Befehl Cluster erstellen (CRTCLU)v Erweiterter Befehl CRG erstellen (CRTCRG)v Erweiterter Befehl Clusterinformationen anzeigen (DSPCLUINF)v Erweiterter Befehl CRG-Informationen anzeigen (DSPCRGINF)v Erweiterter Befehl Mit Cluster arbeiten (WRKCLU)v Erweiterte grafische Oberfläche der Cluster Resource Servicesv Erweiterte grafische Oberfläche des High Availability Solutions Manager

Unterstützung für Druckereinheiten und Berechtigungslisten in der Verwaltungsdomäne:

v Erweiterter Befehl MRE der Verwaltungsdomäne hinzufügen (ADDCADMRE)v Erweiterte grafische Oberfläche der Cluster Resource Servicesv Neuer Befehl MRE der Verwaltungsdomäne drucken (PRTCADMRE)v Erweiterter Befehl MRE aus Verwaltungsdomäne entfernen (RMVCADMRE)

Unterstützung für umschaltbare logische Einheiten

v Unterstützung für umschaltbare logische Einheiten steht jetzt zur Verfügung. Weitere Informationen fin-den Sie unter umschaltbare logische Einheiten.

Neuer PowerHA-Server-Job

Wenn Clustering aktiv und die aktuelle PowerHA-Version 2.0 oder eine höhere Version ist, ist der Pow-erHA-Server-Job aktiv. Der Jobname ist QHASVR und der Job wird im Subsystem QSYSWRK unter demBenutzerprofil QHAUSRPRF ausgeführt.


Option 41 (HA Switchable Resources)Option 41 (HA Switchable Resources) ist für die Verwendung verschiedener IBM i HA-Management-schnittstellen und -Funktionen erforderlich.

Option 41 (High Availability Switchable Resources) ist erforderlich, wenn Sie die folgenden Schnittstellenverwenden möchten:v Das Lizenzprogramm IBM PowerHA für i

– Grafische Oberfläche des High Availability Solutions Manager– Grafische Oberfläche der Cluster Resource Services– Befehle von IBM PowerHA für i– APIs für IBM PowerHA für i

Option 41 ist außerdem für die folgenden Funktionen erforderlich:v Umschaltbare Platte mit Einheitendomänen erstellen und verwaltenv Standortübergreifende Spiegelung mit Einheitendomänen erstellen und verwalten

Hochverfügbarkeitsfunktion im BasisbetriebssystemEinige der CL-Clusterbefehle und alle Cluster-APIs sind im IBM i-Basisbetriebssystem enthalten.

Clusterbefehle

Für Debugging-Zwecke und zum Löschen clusterbezogener Objekte verbleiben die folgenden Clusterbe-fehle in QSYS:v CRG löschen (DLTCRG)v Speicherauszug von Cluster-Trace erstellen (DMPCLUTRC)v Clusterwiederherstellung ändern (CHGCLURCY)v Cluster-Hash-Tabelle starten (STRCHTSVR)v Cluster-Hash-Tabelle beenden (ENDCHTSVR)

Cluster-APIs

Mithilfe von Cluster-APIs können Sie eine kundenspezifische Anwendung für die Konfiguration und Ver-waltung eines Clusters erstellen. Diese APIs nutzen die Technologie, die von den Cluster Resource Servi-ces als Bestandteil von IBM i zur Verfügung gestellt wird. Neue, erweiterte Funktionen sind in den Befeh-len von IBM PowerHA für i enthalten, die vom Lizenzprogramm IBM PowerHA für i bereitgestelltwerden.

QUSRTOOLIn IBM i 6.1 wurden die meisten der Cluster Resource Services-Befehle von QSYS in das Lizenz-programm IBM PowerHA für i übertragen. QUSRTOOL enthält eine V5R4-Version der Befehls-quelle für die Cluster Resource Services sowie die Quelle für das Befehlsverarbeitungsprogramm.Diese QUSRTOOL-Befehle können sich in einigen Umgebungen als dienlich erweisen. Weitere In-formationen über diese Beispielbefehle finden Sie in der Teildatei TCSTINFO der DateiQUSRTOOL/QATTINFO. Die Bibliothek QUSRTOOL enthält außerdem ein Beispiel für ein Exit-programm einer Anwendungs-CRG. Der Musterquellcode kann als Basis für ein eigenes Exitpro-gramm dienen. Der Quellcode TCSTDTAEXT in Datei QATTSYSC enthält die Quelle für ein Pro-gramm, mit dem die Datenbereiche QCSTHAAPPI und QCSTHAAPPO sowie die DateiQACSTOSDS (Objektkennung) erstellt werden können.

Um Speicherbereich zu sparen, wird die Bibliothek QUSRTOOL mit zahlreichen Sicherungsdatei-en geliefert. Führen Sie den folgenden Befehl aus, um die Sicherungsdateien in physische Quel-lendateien umzuwandeln:


|

|

|

|

CALL QUSRTOOL/UNPACKAGE ('*ALL ' 1)CRTLIB TOOLLIB TEXT('Commands from QUSRTOOL')CRTCLPGM PGM(TOOLLIB/TCSTCRT) SRCFILE(QUSRTOOL/QATTCL)CALL TOOLLIB/TCSTCRT ('TOOLLIB ')

Diese Befehle wurden in der Bibliothek TOOLLIB erstellt.

Anmerkung: Befehle und Programme in QUSRTOOL werden ohne Wartung (auf 'as-is'-Basis) zurVerfügung gestellt. Es gibt daher keine entsprechenden APARs.


Cluster APIs

IBM Business Partner für Cluster-Middleware und verfügbare Cluste-ring-Produkte

Neben IBM PowerHA für i stehen weitere Clusterverwaltungsprodukte zur Verfügung.

IBM iCluster for i als auch andere Produkte bieten Softwarelösungen für Replikations- und Clusterver-waltungsfunktionen an. Die meisten Lösungen basieren auf der logischen Replikation. Die logische Repli-kation verwendet die Technologie des fernen Journals oder eine vergleichbare Technologie, um Objektän-derungen auf ein fernes System zu übertragen, auf dem sie auf die Zielobjekte angewendet werden.Neben den PowerHA-Verwaltungslösungen können Sie weitere Cluster-Middleware-Produkte beziehen,die die Technologie für logische Replikation verwenden. Diese Produkte enthalten normalerweise aucheine Verwaltungsschnittstelle.Zugehörige Informationen

Logische Replikation planen

Referenzinformationen für Hochverfügbarkeit - TechnologienProdukthandbücher, IBM Redbooks (im PDF-Format), Websites und andere Themensammlungen des In-formation Center enthalten Informationen, die sich auf die Themensammlung "Hochverfügbarkeit - Tech-nologien" beziehen. Sie können alle PDF-Dateien anzeigen oder drucken.

IBM Redbooks

v Clustering and IASPs for Higher Availability (6,4 MB)

v IBM i and IBM TotalStorage: A Guide to Implementing External Disk (6,4 MB)

v IBM i 6.1 Independent ASPs: A Guide to Quick Implementation of Independent ASPs (5,8 MB)

v Implementing PowerHA for IBM i (7,2 MB)

Websites

v IBM PowerHA http://www.ibm.com/systems/power/software/availability/ Dies ist die IBMWebsite zum Thema "Hochverfügbarkeit und Cluster für i, UNIX® und Linux®".

v HA (High Availability) Offering Web page: http://www.ibm.com/systems/i/support/rochester-services/soff-ha.html . Dies ist die IBM Website zum Thema "Hochverfügbarkeit und Analyse für IBMi-Umgebungen".

v Learning Services US www.ibm.com/services/learning/us/ Dies ist die IBM Website für IT-Pro-dukttraining, kundenspezifische Lösungen und E-Learning. Sie können nach Kursen suchen, die Clus-tering und unabhängige Plattenpools betreffen.


|

|||||||

|

http://publib-b.boulder.ibm.com/Redbooks.nsf/RedbookAbstracts/sg245194.html

http://www.redbooks.ibm.com/abstracts/sg247120.html?Open

http://www.redbooks.ibm.com/redpieces/abstracts/sg247811.html?Open

http://www.redbooks.ibm.com/abstracts/sg247405.html?Open

http://www.ibm.com/systems/power/software/availability/

http://www.ibm.com/systems/i/support/rochesterservices/soff-ha.html

http://www.ibm.com/services/learning/us/

v Recommended fixes http://www-912.ibm.com/s_dir/slkbase.nsf/recommendedfixes Diese Websi-te enthält Links zu den verfügbaren PTFs für mehrere IBM i-Produkte. Wenn Sie nach PTFs zur Hoch-verfügbarkeit suchen, wählen Sie das Thema "High Availability: Cluster, IASP, XSM and Journal".

Themensammlungen im Information Centerv Roadmap zur Verfügbarkeitv Hochverfügbarkeit - Überblickv Hochverfügbarkeit - Implementierung

Weitere Informationenv Resource Monitoring and Control (RMC)

Resource Monitoring and Control (RMC)Resource Monitoring and Control (RMC) ist ein allgemeines Rahmengerüst für die Verwaltung, Überwa-chung und Bearbeitung von Ressourcen, wie z. B. physische und logische Systementitäten.

RMC dient als Kommunikationsmechanismus für die Berichterstattung über Serviceereignisse an dieHardware Management Console (HMC). Wenn RMC nicht aktiv ist, werden keine Ereignisse an die HMCberichtet. In der folgenden Liste werden RMC-Services beschrieben:

CAS-DämonFunktion: Fungiert als Authentifizierungsserver für RMC.

Jobname: QRMCCTCASD

RMC-DämonFunktion: Überwacht Ressourcen durch Kommunikation mit den Ressourcenmanagern.

Jobname: QRMCCTRMCD

SRC-DämonFunktion: Überwacht den Status anderer RMC-Jobs; startet einen Job erneut, wenn dieser uner-wartet endet.

Jobname: QRMCSRCD

Ressourcenmanager (RM)

Ein Ressourcenmanager (RM) ist ein Job, der die Schnittstelle zwischen RMC und tatsächlichen physi-schen oder logischen Entitäten verwaltet und bereitstellt. Obwohl RMC die wichtigsten Abstraktionen wieRessourcenklassen, Ressourcen und Attribute für die Darstellung physischer oder logischer Entitäten lie-fert, stellt RMC selbst keine tatsächlichen Entitäten dar. Ein RM ordnet tatsächliche Entitäten zu RMC-Ab-straktionen zu. In der folgenden Liste werden die verschiedenen für RMC unterstützten Ressourcenma-nager beschrieben:

Prüfprotokoll-RMFunktion: Eine Einrichtung zur Aufzeichnung von Informationen über den Systembetrieb.

Jobname: QYUSALRMD

CSMAgent-RMFunktion: Bietet Ressourcenklassen zur Darstellung des Management-Servers (entspricht derHMC).

Jobname: QYUSCMCRMD

Host-RMFunktion: Bietet Ressourcenklassen zur Darstellung einer individuellen Maschine.


http://www-912.ibm.com/s_dir/slkbase.nsf/recommendedfixes

Jobname: QRMCCTHRMD

Service-RMFunktion: Verwaltet Informationen über Probleme und bereitet sie für die Übermittlung an dieHMC vor.

Jobname: QSVRMSERMD

RMC starten oder beenden

Alle RMC-Jobs, einschließlich der RM-Jobs, befinden sich im Subsystem QSYSWRK und werden automa-tisch gestartet, wenn das Subsystem gestartet wird. Damit der Startvorgang ausgeführt werden kann,muss TCP/IP aktiv sein. Für den RMC-Dämon muss TCP/IP aktiv sein. Wird TCP/IP inaktiviert, wirdder RMC-Dämon beendet. Der RMC-Dämon wird automatisch vom SRC-Dämon erneut gestartet, sobaldTCP/IP wieder aktiviert wird. Unter normalen Bedingungen sind hierzu keine Benutzeraktivitäten erfor-derlich. Falls RMC dennoch einmal manuell gestartet werden muss, führen Sie den folgenden Befehl aus:SBMJOB CMD(CALL PGM(QSYS/QRMCCTSRCD)) JOBD(QSYS/QRMCSRCD) PRTDEV(*JOBD) OUTQ(*JOBD)USER(*JOBD) PRTTXT(*JOBD) RTGDTA(RUNPTY50)

Falls RMC manuell beendet werden muss, beenden Sie den Job QRMCSRCD mit dem Befehl ENDJOB.Mit diesem Befehl sollten alle RMC-Jobs beendet werden. Sollte dies nicht der Fall sein, beenden Sie je-den der oben aufgelisteten Jobs manuell.


Anhang. Bemerkungen

Die vorliegenden Informationen wurden für Produkte und Services entwickelt, die auf dem deutschenMarkt angeboten werden.

Möglicherweise bietet IBM die in diesem Dokument beschriebenen Produkte, Services oder Funktionen inanderen Ländern nicht an. Informationen über die gegenwärtig im jeweiligen Land verfügbaren Produkteund Services sind beim zuständigen IBM Ansprechpartner erhältlich. Hinweise auf IBM Lizenzprogram-me oder andere IBM Produkte bedeuten nicht, dass nur Programme, Produkte oder Services von IBMverwendet werden können. Anstelle der IBM Produkte, Programme oder Services können auch andere,ihnen äquivalente Produkte, Programme oder Services verwendet werden, solange diese keine gewerbli-chen Schutzrechte von IBM verletzen. Die Verantwortung für den Betrieb von Produkten, Programmenund Services anderer Anbieter liegt beim Kunden.

Für in diesem Dokument beschriebene Erzeugnisse und Verfahren kann es IBM Patente oder Patentan-meldungen geben. Mit der Auslieferung dieses Dokuments ist keine Lizenzierung dieser Patente verbun-den. Lizenzanforderungen sind schriftlich an folgende Adresse zu richten (Anfragen an diese Adressemüssen auf Englisch formuliert werden):

IBM Director of LicensingIBM Europe, Middle East & AfricaTour Descartes2, avenue Gambetta92066 Paris La DefenseFrance

Trotz sorgfältiger Bearbeitung können technische Ungenauigkeiten oder Druckfehler in dieser Veröffentli-chung nicht ausgeschlossen werden. Die hier enthaltenen Informationen werden in regelmäßigen Zeitab-ständen aktualisiert und als Neuausgabe veröffentlicht. IBM kann ohne weitere Mitteilung jederzeit Ver-besserungen und/oder Änderungen an den in dieser Veröffentlichung beschriebenen Produkten und/oder Programmen vornehmen.

Verweise in diesen Informationen auf Websites anderer Anbieter werden lediglich als Service für denKunden bereitgestellt und stellen keinerlei Billigung des Inhalts dieser Websites dar. Das über diese Web-sites verfügbare Material ist nicht Bestandteil des Materials für dieses IBM Produkt. Die Verwendung die-ser Websites geschieht auf eigene Verantwortung.

Werden an IBM Informationen eingesandt, können diese beliebig verwendet werden, ohne dass eine Ver-pflichtung gegenüber dem Einsender entsteht.

Lizenznehmer des Programms, die Informationen zu diesem Produkt wünschen mit der Zielsetzung: (i)den Austausch von Informationen zwischen unabhängig voneinander erstellten Programmen und ande-ren Programmen (einschließlich des vorliegenden Programms) sowie (ii) die gemeinsame Nutzung derausgetauschten Informationen zu ermöglichen, wenden sich an folgende Adresse:

IBM CorporationSoftware Interoperability Coordinator, Department YBWA3605 Highway 52 NRochester, MN 55901U.S.A.

Die Bereitstellung dieser Informationen kann unter Umständen von bestimmten Bedingungen - in einigenFällen auch von der Zahlung einer Gebühr - abhängig sein.

43

Die Lieferung des in diesem Dokument aufgeführten Lizenzprogramms sowie des zugehörigen Lizenz-materials erfolgt auf der Basis der IBM Rahmenvereinbarung bzw. der Allgemeinen Geschäftsbedingun-gen von IBM, der IBM Internationalen Nutzungsbedingungen für Programmpakete, der IBM Lizenzver-einbarung für Maschinencode oder einer äquivalenten Vereinbarung.

Alle in diesem Dokument enthaltenen Leistungsdaten stammen aus einer kontrollierten Umgebung. DieErgebnisse, die in anderen Betriebsumgebungen erzielt werden, können daher erheblich von den hier er-zielten Ergebnissen abweichen. Einige Daten stammen möglicherweise von Systemen, deren Entwicklungnoch nicht abgeschlossen ist. Eine Gewährleistung, dass diese Daten auch in allgemein verfügbaren Syste-men erzielt werden, kann nicht gegeben werden. Darüber hinaus wurden einige Daten unter Umständendurch Extrapolation berechnet. Die tatsächlichen Ergebnisse können davon abweichen. Benutzer diesesDokuments sollten die entsprechenden Daten in ihrer spezifischen Umgebung prüfen.

Alle Informationen zu Produkten anderer Anbieter stammen von den Anbietern der aufgeführten Pro-dukte, deren veröffentlichten Ankündigungen oder anderen allgemein verfügbaren Quellen. IBM hat die-se Produkte nicht getestet und kann daher keine Aussagen zu Leistung, Kompatibilität oder anderenMerkmalen machen. Fragen zu den Leistungsmerkmalen von Produkten anderer Anbieter sind an den je-weiligen Anbieter zu richten.

Aussagen über Pläne und Absichten von IBM unterliegen Änderungen oder können zurückgenommenwerden und repräsentieren nur die Ziele von IBM.

Alle von IBM angegebenen Preise sind empfohlene Richtpreise und können jederzeit ohne weitere Mittei-lung geändert werden. Händlerpreise können u. U. von den hier genannten Preisen abweichen.

Diese Veröffentlichung dient nur zu Planungszwecken. Die in dieser Veröffentlichung enthaltenen Infor-mationen können geändert werden, bevor die beschriebenen Produkte verfügbar sind.

Diese Veröffentlichung enthält Beispiele für Daten und Berichte des alltäglichen Geschäftsablaufes. Siesollen nur die Funktionen des Lizenzprogramms illustrieren; sie können Namen von Personen, Firmen,Marken oder Produkten enthalten. Alle diese Namen sind frei erfunden; Ähnlichkeiten mit tatsächlichenNamen und Adressen sind rein zufällig.

COPYRIGHTLIZENZ:

Diese Veröffentlichung enthält Musteranwendungsprogramme, die in Quellensprache geschrieben sind.Sie dürfen diese Musterprogramme kostenlos kopieren, ändern und verteilen, wenn dies zu dem Zweckgeschieht, Anwendungsprogramme zu entwickeln, zu verwenden, zu vermarkten oder zu verteilen, diemit der Anwendungsprogrammierschnittstelle konform sind, für die diese Musterprogramme geschriebenwerden. Diese Beispiele wurden nicht unter allen denkbaren Bedingungen getestet. Daher kann IBM dieZuverlässigkeit, Wartungsfreundlichkeit oder Funktion dieser Programme weder zusagen noch gewähr-leisten.

Kopien oder Teile der Musterprogramme bzw. daraus abgeleiteter Code müssen folgenden Copyrightver-merk beinhalten:

© (Name Ihrer Firma) (Jahr). Teile des vorliegenden Codes wurden aus Musterprogrammen der IBMCorp. abgeleitet. © Copyright IBM Corp. _Jahr/Jahre angeben_. Alle Rechte vorbehalten.


Informationen zu ProgrammierschnittstellenIn der vorliegenden Veröffentlichung werden vorgesehene Programmierschnittstellen dokumentiert, mitderen Hilfe Kunden Programme für den Zugriff auf die Services von IBM i schreiben können.

MarkenIBM, das IBM Logo und ibm.com sind Marken oder eingetragene Marken der International Business Ma-chines Corporation. Weitere Produkt- und Servicenamen können Marken von IBM oder anderen Herstel-lern sein. Eine aktuelle Liste der IBM Marken finden Sie auf der Webseite "Copyright and trademark in-formation" unter www.ibm.com/legal/copytrade.shtml.

IT Infrastructure Library ist eine eingetragene Marke der Central Computer and TelecommunicationsAgency. Die Central Computer and Telecommunications Agency ist nunmehr in das Office of Govern-ment Commerce eingegliedert worden.

Intel, das Intel-Logo, Intel Inside, das Intel Inside-Logo, Intel Centrino, das Intel Centrino-Logo, Celeron,Intel Xeon, Intel SpeedStep, Itanium und Pentium sind Marken oder eingetragene Marken der Intel Cor-poration oder deren Tochtergesellschaften in den USA oder anderen Ländern.

Linux ist eine eingetragene Marke von Linus Torvalds in den USA und/oder anderen Ländern.

Microsoft, Windows, Windows NT und das Windows-Logo sind Marken der Microsoft Corporation inden USA und/oder anderen Ländern.

ITIL ist eine eingetragene Marke und eine eingetragene Gemeinschaftsmarke des Office of GovernmentCommerce, welche beim US Patent and Trademark Office registriert sind.

Java und alle auf Java basierenden Marken und Logos sind Marken von Sun Microsystems, Inc. in denUSA und/oder anderen Ländern.

UNIX ist eine eingetragene Marke von The Open Group in den USA und anderen Ländern.

Weitere Unternehmens-, Produkt- oder Servicenamen können Marken anderer Hersteller sein.

BedingungenDie Berechtigungen zur Nutzung dieser Veröffentlichungen werden Ihnen auf der Basis der folgenden Be-dingungen gewährt.

Persönliche Nutzung: Sie dürfen diese Veröffentlichungen für Ihre persönliche, nicht kommerzielle Nut-zung unter der Voraussetzung vervielfältigen, dass alle Eigentumsvermerke erhalten bleiben. Sie dürfendiese Veröffentlichungen oder Teile der Veröffentlichungen ohne ausdrückliche Genehmigung von IBMweder weitergeben oder anzeigen noch abgeleitete Werke davon erstellen.

Kommerzielle Nutzung: Sie dürfen diese Veröffentlichungen nur innerhalb Ihres Unternehmens und un-ter der Voraussetzung, dass alle Eigentumsvermerke erhalten bleiben, vervielfältigen, weitergeben undanzeigen. Sie dürfen diese Veröffentlichungen oder Teile der Veröffentlichungen ohne ausdrückliche Ge-nehmigung von IBM außerhalb Ihres Unternehmens weder vervielfältigen, weitergeben oder anzeigennoch abgeleitete Werke davon erstellen.

Abgesehen von den hier gewährten Berechtigungen erhalten Sie keine weiteren Berechtigungen, Lizenzenoder Rechte (veröffentlicht oder stillschweigend) in Bezug auf die Veröffentlichungen oder darin enthalte-ne Informationen, Daten, Software oder geistiges Eigentum.

Anhang. Bemerkungen 45

http://www.ibm.com/legal/copytrade.shtml

http://www.ibm.com/legal/copytrade.shtml

IBM behält sich das Recht vor, die in diesem Dokument gewährten Berechtigungen nach eigenem Ermes-sen zurückzuziehen, wenn sich die Nutzung der Veröffentlichungen für IBM als nachteilig erweist oderwenn die obigen Nutzungsbestimmungen nicht genau befolgt werden.

Sie dürfen diese Informationen nur in Übereinstimmung mit allen anwendbaren Gesetzen und Verord-nungen, einschließlich aller US-amerikanischen Exportgesetze und Verordnungen, herunterladen und ex-portieren.

IBM übernimmt keine Gewährleistung für den Inhalt dieser Veröffentlichungen. Diese Veröffentlichungenwerden auf der Grundlage des gegenwärtigen Zustands (auf "as-is"-Basis) und ohne eine ausdrücklicheoder stillschweigende Gewährleistung für die Handelsüblichkeit, die Verwendungsfähigkeit oder die Frei-heit von Rechten Dritter zur Verfügung gestellt.


��

IBM i Verfügbarkeit Hochverfügbarkeit - Technologien...Informationen, die nur für bestimmte...

Documents

Transcript of IBM i Verfügbarkeit Hochverfügbarkeit - Technologien...Informationen, die nur für bestimmte...