Navigatie overslaan.
Start

RAID en partities

Ik dacht dat het triviaal was, maar men doet het bijna altijd verkeerd.
Dus hier is iets om in uw oorkes te knopen:

Een RAID volume mag je NIET partitioneren! (Disk partities, zoals met fdisk.)

Natuurlijk kan je dat wel doen, en zo goed als altijd doet men dat ook, maar dat is dus helemaal niet de bedoeling.
Hier is waarom:

We gaan ervan uit dat we een hardware RAID controller gebruiken in RAID-1 (Mirroring) met 2 harde schijven.
Er zijn 2 partities, een O.S. partitie, en een Data partitie.

Er zijn 2 manieren om dit op te zetten:

Methode 1: De verkeerde manier die ik in 99% van de gevallen tegenkom.

Maak via het BIOS van de RAID controller één groot RAID-1 volume, partitioneer dit RAID volume in 2 partities

Methode 2: De correcte manier

Maak via het  BIOS van de RAID controller twee RAID-1 volumes, ter grootte van de partities. Ieder RAID volume is één, en slechts één, volledige partitie.

Waarom?

RAID werkt op Block-level en weet absoluut niet wat er op de hogerliggende lagen gebeurd. Dit kan een voordeel zijn, maar ook een nadeel.

Intellingen (Performance)

Een O.S. partitie en een Data partitie zijn 2 verschillende zaken die een verschillende aanpak vereisen inzake performance. Ook RAID parameters hebben een grote impact op performance.
Het is dus logisch om dit als 2 verschillende RAID volumes aan te maken met verschillende parameters.

Caching (Performance)

Een RAID controller doet aan caching. Laat de RAID controller dat dan ook doen.
Met 2 RAID volumes, kan de RAID controller per partitie aan caching doen. Dit heeft ook een enorme invloed op performance.
Met slechts 1 RAID volume, kan er nooit efficiënt gecached worden.

Resizing

RAID controllers kunnen vaak RAID volumes resizen. Of dat ook nuttig is, hangt ervan afwat er in het RAID volume zit.
Is er maar 1 partitie, dan is dat geen probleem, zitten er meerdere partitie in, dan kan je vaak niet resizen, of enkel de laatste partitie.

Errors

Moest er een slechte sector ontstaan op de schijf, dan is dat op een bepaalde locatie in dus ook in een bepaalde partie.
Bij methode 1 verlies je je redundancy voor ALLE partities aangezien het een volledig RAID volume is dat geaffecteerd wordt.
Bij methode 2 enkel de partitie die zich in het geaffecteerde RAID volume bevindt.

Rebuilding (Performance)

De meeste (+/-80%) errors verdwijnen na een disk reset. (Disken zelf hebben ook error recovery d.m.v. spare sectors.)
Het RAID volume moet echter wel gerebuild worden. Hoe kleiner het volume, hoe sneller je terug volledig redundant kan werken, en hoe minder performance impact dit heeft.
Bij meerdere RAID volumes, heeft het rebuilden van 1 volume ook bijna nooit een performance impact op een ander RAID volume, dus heb je 2 keer een voordeel.

Praktisch

In de praktijk wil je natuurlijk zo flexibel mogelijk werken en de partitionering bijvoorbeeld dynamisch aanpassen al naargelang de groei van bepaalde partities.
Hoe je dit het beste doet, is door een aantal RAID volumes te creëren voor bepaalde doeleinden. Deze kunnen dan geoptimalisseerd worden voor Read of Write performance, Grootte van het volume, dubbele reduncancy, etc...

Deze volumes bestaan dus steeds uit slechts 1 partitie.

Deze partities mag je dan wel weer logisch opdelen met bijvoorbeeld LVM. (http://en.wikipedia.org/wiki/Logical_Volume_Manager_(Linux))
Op die manier kan je RAID volumes van dezelfde "soort" combineren, of verder opdelen.

En vergeet niet, Voor performance moet je ongeveer 0.1% caching voorzien. D.w.z. 1GB cache voor een 1TB disk.

In de meeste gevallen is RAID echter tijdverlies. Je kan veel beter LVM gebruiken met daarin een filesystem dat ingebouwde redundancy heeft (bijvoorbeeld: http://en.wikipedia.org/wiki/ZFS, of http://en.wikipedia.org/wiki/BTRFS), tenzij je natuurlijk opgescheept zit met een Microsoft besturingssysteem...