Raid 5 of toch maar niet?

[sdk1985]

Ik wil graag een nieuwe NAS oplossing omdat ik momenteel tegen een paar dingen aan loop

1) Mijn huidige NAS zit aardig vol (+- 10 TB via 6 losse disks)
2) Ik zou graag een deel van de data beschermen tegen hardware defecten (TV series waarvan in het niet waard vindt om een volledige backup te bewaren)
3) Ik heb een aantal backups die ik graag wil beschermen tegen hardware defecten waarvan ik wel duplicatie heb (denk aan 30 dagelijkse backups van een website, foto's , etc).

Dat alles samen kwam ik in eerste instantie uit op een Raid 5 array van 3x 5 TB. Het is nog redelijk betaalbaar (met desktop schijven) en levert 10 TB aan opslagcapaciteit. Bij een defecte disk zou ik de data moeten kunnen herstellen.

Vervolgens kwam ik op dit artikel dat het gebruik van Raid 5 voor huidige schijven af raad op basis van rebuild errors: http://www.zdnet.com/arti...e-raid-5-on-small-arrays/

Alternatief is een Raid 1 maar ik weet niet of dat echt waarde toevoegt tov scripts die zelf de gewenste data naar een andere disk clonen (rsync ofzo). Zo zou ik één 8 TB schijf kunnen kopen waar alle belangrijkere mappen lokaal op worden gedupliceerd.

Verder vraag ik mij af hoe het precies zit het met raid 1? Kan die "live" een nieuwe lege schijf vullen zonder dat de data tijdelijk niet toegankelijk is?

Zie ik verder iets over het hoofd?

[redfoxert]

RAID-1 kent hetzelfde probleem als RAID-5. Bij een full rebuild is de kans groot dat er ergens een non-recoverable error ontstaat. De hoeveelheid data op je disk is groter dan de marge waarin de fouten zich voordoen, zeker met een 8TB disk.

[Verwijderd]

Why RAID5 stops working in 2009

Dit artikel stipt het probleem aan van steeds groter wordende kans op bad sectors bij het toenemen van de datadichtheid, terwijl de mogelijkheden voor errorcorrectie (ECC) gelijkblijven. Dan is het een kwestie van tijd voordat bad sectors zonder fysieke schade een steeds groter probleem worden. Kortom, consumenten schijven zijn min of meer ontwikkeld om bad sectors te genereren, ook als er totaal geen fysieke schade aanwezig is.

Bij maximale belasting (100% duty cycle) kan dit probleem oplopen tot gemiddeld één bad sector per dag, alhoewel eens per paar maanden een normalere frequentie is gezien de veel lagere duty cycle van 1% voor typisch consumentengebruik.

RAID5 vandaag de dag is gewoon niet zo slim. Alleen RAID6 met enterprise schijven die tot 100 keer minder bad sectors genereren (uBER 10^-16) is nog betrouwbaar. In plaats van hele dure hardware te kopen, kun je ook kijken naar slimme software. En dan kom je uit op ZFS. En dat is wat bijna iedereen hier doet: een ZFS NAS bouwen met goedkope consumenten hardware zoals WD Green drives.

ZFS is ideaal voor zowel zeer belangrijke data waar je backups ook op ZFS hebt zodat je het risico van corruptie die naar je backups sluipt kunt beheersen, alsmede data waarvan je géén backup hebt en het origineel dus goed genoeg beschermd moet zijn zodat je geen backup nodig hebt. Nogal onzinnig als je je data verliest door enkele plekjes op de schijf die niet gelezen kunnen worden. Vele RAID implementaties zijn daar erg gevoelig voor. ZFS is vrijwel immuun voor bad sectors en dat maakt het dé manier van opslag in dit tijdperk.

Wat mij betreft het overwegen waard dus. Kijk eens in Het grote ZFS topic en Het grote DIY RAID NAS topic deel 3 voor meer informatie.

[dcm360]

Verwijderd schreef op maandag 02 november 2015 @ 01:30:
Why RAID5 stops working in 2009

Dit artikel stipt het probleem aan van steeds groter wordende kans op bad sectors bij het toenemen van de datadichtheid, terwijl de mogelijkheden voor errorcorrectie (ECC) gelijkblijven. Dan is het een kwestie van tijd voordat bad sectors zonder fysieke schade een steeds groter probleem worden. Kortom, consumenten schijven zijn min of meer ontwikkeld om bad sectors te genereren, ook als er totaal geen fysieke schade aanwezig is.

Net als Enterprise schijven, die worden ook ontwikkeld om bad sectors te genereren (als ik dit verhaal door generaliseer). Verschil is echter dat daar betere (en duurdere) hardware wordt gebruikt waardoor het probleem kleiner is. Het blijft gewoon een kansverdeling.

Daarnaast 'vergeet' CiPHER in zijn verhaal dat je ook nog de tegenhanger van ZFS, BTRFS, kan gebruiken.

[Verwijderd]

Over 2 tot 5 jaar misschien; nu is ZFS het enige volwassen filesystem van de 3e generatie. En als we dan toch alle onvolwassen next-gen filesystems willen noemen, mogen zeker ook ReFS (Microsoft) en HammerFS (DragonFly BSD) genoemd worden.

[dcm360]

Ze mogen inderdaad wel genoemd worden, maar zo begint het wel heel erg op een lijstje 'brak, brakker, brakst' te lijken. BTRFS lijkt echter wel met een aardig vaartje bezig te zijn met het gat naar ZFS dichtlopen, en echt rare dingen (zoals een scrub die geen idee heeft wat die aanmoet met een raid-z) verdwijnen rap.

[Verwijderd]

Ik verwijs naar het 'stabiel' worden van Ext4 en het opnemen in de standaard Ubuntu installatie. Met als gevolg filesystem corruptie op vele duizenden installaties en upgrades. Production ready is iets wat relatief is. Bij BSD heeft ZFS vele jaren als 'experimental feature' gediend totdat het flink is uitontwikkeld en een niveau heeft bereikt wat men als 'production ready' acht. Mijn ervaring is dat vele partijen een veel lagere grens hanteren voor wanneer iets 'production ready' is. Ik denk zelf dat je voor iets als een filesytem best reden hebt om conservatief te zijn in deze.

[base_]

ZFS is leuk voor linux storage (en daar zeker production ready), helaas is het voor windows data stores minder geschikt, de CIFS/SAMBA durf ik niet in een iets groter zakelijk netwerk te gebruiken (krijg zowiezo heel veel lagere performance als windows <-> windows of nfs), en iSCSI of andere block storage oplossingen gooien het grootste deel van de voordelen van ZFS over de balk. Op FreeBSD bevalt ZFS uitstekend, maar als iemand mij kan vertellen hoe ik ZFS storage serieus kan gebruiken voor VM's/datastores voor microsoft servers hoor ik het graag

[Verwijderd]

base_ schreef op maandag 02 november 2015 @ 02:58:
ZFS is leuk voor linux storage (en daar zeker production ready)

Zeker weten! Je hoeft maar een update te doen en alles blijft werken!

Helaas is het voor windows data stores minder geschikt, de CIFS/SAMBA durf ik niet in een iets groter zakelijk netwerk te gebruiken

Zegt misschien iets over jouw gebrek aan vertrouwen? SMB/CIFS en andere NAS-protocollen zijn dé manier om data op ZFS op te slaan vanaf Windows-omgevingen.

en iSCSI of andere block storage oplossingen gooien het grootste deel van de voordelen van ZFS over de balk. Op FreeBSD bevalt ZFS uitstekend, maar als iemand mij kan vertellen hoe ik ZFS storage serieus kan gebruiken voor VM's/datastores voor microsoft servers hoor ik het graag

Als je SAN-protocollen zoals via iSCSI wilt gebruiken, kan dat prima. Je hebt de voordelen van ZFS omdat je de onderliggende opslag beveiligt. Je beveiligt niet meer de individuele bestanden, omdat Windows impliceert dat je een legacy filesystem gebruikt zoals NTFS, want ReFS is nog lang niet volwassen/bruikbaar laat staan universeel inzetbaar.

Je bescherming zit hem in het feit dat je snapshots kunt gebruiken op de iSCSI data store, zodat je snapshots kunt maken van je volume die op dat moment zich in een consistente staat bevindt. Als dit niet genoeg voor je is, dan is elk SAN-protocol niet genoeg en dien je over te stappen naar een NAS-protocol.

[base_]

Verwijderd schreef op maandag 02 november 2015 @ 03:02:
[...]

Zeker weten! Je hoeft maar een update te doen en alles blijft werken!

Ik bedoelde BSD, niet linux

[...]
Zegt misschien iets over jouw gebrek aan vertrouwen? SMB/CIFS en andere NAS-protocollen zijn dé manier om data op ZFS op te slaan vanaf Windows-omgevingen.

Waarom haal ik dan 10x minder throughput op cifs als windows <->windows?
Hoe goed is de AD integratie met server 2012R2?
ik heb er weinig success mee i.i.g., cifs lijkt nog steeds een hack om windows filesharing en DS op linux/bsd te draaien. Voor thuis werkt dat prima, maar als er bijvoorbeeld ook intensief filelocking gebruikt wordt of versioning is e.e.a. wat moeilijker.

[...]
Als je SAN-protocollen zoals via iSCSI wilt gebruiken, kan dat prima. Je hebt de voordelen van ZFS omdat je de onderliggende opslag beveiligt. Je beveiligt niet meer de individuele bestanden, omdat Windows impliceert dat je een legacy filesystem gebruikt zoals NTFS, want ReFS is nog lang niet volwassen/bruikbaar laat staan universeel inzetbaar.

Die onderliggende opslag beveiligen is wel een beetje vergelijkbaar met RAID (ZFS heeft duidelijk meer voordelen) voor RAID heb ik echter een controller nodig, voor ZFS een OS (+computer of VM).
Doet ZFS overigens niet beschermen tegen bitrot op bestandsnivo?
lol @ wiki trouwens: Because ReFS was designed not to fail, if failure does occur, there are no tools provided to repair it.

Je bescherming zit hem in het feit dat je snapshots kunt gebruiken op de iSCSI data store, zodat je snapshots kunt maken van je volume die op dat moment zich in een consistente staat bevindt. Als dit niet genoeg voor je is, dan is elk SAN-protocol niet genoeg en dien je over te stappen naar een NAS-protocol.

Snapshots zijn met name ook m.b.t. restore tijd een groot voordeel, even een paar terabyte terugzetten duurt nogal lang, restoren naar vorige snapshot meestal niet.

[jan99999]

ZFS doet net wel "Doet ZFS overigens niet beschermen tegen bitrot op bestandsnivo?, wel ZFS raid gebruiken. ZFS doet een checksum op elke file, en bij gebruik van raid kan dit ook nog gerepareet worden.

[Verwijderd]

base_ schreef op maandag 02 november 2015 @ 03:33:
Ik bedoelde BSD, niet linux

Oh, gelukkig.

Waarom haal ik dan 10x minder throughput op cifs als windows <->windows?

Geen idee, hangt helemaal van je configuratie af. Bij 10G is optimalisatie vaak noodzakelijk. Ook multipathing wat in de nieuwe SMB versie zit, is daarbij zeer nuttig. Voor gigabit werkt het out-of-the-box eigenlijk wel prima. Omgekeerd hoor ik ook regelmatig over NFS-specifieke performanceissues. Dus helemaal uniek voor SMB is het niet.

cifs lijkt nog steeds een hack om windows filesharing en DS op linux/bsd te draaien. Voor thuis werkt dat prima, maar als er bijvoorbeeld ook intensief filelocking gebruikt wordt of versioning is e.e.a. wat moeilijker.

Previous versions werkt toch prima samen met ZFS? Intensieve filelocks ben ik ook benieuwd waar je op doelt; heeft dat zoveel performance impact als je veel clients aansluit? Je hebt wel een punt dat ik een ZFS server vooral in kleinere thuisomgevingen inzet en minder ervaring heb met grote netwerken en veel clients. Maar ook daar wordt ZFS ingezet en ook SMB gebruikt.

Die onderliggende opslag beveiligen is wel een beetje vergelijkbaar met RAID (ZFS heeft duidelijk meer voordelen) voor RAID heb ik echter een controller nodig, voor ZFS een OS (+computer of VM).

Software RAID kan toch ook prima; de tijden van hardware RAID zijn min of meer voorbij omdat dat alleen nodig was omdat Windows geen goede opslagtechnologie bood en nog steeds niet biedt - alleen gaat dat wel veranderen met ReFS.

Doet ZFS overigens niet beschermen tegen bitrot op bestandsnivo?

Of op LBA niveau als je volumes gebruikt, zoals bij iSCSI gebruikelijk is. Er kunnen dan snippertjes LBA (blocks) verloren gaan als deze de checksum niet meer doorstaan.

Nog steeds heb je voordelen van ZFS zoals dat je de integriteit van de onderliggende volume (wat jij 'RAID' noemt) kunt waarborgen, en je kunt snapshots gebruiken om altijd terug te kunnen keren naar een periode waarbij deze volumes consistent waren. Maar je verliest inderdaad de integriteitsbewaking op fileniveau want op zo'n iSCSI volume wordt vaak een legacy filesystem zoals NTFS gezet. Daarom zijn NAS protocollen als SMB en NFS superieur aan SAN protocollen als iSCSI en AoE.

lol @ wiki trouwens: Because ReFS was designed not to fail, if failure does occur, there are no tools provided to repair it.

Klinkt vreemd maar er zit een waarheid in. Want als iets te recoveren is, waarom zit dat standaard dan niet in het filesystem? Als het mogelijk is je data terug te halen, hoort je filesystem dit automatisch al te doen voor je. Dat we gewend zijn met een (veelal offline) utility te gaan knoeien met een filesystem is gewoon een teken dat dergelijke filesystems ouderwets zijn. Een modern filesystem repareert zichzelf en heeft geen (offline) utility nodig om files te recoveren. ZFS doet al heel veel zelf, maar benut ook zeker niet alle potentie van wat mogelijk is om data te recoveren.

Neem bijvoorbeeld een 2-disk stripe (RAID0) waarvan één disk kapot is, maar het bestand met copies=2 (ditto blocks) is opgeslagen. Die kan ZFS niet meer toegankelijk maken en daarvoor moet je dan zdb gebruiken. Erg jammer mijns inziens. RAID0 kan heel sexy geimplementeerd worden als je per dataset opgeeft ik wil copies=2 of copies=3 en dat dergelijke data dan de bescherming van een 2-way of 3-way mirror krijgt, en de rest dan bij het falen van een disk ontoegankelijk wordt (I/O error bij het lezen ervan). De metadata wordt standaard al met minimaal twee kopieën geschreven bij ZFS, dus alle filesystem structuur zou ook niet verloren gaan bij een stripe met disk failure.

@jan99999: ook zonder mirror/RAID-Z redundancy beschermt ZFS je tegen bad sectors, door middel van ditto blocks. Alle filesystem metadata wordt extra beschermd, dus ook op een enkele disk zonder RAID, out of the box. Je kunt je bestanden daarnaast extra bescherming geven door individuele datasets met copies=2 in te stellen.

[sdk1985]

Ik ben even gaan inlezen en kwam ook nog op dit alternatief: Windows Storage Spaces / ReFS. Hierbij wordt o.a. gemeld dat voor FreeNAS met ZFS 8 GB ram minimum is en 16 GB recommended. Klopt dit? Mijn huidige server heeft 4 GB ram en dat is tot nu toe echt overkill.

http://betanews.com/2014/...e-to-ditch-raid-for-good/

De on the fly data repair van ReFS klinkt in ieder geval goed daarnaast zou het geen CHKDSK meer nodig hebben door auto-healing.