RAID tömbök karbantartása

Linux-haladó

Sok téma van már hw/sw raid-ek létrehozásáról, hibaelhárításáról - mikor már megtörtént a baj - de ki hogyan üzemeltet, tart karban kisebb-nagyobb raid rendszereket?
Engem elsősorban a "kommersz" eszközökből felépített software raid érint, de info szinten érdekelnek a komolyabb megoldások is.

Ami miatt ez konkrétan felmerült: 7/24-ben üzemelő raid5 tömb, ~2TB adattal, 3 éves hdd-kkel. Egyesével újakra cserélném a winyókat, mert szerintem ezek már eleget mentek, nem várnám meg, míg kipurcan. Hogyan oldható meg minimális leállással, maximális biztonsággal? Amik felmerültek:
- leállás alatt 1 disk dd az új hdd-re, átszerel, start - így min. 1 napig áll a rendszer, míg a dd lefut.
- 1 disk kirúgása a raid-ből, leáll, csere, resync - így min. 1 napig nem biztonságos a tömb, ha sync alatt hibázik egy disk, széthullik az egész.

Spare disk jelenleg nincs, de ha lenne és úgy "rúgok ki" egy disket a tömbből, gyakorlatilag akkor is a 2. verzió játszódik le.

1. kérdés: hogy lehet menet közben egy új disket beszinkronizálni egy teljes tömbbe úgy, hogy az utána egy adott régi disk helyére azonnal beállhasson?

Persze, első körben a fenti 2. megoldást választottam a probléma áthidalására, ami - természetesen - sync közben talált is hibát egy másik lemezen, valószínüleg olyan helyen, ahova napi használat közben nem nyúlt, így menet közben nem bukott ki.

2. kérdés: hogyan lehet - és érdemes-e, szoktátok-e - egy ép(nek tűnő) tömb szinkronizációját a diskek teljes hosszűn ellenőrizni annélkül, hogy hiba esetén azonnal szétdobmá a tömböt?

...és persze jöhet az összes témába vágó gyakorlati üzemeltetési tapasztalat:
pl. mennyi időt szabad adni egy disk-nek, mennyi után érdemes cserélgetni?

  • 7574 megtekintés

( wpeople v | 2010. 12. 24., p – 11:25 )

workaround 2TB tömbnél: lemented az egészet egy 2 (esetleg 3) TB lemezre?

Mivel nem sok konkrétumot írtál, így nehéz válaszolni, de mivel ennyire apró adatállományról van szó (2Tb), lehet, hogy az lenne a leggyorsabb, ha vennél 2x2T vinyót áthúznád mind a kettőre, aztán cserélnéd a tömböd vinyóit majd visszamásolnád. Tudom paraszt megoldás, de néhány óra alatt megvan.
+ Maradna 2 tartalék vinyód amiből lehet spare vagy hideg tartalék.

Konkrét karbantartást konkrét konfiggal lehetne csak mondani.

Ez most konkrétan 4x750GB sw raid5, no spare, egy "mezei" 4 portos sata csatolóval.
Mivel láthatóan "low budget" megoldásról van szó, ezért +2db ideiglenes disk (+1 csatoló, amire rá tudom kötni) workoround extra költségvetését nehézkesen nyomnám le a főnököm torkán (még a "cseréljünk egyenként lemezeket, mielőtt megdöglenek" dolog sem megy simán)
Másrészt a raid felett lvm van, így max, pvmove-olni tudnám az egészet, de az megint nem 1-2 óra.
Nem hinném, hogy nincs már megoldás, mint X óra/nap leállással lementeni az adatokat és visszatölteni egy komplett új tömbre.

Baszki most fölszívtam magam... Mit tartotok azon a tömbön divix videokat meg empéhármakat meg xxx videokat???
Mert akkor tényleg tökmindegy... Ha elvész akkor run torrent és három-négy nap alatt megvan újra.

Ha fontos adatokat, akkor ne néhány tízezres vagy százezres tételen spóroljatok már.

(ez a bejegyzés a főnöködnek szólt)

gondolom, te sem kis cégnél dolgozol! :)
Ha nem kéne spórolni pár 10/100 ezreken, akkor én sem kommersz eszközökből épített sw raid-et használnék.
Amúgy, ha már plusz disk, akkor lehet, hogy inkább migrálnék raid6 + spare-re és utána dobnék ki egy régi disket (vagy akkor már nem is, maradjon csak, míg ki nem múlik)
(a szervergépben levő fizikai hely korlátai - avagy több disket állandóra nincs hova rakni - már csak a hab a tortán)

( lazly | 2010. 12. 24., p – 12:24 )

Hulye otlet, kivitelezest meg vegig kell gondolni, de:
Csinalsz 4 darab raid1et egy diskel, azt rakod raid5be, es a raid1ekbe rakod az ujjat es veszed ki a regit. Ha uj konfigrol lenne szo tuti menne, benchmarkot nem tudom mennyiben modositana a plusz egy layer, erdemes lenne kimerni. A meglevo konfig ilyenre atfaragasat igy hirtelen nem tudom hogy csinalnam annelkul hogy az eredeti problema nem jon elo.

Varians 2: Veszel megegy mezei sata kartyat (5 ezer forint, az uj diskek melle belefer), ra a 4 uj disk, uj raid5, (cp v mv), regi raid5 kill.

Boldog bejglit!

-------------------------------
"A gorog katolikus noknek 8 dioptria alatt nem kotelezo a bajusz!" avagy "Nozni csak muholddal lehet..." | http://lazly.hu

Most latom lvm van. Akkor megjobb, nem cp hanem pvmove mint irtad is es mehet a moka s kacagas! :)

Szerintem mar a raid5 is kicsit sok egy softraidhoz nemhogy a raid6, de ha nem teljesitmeny kritikus az IO akkor vegulis miert ne.

-------------------------------
"A gorog katolikus noknek 8 dioptria alatt nem kotelezo a bajusz!" avagy "Nozni csak muholddal lehet..." | http://lazly.hu

( tovis v | 2010. 12. 24., p – 13:05 )

Csak suttogom, a RAID1 - esetleg ha annyira fontos a sebesség akkor RAID10. Az LVM -nek akkor van értelme (szerintem) ha később bővíteni/csatolni akarsz, minden másra az mdadm is elég.
Egyébként, nem tudom milyen diszkjeid vannak, a három év az ck. 26.280 óra - az átlagos diszkek, átlagos meghibásodási ideje 100-150 ezer óra (MTBF) - feltéve ha nem kapcsolgatod ki/be, ami a szerverekre jellemző.
RAID1 -en simán másoltam a sfdisk kimenetét egy szűz diszkre, bedugtam, hozzáadtam és a szinkronizációt "páholyból" figyeltem. Ami nagyobb meglepi, valószínű egyedi probléma, hogy a lecserélt diszk író/olvasó ellenőrzése, formázással több mint 24 órát vett igénybe :( nem mutatott ki semmilyen hibát.

* Én egy indián vagyok. Minden indián hazudik.

( dap | 2010. 12. 24., p – 13:41 )

> 2. kérdés: hogyan lehet - és érdemes-e, szoktátok-e - egy ép(nek tűnő) tömb szinkronizációját a diskek teljes hosszűn ellenőrizni annélkül, hogy hiba esetén azonnal szétdobmá a tömböt?

Nem hogy érdemes, hanem RAID5 esetén egyenesen kötelező.

A Debian automatikusan ellenőrzi ha az AUTOCHECK=true az /etc/default/mdadm fájlban, így: 

 /usr/share/mdadm/checkarray --cron --all --quiet

Ez a script lényegében ezt csinálja: 

 echo check >/sys/block/md?/md/sync_action

Ha olvashatatlan, pending szektorra fut, akkor a többi diszk alapján újra fogja írni a szektort.

Ha több diszked lenne, akkor érdemesebb volna rendszeresen SMART long selftestet végezni (mert az nem passzírozza át a buszokon az adatokat), de most a hagyományos media check egyszerűbb.

> pl. mennyi időt szabad adni egy disk-nek, mennyi után érdemes cserélgetni?

Én speciel nem vagyok híve a cserélgetésnek, mert az életkorral nem egyenes arányban szaporodnak a problémák, sőt, azt mondanám, hogy nem sok köze van hozzá. Kb 4 év után gazdasági megfontolásból szoktuk cserélni, addig teljesen random hal meg újabb és öregebb is.

( mekrisz | 2014. 07. 25., p – 16:05 )

Sziasztok!

A segítségeteket szeretném kérni. Olyan problémába ütköztem, hogy volt 3 lemezes RAID-5-öm, hozzáadtam egy negyedik lemezt fél éve, megy is minden rendesen, partíció méret felnőtt, ahogy kell, meg minden oké.... viszont most szükség lenne az egyik lemezre ( mert úgysem használom a teljes kapacitást ), de nem tudom, hogyan kell a 4 lemezes RAID-5-öt "lecsökkenteni" 3 lemezesre adatvesztés nélkül ( természetesen van elég szabad hely a művelet végrehajtására a tömbön belül ).

Valaki tudna nekem segíteni, merre keresgéljek, hogyan induljak el? (azt tudom, hogy 1,5-2 napos művelet lesz, a felnövesztés is kb annyi volt ) , jaj igen, és a legfontosabb - Szoftveres RAID-5-ről beszélek Ubuntu 14.04 LTS alatt.

maximusz

ezt értem, és így is csinálnám, ha lenne kellő tárhely ( 4 db 2 TB-os winyóról van szó, ha megengedhetném magamnak, hidd el vennék ugyenennyi diszket és fel sem tettem volna a kérdést ). Azt tudom, hogy nővelni lehet ( újabb lemez hozzáadásával ), de csökkenteni is lehet ( lemez elvételével ) realtime ?

Az a parancs érdekelne, ami ezt megcsinálja . Tudom, hogy sokáig el fog vele kerregni, de szükségem lenne rá...

Miután ellenőrizted a működő backupot...
resize2fs-sel (vagy a filerendszerednek megfelelő tool-lal) csökkented a filerendszer meretét,
mdadm --grow --array-size=N /dev/mdX -szel csökkented a tömb méretét, hogy elférjen később 3 diszken,
mdadm --manage --fail /dev/mdX /dev/sdY -nal kijelölöd, hogy melyik diszket fogod kiszedni,
mdadm --grow /dev/mdX -n 3 -mal átalakitod a tömböt 3 lemezesre, majd (ha szükséges) ismét átméretezed a tömböt majd filerendszert, hogy a teljes rendelkezésre álló területet használja.
Mielőtt élesben futtatod, csinálsz egy raid tömböt négy filera (-> loop device) és ott lepróbálod, hogy működik-e így :)
Ha sikerült, pl smartctl-lel megnézed hogy mi az eltávolítandó diszk tipusa, sorszáma, nehogy a raid tömb alól húzd ki.