Folie 1

gtug.de

Folie 1

Desaster Recovery Konzept für HP NonStop Server bei

Daimler und Test am Beispiel Mercedes-Benz Werk

Rastatt

Manfred Klump, Daimler AG


Agenda

Anforderungen und Rahmenbedingungen

DR-Konzept für die deutschen Standorte

Durchführung eines DR-Tests mit dem Werk Rastatt

Fazit

Folie 2


Anforderungen und Rahmenbedingungen

• Kein Datenverlust, kein Transaktionsverlust

• Wiederanlaufzeit nach Desaster im Stundenbereich ( < 48 Stunden)

• Die DR-Lösung muss betreibbar sein

• Keine (geringe) zusätzlichen Risiken

• Keine (geringe) Komplexitätserhöhung

• Keine (geringe) Mehraufwände in der Administration und im laufenden Betrieb

•Die DR-Lösung muss testbar sein

•Keine AWAN/SWAN und keine MAC basierte Kommunikation

•Die DR-Lösung muss finanzierbar sein

•Die DR-Lösung muss von HP supported sein

•Zwei Varianten wurden betrachtet

• Host Based Mirroring incl. Desaster Rechner Rechner zu den Daten

• Zentraler RDF Knoten Daten zum Rechner

Folie 3


Definition RTO und RPO

Folie 4


DR-Lösung auf Basis Host Based Mirroring und Nutzung des

zentralen Integrationsrechners

Sindelfingen

mobiles

Desaster

Recovery

System

Rastatt

Bremen

• Räumliche Trennung der gespiegelten

Platten an jedem Standort (max 5 km)

• Integrationsrechner als DR-Rechner so

konfigurieren, dass dieser jeden

Produktionsrechner ersetzen kann

• Aufbau des DR-Systems an einem

Standort neben den ausgelagerten Platten

(auch für Desaster Tests)

• Im Desasterfall wird der Integrationsrechner zu

den Platten transportiert und in Betrieb genommen

• Wiederanlauf der Applikation


Realisierung des Host Based Mirroring im Werk Rastatt

Bau A Bau B

Folie 6


Durchführung eines DR-Tests mit dem Werk Rastatt

• Im Rahmen der Itanium-Migration des FLR Rastatt konnte eine einmalige Gelegenheit für

einen vollständigen DR-Test genutzt werden

• kein Risiko/keine Beeinflussung der Produktion, da neuer FLR in Testphase

• vollständiger Nachweis der Tragfähigkeit des Konzepts sowohl für das Werk Sindelfingen

(dort im Rahmen ltanium-Migration bereits verifiziert) als nun auch für einen entfernten

Standort

• Erfüllung der Konzernrichtlinien zur DR-Planung insofern, dass der Notfallplan mindestens

einmal getestet wurde

• Verifizierung der Notfallpläne, Arbeitsschritte, Ablaufbeschreibungen, Dokumentationen usw.

• Verprobung der Zusammenarbeit aller im DR-Fall Beteiligten

• Verprobung des Transports und der Transportwege (Spedition, Werkszugang,

Aufzüge, Rampen)

• Dokumentation des tatsächlichen zeitlichen Ablaufs

• Verifizierung der gesamten notwendigen Infrastruktur (Strom, Netz, Verkabelungen,

Konfigurationen, Lizenzkeys)

Folie 7


Testszenario Rastatt

Normalbetrieb Desaster-Fall

Bau A:

FLR CPU‘s +

Primärdisks

Bau B:

Mirrordisks

Bau A:

CPU‘s + Primärdisks

Bau B:

TIR als FLR

Folie 8


Zeitplan für die Aktionen

Folie 9


Folie 10


Folie 11


TIR Stopp

versandfertig

Zeitlicher Verlauf

Der zeitliche Verlauf der relevanten Wiederherstellungsphasen wurde dokumentiert und ist Basis für einen

realistischen DR-Plan

Verladen

Transport

Abladen

HW-Aufbau,

betriebsbereit

Start Prüfen

Anwend.

Testzeit

Rastatt

FLR wiederher-stellen

2:15 2:45 3:00 1:00 4:00 1:30

HW rückversandfertig

Verladen

Transport

Abladen

TIR

betriebsbereit

2:00 2:30 2:45

Folie 12


Fazit

• Innerhalb von ca. 9 Stunden (ab K-Fall Entscheidung) kann in Rastatt für den FLR ein

Ersatzsystem bereitgestellt werden

• Voraussetzung: Eine Spedition kann innerhalb von 2 Stunden vor Ort in

Sindelfingen sein.

• Nach Bereitstellung eines neuen Rechners im Ausweich-RZ ist der technische

Übergang in ca. 2 Stunden möglich (wurde auch in Sindelfingen verifiziert).

• Der Datenbestand wird jeweils transaktionsgenau übernommen.

• Der Aufwand für den DR-Test (Vorbereitung und Durchführung) und Spedition,

Versicherung, HP-Support ist wirtschaftlich tragbar.

Folie 13


Erkenntnisse aus dem DR-Test

Es traten lediglich drei beherrschbare technische Probleme auf:

• Kabeldefekte (Glasfaser) sind möglich, Ersatzkabel vorhalten

• überzählige CPUs müssen abgeschaltet werden, sonst können SECOM und PROGNOSIS nicht gestartet

werden (Lizenzkeys müssen passen). Die Alarme zu HP müssen unterdrückt werden.

• in den P-Switchen (Servernet) muss der Systemname ebenfalls angepasst werden

Handlungsbedarfe im Hinblick auf die Umsetzung im Werk Bremen:

• Anpassung der Reihenfolge von System- und Anwendungsplatten an die Konfigurationen von Sindelfingen

und Rastatt

• Überprüfung der Plattenpfade (primary/mirror), Verkabelung und logische Sicht müssen übereinstimmen

und einheitlich sein

• Überprüfung der Netzwerkanschlüsse der Konsole und korrekte Dokumentation, da diese von HP

unterschiedlich ausgeliefert werden können

• genereller Check aller relevanten Konfigurationen, die einheitlich sein müssen

Folie 14

Weitere Magazine dieses Users
Ähnliche Magazine