Názory k článku
LVM: Praktické ukázky

ne reiser2fs ale resize2fs :)

Ooops.. opraveno.

Měl bych dotay k tomuto, cituji:

Pokud použijeme pro každý disk samostatný VG, tak se nám nebudou data rozlézat po obou discích, ale zůstanou jen na jednom. Tím dosáhneme aspoň toho, že po vypadnutí jednoho disku nepřijdeme o data na obou.

Zatím jsem vždy viděl doporučení dát všechny disky (pokud jich není skutečně hodně a není k spec. důvod to tak nedělat) do jedné VG. V takovém případě má být možné právě zmiňované migrování LV na nový disk.

Je skutečně možné on-line migrovat LV mezi dvěma různými VG? Zdá se mi, že ne. Už proto, že když budu mít připojenou LV: /dev/nejaka_vg/nejaka_lv - tak není online změna VG prakticky možná.

V konfiguraci s jednou VG přes více disků je samozřejmě možné při vytváření Logical Volume tuto omezit jen na danou PV, takže se "nerozleze" přes více disků. V případě havárie jednoho z disků budou přístupné oddíly, které jsou celé na tomto disku (PV). Metadata jsou na obou discích, takže výpadkem jednoho nepřijdeme o celou VG!

Je možné přesouvat PV mezi VG, ale jak to pak dopadne s daty se neodvážím odhadovat. Online migrace LV na jinou VG opravdu možná není, nikde jsem na nic podobného nenarazil. V článku pracuji pouze s jednou VG a citovaný odstavec je spíše jenom myšlenka než nějaké doporučení.

No slo by to udelat spojenim dvou VG (za predpokladu za maji obe stejnou velikost PE), pote presunout LV z disku jedne VG na disky druhe VG a pote obe VG zase rozdelit. Ale uz si nepamatuju, zda online.

Troska sa logicky zamyslite :-)

kazdy PV ma VGID v hlavicke, cize vzdy system vie kto kam patri. LV je len logicky kontajner vytvoreny cez jeden alebo viac PV. Migracia LV medzi dvoma VG teda NIEJE mozna. Jedine co sa da spravit je kopirovanie. dd skopiruje aj prislusne identifikatory VG atd. takze vyvori len kopu problemov. Migroval som na SLES 10 system z interneho smartarray disku na SAN disk, to len bola sranda s duplicitnymi IDckami.

Co ma na linuxovom LVM vzdy zarazalo je absencia jednoducheho RAID 1. Volakedy na to sluzila pomerne krepa konfiguracia cez device mapper, v novsich verziach nemam prehlad. Je to jedina vec ktora ma odradza od linuxoveho LVM. Mam skusenosti s LVM pod HP-UX a LSM pod Tru64 a ich moznosti, jednoduchost konfiguracie a prehladnost su na linuxe stale nedosiahnutelne (a to je ich implementacia LVM desne stara oproti linuxovej).

No k HP-UX, pokud tam neni veritas, tak jeho LVM umi velke kulove, dokonce neumi delat zvetsovani online, takze na LVM2 opravdu nema.

LVM2 umi mirroring (RAID1), je to velmi dulezita vlastnost, protoze LVM2 umi i cluster, zatimco SW_RAID nikoliv, takze je mozne mit 2 pole 2 servery a napr LVM2 + GFS a mit data online replikovane, oba servery musi videt obe pole a muzou do nich zapisovat najednou.

Tru64 je dost unikat, ostatne jako vse, co Digital vymyslel, takze toho skutecne umi vice, nez LVM2, ovsem mi LVM2 staci.

no jasne ze na HP-UX bez OnlineJFS nic nezvacsis ... to som zvedavy ako by si to robil na inode filesysteme ako ext2 :-) a mirror na HP-UX je za priplatok, to uznavam. ale stale sa s tym robi komfortnejsie ako s Linuxovym LVM (a to nehovorim o strasnom vypise konfigu na Linuxe).

Děkuji autorovi za nakousnutí tématu bezpečnosti LVM. Asi se časem také pustím do nějakého experimentování na tomto poli...

Jojo, minulý týden sem si s tím LVM užil. Potřeboval sem najednou docela dost souvislého místa a protože mám lvm a v něm lvčka na usr, home, atd. tak v každém kromě home bylo nějaké volné místo, v home bylo hromada volného místa, potřeboval sem teda části volného místa z ostatních oddílů nacpat do home. kdybych při instalaci prozíravě nenasadil lvm, tyhle srandičky by asi nebyli tak jednoduché. no ani to netrvalo dlouho, cca půl hodiny. no a pak zase pěkně vrátit vše nazpět. jo a taky je dobrý se hodit do single init režimu, když děláte takovéhle alotrie nad živím systémem.
PS: a co takhle použít jednu particii na celý systém? :)

Chtel bych se zeptat, zda mel nekdo problemy, s vypadkem LVM2 a to tak, ze se LVM2 uz nenasel a musel se obnovovat ?

Uz jsem opravoval ext2/3 xfs a vse mozne, dokonce i SW_RAID, ale tam to byl skutecne vypadek (vite, ze kdyz se zhrouti SW RAID5 a pak disky poskladate a date vytvorit znova uplne stejne, tak se vam tento RAID obnovi a zustanou an nem data, samozrejme o tom vi a chce to potrvrdit force a realy force, nebot pri spatnem zadani by spatne spojil bloky, ale jednou jsem tak ziskal nejcerstvejsi data, nebot zaloha byla 24hod stara a ja ziskal aktualni, ovsem bylo to po zasahu blesku, kdy to cele postupne zkolabovalo a po vypnuti a zapnuti se diky rozjely, ovsem SW_RAID se sam nespojil a XFS chtel pak taky opravu)

Ovsem s VLM2 jsem nikdy na problem nenarazil, nechci tim rict, ze by se metadata nemely zalohovat, jenom me zajimaji prakticke zkusenosti.

jinak s LVM2 zpravuji i 18TB oddily po 2TB, jinak pokud je disk/HW_raid vetsi nez 2TB musite pouzit GPT adresaci diku.

Mohu se zeptata jak je to s obnovou dat? Naprikald ve VG mam disky sda1 a sdb1 s LV test1,test2,tes3. A situace je takova, ze mi odejde disk sdb1, prijdu o vsechna data ? Nebo se nektera data, ktera jsou fyzicky na sda1 daji obnovit ?

"Jenom" o ty oddíly, které jsou buď částí nebo rovnou celé na postižených discích.

No pokud se nerekne jinak LVM obsadi oba disky, tedy vypadek.

LVM ma byt provozovano bud na jednom disku, nebo RAID (jedno ci SW nebo HW), stripping (ala RAID0) se pouziva jenom na docasne data.

Popravde, pokud vypadne jeden z disku a data jsou na obou, tak jsou data nekonzistentni.

LVM se má používat tak jak to vyžaduje situace.. tedy ne jen nad RAID polem nebo jedním diskem.

Zrovna nedávno mi odešel jeden z pěti disků v LVM2. Když najel na určité místo, zastavil se a zcela přestal se systémem komunikovat. Konečně se ověřilo, že je to vymyšlené velice dobře - LVM2 odmítala přijímat jakékoli změny konfigurace, nicméně připojený souborový systém zůstal připojen a bez problémů četl data, která byla na jiných fyzických discích. Když chtěl ss přečíst něco z mrtvého disku, vyhlásil LVM souborovému systému chybu, na což souborový systém zareagoval tak, že ve výpisu adresáře prostě zmizely některé soubory. To byl v podstatě jediný efekt, jak se dalo poznat, že něco není v pořádku.

Disk jsem vyndal a připojil přes USB, abych ho mohl jednoduše vypnout/zapnout, pokud přestane komunikovat. Takto jsem z něj na nový disk vykopíroval většinu zdravých dat, až na disku zbylo posledních 100 PE (po 16 MB), ve kterých byla ta chyba... Po několikerém přemlouvání se disku povedlo i tato data přečíst, takže nakonec celá havárie skončila bez ztráty dat.

Jediný problém je, že teď mám LV strašně fragmentované a defragmentace bude asi možná jenom ručně :)

Clanek je zajimavy, ale jen me utvrdil v presvedceni, ze je cela ta sranda s LVM jen dobra zadelavka na problemy v buducnu. Podle meho nazoru dnes delit disky na vice oddilu je nesmysl. Jediny pochopitelny pripad je, kdyz mam dualboot (a pak mi staci dve primarni particie). Ale jinak je to hloupost. Uz jen proto, ze normalne nevyuzijete volne misto (spatny odhad velikosti pri rozdelovani), a pokud se pouzije LVM, tak je to potom akorat hrani se zvetsovanim/zmensovanim oddilu. Kazda takova manipulace prinasi potencionalni riziko ztraty dat. Takze takovy postup je iracionalni a zbytecny.

Hm, na desktop je to asi dost zbytocne... avsak na serveri, ked mame hotswap disky (alebo nejaky storage cez Fibre Channel) je moznost zvacsit volume pridanim diskov alebo vymenou za vacsie ZA BEHU stroja bez jedineho rebootu na nezaplatenie (neviem ci to celkom tak funguje aj na linuxe, ale na velkych HA systemoch s HP-UXom ci AIXom by sa bez toho asi nedalo existovat).

na linuxu normalne, pomoci echo "add- ..." > /proc/scsi/scsi lze disk pridat, ci odebrat a QLA karta se tez umi prez echo rescanovat, pokud nemam sansurfer.

Taktez pouzivam LVM a FC pole

Jo a nekdo zalohuje pres snapshoty.

Presun PE z disku na disk
-------------------------
Presun LV na iny PV (disk) sa da urobit aj bez zistovania konkretnych cisiel PE, na ktorych sa nachadza. Pomocou parametra -n vyberieme len tie PE z sda3, ktore patria LV movetest:
pvmove -n movetest /dev/sda3 /dev/sdb1

Pre zrozumitelnost by bolo tiez vhodnejsie dat
lvcreate -L 1G -n movetest test_lvm
pred
lvdisplay -m /dev/test_lvm/movetest


RAID 1
------
Parameter -m urcuje na kolko DALSICH PE sa ma LE mapovat. Pre RAID 1 (s 2-ma PV) je hodnota 1 (teda jeden 'original' a jedna 'kopia' dat).
Bohuzial na RAID 1 pod LVM potrebujete 3 PV ('original', 'kopia' a 'log'). Log je maly a eviduje stav zosynchronizovania. Moze byt aj v pamati (vtedy stacia 2 PV), ale potom sa LV synchronizuje po kazdom restarte.

Prikaz
lvcreate -L 1G -m 2 -n raid1 test_lvm
by teda potreboval 4 PV (mate len 2). Preto za Vam to nepodarilo.

Inac RAID 1 v LVM je podla mojich testov nepouzitelny - pri vypadku jedneho z 2 'datovych' PV prejde LV do ReadOnly rezimu a po restarte sa uz automaticky nepripoji. Ked vyzadujeme bezpecnost, je lepsi SW (md), alebo HW RAID.


---------
Pre menej skusenych odporucam testovat LVM cez /dev/loopX - mozete si narobit PV-ciek kolko chcete aj ked mate v kompe fyzicky len jeden disk. Tiez sa da jednoduchsie (a snad aj bezpecnejsie) simulovat vypadok PV a vyskusat si obnovu.
Vytvorenie 100MB 'disku':
dd if=/dev/zero of=disk1 bs=1M count=100
losetup -f disk1
pvcreate /dev/loop0

Clanok je zaujimavy a tema super.

Tak nevím, asi jste nečetli manuál, ale přesun LV se dělá ONLINE a to takto:

0) rozšířím VG o PV na novém disku

pvcreate /dev/novydisk
vgextend MojeVG /dev/novydisk

1) konvertuju LV na mirrorovaný. TohleLV bude stále online, r/w, a vše funguje dál (může to být klidně fs běžícího systému). Parametr --corelog způsobí, že se log mirroru nechá jen v paměti, tzn. mirror nepřežije restart, kdyžtak se začne kopírovat znova.

lvconvert -m1 --corelog MojeVG/TohleLV /dev/novydisk

2) Občas se podívám, jestli je to už zkopírovaný (Copy% = 100)

lvs -a -o +devices

3) konvertuju LV zpět na normální (lineární), ale nechám si jen tu novou kopii (parametr je ten PV ktery chci odstranit)

lvconvert -m0 MojeVG/TohleLV /dev/starydisk

A je to.

P.S.: ten manuál k lvconvert v debianu neexistuje ;-)

No kedze som sa hral aj s LVM i raid i „holym“ FS mozem povedat ze pre man bolo riesenie nasledovne:
- Na server som nasadil SW RAID 1 + denna zaloha dat cez rsync
- na desktop som dal 1 particiu s ext4, predsa len lvm je tam uplne k nicomu, za prve to je dalsia vrstva ktora logicky spomali I/O operacie a potom pri zmene disku nie je nic lahsie ako urobit particiu a MBR a potom len skopcit data cez cp alebo rsync, naco sa serinkat s LVM? Tymyo mozem tendruhy disk mat akejkolvek velkosti kam sa zmestia moje data.
Vyznam LVM vidim snad len v pripade spajania viac diskov do jednej logickej vrstvy, a mozno snapshotu na servere.