Eind vorige week heeft het OpenZFS-project versie 2.1.0 van het ZFS-bestandssysteem en volume manager uitgebracht. De nieuwe release is compatibel met FreeBSD 12.2-RELEASE en nieuwer en Linux-kernels 3.10 tot 5.13. Er zijn wat prestatieverbeteringen doorgevoerd en er zijn een paar volledig nieuwe functies, vooral gericht op bedrijfsmatige en andere geavanceerde toepassingen. Een van de belangrijkste toevoegingen is de distributed RAID-functionaliteit. dRAID is sinds 2015 ontwikkeld en eind 2020 als beta aan OpenZFS toegevoegd.
Bij het creëren van een dRAID-virtual device of vdev, moet de administrator een aantal sectoren per stripe of datasegment aanwijzen voor data, pariteit en hotspare, actieve schijven die leeg gehouden worden voor het geval een andere schijf kapot gaat. Dit is onafhankelijk van het aantal fysieke schijven, zoals je in dit voorbeeld kunt zien. Er zijn 11 harde schijven waarmee een dRAID-vdev wordt opgezet met 2 pariteits-sectoren, 4 voor data en 1 als reserve, of in jargon een draid2:4:1. Hoewel er in totaal 11 schijven zijn worden er maar zes in elke data-stripe gebruikt, en één in elke fysieke stripe. In een ideale wereld zou de vereenvoudigde layout van een draid2:4:1-setup er zo uitzien:
D voor data, P voor pariteit en s voor spare/reserve.
dRAID maakt eigenlijk gebruik van hetzelfde onderliggende idee als raid 3, met een vaste pariteitsschijf, en het snellere raid 5 waarbij de pariteit over de volledige array verdeeld gedistribueerd wordt. dRAID breidt dit systeem uit, door ook de reserve-schijven te verdelen in sectoren op verschillende schijven. Als een schijf faalt wordt de inhoud hiervan geschreven naar de vrijgehouden ruimte op meerdere schijven, zoals je hieronder kunt zien.
De data en pariteitsinformatie van de defecte schijf wordt geschreven naar de vrijgehouden ruimte op andere schijven.
Deze diagrammen zijn gesimplificeerd, in werkelijkheid komen er groepen, slices en rijen aan te pas en wordt de layout gepermuteerd om de data gelijker te verdelen. Voor geïnteresseerden is daarover een uitgebreid stuk commentaar toegevoegd in de code.
In onderstaande grafiek is de tijd die het kost om data van een verloren schijf te herschrijven weergegeven, uitgaande van een pool van 90 schijven. De bovenste, donkerblauwe lijn is de tijdsduur in het geval van een traditionele losse reserveschijf. De gekleurde lijnen daaronder laten zien hoe lang dat zou duren met gedistribueerde vrijgehouden capaciteit, met drie verschillende pariteits-niveaus.
Een dRAID-vdev zal over het algemeen gelijkwaardig presteren aan een even grote groep van traditionele virtuele apparaten. De fouttolerantie is iets minder, waar raidz1 vaak nog een tweede kapotte schijf aan kan zolang deze in een andere vdev valt, zal bij dRAID een tweede defecte schijf waarschijnlijk sectoren bevatten van stripes die al geraakt waren door de eerste uitval. Deze ietwat verminderde betrouwbaarheid wordt gecompenseerd door de veel snellere reparatietijden. In een traditionele setup met een vaste reserveschijf duurt dit altijd zo'n 30 uur, in het geval van verdeelde extra ruimte kan dit in een uur al klaar zijn, aangezien de schrijflast verdeeld wordt over zo veel mogelijk schijven.
Distributed RAID is vooral bedoeld voor grote opslagservers, daarom zijn de meeste tests ook uitgevoerd rondom systemen van 90 hdd's. Voor beginnelingen met kleinere setups is de verhoogde complexiteit het waarschijnlijk niet waard, ook omdat de compressieniveaus lager zijn en de prestaties in sommige scenarios trager zijn door de stripes die verplicht een vaste lengte moeten hebben. Als consumentenschijven groter blijven worden zonder veel sneller te worden is het mogelijk dat dRAID met zijn snelle reparatietijden ook goed van pas komt voor kleinere systemen.
Wat voor consumenten met een kleinschalige nas misschien interessanter is, is dat het op niet al te lange termijn mogelijk moet zijn eenvoudig extra schijven toe te voegen aan de setup. Matthew Ahrens oprichter en ontwikkelaar van OpenZFS, heeft daarvoor een pull request geplaatst. Het gaat in dit geval om RAIDz, waarbij het mogelijk moet worden om zo nodig meer capaciteit te gebruiken, zonder dat de volledige array opnieuw opgebouwd moet worden.
Bron: Ars Technica
