Wenn ein Wiederanlauf des Produkts auf einem anderen System möglich sein soll,
müssen zunächst auf allen Systemen (dem ursprünglichen System sowie den für die Wiederherstellung vorgesehenen Systemen)
die folgenden Voraussetzungen installiert und dann die
ARM-Richtlinien für Peerneustart und Peerwiederherstellung rekonfiguriert werden.
Vorbereitende Schritte
Veraltetes Feature: Die Funktion "Peerneustart und Peerwiederherstellung" ist veraltet. An Stelle
der PRR-Funktion für Transaktionen sollten Sie die integrierte Unterstützung für hohe Verfügbarkeit für die Unterkomponente Transaktionsservice verwenden. Weitere Informationen zur integrierten Unterstützung für hohe Verfügbarkeit für die Unterkomponente Transaktionsservice finden Sie
im Artikel
Transaktionsunterstützung in WebSphere Application Server. Dort ist auch beschrieben, wie diese Unterstützung für eine Peerwiederherstellung von Transaktionen, die auf einem ausgefallenen Anwendungsserver ausgeführt werden,
konfiguriert wird.
depfeat
Außerdem müssen Sie sicherstellen, dass
alle Systeme, auf denen ein Wiederanlauf möglich sein soll, zu einer RRS-Protokollgruppe gehören.
- z/OS Version
1.2 oder höher
- BCP-APAR OA01584
- RRS-APARs OA02556 und OA2556
- WebSphere Application Server Version
5 oder höher
Die Installation der vorausgesetzten Serviceupdates auf allen Systemen hat keinen negativen Einfluss auf Ihre aktuelle aktive Umgebung, sodass
Sie auch weiterhin einen Wiederanlauf auf demselben System durchführen können. Wenn diese Services nicht installiert sind,
besteht jedoch die Möglichkeit, dass der Controller nicht zurückversetzt werden kann. Der OTS wird auf dem alternativen System einen
Wiederanlauf versuchen und scheitern. Falls es zu diesem Zeitpunkt noch unaufgelöste Arbeitseinheiten (URs) im
RRS gibt, ist ein Wiederanlauf des Controllers auf dem Ausgangssystem erst möglich, wenn der RRS auf dem alternativen System
abgebrochen wird. Weitere Informationen zu OTS und RRS finden Sie in der Veröffentlichung
z/OS MVS Programming: Resource Recovery.
Falls Sie keinen Peerneustart und keine Peerwiederherstellung planen,
müssen Sie
die hier genannten funktionalen Voraussetzungen nicht erfüllen. Sie müssen dann den Wiederanlauf auf dem Ausgangssystem
ausführen.
Die folgenden Produkte unterstützen alle den
RRS. Einzeln unterstützen sie auch den Peerneustart und die Peerwiederherstellung, sofern die oben aufgelisteten Voraussetzungen ordnungsgemäß
installiert sind:
- DB2 Version
7 oder höher
- IMS Version
8 oder höher
- CICS Version
1.3 oder höher
- MQSeries Version
5.2 oder höher
Neben den vorausgesetzten Produkten können viele JTA-XAResource-Manager
verwendet werden, um den Peerneustart und die Peerwiederherstellung im Produkt zu unterstützen. Stellen Sie anhand
der Dokumentation zu Ihrem JTA XAResource Manager fest, ob der Manager den Wiederanlauf auf einem alternativen System
unterstützt.
Fehler vermeiden: Wenn Sie die ARM-Richtlinie für einen Sysplex konfigurieren, vergewissern Sie sich,
dass auf beiden Systemen derselbe
Application-Server-Versionsstand installiert ist. Einen Anwendungsserver, der
WebSphere Application Server Version 5.1 ausführt, kann nicht für
Peerneustart und Peerwiederherstellung für einen Anwendungsserver mit
WebSphere Application Server Version 6.0.1 verwendet werden.
gotcha
Vor dem Peerneustart und der Peerwiederherstellung
ist Folgendes erforderlich:
- Sie müssen sicherstellen, dass der Location Service Daemon und der Node Agent auf allen Systemen, die für
die Wiederherstellung in Frage kommen, aktiv sind. Andernfalls könnte das wiederherstellende System versuchen,
ein System wiederherzustellen, auf dem der Location Service Daemon und der Node Agent nicht ausgeführt werden. Die Folge wäre,
dass der Server nicht startet und die Wiederherstellung scheitert.
Wenn die Systeme an der Leistungsgrenze arbeiten, macht sich bei den Clients ein Leistungsrückgang bemerkbar. Auf Servern im Modus für
Peerneustart werden die Enterprise-Bean und die Web-Container
nicht neu gestartet, um die Auswirkungen auf Speicher und CPU des alternativen Systems so gering wie möglich zu halten. Das bedeutet für Anwendungsserver, die wiederhergestellt werden,
dass sie keine eingehenden Aufgaben annehmen können.
Informationen zu diesem Vorgang
Wenn Sie nach der Installation der vorausgesetzten Produkte einen Server auf einem System starten, für das er nicht konfiguriert wurde,
wechselt er automatisch in den Modus für Peerneustart und -wiederherstellung. Wenn Sie Ihr
XA-Partnerprotokoll so konfiguriert haben, dass in ein nicht gemeinsam genutztes HFS geschrieben wird, oder wenn Sie einen JTA-XA-Ressourcenmanager verwenden, müssen
Sie die folgenden Schritte ausführen, bevor Sie einen Server starten:
Vorgehensweise
- (Nur bei einem nicht gemeinsam benutzten HFS erforderlich.) Aktivieren Sie die Unterstützung für nicht gemeinsam benutztes
HFS. Wenn Sie ein nicht gemeinsam benutztes HFS verwenden, müssen die Konfigurationseinstellungen auf den verschiedenen Systemen
des Sysplex repliziert werden. Dieser Schritt wird automatisch vom Deployment Manager und vom
Node Agent ausgeführt. Zum Aktivieren der entsprechenden Unterstützung muss jeder Node Agent in Ihrer Konfiguration
als ein Wiederherstellungsknoten konfiguriert sein. Diese Änderung können Sie in der Administrationskonsole
vornehmen:
- Wählen Sie in der Administrationskonsole aus.
- Wählen Sie in der Liste einen Node Agent aus.
- Wählen Sie im Abschnitt "Weitere Eigenschaften" die Option Dateisynchronisationsservice aus.
- Wählen Sie unter "Weitere Eigenschaften" die Option aus.
- Wählen Sie aus.
- Geben Sie recoveryNode im Feld Name und true im Feld Wert ein.
Das Feld Beschreibung können Sie leer lassen.
- Wiederholen Sie die Schritte 3-7 für jeden Node Agent in Ihrer Konfiguration.
- Speichern Sie die Konfiguration.
- (Nur bei Verwendung von JTA XAResource Managern erforderlich.) Stellen Sie sicher, dass
die erforderlichen Protokolle und Klassen auf dem alternativen System verfügbar sind. Wenn Sie
die Verwendung des Peerneustarts und der Peerwiederherstellung planen
und Ihre Anwendungen auf JTA-XAResource-Manager zugreifen, müssen Sie sicherstellen, dass auf dem alternativen System
die entsprechenden Protokolle und Klassen verfügbar sind.
- Die Variable TRANLOG_ROOT muss auf ein gemeinsam benutztes
HFS zeigen. Die Variable TRANLOG_ROOT muss auf ein gemeinsam benutztes HFS zeigen, in das alle Systeme der Zelle
schreiben können. In diesem System wird das XA-Partnerprotokoll gespeichert und das alternative System muss
dieses Protokoll lesen und aktualisieren können.
- Klicken Sie in der Administrationskonsole auf .
- Klicken Sie unter "Container-Services" auf Transaktionsservice.
- Geben Sie das Verzeichnis des gemeinsam genutzten HFS im Feld Transaktionsprotokollverzeichnis ein.
- Speichern Sie den Treiber (JDBC-Treiber, JMS-Provider oder JCA-Ressourcenadapter)
für jeden JTA XAResource Manager in einem HFS, das von allen
Systemen in der Zelle gelesen werden kann. Falls Ihr Connector
beispielsweise ein JDBC-Treiber für eine Datenbank ist, wird der Treiber wahrscheinlich in einem schreibgeschützten
HFS gespeichert, auf das alle Systeme im Sysplex zugreifen können. So ist gewährleistet, dass das alternative System
den gespeicherten Klassenpfad für die Ressource lesen und beim Wiederanlauf rekonstruieren kann.
Falls der für den Zugriff
auf einen JTA XAResource Manager verwendete Connector nicht in einem HFS gespeichert, das von allen für die Wiederherstellung in Frage kommenden
Systeme lesbar ist, sind zwei Folgen möglich:
Beim Wiederanlauf eines Anwendungsservers auf einem alternativen System sieht es so aus,
als wäre keine XA-Wiederherstellung erforderlich, oder die für die Kommunikation mit dem JTA XAResource Manager erforderlichen
Klassen können nicht geladen werden.
- Beenden Sie Einheiten mit unbestätigtem Status.
Bei der Wiederherstellung kann es vorkommen, dass für die Beendigung von
Einheiten mit unbestätigtem Status ein manueller Eingriff erforderlich ist.
Für diesen manuellen Eingriff müssen Sie RRS-Anzeigen verwenden.