Pár praktických poznámek k diskovým polím (diskuse)

[aaaa]

A aky je Vas nazor a pripadne skusenosti (rychlost, spravanie sa pri havarii a pod.) pri pouziti LVM nad RAID polom?

[Shadow]

Zatím žádné, LVM příliš nepoužívám, a tam, kde ho používám, mi na diskovém poli zatím neselhal (a benchmarky jsem nedělal). Možná vám odpoví někdo povolanější.

[R]

Suhlasim, SMART je velmi dobra vec a treba ho sledovat. Sluzi na to smartd zo smartmontools.

Vypadok napajania pri zapise naozaj vyrobi necitatelny sektor, ktory sa prepisanim opravi.

Na prepisanie sa da pouzit hdparm --write-sector. Ak sa nedari sektor precitat pri rebuilde pola, niekedy pomoze viackrat skusit hdparm --read-sector, obcas sa to podari a sektor sa opravi. Ak to nejde, tak neostava nic ine, len prepisat.

Z pohladu bezpecnosti je do RAIDu vhodne davat rozne disky. Bud od roznych vyrobcov, alebo aspon rozdielne typy, prinajhorsom rovnaky typ, ale kupeny v inom obchode. Cielom je zabezpecit, aby disky odchadzali po jednom a nie naraz.

[aaaa]

www.abclinuxu.cz/blog/home_feco_blog/2007/9/zakladne-pravidla-swraidu-typ-1

[Shadow]

Vida, to jsem přehlédl. Odkaz jsem přidal do blogpostu. Díky.

[Pavel Siska]

Hezke cteni. Docela by mne zajimalo, zda ma nejkdo nejaky ten tip ohledne kopirovani souboru. Kdyz uz se stane, ze pole odejde a je potreba zavest nove a na nej nakopirovat data ze zalohy.

Pokud se jedna napriklad o 300GB dat a casto v malych souborech, tak to i mezi dvema SATA disky trva asi 5 hodin s tim, ze na tech malych souborech je hrozny zasek a kopirovani jde opravdu pomalu.

Je nejaka moznost kopirovat to cele jako nejaky blok? Vim, ze jde napriklad duplikovat cela partition na jiny disk, coz je urcite rychlejsi, nez to kopirovat na urovni filesystemu, ale pokud jsou parition na obou discich jine, tak jak toto resit?

 

Zkusenost je s ext3...

[Shadow]

Buď kopíruji jednotlivé soubory, nebo _celý_ filesystém. Pokud přenáším filesystém, je možné přenést menší filesystém na větší partition a nechat filesystém "dorůst" (grow), tj. využít operaci resize. U ext3 se to dělá třeba takto.

[Heron]

Mno, ten odkazovaný článek je takový ... až zbytečně moc složitý.

Zvětšení ext3 je triviální. Stačí zvětšit oddíl pod ní a pak už je pustit resize2fs oddíl. Netřeba umount, netřeba reboot, netřeba live distra a už vůbec není potřeba z ext3 dělat ext2 (odebráním žurnálu). Lze to dělat za běhu systému a s připojeným systémem souborů. Více třeba tady.

[R]

Ako zvacsis particiu "pod" namontovanym filesystemom bez restartu? Pokial viem, tak to sice (c)fdiskom zmenit ide, ale "blockdev --rereadpt" skonci s chybou, ak je na tom disku nejaky filessytem namontovany.

[Jendа]

Heron asi automaticky předpokládá použití LVM

[Heron]

Ano předpokládám. Pravda, měl jsem to zmínit.

[xkucf03]

Nebo použít nástroj typu xfsdump a xfsrestore – tím se dají soubory přenést dost efektivně (lépe než cp i dd).

[Jendа]

Pokud se jedna napriklad o 300GB dat a casto v malych souborech, tak to i mezi dvema SATA disky trva asi 5 hodin s tim, ze na tech malych souborech je hrozny zasek a kopirovani jde opravdu pomalu.

Nepomohlo by posílat to rourou a na jedné straně dělat tar c a na druhé tar x?

[Heron]

Nepomohlo. Každý soubor je na jiném místě disku. Disk tedy musí neustále seekovat hlavačkami. Pomohlo by, kdyby se ty soubory četly v pořadí v jakém jakou na FS uloženy. Do toho by ale zase zasáhla jejich fragmentace (i když ta u malých souborů moc nebude). Úplně nejlepší by bylo kopírovat pouze zabrané bloky FS. Kopírovalo by se méně dat a bylo by to sekvenční čtení.

[Radek Hladik]

Dodal bych pár postřehů:

Pole je možné kontrolovat (echo check >/sys/block/mdX/md/resync_action). Dokonce jsem koukal, že nová Fedora 11 to už dělá každý týden z cronu.  Samozřejmě se tím zvyšuje pravděpodobnost, že nějaký disk selže, ale o to přeci jde. Jakmile je jakýkoliv disk tak špatný, že není 100% schopný plnit svojí funkci, tak se musí vyměnit. A u té výměny bych nedoporučoval čekat, až dorazí disk opravený, ale mít po ruce disk nový a rekonstrukci udělat co nejdříve. S tím je taky spojené to, že je dobré mít odzkoušené, zda systém nový disk umí bez restartu najít.

[Shadow]

Vida, tohle jsem vůbec netušil, že jde. To je super věc. Snad jen správným souborem je podle mého /sys/block/mdX/md/sync_action, soubor resync_action jsem v příslušném adresáři neobjevil. Každopádně díky moc za tip.

BTW, ono je také možné do pole přidat nějaký spare disk (třeba i více než jeden), takže hned po případném selhání dojde automaticky k zahájení rekonstrukce pole.

[Radek Hladik]

Jo, je to sync_action. Já to vždycky tabkuju a byl jsem línej to dohledávat A pletu si to se souborem v adrsáři pro scsi řadič, kterým se řekne řadiči, ať si rescanuje porty...

Spare disk je zajímavá možnost, ale zase žere slot na disk. A pokud chci mít jeden disk jako spare pro víc polí, tak to "nativně" nejde, ale musí se nakonfigurovat mdadm jako démon a ten ho v případě výpadku připojí. Abych se přiznal, to jsem ještě nezkoušel. A další zajímavost je vzdálený disk připojenž pžes iSCSI v raidu s lokálním, ale to už je zase trochu k něcěmu jinému....

[xkucf03]

1. Docela hezkým doplňkem RAIDu jsou LVM snapshoty – sice zase neřeší všechny důvody, proč mít klasické zálohy, ale některé přece jen ano – např. omylem přepsané smazané soubory, nebo chybu FS. Udržuji si tahle snapshot a čas od času ho smažu a vytvořím znovu – např. po upgradu nebo po přírůstku nějakých důležitých dat.
2. jaké máte kdo zkušenosti se ZFS? Byl jsem už na několika prezentacích a vždycky se tam chlubí (nejen) jeho odolností proti tiché ztrátě dat („silent data corruption“). Takže jak moc je to užitečná vlastnost a jak moc jen marketing? Komu už se takhle „potichu“ ztratila data z ne-ZFS disku.

[Shadow]

Ad 2) Zkušenosti se ZFS nemám (v Linuxu zatím není a žádný novější Solaris po ruce nemám), jednu pěknou prezentaci jsem také viděl, a ta technologie vypadá velmi pěkně. Silent data corruption nebo něco velmi podobného jsem nicméně zažil na jednom RAID-1 poli, kde jsem u větších souborů začal dostávat různé MD5 hashe při opakovaných čteních. Pěkné. O data jsem naštěstí nepřišel (zálohy byly) a problém odstranil (vyhozením defektního SATA řadiče), ale od té doby si na RAIDy dávám větší pozor - viz třeba tenhle blogpost. :-)

[xkucf03]

Docela hloupé je, že v takovém případě člověka nemusí zachránit ani ty zálohy – na chybu nepřijdu hned a mezitím zálohy přepíši novějšími (ale zmršenými) daty. Tak snad leda zálohovat přes rsync a na zálohovacím médiu dělat snapshoty po každé záloze → a mít tak všechny verze – ale v praxi to vyzkoušené nemám, jen mě to tak teď napadlo

[Nicky726]

Na tento typ zálohování je dobrý rdiff-backup, pokud je cílové médium dost velké je možné mít komprimovanou kompletní historii všech záloh a prostý mirror poslední z nich.

[dik]

rdiff-backup je vyborny,ma vsak jednu pro mne dost podstatnou nevyhodu - je desne pomaly, chapu ,ze dekomprimace neco stoji ,ale i tak  ...

dik

[David Šmíd]

Právě. Po zkušenostech s rdiff-backupem přecházíme na nilfs. Zdá se to být elegantním řešení problému.

 

---