Sie sind hier : Homepage →  Linux (6) Ein Webtropia root-Server→  Der Migrationsfahrplan Feb 2017

Zusammenfassung der Erkenntnisse / Erfahrung

Fangen wir nochmal an, die (teils sehr ernüchternden) Erfahrungen der letzen Wochen zusammen zu fassen:

  1. Ich verwalte seit über 8 Jahren mehrere virtualisierte HP-Server mit opensue 12.3 XEN und 8 opensue virtuellen Maschinen (Produktiv VMs) sowie 2 Reserve VMs.

  2. Alle 8 VMs sollen auf den neuen "dedicated root-Server" geclont werden, auch wieder unter opensue.

  3. Erkenntnis : opensue 42.1 (Hetzner) als DOM 0 bzw. Hypervisor zickt und ist instabil, also unbrauchbar. - opensue 13.2 dagegen ist stabil und wird von Webtropia unterstützt.

  4. Aufgrund der Erfahrung gibt es nur noch die Vorwärts-Strategie. Also einen Muster-Server hier im EDV-Labor in Wiesbaden aufsetzen und diese Konfiguration auf den Ziel-Server in Düsseldorf übertragen.

.

Der opensuse Musterserver mit 2 SATA Platten

Damit alles so flüssig wie möglich funktioniert, sollte der Musterserver mindestens den gleichen Netzwerk-Chip haben wie der Zielserver.

Auch die 4 Partitionen sollten jetzt schon wie auf dem Zielserver eingerichtet werden.

Wenn der Musterserver läuft (das ist hier jetzt der Fall), muß diese Konfiguration (Partitionierung und XEN-Boot-System) auf den Zielserver übertragen werden.
.

Neu : Ich muß mich in ein "gmrl" einarbeiten.

Auf dem Wbtropia Zielserver hatte ich zwar das "default" Opensuse 13.2 System per Klick installiert bekommen, jedoch in einer völlig verqueren Konzeption, die so für einen Produktionsbetrieb überhaupt nicht brauchbar ist. Bis ich kapiert hatte, daß dort RAID0 konfiguriert war, hatte es bereits etwas gedauert. Auf die Idee, daß das angezeigte RAID auch ein RAID0 sein könnte, kam ich im Traum nicht.
.
Also alles killen und neu anfangen. Als Rescue Betriebssystem wird dort ein "grml" (??? gestartet. Davon hatte ich noch nie etwas gehört und war entsprechend skeptisch. Es sei ein debian Derivat oder so ähnlich.

Was ist "grml" - gesprochen "grummel" ??

In den letzen 10 Jahren hatten wir uns hier in Wiesbaden unsere (suse) Rescue CDs selbst zusammen gestellt und immer mit den Tools ergänzt, die wir gebraucht hatten. Bei Webtropia wurde mir nun dieses "grml"-debian vorgesetzt und ich mußte lernen, erst mal wieder zu lernen = kein YAST mehr. Der Entwickler von grml hat sich einige Gedanken gemacht, wie man an eine zu reparierende Platte herangeht und welche Tools und Module man braucht -- und wie man ein Standard-System vorkonfiguriert.

Bespiel: Es soll die vorhandenen Platten-Partitionen (aller Art) "erkennen" aber nicht mounten. Das Suse Rescue mountet auch gleich, das Unmounten ist aber Mehrarbeit.

Ich brauche von Anfang an den "ssh-server" sowie den "tightvncserver" und "gparted". Die ganzen Commandline Werkzeuge brauche ich sowieso, dazu den "midnight commander" und den Editor "joe". Der "Filezilla" wäre super, den kann man aber nachinstallieren.

Das hatte ich auf dem "Webtropia grml" rescue alles bereits ausprobiert und auch dokumentiert.
.

grml installieren: erst auf CD, dann auf den USB Stick

Sinnvollerweise arbeite ich natürlich auch hier auf dem Musterserver mit grml, dann sind die Abläufe auf demMusterserver und auf dem Zielserver nahezu identisch. Und sinnvollerweise arbeite auch auch auf dem Musterserver per putty und mit dem VNC Viewer. Denn dann kann ich per Tastendruck Screenshots zur Dokumentation erstellen.

Der USB Stick mit "grml" wäre dann hilfreich, wenn ich im laufenden Betrieb weitere Programme (nach-) installiere, die ja nur im RAM gehalten würden und danach (reboot) wieder weg sind. Es gibt dort den persistent Modus, der aber (bei mir) im Moment noch nicht funktioniert.
.

Einen Notebook mit der grml "CD" booten

Das aktuelle 64 Bit grml ISO Image (grml64-full_2014.11.iso) hat etwa 470 MB Größe und läßt sich mit NERO Express bequem auf eine CD brennen. Damit starte ich einen Notebook mit USB Ports und partitioniere den Stick mit dem gparted über VNC. Damit alles Standard bleibt, wird der 8GB Stick in 4GB FAT16 und 4GB ext3 unterteilt - (das sollte später der "persistent" Bereich werden).
.

Dateien mit wget abholen .... auspacken und installieren

Die grml CD starten mit Option german und ohne grafik.

Dann erst mal ein password für root erstellen, sonst geht nichts
dann
ssh starten:
/etc/init.d/ssh start

gehe nach /opt

den usb installer (wenige Kilobyte) abholen
wget grml.org/grml2usb/grml2usb.tgz

abholen, mit dem "mc" auspacken und installieren

die grml iso datei (470MB) holen
wget download.grml.org/grml64-full_2014.11.iso

und das hatte dann funktioniert

# grml2usb --bootloader-only --fat16 --force --skip-bootflag grml64-full_2014.11.iso /dev/sdb1 

Der USB Stick ist jetzt bootfähig gefüllt.
.

Den Musterserver mit dem USB Stick booten

Auch hier als Option nur "d" für deutsche Tastatus eingeben und x für X11 Grafik Modus wählen. Sodann mit der rechten Taste eine Console öffnen.

Zu Allererst mit "ifconfig" die aktuellen IP Nummer (DHCP) abfragen. - Dann mit "su -" zum User root wechseln und vorsorglich ein root Passwort vergeben.

Als Nächstes den tightvncserver installieren mit
aptitude update
und
aptitude install tightvncserver

Das geht recht schnell, ist nicht sehr groß.

Dann "tightvncserver" aufrufen und das "vnc-" Passwort vergeben. Der vnc-Server läuft ab dann (jedenfalls unter Debian) im Hintergrund.
.

Warum mache ich das so ?

Auf dem Musterserver liste ich jetzt offline mit dem hiesigen grml-debian die Eigenschaften der unter opensuse angelegten 8 Partitonen (es sind nur 4 aber jeweils gespiegelt) auf meinen beiden SATA-Platten und dokumentiere das. Die Partitionen sind nicht gemounted. Über den VNC-Viewer lade ich den gparted und erstelle Screenshots.

Auf dem Zielserver lege ich (ebenfalls) mit dem dortigen grml-debian über den VNC-Viewer und gparted diese 8 Partitonen genau spiegelbildlich an und dokumentiere das ebenfalls.

Die 8 neuen Partitionen auf diesen beiden SATA-Platten sda und sdb müssen jetzt mit den 8 Partitionen auf dem Musterserver - UUID usw. absolut exakt übereinstimmen. Mit diversen Command-Line-Tools prüfe ich das nochmals.

Die Befehlszeilen kommen noch ....

Bislang gehe ich davon aus, daß die ganzen UUIDs auf den jeweiligen physikalischen Platten für den späteren Boot-Vorgang keine Rolle spielen (sondern nur die UUIDs der gespiegelten Raid1 Partitionen).

Auf dem Musterserver ist ja opensuse 13.2 bereits bootfähig installiert und es funktioniert auch. Und noch ist auf dem Zielserver kein RAID1 eingerichtet.
.

Den Master-Boot-Record übertragen

Der Masterboot-Record des Zielservers (auf beiden Platten) muß ja genau der gleiche sein wie der des Musterservers. Den muß ich also hier von einer der beiden Platten auslesen und !! auf beide physiklischen Platten des Zielservers übertragen.
.
Der MBR besteht aus 446 + 64 + 2 = 512 Byte.
(Wobei 446 bytes = Bootstrap, 64 bytes = Partition table und 2 bytes = Signature bedeuten.)
Ich brauche also nur die 446 Byte Bootstrap Informationen.

also sichern des (gesamten) MBR auf dem Musterserver mit
# dd if=/dev/sda of=/tmp/mbrquell-platte.bak bs=512 count=1

jetzt übertragen der Datei auf den Zielserver in /tmp/

und rücksichern (nur des Bootstrap Teils) auf beide Platten des bereits partitionierten Zielservers
# dd if=/tmp/mbrquell-platte.bak of=/dev/sda bs=446 count=1
und
# dd if=/tmp/mbrquell-platte.bak of=/dev/sdb bs=446 count=1
.

Die ersten drei Partitonen jetzt als RAID1 konfigurieren

Die Partition 1 (swap) ist unwichtig. Aber die Inhalte von Part. 2 (das ist /boot) und von Part. 3 (das ist /) werden auf dem Musterserver (offline !!!) gepackt und sollen auf den Zielserver übertragen werden.

Dazu müssen aber auf dem Zielserver zuerst die RAID1 Partitionen eingerichtet und aktiviert werden und mit den exakt gleichen UUIDs gelabelt werden.

Wichtig ist auch hier, daß man das 1:1 vergleicht und zwar akribisch vergleicht.
.

Zurück zur Startseite ----- © 2009 / 2016 - Copyright by Dipl. Ing. Gert Redlich - Zum Telefon - - - - NEU : Zum Flohmarkt