Dotaz: RAID5 rekonstrukce diskového pole

[kibo]

Příloha:

• 30042014648.jpg (564655 bytů)

Na řadiči Adaptec 2610SA (HP ProLiant server), který používá RAID5 se poškodily data na dvou ze tří disků. Existuje nějaký nástroj, kterým bych se mohl pokusil rekonstruovat diskové pole?

V příloze náhled.

Děkuji za radu

Odpovědi

[ewew]

Ako prvé by som urobil kópiu 1:1 diskov na ktorích by mali byť poškodené data. Ďalší krok by bol test diskov cez S.M.A.R.T, kontrola atribútov a použitie HDAT2 na hladanie a opravu sektorov. Lepšie je urobiť zálohu na nové disky pre prípad, že by pôvodne disky zlyhali.

Zlyhanie RAID mohol tiež spôsobiť nejaký parameter disku.

Možné postupy v tejto problematike môžu byť rôzne. Popisovaný postup nemusí byť najvhodnejšie riešenie. Jednoducho je nutné zvážiť hodnotu dát.

[kibo]

Ahoj

udělal jsem si kopiji disků. Snažil jsem se připojit ke kontroleru lokálně přes "Adaptec Recovery manager" (dostupný také jako Linux bootable CD).

Podle dokumentace je tento typ kontroléru Adaptecem nepodporován, protože je vytvořen pro HP a Dell. Adaptec tedy odkazuje na support těchto dodavatelů. Použil jsem "Adaptec Recovery manager" pro Adaptec 2410SA.

S kontrolerem se mi nepodařilo spojit (existuje i CLI nástroj pro připojení ke kontroleru).

Po přečtení nějakého recovery tutoriálu jsem v BIOSU kontroleru znovu inicioval vadné disky a vytvořil nové pole. Při vytvoření nového diskového pole jsem použil volbu "Build/verify" a podruhé (z obnovené kopie) jsem vyzkoušel i volbu "Quick init". Po několika hodinách skládání skončil můj pokus neuspěšně. Došel jsem si pro zálohy, pustil jsem si hodně nahlas reggae a užil jsem si pěkný 1. máj - Svátek práce.

Díky za radu. Je mi jasné, že neexistuje jednoduchý návod.

[NN]

Pokud ti odejdou dva disky ze 3 v raid5 coz je samo osobe debilita, nemas nic a pokud k tomu jeste pridas HW raid s minimalni inteligenci popreju ti jen hodne stesti do budoucna.

[Heron]

Nebylo by rychlejší obnovení dat ze zálohy?

[PanZvedavy]

raid5 ze 3 disku je samo o sobe diletantstvi...ale raid5 ze 3 disku v produkcnim serveru???
Pokud pomineme absurditu teto situace, tak povetsinou se nema cenu zabyvat obnovou takto(vic poskozenych disku nez dovoluje raid)rozsypaneho pole.
V drtive vetsine to nepovede k uspechu a doba stravena snahou o obnovu vyrazne(i v nasobcich) predci cas nutny pro cisty reinstal a obnovu z(jiste cerstve) zalohy.

Musim se priznat ze me lidi co provozuji raid5 se tremi disky trosku desi...potkat je vecer v parku, tak hodim penezenku na zem a vyskrabu se na nejblizsi strom.

[Jendа]

Byl by nějaký argument k té děsivosti RAID5 ze tří disků? (data se samozřejmě každou noc zálohují)

[PanZvedavy]

3 diskova kombinace = mizerny vykon zapisu...,ale predevsim spatne zkusenosti s raid5 obecne, protoze uz jsem jich videl prilis mnoho se odporoucet - po odejiti jednoho se nakopnul hot-spare, ale nasledna extremni zatez slozila dalsi disk. Z historickych duvodu me jeste bezi par postarsich kousku dellu a ibm v nekterych lokalitach co maji raid5 z 5ti disku s hot-spare, ale ty jsou na doziti.
Aby to ale neznelo, ze jsem zasadne proti raid5 za vsech okolnosti...za poslednich par let jsem ho nastavoval zamerne pouze v jednom pripade, a to pri prechodu na virtualy jsem musel provest downgrade z raid6 na raid5, protoze radice raid6 nedavaly pri pozadovanych narocich. V tomto pripade, ale mam relativni pocit sucha a bezpeci, protoze mam diskova pole dvoje, kazde se dvema radici(aktiv-pasiv) a ty se navzajem zrcadli a tech par TB dat je pravidelne odlivano do knihovny.

Zpet k raid5 ze 3 disku...radeji bych zvolil raid 1 s hotspare. Sice to nebude zadnej rychlik v zapisu ani cteni, ale dlouhodobe jsou to nejvetsi drzaky.

[vandrovnik]

Než Raid 1 s hotspare, to už bych do toho Raid 1 dal rovnou všechny 3 disky. Bude lepší rychlost čtení za normálního provozu a pokud jeden disk zdechne, není třeba se tolik modlit, aby se stihlo udělat kopírování na hotspare dřív, než pod neobvyklou zátěží zdechne i disk druhý...

[Aleš Kapica]

Raid 1 se třemi disky? Možná mi něco uniklo, ale on by stejně ten jeden fungoval jako spare.

[dustin]

Proč? Máme např. raid1 s osmi disky (vsechny disky mají stejné rozložení partišen a na jejich datové partišně je 4x2 RAID10, tak proč rootovské partišny nedat do 8 x raid1).

[Šangala]

Ne, RAID 1 můžeš mít klidně nad 6 disky - na všech máš to samé (teoreticky zpomalíš zápis a potencionálně zrychlíš čtení ).

Řekl bych běžná situace u systému se softw. RAID 5, tak (minimálně) pro boot je RAID 1 přes všechny disky na 1.partition a na 2. je RAID 5.

[pavlix]

Běžná situace ano, nicméně pokud vím, tak GRUB2 bez problémů zvládá RAID5 a LVM už hoooodně let.

[Šangala]

To že to umí ještě neznamená, že to poskytuje vždy výhodu a musí se to využít

Například CentOS stále používá by-default jen GRUB.

Má to (někdy využitelnou) výhodu, že pokud je tam celý systém, tak systém nahodíš s libovolného disku - ať se to rozkokoší jak chce, tak systém nahodíš i s jedním diskem.

[pavlix]

A?

[Šangala]

¡B!

Formuluješ to tak, jako by jsi si myslel, že je to chyba a „dneska“ se to tak už nemá dělat…

[pavlix]

Napsal jsem, že je to běžná situace, ale že to už dlouho není nutné tak dělat, to je vše. Osobně nepovažuju GRUB2 za žádné zlo a naučil jsem se ho používat v době, kdy na distribucích ještě běžně nebyl default, tudíž nepovažuju za nutné rozhodovat se podle schopností GRUB legacy.

[Šangala]

Automatické provolávání scriptů kolem GRUB2 považuju za zlo, jinak je GRUB2 někdy fajn (na druhou stranu často by stačilo jen LiLo na 4 řádky).

Myslím, že u all-in-one serverů jo to často žádoucí a proto stále obvyklé…

Dohazovat něco do distribuce z boku je vždy na zvážení, takže to rozhodování je o něčem jiném.

[pavlix]

Automatické provolávání scriptů kolem GRUB2 považuju za zlo

Jakékoliv volání skriptů kolem GRUB2 považuju za menší zlo než odpovídající volání distribučně specifických skriptů kolem GRUB1. Alespoň je to předvídatelné napříč distribucemi. Nechci srovnávat s LiLo a vzhledem k notorickému používání LVM všude, kde to je, se ani necítím být dostatečně neutrální.

Automatizaci toho volání považuju za věc administrátora, potažmo distribuce. Moje aktuální distribuce (Gentoo) automaticky nevolá nic, ale jedním příkazem zpřístupňuje generování, které mi vyhovuje. Pokud bych používal o něco více automatizovanou distribuci typu Fedora nebo Ubuntu, asi bych předpokládal, že bude automatizace zadrátovaná přímo do aktualizací kernelu a nerozčiloval bych se, jen bych to v případě potřeby vypnul.

Myslím, že u all-in-one serverů jo to často žádoucí a proto stále obvyklé…

Tvrdit, že je to obvyklé není moc dobrým příspěvkem do diskuze, ve které rovněž tvrdím, že je to obvyklé.

Dohazovat něco do distribuce z boku je vždy na zvážení, takže to rozhodování je o něčem jiném.

GRUB2 jsem nikdy z boku nedohazoval, nýbrž používal z repozitářů, ačkoliv ještě nebyl používán instalátory daných distribucí. V případě Fedory jsem typicky dával /boot v instalátoru na flashku a po rebootu ho přesouval do root partition, dnes bych asi spíše použil yum --installroot=.... Na Debianu jsem tradičně používal debootstrap a Gentoo-style instalaci.

[Aleš Kapica]

To nemá cenu. Já už si ani téměř nedovedu představit, že bych měl používat GRUB legacy. Flash disk s GRUB2 je při řešení problémů se zaváděním k nezaplacení.

[Šangala]

Nemá cenu GRUB nebo nemá cenu to vysvětlovat?

Kdyby náhodu: tak nejsem proti GRUB2 jako takovému, na rescue flashce ho mám taky, ale u serveru jsem proti čemukoliv mimo základní repozitář, pokud to nemá pádný důvod. A vzhledem k tomu, že většina serverů opravdu naběhne s čímkoliv a /boot separé na zvlášť partition či zařízení je obvyklá a nutná věc, bo většinou je zbytek šifrovaný a až na tom LVM, tak ani není potřeba ničeho co umí, tedy není třeba ho přitahovat do distrubuce (kdyby tam byl, samozřejmně ho vyhazovat nebudu ).

[pavlix]

u serveru jsem proti čemukoliv mimo základní repozitář

Už jsem psal, že jsem používal balík z repozitáře distribuce. Žádný základnější repozitář už neexistuje.

a /boot separé na zvlášť partition či zařízení je obvyklá a nutná věc

I ty brepto.

Mimochodem, po mnoha letech mám zvláštní boot partition až teď na Gentoo, ale mám ji rovněž na LVM, abych neměl na disku bordel.

...ale u serveru jsem proti...

bo většinou je zbytek šifrovaný

Nejsem si vědom toho, že by většina serverů měla šifrovaný root filesystém.

kdyby tam byl, samozřejmně ho vyhazovat nebudu

V případě Fedory a Debianu, o kterých jsem psal, šlo jen o zvolení jiného bootloaderu než podporoval instalátor, popřípadě vytvoření jiného rozložení disku než podporoval instalátor. Že to není případ CentOS 6 je jiná věc.

[Šangala]

Jsi moc vztahovačný, dal jsem jako příklad hned v úvodu CentOS, ne tvou situaci a situaci serverů ne tvého NTB (jen a pouze odvozuji podle na „neměl na disku bordel“).

Vytrháváš věci z kontextu; je to nutná věc, pokud máš šifrovaný zbytek.

Znám několik serverů, které to tak mají a už u all-in-one vesele rozšiřuji jejich počet, protože to považuji nejednoduší a i nejlepší způsob.

[pavlix]

Kontext je především zde. Nemůžu ani za to, že sis to špatně přečetl (píšu tam, že je to běžné), ani za to, že píšeš nesmysly (že je samostatný boot nezbytný, že většina serverů či obecných strojů má šifrovaný root), ani za to, že si to bereš osobně.

[Šangala]

Ano, přesně tím to začalo.

Nepíšu nesmysly, ty se je snažíš z toho dostat zaměňováním spojek, či kvantitativních slov a zásadním zobecňováním „typů strojů“.

Nevím podle čeho jsi došel k závěru, že to beru osobně…

[Aleš Kapica]

Nemá cenu to vysvětlovat.

[Šangala]

Budu rád, když mi řekneš co.

[Aleš Kapica]

Proč je lepší používat GRUB2 než GRUB legacy.

[Šangala]

To opravdu nemá cenu vysvětlovat.

Normálně jej používám (Debian, Bubuntu) a využívám i jeho výhody, jen hlásím, že je do distribuce necpu (pokud není třeba a zatím nebylo), když tam není by-default (CentOS).

[Šangala]

Ha!, doposud jsem si myslel že Raid5 je právě nejvíc vhodný s 3-4 disky…

Čím Tě to tak děsí? …jo a tu peněženku beru… :)

[Ivan]

Ono to hodne zavisi na tom co doporucuje ktery vyrobce. Preci jenom se tenhle obor neustale vyviji a soucasny stav uz nema moc spolecneho s tim jaka teorie byla na zacatku. Napr. EMC doporucuje delat meta-LUNy nad skunami 5ti disku s RAID5 a ty potom sdruzovat do vetsich bloku. IBM zase doporucovalo udelat RAID5 pres cely shelf (tzn 12 disku v RAID5) a 13. jako hot-spare. S tim, ze rozdil mezi RAID 1+0 a RAID5 neni nijak vyrazny.

Kdyz ma pole spoustu RAMky zalohovane baterkou, a kdyz zapisy na disk tridi nejaky dedikovany kus kremiku tak uz davno v praxi neplati teorie, kterou nas kdysi ucili na skole.

[Šangala]

Ono to hlavně závisí na tom, jak jsou ta data a poli důležitá a jestli je pole redundantní, či jak dlouho lze vytahovat data ze záloh a jestli vůbec existují mimo to pole.

Jeden RAID5 nad 12 disky, byť s jedním spare, děsí zas mě a to dost a nemá to nic společného s křemíkem, baterkou ani velikostí RAM (na můj děs ta teorie naopak platí víc než dřív).

[mca]

Jak se to vezme, protoze obvykle se pouziva r5 ADG (Advanced Data Guarding) s volitelnym poctem paritnych disku. Kdyz to zacnes pocitat, tak vylezou cisla r5: 3 - 7x HDD, s ADG 4 - 12x.

[trekker.dk]

No, jestli to dobře chápu, tak tím se nedělá nic jiného, než že se ten velký RAID5 rozdělí ně několik menších RAID5, které se tváří jako jeden...?

[Šangala]

Prostě RAID50.

[pavlix]

Profesionál přece na třech discích používá RAID6.

[Šangala]

A navíc má jeden z nich jako „spare“!

[pavlix]

To už ovšem musí být ultraprofík.

[pet]

U jednoho zákazníka máme RAID5 na 3 discích (samozřejmě bez SPARE) v provozu 24/7 od roku 1999. Co je špatně? A kdy a kde půjdeš večer přes park s plnou peněženkou?

[Patvor]

Me umoznil pomoci zakaznikovi RaidReconstructor. Meli RAID 5 nad vice disky a hotspare. Selhaly dva disky a hotspare se nechytil. Pole tez ne. Po udelani kopii 1:1 ze vsech disku (ponechana vratka k profi reseni) se diky RaidReconstructoru data seradily za sebe na jeden disk a pomoci GDB sla zachranit cela. Tuto konfiguraci pole pak opustili.