[linux-support] Migration von LVM Volumes auf DRBD Devices

[Gaudenz Steinlin]

Hallo Markus

Markus Wernig <wernigm at lugbe.ch> writes:

> Hallo Attila
>
> On 02/04/2015 01:42 AM, Vagi Attila wrote:
>
>> ja, theoretisch könnte ich es mir vorstellen, finde aber schwer zu
>> realisieren.
>
> OK, ich habe das jetzt ausprobiert, und in der Tat geht das, wenn man
> das Zielvolume etwas grösser macht als das Quellvolume. Wenn beide
> gleich gross sind, gibt es beim dd ein "No space left on device".
> Der für die Metatdaten benötigte Platz ist in der Tat recht gering (ob
> die errechneten 1.25 MB für 8 GiB Daten wirklich reichen, muss ich noch
> verifizieren).

Ja das ist logisch, da dein DRBD Volume ja etwas kleiner ist als dein
reines LVM Volume, wenn du das LV, welches hinter dem DRBD Volume steht
genau gleich gross machst wie das Ausgangsvolume.

Wenn du das LV für DRBD etwas grösser machst (mind. so viel wie die
Metadaten brauchen), dann wird es gehen. Du musst einfach darauf achten,
dass du als Ziel nicht direkt das LV, welches von DRBD verwendet wird,
sondern das Block Device der DRBD Resource verwendest. So lange du nicht
direkt auf des LV schreibst, kannst du die Metadaten nicht überschreiben.

Falls du dir dd sparen willst geht sogar folgendes (habe ich schon
gemacht):
1. bestehendes LV mit lvextend etwas vergrössern.
2. Dieses LV nun als Backing Store für die DRBD Resource benutzen.
3. Auf dem 2. Host ein gleich grosses LV anlegen und auch DRBD
   konfigurieren.
4. Wenn du nun die Resource aktivierst, wird sie
   Inconsistent/Inconsistent sein.
5. WICHTIG: Beim initialen synchronisieren der DRBD Resource die
   korrekte Quelle auswählen. Sonst werden deine schönen Daten mit
   Nullen überschrieben. Danach ist deine Resource breit.

>> Was ich schon gesehen habe und schön funktioniert hat, dass man LVM
>> Volumes erstellt, so kann man auf einem grösseren physikalischen Storage
>> ein LV für die Metadata und ein LV für die Daten selber anlegen. 
>
> Hm, ich finde da den Ansatz mit dem größeren Zielvolume eigentlich
> einfacher. Weil mit dem Zwei-Volume-Ansatz können sowohl Daten- als auch
> Metadaten-Volume unabhängig voneinander kaputt gehen, wodurch sich
> zumindest rechnerisch die Verfügbarkeit halbiert. Und ich muss doppelt
> so viele Devices verwalten.

Wobei wohl typischerweise sowieso alles auf der gleichen physischen Disk
ist. Mir scheint der Ansatz mit externen Metadaten aber auch unnötig
kompliziert.

Hier noch ein Link zum libvirt hook, den ich brauche um sicherzustellen,
dass jeweils nur von einem Host auf ein Volume zugegriffen wird und um
live Migrationen zu ermöglichen. Das Skript muss nach
/etc/libvirt/hooks/qemu.

http://git.cirrax.com/?p=puppet-modules/libvirt.git;a=blob;f=files/hooks/qemu/drbd;h=ac7d0b15e87f56a93b13bb6a40d0c312fba11f07;hb=HEAD;js=1

Gruss Gaudenz
-------------- n�chster Teil --------------
Ein Dateianhang mit Bin�rdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigr��e  : 810 bytes
Beschreibung: nicht verf�gbar
URL         : <http://maillists.lugbe.ch/pipermail/linux-support/attachments/20150205/febc1c6f/attachment.sig>