Software RAID 5 CPU intensief op een homeserver?

[koen_92]

Hallo,

Momenteel heb ik hier thuis een home-server draaien.
Deze wordt vooral gebruikt voor data-opslag.
Daarnaast zitten er twee DVB-S2 kaarten in icm Mythtv (backend).
Hiermee is het mogelijk om (HD) Televisie op te te nemen.

Momenteel zitten er twee harde schijven in van ieder 2 TB.
Deze staan in RAID 1. (software-RAID)
Er is dus effectief 2 TB opslag.

Echter begint deze 2 TB een beetje vol te raken.
Nu kan ik er nog een keer 2x 2 TB bij kopen om de opslagcapaciteit te verdubbelen, maar wel de redundantie te behouden.

Het is ook mogelijk om er slechts 1 harde schijf van 2 TB bij te kopen en mijn RAID 1 array om te zetten naar RAID 5.
Dan bespaar ik 1 harde schijf uit met dezelfde redundantie.

Echter moeten er voor RAID 5 pariteits-berekeningen uitgevoerd worden, iets dat dus CPU-kracht kost.
Dit zal nog best wel veel zijn als er bijvoorbeeld 2 full-hd uitzendingen tegelijk opgenomen moeten worden
Als CPU zit er een Athlon X2 240e op 2,8ghz in.

Nu vraag ik me af:
Kunnen de harde schijven en de CPU dit aan?

[Bloom]

Ja, geen enkel probleem.

[lord4163]

Dat lijkt me ook niet, dat is een redelijk krachtige processor voor een Server/NAS. RAID 5 heeft maar 3 schijven nodig, misschien verstandiger om die eerst vol te maken dan en dan misschien de 4e schijf (bespaar je ook weer 8w  )

[koen_92]

Ja, natuurlijk zet ik er eerst 1 schijf  bij.
Ik moet nog wel bedenken hoe ik dit op een veilige manier omzet.
Ik denk dat ik eerst even van iemand anders een schijf leen en die als backup ga gebruiken.

Wikipedia heeft er ook iets over gezegd:

Over the history of hard disk drives, the increase in speed of commodity CPUs has been consistently greater than the increase in speed of hard disk drive throughput.[22] Thus, over-time for a given number of hard disk drives, the percentage of host CPU time required to saturate a given number of hard disk drives has been dropping. e.g. The Linux software md RAID subsystem is capable of calculating parity information at 6 GB/s (100% usage of a single core on a 2.1 GHz Intel "Core2" CPU as of Linux v2.6.26). A three-drive RAID 5 array using hard disks capable of sustaining a write of 100 MB/s will require parity to be calculated at the rate of 200 MB/s. This will require the resources of just over 3% of a single CPU core during write operations (parity does not need to be calculated for read operations on a RAID 5 array, unless a drive has failed).

En jullie hebben gelijk: Het valt allemaal wel mee met de CPU-load.

En dan nog iets:
Grub kan niet booten vanaf een raid5 array toch? Dan moet ik dus eerst nog een aparte /boot maken.

[Bloom]

Tegenwoordig kan Grub (Grub2 althans) wél booten van een RAID-5 array. Maar een aparte boot is zeker geen slecht idee. Kun je zelfs een usb-stick voor gebruiken...

[flyerman]

Mag ik vragen wat het nut is om tv programma's op te nemen op een raid config, dat is toch zonde van je ruimte cq schijven?

[koen_92]

Ja, daar heb je een punt ja.
Maar er staat ook andere (wel belangrijke) data op.
Dan kan ik natuurlijk wel 2 partities maken, of de tv-programma's op een andere schijf opnemen die niet in RAID staat.
Maar dat is dan ook weer lastig, dan kies ik er liever voor om alles op 1 RAID array op te slaan.
En met RAID 5 kost dit maar 1 schijf, iets dat wel te overzien is in de kosten (opslagruimte kost niets meer tegenwoordig).

[flyerman]

ik zelf heb in mijn server drie schijven. Aparte partities voor films. Belangrijke dingen zoals documenten en foto's wordt elke dag van schijf 1 naar 2 en 3 gekopieerd met Rsync. En ook automatisch gesynchroniseerd naar Dropbox voor een externe backup.

[Johan van Dijk]

Ik heb net even wat testjes gedaan op mijn eigen computer.
Software RAID 5 van 4x WD10EADS schijven, AMD Athlon X2 Dual Core Processor BE-2350

Met de processor vastgezet op 1GHz haal ik gemiddeld 150 MB/sec
Met de processor op 2.1GHz haal ik gemiddeld 200 MB/sec
(gemeten met dd_rescue, schrijven naar /dev/null) _{Pas wel op, dd en dd_rescue kunnen wel je data vernietigen bij verkeerd gebruik}

Een enkele losse schijf haalt gemiddeld 80 MB/sec, ook weer met dd_rescue

Met een snellere Athlon X2 240e kan je dus je 1Gbit netwerkverbinding al helemaal benutten, zelfs op de laagste snelheid.

Om te booten kan je een kleine RAID1 maken aan het begin van de schijven. Die hoeft maar een paar 100 MB te zijn.
GRUB start prima op van een RAID1 volume.

[koen_92]

Oke, bedankt, dat gaat dus helemaal goedkomen

Nu nog 1 vraag:
Hoe krijg ik het allemaal netjes overgezet zonder data-verlies?

Ik heb nu in RAID 1:
/dev/md0 die bestaat uit /dev/sda1 en /dev/sdb1
sda1 en sdb1 zijn beide 2TB groot, en md0 dus ook.

Nu ga ik er dus 1 schijf bijkopen van ook 2TB en dan wil ik dus krijgen:
/dev/md0 van 4TB in raid5 die bestaat uit:
/dev/sda1, /dev/sdb1 en /dev/sdc1 van ieder 2TB.

Verder kan ik van iemand 1 2TB-schijf lenen, om als backup te gebruiken. (Deze zal dus tijdelijk te vinden zijn onder /dev/sdd)

Is het dan mogelijk om dit zo over te zetten (vanaf live-cd):

Code: [Selecteer]

mount /dev/sdd1 /mnt/tmp
dd if=/dev/md0 of=/mnt/tmp/backup.img
mdadm --stop /dev/md0
mdadm --create /dev/md0 --level=5 --raid-devices=3 /dev/sda1 /dev/sdb1 /dev/sdc1
dd if=/mnt/tmp/backup.img of=/dev/md0
Dan moet /etc/mdadm/mdadm.conf nog overgezet worden naar de nieuwe installatie en /boot nog apart gezet worden.
/boot kan ik dan eventueel op een Compact Flash-kaartje zetten. (Want shrinken van deze partities zie ik nou ook niet zo zitten)

Werkt dit zo?

[Johan van Dijk]

Je idee lijkt wel te kloppen ja.
Zo uit mijn hoofd weet ik alleen niet of alle details kloppen en of alles ook direct zo werkt. Mogelijk zou mdadm kunnen weigeren om een nieuwe md0 te maken als de oude nog bestaat, al is die gestopt.
Misschien dat je eerst even moet rebooten en misschien dat je de superblocks van de oude RAID1 schijven moet vernietigen.

Nog een tip:
Zorg dat je een werkende computer bij de hand hebt als je hiermee begint, zodat je bij problemen kan Googlen of hulp kan vragen op IRC of het forum. Verder is een goede portie geduld en een flinke bak koffie ook wel handig, want het doen van zulke ingrijpende bewerkingen kan lang duren

[Bloom]

Als je volume niet flink vol staat, is het wellicht beter om de bestanden met rsync te kopiëren dan om dd te gebruiken...

[koen_92]

Het leek mij slim om dit eerst eens in Virtualbox te proberen, en dan met schijven van 5GB ipv 2TB.
Het was even een gedoe, maar het is gelukt.

Omdat ik dit dan straks ook met mijn 2TB schijven wil gaan doen, leek het mij handig om even netjes op te schrijven hoe ik dit precies voor elkaar gekregen heb.
Het zou asociaal zijn om dit niet hier te delen, vandaar hier dus een uitgebreide uitleg:

Ik had in Virtualbox 5 schijven gemaakt (om het zo veel mogelijk op het 'echte' scenario te laten lijken):
/dev/sda - eerst raid1 schijf 1, moet: raid5 schijf 1 - 5 GB
/dev/sdb - eerst raid1 schijf 2, moet: raid5 schijf 2 - 5 GB
/dev/sdc - initieel ongebruikt , moet: raid5 schijf 3 - 5 GB
/dev/sdd /boot - 1 GB
/dev/sde - extra backup schijf - 5 GB

Eerst heb ik dus enkel /dev/sda en /dev/sdb gebruikt en hier Ubuntu in raid1 op geinstalleerd.

Vervolgens gaan we de live-cd starten.
Daarin eerst mdadm installeren.
Vervolgens /dev/md0 assembleren:

Code: [Selecteer]

# mdadm --assemble /dev/md0 /dev/sda1 /dev/sdb1
Dan backuppen. Hier moet gzip icm met dd gebruikt worden, omdat het image anders te groot is.

Code: [Selecteer]

# mkdir /mnt/tmp && mount /dev/sde1 /mnt/tmp
# dd if=/dev/md0 | gzip --fast > /mnt/tmp/backup.img.gz
Nu /dev/md0 stoppen, en superblock wissen (voor zekerheid):

Code: [Selecteer]

# mdadm --stop /dev/md0
# dd if=/dev/zero of=/dev/sda bs=1M count=10 && dd if=/dev/zero of=/dev/sdb bs=1M count=10
Nu nieuwe raid5 array aanmaken en backup terugzetten, mounten en mdadm.conf vervangen:

Code: [Selecteer]

# mdadm --create /dev/md0 --level=5 --raid-devices=3 /dev/sda1 /dev/sdb1 /dev/sdc1
# gzip -dc /mnt/tmp/backup.img.gz | dd of=/dev/md0
# mkdir /mnt/tmp2 && mount /dev/md0 /mnt/tmp2
# cp /etc/mdadm/mdadm.conf /mnt/tmp2/etc/mdadm
En dat werkt! 1 probleem: df -h /mnt/tmp2 geeft nog steeds de oude grootte terug (5GB) en nog geen 10GB. Dit is gelukkig eenvoudig op te lossen:

Code: [Selecteer]

# umount /dev/md0
# e2fsck -f /dev/md0
# resize2fs /dev/md0
En nu heeft de array ook de goede grootte!
Helaas lukt booten nog niet: root file-system kan niet gevonden worden.
Na wat zoeken, vond ik hier wel iets waar ik wat aan had. Er moet een nieuwe inititial ramdisk gemaakt worden. Dit kan door het pakket mdadm te reconfigureren, en daarvoor moet je eerst in je root-filesystem chrooten. Vanuit de live-cd kan dat dan zo (eerst natuurlijk weer mdadm installeren en /dev/md0 assemblen):

Code: [Selecteer]

# mkdir /mnt/tmp
# mount /dev/md0 /mnt/tmp
# mount /dev/sdd1 /mnt/tmp/boot
# mount --bind /dev /mnt/tmp/dev
# mount -t devpts devpts /mnt/tmp/dev/pts
# mount -t proc proc /mnt/tmp/proc
# mount -t sysfs sysfs /mnt/tmp/sys
# chroot /mnt/tmp
# dpkg-reconfigure mdadm
# exit

En als we dan rebooten, kan hij wel opstarten, waarmee de operatie dus gelukt is
Nu moet ik ditzelfde dus ook voor mijn 2TB schijven gaan doen, waar iedere stap waarschijnlijk >100x zo lang zal duren...

Kleine opmerking nog:
Ik heb tussendoor voor de zekerheid heel vaak gereboot, waar precies weet ik niet meer, maar naar iedere grote stap. Of het noodzakelijk was weet ik niet, maar het kan in ieder geval geen kwaad (het kost alleen maar tijd en koffie).

@Bloom:
Volume staat wel bijna vol, anders is het natuurlijk zonde van het geld om een extra schijf toe te voegen.
Maar rsync werkt volgens mij wel een stuk minder fijn, omdat er dan op file-niveau gekopieerd wordt.

Voor niet volle volumes is dd ook heel goed te gebruiken hoor. Je moet er alleen eerst voor zorgen dat de vrije ruimte opgevuld wordt met nullen, anders krijg je een image net zo groot als de hele harddisk, ipv net zo groot als de gebruikte ruimte.
Vanaf een live-cd kan dat zo: (hier is /dev/sda de bron en /dev/sdb het doel)
(Eerste 3 stappen voor iedere partitie herhalen)

Code: [Selecteer]

# mkdir /mnt/tmp && mount /dev/sda1 /mnt/tmp
# dd if=/dev/zero of=/mnt/tmp/nullen.img
# rm /mnt/tmp/nullen.img && umount /mnt/tmp
# mount /dev/sdb1 /mnt/tmp
# dd if=/dev/sda | gzip --fast > /mnt/tmp/backup.img.gz

In ieder geval:
Iedereen bedankt voor zijn/haar hulp!

[Johan van Dijk]

Bedankt dat je nog even gemeld hebt hoe je het hebt gedaan!
Dit zal vast wel handig zijn als iemand anders eens zoiets wil proberen

Overigens heeft mdadm ook gewoon een functie om de superblocks te wissen, dat lijkt me iets veiliger dan met dd een bepaald stuk overschrijven. IK zit nu alleen wel achter XP, dus welk commando het precies is is lastig uit te zoeken.

[koen_92]

Oja, dat klopt, de optie: --zero-superblock
Dan gebruik ik die wel als ik voor dit 'voor het echt' ga doen.