Was alles beim Cloud Computing passieren kann, habe ich in meinem Vortrag Leben und Sterben im Netz präsentiert. Lesen Sie, wie die Geschichte im vierten Beispiel aus diesem Vortrag ausgegangen ist:
1. Tag: Das Geschäftsgebaren des Rechenzentrums (RZ) eines Kunden deutet auf eine böse Eskalation mit maximalem Datenverlust hin. Erneutes Krisengespräch mit dem Kunden und Beschluss, sämtliche Daten mit einem vom RZ auf ca. 350 GByte geschätzten Volumen so schnell wie möglich abzuziehen und eine Wiederherstellung unabhängig vom RZ zu proben. Ob es wirklich 350 GByte sind, ist fraglich. Formulierung des mehrwöchigen Projekts Disaster Recovery mit dem Ziel, dem RZ jederzeit kündigen zu können. Das besondere Problem: Datenabzug via Internet in den Geschäftsräumen des Kunden würde mangels Bandbreite (2:0,4 MBit/s) mehrere Wochen dauern. Beschluss, alle Daten über den Umweg eines externen Rechners in einem meiner Büros mit deutlich mehr Bandbreite (32:2) abzuziehen.
2. Tag: Nach Hin- und Rückreise eines Netbooks auf dem Postweg zwecks Vorbereitung mit den nötigsten Programmen unter Windows 7 Pro, Vernetzung und Anschluss zweier Festplatten mit jeweils 500 GByte Kapazität. Zwei Festplatten deshalb, um ca. 130.000 Dateien in problematisch tief verschachtelten Verzeichnissen vor der nächsten Aktualisierung sicherheitshalber komprimiert duplizieren zu können. Abzug der 77 GByte umfassenden Kundendatenbank über eine direkte Remotedesktopverbindung (RDP) über Nacht. Anschließend Abzug von 10 GByte Sharepoint-Dateien und 8 GByte vom integrierten Kopierer. Summiertes Datenaufkommen: 95 GByte. Hinzu kommen sämtliche Exchange-Postfächer mit einem Gesamtvolumen von rund 13 GByte, die bereits wenige Wochen zuvor als PST-Dateien gesichert wurden, um den Umstieg auf Google Business Mail zu testen. Die enorme Abweichung zwischen geschätztem und tatsächlichem Datenvolumen ergibt sich aus programmierten Redundanzen. Nebenbei dürfte subtile Panikmache vom RZ im Spiel gewesen sein.
3. Tag: Feststellung, dass der Abzug von Daten über eine virtuelle Hintertür (!) im RZ reibungsloser verläuft als befürchtet. Kurzfristige Entscheidung, an Werktagen neue Daten nur inkrementell zu sichern und vollständige Übertragungen aufs Wochenende zu verlegen. Währenddessen trifft die Information ein, dass RZ Insolvenz angemeldet hat. Alarmstufe Rot. Umschaltung des Projekts Disaster Recovery auf höchste Dringlichkeitsstufe.
4. Tag: Ausfall des Netbooks. Vermutlich Überhitzung nach eineinhalb Wochen Dauerbetrieb mit permanentem Netzwerkverkehr bei hochsommerlichen Temperaturen. Neustart von Windows unmöglich. 1:1-Kopie aller Daten von den externen Festplatten auf eine dritte. Beim Kopieren unter Windows mit NTFS kommt es zu Fehlermeldungen. Mac OS X mit HPFS kopiert ohne zu meckern. Verdacht auf Inkonsistenz. Verschickung des defekten Netbooks mit beiden Sicherungen zur Wiederherstellung. Installation einer virtuellen Maschine mit Parallels Desktop auf einem iMac unter Snow Leopard. Wiederherstellungsversuch der kopierten Daten von der dritten Festplatte produziert Fehlermeldungen. Verdacht auf Inkonsistenz bestätigt. Erneute Wiederholung des Datenabzugs aus dem RZ über Nacht mit der Feststellung, dass die Bedienung der virtuellen Maschine via Teamviewer deutlich langsamer als auf einem originären Rechner ist. Versehentliche Löschung der virtuellen Maschine nach vermeintlicher Spiegelung, die keine war. Gefahr in Verzug.
5. Tag: Installation eines ausrangierten Macbooks mit Boot Camp und Windows 7 Pro. Zwei Abstürze über Nacht. Wiederherstellung der kopierten Daten auf der dritten Festplatte unmöglich. Verzicht aufs MacBook, da es vermutlich defekt ist. Stattdessen beschleunigte Einarbeitung in Elastic Compute Cloud (EC2) von Amazon Web Services. Installation einer Micro-Instanz in der Wolke von Amazon. Stundenlange Updates, Serveranpassungen und Erstinstallationen aller nötigen Programme, die zum Abzug und für die Wiederherstellung sämtlicher Daten aus dem insolventen RZ erforderlich sind. Feststellung, dass eine Micro-Instanz zur Ausführung von Windows-Programmen mit grafischer Benutzeroberfläche störend langsam ist. Einbindung von Simple Storage Service (S3) via Tntdrive als Netzlaufwerk führt zu einer Auslastung des zentralen Mikroprozessors (CPU) auf bis zu 100 %. Flüssiges Arbeiten unmöglich. Abschaltung von Tntdrive. Stattdessen Konzentration auf S3 Browser. Umschaltung der Micro-Instanz mit 619 MByte Arbeitsspeicher in eine Small-Instanz mit 1,7 GByte. Ergebnis: deutlich flüssigerer Programmlauf und sympathische Datenübertragungsraten jenseits von 200 MBit/s mit klar absehbarer Aussicht auf Erfolg. Insolventes RZ schafft 4 MBit/s. Pointierter Überschlag: Wofür geschätzte vier Wochen in den Büroräumen des Kunden mit der geringsten Bandbreite notwendig wären und was bei mir bis zu vier Tage gedauert hat, müsste mit EC2 in vier Stunden erledigt sein.
6. Tag: Defektes Netbook und Festplatten sind beim Empfänger angekommen. Netbook nicht wiederherstellbar. Jungfräuliche Neuinstallation erforderlich. Gespeicherte Daten auf externen Fesplatten scheinen intakt zu sein. Reibungslose Wiederherstellung ungewiss. Volle Konzentration auf EC2 und S3. Vorsorglicher Upload gesicherter Daten in ein S3-Bucket. Erweiterung der Small-Instanz um einen Elastic Block Storage (EBS) mit 250 GByte Kapazität. Wiederholte Neukonfiguration wichtiger Programme und erneuter Abzug aktueller Daten aus dem insolventen RZ über Nacht. Erfolgreiche Wiederherstellung ohne Nebenwirkungen. Einfrierung der jüngsten Instanz mit intakten Daten sowie Speicherung so genannter Snapshots beider EBS als Virgin C und D. Jetzt „darf“ im insolventen RZ das Licht ausgehen ;-)
P.S. Die Zusammenfassung dieses Protokolls auf sechs Arbeitstage lässt eine wesentliche Komponente außer Acht — die Tage und Nächte zwischen den Tagen. Was komprimiert und flüssig klingt, hat viele Stunden Zeit, Kraft und Nerven für Analysen, Tests und Wiederholungen gekostet. Mit handfester Zuarbeit eines operativen Unterstützers und seiner komplementären IT-Erfahrung hat der komprimierte Verlauf deutlich mehr als zwei Wochen zeitversetzte Aktionen und etwa zwei Dutzend längere Telefonate gedauert. Stundenlange Reisen, Beratungsgespräche und Fachlektüre im Vorfeld nicht mitgerechnet.