lug-in.de
Linux User Group Ingolstadt e.V.
Startseite
Der Verein
Technikecke
Mailingliste
Kalender
Impressum

Login

LVM Migration

Zeitplan:

  1. Herrunterfahren der virtuellen Maschienen: (mit Befehl "xm shutdown")

    1. fleischer.jp -> OK

    2. lug-in.de -> OK

  2. Anlegen einer lokalen Kopie der virtuellen Festplatte, liegen unter: /srv/xen/domains (Dauer: 0,5 - 1 Std)

    1. Abspeichern der Kopie samt Konfigurationsdatei unter: /srv/xen-backup/
  3. Kopieren der Konfigurationsdateien (liegen unter: /etc/xen)
  4. Beide virtuellen Maschienen wieder starten (hoffentlich muss nichts manuell auf den Maschienen selbst gestartet werden!) -> OK (Maschienen laufen wieder)

  5. 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)
  6. Evtl kurz testen ob Images auch funktionieren (kurz starten)
  7. Wenn das funktioniert hat kann mit dem eigentlichen Migrationsvorgang angefangen werden (Dauer: Unbestimmt)

    1. Erst wieder alle virtuellen Maschienen herrunterfahren

    2. Im Recovery Modus (Strato Weboberfläche) Server neustarten
    3. /dev/md1 verkleinern auf 50 GB (Klärungsbedarf: Welches Tool verwenden? parted?)
      1. Edit: parted sollte funktionieren
      2. Edit2: Tut es nicht! Fehlermeldung: "File system has an incompatible feature enabled" -> mich nicht wirklich damit näher beschäftigt

      3. Edit3: resize2fs solls richtien.
    4. 50 GB sollten auch ausreichen um die Backups der beiden Server noch zu beinhalten
    5. Restlichen Speicher (≈ 400 GB) mit LVM Partitioniere
      1. 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

      2. 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
    6. LVM Container anlegen // Punkte 6 - 10 Auf unbestimmte Zeit verschoben
    7. LVM Volumes anlegen (Jeweils einmal Disk (ca. 10GB) und Swap (256MB Fleischer 512MB Lugin) pro Server)
    8. Kopieren der Backups zurück auf die LVs
    9. Abändern der Konfigurationsdateien der Maschienen
    10. Virtuelle Maschienen wieder starten
    11. 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)