A) Bagger RAID controller dus.
B) RAID is geen vervanging voor een goede backup.

Hoe zit dit eigenlijk op SSD disks?

RAID6 is net zo dood als raid5, het duurt alleen net wat langer voordat je tegen een kritieke fout oploopt. Verder zijn zowel raid5 als raid6 erg beperkend in de schrijfsnelheid van de array. Gezien de prijs van harde schijven is het bijna nooit meer zinvol om raid5 of raid6 te gebruiken, maar zou Raid1+0 (raid10) veel zinvoller zijn. De kans dat je dan nog door 2 slechte schijven data kwijt raakt is nog veel kleiner en de schrijfsnelheid is een stuk hoger dan bij raid5 of raid6.

Wat? Waarom zou dat anders zijn?

Omdat er geen bewegende onderdelen inzitten en de opslag-techniek heel anders is (NAND flashtechniek vs elektro-magnetisch veld + lees-/schrijfkop). De basis principes blijven wel overeind (RAID5 vs RAID6), maar het slijtage-patroon is heel anders.

Ja, ze gaan minder lang mee en zijn duurder. ;)

Verder snap ik de vraag ook niet zo.

De kans dat je door 2 slechte schijven data kwijt raakt is met RAID10 juist groter dan met RAID6. Als 2 schijven die elkaars mirror zijn problemen krijgen, ben je alsnog al je data kwijt. Met RAID6 heb je dat probleem niet.

Leuk met 4 of 6 disken, maar als je er 20-30 hebt, dan is RAID1 gewoon geen oplossing meer, veel te kostbaar.
Daarbij bij RAID1(0) is dataverlies al mogelijk bij 2 defecte disken, bij RAID6 moet je 3 defecten hebben. Kans op fouten is dus een stuk lager.

Dit is juist ook 1 van de redenen waarom ZFS zo mooi is. Hiermee vervalt de dure RAID controller. ZFS heeft deze niet meer nodig. Meer snelheid nodig, gewoon SSD caching er bij doen. En natuurlijk de vele overige voordelen van ZFS.

Persoonlijk vertrouw ik me data alleen nog maar toe aan ZFS.

"RAID is dood, lange leve ZFS"

Zfs scrub bijvoorbeeld ;-)

+1

Waarom maken ze geen RAID versie waarbij ook een integriteitscheck is ingebouwd? Je zou zeggen dat je gewoon de integriteit van iedere schijf voortdurend kunt controleren (in de background) en elke fout herstellen aan de hand van de data op de overige schijven. Valt er dan een keer een hele schijf uit, dan weet je zeker dat het altijd te herstellen valt.
In feite is dat ook wat ZFS doet, als ik me niet vergis.

ZFS heeft dan wel weer genoeg CPU en vooral geheugen nodig dat je eigenlijk een aparte servert nodig hebt. En dat geheugen mag ook wel ECC hebben aangezien die geheugensticks ook steeds groter worden.

Wat mij dan weer ergert is dat ECC zo slecht te krijgen is in "consumenten"bordjes. Want serverbordjes hebben dan weer een hele andere mix van features. Zo hebben ze meestal 8x PCIe slots, terwijl ik 2x PCIe 16x hebben wil. Waar ik dan dus ECC voor moet inleveren. En zo vreselijk moeilijk is het niet aangezien de controller tegenwoordig in de CPU zit, dus wat extra lijntjes erbij en de juiste CPU zou voor de rest moeten zorgen. Maar dan zijn die lijntjes er dus gewoon niet. *zucht*

De problemen die je hebt met defecte disken worden door de RAID controllers meestal verergerd.
Daar is die meneer kennelijk ook een keer tegenaan gelopen.
Als je een RAID setje hebt en er komt ergens een rotte sector op een van de disken dan zal de controller meestal meteen die hele disk op error zetten en offline halen, waarmee dan je redundancy vaak weg is.
Wat je dan vaak ziet is dat het even trekken en terugzetten van dezelfde disk (waarbij de hele disk opnieuw geschreven wordt met de data van de andere disk(en)) het probleem weer oplost.
De rotte sector wordt dan door de drive geheralloceerd naar een andere plaats, en alle data is er nog.
Echter, heb je bij het rebuilden van de disk ergens anders een error dan is Leiden in last.

Veel beter zou het zijn als de controller software zelf bij een read error de data na recovery vanaf de andere disk(en) terug zou schrijven naar de rotte sector, en verder zou gaan. Dit natuurlijk tot een bepaald maximum aantal, en met een alert naar de beheerder.
Het is beter om de schijf met de rotte sector er zo lang mogelijk bij te houden want deze kan wellicht sectoren leveren die op de andere disk(s) defect zijn. Is hij eenmaal offline gehaald dan kan dat niet meer betrouwbaar.

Helaas helaas, zowel controller software als bijvoorbeeld de RAID software in Linux doet dit niet.

Wat de performance betreft: RAID-5 is wel slecht voor schrijven, maar daarentegen is het weer beter voor lezen.
Ik gebruik ook altijd RAID-1 maar als je echt snel wilt kunnen lezen (bijvoorbeeld als je een LTO-5 tape hebt) dan kan het beter zijn om RAID-5 te hebben.

Ook wel vreemd: je zou denken dat RAID controllers als je grote blokken leest van een RAID-1 setje dit interleaved doen, op dezelfde wijze als RAID-0 doet. Op beide disks de helft van de data lezen en dat dan samenvoegen. Dat zou de lees performance kunnen verdubbelen. Maar toch doet (vrijwel?) niemand dat.

Ten eerste is RAID is geen vervanging van een backup.


Nee dus. Dan had hij nog steeds alle 18TB van de backup kunnen herstellen. Alleen als er na de backup een bestand was gewijzigd dat daarna toevallig ook op een andere disk niet meer leesbaar was dan was dat bestand verloren gegaan.


Ten tweede:
Een (goede) RAID kaart controleert de disks. (Scrubbing). Een oud defect op een tweede disk wordt dus al eerder opgemerkt.

Ten derde:
RAID 5 op een grote harddisk is inderdaad een slecht idee. BIj het herconstrureren van de array nadat een disk kapot is worden de andere harddisk zwaar belast. Daarbij kan een tweede disk kapot gaan.

Nou, jammer. Als dat in een bedrijf gebeurt dan wacht je tot vijf uur (zodat het personeel kan blijven doorwerken. Daarvoor heb je RAID). Daarna maak je een backup van de laatst gewijzigde gegevens, stop er een nieuwe disk in en hersteld van backups.

Het grote punt hier is dat het personeel kan blijven doorwerken. Niet dat je data magisch veilig is door RAID.

Backups zijn natuurlijk heel goed, maar als je 18 TB moet terughalen van de backup ben je toch wel twee dagen offline.

Bij RAID5 zijn het 2 schijven, bij RAID6 zijn het er 3, daar zat ik even naast. Het punt is, bij RAID5/6 kan het een combinatie van willekeurige schijven zijn die stuk is, bij RAID10 is het alleen maar een probleem als 2 schijven van hetzelfde paar stuk zijn. Bij ZFS is het standaard zo dat je bij 2 willekeurige schijven uit een pool defect je data kwijt bent.

ZFS is zonder meer een heel slim filesysteem wat "hardware raid" snel achter zich laat qua kracht en performance, mits je voldoende RAM en CPUpower in je systeem hebt zitten. Zo zijn er meer in ontwikkeling, BTRFS gaat bijvoorbeeld ook die kant op. Een groot nadeel van is, is dat ZFS alleen ondersteund op unixachtige besturingssystemen, Windows kan er niets mee. Hardware raid is veel breder ondersteund en voor sommige toepassingen zal je zoiets moeten kiezen, of software raid.

Het aantal schijven wat belast wordt bij een rebuild van raid 10 als je een stukke disk vervangt is altijd twee. Bij ZFS, RAID5 of RAID6 is het altijd de hele set, omdat de parityblocks over de hele set verdeeld zijn. De belasting voor je storage is dus veel groter en het duurt daardoor bijna altijd langer om te rebuilden. Hoe meer disken in de raidset, hoe meer belasting en hoe vaker je moet rebuilden. Bij RAID6 als je 30 disken in je volume hebt zitten, heb je, statistich bekeken, 5 keer zoveel kans op een stukke disk als bij een RAID6 van 6 disken. Als een disk gemiddeld 3 jaar meegaat, heb je in een RAID6 van 30 schijven dus 10 keer per jaar een rebuild waarbij alle disken staan te klapperen en de rebuild dus heel langzaam gaat, want je doet alleen aan rebuilden als er geen data gelezen/geschreven wordt, of je storage is 10 keer per jaar een dag traag. Als je dat met een RAID10 set doet, heb je net zo vaak rebuilds, maar is 28/30e van je storage net zo snel als anders en is de kans dat gebruikers er iets van merken vele malen kleiner.

Software RAID oplossingen, of je nou ZFS RAID5, RAID6 of RAID10 doet, of LVM2 of zoiets, kosten CPU en RAM. CPU en RAM zijn relatief goedkoop, maar je moet het wel "over" hebben. Er valt wat te zeggen voor een hardware RAID10controller, want die kan zonder dat ie parity moet berekenen en blocks allocaten (wat de RAID5/6 controllers zo'n bottleneck geeft) toch de /read/write requests afhandelen en verdelen over de schijven. Ook is background scrubbing in hardware (het controleren of de data nog wel leesbaar is en niet corrupt) mogelijk. Niet iedereen heeft 8G ram en 2 CPU cores "over" om een zpool van 10 schijven van 1TB een beetje snel te laten werken.

Ik kom nu misschien over als iemand die roept dat RAID10 de oplossing voor al je problemen is. Dat is het zeker niet, er zijn vaak genoeg betere oplossingen denkbaar. Raid5/6 zijn alleen redelijk archaisch aan het worden en met de huidige prijzen van disken hoef je raid10 niet meer te laten vanwege de netto storagecapaciteit die je vergeleken met RAID5/6 in moet leveren. Dat is echt het enige nadeel van RAID10 en als je dat nou echt een probleem vindt, dan kan je in ieder geval onder Linux ook gewoon met blocks van 3 disken werken, dan heb je 2 paritydisks per datadisk. Dan moeten er 3 specifieke disken uitvallen voordat je je raidset opnieuw moet opbouwen en data restoren (want je hebt backups, toch?) terwijl bij raid6 er 3 willekeurige disken uit hoeven te vallen voordat je RAIDset corrupt is. Hoe dat bij andere besturingssystemen zit weet ik niet, maar ik kan me goed voorstellen dat in ieder geval de diverse BSDvarianten daar wel oplossingen voor hebben.

Ik denk eerder dat het probleem waar Graham op doelt is dat de hoeveelheid bytes op een disk gestaag toeneemt, terwijl de gemiddelde error-rate niet daalt. Daardoor neemt het aantal foute bytes in absolute aantallen toe. Gezien de gigantische groei in datadichtheden op een schijf verbaast me eerder dat de error-rate niet stijgt.

Stel, je hebt een disk met een error-rate van 10^-12 (dus gemiddeld zal 1 op de 1,000,000,000,000 bytes verkeerd worden geschreven of gelezen), en je propt 1 TB (10^12 bytes) data op de schijf, dan kun je er dus verwachten dat er gemiddeld (let wel, gemiddeld) 1 byte op de schijf verkeerd is geschreven of wordt gelezen. De vraag is alleen: welke? :-)

RAID1, RAID5 & RAID10 kunnen je daar niet het antwoord op geven; je kunt wel een verschil detecteren, maar je weet niet welke van de 2 mirror schijven "gelijk" heeft (RAID1/RAID10), of dat de fout in het data- of pariteitsblok (RAID5) zit. Afhankelijk van de implementatie van de parity op een RAID6 array kun je wel bepalen welke van de blokken correct is.

De enige oplossing om dit soort dingen wel goed te kunnen detecteren is het inbouwen van checksums in het filesysteem, zodat per blok/stripe bepaald kan worden of de data nog correct is (en er natuurlijk rekening mee houden dat er in deze metadata ook fouten op kunnen treden....)

NB: een error-rate van 10^-12 lijkt heel weinig, en fabrikanten geven rates op van 10^-14...10^-15, dus nog een factor 100-1000 lager. (in 2005 was het meer rond 10^-13, zie bv. http://arxiv.org/pdf/cs/0701166.pdf). Maar goed, wie veel data heen en weer schuift op zo'n schijf zal dus vroeg of laat verkeerde bytes terugkrijgen.

Hier (en verder) ga je de mist in. Het is wel bekend dat er een leesfout is en waar.
Disks zijn voorzien van ECC wat betekent dat ze een bepaald aantal leesfouten binnen een blok kunnen herstellen en bij een groter aantal fouten kunnen aangeven dat het blok onherstelbaar is.
Er kan wel een fout optreden die niet gedetecteerd wordt, maar de kans daarop is wel heel klein.

Dus in het algemeen weet je prima welk blok van een mirror of parity set het onleesbare blok is en welke andere blokken je moet lezen om dat te herstellen.
Er komen pas problemen als die andere blokken ook niet leesbaar zijn.
En die situatie kun je soms tegenkomen als de redundantie al verlaagd was bijvoorbeeld door een disk te trekken.

RAID5 is dood?? Oooh shit, mijn farms!