Arnoud1 schreef op vrijdag 18 maart 2011 @ 00:21:
[...]
Vergeet ook niet dat ZFS na hardware raid kwam om de beperkingen van bestaande filesystemen op te vangen. Raid is nooit gemaakt om samen te werken met ZFS en de houding van raid tegenover slechte schijven is net waarom raid in enterprise systemen gebruikt wordt! Een schijf die voor 80% goed is wil je dan echt niet meer gebruiken.
RAID is juist ontworpen om géén dure schijven aan te hoeven schaffen. In een tijd waarbij je moest kiezen tussen dure betrouwbare schijven en goedkope maar minder betrouwbare schijven, was een techniek om één betrouwbaar medium uit meerdere minder betrouwbare disks te destilleren een hele interessante en vernieuwende optie.
RAID gaat dus specifiek over kostenbesparingen en goedkope hardware. De I in RAID staat origineel voor Inexpensive. Hedendaags zijn we behoorlijk afgedwaald, en fabrikanten hebben RAID juist als een melkkoe gezien. Vandaar ook dat ze de 'RAID dropout' probleem niet willen fixen; ze verdienen er grof geld aan waarom zouden ze het fixen kost ze heel veel geld omdat ze geen RAID edition hardeschijven meer kunnen verkopen.
Zie ook de blog van Jeff Bonwick, lead dev van ZFS:
The original promise of RAID (Redundant Arrays of Inexpensive Disks) was that it would provide fast, reliable storage using cheap disks. The key point was cheap; yet somehow we ended up
here. Why?
url:
http://blogs.sun.com/bonwick/entry/raid_zIk vraag mij ook af waar die legende over 'geen hardware raid kaarten gebruiken' ontstaan is. Al 3 jaar lang een hardware raid 5 (3Ware 9550SXU-ML + BBU) en 7 gewone schijven van 1TB (Seagate Barracuda 7200.11) en nog nooit is er een schijf uitgekickt.
Dus, omdat jouw array er nog nooit mee te maken heeft gehad, bestaat het probleem niet? Oudere schijven hebben sowieso veel minder last van uBER; het zijn vooral nieuwe schijven met een hoge datadichtheid die problemen met uBER krijgen. WD20EADS is berucht omdat het duizenden pending sectors kan ontwikkelen doordat de ECC in veel gevallen tekort schiet. Bij 4K sector disks zou je dit probleem minder moeten hebben.
Je kunt kijken in je SMART output. Current Pending Sector is de waarde waardoor een schijf uit de RAID zal vallen. Deze hoort altijd 0 te zijn. Als je Reallocated Sector Count niet 0 is, dan heb je in het verleden dus actieve bad sectors gehad. Zonder bad sectors heb je geen last van uitvallende schijven, dus dat is een voorwaarde. Het probleem is dus dat moderne schijven relatief veel vaker last krijgen van uBER.
Een schijf kicken gebeurd echt wel met redenen. Niet bij kleine foutjes, wel bij ernstige die moeten opvallen.
Een schijf wordt eruit gekickt als de controller een tijd lang geen reactie krijgt op zijn commando. Dat noemen we een timeout en die staat meestal op 10 seconden voor de meeste hardware RAID. Daarom is de TLER functie ook uitgevonden: de RAID controller zal dan geen timeout genereren en de disk eruit trappen. Het gevaar van TLER is dat je hardeschijven al heel snel opgeven bij bad sectors en dus de kans dat ze die kunnen recoveren erg klein is.
Het is niet omdat je een hardware raid kaart hebt dat je die functionaliteit moet gebruiken. Voor zover ik weet ondersteund iedere kaart pass trough (zie verder).
Elke controller kan het anders ondersteunen, maar bijvoorbeeld Areca dropt nog steeds disks in Passthrough mode of JBOD mode; dus deze controller is in welke modus dan ook ongeschikt. Daar zit je dan met je dure controller!
Pass through en JBOD zijn totaal verschillende dingen. Bij pass through heb je GEEN ARRAY. De schijf wordt gewoon doorgegeven aan het OS en die moet er maar zijn ding mee doen.
Bij JBOD heb je meestal 'spanning'. Meerdere schijven vormen een array, zonder dat de voordelen van raid gebruikt worden.
Bij zowel PassThrough als JBOD mode heb je een SCSI array: één disk per array. Je disks zullen als SCSI disks worden gezien, niet als ATA disks. Je kunt niet normaal SMART opvragen, alleen door passthrough module van je RAID controller (zoals areca of highpoint in smartctl -d). Het blijft dus een RAID array, waarbij de RAID firmware de controle heeft over je disks. Als die besluit je disk eruit te schoppen, dan heeft ZFS daar NIETS over te zeggen. Dát is het hele probleem.
JBOD wordt gebruikt voor verschillende dingen:
- non RAID HBA mode
- RAID mode waarbij elke disk zonder metadata als passthrough wordt geconfigureerd
- spanning/concatenating (RAID0 achtige array maar zonder snelheidswinst)
Voor ZFS gebruik je best pass through en geen JBOD.
Voor ZFS gebruik je het beste een NON-RAID controller ook wel HBA genoemd. Intel SASUC8i in IT-mode is een uitstekende keuze. Je onboard AHCI poorten zijn de beste poorten die je kunt hebben. Bij al deze non-RAID adapters is het zo dat het OS bepaalt of de schijven eruit worden getrapt; niet de controller. Dat is dus wat je wilt.
En omdat je bij pass through geen array hebt is er geen sprake van degradatie of dergelijke.
Je hebt gewoon 8 arrays; voor elke disk een array. Performancedegradatie heb je altijd bij een RAID controller; alle latencies zijn ongeveer 0.1ms hoger door de verwerkingstijd van de firmware. Een echte HBA is dus sneller.
ZFS is gewoon een bestandsysteem met lvm en heeft op zich niet rechtstreeks met raid functionaliteit te maken. ZFS kent een softwarematige raid implementatie die in wezen niet verschilt van hardware raid. De foutcorrectie zit hem in het bestandsysteem zelf en die doet dat dus beter dan raid.
Dat is dus onjuist. Als wat je zou zeggen zou kloppen, dan zou het theoretisch mogelijk zijn om ZFS RAID na te bouwen met een andere driver, die niet het hele ZFS filesystem hoeft te kennen. Dat lukt dus niet - de manier hoe ZFS RAID doet is eigenlijk géén RAID! Daarom wordt ZFS ook wel een 'layering violation' genoemd, omdat het filesystem en RAID engine met elkaar versmelt; de RAID engine moet dingen van het filesystem weten en andersom; geen enkel project wat zo werkt!
De manier hoe ZFS zijn data opslaat zal dan ook nooit door een RAID controller te implementeren zijn. Dynamische stripesizes bijvoorbeeld zijn niet mogelijk als filesystem en RAID layer gescheiden producten zijn. De stripesize wordt aangepast naar de grootte van het bestand.
Zie ook:
http://blogs.sun.com/bonw...ampant_layering_violationWaar ik ook nog eens op wil wijzen is dat raid kaarten met een BBU werken en hierdoor je data beschermen bij stroomuitval.
Je kunt het anders omschrijven: RAID controllers met write-back zijn inherent onveilig, omdat bijna alle filesystems niet genoeg foutcorrigerende middelen hebben om zonder schade te recoveren van verloren transactie metadata. De RAID controller doet dus onveilige writeback met een BBU. Zonder die write-back schrijf je met 5MB/s naar een RAID5, dus een BBU is min of meer verplicht.
Dus RAID controller + BBU + RAID edition schijven (TLER) is een dure aangelegenheid. Vergelijk met een non-RAID controller zonder BBU of UPS met normale desktop schijven en het slimme ZFS filesystem zorgt voor de veligheid; ideale keus IMO. Dan heb je ook al die dure hardware niet nodig, die profitteert van de onduidelijkheid over problemen met RAID.
Indien je dus niet met zo'n kaart wil werken met je een externe BBU voorzien op je NAS of met flashcache werken. Ik denk dat velen hier geen rekening mee houden.
Ik weet niet pecies wat je wilt zeggen, maar ZFS heeft geen BBU nodig. ZFS kan heel snel naar RAID5/6/7 achtige vormen schrijven zonder bescherming van een UPS nodig te hebben; dat is alleen voor filesystems zonder goede intent log of zonder write barriers. ZFS heeft de ZFS Intent Log (ZIL) - een softwarematige manier van journaling die de hele BBU enzo vervangt. Foetsie! Scheelt weer doekoe.

Daar is ZFS dus immuun voor. uBER kan er wel voor zorgen dat één of meer bestanden beschadigd raken. Dit krijg je te zien met zpool status -v output, precies welke bestanden. Silent corruptie heb je dus nooit meer, en je hele array gaat ook niet aan gort door uBER zoals wel met veel conventionele RAID.
Zelfde geldt voor RAID6 overigens:
http://www.zdnet.com/blog...stops-working-in-2019/805