Raid ure gyakorlatban

Merevlemezek, vezérlők

hali. Olvastam elmeleti dolgokat arrol, hogy a nagy driveok eseten a RAID5 rebuild eseten 100% a failure. Ez nekem hihetetpennek tunik, ezert szeretnem megkerdezni azokat, akik hasznalnak raideket, hogy ez mennyire valos. Nekem csak home NASban van raid 6, 16 TB diskekkel, es a terv hogy addig hasznalom a diskeket amig ki nem novom vagy meg nem doglik(SMART warningot is ide ertve) + backup mashol, de most mar azt is olvasom hogy a raid 6 sem eleg jo, elmeletileg. tenyleg? ez hogy raid 6 vagy akar 5 a rebuild soran 100%ban meghal, ez valoban igy volna?

  • 835 megtekintés

( zeller | 2022. 08. 28., v – 13:45 )

16TiB diszk arra jó, hogy k. sok adatot tudj k.gyorsan elveszíteni. A RAID5 mentés nélkül orosz rulett: egy döglött diszk esetén amíg nincs kész a resync, semmilyen redundancia nincs, egy újabb diszk elvesztése egyenes út az adatok elvesztéséhez. A rebuild-hez meg a maradékot végig kell olvasni, és az új diszkre a megfelelő (checksum, illetve checksum+data-ból visszaszámolt data) blokkokat ki kell írni. Ha kellően okos a raid-megoldás, akkor csak a használt blokkokkal foglalkozik - ha nem, akkor mindennel _is_.
RAID 6 esetén egy diszk esetén no para, a második checksum blokkok még ott vannak, ha egy másik diszk is feldobná a talpát - viszont a resync itt is retek sok olvasást és az új diszk írását jelenti.

Keresztkérdés: a 16TiB méretű diszket ha csak szimplán tele szeretnéd írni, az meddig tart? Igen,pontosan: sokáig. Sőt nagyon sokáig. RAID-et már ezért sem kevés és nagy diszken célszerű építeni (A Ft/TB mellett ugye...), hanem inkább több, kisebb diszkből. Több tengely gyorsabban szolgál ki, baj esetén a rebuild is hamarabb elkészül - mindamellett olcsóbb is lesz ugyanakkora tömb.

hello, köszönöm a választ

én azt tudom, hogy a rebuild eseten a masodik diszk meghalása gond. de a claim az, hogy az esetek 100%-ában nem fog mukodni a rebuild. Hát amikor a 8 terramat atmasoltam a 16osokra, az mondjuk lehetett 1 vsgy 2 nap, nem tudom, könyvtárankánt másoltam, na de NAS-rol másik NAS-ra. A kérdésem, hogy ez amit itt kapok,hogy 3 db 12 terras disk eseten a sikeres rebuild eselye 15% az valos-e

https://magj.github.io/raid-failure/

Backup alá legutóbb maximum 12T-s diszkekből mertem RAID6-ot építeni, és itt már két külön gyártótól kértem a diszkeket, pedig ezzel eddig különösebben nem foglalkoztam. :) Ez sima MDADM alapú és 2+ paritás diszkes opciót egyelőre nem találtam, pedig nem ártana. A vicc az, hogy ha építesz egy mittom 100T-s valamit, akkorarról egy hasonló (vagy kevesebb, de nagyobb diszkes) mentést tudsz csinálni, de az minimum nem lesz realtime, ha sok adat érkezik a tömbre. Oké, lehet olyat is, hogy 52db 2T-s diszkből, de ezt valahogy nem érzem életszerűnek, még a 4-6T-set sem, fizikailag sem egyszerű ilyen megoldást találni, vagy néhány fényéves körzetben felszippantja az ájti büdzsét. :)

( vasla_ | 2022. 08. 28., v – 14:34 )

Olvastam elmeleti dolgokat arrol, hogy a nagy driveok eseten a RAID5 rebuild eseten 100% a failure

 

Évekkel ezelőtt megjelent egy cikk a és a  HDD-k adatlapján lévő Bitrate error (BER) alapján kiszámolták , hogy a legtöbb lemeznél megadott 10e-14 BER , az úgy 10 TBájt. Vagyis egy 6 terrás lemezt nem tudsz kétszer teleírni,  hiba nélkül, Raid-ben pedig nem lehet újjáépíteni, csak nagy szerencsével. Sok link is készült erről, percek alatt találhatsz egy csomót:

https://www.zdnet.com/article/why-raid-5-stops-working-in-2009/

2019-ben még mindig ez a helyzet:

https://www.digistor.com.au/the-latest/Whether-RAID-5-is-still-safe-in-2019/

Vagyis ezek a lemezek nem jók sem raid5 -ben sem raid6-ban való használatra.

A hiba ott van , hogy rosszul okoskodnak a BRE értelmezéséről. Májerek irják hogy elfelejtik , hogy az adatlapokon nem egyenlő, hanem  nagyobbb mint 10e-14, illetve értelmezheted akár egyetlen szektorra is, illetve ez észlelt hiba, amit a lemez javítani tud, akit érdekel utánannézhet a BER vs UBER -nek.

Raid 5 vs Raid6: Ha van lehetőséged inkább használj raid6 -ot, egyformán öregedő lemezeknél nagyobb biztonságban vagy a 6-tal, szétszedett gépnél rebuild alatt elég egy kábel leesés, de azért teljesen használhatatlannak nem mondanám.

https://blog.claryel.hu

köszi a választ, pont a fenti cikkek miatt kérdeztem, mert ismét a calculator linkelve

https://magj.github.io/raid-failure/

ez azt allitja hogy 3 db 12 terras disc eseten meg raid 6 eseten is csak 47% a sikeres rebuld eselye, ami nekem total hihetetlennek tunik. meg a 2%ot is sokank tartanam (hacsak nem az azonos oregedes miatt)

Hát a gond alapból az, hogy 3 db HDD-ből nem lehet RAID6-ot építeni, és ha erre nem figyelt a kalkukulátor készítője, akkor felmerül bennem a kérdés, hogy mi mindenre nem figyelt még.

A másik, hogy RAID6 esetében nem derül ki, hogy a sikertelenség alatt azt érti, hogy elveszik a tömb, vagy azt, hogy rebuild közben kell egy újabb diszket cserélni.

Az elmélet az, hogy nincs mőd űjraépiteni, sehogy, 12 Tera fölött.

Az alapja ez az állítás: 

10**14/1024/1024/1024/1024/8=11.4 Terabájt. Egíy sata lemez ennyit tud írni/olvasni bithiba nélkül.

PL wd red pro adatlap:

 

Reliability/Data Integrity

Non-recoverable errors per bits read <10 in 10**14 

https://documents.westerndigital.com/content/dam/doc-library/en_us/assets/public/western-digital/product/internal-drives/wd-red-pro-hdd/data-sheet-wd-red-pro-idk.pdf

https://blog.claryel.hu

Hát, ez a WD-s adat eléggé elkeserítő, mert azt mondja, hogy 12.5 TB-nyi olvasásonként kevesebb mint 10 (nem 1!) URE bit hiba lesz... Az azt jelenti, hogy 1.25 TB-onként kevesebb, mint 1 bit URE... Egy NAS meghajtónál.
Ráadásul a vadi új 22TB-os modellre is ugyan az van megadva, hogy URE <10 in 10^14, tehát tényleg egyszer sem lehet végigolvasni URE nélkül a gyártó állítása szerint a 2TB-nál nagyobb modelleket.

Ezzel szemben a Seagate IronWolf (és ~ Pro) modellekre 1 URE per 10^15 bit olvasás (125 TB-onként egy bit URE) van megadva, az óriási nagy különbség ígért hibaarányban, nagyjából azonos pénzért.

Ez a 10 csak a wd-nél van, minden más sata hdd  1/10**14, sas-lmezek 1/10**15 gyakorlatilag szabvány ez a két szám.

Azt hogy mit jelent nem tudom, minden cikk tele van feltételezéssel pro és kontra, meg Buddha szavaival. 

https://blog.claryel.hu

kevesebb, mint 1 bit URE... 

Itt egy picit pontosabban meg kellene nezni hogy mire gondolt a kolto mi van a leirasban mert olyan/olyasmi hogy "1 bit URE" nem igazan van a blokk-jellegu forward error correction code-oknal. Te tudsz definialni egy alaphalmazt (code word hosszusagot), teljes leirt hosszt es teljes informaciomennyiseget. Egy ilyen blokk az vagy helyreallithato (mert vagy teljesen jo vagy annyira keves code word - bit, byte, ... - hibas hogy helyreallithato). Vagy nem, mert tul sok benne a hiba, de akkor biztos nem 1 bitnyi URE-d van hanem rengeteg. Extrem esetben annyira serult is lehet egy blokk hogy mar a helyreallitott informacio mar egy masik valid code word-re mutat. (Vagy hasznalhatunk un. perfect code-okat, de ott ugye mindegyik serultnek latszo bitkupac szarmaztathato valahonnan, igy az tkp nem az igazi a gyakorlatban :))

De hogy "1 bitnyi javithatatlan hiba" lenne valamiben az abszolut nem gond: mar a legeslegegyszerubb blokk-jellegu hibajavito kodok (Hamming, extended Hamming) is annyira immunisak 10^-12-es valoszinusegu korrelalatlan egyedi bithibara hogy a gyakorlatban nem fog feltunni, es mondjuk 10^6-10^7 teljes felolvasas kellene ahhoz hogy legyen egy darab URE esemenyed. 

Emiatt nagyobb gubanc altalaban akkor van ha lokalizalt a hiba (burst jellegu) es olyan a blokk-jellegu kodunk hogy nincs benne szandekos permutaltsag es/vagy nem kombinaljak konvolucios kodokkal es/vagy nem egymasra epulo blokk kodok vannak (pl egy Reed-Solomon kodolast nem byte-okra, azaz GF(2^8)-ra epitesz fel hanem mondjuk GF(2^11)-re, ahol a 11 bitnyi codeword hosszusag eleve egy (16,11,1)-es Hamming kodbol jon). 
 

Mondjuk, hogy nagyjából értem amit írtál. De én csak abból tudok főzni, amit a gyártó az adatlapon megad. Ott pedig az szerepel, hogy mennyi bit olvasásán belül garantálják (tippelik), hogy nem lesz 1 bitnyi (WD terminológiában kevesebb mint 10) javíthatatlan olvasási hiba. A RAID vezérlő meg mikor azt hallja a HDD-tól, hogy javíthatatlan olvasási hibába futott, akkor jellemzően elköszön tőle. Szóval laikusoknak ez az összevetési lehetőség van (pontosabban az én ilyen irányú, szűk tudásomon belül).

Én még nem találkoztam (lehet nem kerestem eléggé) olyan leiratokkal, amiben részletezik, hogy milyen algoritmussal, milyen blokkmérettel fut az adott HDD-n a hibajavítás, és átlagosan milyen eredménnyel. Ezért feltételezem, hogy ennek ismeretében és tesztelése során alakul ki a "1 bit hiba a 10^15 bit olvasásból" meg a "kevesebb mint 10 bit hiba a 10^14 bit olvasásból" adat az adatlapokon.

"A RAID vezérlő meg mikor azt hallja a HDD-tól, hogy javíthatatlan olvasási hibába futott, akkor jellemzően elköszön tőle."

Vezérlő lehet. Linux-os soft RAID biztos nem, legalábbis nem rögtön tapasztalatom szerint, ZFS-nél pedig még ennyire sincs ez így. Legrosszabb helyzet egy 2 lemezes R1 volt, a ZFS vígan elvolt vele, egyik már félholt volt, a második pedig épp kezdett haldokolni. Simán lejött minden adat róla.

( arpi_esp v | 2022. 08. 28., v – 14:36 )

Szerkesztve: 2022. 08. 28., v – 14:41

volt itt egy topic talan ugy fel-1 eve arrol hogy az ujabb hdd-ken 2 fele tarolas van, egyik kisebb de gyorsabb a masik resze lassabb. ezt a raid vezrelok nem szeretik, mert iraskor ha a gyors resz megtelik akkor sokat kell varni es timeoutolhat, ami miatt a vezerlo kidobja a disket a tombbol. ez normal hasznalat kozben ritkan jon elo de resyncnel 100% hogy belefutsz. lehet erre gondolt a kolto?

meg is van:  https://hup.hu/node/168856

( dotnetlinux | 2022. 08. 28., v – 21:48 )

Offtopic: huh, nem gondoltam volna hogy manapsag van ilyen az IT-ban, hogy biztos nem fog sikerulni egy 10+ TB raid mukodtetese. Hogy csinaljak azok akik velhetorn tobb 100TB-on adnak kisebb tarhelyeket, vps stb? 

100TB manapsag kicsi, inkabb beszeljunk a PB-okrol...

nem sima raidet hasznalnak, hanem
* valami elosztott storageot (Ceph, peldaul)
* sok fele szetszedett EC-t nagyon sok diszken, gyartoi megoldasban (itt egy IBMes: https://barrywhytestorage.blog/2020/01/09/some-details-about-how-draid-…)

ha sok diszked van, nem erdekel az, hogy egy meghal.

persze ha osszesen 100TB kell, akkor ne rohanj a boltba venni 5db 20TB-osat :-)

Nincs olyan hű de sok elönye . Én is a nagyobbat válsztanám. Ha a fogyasztását nézed akkor mondjuk 36 watt vs 108 watt. Jobb a szekvenciális irás olvasás, de hat lemezzel is kitömöd a GIGAbitet.

Random I/0-ra meg meg gyenge minden felállásban a HDD.  Hat lemezhez elég az alaplapi SATA , netán ECC  ram és ZFS és van egy nagyon  jő tárolód, alacsony költséggel.

https://blog.claryel.hu

Erre a BER/UBER 10**14 dologra , csak ismételni tudom,  a mérés leírását , értelmezését SEHOL nem láttam, csak találgatást, de a dolog egyszerű.

Ha a hiba a lmez egyszeri olvasásánál(10**14) ,  előjönne, akkor MINDEN raid tömb  5-6 TB-tól használhatatlan lenne. Erről csak tudnánk. 

Egy 30 TB-os raidet ha kell 25x újjáépítek- volt aki ki is próbálta, gond nélkül.

https://blog.claryel.hu

ezt lattam: https://www.qnap.com/en/how-to/faq/article/can-i-add-an-individual-disk…

 

na most ha jol ertem amit kuldtel, akkor mondjuk letre hozok egy raid 6ot 4 diskel, az 1 vdev, utana letre hozhatok egy masik raid 6ot 4 masik diskel, azeg egy vdev, es akkor van 6 disknyi helyem, de en a meglevo raidhez szeretnek hozza adni meg egy 5. disket, de ha jol ertem azt nem lehet.

( Protezis | 2022. 08. 30., k – 14:55 )

Ironwolf-oknál talán 8TB-tól 10^15 az URE. Aki a kisebb kapacitás mellett érvel, az itt pont rosszul teszi.

Bár az URE a legrosszabb forgatókönyv (statisztikailag), én emiatt is nem egy 4. 4TB-os lemezzel bővítettem a tömbömet, hanem kicseréltem 2 diszket 12TB-osra (Synology SHR).

( elod v | 2022. 08. 30., k – 16:07 )

Home NAS, 16TB-os lemezzel... UR(E)i probléma :D. Otthon még régi 4TB-os lemezekből építkezek.