RAID6 failure met 12 schijven

[yourservice]

Op mijn PC heb ik een RocketRaid 3530 met 12 * WD20EARS. Bruto 24TB en netto 20TB dus.

Sinds een paar weken is de array alleen maar aan het rebuilden geweest.

Inmiddels staan 2 schijven op vlammen/slotje:



Rebuilden is inmiddels op 56% maar de laatste 6% heeft ie al net zoveel dagen over gedaan.



De event laat voornamelijk dit zien totdat ie niet meer kan en begint te piepen, op dit moment schijf 5 eruit gooit en na een rescan weer doorgaat:



Inmiddels de error bij HighPoint aangemeld (binnen de garantie) maar die geeft de schuld aan de WD schijven.

Inmiddels de 2 "kapotte" schijven aangemeld bij WD (ook binnen de garantie) en voor $ 180 per stuk 2 vervangende schijven opgestuurd gekregen, dit geld krijg ik terug als ik binnen 30 dagen de kapotte schijven retour stuur maar het rebuilden kan nog wel eens 30 dagen gaan duren plus dat ik niet weet wat er daarna gaat gebeuren.

Zoals je kunt zien in de event zijn schijven 2, 3, 5, 9, 10 en 12 inmiddels verdacht.

Er staat zo'n beetje 18TB aan data op van de 20TB die ik ter beschikking heb, is dit teveel aan data?

Op een andere PC heb ik een RAID 5 draaien met 12 1TB schijven van Samsung, ik ga toch maar weer terug naar dit merk.

Iemand tips, trucs, advies?

[jimmy87]

Tja een RAID-6 met die schijven inderdaad lang kunnen duren. WD20EARS zijn vrij langzame schijven en eigenlijk niet bedoeld voor in een RAID controller. ( aan den lijve ondervonden ).

De data zelf zou niet uit moeten maken wat betreft het rebuilden, op de HP controllers die wij hier hebben duurt 20TB RAID-6 rebuilden ongeveer 3 dagen maar dat is wel met Hitachi schijven.

[Kippenijzer]

Hoe vervelend ook om te horen: grote SATA arrays waarbij teveel disks falen tijdens de rebuild zie je helaas vaak. Ik vrees dat je, als je data je lief is, je de rebuild het beste kunt pauzeren (indien mogelijk), geld uitgeven aan enkel grote disks en zsm alle belangrijke data buiten je array opslaan. Raid != backup, je leest het overal. Pijnlijk om dat op deze manier te moeten ervaren natuurlijk...

[4POX]

Een stel hackers hebben mij ooit uitgelegd dat raid beter niet boven de 12 GB kan uitkomen. Daarboven neemt de kans door corruptie zo erg toe omdat de foutcorrectie van de hardeschijf het niet meer kan bolwerken.

[Wceend]

4POX schreef op maandag 11 februari 2013 @ 14:11:
Een stel hackers hebben mij ooit uitgelegd dat raid beter niet boven de 12 GB kan uitkomen. Daarboven neemt de kans door corruptie zo erg toe omdat de foutcorrectie van de hardeschijf het niet meer kan bolwerken.

ik hoop dat je TB bedoeld ipv GB

[timberleek]

Die schijven zijn niet geschikt voor zo'n hardware raid controller.
Met dergelijk grote schijven is de kans op leesfouten redelijk groot (dat is normaal), echter is een hardware raid controller ontzettend streng.
De ears schijven hebben geen TLER meer waardoor ze bij een leesfout ruzie gaan maken met je controller. Voor TLER (dat wil je voor hardware raid) moet je black of red schijven kopen.

Samsung is voor zover ik weet echter weg van de HDD markt. Is allemaal opgekocht. De pricewatch heeft ook enkel nog oude schijven in een handjevol winkels

[_Dune_]

Precies dit...

timberleek schreef op maandag 11 februari 2013 @ 15:31:
Die schijven zijn niet geschikt voor zo'n hardware raid controller.
Met dergelijk grote schijven is de kans op leesfouten redelijk groot (dat is normaal), echter is een hardware raid controller ontzettend streng.
De ears schijven hebben geen TLER meer waardoor ze bij een leesfout ruzie gaan maken met je controller. Voor TLER (dat wil je voor hardware raid) moet je black of red schijven kopen.

De RED en de RE hardeschijfen van Western Digital schijn geschikt voor (hardware)RAID-controllers. Precies om TLER zoals WesternDigital het noemt, andere fabrikanten kunnen er een andere benaming voor hebben. Het komt er op neer dat de hardeschijf zelf maar beperkt fouten probeerd te corrigeren en dit sneller aan de RAID controller overlaat dan "desktop"-hardeschijfen.

Ik weet niet precies welke Green serie het was, maar bij een wat oudere serie kon met tooling van WesternDigital TLER ingeschakeld worden, zoek daar even op in dit subforum daar moet je gegarandeerd iets op kunnen vinden.

[ Voor 10% gewijzigd door _Dune_ op 11-02-2013 15:41 ]

[Dadona]

Los van dat ik een rebuild met grote schijven al snel zou laten schieten zou ik nu al helemaal niet meer laten rebuilden. Met een RAID6 en twee falende schijven kun je je niets meer permiteren.
Ik zou door de zure appel heenbijten en linksom of rechtsom zorgen dat je een doodsimpele sync maakt met de array. Zorg ervoor dat je alle data kopieert naar een andere bestemming. Daarna kun je een afweging maken. Een rebuild doorzetten of de hele zooi van voor af aan opzetten. Persoonlijk zou ik overwegen om van begin af aan te beginnen.
_{(Met opzet heb ik het niet over backups, waarde van RAID, .. gehad. Het zou afleiden.)}

[ Voor 8% gewijzigd door Dadona op 11-02-2013 15:47 ]

[leuk_he]

Je zou met dezelfde config kunnen gaan naar een ZFS file systeem.... nadeel is dan dus wel dat je een ander OS typisch (freebsd/ opensolaris) moet gaan draaien. Dan heb je geen full-rebuilds meer als 1 enkele write mislukt.

[timberleek]

De RED en de RE hardeschijfen van Western Digital schijn geschikt voor (hardware)RAID-controllers. Precies om TLER zoals WesternDigital het noemt, andere fabrikanten kunnen er een andere benaming voor hebben. Het komt er op neer dat de hardeschijf zelf maar beperkt fouten probeerd te corrigeren en dit sneller aan de RAID controller overlaat dan "desktop"-hardeschijfen.

Ik weet niet precies welke Green serie het was, maar bij een wat oudere serie kon met tooling van WesternDigital TLER ingeschakeld worden, zoek daar even op in dit subforum daar moet je gegarandeerd iets op kunnen vinden.

Oh ik dacht de blacks ook nog.
Die green serie die nog TLER had was geloof ik de EADS serie. Maar dat was ook niet de hele serie. De eerste tijd hadden ze wel TLER later niet meer

[Verwijderd]

Correct.

@topicstarer: het staat niet in je topicstart, maar wat wil je precies? Wil je je data veiligstellen of wat? De opstelling zoals jij hem nu hebt is niet veilig zoals hierboven uitgelegd.

Om te waken over je overige schijven, kun je SMART uitlezen hiervan en kijken naar Current Pending Sector. Als deze van één schijf niet 0 is, heb je grote problemen omdat je degraded draait. Op dat moment dat je die sector tegenkomt zal ook die schijf afgekoppeld worden en dan wordt je array ontoegankelijk. Dus backup razendsnel wat je wilt bewaren en denk dan eens na over hoe het verder moet.

In jouw geval heb je last van bad sectors waarschijnlijk. Een overstap naar ZFS zal die problemen oplossen en dan hoef je ook niet meer elke schijf die een scheet laat om te laten wisselen. Het nadeel is dat je Intel IOP hardware RAID controller niet geschikt is voor ZFS; die zul je dan 2e hands moeten verkopen.

Om eerlijk te zijn is dit iets wat je had kunnen weten; dat je TLER schijven nodig hebt voor hardware RAID. Dus wel jammer dat je nu met een dergelijke - incompatible - hardwarecombinatie zit.

[yourservice]

Dank allen voor de antwoorden.

Het is mij nog niet allemaal duidelijk, ik heb destijds erg veel info gevraagd aan Zercom, mijn hardware leverancier en dit kon allemaal prima! Is ook ruim 2 jaar goed gegaan met deze WD schijven.

Ik ga mij nu concentreren op het redden van mijn data, ik zal daar ws 3TB schijven voor gaan aanschaffen.

ZFS zegt mij even niets maar ga er vanuit dat 30TB straks de max is / wordt van een nieuwe PC. Wat heeft dan de voorkeur, ZFS of RAID? En welk advies is er betreffende de schijven? Ik zal deze PC nog niet gelijk aan kunnen schaffen maar na inruil/garantie van de WD schijven denk ik wel dat ik nog een array kan opbouwen waar ik de data op terug kan plaatsen zodat ik de nieuw aan te schaffen schijven kan gebruiken voor de nieuwe array in RAID of ZFS.

Verwijderd schreef op maandag 11 februari 2013 @ 16:30:
Correct.

@topicstarer: het staat niet in je topicstart, maar wat wil je precies? Wil je je data veiligstellen of wat? De opstelling zoals jij hem nu hebt is niet veilig zoals hierboven uitgelegd.

Data veilig stellen, prio 1!

Om te waken over je overige schijven, kun je SMART uitlezen hiervan en kijken naar Current Pending Sector. Als deze van één schijf niet 0 is, heb je grote problemen omdat je degraded draait. Op dat moment dat je die sector tegenkomt zal ook die schijf afgekoppeld worden en dan wordt je array ontoegankelijk. Dus backup razendsnel wat je wilt bewaren en denk dan eens na over hoe het verder moet.

Hoe kan ik SMART uitlezen en waar vind ik daarna de Current Pending Sector?

[ Voor 34% gewijzigd door yourservice op 12-02-2013 00:12 ]

[yourservice]

Sorry!

[ Voor 99% gewijzigd door yourservice op 12-02-2013 00:12 ]

[jan99999]

Hier vind je ook nog veel info met schijven die uitvallen.
http://forums.overclockers.com.au/forumdisplay.php?f=44
En natuurlijk ook hier op gathering.
Voordat je hardware koopt, lees heel veel daarover, want heel veel werkt niet hoe fabrikanten zeggen.

ZFS is de voorkeur, dan heb je geen last ook met je wd schijven, want dit is software raid, je kan gewone controller gebruiken, je zit niet vast aan je hardware controller.
Je kan bijv hier een file server van maken en de files door het hele huis aanspreken viua bijv samba(windows sharen).
En omdat je niks anders doet dan samba gebeurt er ook niet veel met file server, is beter dan alle software hier ook nog op zetten.

[yourservice]

Dus deze zou eventueel wel kunnen? In een nieuwe RAID 6, nog wel ff mét de RocketRaid.

pricewatch: Western Digital Red WD30EFRX, 3TB

[Viper®]

Ik gebruik zelf ook 3 TB RED schijven in een raid6 opstelling.

Maar, hou er rekening mee dat RED schijven door de TLER minder snel oneigenlijk uit je raid gegooid worden, zoals ik bij jou lees heb je gewoon echt 2 schijven met een defect, daar gaat TLER niks aan wijzigen.

RED's hebben een zelfde MTBF rate als andere schijven, dus ze zijn niet extra veilig zover ik weet.

Met elke extra schijf en hoe hoger de grote van je totale Raid opslag neemt je kans op fouten toe, waarbij ook fouten tijdens rebuilds, wat tot gevolg heeft dat je al je data kwijt bent.
In jou geval was je met Raid5 al alles kwijt geweest.

[yourservice]

Ok, thnx Viper. Ik heb nu een bod gedaan op deze schijven, schijnen erg goed te zijn:

V&A aangeboden: Hitachi Ultrastar 7K3000, 3TB 24/7 HUA723030ALA640

[jantje112]

Beetje wazige deal met " slechts" drie maanden garantie.. Waarom risico nemen als je op de RED's gewoon een degelijke performance krijgt en garantie.

Ik zou als de brandweer je data veilig stellen. Je array staat nu op springen, dus nog even en je bent al je data kwijt!

[yourservice]

Ben ik mee bezig jantje112 maar het gaat zo traag, is dat de "schuld" van de verrotte arry of zijn er manieren waarop ik sneller, intern, kan kopiëren. Ik heb al geknipt en geplakt via Verkenner en RoboCopy doet nu zijn best.

[BartNL]

wanneer intern via netwerk en/of naar een enkele backup schijf is mag je blij zijn wanneer je 100MB/s haalt. Naar je raid 5 array zou ben je over Gb netwerk nogsteeds gelimiteerd tot 125MB/s. Een raid-6 array die niet aan het rebuilden is wordt niet trager wanneer er twee schijven uitvallen.
Bij 20TB + 11TB voor thuisgebruik kan ik mij niet voorstellen dat alles de moeite van het backuppen waard is. Belangrijkste is denk ik dat je prioriteiten stelt aan je backups. Dus eerst de belangrijkste zaken backuppen en daarna de rest. Persoonlijk zou ik dat wat belangrijk is backuppen en dan de array opnieuw aanmaken.
Overigens zou ik bij zoveel falende / verdachte schijven ook de interne bekabeling en PSU verdenken en die dus controleren / vervangen.

[yourservice]

Ben nu halverwege de back-up, so far so good... Heb uitbreiding van de 30 dagen van WD gekregen tot 60 dagen, moet lukken.

[yourservice]

Alle data is gebackupped nu, bijna alles is ook gelukt. Inmiddels zijn er nog 2 schijven bijgekomen die failen.

Nu contact opgenomen met WD omtrent de afhandeling van de rest van de schijven want nu de 2 nieuwe schijven zijn geplaatst is er een andere schijf mee gestopt. Mijn twijfels dus over de rest van de 4 schijven nog (8 vd 12 bad sectors).

Ook de HighPoint 3530 gaat nu retour via Zercom, ik vertrouw deze kaart nu even niet meer. Alle data komt straks als back-up op de nieuwe WD schijven en de RAID-6 wordt opnieuw opgebouwd met de 14 Hitachi schijven.

[Verwijderd]

Ik zou maar eens goed denken over welke route je nu wilt wandelen. Je hebt je controller nu retour gedaan. Dat betekent dat je hét alternatief zou kunnen overwegen: ZFS. Dan heb je geen enkel probleem meer met bad sectors en blijft alles lekker draaien al hebben al je schijven bad sectors.

Het komt steeds vaker voor dat hardeschijven onleesbare sectoren ontwikkelen. In veel setups kan ik zien dat ongeveer de helft van de disks bad sectors ontwikkelt. Op een traditionele RAID5 of RAID6 zou dit enorm veel problemen opleveren zoals ook in jouw geval. Dus zonder je te willen pushen raad ik je wel aan om ZFS serieus te overwegen; het is dé oplossing voor het probleem waar je nu mee te maken hebt.

[Rainesh]

Agree with Cipher.

ZFS is in jouw geval erg aan te raden.

[yourservice]

Ik heb één en ander gelezen over ZFS maar begrijp er nog niet veel van.
Kan ik dit binnen Windows 7 gebruiken?
Moet ik een aparte PC maken met een voor mij onbekend OS om ZFS te kunnen implementeren?

[Ben1985]

Als ik zo het ZFS topic doorlees, dan zie ik dat je het niet onder windows 7 kunt draaien. Aparte pc is niet nodig, je moet alleen bereid zijn om met een ander OS te werken:

Er zijn drie platforms waar ZFS op draait:
• Solaris (eerst van Sun, nu in de klauwen ehh handen van Oracle)
• FreeBSD (opensource UNIX)
• Linux (in beperkte mate en enigszins experimenteel)

Dit haal ik letterlijk uit Het Grote ZFS topic.

[yourservice]

Tja Ben, ik draai en heb altijd gedraaid met Windows. Mijn Raid-5 PC met 12TB draait al jaren met Samsung schijven en ben ik heel gelukkig mee.

Ik ga nu richting de 36 TB met Raid-6 en de genoemde Hitachi schijven.

Zit er inderdaad een grens aan de hoeveelheid data/Raid-X?

Ik vind t geen probleem hoor om voor de data over te stappen naar 1 PC met "een" ander OS maar ik blijf wel bij Windows op mijn eigen PC.

[Wouter.S]

yourservice schreef op vrijdag 15 maart 2013 @ 00:44:
Ik vind t geen probleem hoor om voor de data over te stappen naar 1 PC met "een" ander OS maar ik blijf wel bij Windows op mijn eigen PC.

Als je zelf al aangeeft dat je voor pure opslag niet opziet tegen een tweede pc (meestal=NAS) dan is dit het beste moment. Je kan met een schone lei beginnen. Maak gebruik van bijvoorbeeld ZFSguru of andere gelijkaardige distro's en je kan met een minimum aan inspanning je dataveiligheid enorm verhogen zodat deze problemen niet meer voorkomen.

Bovendien is de kostprijs van een dedicated NAS met eenvoudige hardware en een intel (non-raid !!) controller redelijk verwaarloosbaar tegenover de prijs van zo'n lading harde schijven.

Ik zou zeggen lees hier even in:
Het grote ZFS topic
Het grote zuinige server topic (als je het goed wilt aanpakken )

[Viper®]

yourservice schreef op vrijdag 15 maart 2013 @ 00:44:
Tja Ben, ik draai en heb altijd gedraaid met Windows. Mijn Raid-5 PC met 12TB draait al jaren met Samsung schijven en ben ik heel gelukkig mee.

Ik ga nu richting de 36 TB met Raid-6 en de genoemde Hitachi schijven.

Zit er inderdaad een grens aan de hoeveelheid data/Raid-X?

Ik vind t geen probleem hoor om voor de data over te stappen naar 1 PC met "een" ander OS maar ik blijf wel bij Windows op mijn eigen PC.

Interessante stukjes:

http://www.zdnet.com/blog...stops-working-in-2019/805
http://www.servethehome.c...-anthology-part-1-primer/

The crux of the problem RAID arrays are groups of disks with special logic in the controller that stores the data with extra bits so the loss of 1 or 2 disks won't destroy the information (I'm speaking of RAID levels 5 and 6, not 0, 1 or 10). The extra bits - parity - enable the lost data to be reconstructed by reading all the data off the remaining disks and writing to a replacement disk.

The problem with RAID 5 is that disk drives have read errors. SATA drives are commonly specified with an unrecoverable read error rate (URE) of 10^14. Which means that once every 200,000,000 sectors, the disk will not be able to read a sector.

2 hundred million sectors is about 12 terabytes. When a drive fails in a 7 drive, 2 TB SATA disk RAID 5, you’ll have 6 remaining 2 TB drives. As the RAID controller is reconstructing the data it is very likely it will see an URE. At that point the RAID reconstruction stops.

Here's the math: (1 - 1 /(2.4 x 10^10)) ^ (2.3 x 10^10) = 0.3835

You have a 62% chance of data loss due to an uncorrectable read error on a 7 drive RAID with one failed disk, assuming a 10^14 read error rate and ~23 billion sectors in 12 TB. Feeling lucky?

RAID 6 RAID 6 tackles this problem by creating enough parity data to handle 2 failures. You can lose a disk and have a URE and still reconstruct your data.

Some complain about the increased overhead of 2 parity disks. But doubling the size of RAID 5 stripe gives you dual disk protection with the same capacity. Instead of a 7 drive RAID 5 stripe with 1 parity disk, build a 14 drive stripe with 2 parity disks: no more capacity for parity and protection against 2 failures.

Uitgaand van 36 TB / 3 TB = 12 disks zie ik geen kleurrijke toekomst tegemoet.

[y_boonstra]

Hou er wel rekening mee dat met de huidige ZFS het niet mogelijk is om je array uit te breiden met een schijf.

[yourservice]

y_boonstra schreef op vrijdag 15 maart 2013 @ 10:41:
Hou er wel rekening mee dat met de huidige ZFS het niet mogelijk is om je array uit te breiden met een schijf.

Dat laatste is niet geheel onbelangrijk.

[yourservice]

Zojuist de overige 10 schijven ook als RMA aangemeld. Deze zullen allemaal worden vervangen door WD.

Netjes!

Ik ga nu 12 Hitachi 3TB schijven koppelen aan de HighPoint RocketRaid 3530 om mijn data weer terug te zetten. Zodra de 10 schijven à 2TB weer binnen zijn zal ik deze gebruiken als losse back-up schijven en gaan kijken naar een ZFS oplossing.

Ik twijfel nog of ik de HighPoint RocketRaid 3530 ook zal opsturen als RMA of dat het echt door de WD schijven is veroorzaakt al deze commotie.

[Verwijderd]

Weet in elk geval dat de HighPoint RR 35xx series een hardware RAID controller is, en per definitie ongeschikt voor ZFS. De controller is de oorzaak van je problemen, niet zozeer de disks.

Zeker als je de mogelijkheid hebt om je controller te retourneren, ligt een ZFS build voor de hand. Je had je schijven niet hoeven te retourneren; bad sectors komen bij vrijwel alle schijven voor. Je dient dus een oplossing te gebruiken die hiermee kan omgaan. ZFS valt hieronder, en had al jouw bestaande schijven zonder problemen geslikt.

Zou je dus voor de optie kiezen om ZFS te draaien op een aparte computer die als NAS fungeert, dan kun je toch op je Windows over veilige opslag beschikken die niet gelijk op zijn bek gaat als een van je schijven een scheet laat. Problemen als bad sectors zijn dan verleden tijd.

[BartNL]

Verwijderd schreef op vrijdag 15 maart 2013 @ 18:12:
Je dient dus een oplossing te gebruiken die hiermee kan omgaan.

zijn Highpoint controller heeft de volgende features,

• TerabtyeSaver™ with write journaling optimizes data protection
• TerabyteGuard™ with bad sector repair and remapping, disk scrubbing and (SHI) - Storage Health Inspector

Lijkt mij dus eenvoudigweg gebruik maken van deze opties. Met een beetje geluk kun je de disks maandelijks automatisch laten checken en is risico al stuk beter.

[Verwijderd]

Hoe verklaar je dan de problemen die de TS heeft? Of moet hij die features handmatig enablen?

[BartNL]

ik verwacht dat TS niet weet dat het verstandig is om je raid volumes regelmatig te controleren en dat dan ook niet doet. Ik verwacht dat je bij Highpoint die controles zelf moet doen (alhoewel write journalling wel meer suggereert) en mocht het automatisch kunnen je dat wel moet enablen / instellen.

[Verwijderd]

Al doe je geen regelmatig surface checks; dan nog moeten alle bad sectors gerepareerd worden volgens jou. Als redundante informatie wordt gebruikt om bad sectors te overschrijven zoals ZFS doet, zal de TS nooit problemen hebben mogen ondervinden. Dus kennelijk werkt dat toch niet zoals geadverteerd.

Ik heb dat ook nog nooit werkend gezien; hardware controllers die redundantie gebruiken om bad sectors te corrigeren. Is daar een échte bron van die dit aantoont? Marketing blabla kan iedere knuppel schrijven; maar echt dit goed engineeren is een ander verhaal.

[BartNL]

Verwijderd schreef op zaterdag 16 maart 2013 @ 20:08:
Al doe je geen regelmatig surface checks; dan nog moeten alle bad sectors gerepareerd worden volgens jou.

ik weet niet hoe je er bij komt dat dat volgens mij zo is? Persoonlijk geloof ik niet dat het net zo goed is ontworpen als bijvoorbeeld ZFS. Ik zie deze opties op een hardware raid controller als een lapmiddel dat de angel uit het probleem neemt dat je ongemerkt corrupte data krijgt.

[Wim-Bart]

Het ligt per definitie niet aan de controller, wat hij mee gemaakt heeft met een hardware raid controller kan ook gebeuren met een software raid controller van andere fabrikanten. Zelfde ervaring met AMD, Dell PERC, HP, Highpoint en Silicon Image controllers.

Het lijkt een jaar, 2 jaar stabiel te draaien en dan gaat het opeens fout, zijn geluk is RAID 6. Met RAID 5 had hij een groter probleem gehad (zoals ik had met RAID 5). Wanneer je Green disks gebruikt dan kan je twee soorten problemen krijgen. Zelf last gehad van beide problemen.

1. Bad sector, waardoor de drive uit de array gekicked wordt, sector blijkt soms echt bad, soms niet. Maar de controller denkt dat de disk kapot is omdat het meer dan een paar seconden duurt voordat de disk antwoord geeft. De array raakt degraded en de array is kapot. Zelf gehad dat een paar keer op x% rebuild de disk weer uit de array gekicked werd en overnieuw begon.
2. Spin down, sommige disks hebben de eigenschappen om onverwacht down te spinnen als power saving, ik snap niet hoe dat kan, want in theorie moet het OS zo iets regelen. Wat er bij mij gebeurde op een PERC controller is dat de betreffende drive niet snel genoeg weer on-line was en uit het array gegooid werd.

Overigens is mij iets anders opgevallen en het zal wel een belangrijke reden hebben. Maar wanneer je naar professionele storage kijkt van IBM, NetApp, HP EVA, EMC Clarion, dan zie je dat RAID-5 en RAID-6 sets maximaal uit 12 drives bestaan. Technisch zouden het meer drives kunnen zijn, maar ze limiteren dit. Bij navraag bij IBM was het antwoord heel erg simpel. Hoe meer drives, hoe groter het risico dat er read en of errors zijn binnen de array waarbij het verhaal min of meer neer kwam op:

The crux of the problem RAID arrays are groups of disks with special logic in the controller that stores the data with extra bits so the loss of 1 or 2 disks won't destroy the information (I'm speaking of RAID levels 5 and 6, not 0, 1 or 10). The extra bits - parity - enable the lost data to be reconstructed by reading all the data off the remaining disks and writing to a replacement disk.

The problem with RAID 5 is that disk drives have read errors. SATA drives are commonly specified with an unrecoverable read error rate (URE) of 10^14. Which means that once every 200,000,000 sectors, the disk will not be able to read a sector.

2 hundred million sectors is about 12 terabytes. When a drive fails in a 7 drive, 2 TB SATA disk RAID 5, you’ll have 6 remaining 2 TB drives. As the RAID controller is reconstructing the data it is very likely it will see an URE. At that point the RAID reconstruction stops.

Here's the math: (1 - 1 /(2.4 x 10^10)) ^ (2.3 x 10^10) = 0.3835

You have a 62% chance of data loss due to an uncorrectable read error on a 7 drive RAID with one failed disk, assuming a 10^14 read error rate and ~23 billion sectors in 12 TB. Feeling lucky?

RAID 6 RAID 6 tackles this problem by creating enough parity data to handle 2 failures. You can lose a disk and have a URE and still reconstruct your data.

Some complain about the increased overhead of 2 parity disks. But doubling the size of RAID 5 stripe gives you dual disk protection with the same capacity. Instead of a 7 drive RAID 5 stripe with 1 parity disk, build a 14 drive stripe with 2 parity disks: no more capacity for parity and protection against 2 failures.

Verder heb ik voor een ander project contact gehad met NetApp over het gebruik van "Consumer high cappicity" disk in de laagste tier van een storage oplossing. En het antwoord is heel simpel. Niet doen omdat de meeste consumer disks bepaalde features niet ondersteunen waaronder rapportage over een read of write error. Transparante sector relocation is voor storage arrays iets wat ze liever niet zien.

[BartNL]

Wim-Bart schreef op zaterdag 16 maart 2013 @ 20:26:
...voor storage arrays iets wat ze liever niet zien.

tja, wanneer je professioneel een disk array beheert zou je ook wel gek zijn om risico's te nemen. Voor thuisgebruik zie ik dat wel anders en liggen de odds naar mijn ervaring (ik weet het zegt niet veel) minder ongunstig dat in het geciteerde stukje en durf ik die gok wel aan.
Als de fileserver hier morgen faalt is het even slikken maar er is feitelijk geen schade. Stel de raid-array bedrijfsmatig zou worden gebruikt zou ik ook alleen maar enterprise achtige oplossingen gebruiken.
Idem wanneer ik zuivere opslag zou draaien (zo gauw 10Gb netwerk betaalbaar is ) zou ik ook via IBM serveraid kaart ZFS draaien.

[Wim-Bart]

BartNL schreef op zaterdag 16 maart 2013 @ 20:34:
[...]

tja, wanneer je professioneel een disk array beheert zou je ook wel gek zijn om risico's te nemen. Voor thuisgebruik zie ik dat wel anders en liggen de odds naar mijn ervaring (ik weet het zegt niet veel) minder ongunstig dat in het geciteerde stukje en durf ik die gok wel aan.
Als de fileserver hier morgen faalt is het even slikken maar er is feitelijk geen schade. Stel de raid-array bedrijfsmatig zou worden gebruikt zou ik ook alleen maar enterprise achtige oplossingen gebruiken.
Idem wanneer ik zuivere opslag zou draaien (zo gauw 10Gb netwerk betaalbaar is ) zou ik ook via IBM serveraid kaart ZFS draaien.

Zelfs al heb je de mooiste oplossing, met de meest betrouwbare disks, dan nog valt en staat alles met een goede backup :-) Heb array's met over de 150 disks zien draaien die in 5 jaar maar 1 disk failure hadden (EVA 8100 met 12 enclosures) en array's met 2 enclosures (NetApp) met een kwart aan dat aantal disks waar iedere maand wel een drive er uit klapte. Er is gewoonweg geen pijl op te trekken.

Vroeger had je nog wel eens dat disks uit de zelfde productie batch binnen een tijdsspanne van een paar weken er uit klapten maar tegenwoordig is dat ook al niet altijd meer het geval. Kortom, Backup op good old tape is gewoon de oplossing in alle gevallen.

[Verwijderd]

BartNL schreef op zaterdag 16 maart 2013 @ 20:25:
ik weet niet hoe je er bij komt dat dat volgens mij zo is?

Als je claimt bad sectors uit redundante data te kunt destilleren, dan betekent dit dat als je in een RAID5 een bad sector tegenkomt die disk niet uit de array wordt gegooid maar die ene bad sector wordt overschreven door parity calculatie van de overige disks. Dan zou er in het geval van de topicstarter geen enkel probleem hebben met twee disks met rode uitroeptekens.

Dat is wat er bij ZFS gebeurt wanneer je bad sectors tegenkomt door gewoon te lezen. De bad sector wordt overschreven, je applicatie merkt niets en alles blijft prima draaien. Een uitzondering hierop is ZFS via hardware RAID; dan krijg je hetzelfde gezeik dat de firmware de disk onzichtbaar maakt en dan houdt het voor ZFS natuurlijk ook op. Daarom moet je ZFS niet combineren met een hardware RAID controller; IBM M1015 enzo zijn wel geschikt omdat de firmware geen disks onzichtbaar maakt zelfs in RAID mode (IR) zo heb ik mij laten vertellen. In IT mode (non-RAID firmware) zou dit helemaal geen probleem mogen zijn omdat het operating system dan volledige controle heeft over disk timeouts.

Als de functionaliteit die deze controller zou moeten hebben zoals geadverteerd correct zou werken, zou je enkel een periodieke een background scan / rebuild / scrub moeten doen om twee problemen te verzachten:

• Dat zodra je een schijf verliest aan een échte failure, je een kleinere kans hebt onopgemerkte bad sectors tegen te komen op de resterende schijven als je regelmatig scrubt.
• Om bij een enkelvoudig redundante array (RAID5 / RAID-Z) bescherming te krijgen tegen twee bad sectors op twee disks die op exact de verkeerde plek zitten zodat in één parity block er twee blocks zijn met bad sectors. Dit is echter extreem zeldzaam als je disks maar op een normaal tempo af en toe een bad sector genereert.

Kortom, als de firmware goed ontworpen zou zijn, zou background scan/rebuild niet nodig zijn voor het corrigeren van bad sectors; dat kan in theorie gewoon goed werken ook op hardware RAID. Maar helaas, het is een grote bende. Tijd om je data écht te beschermen met iets als ZFS, ReFS of Btrfs. Van die drie opties is ZFS met kop en schouders beter in vrijwel alle opzichten. Afgezien van technische voordelen is het cruciaal punt wel dat ZFS op bijna alle operating systems draait (Mac, Linux, BSD, Solaris) terwijl ReFS en Btrfs enkel op hun thuisplatform draaien: respectievelijk Windows en Linux.

Persoonlijk geloof ik niet dat het net zo goed is ontworpen als bijvoorbeeld ZFS. Ik zie deze opties op een hardware raid controller als een lapmiddel dat de angel uit het probleem neemt dat je ongemerkt corrupte data krijgt.

Maar dat betekent dus dat hardware RAID in het algemeen erg onbetrouwbaar is doordat het eigenlijk geen antwoord heeft op bad sectors, iets wat tegenwoordig bij 2TB+ schijven veelvuldig voorkomt. Dat is eigenlijk gewoon volstrekt onacceptabel. Zulke controllers werken wel goed met lage capaciteit SAS schijven met 10^-16 uBER spec, maar voor 2TB+ disks zou ik ze niet snel aanraden zelfs als iemand persé Windows wilt als storage OS. Dan nog beter de storage pooling gebruiken zonder RAID - heb je tenminste werkende bescherming tegen enkelvoudige bad sectors.

---

Wim-Bart schreef op zaterdag 16 maart 2013 @ 20:26:
Het ligt per definitie niet aan de controller, wat hij mee gemaakt heeft met een hardware raid controller kan ook gebeuren met een software raid controller van andere fabrikanten. Zelfde ervaring met AMD, Dell PERC, HP, Highpoint en Silicon Image controllers.

Dat klopt, dit geldt voor alle Hardware RAID + Fake RAID. Laatstgenoemde is bijzonder, want zoals als Silicon Image werkt onder Linux en BSD prima in combinatie met software RAID. Maar de Windows-only drivers die de RAID functionaliteit verzorgen, zijn net zo brak als anderen. Ook Intel Onboard RAID, de beste 'FakeRAID' die er is, kan niet intelligent omgaan met bad sectors. Erg jammer.

Het lijkt een jaar, 2 jaar stabiel te draaien en dan gaat het opeens fout

Precies dat. Velen zeggen dat het prima werkt, totdat ze een keer een schijf kwijt zijn en een rebuild moeten draaien. Dan komen ze bad sectors tegen die hun overige disks detached en de array is FAILED. En dan gaan ze panieken en die paniekacties zorgen voor permanent dataverlies.

zijn geluk is RAID 6. Met RAID 5 had hij een groter probleem gehad

Zeer scherp!

Verder heb ik voor een ander project contact gehad met NetApp over het gebruik van "Consumer high cappicity" disk in de laagste tier van een storage oplossing. En het antwoord is heel simpel. Niet doen omdat de meeste consumer disks bepaalde features niet ondersteunen waaronder rapportage over een read of write error. Transparante sector relocation is voor storage arrays iets wat ze liever niet zien.

Het is niet transparant hoor; juist het tegenovergestelde: de host heeft geen weet van de sector remap. Net als bij SSDs dus.

Wat betreft hoge capacity disks: prima doen! RAID is van oudsher bedoeld om met meerdere apparaten die van zichzelf minder betrouwbaar zijn dan hele dure, toch een betrouwbaar volume te kunnen maken. Het principe is dus betrouwbaar met goedkope componenten. De andere kant is om veel geld uit te trekken voor dure hardware, dure controllers, battery backup unit en op de 'domme' manier je veiligheid te vergroten. Je hebt dure hardware met domme software die totaal onbeschermd data opslaat en aanneemt dat het opslagapparaat perfect is. De 'slimme' manier is met weinig geld en goedkope componenten, de software zo ontwerpen dat deze goed kan omgaan met de zwakke punten, zoals bad sectors.

Dit verhaal is toch wel heel erg van toepassing op Hardware RAID (en onboard ofwel FakeRAID) versus ZFS.

[Q]

Met MDADM en ZFS kun je snel recoveren als een disk eens uit een array klapt. MDADM heeft bitmaps, ZFS is sowieso al beter op de hoogte wat wel en niet in sync is op een disk.

Ik heb voor mijn Array's altijd 7200 RPM drives gekocht mede om rebuild times van mijn array acceptabel te houden.

Mijn 20 disk 18 TB array doet een rebuild in 5 uur. Dat is een zeer goede tijd vergeleken met de meeste verhalen waarbij dit dagen duurt. Met 2 TB disks ipv 1 TB disks zou dit 10 uur duren.

[yourservice]

WOW, wat een boel informatie

Maar om even vooruit te kunnen en zonder verdere investering zijn de Hitachi schijven (7200rpm) goede schijven om een RAID6 op te bouwen mbv de genoemde HighPoint 3530.

12 schijven, 30TB schoon (ongeveer)?

En als ik ga kijken naar een ZFS oplossing, wat is dan een goeie controller? Ik zal de 12 schijven toch op een hardware controller aan moeten sluiten.

[Wouter.S]

yourservice schreef op zaterdag 23 maart 2013 @ 10:44:
En als ik ga kijken naar een ZFS oplossing, wat is dan een goeie controller? Ik zal de 12 schijven toch op een hardware controller aan moeten sluiten.

pricewatch: IBM ServeRAID M1015 SAS/SATA Controller for System x
Geflashed met IT firmware, deze geeft de disk gewoon puur door zonder enige vorm van raid-tussenlaag. Dit in combinatie met de gewone sata poorten op je moederbord. Eventueel twee controllers afhankelijk van hoeveel sata poorten je hebt op je moederbord. Is trouwens ook veel goedkoper dan een Areca/Rocketraid

[yourservice]

Eindelijk dan na n paar maanden?

[Madrox]

Tja, green disks van WD zijn niet geschikt voor raid. Sterker nog, ze gaan ook nog sneller stuk is mijn ervaring, ook zonder raid. Dat je WD dan dropt is niet terecht, want de blue's, blacks, RE's en RED's hebben een veel betere status en zijn iig solide genoeg om in raid te zetten. De greens zijn nou eenmaal de budget consumer serie en dat zie je terug in de prijs, prestaties en betrouwbaarheid.

Mijn 6 Blue's van 640GB doen het nog uitstekend na ruim 2 jr. Wel heb ik 1 disk opnieuw een lowlevel format gegeven daar die ff regelmatig uit de array "viel". Bleek een prima oplossing, de onwillege disk doet sindsdien prima zijn werk

Heb btw ook een Highpoint, een ietwat goedkopere. Niks mis mee.

[ Voor 4% gewijzigd door Madrox op 24-04-2013 11:46 ]

[Verwijderd]

Madrox, ik zou het wel waarderen als je de thread door wilt lezen. Veel van de onderwerpen die je aanhaalt worden in deze draad beschreven en het lijkt erop dat je daar weinig van hebt meegekregen.

Dat Green ongeschikt is voor RAID is simpelweg onzin. Ga je verdiepen in bad sectors en timeouts, en vorm dan je mening. Bedenk ook dat WD Green en WD Red fysiek hetzelfde zijn; enkel de firmware en garantie is anders. Je mag ook best sceptisch zijn versus de claims van hardeschijffabrikanten, die er natuurlijk belang bij hebben om een product op een bepaalde manier te positioneren. Denk ook aan verzekeringen die overlappend zijn met waar de wet al in voorziet, en derhalve deels overbodig maar je betaalt er wel voor.

Wat je verder beschrijft over uit de array vallen en na een zero write weer prima functioneren, komt ook exact overeen met bad sector en timeout. Als je dan vervolgens zegt dat er met Highpoint niets mis mee is, denk ik dat je het complete verhaal nog niet helemaal begrijpt. Mocht je willen dat ik daar meer over uitleg, wil ik je vragen éérst de tekst in deze thread door te nemen, en vervolgens: Verwijderd in "Het grote ZFS topic".

[Madrox]

Jij mag dat onzin vinden, mij is opgevallen dat Greens vaker stuk gaan dan blue's. Van de drie greens zijn er twee stuk hier, van de blue's nul. als je rondneust op internet zie je hetzelfde beeld, greens gaan vaker stuk.

Misschien geef ik een verkeerd beeld met mijn highpoint verhaal, maar ik het het ZFS topic al gelezen en weet waar het over gaat. Wat overblijft is dat hij, in mijn ogen, onterecht zijn raidcontroller niet meer vertrouwd.

[Verwijderd]

Van de drie greens zijn er twee stuk hier

Iets met statistisch insignificante meetresultaten? Zo zijn er ook mensen met 4 OCZ SSDs die het prima doen en een kapotte Intel 320. Dus de conclusie is dat laatstgenoemde zuigt en OCZ het beste merk ter wereld is?

als je rondneust op internet zie je hetzelfde beeld, greens gaan vaker stuk.

Daar kan ik twee dingen over zeggen:

1) de hardeschijf hoeft helemaal niet stuk te zijn. In RAID arrays is het de RAID controller die de schijf uitspuugt. De hardeschijf werkt correct volgens de uBER specificatie en veroorzaakt nu en dan bad sectors. Dat is geen defect. Een defect is pas als een apparaat zijn opgegeven specificaties niet meer kan halen. Het echte defect is de onvolkomenheden in RAID implementaties, zoals in de firmware van Hardware RAID veelvuldig voorkomt.

2) er worden veel meer Greens verkocht dan Blue's; de blues zijn eigenlijk generfde Blacks en zijn het minst interessant. 7200rpm is ook niet meer zo relevant als dat vroeger was omdat we nu SSDs hebben en hardeschijven steeds meer voor bulkopslag gebruiken ipv alle opslag dus ook je operating system en andere data die random I/O snelheden nodig heeft. Gevolg is dus dat Greens veel populairder zijn, en dan zie je ook dat de absolute aantallen van RMA's hoger ligt. Maar relatief hoeft dat helemaal niet zo te zijn. Ik kan geen reden vinden waarom een Green een hoger uitvalpercentage zou moeten hebben dan Blue. Zeker als de datadichtheid gelijk ligt is omgekeerd zelfs logischer; lager toerental zou meer betrouwbaar moeten zijn dan een hoger toerental - indien de overige factoren onveranderd blijven (ceteris paribus).

[Wim-Bart]

Heb zelf 8 x een mix van Green, Red en RE in ëën enkele Raid 10 set hangen, en dat van alle types er al 1 kapot is gegaan binnen het eerste levensjaar (4x Green, 2x RE, 2x Red). Eigenlijk wilde ik een RAID-5 set, maar probleem was dat bij het defect raken van de RE en Red er geen probleem was, maar toen een Green kapot ging de RAID controller opeens de disk dropte op 1 "defecte" sector.

[Viper®]

Persoonlijk vind ik het mixen van verschillende merken en types niet ideaal, al begrijp ik dat het in de praktijk lastig is om hot/cold spares te hebben liggen.

Wel pak je alle slechte eigenschappen van alle schijven mee.

In a general way, the main issue I see with mixing brands is a RAID will combine the flaws of both models. For example, if one has lower random writes, and one has lower sequential writes, the RAID will end up bottlenecked in both types of operations, preventing near 2x speeds.