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 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 <= 4 Stunden bzw. 48 Stunden, wenn das DR- System transportiert werden muss Zusätzlicher Einsatz von VTS mit Auslagern der Sicherungen Rastatt Folie 5
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: Bau B: Bau A: Bau B: FLR CPU s + Primärdisks Mirrordisks CPU s + Primärdisks TIR als FLR Folie 8
Zeitplan für die Aktionen Folie 9
Folie 10
Folie 11
Zeitlicher Verlauf Der zeitliche Verlauf der relevanten Wiederherstellungsphasen wurde dokumentiert und ist Basis für einen realistischen DR-Plan TIR Stopp versandfertig 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