Skip to content

LVM regelt verschärft

Ich glaube, ich erwähnte es schon, aber LVM ist einfach cool. Ich bereue keinen Meter, schon seit 2002 LVM grundsätzlich auf jedem Linux-System das ich installiere einzusetzen. Damals war ich hauptsächlich scharf darauf, Festplattenpartitionen mit "sprechenden" Namen zu haben, die obendrein auch noch unabhängig davon sind, mit welcher Schnittstelle eine Platte an das System angebunden ist.

Aber auch Snapshots und die Möglichkeit zum Resize haben mir inzwischen schon öfter den Arsch gerettetdie Arbeit erleichtert.

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.

Trackbacks

No Trackbacks

Comments

Display comments as Linear | Threaded

UWP on :

Coole Wurst! Das mit dem pvmove kannte ich noch nicht, ich denke, da dürften die nächsten Plattenverschiebungen deutlich entspannter ablaufen. Bisher mache ich immer sowas wie: dump im laufenden Betrieb auf andere Disk. Dann ständige rsyncs hinterher, was total nervig ist bei 2 Mio. Dateien, da braucht rsync ewig. Wenn die Unterschiede dann geringer werden, schalte ich die User und Prozesse runter und mache den letzten rsync. Das bedeutet meistens eine Downtime von gut 2-4 Stunden (jedenfalls bei 2 TB auf einem System, auf dem zwischen 1000 und 2000 Leute gleichzeitig ihre Mail lesen). Deine Idee mit dem pvmove dürfte die Zeit auf 2 x booten verkürzen, also ungefähr 5 Minuten. Dankedankedanke!

Mermgfurt,

Udo

P.S.: Wobei ich zugegebenermaßen lvm bei unserer Mail-Partition wegen leichter Erweiterbarkeit sowieso schon hatte. Aber man lernt ja täglich dazu, so macht es auch in anderen Bereichen Sinn...

Marc 'Zugschlus' Haber on :

Zwei Tipps noch:

(1) Beim Anlegen der LVs am besten noch ordentlich Platz in der VG lassen, dann snapshottet es sich besser, und snapshots kann man immer mal brauchen

(2) vor pvmove-im-laufenden-Betrieb-Stunts sicherheitshalber ein aktuelles Backup in der Hinterhand haben

Django on :

Und was passiert bei Bad-Blocks? Die scheinen ja inzwischen immer häufiger aufzutreten.

Florian Laws on :

Gute Frage. Wahrscheinlich gibt es entweder einen I/O-Error und pvmove bricht ab (dann hat man das Volume teils auf der alten und teils auf der neuen Platte, pvmove ist restartable), oder das System merkt es nicht, und die Daten in dem Block haben leider Pech gehabt.

Prinzipiell könnten pvmove bzw. LVM auch auf Badblocks prüfen, indem der Block nach dem Schreiben nochmal gelesen und mit seinem Original auf der alten Platte verglichen wird.

pvmove arbeitet intern nämlich so: das neue Physical Volume wird (in Stücken) als zweite Hälfte eines RAID-1-Spiegels konfiguriert, und der Spiegel wird dann vom alten PV synchronisiert. Wenn die Spiegel-Synchronisation fertig ist, wird die Spiegelhälfte auf der alten PV abgehängt. Davor könnte man natürlich nochmal einen Checksummenvergleich auf beiden Hälften machen.

Was im Bezug auf Bad Blocks von LVM auch fehlt, ist ein Programm analog badblocks(8), das fehlerhafte Sektoren auf einem PVs für die Verwendung sperrt. Und ein Diskscrubber, der sie erstmal findet, natürlich online, bitte.

Bis dahin hilft vielleicht dieses Howto, das immerhin erklärt, wie man von der physischen Blocknummer die z.B. SMART ins Syslog schreibt, zur logischen Blocknummer auf dem betroffenen LVM-Volume kommt: http://smartmontools.sourceforge.net/BadBlockHowTo.txt

Aber grundsätzlich stellt sich ja bei Bad Blocks eh die Frage zwischen radikal Platte rauswerfen beim ersten Mucks oder hoffen auf die Wirksamkeit der Wunderdinge, die Sun so anpreist... Von Linux habe ich da allerdings noch nicht viel gehört.

Add Comment

Markdown format allowed
Enclosing asterisks marks text as bold (*word*), underscore are made via _word_.
Standard emoticons like :-) and ;-) are converted to images.
E-Mail addresses will not be displayed and will only be used for E-Mail notifications.
Form options