Zusammenfassung der Ausfallszenarien

Ausfall	Bedingung	gemeldet durch	Betriebs- Unterbre- chung?	Auswirkungen	Reaktion (Maßnahme)	Dateninkonsistenz beim späteren Umschalten auf Targets?
Source- bzw. Target-Unit	geschützt	NJD00121	nein	-	Service (Maßnahme A)	nein
	ungeschützt, ON-ERR=   *CONT	NJD00121, NDE0020	nein	Performance, wenn Source-Unit betroffen ist	Service Inkonsistenz zu beachten (Maßnahme B)	ja, wenn Target-Unit betroffen
	ungeschützt, ON-ERR=   *HOLD	NJD00121, NDE0020	REMOUNT NKVD014	Anwendungen warten	Maßnahme A oder mit verbleibender Unit weiterarbeiten	nein ja
einzelne remote Verbindung		NJD00121, NDE0010	nein	Schreib-Performance	Service	nein
letzte remote Verbindung	ON-ERR=    *CONT	NJD00121, NDE0010, NDE0012	nein	-	Service Inkonsistenz zu beachten	ja
	ON-ERR=   *HOLD	NJD00121, NDE0010, NDE0020, NDE0012	REMOUNT NKVD014	Anwendungen warten auf Antwort	Maßnahme A oder mit verbleibender Unit weiterarbeiten	nein ja
Storage-System mit Source-Units		PGER- Meldung	ja		Maßnahme A	möglich2
lokales System	-	..	ja	-	neu starten	nein
Komplettausfall 3		..	ja		Maßnahme A	möglich2
Rückumschalten auf lokales Storage-System		-	ja		Maßnahme B

1	Meldungen NJD0012 werden für x86-Server nicht unterstützt.
2	Dateninkonsistenz beim späteren Umschalten auf die Targets ist möglich, wenn nicht der synchrone oder asynchrone (SRDF/A) Verarbeitungsmodus eingestellt ist oder wenn Fehler an remote Verbindungen oder Fehler bei Target-Units vorausgehen.
3	Ausfall des lokalen Storage-Systems mit Source-Units und Ausfall des lokalen Systems.

Maßnahmen zur Behebung des Ausfalls

Maßnahme	Beschreibung	Bedingung	Aktion	Kommando
A	Umschalten auf Target-Unit, lokales System betroffen		Ersatz-Host hochfahren, Target-Units zuschalten	/ATTACH-DEVICE
		Source- und Target-Unit waren synchronisiert	Target-Units verfügbar machen	/SET-REMOTE-COPY-ACCESS TARGET-ACCESS=*DIRECT
		Source- und Target-Unit waren nicht synchronisiert, Inkonsistenzen akzeptabel (bzw. Rücksetzen auf letzten Konsistenzpunkt)		/SET-REMOTE-COPY-ACCESS TARGET-ACCESS= *DIRECT(PEND-UPD- ALLOWED=*YES)
B	Rückumschalten auf das lokale Storage-System, Betrieb auf Standby-System		Nutzung der Target-Units beenden	/EXPORT-PUBSET
			Target-Units nicht verfügbar machen	/SET-REMOTE-COPY-ACCESS TARGET-ACCESS=*BY-SOURCE
			alle Kanäle und remote Verbindungen am lokalen Storage-System deaktivieren	(Service)
			lokales Storage-System hochfahren	(Service)
		lokales Storage-System OK (Service prüft)	remote Verbindungen zuschalten und aktivieren	(Service)
		Abgleich OK / automatische Synchronisierung begonnen?	Kanäle zuschalten	(Service)
			lokales System hochfahren

Besonderheiten zu Ausfallszenarien mit SRDF/A

SRDF/A setzt stets auf einer bestehenden SRDF-Replikation auf (siehe "SRDF/A-Konfigurationen"). Deshalb erfolgt die Wiederaufnahme von SRDF/A nach einem Ausfall in zwei Schritten. Zunächst ist die SRDF-Replikation wieder aufzunehmen (wie in den vorausgehenden Abschnitten beschrieben), danach kann die SRDF/A-Session wieder aktiviert werden.

Bei einer SRDF/A-Replikation sind beim Ausfall folgende Besonderheiten zu beachten.

• SRDF-Link-Ausfall

  • Temporärer Ausfall:SRDF/A ist in der Lage temporäre Ausfälle von SRDF-Links zu kompensieren. Im Storage-System kann ein Zeitintervall von 0 bis 10 Sekunden konfiguriert werden, für das SRDF/A einen SRDF-Link-Ausfall toleriert. Werden innerhalb dieses Intervalls die Links wieder verfügbar, bekommt die Anwendung davon nichts mit. Nach Ablauf des Zeitintervalls, wird wie bei einem permanenten Ausfall verfahren.

  • Permanenter Ausfall:
    Im Fall eines permanenten Ausfalls wird die SRDF/A-Session automatisch abgebrochen. Die Daten auf der Target-Seite sind konsistent. Nachdem die Links wieder verfügbar sind, kann der SRDF-Betrieb mit den üblichen SRDF-Recovery-Verfahren wieder aufgenommen werden und eine neue SRDF/A-Session aktiviert werden.

• Verfügbarer Cache für SRDF/A im lokalen Storage-System voll

  Wenn die I/O-Last für das lokale Storage-System, die verfügbare Bandbreite für die SRDF/A-Replikation und die Cache-Größe des Storage-Systems nicht (mehr) korrekt konfiguriert sind, kann es vorkommen, dass der gesamte verfügbare Schreib-Cache für SRDF/A im lokalen Storage-System aufgebraucht wird.

  Für diesen Fall können durch den Service alternativ 2 Verhalten eingestellt werden:

  • Die Anwendung wird auf die Übertragungsgeschwindigkeit der SRDF-Links heruntergebremst. Das bedeutet für diesen Zeitraum eine schlechtere Performance, vergleichbar mit einem synchronen SRDF-Betrieb in derselben Konfiguration.

  • Es wird sofort und automatisch ein Abbruch der SRDF/A-Session durchgeführt. Dieser kann im Rahmen eines konfigurierbaren Zeitintervalls verzögert werden (die Standardeinstellung des Zeitintervalls ist 0 Sekunden). Innerhalb dieses Zeitintervalls wird die Anwendung gebremst. Wenn sich der Engpass innerhalb des Zeitintervalls auflöst, wird die SRDF/A-Session fortgesetzt, andernfalls abgebrochen.

• Disaster-Recovery, Failback-Verfahren von der Target-Seite

  Bei Ausfall sind die Daten auf der Target-Seite konsistent. Aus Sicht der Failback-Verfahren unterscheidet sich die Vorgehensweise nicht von der Vorgehensweise bei SRDF. SRDF/A kann nach einem Failback wieder aktiviert werden, sobald die Anwendung auf dem lokalen Server wieder verfügbar ist.