Opensource XEN+DRBD LVM felett snapshot

Virtualizáció

Van két gépem, amin az opensource xen (xen.org) megy. A virtuális gépek diszkje 1-1 logical volume tetején levő DRBD volume. Tehát a DRBD alatti diszk az LV. A metadata internal.
Szeretnék rizikós konfigurációs változtatás előtt snapshotot csinálni és azt visszaállítani ha kell.
A gond az, hogyha snapshotot csinálok az LV-ről és azt a merge-el vissza akarom állítani az eredeti állapotára akkor nyöszörög, hogy használt az LV - és valóban a usage count kettő.
Ha erőszakoskodok és (lvchange -ay) aktiválom akkor elkezdi a merge műveletet (szerintem ez hiba, mert előtte is aktív volt), de megsérül minden és a VM nem is bootol.

Ha kiszedem a DRBD alól (dikless lesz a kapcsolat), hogy ne legyen használva akkor a visszaállítás után a secondary oldalról visszaszinkronizálódik minden.

Az is gáz lehet, hogy a metadataokat is megpiszkálhatja a viszaállítás és akkor a DRBD szét fog esni - eddig még nem jutottam el, de lehetséges.

Van valakinek épkézláb ötlete?

  • 2140 megtekintés

( bitraider01 | 2014. 11. 24., h – 12:39 )

Szia!

Mi az a kritikus változtatás? XEN oldal? VM? vagy VM-en belül lvm módosítás?

Egyik nodeon legyen a drbd forceolva slave üzemmódban, és állítsd le a deamont. Csináld meg a snapshotot és a másik nodeon indítsd el a drbd-t.

A snapshot is a drbd-s lemezen van? Van elég hely?

( wpeople v | 2014. 11. 24., h – 12:42 )

lehet, h én értem félre, de
van 2 géped, a két gépen LV, ezen egy DRBD és ezen fut a VM.

Ha a DRBD-ről csinálsz egy snapshot-ot backup néven, akkor az megvan.
Amennyiben erről vissza akarsz állni, akkor felteszem mindent leállítasz, a DRBD-t is, és úgy futtatod a merge-t, ugye?
Ha nem így teszel, akkor joggal panaszkodik, hiszen DRBD aktívan használja a LV-t.

Akkor is borult ha le volt állítva.
Valószínű azért, mert a metadata internal és a snapshot visszaállítás azt is visszaállította és így kiesett a szinkronból a két oldal metainformációja.
Ha most csinálnám a metadata nem a diszkre kerülne, hanem egy kis ssd-re, így a metainfo írása nem is lassítaná a drbd-t. Az persze kérdés, hogy az ssd hogyan mírmá a gyakorlatilag állandó írogatást.

Teljesen jól érted.
A VM le van állítva, de a DRBD process fogja az LV-t, mert szinkronizál. Az egész bulit a primary oldalon csináltam. Ha nem akarom, hogy használt legyen akkor kiveszem a DRBD alól - ekkor a usage conunter nulla lesz, de a merge után az eddigi masodlagosról visszaszinkronizálódott valami és borult a bili.

( dap | 2014. 11. 24., h – 13:35 )

Nem ízleltem sokáig a posztod, de hirtelen az jutott eszembe, hogy az LV amit snapshot-olsz ofkoz a DRBD _fölött_ legyen. Ettől persze alatta is lehet egy, de ne azt snapshot-old.

Nekem is ez volt az ötletem. Ha van a DRBD alatt és fölött is LVM és a felsőről csinálom a snapshotot akkor a visszaállítást az alatta levő DRBD szépen szinkronizálná. Ha a mostani eszemmel csinálnám így csinálnám, de az a gép amit piszkálni kellene nem így van installálva az csak LVM tetjén DRBD és az van odaadva virtuális diszknek. Ráadásul nincs rajta fájlrendszer, hanem a nyers diszk amit a DRBD ad.

( Zs | 2014. 11. 24., h – 17:05 )

Szerintem (is) rossz az alapállás. A drbd egy spéci raid mirror: a két diszk két külön gépen van.
Na de logikailag milyen sorrendet érdemes követni? Előbb LVM, majd a logikai köte(ke)t tükrözni - vagy előbb a tükör és utána az LVM? Szerintem ez utóbbi a logikusabb - illetve az LVM-nek is van hálózati változata (tán clvm, de nem ugrik be a betűszava).

( Elbandi v | 2014. 11. 24., h – 17:40 )

alakitsd at a felepitest valami ilyenre: 


              |---------------------|
              | vm1   | vm2   | ... |
              | (LV1) | (LV2) |     |
              |---------------------|
              |         VG          |
              |---------------------|
              |         PV          |
|-------------|---------------------|
| swap | root |        DRBD         |
|------|------|---------------------|
| sda1 | sda2 |        sda3         |
|-----------------------------------|
|            disk                   |
|-----------------------------------|

ezutan eleg csak az LV1-et snapshotolnod, konnyen vissza tudsz allni az eredeti allapotra (akar a masik gepen is, mivel a "snapshot regi allapota" is atkerul a masik gepre a drbd miatt)

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Nagyjából erre gondoltam én is csak sajnos most át kell alakítani a már meglevőt.
Annyiban finomítanám a rendszert, hogy az egyes DRBD kapcsolatokat érdemesebb külön LV-re tenni, mert így egymástól függetlenül migrálhatók a vm-ek két gép között.
(Köszönöm a szuper ascii rajzot - itt a módosított)

Eddig ez volt: 


|---------------------|
|  vm1  | vm2   | ... |
|---------------------|
| DRBD1 | DRBD2 | ... |
|---------------------|
|  LV1  |  LV2  | ... |
|---------------------|
|         VG          |
|---------------------|
|         PV          |
|---------------------|
|        sda3         |
|---------------------|
|       RAID6         |
|---------------------|

Most azt gondolom, hogy ez a felépítés a legrugalmasabb, viszont csúnyán bonyolult: 


|---------------------|
|  vm1  | vm2   | ... |
|---------------------|
|  LV1  | LV1   | ... |
|---------------------|
|  VG1  | VG2   | ... |
|---------------------|
|  PV1  | PV1   | ... |
|---------------------|
| DRBD1 | DRBD2 | ... |
|---------------------|
|  LV10 |  LV20 | ... |
|---------------------|
|         VG          |
|---------------------|
|         PV          |
|---------------------|---------------|
|        sda3         | M1 | M2 | ... |
|---------------------|---------------|
|        RAID6        |      SSD      |
|---------------------|---------------|

Így az egyes vm-ek által kapott disk mennyiségét a LV10 és LV20 állításával lehet szabályozni a vm-ek snapshotját és visszaállítását pedig a LV1 és LV2 szintjén lehet csinálni.
Szerintem célszerű a DRBD metadadatokat externalként egy SSD-re tenni a sebesség miatt M1, M2 ...

Valakinek ötlete ennél egyszerűbb, de hasonlóan rugalmas felépítésre?