Sie sind hier : Homepage →  Erfahrungen mit Windos aller Art→  Der April 2014 GAU

Die Web-Server bei uns hier in Wiesbaden gibt es seit 1997 ....

Der Anfang: RDE Server Jan 1997
Unser RDE EDV Raum - für unsere Server Ende 2001

von Gert Redlich im Mai 2014 - Unsere diversen Internet-Server betreiben wir seit April 1997, erst in den eigenen Räumen in Wi-Bierstadt, dann in einer "Housing"-Lokation der Wi(esbadener)-T(ele)com, die neben den ganzen Glasfaserstrecken in Wiesbaden auch zwei große Server-Housings (Server-Keller) betreibt. - - - - - - - -

17 gute Jahre bis zum ersten GAU

Mit ein paar Ausnahmen lief unsere "Server-Farm" über Jahre rund um die Uhr. Ausfälle durch Erneuerungen von Soft- oder Hardware gab es meist nur spät Nachts. Einen richtigen "GAU" hatte ich jedenfalls (bei uns !!) noch nie erlebt.
.

Was ist ein EDV-GAU ?

Wenn dem "EDV Administrator" (oder dem "Verwalter der Server") ein GAU zustößt, ist das Kind meist in den Brunnen gefallen. Der "Größte Anzunehmende Unfall" (darum wird der auch "GAU" genannt) bedeutet nämlich den (etwas längeren) Totalausfall aller Systeme.

Die für alle Bewohner und Menschen richtig gefährlichen GAUs kennen wir nur von Tschernobyl und Fukushima. Auch ist mal vor ganz vielen Jahren eine amerikanische Fregatte zwei Stunden steuerlos über den Ozean "gebrettert", weil der Windows (NT 4.0) Server "gehangen" hatte. Und das Schiff war damals auch mit allen Tricks zwei sehr lange Stunden nicht zu stoppen.
.

Wie kann es zu einem GAU kommen ?

Ein Teil unserer RDE Server - Compaq Proliants DL 380 - in 2006

Die Internet-Server-EDV ist ziemlich komplex und die Server-Systeme für einen Internet-Betrieb sind "verkettet". Stürzt ein Glied in der Kette ab, so trifft es oft alle.

Was ist daran so kompliziert ?

Früher (vor 2004) hatten wir bei uns im POP Wiesbaden (POP steht für "Point of Presence") über 30 Server. Davon hatten sich 29 Server Tag und Nacht überwiegend total gelangweilt. Stürzte einer der Server mal ab, liefen die anderen weiter. Das war dennoch sehr ineffizient - und da die Leistungsfähigkeit der Server ganz enorm gesteigen war, erfand man das sogenannte "Virtualisieren".

Heute / jetzt haben wir mehrere (zur Zeit 3) echte Server mit sogenannten "Virtuellen Maschinen" (VM) drauf. In der Summe sind es zwar wieder fast 30 (aber virtuelle) Server (die nennen wir jetzt "VM"s), aber nur noch auf 3 echten HP Proliant DL385 Servern. Diese Server haben jetzt 4 oder bald 8 CPUs (Kerne), die aber jetzt mit ihrer insgesamt möglichen "Prozessor-Kraft" gemeinsam für alle "virtuellen Gäste" zur Verfügung stehen. Und wir haben natürlich mehrere gleichartige Reserve-Server im Keller betriebsbereit stehen.
.

neue RDE Server in 2011
unsere RDE Server 2014
und hier von hinten

Was ist eine "Virtuelle Maschine" (VM) ?

Das hier dient zum Verständnis für Laien ! Stellen Sie sich vor (als Beispiel), Sie sehen (oder sähen) vor sich 6 Reihen- häuser - aber alle mit oder auf nur "einem gemeinsamen" langen Keller (darunter). Von der Straße her gibts auch nur einmal für alle 6 Häuser den Strom, das Telefon, Wasser, Gas und Abwasser und dazu einen Kupfer- oder Glasfaser- Kabel- anschluß für die Kommunikation.

Im langen gemeinsamen Keller gibts (für jedes dieser obigen Häuser) den gemeinsamen Verteiler mit jeweils einem Abzweig für jedes einzelne "Haus". Und diesen gemeinsamen Keller managed / verwaltet der "Keller-Meister". Bei uns heißt der aber nicht "EDV Keller-Meister", sondern "Hypervisor". Und dieser "Hypervisor" ist sehr intelligent, denn, wenn ein solches (virtuelles) Haus einen Waserrohrbuch hat, merken es die anderen nicht. Selbst wenn eines die Häuser brennt, abbrennt oder gar explodiert, merken es die anderen nicht. (So weit jedenfalls die Theorie !!)

Im "EDV-Deutsch" bedeutet das
, alle 6 "Häuser" teilen sich diesen Keller und damit die sogenannten "Ressourcen" - Wasser, Gas, Strom usw., also bei uns in der EDV wären das die 4 oder 8 Prozessorkerne und der 32 Gigabyte große Hauptspeicher und die 8 Festplatten und die beiden Netzteile und natürlich auch den (einen oder alle 4) Netzwerk-Ports.

Der "Hypervisor" ermöglicht dem Administrator oder Programmierer weiterhin, daß er mit seiner Tastatur und dem Bildschirm (bei uns ist das die "Konsole") sowohl in den gemeinsamen Keller als auch in jedes einzelne Haus rein schaun kann.
.

Das wäre ein schlimmer Alptraum
Wasser bis oben hin
und das hier wäre der Super-GAU in einem Fernsehstudio

Und jetzt kommt der Haken an der Sache:

Nehmen wir an, der gemeinsame "Keller" säuft ab, also er läuft voller Wasser. Dann fällt der Stom für alle aus. Oder der Abfluß zur Straße ist verstopft, dann steht bei allen das Wasser im Klo bis zum Deckel. Oder einer schnipselt das Glasfaser- kabel durch, dann nämlich sind alle Häuser kommunikativ "blind" oder "tot".

Dieser gemeinsame Teil des Servers (der Keller) ist unser Linux/XEN Betriebssystem "DOM 0", das uns überhaupt erst den Betrieb dieser "virtuellen Maschinen" - manche nennen die auch "Gäste" - (oben drauf) ermöglicht. Gäbe es dort eine Sicherheitslücke, (zur Zeit - April 2014 - ist das so), dann ist die höchste Aufmerksamkeit gefordert bzw. erzwungen. Das Betriebssystem muß schnellstens korrigiert werden. Sie kennen das mit den andauernden Sicherheits-Updates bei allen Windows Versionen. Doch hier müßte oder sollte es im laufenden Betrieb erfolgen. Und das ist riskant.

Der Server-Administrator macht sich also vorher sehr intensiv schlau (über Suchmaschinen und in Linux/Suse Foren), wie er von der Version x-a (sagen wir Suse 12.1) zur Version x-b (sagen wir Suse 12.3) wechselt oder "updated". Dazu macht er Backups aller wichtigen Konfigurationen des XEN Server Basissystems und aller oben drauf sitzenden "VM"s. Natürlich werden auch die Daten alle gesichert. Und dann kann es eigentlich losgehen.

Wie solch ein Update funktioniert ...... oder nicht funktioniert ...

Installation von openSuse

Noch im laufenden Betrieb werden die betroffenen "Bestandteile" des Betriebssytems auf der Festplatte ausgetauscht und das Ganze wird am Bildschirm genau bewacht - Fehler werden aufgeschrieben. Dann wird mit Hilfe des Hypervisors ein Häuschen (also eine VM) nach der anderen "runter gefahren" und der XEN-Server neu gestartet. Das ist alles nichts Ungewöhnliches und dauert in der Regel weniger als 1 Minute. Doch aus irgend einem Grund startet jetzt dieser (veränderte) Server nicht mehr. Und jetzt wird gesucht und repariert und recherchiert, was denn da schief gelaufen sein könnte.

Die oben drauf sitzenden VMs, also die vrtuellen Server, sind natürlich alle ebenfalls offline - also tot. Damit stehen (bei uns) bestimmte Internet-Funktionen nicht mehr zur Verfügung, die aber von den restlichen Servern dringend benötigt werden.

Wichtig im Netzwerk, der DNS-Server und der DHCP-Server

Im Internet lokal bei Ihnen Zuhause oder bei uns im Server-Raum muß jedes Gerät eine weltweit einmalige Nummer haben, die sogenannte IP"-Nummer. Gäbe es IP-Nummern doppelt, knallt oder kracht es sofort. Und "alternativ" ohne Nummer geht sowieso gar nichts mehr. Will (oder muß) man von einer CD/DVD oder dem USB-Stick ein solches Betriebssystem neu aufspielen, braucht man eine "temporäre" IP-Nummer, die von einem sogenannten "DHCP" Server erfragt wird. DHCP steht für "dynamic host configuration protocol". Ist dieser Dienst (also der DHCP Server) down (also tot) und antwortet nicht, kann man nur mühsam mit viel Zeitaufwand weiter machen.
.

Diese Namen müssen in IP-Nummern konvertiert werden

Weiterhin gibt es im Internet so eine ähnliche Technik wie ein Telefonbuch. "Ich sage Dir, wen ich (an)sprechen will und Du gibst mir dessen IP-Nummer." - Also ich rufe www-google-de auf und du sagst mir, welche IP-Nummer dieser Server hat - die IP-Nummer wäre dann "uuu.xxx.yyy.zzz".

Alles ganz prima. Wenn aber dieser DNS Service, (DNS steht für "domain name system") nicht verfügbar ist, kann man die Software nicht installieren, denn auf der CD wird "download.opensuse.org/xxxxx" verlangt. Dort wohnen/lagern nämlich die ganzen Software- Module, die wir dringend benötigen.
.

Das ist also der Anfang der Verkettung ....

..... oder : wie man sich selbst austrickst. Natürlich ist dieser wichtige DNS Server redundant, also es gibt da einen "primary" und einen oder sogar mehrere "secondary" DNS-Server. Und eigentlich synchronisieren die sich gegeneinander - jedenfalls theoretisch. - So weit so gut. Es gibt aber weitere Hinkefüße:
.

Die verflixte Hardware, unsere professionellen HP Server

Der Server-Speicher - wenn ein Streifen muckt - startet er nicht mehr
ein Controller-Akku-Pack
und hier von innen

Und jetzt kommen wir zur "Überintelligenz" von Hardware. Die Compaq/HP Server-Entwickler sind wirklich gut, eigentlich überragend gut. Darum haben sie bestimmte Sperren (gegen Fehler bei Hektik und Stress) eingebaut. Nämlich: Wenn der Server mal stromlos - also ausgeschaltet - war, dann bekommt man ihn nur wieder zum Laufen, wenn wirklich alle seine "Eingeweide" - die Komponenten - korrekt und sauber funktionieren. Trotz meines Frustes, es macht Sinn !

Findet die Speicher- Test-Routine einen fehlerhaften RAM Streifen, geht es einfach nicht mehr weiter. Und der Server hat viele davon. Ist die Stützbatterie des RAID Controllers (ein NMH Akku) unbrauchbar geworden (überaltert), gehts auch da nicht weiter. Ist einer der Prozessor Stromwandler defekt, startet der Server auch nicht - gnadenlos.

Also muß man den Server aus dem Rack ausbauen und mitnehmen, denn Teile haben wir nur in der Werkstatt, und dort dann schnell reprieren. Zum Glück sind es nur 3km bis zu den sogenannten Kollokations-EDV-Kellern und wir können auch Nachts rein, super.
.

Die ersten Kunden rufen an - es ginge nichts mehr ....

Wir haben genügend Server - jedenfalls theoretisch

Es ist Freitag früh, Morgens um 8 Uhr. Jetzt kommt (Leidens-) Druck und Zeitdruck auf, weil der secondary DNS anscheinend doch nicht synchronisiert (= aktuell) war. Die Kunden können keine Mails mehr senden und/oder empfangen und ich natürlich auch nicht !!!!!! Das wird jetzt nicht nur komisch, es wird kritisch.

Also in den "secondary DNS" mal schnell rein schaun (der läuft ja noch) und die Fehler korrigieren/beseitigen. Es sind aber zu viele Fehler. Diese Lösung ist Mist. Ist aber auch kein Problem, dann eben auf dem Reserve-Server eine weitere der vorbereiteten VMs aufsetzen und den "primary DNS" dort installieren und die Sicherung einspielen, dauert in der Regel 20 Minuten. Hatte aber nicht funktioniert (diese Version der Suse Software war inzwischen nicht mehr verfügbar - Mist).

Ist dennoch immer noch kein Problem. Dann mal schnell einen unserer weiteren Reserve Sever aus dem Standby hochfahren und die DNS Software auf diesem Server installieren und das Backup rein spielen, dauert in der Regel 10 Minuten, ist vermeintlich gar kein Problem (jedenfalls theoretisch).
.

Der zweite Akt der Verkettung von (unerwarteten) Problemen ... nennt sich "iLO"

der spezielle iLO 2 Chip
unsere HP Proliant Server
die separaten iLO Anschlüsse

Die Compaq/HP Proliant Server haben seit Jahren einen sehr hilfreichen völlig separaten zusätzlichen Hilfs-Prozessor mit eigener Ethernet-Schnittstelle, über die man sich die Server-Tastatur und den Bildschirm bequem Nachhause ins Büro holen kann - immer, auch wenn der Server gerade im Standby "schläft" oder wenn er total abgestürzt wäre. Das funktioniert bei uns seit etwa 2007. Ich mußte ab 2007 nur noch seltenst runter in den EDV Keller und mal "aufs RESET-Knöfpchen drücken" oder die berühmte dämliche "F1 Taste" drücken.

Bei Compaq/HP heißt diese Funktion iLO = "integriertes Licht aus" System
, eine sehr mächtige geniale tolle Funktion. Aber vor ein paar Tagen waren alle iLOs weg. Ich war dann am 9.4. bei meinen Servern und habe sie alle "stromlos" !!!! machen müssen (also wirklich alle runterfahren und Stecker raus), damit der (vermutlich abgeschossene) iLO Prozessor wieder online war. Kann ja nach 3 Jahren mal vorkommen - aber alle 5 Server gleichzeitig - sehr merkwürdig ???
.

Nachtrag - Ursache war also doch diese Hartbeat Sicherheitslücke

. . . . aber anders als zuerst gedacht. Wir hatten auf unseren Servern diese Lücke gar nicht, doch die Schweinbacken (aus den Ländern der aufgehenden Sonne und/oder hinter dem Ural) haben Tag und Nacht alle verfügbaren IP Numern ... auf der ganzen Welt ... durch-gescannt = angebaggert, um die Passwörter zu ergattern. Und diese Scans haben dann mehrfach alle unsere iLO1 Anschlüsse abgeschossen (überlastet). Nur - diese Ursache wußte ich zu der Zeit noch nicht. Das stand erst Tage später (am 23.4.) auf der HP iLO (Service-) Webseite. - Und die muß man suchen, wenn man überhaupt weiß, daß es sie gibt.

Und so ging es weiter :

Also in dieser verflixten Nacht vom 10.4. auf den 11.4. waren schon wieder alle ILOs weg. Also wieder runter zu den Servern. Dann runter in den Keller, Stecker auch bei dem Standby-Server raus und wieder rein und gleich die aktuelle Suse 13.1 NET CD ins CD-Laufwerk einlegen.

Dann in Windeseile wieder zurück ins Büro, es war bereits 3.oo Morgens und nun "mal schnell" das Suse 13.1 XEN Grundsystem installieren und ganz schnell eine erste VM drauf und den DNS Dienst zum Laufen bringen. Die Install-CD moniert schnell, keine sogenannten Repositories (die Software Quellen) gefunden. Aha, der DHCP Dienst (Vergabe der IP-Nummern) war ja auch nicht mehr da. Nun gut, es sind ja genügend funktionierende Server da, also ganz schnell auch noch einen (Aushilfs-) DHCP Dienst aktivieren.

Der dritte Akt der Verkettung von Problemen ...

Kennen Sie das ? - Wenn unerwartet richtig dicke Steine im Weg liegen ?

Wieder Zuhause im Büro - es ist bereits 4.30 und wird gerade hell, das nächste Erwachen: Bei jeder Installation von zusätzlicher Software greift das Installationspro- gramm auf die zum System notwendigen Netzwerk-Quellen zurück. Doch die waren inzwischen vom Software-Hersteller (Novell-Suse) gekillt worden, diese Software Version würde nicht mehr unterstützt. Vor ein paar Tagen gingen die aber noch, ich habs zum Glück protokolliert. - Aber geholfen hatte es nichts. Also einen anderen laufenden Server mit einer aktuellen Suse Software ansprechen und dort auf Suse 12.3 den DHCP Server installieren und konfigurieren. Prima, hat alles geklappt.

Jetzt zurück auf die ILO Konsole des Delinquenten und hoppla, die ganzen ILOs sind ja schon wieder alle weg. Wenn man jetzt Klarheit haben möchte, was da abgeht, geht das aber nur an der echten physikalischen Konsole unten im EDV Keller. Startet man dort den Server per Netzschalter, verblüfft uns der Monitor ganz am Anfang : "ILO temporarily not available." Es ist bereits 6.oo Morgens.

Eine über Google vor Tagen gefundene Antwort zum ILO "Blackout" sagte dazu, der Server muß stromlos gemacht werden. Einen Grund für das Verhalten nennt keiner.

Nur, ich brauche diese ILO Fernsteuerung unserer Server
, alles andere ist viel zu unhandlich und mühselig. Im Serverraum sind es etwa 110 Dezibel an Lüftergeräusch, wenn die Klimanalge NICHT läuft. Wenn die läuft, ist es unerträglich und man kann fast keinen vernünftigen Gedanken mehr fassen und zuende bringen.
.

Kein Problem, hängen wir die "ILO"s hinter eine Firewall

ein Compaq Sever DL360 G1
ein Alptraum - Kernel panic

Als Firewall hatte ich vor Jahren "ipcop" schätzen gelernt und war auch sofort mit der aktuellen soeben herunter geladenen und gebrannten CD an einem weiteren Reserve-Server hier im Büro. Einen 12Port Hub hatte ich auch sofort zur Hand. Also alles kein Problem, doch dann sagt ipcop 2.11 auf einmal : Dieser Chipsatz wird nicht mehr unterstützt und das wars. Es war ein Compaq DL360 G1, eigentlich mit 800 MHz völlig ausreichend für eine Firewall. Also die uralte ipcop 1.4.2 CD (aus 2007) aus dem Archiv geholt und der Firewall Server lief nach 1 Stunde. Es ist bereits Morgens um 6.oo.

Nix wie ins Auto, auch den kleinen Switch und genügend kurze Ethernet Kabel eingepackt, ist ja alles im Lager in Mengen vorhanden. Den "ipcop" Server hatte ich bereits im Büro konfiguriert mit rotem Bereich (im Internet) und grünem Bereich (im geschützen Netzwerk). Doch heute klappt gar nichts richtig - denn ganz nebenbei - das große Schiebetor vor der Zufahrt zu unseren Server-Räumen rollt zwar auf, aber die Schranke geht nicht hoch. Nun gut, es sind nur etwa 300 Meter und mit den Servern auf dem Sackkarren ist es erträglich. Runter gehts mit dem Aufzug, der geht wenigstens noch.

Server in unseren Schrank geschoben, alle Kabel gesteckt, mit der Console direkt am Server einen Test (ping) auf das Gateway (das Türchen) nach draußen und dann noch mal den google Server irgendwo draußen geprüft, alles ok. Einen weiteren dicken schweren HP DL385 Reserve-Server hatte ich ja auch noch mitgebracht (der ist recht schwer) und auch noch angeschlossen. Und wieder nach Hause gefahren.

Der vierte Akt - Die Firewall reagiert nicht

Das Ziel ist in Sichtweite - aber steht jemand oder etwas im Weg ...

Es war wie beim Mäusemelken, vom Büro aus konnte ich auf den Firewall-Server per https nicht zugreifen. Egal, was ich versucht hatte, es ging nicht. Also Notebook eingepackt und wieder ins Auto und ab in den EDV Keller. Der Sicherheitsdienst wollte schon wissen, ob ich da vielleicht LKW-weise Server klaue?

Vom Notebook aus konnte ich die Firewall per Webinterface konfigurieren. Die großen Server hatte ich dann unten um Keller von Hand an der physikalischen Konsole hoch gefahren, sodaß ich sie mit vom Büro aus (man nennt das bei uns per SSH-Konsole) mindestens mal administrieren konnte.

Wieder Zuhause angekommen hatte ich dann einen primary DNS Server auf dem Kunden-Server einer noch freien VM installiert und die Server mit den Kunden Webs wieder am Laufen. Auf der gleichen Maschine läuft auch der secondary DNS und den habe ich dann auch erst mal synchronisert. Damit  waren wieder mehrere halbe oder ganze Stunden rum.

Der fünfte Akt - Die Fritzbox 7570 blockt viele Ports

ein Super-Teil, aber nur eigentlich

Vorab muß man wissen, daß auf solch einem Server mit nur einer IP-Nummer viele verschiedene "Dienste" ansprechbar sind, und zwar über deren "Port"-Nummern. Im Handbuch der Firewall "ipcop" steht, daß die Firewall aus Sicherheitsgründen über die weitgehend ungebräuchlichen Ports 81 und 445 administriert wird. Das wäre für uns wie ein Kanadischer Indianer Dialekt bei den Genfer Verhandlungen über die Krim mit den Russen und Chinesen. -

Also weiter: Mit meinem Notebook direkt am Switch im EDV-Keller hatte es ja funktioniert. Der sogenannte Ping auf die IP-Nummer des Servers funktioniert auch vom Büro aus, also ist der Server am Leben und eigentlich ok. Doch die Fritzbox bei uns im Büro blockt diese ungebräuchlichen IP-Ports, wie ich dann zur Kenntnis nehmen mußte, - aber ohne mich zu fragen und ohne mir auch im Fritz-Box Expertenmodus die Möglichkeit der Freischaltung bzw. Öffnung anzubieten. Also kann ich vom Büro aus diese Firewall nicht administrieren - ganz grosser Mist.

Habe dann im Netz gesucht nach Tricks, die Fritzbox für diese Ports 81 und 445 zu öffnen. Suchzeit ca. 2 Std mit 2 DIN A 4 Seiten an Tips und Tricks. Nur ist die dort genannte "ar7.cfg" Konfigurations-Datei in der Fritzbox schreibgeschützt. - auch Mist. Insgesamt waren das dann weitere 4 Stunden ohne brauchbares Ergebnis - mit einer Ausnahme - ich weiß jetzt ziemlich genau, was alles NICHT !!! funktioniert.

Dann - der Tag war inzwischen (unerfolgreich) fast rum, es wurde bereits dunkel - einen Freund (auch EDV Administrator) kontaktiert und das Problem geschildert, er würde mir gerne helfen, wenn ich ihm als Firewall einen ganz simplen Suse Server mit zwei Netzwerkkarten und mit Version 13.1 bereitstelle.
.

Daher: Ein weiterer Server muß her .......

ein DL 360 G2

Und wieder einen Server aus dem Regal geholt, einen DL 360 G2 sogar mit ILO drinnen. Meine Suse 13.1 NET CD stockt gleich am Anfang und sagt mir, das ist ja nur eine 32 Bit CPU, die mag ich nicht. Nun gut, also "mal schnell" die 32 Bit NET Variante von SUSE 13.1 herunter laden, doch ausgerechnet zu der Zeit war das alles sehr sehr lahm, und dann eine CD gebrannt. - Und auch sofort ans Installieren gegangen. Für die minimale opensuse Text-Version brauchte er an diesem Abend geschlagende 2 Stunden, sonst weniger als 15 Minuten .....

Mit allen Tricks meines Freundes konnte ich nach vielen Stunden des Nachts um 2.oo wieder auf die ILO Schnittstellen aller 5 Server zugreifen, denn der vermutlich Java-Web Client nutzt anscheinend ein JAVA Applet, das nur mit "plain" IP-Nummern arbeitet, also nicht mit angehängten Ergänzungen wie der Portnummer. Die eigentlich gängige Port-Weiterleitung (oder Umleitung) in der Firewall funktioniert somit für diese ILOs hier bei uns auch nicht - wieder eine Erfahrung mehr - Mist !
.

Der 6. Akt der Verkettung - die Rettung dieser (alten) VM

Auf dem bis zum Donnerstag funktionierenden Museumsserver, unserem "XEN5", waren die Updateversuche des XEN Basis-Systems so gründlich daneben gegangen, damals war nämlich "GRUB2" als sogenanntes Startsystem (bootloader) augewählt worden, daß ich die online Umstellung auf GRUB1 nicht mehr hinbekommen hatte. Nach den diversen Versuchen mit diversen opensuse 12.1/2/3 Varianten hatte ich das XEN Grundsystem dann komplette neu installiert, diesmal gleich mit SUSE 12.3 und dem uralten idiotensicheren GRUB (-Version1) Boot-Loader.

Die alte "VM", auf der die Museums-Webs - nach wie vor intakt - schlummerten, war nie kaputt, das ist ja zum Glück völlig getrennt - nur kannte der neue "Hypervisor" die alten VMs nicht (mehr).

Anmerkung: Daß es unter XEN (immer noch) keine Werkzeuge zum Einbinden bereits vorhandener VMs auf eigenen Platten gibt, ist ein Armutszeugnis für die XEN Entwickler. Ich hatte dann einen simplen aber arbeits- und zeitaufwendigen Trick genutzt.

Ich habe auf diesem Server auf einer freien Platte eine ganz neue VM installiert und hoch gefahren und getestet. Dann habe ich diese VM wieder gestoppt und versucht, den ganzen Server im Desktop Modus zu starten. Denn nur dann kann ich sämtliche vorhandenen Fest-Platten und Partitionen hilfsweise gemeinsam zwecks Kopiervorgang "montieren" = ansprechen.

Das Straten in diesem Desktop-Modus hatte aber leider auch nicht mehr funktioniert, auf einmal war das Start-System komplett weg. Ich musste dieses Betriebssystem dann auch nochmal installieren, damit der Boot-Loader wieder funktionierte. Und das ging natürlich auch erst wieder, als die ILOs wieder verfügbar waren.

Danach ging alles ziemlich schnell, den Server starten - aber keine VM starten, die vorhandenen alten und neuen Partitionen "mounten" und von den alten Partitionen alle Inhalte auf die neuen Partitionen komplett (und rücksichtslos) drüber kopieren, einschließlich der sogenannten "symlinks", die für die Datenbank-Funktionen essentiell sind. Dann habe ich alle Partitionen wieder demontiert und den Server im XEN Modus gestartet.

Über VNC (ein grafisches Fern-Steuerungsprogramm für die Server-Konsole) habe ich jetzt über den XEN-Admin im Hypervisor diese einzige neue VM gestartet und nach etwas bangem Warten waren die ganzen RDE- und Museums-Webs alle wieder da, wie am Freitag dem 11.4. vor dem großen Desaster. Es waren also über 6 Tage mit wenig Schlaf und viel verbratenem Gehirnschmalz.

Es gäbe noch viel mehr über die Flops und Macken von Software zu erzählen, aber Sie sehen schon an dem Zeitraum - von Donnerstag Nachmittag etwa 16.oo bis Donnerstag Mittag 14 Uhr hat sich viel ereignet.
.
Und wenn Sie alles vorbereitet haben und denken, jetzt kann wirklich nichts mehr schief gehen, dann kommt dieser Mr. Murphey und alles geht schief.

.

Fazit / Erkenntnis : Keine Updates auf/in laufenden Systemen

Das wiederum bedeutet, betreibt man eigene sogenannte Root-Server im normalen Standard- oder im virtualisierten Modus, braucht man immer einen (oder mehrere) Reserve-Server (in ferngesteuerter Dauerbereitschaft - das wäre die ILO Technik), auf dem die neuen Betriebssysteme ausprobiert werden können und dann erst werden die Inhalte der auszutauschenden virtuellen Maschinen dorthin herüber kopiert.

Also am Besten wäre es, zu Hause (kurzer Weg, kein Schlüssel) einen Spiegel Server aufzusetzen, und dort zuerst die geplanten Updates ausprobieren. So klingt die reine Theorie. Doch das alles ist dann ebenfalls sehr zeitaufwendig und die Zeit läuft einem einfach davon.

Jetzt sind die Museen also wieder geöffnet und Sie können wieder den ganzen Abend schmökern gehen:

http://www.hifimuseum.de


.

Startseite -- © 2001/2022 - Copyright by Dipl.-Ing. Gert Redlich / Germany - D-65191 Wiesbaden - Telefon-Nummer - Impressum