LVM Migration
Zeitplan:
Herrunterfahren der virtuellen Maschienen: (mit Befehl "xm shutdown")
fleischer.jp -> OK
lug-in.de -> OK
Anlegen einer lokalen Kopie der virtuellen Festplatte, liegen unter: /srv/xen/domains (Dauer: 0,5 - 1 Std)
- Abspeichern der Kopie samt Konfigurationsdatei unter: /srv/xen-backup/
- Kopieren der Konfigurationsdateien (liegen unter: /etc/xen)
Beide virtuellen Maschienen wieder starten (hoffentlich muss nichts manuell auf den Maschienen selbst gestartet werden!) -> OK (Maschienen laufen wieder)
- Backups werden auf den von Hetzner zur Verfügung gestellten Speicher kopiert (100GB sollten reichen). Habe Backups ganz Standardmäßig mittels "ftp" hochgeladen, duplicity war doch zu aufwendig (Version etc)
- Evtl kurz testen ob Images auch funktionieren (kurz starten)
Wenn das funktioniert hat kann mit dem eigentlichen Migrationsvorgang angefangen werden (Dauer: Unbestimmt)
Erst wieder alle virtuellen Maschienen herrunterfahren
- Im Recovery Modus (Strato Weboberfläche) Server neustarten
- /dev/md1 verkleinern auf 50 GB (Klärungsbedarf: Welches Tool verwenden? parted?)
- Edit: parted sollte funktionieren
Edit2: Tut es nicht! Fehlermeldung: "File system has an incompatible feature enabled" -> mich nicht wirklich damit näher beschäftigt
- Edit3: resize2fs solls richtien.
- 50 GB sollten auch ausreichen um die Backups der beiden Server noch zu beinhalten
- Restlichen Speicher (≈ 400 GB) mit LVM Partitioniere
Zwischenstand (31-07-10 18:22Uhr): /dev/md1 hat jetzt die größe von 120GB, Server laufen vorrübergehend wieder, naechster Schritt: Anlegen einer (?zweiten) Partition fuer LVM
- fdisk -l
Disk /dev/sda: 500.1 GB, 500107862016 bytes 255 heads, 63 sectors/track, 60801 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Disk identifier: 0x00000000 Device Boot Start End Blocks Id System /dev/sda1 1 262 2104514+ fd Linux raid autodetect /dev/sda2 263 60801 486279517+ fd Linux raid autodetect Disk /dev/sdb: 500.1 GB, 500107862016 bytes 255 heads, 63 sectors/track, 60801 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Disk identifier: 0x00000000 Device Boot Start End Blocks Id System /dev/sdb1 1 262 2104514+ fd Linux raid autodetect /dev/sdb2 263 60801 486279517+ fd Linux raid autodetect Disk /dev/md0: 2154 MB, 2154954752 bytes 2 heads, 4 sectors/track, 526112 cylinders Units = cylinders of 8 * 512 = 4096 bytes Disk identifier: 0x00000000 Disk /dev/md0 doesn't contain a valid partition table Disk /dev/md1: 128.8 GB, 128849018880 bytes 2 heads, 4 sectors/track, 31457280 cylinders Units = cylinders of 8 * 512 = 4096 bytes Disk identifier: 0x00000000 Disk /dev/md1 doesn't contain a valid partition table
- LVM Container anlegen // Punkte 6 - 10 Auf unbestimmte Zeit verschoben
- LVM Volumes anlegen (Jeweils einmal Disk (ca. 10GB) und Swap (256MB Fleischer 512MB Lugin) pro Server)
- Kopieren der Backups zurück auf die LVs
- Abändern der Konfigurationsdateien der Maschienen
- Virtuelle Maschienen wieder starten
- Xen Konfig ändern damit zukünftige Maschienen gleich auf LVM erstellt werden
bisher Ausgefuehrte Befehle:
resize2fs /dev/md1 100000 mdadm --grow /dev/md1
2. Anlauf:
Problem: Der RAID Verbund (md1) wurde zwar verkleinert, aber die zugrundeliegenden Partitionen auf den "realen" Festplatten (sda/sdb) wurden nicht automatisch verkleinert.
Somit wurde also kein Platz gewonnen. Unsere Zielpartitionierung sieht so aus:
- sda1: ca 4GB: swap - sda2: ca 100GB: root - sda3: rest : daten (LVM) Das gleiche nochmal mit sdb, dann zu den RAIDs: - md0: sda1,sdb1: swap - md1: sda2,sdb2: root - md2: sda3,sdb3: daten (VG, LV ...)
Das ganze soll folgendermaßen geschehen:
- Backup Anlegen (dd oder ntfsclone, mal guggn) - Raid degraden - 1ne Platte löschen - aus der gelöschten Festplatte eine ext3 Partition anlegen - Daten aus dem Backup oder dem Raid (wenn das noch geht) rüberkopieren auf die ext3 Partition - die andere (nicht ext3) Festplatte löschen und Partitionstabelle wie benötigt anlegen (Raids usw.), aber immernoch degraded - Daten wieder rüberkopieren auf die gerade erstellte Partition - die ext3 Platte wieder löschen und ins RAID mitaufnehmen, synchronisieren
Test 16-08-2010:
Ausgangslage: 40GB hda1, 40GB hdb1, 20GB /dev/md1 (aus hda1,hdb1) eben wie bei unserem Server
Mit Live CD
- Raid stoppen: mdadm --stop /dev/md1
- Raid mit einer Platte starten: mdadm --run /dev/md1
- Raid laeuft, "cat /proc/mdstat" zeigt: md1 : active raid1 hda1[0] 20971520 blocks super 1.0 [2/1] [U_]
- aendern des Dateisystemtyps von hdb1 mit cfdisk auf 83 (Linux, denke ext3): cfdisk /dev/hdb
- /dev/hdb1 verkleinern auf 20GB: resize2fs /dev/hdb1 20000 (habs mit Gparted gemacht müsste aber so auch gehen)
- aender des Dateisystemtyps von hdb1 wieder auf "Raid Autodetect" (FD)
- loeschen der Partition von hda1: cfdisk /dev/hda
- erstellen des Raids mit /dev/hdb1: mdadm --create /dev/md1 --level=1 --raid-devices=2 missing /dev/hdb
- kopieren der Partitionstabelle von hdb nach hda: sfdisk -d /dev/hdb | sfdisk /dev/hda
- hinzufuegen von /dev/hda1 zu /dev/md1: mdadm --add /dev/md1 /dev/hda1
- nochmal e2fsck resize2fs und nochmal e2fsck
- Grub muss wieder installiert werden !!!: http://wiki.ubuntuusers.de/GRUB
Ausfuehrung 22/23-08-2010:
Im Rescue (64Bit) Modus:
- Raid stoppen: mdadm --stop /dev/md1
- Raid mit einer Platte starten: mdadm --create /dev/md1 /dev/sdb2 missing (missing steht dafür dass sda fehlt)
- Raid laeuft, "cat /proc/mdstat" zeigt: md1 : active raid1 sdb2[0] ... blocks super 1.0 [2/1] [U_]
- aendern des Dateisystemtyps von sda2 mit cfdisk auf 83 (Linux, denke ext3): cfdisk /dev/sda
- /dev/sda2 verkleinern auf 100GB: resize2fs /dev/hdb1 95G (verkleinert nur das Dateisystem !!! Erst mal nur 95GB kann nachher einfach angepasst werden)
- /dev/sda2 verkleinern auf 100GB: umwandeln in ext2 damit mit "parted" die Partition verkleinert werden kann: tune2fs -O ^has_journal /dev/sda2
bei mir hat dann parted immer noch gemeckert, nach ein paarmal e2fsck und entfernen weiterer "Filesystem features" gings endlich
- /dev/sda2 verkleinern auf 100GB: "parted" -> "resize 2 Startgroesse Endgroesse" (Start/Endgroesse muss in MB angegeben werden)
- /dev/sda2 verkleinern auf 100GB: wieder hinzufuegen von "has_journal" (also wieder ext3 machen): tune2fs -O has_journal /dev/sdb2
- aender des Dateisystemtyps von sda2 wieder auf "Raid Autodetect" (FD)
- Stoppen von md1: mdadm --stop /dev/md1 (das war ja nur zur sicherheit jetzt wird das Raid mit dem verkleinerten sda2 aufgesetzt)
- Raid mit sda2 starten: mdadm --create /dev/md1 /dev/sda2 missing
- Test ob mounten funktioniert: mount /dev/md1 /mnt/md1 -> OK, und es sind sogar noch alle Dateien da
- loeschen der Partition von sdb2: cfdisk /dev/hda
- kopieren der Partitionstabelle von sda nach sdb: sfdisk -d /dev/sda | sfdisk /dev/sdb
- hinzufuegen von /dev/sdb2 zu /dev/md1: mdadm --add /dev/md1 /dev/sdb2
- resync abwarten ... (aktueller Stand abfragen mit: cat /proc/mdstat)
- nochmal e2fsck, resize2fs, e2fsck
- mal rebooten: komm nicht mehr drauf... Recovery Modus + "Strg + Alt +Entf" von Hetzner Menü senden
- Bootloader nochmal ueber sda buegeln: http://wiki.ubuntuusers.de/GRUB (siehe: Bootloader wiederherstellen: Methode 3) -> bootet immer noch nich
- viel herumprobieren: Kontrollieren von /etc/mdadm/mdadm.conf (braucht man eigentlich gar nicht mehr), /etc/fstab, /boot/grub/menu.lst -> bringt alles nix
- Die Loesung stand wie so oft im Ubuntuusers Wiki, im rescue Modus folgedes machen:
sudo mount /dev/md0 /mnt sudo mount -o bind /dev /mnt/dev sudo mount -t proc /proc /mnt/proc sudo chroot /mnt /bin/bash sudo update-initramfs -u -k all
Endspurt:
- Anlegen von PV: pvcreate /dev/md2
- Anlegen von VG: vgcreate volgr1 /dev/md2
- Anlegen von LV fuer fleischer.jp: "lvcreate -L 11G -n fleischer.jp-disk volgr1" und "lvcreate -L 2G -n fleischer.jp-swap volgr1"(11G nur zur sicherheit)
- Kopieren der Daten der Image auf das LVM: dd if=/srv/xen/domains/fleischer.jp/disk.img of=/dev/volgr1/fleischer.jp-disk (Swap kann man auch neu anlegen
)
- e2fsck -f /dev/volgr1/fleischer.jp
- Filesystem vergrößern damit es die 11G auch nutzt: resize2fs /dev/volgr1/fleischer.jp
- aendern der /etc/xen-tools/xen-tools.cfg: Zeile 55 auskommentieren: lvm = volgr1 (damit werden mit xen-tools erstellte Domains automatisch als Logical Volume in der Volume Group "volgr1" erstellt)