So kann’s kommen. Mehrere Jahre hat mir mein aus häuslichen Resten zusammen- gebastelter, um eBay-Fundstücke erweiterter 4‐HE‐Dual‐P3‐Rechner im Housing gute Dienste geleistet — aber offensichtlich ist nach 6+ Jahren Lebenszyklus das Ende der Fahnenstange erreicht …
Das stabilste Blech unter der Sonne war es nie, aber das schob’ ich auf einige Experimente, die ich mit der Kiste veranstaltete — zu sporadisch trat es auf und zu leicht verschwanden die Probleme durch Unterlassen allzuviel Spielerei, als daß ich auf ein Hardwareproblem getippt hätte. Um so unvorbereiteter traf mich der sich beschleunigende Niedergang ab Mitte letzter Woche.
Gut, die meisten Daten waren extern gesichert bzw. nicht unwiederbringlich. Der Plan war daher, bei einem ernsten Problem, von der einen, sehr wahrscheinlich noch intakten, Spiegelhälfte ein Image zu ziehen auf eine neue Kiste, wo in einer Virtualisierungsumgebung (VMWare Server, UML, vServer, OpenVZ, …) dann einfach dieses Image hochgefahren wird, kurz und schmerzlos.
Vor ca. einem halben Jahr holte ich daher meine zweile Kiste, die nach einem doppelten Plattendefekt lobotomisiert im RZ eh’ zu nichts mehr nütze war, zurück und begann mit dem Neuaufbau des Redundanzsystems.
Time goes by, everything ages — and Murphy strikes.
Böser Murphy. Der noch servende Server stellt das Serven ein — und zwar so, daß nicht, wie bislang sporadisch, ein panic() gefolgt vom Reboot geschieht, nein, jetzt knallt es in Programmen. Mithin ist ein Software-Shutdown nicht mehr durchführbar, der hängt dann beim Versuch, die Prozesse zu beenden.
Also Remote-Hands triggern, daß sie das berühmte Knöpfchen drücken, versuchen, die Daten über’s Netz runterzukratzen — und dabei immer wieder Stunden verlieren, weil der Server mittendrin sich weghängt. Kein Spaß. Nicht mal ansatzweise. Parallel den zweiten Server fertigmachen — inkl. Distributionswechsel (Fedora -> Debian), was die Migration wiederum aufwändiger macht.
Wie auch immer: es ist vollbracht, aber alles andere als so, wie geplant.
- Wegen des akuten Ausfalls bei schlechter Prognose keine sanfte Migration möglich ⇒ full-blown Installation muß kopiert werden
- Die gewählte Serverbasis ist Debian Etch mit vserver-Kernel ⇒ UML oder VMWare wird benötigt für FC4 als Gast
- Kurzer Check via Google ergab nicht klar, ob der vserver-Kernel von Debian Etch SKAS-Unterstützung mitbringt; ohne SKAS ist UML aber nicht sinnvoll einsetzbar (mail.uu.org läuft seit Jahren als virtualisierte RH7-Installation auf einem FC3-Host mit SKAS-Patch) ⇒ VMWare Server wird das Produkt der Wahl
- VMware kann offenbar (zumindest wüßte ich nicht, wie) nicht mit reinen FS-Images arbeiten sondern braucht die Partitionsdaten; nachvollziehbar, aber bei UML geht das ⇒ 14 GB (Endgröße, Abbrüche nicht eingerechnet) umsonst übertragen
- Selbst dd | nc setzt die Grenzen von <= 12 MByte/sec bei 100 MBit/sec nicht außer Kraft ⇒ Migration der 36 GB Platte blieb zeitraubend
Es gäbe noch weitere Punkte — aber dies soll erstmal reichen. Status ist: http://sietland.net und http://blogdoch.net laufen statt auf realer Hardware (derzeit) in einem VMware Server. Und ich habe neue Hausaufgaben bzgl. des Desasterkonzepts für meine kleine Serverfarm ;)
Totalausfall von Sonntag 17 Uhr bis Dienstag 10 Uhr. Dabei hätte es so einfach sein können — z. B. mit einem außerhalb der Kiste liegenden Dump *seufz* Es bleibt ein Trost: Aus Schaden wird man klug.
Kollege corona berichtete kürzlich über sein neuestes Spielzeug — einen »USB Missile Launcher«: 
Was er bislang nicht berichtete: es gab, nur zwei Tage später, einen Betriebsunfall mit Kollateralschäden.
»StudiVZ«‐Nennung Technorati entdeckt.