Jak jsem psala zde, data jsou na mém serveru uložena v zašifrovaném RAID poli seskládaném z pěti 250GB SSD disků, přičemž jsem použila RAID 5 – jeho kapacita (n-1) je tedy 1TB. Tento typ RAID pole je výhodný proto, že umožňuje začít se třemi disky a postupně navyšovat kapacitu pole přidáváním dalších disků. Toto pole zvládne poruchu jednoho disku. Rebuild degradovaného RAID5 pole ovšem může být napínavá věc, protože by stačila jediná chyba čtení z některého ze zbylých disků a může nastat vážný problém s celým polem. Proto jsem se rozhodla spolehlivost pole zvýšit přechodem na RAID6, který zvládne výpadek dvou disků – jeho kapacita je n-2.

Nejjednodušší způsob přechodu z RAID5 na RAID6 v linuxu se mi zdál ten, který nezmění velikost pole, jde cestou přes přidání nového disku.

U stávajícího RAID5 pole jsem skončila u pěti disků, přičemž šestý disk v serveru je systémový, všech šest SATA portů je tedy obsazeno. Další 2 SATA porty jsem získala instalací PCIe SATA řadiče Delock. Linux si s kartou poradil bez potíží, k ní připojený disk jsem našla jako /dev/sdf, a smartctl -i pro tento disk hlásí:

SATA Version is: SATA 3.3, 6.0 Gb/s (current: 6.0 Gb/s)

Disk je tedy připojen maximální možnou rychlostí. Ok.

Zazálohovala jsem všechna data, a za plného provozu serveru spustila

mdadm –add /dev/md0 /dev/sdf
mdadm –grow /dev/md0 –level=6 –raid-devices=6 –backup-file=backupFile

Zatímco u rozšiřování RAID5 pole o další disky jsem byla zvyklá počkat si asi hodinku, tak tentokrát bylo potřeba počkat přes hodiny čtyři – ano, přibylo dat, které bylo třeba přechroustat a rozházet po šesti discích pole, bylo jich asi 100Gb. Na průběh operace se dalo dohlížet pomocí:

progress: cat /proc/mdstat

Poté, co reshape pole doběhl, hlásí mdadm toto:

Kapacita pole zůstala tedy beze změny, změnil se jen počet disků a typ pole, přesně podle očekávání. Lsblk hlásí následující strukturu datových disků:

NAME MAJ:MIN RM SIZE RO TYPE
sda 8:0 0 232.9G 0 disk
└─md0 9:0 0 931G 0 raid6
└─cryptedData 253:0 0 931G 0 crypt
sdb 8:16 0 238.5G 0 disk
└─md0 9:0 0 931G 0 raid6
└─cryptedData 253:0 0 931G 0 crypt
sdc 8:32 0 232.9G 0 disk
└─md0 9:0 0 931G 0 raid6
└─cryptedData 253:0 0 931G 0 crypt
sde 8:64 0 238.5G 0 disk
└─md0 9:0 0 931G 0 raid6
└─cryptedData 253:0 0 931G 0 crypt
sdf 8:80 0 477G 0 disk
└─md0 9:0 0 931G 0 raid6
└─cryptedData 253:0 0 931G 0 crypt
sdh 8:112 0 477G 0 disk
└─md0 9:0 0 931G 0 raid6
└─cryptedData 253:0 0 931G 0 crypt

Vše je tedy v pořádku. Některé disky v poli jsou už vyšší kapacity, protože jak ceny SSD disků klesají, je výhodnější kupovat větší disky. Po čase můžu nahradit všechny menší disky většími a zdvojnásobit datovou kapacitu pole, což provedu takto:

Nejdřív nechám mdadm využít veškerou dostupnou kapacitu:

mdadm –grow /dev/md0 –size=max

Toto chvíli běží, mdadm provede resync celého pole. Pak provedu resize zašifrovaného kontejneru:

cryptsetup resize /dev/mapper/cryptedData -v

tento příkaz si vyžádá heslo. A nakonec ještě resize file systému:

resize2fs /dev/mapper/cryptedData

Navýšení kapacity datového úložiště se dá provést online, s namountovaným zašifrovaným diskem, za plného provozu stroje. Krása.

Raid6 by mělo být při zápisu o něco pomalejší než Raid5, protože se paritní data dopočítávají a ukládají dvakrát. Na druhou stranu čtení je rychlé a roste s počtem použitých disků. Na tomto serveru nejsem ale schopná si to ověřit, protože k vlastním testům se nechystám a při běžném používání není žádné zpomalení pozorovatelné, jen v top lze pozorovat spolu s úlohami webového nebo mailového serveru i proces md0_raid6 s malým zatížením CPU 0,3, občas se tam mihne i  dmcrypt.

 

 

 

 

 

Další díly seriálu

<< Server 10: automatické odemknutí zašifrovaného poleServer 12: UPS baterie umřela >>