Minden amit a merevlemezekről hittél

Hardver

Röviden, s finoman: téves. Két érdekes cikk is napvilágot látott az utóbbi egy hétben merevlemezek témakörében. Az egyik a Google berkeiből, a másik a CMU kutatóitól érkezett.

A Google közel 100 000 diszk életútja alapján végzett statisztikai elmezés során szerzett tapasztalatait közölte. Sok közülük eléggé meglepő.
Szemelvények:

  • Az MTBF amit a gyártók közölnek, teljesen haszontalan.
  • A SMART az esetek 36%-ában nem vette tudta előre jelezni a lemez halálát.

Link az eredetihez itt, link a kivonathoz itt.

A második cikk szintén jókora mennyiségű lemez adatait elemzi. Többek közt a los alamosi és a pittsburghi számítóközpontok adatainak felhasználásával készült. Az ő írásukban két kiemelten érdekes információ volt számomra:

  • Semmivel sem jobbak az enterprise lemezek (nem , a garancia nem számít. Az nem gépeli be újra szakdolgozatot).
  • A RAID5 rebuild alatti diszk vesztés esélye borzasztóan alá vagyon becsülve.

Link az eredetihez itt, link a kivonathoz itt.

( Toma_ | 2007. 02. 21., sze – 11:00 )

Sejtettem...
2 disk, no RAID, copy. Nekem tutira műxik ezer éve. :)

( Chain-Q v | 2007. 02. 21., sze – 11:08 )

Az MTBF amit a gyártók közölnek, teljesen haszontalan.

Es meg ha csak ezzel lenne baj, de tapasztalatom szerint az utobbi par evben, ugy altalaban a gyartok altal kozolt parameterek nagyresze - barmely hardverelem eseten - idealis esetekre, szelsoseges benchmarkokra, es marketingbullshitre, roadmapek eroltetesere, konstrukcios hibak elhallgatasara van kihegyezve.

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

( necrolite | 2007. 02. 21., sze – 11:22 )

Ami a SMART-ot illeti maximalisan egyetertek semmit nem fox belole elorejelezni, bar ehhez nekem 3 diszkhalal eleg volt es nem kellett hozza ennyi tesztalany sem ;o)

Ami a RAID5 alatti recovery diszkhalalt illeti mi anno ugy jartunk hogy berantotta a hot-spare-t ami kb 1 ora utan beadta a kulcsot... A RAID-vezerlo reduced modba vagta a tombot es full hutesre kapcsolt... A diszkek pedig csokkentett sebesseggel porogtek tovabb. A RAID elerhetetlenne valt (marmint a kiajanlott diszkek a szerverek szamara) majd a 2 diszk megerkezese utan rendesen helyreallt. Sajna 4 eves diszkek voltak a spare is 3 eve porgott a helyen. Egy csoro FAStT200 volt egy controllerrel es tuleltuk, de el kell a RAID6-ot adni ez mar laccik jonehany ceg PR-jabol evek ota (Netapp stb stb...) Noha a RAID5 nem a sziklaszilard teljesitmeny tehat azert arra sem lehet alapozni...

Lehet, hogy én emlékszem rosszul, de a hot-spare nem azt jelenti, hogy nincs dedikált spare disk, hanem mindegyik disk-en szabad marad annyi terület, ami együtt(-1) kiadja a spare disk méretét? Pontosan azért alkalmazzák ezt a megoldást, mert a dedikált spare disk-nél gondok lehetnek az évek múlva esedékes beindulásnál.

Ave, Saabi.

Ha kicsit belegondolsz, akkor nem biztos hogy igazad lesz. Pl. van RAID5: 3db merevlemezzel (spare disk nélkül). Az elméleted szerint mind a 3 hdd -ről fenntartunk annyi helyet, hogy az "kiadja" a spare diszket. Na mi van ha az elektronik elfüstöl vagy a fej legyalulj a a tányért az egyik vinyón, már nincs is 3 hdd -n, csak kettő. Szóval semmilyen helyet nem tartunk így fent, hanem ott figyel szépen a 4. hdd, azt meg ellenőrizni kell rendszeresen, hogy milyen állapotban van.
___________________________________________________________________
Lógnak a pálmafán a kókuszok .... :)

"Lehet, hogy én emlékszem rosszul, de a hot-spare nem azt jelenti, hogy nincs dedikált spare disk"

Nem. A "hot spare" az egy üres, készenlétben levő diszk, ami baj esetén be tud ugrani a RAID tömbből kiesett diszk helyére.

"Pontosan azért alkalmazzák ezt a megoldást, mert a dedikált spare disk-nél gondok lehetnek az évek múlva esedékes beindulásnál."

AFAIK a "hot spare" diszk az együtt "pörög" a RAID tömbbel. Ezért "hot". :)

--
trey @ gépház

Jogos, nem néztem utána. Amire én gondoltam az az "Active Hot Spare". :-)
Egy kis angol nyelvű okosság:
---
An active hot spare is differentiated from traditional hot spares in that rebuild space is distributed across all disks in the array for those disk arrays that provide active spares. This allows user data to be stored on a “spare disk,” which improves I/O performance. It also increases the amount of high performing RAID 1 space. In other words, the active hot spare disk is constantly undergoing writes and reads in order to verify that it is working properly.

In a traditional hot spare array, a defective hot spare disk may not be detected until it is actually needed. The integrity of the active hot spare is assured because it is kept in use at all times. Note that some disk arrays provide active hot spares although others do not.
---

A fentiek rávilágítanak arra a tényre, hogy a hot spare diskről csak akkor derül ki, hogy hibás, amikor használatba akarjuk venni. De akkor már egy kicsit késő.

Ave, Saabi.

Az esetek harmadat nem tudja elore jelezni, tehat nem lehet abban bizni, hogy ha a SMART nem jelez nem hal meg akarmelyik masodpercben a lemez.

Ebbol kifolyolag, mint teljes koru hiba elorejelzo rendszer hasznalhatatlan.
Azert mert van SMART nem hasznalhatsz kevesebb lemezt arra hivatkozva, hogy de van nekem ilyen hiba elorejelzom. Mert a hibak harmadat nem veszi eszre.
Rosszabb mint az orosz rulett. :)
Ott csak 1 a 6-hoz az esely az elso lovesnel. Itt 1 a 3-hoz.

( bervi | 2007. 02. 21., sze – 11:55 )

hahaha. én teljesen jó véleménnyel vagyok a hdd-kről, főleg mióta besült egy a gépemben :))

( uid_228 | 2007. 02. 21., sze – 12:50 )

A RAID5 rebuild alatti diszk vesztés esélye borzasztóan alá vagyon becsülve.

Különösen akkor, ha a RAID-vezérlő firmware-je a szar és nem a disk. :)) Nekem egy Adaptec 2400A így robbantotta széjjel egy RAID5 tömbömet - ofkorsz ment minden adat a levesbe (egyébként a hot-spare-nek semmi baja nem volt). Amikor utána a supportjuknak kurvaanyáztam, hogy "éseztígyhogy?", akkor egy sorryra futotta tőlük. :I

Azóta nem veszek Adaptec terméket és akit csak lehet, eltanácsolok tőle. FOSPUMPA.

--
Sokan nincsenek tudatában annak, / hogy egyszer mindenki meghal. / Akik ráébrednek erre, / azonnal abbahagyják az ellenségeskedést.

Te ezt biztosan alaposan megtapasztaltad a HP-nál, ugye? :)))))

Egyébként ez igaz, egyetértek. Csak éppen az volt itt a gond, hogy az adott terméknek pont az a funkciója nem működött, amiért megvettem: a hibatűrés. Az Adaptecnél valószínűleg ismeretlen fogalom a "graceful degradation". Ha nem bírja a tömböt optimális állapotba hozni, akkor legalább visítson, hogy "oltári gáz van és leállok". De ne verje szét teljesen, használhatatlanra, komplett adatvesztéssel. Ez minden, csak nem normális működési mód.

Különös tekintettel arra, hogy mindezt a hot-spare beépítésénél csinálta. Ergo az eredeti tömb maradék, jól működő lemezein az adatok még ott voltak sértetlenül.

Mindegy, nagy szívás volt, de tanultam belőle. Rendszeres mentés és elkerülök minden Adaptec terméket. Ha hardveres RAID és x86 kell, akkor 3Ware, LSI Logic, vagy Areca.

--
Sokan nincsenek tudatában annak, / hogy egyszer mindenki meghal. / Akik ráébrednek erre, / azonnal abbahagyják az ellenségeskedést.

"Te ezt biztosan alaposan megtapasztaltad a HP-nál, ugye?"

Nem, ezt még elötte tanultam meg, aktív rendszergazdaként. Mint ahogy azt is, hogy nem elég a backup, azt sem árt időnként megnézni, a restore megy-e. Kellemetlen meglepetés éles üzemben, amikor kiderül hogy a jól belőtt Oracle mentésem szart se ér, mert a fejlesztők - tudom, miért volt egyáltalán joguk hozzáférni az adatbázishoz - az erre kijelölt területeken kívül adtak az adatbázishoz egy adatfile-t. Ami így kimaradt a mentésből.
Amúgy meg, mivel nagyképű vagyok, úgy gondolom a RAID vezérlő kártya egy rossz vicc. Részemről az intelligens storage-okat vagy méginkább a JBOD-okat részesítem előnyben. De nem bízom egyikben sem. Csak a külön szalagokra egyidejüleg végzett és rendszeresen ellenőrzött backup-ban bízom.

Ave, Saabi.

Nem mindenki gondolkodik ám abban az árkategóriában, amiben te. :)

A szalag meg jó dolog, csak baromi lassú tud lenni. Én annak a híve vagyok, hogy egy dedikált, szintén RAID-es hostra mentek (pl. rsync-kel), aminek nem is kell 24/365-ben futnia, viszont fizikailag lehetőleg máshol van. Exta paranoia esetén lehet több ilyen gép is. :) Szalagra meg innét archivál az ember, azt, ami hosszú távra is kell(het). A kazettákat könnyebb elrakni a tűzálló páncélszekrénybe, mint egy több tíz kilós szervert. :)

--
Sokan nincsenek tudatában annak, / hogy egyszer mindenki meghal. / Akik ráébrednek erre, / azonnal abbahagyják az ellenségeskedést.

Szerintem vagy adatbiztonságról beszélünk vagy nem. Ha az adott adat fontos, akkor költeni kell rá. Ha nem telik Ultrium-ra, akkor DDS-re.
Amit leírtál, azt hívják two-stage backup-nak. Első lépésben valamilyen disk-re mentesz, utána szalagra. Ennek az a legnagyobb előnye - szerintem - hogy míg egy disk-re, egy filerendszerre több backup is mehet egyszerre, addig a szalagot egyszerre csak egy backup használhatja.
Vegyük például egy olyan helyzetet, amikor több laptopot kell rendszeresen mentened. A laptopok sajátossága, hogy hordozhatóak és ennek következtében csak akkor tartózkodnak az irodában, amikor a tulajdonosuk. Tehát rendszeres esti mentést nem tudsz ütemezni. Napközben ugyan elérhetőek, de tételezzük fel hogy dolgoznának rajtuk. Ráadásul nem lehetsz biztos benne, hogy mikor vannak egyáltalán hálózatközelben. Magyarán semmilyen idő szerint ütemezett backup nem jöhet szóba. Kialakult egy olyan mentési feladat, amiben több kliens, jórészt megjósolhatatlan módon, össze-vissza kezdeményezhet mentést. Ilyen helyzetben vagy lokális szalagegység lehet a megoldás - ami azért manapság nem standard tartozéka a laptopoknak -, vagy a disk-re mentés. Ez utóbbi esetben nem probléma, ha egyszerre akár húsz backup session fut egyszerre - mondjuk mert mindenki ugyanakkor éhezett meg és ebédidőben inditott egy mentést - a disk bírja. Éjjel vagy hajnalban pedig ki lehet írni ezeket a mentéseket szalagokra, hogy a páncélszekrény is kapjon valamit.

Amúgy létezik olyan, hogy Virtual Tape Library. Ez egy olyan eszköz ami tape-t, library-t emulál, de valójában disk-re, disk tömbre dolgozik.

Ave, Saabi.

Ultriumra -- meg a 3 éves Care pack-re, mert ugye az alatt nagy az esélye, hogy megpunnyad... :-P

Azt kell mindenkinek megértenie/felfognia, hogy a RAID is másra szolgál, meg a backup is. Hiába van RAID-1024 -ben a kupac diszk, ha mondjuk megfut az egyik táp, és halomra gyilkolja a diszkeket, és hiába van mentett kazetta egy héttel ezelőttről (merthogy elég hetenként menteni), ha az utcsó héten keletkezett adatmenyiség értéke sok-sok sestertius, és nincs lehetőség a pótlására. Szerintem...

Szerintem éppenhogy ugyanazt a célt szolgálják. Úgy a RAID tömb, mint a backup egy esetleges HW meghibásodás következtében fellépő adatvesztés ellen való. Jó, a backup védhet egy esetleg agylágyulás következtében történt adattörlés, felülírás ellen is. :-)
Ellenben nem való egyik megoldás sem arra, hogy megtudjuk, milyen adataink voltak fél, egy, három, öt évvel ezelött. Mert ezt már archiválásnak hívják és más eszközöket igényel mint a backup vagy a RAID. (pl. lézergravírozott márványtábla)

Ave, Saabi.

Arra gondoltam, hogy a RAID a rendszer egészének a rendelkezésre állását növeli (vagy balf...sz módon használva/kezelve csökkenti (talán mattise-nak "hívták" azt a HP-vasat, aminek a rootdiszkje tükrözött vala, és azóta is jót kuncogok a diszkcsere post mortem jelentésén, ha rá gondolok...)), a backup meg az adatokét. Attól, hogy van az egyik, még kell a másik, és viszont, azaz hiába van raid-ed, kell a backup, és hiába van backup-od, a raid-et azért "érdemes" használni.

Röhögni fogsz, de a teljesítménye is olyan volt, amire inkább nem írok jelzőket. 4 lemezes RAID0 tömbbel (teszt) is csak 13 MB/s körül volt képes olvasni.

--
Sokan nincsenek tudatában annak, / hogy egyszer mindenki meghal. / Akik ráébrednek erre, / azonnal abbahagyják az ellenségeskedést.

( asch v | 2007. 02. 21., sze – 17:36 )

Ehhez képest a HUP-on nincs olyan kategória, hogy backup... Sőt, interneten rákeresve szinte mindenről több információt találni, mint hogy hogyan érdemes megoldani egy akármilyen rendszer backupját.

Így backupolunk mi:

A rendszer: egy központ, 12 alegység szétszórva 2 megyében.
Mindenhol fix_ip, adsl.

Az archiválandó dolgok tömörítve fölballagnak a központba,
egyúttal egy dátumstemplivel félre lesznek dobva helyileg is.
A fölküldött adat a központban kicsomagolódik és megy a központi
adatbázisba, illetve összecsogaolva, származási hellyel és
időstemplivel az archívumba.

A központi adatbázisról - tehát az összes alegység egyesített
adatairól - szintén külön archívum készül: hétfő, kedd, szerda...
és így tovább. Tehát 7 nap van arra, hogy észrevegyük a zűrt.

Az egyes archívumok fizikailag elkülönített gépeken várják,
hogy vész esetén előkotorjuk őket. Több évre visszamenőleg
képesek lennénk tetszőleges napi állapotot előállítani.

A nagyon régi anyagok közül csak a kritikus időpontban
keletkezetteket (pl: évforduló) hagyjuk meg.

A lényeg: rendszeres backup, fizikailag több helyen, a friss
backuppal pedig nem írjuk felül a régit.

Mindenhol GAGYI_PC van, 2-3 évenként cseréljük őket.
Adatvesztés eddig nem volt, minden archivumba_keresési
igényt ki tudtunk eddig elégíteni.

Meglepő, hogy milyen kevés a hiba. Szidjátok a vinyókat, én
viszont csodálom: egy tenyérnyi helyen MECHANIKUSAN
előbányászhatóvá tesz egy korábban rá írt információt.

> Sol omnibus lucet.

annyi még: a helyi szervernek van egy tükre. Erre a célra mindig
az előző szerver_széria kifutó gépeit használjuk. Ez a tükör
időre ébred, fölmontulja az új szerver megfelelő könyvtárát,
készít róla egy másolatot és lehaltol.

Ez arra jó, hogy, ha az új szerver kidől, akkor azonnal folytatni
lehet a munkát a régi szerver bekapcsolásával.

> Sol omnibus lucet.