Hoe schaalbaar zijn geneste RAID-levels?

[Q]

Hallo,

De context in deze post is een op Linux gebaseerde software RAID-array.

Disks worden steeds groter. 1 TB is nu eigenlijk de norm, 2 TB gaat dat vast worden. De vraag is nu hoe je een RAID-array zodanig opzet dat je deze kunt laten groeien waarbij je optimaal gebruik kunt maken van deze extra Disk capaciteit, zonder dat je de gehele RAID-array opnieuw moet opbouwen.

Ik ben begonnen met een 1.5 TB array op basis van 4x 0.5 TB Samsung disks. Al snel liep de array vol en ben ik aan de slag gegaan met een extra controller en 1 TB disks.

Maar wat doe je met je 0.5 TB disks als je met 1 TB disks aan de slag gaat? Ik heb bedacht dat het verstandig was/is om gewoon 'virtuele' 1 TB disks te maken van twee 0.5 TB disks. Ik stop twee 0.5 TB disks in een RAID 0 device en stop het resulterende device in de 'echte' RAID array.

Dit is hoe het nu bij mij werkt:



Dit is dus 4 TB RAID 6. De Array bestaat uit 6 devices waarvan dus 2 virtuele devices. Overigens is de array inmiddels gegroeid met 2 TB naar 6 TB.

Ik zou echter met het oog op de toekomst, waarmee ik doel op de 2 TB disks, een array opzetten die bijvoorbaat uitgaat van 2 TB disks door het zelfde trucje uit te halen. Ik maak gewoon virtuele 2 TB disks aan op basis van 1 TB disks en op een gegeven moment worden er 'echte' 2 TB disks bij geplaatst.

Mijn grote vraag is in hoeverre dit qua performance schaalt bij grotere aantallen disks, zeg meer dan 10 als in richting 20. Er worden in feite meerdere RAID-arrays aangemaakt die weer onderdeel worden van een grotere array. Is het dan bijvoorbeeld verstandig om te gaan denken aan een quad-core cpu (niet perse veel mhz)? Of wordt dit een grote bende?

Ik wil bereiken dat ik maar 1 mountpoint/device heb en niet allemaal losse arrays. LVM kan helpen maar geeft mi teveel overhead.

Als iemand nog links heeft naar goede benchmarks van dit soort grote Linux RAID-arrays hou ik me aanbevolen. Met name RAID50 en RAID60 vind ik interessant.

[ Voor 3% gewijzigd door Q op 26-05-2009 23:24 ]

[TERW_DAN]

Wat betreft snelheid zal het waarschijnlijk voor een deel wel liggen aan de controller die je gebruikt. Ik zou jouw idee liever doen met een dedicated controller waar je de onderliggende array's van maakt.
Logischerwijs lijkt het me dat op het moment dat je meerdere RAIDlevels tegelijkertijd aanspreekt dit natuurlijk wel meer belasting zal leggen op je cpu, als dat je het doet met 1 array die geen sub array's bevatten.
Benchmarks heb ik er niet van, maar het lijkt me dat er gewoon meer rekenwerk gedaan moet worden, en dat zal je in elk geval toch terug gaan zien in de performance (al dan niet kwa throughput, danwel in cpu usage).

[Fauna]

Ik zou het meer van de toegangstijd-kant bekijken. Immers, soft- en hardwareassised-RAID setups hebben zowat altijd een hogere accesstime. Als je RAID-levels gaat stapelen/nesten zal dit waarschijnlijk alleen maar hoger worden. En dan heb ik het nog niet over de eventuele hogere accesstime van de schijven zelf in het geval dat de kleinere disk van een eerdere generatie is.

Dit zal zich dus waarschijnlijk uiten in een minder goede schaling in random-performance. De troughput zal afhankelijk zijn van de traagste disk.

Je zou eigenlijk zelf de benchmarks moeten draaien. Nested RAID-levels zijn niet heel gangbaar, laat staan als je maar een deel nest.

[Guru Evi]

Als je gewoon expansie wilt dan zou ik een volume aanmaken met een bestandssysteem die kan vergroten/verkleinen. Dan maak je gewoon de RAID arrays aan met volgende generaties van harde schijven en de verschillende RAID volumes gebruik je in een JBOD configuratie alszo:

|     LOGISCH VOLUME       |
|RAID 5  | RAID 5 |  RAID5 |
|1T|1T|1T|2T|2T|2T|xT|xT|xT|

Een andere oplossing is om een hardware RAID controller of enclosure te halen die expansie of omvorming van het RAID array toelaat. Dan kun je gewoon schijven bijsteken en zelfs uithalen en de RAID controller gaat het array uit zichzelf configureren en vergroten.

[AlexanderB]

het snelste zal altijd blijven gewoon een nieuwe array van de dan grootst/snelste disks, als je al die oude "halve" schijven dr in houd, geeft een hoop IO overhead, en meer energieverbruik, nergens voor nodig dus..
500 gig en 1tb schijven kun je nog wel voor n redelijke prijs verpatsen

[Q]

Een punt waar ik niet zo heel erg bij stil heb gestaan is dat extra RAID-lagen ook latency toevoegen. Voor simpele filetransfers (weinig parallel) is dat niet zo'n punt.

Wel kan ik mij voorstellen dat het lonend is om bijvoorbeeld een quad-core processor in te zetten, die niet perse heel snel hoeft te zijn, maar die vooral parallel taken kan afhandelen, dus de verschillende levels.

De oplossing zoals aangedragen door Guru Evi kost mij teveel qua overhead, in het voorbeeld ben je al 3 disks aan parity kwijt. Alhoewel: je zou een array kunnen maken op basis van 1 TB disks, en een apparte array op basis van 2 TB disks en die dan in een JBOD gooien. Alleen toegegeven: met een grotere array wil je eigenlijk kleinere raid5 arrays maken, maar dat kost telkens een disk. Het meest efficient qua opslag is toch een grote array.

Ik kom ook een beetje tot de conclusie dat ik zelf beter kan gaan benchen. Hoe ik ook zoek, op Internet vind ik weinig informatie. Toch vind ik mijn voorstel niet zo heel geschift.

Ter informatie: mijn huidige 6 TB RAID 6 (dus 8 tb kale capaciteit) doet lezen: 200 mb/s en schrijven: 125 MB/s. Kan gigabit aan dus is snel genoeg. iostat laat zien dat een aantal disks minder worden belast, dus mogelijk is hij niet helemaal goed aligned en kan er nog meer read-performance uit gehaald worden, maar heel veel maakt het me niet uit.

AlexanderB schreef op woensdag 27 mei 2009 @ 18:32:
het snelste zal altijd blijven gewoon een nieuwe array van de dan grootst/snelste disks, als je al die oude "halve" schijven dr in houd, geeft een hoop IO overhead, en meer energieverbruik, nergens voor nodig dus..
500 gig en 1tb schijven kun je nog wel voor n redelijke prijs verpatsen

Het idee was juist om huidige 1 TB disks meteen in virtuele 2 TB disks om te zetten, zodat er geen nieuwe array hoeft te worden gebouwd op basis van 2 TB units. Ik denk eigenlijk dat het beste is om gewoon maar eens te gaan testen. Stel ik neem 10 x 1TB disks, dus maak ik 5x 2 TB virtuele disks, zeg md0---md4 en van die devices maak ik een RAID 6 als md9 ofzo, Een stripe array lijkt me vrijwel geen belasting te geven.

[ Voor 64% gewijzigd door Q op 28-05-2009 00:05 ]

[Guru Evi]

Het probleem met de virtuele disks etc. is dat de 2TB schijven geen 2TB zijn (dank u wel hard disk fabrikanten om een kilobyte 1000 byte te maken). 2x 1TB schijven gaan waarschijnlijk iewat groter zijn dan 1 2TB schijf.

Dat is momenteel al het geval met 500GB vs 1TB (afhankelijk van de schijven natuurlijk):

500G = ~480G bruikbare ruimte x 2 = 960G
1T = ~930G bruikbare ruimte

Dus zit je ongeveer met 30G per virtuele schijf die je moet weggooien en met de 2TB schijven gaan die verschillen nog groter worden. Als je echter een fout maakt in de berekening en niet genoeg weerhoudt dan heb je een te grote 2TB 'virtuele' schijf waardoor je je RAID niet kunt vergroten (alle schijven moeten hetzelfde volume bieden).

Mijn oplossing heeft natuurlijk overhead maar daar heb je dan een degelijke bescherming voor (en de overhead verkleint naargelang je meer schijven toevoegt. Jouw oplossing heeft een heleboel meer overhead omdat je virtueel lagen toevoegt die de performance alleen maar omlaag zullen brengen. De performance van je schijven gaan niet zodanig omhoog gaan naargelang je grotere schijven koopt behalve als je een snellere controller/computer koopt met de nieuwe schijven en de nieuwe schijven betere latency krijgen.

Je kunt ook eens kijken naar RAID-Z (ZFS). Ik weet niet of dit de mogelijkheid biedt verschillende schijven met verschillende specificaties te gebruiken.

Een andere oplossing zou zijn je schijven op te breken in virtuele schijven met een grootte van de kleinste schijf. Dus als je kleinste schijf 500G is, dan maak je 2 500G virtuele schijven van je 1TB schijf en 4 500G virtuele schijven van je 2TB schijf en dan kun je daar RAID 5 over zetten. Opnieuw: de groottes kunnen verschillen dus is het mogelijk dat je geen 2 500G partities van een 1TB kunt maken maar 2x 480G en dat moet je extrapoleren naar de 2TB schijven.

[Robtimus]

Guru Evi schreef op donderdag 28 mei 2009 @ 16:52:
Het probleem met de virtuele disks etc. is dat de 2TB schijven geen 2TB zijn (dank u wel hard disk fabrikanten om een kilobyte 1000 byte te maken). 2x 1TB schijven gaan waarschijnlijk iewat groter zijn dan 1 2TB schijf.

Dat is momenteel al het geval met 500GB vs 1TB (afhankelijk van de schijven natuurlijk):

500G = ~480G bruikbare ruimte x 2 = 960G
1T = ~930G bruikbare ruimte

Volgens mij is 500G nog altijd 500 / 1.024 / 1.024 / 1.024 = ~465 bruikbare ruimte, voor een totaal van... 930!

[Fauna]

En bij 1T heb je nog een extra deling door 1024, waardoor je een nog groter verschil krijgt

[Robtimus]

1TB is gewoon 1000GB als het op harde schijven aankomt, en is dus gewoon 930GiB. Maar idd, slechts 0.91TiB.

[Q]

Dames, heren,

Ten opzichte van een 'echte' 1 TB schijf verlies ik maar heel weinig qua opslag als ik een virtuele schijf van 1 TB bouw uit twee 500 GB disks. Het verschil is misschien honderd mb ofzo. Dus dat is geen punt.

Echte 1 TB schijf: 1000120.03 MB

Echte 500 GB Schijf: 500023.00 MB --> 2x = 1000046.00

Scheelt zo'n 80 MB.

Ik lees hier een idee over het opsplitsen van een grote disk in kleinere virtuele disks, die je dan kunt gebruiken om arrays mee te bouwen. Doe dat niet!. Je krijgt dan dat 1 of meer disks lid is van meerdere arrays. Dus als 1 disk klapt en je deze vervangt, moeten tegelijkertijd meerdere arrays gaan rebuilden over dezelfde disks. Volgens mij stor je hele systeem dan in vanwege de absurde IO belasting die je dan krijgt.

[ Voor 58% gewijzigd door Q op 29-05-2009 21:32 ]