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

10.7.2009 11:12 | Přečteno: 1418× | ostatní | poslední úprava: 10.7.2009 12:54

Ať už používáme RAID pole na serverech či desktopech, je dobré mít na paměti několik bodů. Předesílám, že tyto body jsem nashromáždil při svých úvahách, podpořených čtením mnoha článků na Webu a jistou osobní zkušeností, která ale v této oblasti není ani zdaleka tak velká, abych měl nárok považovat se za odborníka. Naopak očekávám, že místní odborníci mě vyvedou z omylu, že o diskových polích něco málo vím.

Bod I. RAID není náhrada pravidelného zálohování

Správci serverů tohle obvykle vědí, ale ostatní si to často neuvědomují. Ano, RAID mne obvykle (pokud to zrovna není RAID 0) ochrání před výpadkem minimálně jednoho disku. Ale přijít o data lze i bez poruchy pevného disku. Může se porouchat řadič, může být v jádře operačního systému chyba, která bude pěkně potichu kazit data (nebo následkem které pole zkolabuje), může zkolabovat souborový systém nad polem, no a nebo může uživatel důležitý soubor omylem vymazat sám. Data by tedy měla být zálohována bez ohledu na to, jaký RAID byl použit.

Bod II. Když disk selže, co pak?

Máme nějaký RAID, který je schopen přežít výpadek jednoho disku. Dříve nebo později k výpadku dojde. V tu chvíli se nám spouští pomyslné stopky. Objednáme náhradní disk, náhradní disk dorazí k nám, my vyměníme vadný disk a nainstalujeme nový. Hotovo? Nikoliv. Pole je třeba rekonstruovat. Rekonstrukce může trvat v závislosti na mnoha parametrech i desítky hodin. V tu dobu je pole nejzranitelnější - nejenom, že ještě nemáme pole v celku, ale při rekonstrukci dochází ke značnému vytížení zbývajících disků.

Jaká je pravděpodobnost, že selže i nějaký z dalších disků, a pole se odebere do věčných lovišť? Pole má za sebou již nějakou dobu provozu, disky již dávno nejsou čerstvě dovezené z továrny, a ještě k tomu dochází při rekonstrukci k jejich značnému vytížení. Pravděpodobnost selhání je tedy vysoká. I to je důvodem, proč se před rekonstrukcí doporučuje aktualizovat zálohu (zálohujete přece dle bodu I.?). I samotné zálohování bude představovat vytížení pole, ale pokud budete provádět pouze přírůstkovou zálohu (nebo nějaký ten rsync), bude dopad zálohy podstatně menší než dopad rekonstrukce pole.

Bod III. Pravděpodobnost selhání disku/disků není konstatní

Sen každého z nás je pole jednou vytvořit a už se o něj nestarat. Maximálně časem (a v klidu) vyměnit nějaký ten vadný disk. Jenomže je třeba mít na paměti, že disky se časem opotřebovávají a pravděpodobnost jejich selhání časem vzrůstá.

U pevných disků, které pracují 24 hodin denně bez přestávek, pak za čas hrozí problém s mazivem/lubrikantem, který vyschne nebo po vypnutí ztuhne. To pak může způsobit, že u dlouho běžícího pole bude do výpadku proudu všechno v pořádku, a po opětovném zapnutí se několik disků prostě už neroztočí. Co to udělá s polem je snad jasné...

Aby to nebylo jednoduché, existuje "kojenecká úmrtnost", kdy nové disky mohou mít různé výrobní vady, které se obvykle projeví brzy při nebo po jejich zahoření, čili, na počátku života disku je relativně vyšší pravděpodobnost selhání, která se za čas sníží na jistou úroveň, která po několika letech začne opět růst, a poroste až do doby selhání. Viz studie.

Bod IV. Chyba čtení při rekonstrukci

Poměrně zajímavým článkem byl tento, který v podstatě říká, že zatímco kapacity disků se zvyšují, pravděpodobnost výskytu chyby čtení vztažená k množství čtených dat zůstává konstatní. Proto se s rostoucí kapacitou disků zvyšuje pravděpodobnost selhání rekonstrukce RAIDu 5. Článek dokonce říká, že brzy nebude stačit ani RAID 6.

K tomu se váže i jedna moje nedávná zkušenost, kdy dva pevné disky z degradovaného RAID 6 pole (5 ze 6 disků) vypadly velmi krátce (sekundy/minuty) za sebou v důsledku chyby čtení, následkem čehož zkolablovalo celé pole (naštěstí na něm ještě nebyla žádná data). Disky byly připojené každý přes jiný SATA řadič. SMART disků hlásil v obou případech jedničku u Reallocation Event Count, následné SMART testy potvrdily chybu při čtení daného sektoru. Disky jsem projel nástrojem badblocks, který příslušné sektory přepsal. Realokovat je nebylo třeba, zápis se podařil, takže jednička skončila ve SMART hodnotě 198 (Uncorrectable Sector Count). Příčinu s největší pravděpodobností přisuzuji dřívějšímu výpadku napájení, který nastal během zápisu na pole (příště se z těmi zatěžkávacími zkouškami budu mírnit...).

Bod V. vypovídací hodnota S.M.A.R.T.

SMART je úžasná technologie, jejíž ambice je předvídat mechanickou poruchu disku ještě před tím, než nastane. Problémem je, že odhalí pouze jisté typy problémů. V mnoha případech chybu předpovědět nedokáže. Jeho vypovídací hodnotu bych spíše bral tak, že pokud SMART říká, že disk je v háji, má pravdu. Pokud SMART říká, že je všechno v pořádku, to ještě vůbec nic neznamená.

SMART je nicméně vynikajícím pomocníkem při diagnostice problémů s pevnými disky. Pokud příslušné SMART hodnoty interpretujete správně, mnohdy vám napoví, kde je zakopán pes. Naučit se SMART údaje číst a správně interpretovat ovšem není vůbec jednoduché. Začít můžete tady.

Závěr

A co vy? Jak se díváte na problematiku diskových polí? Máte další tipy a zkušenosti? Sem s nimi.

Měl bych dodat, že tento zápisek jsem publikoval také na svém soukromém blogu, ale tam si ho nepřečte tolik lidí jako tady. A hlavně mi tam tolik lidí nebude vyvracet případné omyly, kterých jsem se ve svých úvahách dopustil, a o to mi jde především.

Další čtení

• Michal Fecko, Zakladne pravidla swRAIDu typ 1

       

Komentáře

[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.

 

---