Eine real erlebte Geschichte und meine Lehren daraus
Es ist einige Jahre her, als man noch der Meinung war: raus mit dem Blech; wir setzen voll auf virtualisierte Strukturen. So weit, so gut sollte man meinen. Die PRO Argumente liegen klar auf der Hand: weniger Maintenance- und Hardwarekosten, effizientere Nutzung und Platzeinsparung. Was aber, wenn in einer komplett virtualisierten Umgebung der Totalausfall eintritt?
Ehrlich gesagt: bis dato hatte ich mir darüber auch noch keine tieferen Gedanken gemacht, war der Meinung „man kriegt das sicher wieder sauber zum laufen“. Leider musste ich schmerzlich erfahren, dass mitunter die vmdk’s (virtuelle Festplatten) einen Knacks haben und mitunter diverse Snapshots der Platten zusätzlich mein Disaster verschlimmerten. Konsolidierungsversuche des völlig überlasteten NFS-Stores (Storage & Filesystem) scheiterten und somit waren die Maschinen nicht mehr bootbar.
Was also tun, sind doch Domänen Controller und IP-Services (DHCP, DNS) virtualisiert. Glück im Unglück: der Backupserver lief so ziemlich als einziger sauber an. Dank „Veeam“ konnte zumindest dann schnell der erste DC wiederhergestellt werden und nach und nach einige andere Maschinen auch.
Ein externer Partner half mir dann recht schnell bei der Lösungsfindung. Die Problematischen Server hatten letztlich ein Problem mit der eigenen VMX-Datei (virtuelle Gast Informations- & Konfigurationsdatei). Nach Neuerstellung der VM (ohne HDD’s) und verschieben der alten vmdk’s in das Verzeichnis der neu erstellten Maschinen wurden diese dann in die neue Maschine gemounted. Et voilà – die Maschinen liefen wieder gewohnt sauber an.
Einzig ein Server war besonders herausfordernd. Hier waren die Snapshots nicht gemounted und der Server dadurch auf sehr altem Stand nach dem booten (letzter Stand vor dem Snapshot). Mit viel Mühe wurden hier die Snapshot ID’s dann wieder der Konfig angepasst: Operation am offenen Herzen unter freiem Himmel quasi. Am Ende lief das sauber, Daten alle verfügbar.
Ende gut, alles gut…..könnte man sagen. Für mich allerdings eher die Frage: was kann man daraus für Schlüsse ziehen und wie setzt man diese um?
Zunächst ganz klar: wer kennt nicht „Admin’s Disaster Day“? Man versucht etliches und kommt nicht auf die einfachen Dinge. Der Grund: mitunter verfummelt man sich schlicht und ergreifend. Dies ist auch normal unter steigendem Druck von außen und dem eigenen Anspruch „irgendwie wieder zum Laufen bringen“. Der Faktor Mensch denkt nicht wie Maschine! Und unter Streß handelt ein Admin schon gar nicht nach dem Lexikon der „IT-Weisheiten“. Was also sind meine rückblickenden Gedanken, welche ich hier publizieren möchte.
- Besonders wichtig ist, dass man versucht die Ruhe irgendwie zu bewahren. Mir fällt dazu ein alter Spruch ein: „Operative Hektik ist oft Zeichen geistiger Windstille“. Hilfreich ist hierbei wie in meinem Fall, dass möchte ich unbedingt erwähnen, ein Vorgesetzter, welcher pragmatisch und ruhig den Druck von außen herausnimmt.
- Ruhezeiten: wenn die Infrastruktur komplett still steht und das Business betroffen ist werden die Stunden lang. Die innere Unruhe steigt und an Schlaf ist nicht zu denken. Das Problem dann: es kommt ein Punkt wo man zumindest mal einige Stunden Ablenkung braucht (Familie, Sport oder irgendetwas „nicht IT-Typisches“). Danach hat man wieder neue Ideen und Gedanken: deutlich Effizienter als kurz vor dem kollabieren zu sein. Nicht zu vergessen: ein Admin ist ein Mensch und mitunter sind auch eine Dusche, Nahrungsaufnahme und Klamottenwechsel durchaus nötig.
- Priorisierung: in meinem Fall werde ich beim nächsten Fall (ich hoffe der tritt nie ein) 15min Zeit nehmen ein Flipchart zu erstellen, auf welchen in Absprache mit der Geschäftsleitung die Prioritäten plakatiert werden. Je länger man vertieft ist umso mehr verliert man die Prioritäten aus den Augen. Eventuelle „Deathlines“ können sinnvoll sein (z.B. wie lange versuchen wir die Reparatur vor der Neukonfiguration).
- Erreichbarkeit: nichts ist störender als „die offene Tür und das klingelnde Handy“. Hier muss ich ein großes Lob an meine aktuellen User sagen. In anderen Firmen habe ich dies erfahrungsgemäß nicht so erlebt. Mein Rat daher: Handy aus, Tür abschliessen (oder Azubi in die Tür stellen als Bodyguard). Ein Notfallhandy ist eventuell sinnvoll: die Nummer sollte aber nur sehr ausgewählten Personen bekannt sein.
- Externe Hilfe FRÜHZEITIG in Betracht ziehen. Absolut sinnvoll in jeglicher Hinsicht. Sei es der Bewertung der eigenen Infrastruktur oder aber aktiv helfend. Andere Denkansätze bringen neue Erkenntnisse. Hier hatte ich tolle Unterstützung (Danke an dieser Stelle MJ und JH).
Die technischen Schlüsse, welche sich für mich ergeben sind folgende.
- Ich bin schon immer der Auffassung: ein physischer DC ist ein „must have“. Mag sein, dass dieses „old school“ ist – aber diese Ansicht hat sich nun manifestiert. Und sei es nur wegen DHCP und DNS.
- Der Backupserver kann zwar virtuell sein sollte aber im absoluten Notfall z.B. auf einem Laptop des Admins gestartet werden können. Ich werde mir daher regelmäßig einen Klon der Backupmaschine ziehen, und sei es nur um einen einzigen virtuellen Gast zu retten.
- Dokumentation ist das A & O: hier hat mir (mal wieder) „Docusnap“ maßgeblich das Leben gerettet. Zum Glück repliziere ich mir meinen Docusnap-Server auf mein Notebook und bin somit in der Lage den letzten IST-Stand meiner IT-Infra zu betrachten. Beispiele, welche ich nutzte:
- Welche VMDK war wie in dem virtuellem Gast gemounted?
- Wer hat sein Postfach auf welchen Exchange-Server?
- Wie war die alte MAC / IP des virtuellen Gast’s
- Auf welchem SQL-Server befand sich die DB für VoIP-Telefonie?
- Konfigurationsdateien von Hardware liegen meist auf File-Strukturen. Doch was ist, wenn die nicht erreichbar ist und man nicht lange suchen möchte? Die Konfiguration eines Switches oder Routers ist einfach wiederherstellbar: wenn man die Konfigdatei griffbereit hat. Hier auch wieder Docusnap der ultimative Helfer: Konfigdatei als Attachment an der Device und das suchen hat ein Ende (wir haben die DB ja auf das Admin-Notebook repliziert im Punkt 3).
- Netzwerkstruktur flach halten: wenn zuviele VLAN’s und Routings der VLAN’s untereinander bestehen wird im Disasterfall ein Neuaufbau zur Farce. Flaschenhals und Looping mitunter eingebaut und keiner weiss warum. Bisher war ich selber überzeugter VLAN-Fan, stell(t)e aber mittlerweile fest, dass man sich dadurch ziemlich verrennen kann und sich mehr und mehr Klötze in den Weg legt aufgrund der Komplexität.
Gerne würde ich hier von „meinen Lesern“ Feedback erhalten. Vielleicht kann dies ja untereinander helfen und nachhaltige Erfahrungswerte einbringen. Ich selber werde genau diesen Beitrag hier ausdrucken und an meine Pinnwand hängen: als „Review für die Zunkunft“ quasi. Auch nach nahezu 20 Jahren IT lernt man eben nie aus.