LVM regelt verschärft

Im Zuge meiner aktuellen Hardwarebasteleien hatte ich die Aufgabe, ein System von einer SATA-Platte auf eine PATA-Platte umziehen zu lassen. Das hätte man zwar natürlich auch mit einer tar | tar-Pipe oder rsync machen können, aber mit LVM ist es doch viel cooler (und man kann kein --numeric-owner und/oder --numeric-ids vergessen, was mein Lieblingsfehler ist).

Man fahre das System herunter, um die Zielplatte dazuzuhängen. Dann partitioniere man die Zielplatte, lege eine PV an und erweitere die VG des existierenden Systems um die neue PV (vgextend vg0 /dev/hdc1, zum Beispiel). Als nächstes weise man das System an, alle Daten von der “alten” PV herunterzuschieben (im Falle, dass die alte PV /dev/sda1 ist, zum Beispiel mit pvmove /dev/sda1). Das dauert eine Weile, also möchte man den pvmove-Aufruf eventuell mit --interval 30 garnieren, um alle 30 Sekunden darüber informiert zu werden, wie weit der Plattenshredder inzwischen fortgeschritten ist.

Während der gesamten Aktion kann das System, dessen Installation oder dessen Daten da gerade verschoben werden, im vollständigen Produktivbetrieb laufen, was natürlich für einen Server mit wichtigen Aufgaben sehr, sehr praktisch ist. Hat man Hardware, mit der Hotplugging von Festplatten möglich ist, geht die Migration auf eine neue Platte komplett ohne Betriebsunterbrechung. Natürlich bleiben Dateiattribute und sogar die Inode-Nummern unverändert, was bei einer hostbasierten intrusion detection die Menge der nach der Migration erzeugten Fehlalarme deutlich übersichtlicher macht.

Ist das pvmove abgeschlossen, entfernt man die “gehende” PV aus der Volume Group (vgreduce vg0 /dev/sda1, das ist wichtig. Unvollständige VGs mag der LVM auch dann nicht, wenn dort keine Daten mehr drauf liegen) und kann dann die alte Platte aus dem System entfernen.

Wo so viel Licht ist, ist natürlich auch Schatten: pvmove heißt pvmove und nicht pvcopy. Das bedeutet insbesondere, dass man die Daten wieder zurückverschieben muss, wenn sich herausstellt, dass man die neue Platte verkehrt partitioniert hat. Beim konventionellen Arbeiten würde man einfach die Kopieraktion wiederholen und hätte die Daten nur zweimal und nicht dreimal über die Schnittstelle geschlenzt.

Außerdem tun sich Linuxe etwas schwer mit dem Booten von LVM-basierten Systemen. Ich hatte jahrelang eine ausgeprägte initrd-Phobie, was mich dazu zwingt, das root-Filesystem mit typischerweise 200 MB Größe außerhalb des LVM liegen zu haben. Damit ist der Traum, auf hotplug-fähiger Hardware zum Plattenwechsel komplett ohne Downtime auszukommen, ausgeträumt, denn mindestens zum klassischen Umkopieren des Root-FS muss gebootet werden, außerdem macht man diese Kopieraktion am besten aus einem Rettungssystem. Aber da ich zeitlebens noch kein System mit hotplugfähigen Platten (außer USB, aber da hab ich das auch noch nie probiert) in den Fingern hatte kann ich damit auch leben.

Wenn man mutig ist und mit einer initrd booten kann, braucht man nur /boot außerhalb des LVM. Dann geht die Migration komplett ohne Downtime, denn /boot aushängen und kopieren kann man auch im laufenden Produktivsystem. Allerdings will man vermutlich dann auch mal booten, um zu gucken, ob man auch alles richtig gemacht hat - im Zweifelsfall ist sonst der nächste Boot in einer Streßsituation und man darf dann auch noch mit den Fehlern kämpfen, die man beim Umkopieren gemacht hat.

Grub2 kann dem Vernehmen nach auch aus einem LVM booten; sollte Grub2 wider erwarten in diesem Leben nochmal benutzbar werden, kann man sich auch das außerhalb des LVM liegende /boot sparen. Aber ich fürchte, bis dahin wird noch eine Menge Wasser durch die Neckarschleusen fließen.

Noch zwei Worte zum Thema initrd-Phobie: Die war weitgehend unbegründet. Debians initrd-Tools sind in Form von initramfs-tools inzwischen so flexibel und ausgereift, dass der Spaß erstaunlich schmerzarm abläuft und man im Normalbetrieb keine Fußangeln vorfindet. Das funktioniert einfach. Aber bis ich meine Standard-Server-Installation auf initrd umstelle, muss noch etwas Zeit vergehen.