Dotaz: poskozena zaloha LVM snapshotu

[fish]

Zdravim,

narazil jsem na zvlastni problem a uz nevim kde hledat puvodce.

Mam virtualizacni server Debian+Xen hypervizor, virtualy maji kazdy svuj LV.

Na nej se pripojuje zalohovaci stroj, ktery provadi zalohu dat nasledujicim jednoduchym postupem:

- vytvori snapshot

- stahne snapshot pomoci `ssh "dd if=snapshot bs=10M 2>/dev/null" | dd of=vm.img bs=10M`

- zrusi snapshot

Vsechno funguje, ale ve chvili, kdy jsem pro kontrolu pridal vypocet checksumu snapshotu na zdrojovem a image na cilovem serveru, jsem zjistil, ze jeden ze ctyr virtualu ma pokazde chybu v datech. Zbyvajici jsou vzdy vporadku. Velikost VM je u vsech virtualu stejna a i preneseny poskozeny image je cely. Kdyz ten samy snapshot na zdroji preulozim do image a pak stahnu pres scp, jsou data vporadku (na to ale obecne nemam kapacitu, proto se data stahuji primo pres dd+ssh).

Zkusil jsem oba stazene image porovnat a chyba se objevila na cca 15G z 20G. Slo odhadem o 1024B, puvodni blok obsahuje pouze nuly, v cilovem je nahodne nastaveny kazdy osmy byte. Kopirovani image trva relativne dlouho, takze jsem zatim nezkousel, jestli k poskozeni dojde pokazde stejne.

Narazil nekdo na podobny problem, pripadne mate napad co vyzkouset?

diky za napady

Odpovědi

[Jendа]

To může být i chyba v RAM. Má to ECC? Memtest?

Kopirovani image trva relativne dlouho

Pokud je bottleneck v síti, velmi doporučuju dělat rsync --inplace, přenese pár metadat a jen změny.

[Jendа]

(a taky to zchecksumuje, takže je větší šance, že se na tyto chyby přijde)

[fish]

rsync bych samozrejme pouzil rad, kdyby ovsem umel prenaset obsah blockdevice. Vim, ze existuji patche, ale nechce se mi na produkcni server davat jinou nez balickovou verzi.

Kazdopadne to nemeni nic na tom, ze ten stavajici prenos by mel fungovat, i za cenu toho, ze se prenasi zbytecne vic dat. Problem s pameti to podle me nebude (a nemam sanci to overit). Moc se mi nezda, ze by se problem objevil vzdy jen u jednoho LV. Nicmene me to navedlo na jiny napad - potencialni problem s raid1. Pustil jsem check a skutecne se objevilo nekolik inkonzistenci. Byla by to sice velka nahoda, ze by se projevily zrovna jen u dat snapshotu pro jeden LV, ale moznost to je. Pustil jsem resync pole a dam vedet, jestli to pomohlo.

[pavele]

S volbou --inplace by to měl rsync umět.

[Jendа]

rsync bych samozrejme pouzil rad, kdyby ovsem umel prenaset obsah blockdevice

V dotazu píšeš of=vm.img, tak jsem myslel, že přenášíš blockdevice do souboru, a to umí.

[fish]

V tom pripade netusim jak. rsync prenese device node, nikoli jeho obsah. Pro prenos obsahu existuje patch copy-devices, ten ale podle diskuzi, ktery jsem nasel, prikompilovava asi jen Fedora a Ubuntu. --inplace samotny to neresi, ale pro zapis do ciloveho BD by samozrejme byl potreba a pro prenos velkych image se taky vyplati.

[Jendа]

Hm, fakt to nejde.

[Jooky (inactive)]

mas nasledovnu konfiguraciu ?

- dva a viac diskov cez md raid/mirror
- nad tym vsetkym lvm
- VM pouziva svoj vlastny swap

ak ano, tak:

Hlavne zo swapom sa stava jedna istym sposobom "zaujimava" vec. Ak VM dochadza pamat, tak nejake data odprace do swapu. Odpratanie do swapu vygeneruje I/O request a ten sa na MD vrstve rozdeli na dva (mirroring). Je ista pravdepodobnost, ze app, ktora sa dostava do swapu sa "zobudi". Zobudenie sprevadza zrusenie swap requestu a teda aj I/O. To moze vyustit do situacie, ze na jeden disk sa zapis dostane a na druhy nie. Kedze bola I/O operacia zrusena, tak nie je dovod akokolvek konkretny blok riesit a mirror ostane rozdielny. Pri citani "round-robin" read politika sposobi, ze raz dostanes zapisane data a raz nieco, co tam bolo predtym ...

- Ak mas konfiguraciu inu, tak skus to spresnit od diskov az po mountpointy/swap vo virtualkach.

[fish]

Vzasade ano, je to md raid1, na nem LVM a v jednotlive LV pro VM. Nicmene swapy jsou jako oddelene LV a ty samozrejme nezalohuju.

Kazdopadne to zatim vypada, ze ten problem skutecne vznikal nekonzistenci raidu. Po resyncu jsem opakovane zkousel provest zalohu a data jsou pokazde vporadku.

Ale stejne me prekvapuje, ze muze nekonzistence vzniknout pri praci s tolika urovnemi (VM FS > Hypervizor > LVM > MD), kdyz az MD je ten kdo vi o existenci vice disku a cekal bych, ze co prijme, to zapise na oba. Nicmene kdyz jsem zkontroloval par dalsich serveru, nekonzistence se objevuji casteji nez bych cekal.

Jedny veci ale porad nerozumim. Jak muze checksum blockdevice souhlasit s checksumem lokalnim image toho device, ale lisi se od checksumu image toho sameho device preneseneho po siti? Nenapada me duvod, proc by to dd se zapisem na disk zpracovaval jinak nez dd se zapisem do stdout ...

[Jooky (inactive)]

Ono to v zasade je, aj nie je problem :)

Zrusena I/O operacia je z pohladu filesystemu / swapu nepotrebna. Dany blok nebude FS, ani swap do dalsieho zapisu pouzivat, takze -> nie je problem

Block level zaloha, alebo raid verifikacia nad takto puzivanym polom moze ukazovat chybu, aj ked realne chyba nie je -> tu je to asi na dlhsiu diskusiu

Ked mas cas sa s tym pohrat, tak skus nasledovne:
- pockaj az sa znova nejaka inkonzistancia ukaze
- skus si najst addresu, na ktorej sa to nachadza
- cez debugfs si daj vypisat obsah daneho bloku (napr. podla navodu tu)

Podla mna to ukaze na nejake volne miesto.

Co sa tyka dalsej otazky:

dd if=/dev/vg_daco/lv_nieco-snapshot bs=1M | ssh niekto@niekde dd of=zaloha.bin bs=1M

musi preniest data 100% rovnako. Ak nesedia kontrolne sucty, tak zrejme nemas "cisty" neinteraktivny shell. Skus pozriet, ci sa ti nieco z profilu nenacitava, co trosku pozmenuje data ...

btw. ja by som v produkcii nepouzival dd | ssh dd. Je tam hodne veci, co sa ti moze potichu pokazit. Na problem prides az v momente, ked zistis, ze nie je zaloha ... Ja osobne by som zalohu robil cez sw bacula (Backing up Raw Partitions)

ps: nebude lepsie robit zalohu dat z virtualok, ako zalohovat vsetko vratane nepouziteho miesta ?

[fish]

dd if=/dev/vg_daco/lv_nieco-snapshot bs=1M | ssh niekto@niekde dd of=zaloha.bin bs=1M

musi preniest data 100% rovnako. Ak nesedia kontrolne sucty, tak zrejme nemas "cisty" neinteraktivny shell. Skus pozriet, ci sa ti nieco z profilu nenacitava, co trosku pozmenuje data ...

To me samozrejme napadlo jako prvni, proto jsem zkusil ty data porovnat a neslo o zadny truncate/append nebo pridani "dat" obsahujicich hlaseni shellu nebo ssh. Byl to vylozene binarni rozdil, kdy se lisily radove desitky bytu a obsahovaly nahodna data.

btw. ja by som v produkcii nepouzival dd | ssh dd. Je tam hodne veci, co sa ti moze potichu pokazit. Na problem prides az v momente, ked zistis, ze nie je zaloha ... Ja osobne by som zalohu robil cez sw bacula (Backing up Raw Partitions)

ps: nebude lepsie robit zalohu dat z virtualok, ako zalohovat vsetko vratane nepouziteho miesta ?

Moznych problemu jsem si vedom, ale tohle reseni ma zasadni vyhodu v tom, ze v pripade problemu muzu ten image rovnou spustit v zaloznim hypervizoru. Z Baculy a podobnych, bych ho musel nejdriv nekam obnovit. Z tech VM zaroven delam i rdiff-backup, ale s nim zase nemuzu udelat plnohodnotnou zalohu bez zastaveni VM (a davat dovnitr VM LVM jen kvuli snapshotu nevidim jako idealni). Kazdopadne diky za napady a pripominky. Aktualne ty checksumy souhlasi, takze nemuzu dal experimentovat, ale docela rad bych nekdy prisel na to, kde se tam ten rozdil v datech bral ...

[Jooky (inactive)]

To me samozrejme napadlo jako prvni, proto jsem zkusil ty data porovnat a neslo o zadny truncate/append nebo pridani "dat" obsahujicich hlaseni shellu nebo ssh. Byl to vylozene binarni rozdil, kdy se lisily radove desitky bytu a obsahovaly nahodna data.

hmmmm, ssh a samotne tcp/ip si robi kontrolu. Mozes na zdroji a cieli zbehnut memtest ? "just to be sure"

bacula a spol -> ak zakaznik ocakava taky styl restoru, tak si asi moc nevyberies. Ja mam to "stastie", ze sme sa dohodli na file level restore. Kazdy system ma svojho bacula clienta a len realne data vyhatujem z masin ...

Kazdopadne diky za napady a pripominky. Aktualne ty checksumy souhlasi, takze nemuzu dal experimentovat, ale docela rad bych nekdy prisel na to, kde se tam ten rozdil v datech bral ...

nz, ked by sa to znova ukazalo, tak skus najst presne blok. Z toho by sa dalo dopatrat cez debugfs, co tam je presne. Dole som este pridal jeden koment, kedze asi som to uplne presne nesformuloval predtym + par napadov ako monitorovat take pole. (Na thread si necham zapnute sledovanie)

[R]

To je podla mna pekna blbost. MD nevie nic o tom, co ma vnutri - ci je to filesystem, swap alebo nieco lubovolne ine. Takze nesmie za ziadnych okolnosti dopustit, aby data nezapisal na vsetky zariadenia v mirrore.

[Jooky (inactive)]

Nieje :o) ... a nejde o realne zapisy, tie musia byt vzdy zapisane na kazdy relevatny disk v raid konfiguracii. Ide o stav, ked app / kernel zrusi I/O request v momente, ked uz data zacali byt zapisovane. Riesilo sa to tu uz raz. Ked budem mat cas, tak skusim pohladat povodny thread.

[lertimir]

A máš představu, jak moc se to používá. Sice vím že existuje io_cancel, ale moc netuším, jak to smysluplně použít. Tedy, kdy jsem schopen se dostat do situace, kdy se jednak v jednu chvíli rozhodnu pro IO operaci a než operace je provedena zjistím nové skutečnosti na základě nichž bych ji chtěl zrušit.

[Jooky (inactive)]

eeee, nemyslel som io_cancel. Ospravedlnujem sa, skusim to sformulovat trosku inak.

- Ak je "naspodu" raid5 a podobne (stripe + parita), tak toto spravanie je viac nez len podozrive + echo "check" > /sys/block/md*/md/sync_action nesmie ukazat nieco ine ako 0 (slovom nula) v /sys/block/md*/md/mismatch_cnt

- Ak je "naspodu" raid1 (mirror, popripade kobinacia ako raid10), tak "by design" sa mozu tie dva disky lisit. Preto napr distribucie s automatickou kontrolou md-raid ignoruju mirror.

Nemal som pouzit nazov "zrusena" I/O, ale skorsie nepotrebna / zahodena. Priklad:

1) Je malo pamate a VM sa rozhodne nejaku stranku dat do swapu. Toto vyprodukuje dve I/O operacie a je celkom dobra sanca, ze sa APP prebudi a zapise do stranky (ked je malo pamate). VM si danu stranu oznaci ako "dirty" a neriesi, co sa stalo so zapisom. Realne moze jedna DMA operacia dobehnut s povodnymi datami a druha s novymi, alebo jedna z nich nedobehne vobec (ked VM povie, ze to uz nepotrebuje). V realnom stave nie je dovod z takeho miesta citat, takze sa to nejak neriesi, no block level backup bude ukazovat rozdiel (podla toho z ktoreho disku a md rozhodne citat).

2) Nejaka app ma "memory mapped" subor. Do suboru priebezne prihadzuje data a manager pamate ich prehadzuje do suboru. Tak isto sa moze stat, ze sa data zmenia a na diskoch nie su do dalsieho zapisu rovnake data. Tato situacia by mala trvat len kratko, ale zalezi na obieme zmenenych dat + ak sa napr. nespravne signalizuje vyrabanie snapshotu filesystemu (toto je snad uz konecne fixnute v LVM), tak dany blok sa v aktualnom stave "zafixuje".

3) "memmory mapped" subor je po zmenach, ktore sa ciastocne zapisali vymazany. (toto musim pozriet, ci to stale tak funguje) Data sa uz nebudu zapisovat a obsadene miesto sa oznaci ako volne. Tak isto je toto skorsie az race condition, ale moze nastat ...

Ak sa cita vsetko, vratane miest, ktore nie su validne (volne miesto, este nezapisane, etc.). Tak vysledok zalezi od toho, z ktoreho disku sa raid rozhodne precitat. Dost zaujimave citanie na tuto temu je jeden debian bug report. Konkretne odpoved #41.

V pripade md-raid(-u) v mode mirror check pola moc nepomoze. Jednine ako skontrolovat, ze vsetko ide ako ma, je kontrolovat aj uroven pod. Ked je moznost, tak aj uroven nad:

- stav diskov (pravidelne smart -t short, smart -t long, smart -a / mozem vyzdielat moj konfig, ak je to zaujimave)
- samotne pole, ci nehlasi I/O errory a je spravne zlozene, etc.
- checksumy na urovni filesystemu *
- z casu na cas memtest (len vazne pri velkej paranoi, alebo podozreni na problem)

* (ja vramci paranoje kontrolujem vsetky staticke subory a cast dynamickych kontrolujem oproti katalogu / dobuducna mam plan prejst na fs s checksumami dat, zrejme btrfs)

FYI: zbehol som na jednej mojej masine check a mismatch_cnt je nenulove. Ked budem mat cas, tak s tym skusim kus pohrat :o)

[Jendа]

Preto napr distribucie s automatickou kontrolou md-raid ignoruju mirror.

Debian mi mirror neignoruje a jednou za pár měsíců tam najde chyby (stroj s ECC). Tohle by je mohlo vysvětlovat (je to virtualizační host a na tom RAID1 jsou swapy všech virtuálů; paměti mají celkem dost, ale i tak to občas trochu zaswapuje).

Tím pádem odvolávám jak jsem tu někde psal „po půl roce jsem konečně viděl na disku silent data corruption“. Současně se mi ale dost zúžil prostor, kde data corruption hledat.

FYI: zbehol som na jednej mojej masine check a mismatch_cnt je nenulove. Ked budem mat cas, tak s tym skusim kus pohrat :o)

Check to rovnou opraví, ne?

[Jooky (inactive)]

V tom bugreporte z 2007 preberali moznost vypnut check na mirror poliach a nasledny reporting mismatch_cnt. Ked mam pravdu povedat, nepozeral som ci to tak aj naozaj spravili.

md arrays can be scrubbed by writing either check or repair to the file md/sync_action in the sysfs directory for the device.

Requesting a scrub will cause md to read every block on every device in the array, and check that the data is consistent. For RAID1 and RAID10, this means checking that the copies are identical. For RAID4, RAID5, RAID6 this means checking that the parity block is (or blocks are) correct.

If a read error is detected during this process, the normal read-error handling causes correct data to be found from other devices and to be written back to the faulty device. In many case this will effectively fix the bad block.

If all blocks read successfully but are found to not be consistent, then this is regarded as a mismatch.

If check was used, then no action is taken to handle the mismatch, it is simply recorded. If repair was used, then a mismatch will be repaired in the same way that resync repairs arrays. For RAID5/RAID6 new parity blocks are written. For RAID1/RAID10, all but one block are overwritten with the content of that one block.

man 4 md

check explicitne nevyzaduje fixnut data. Fixuje sa len to, co by sa normalne fixlo pri beznom citani s chybou na disku. repair explicitne vyzaduje kazdu inkonzistenciu fixnut. Pri mirror poliach (1 a 10) to znamena, ze sa viacmenej nahodne vyberie jeden disk a rozdielne preplacnu na ostatnych.