Od posledního postu v tomto seriálu bylo třeba server odstavit pouze na necelou hodinu, kvůli zašifrování datového raidu. Jinak aktuální top vypadá takto:

Běžně se pětiminutová zátěž pohybuje kolem 0,05 – nikdo prakticky nikdy nečeká.

Teplota procesoru Ryzen 5 2600 se přes léto (v místnosti s cca 20°C) pohybovala mírně nad 30°C. Teplota při zátěži velmi rychle stoupá, na nějakých 50°C v létě – což jak ventilátor CPU tak i skříňová ventilace v pohodě odvede. I systém napájení je zcela v pořádku.

Všechna data pro weby, mail a další služby jsou v RAID 5 poli. Po tomto typu RAIDu jsem sáhla, protože umožňuje jednoduše zvětšovat velikost pole přidáním dalších disků po jednom (narozdíl od RAID10) , a je výhodný z hlediska poměru kapacity pole a disků v poli n-1. Jednotlivé adresáře v tomto poli jsou namountovány do datových adresářů jednotlivých služeb.

Začínala jsem se třemi disky, po čase jsem pole rozšířila o další dva 256GB SDD:

mdadm –add /dev/md0 /dev/sdc

mdadm –grow –raid-devices=5 –backup-file=grow.bak /dev/md0

resize2fs /dev/md0

Před tímto postupem jsem všechno pro všechny případy zazálohovala. Nicméně upgrade pole proběhl bez potíží a za plného provozu serveru. Procedura běžela několik málo minut. Cílový stav pole:

Tím jsem vyčerpala zásobu SATA portů (deska Gigabyte Aorus M má 6 SATA portů, na jednom visí systémový disk).

Někdy v budoucnu bych ráda přešla na RAID 6, protože RAID 5 může být při rebuildu v degradovaném stavu hodně citlivý na chybu čtení ze zbývajících disků. RAID 6 zvládne poruchu dvou disků, a snížení kapacity na N-2 mi za to stojí. Bude to ovšem chtít rozšířit o další SATA porty, pořídila jsem PCIe-Sata adaptér, až se k tomu dostanu, napíšu sem.

Jak jsem psala výše, jedinou odstávku serveru bylo potřeba provést při zašifrování datového úložiště. Zašifrování dat samozřejmě nezvýší bezpečnost při provozu serveru, je to jenom pojistka proti zneužití dat třeba při jeho krádeži.

K RAID poli lze přistupovat jako k jakémukoliv jinému diskovému zařízení, lze jej tedy i zašifrovat pomocí standardního nástroje dm-crypt. Nejdříve bylo na server potřeba doinstalovat cryptsetup:

apt-get install cryptsetup

Celá procedura zašifrování vypadala takto:

Nejdřív bylo třeba zastavit všechny služby, které k datovému úložišti přistupují:

service apache2 stop service exim4 stop

…

service mysql stop

Poté přesunout veškerá data z raid pole bokem (i s právy):

cp -rp /mnt/data/ /home/vanda/data

Pak odpojit všechny jednotlivé adresáře:

umount /var/www

umount /var/lib/mysql

umount /var/mail …

Poté raid pole zašifrovat:

cryptsetup -y -v luksFormat /dev/md0 password

pak otevřít a naformátovat:

cryptsetup luksOpen /dev/md0 data mkfs.ext4 /dev/mapper/data

namountovat:

mount /dev/mapper/data /mnt/data

a překopírovat původní data i s právy zpět:

cp -rp /home/vanda/data/* /mnt/data

Pak jsem znovu spustila všechny na začátku zastavené služby a po kontrole, zda vše běží jak má, server ponechala jeho běžné práci.

Po odemčení zašifrovaného kontejneru heslem a po připojení celého datového úložiště nelze jednotlivé adresáře připojovat rovnou, ale s klauzulí –bind, např. :

mount –bind /mnt/data/www /var/www

Celý proces trval asi hodinu, přičemž nejdéle trval přesun dat, kontroly, testy a dokumentace. Protože server a jeho všechny služby po restartu nastartují do svých výchozích (prázdných) adresářů, start systému nebude úplně košer a bude jej třeba zušlechtit přidáním dalšího klíče a otevřením zašifrovaného kontejneru scriptem při startu serveru, přičemž se keyfile načte třeba z USB disku.

Zálohovací plán serveru jsem rozšířila o zálohování luks headru.

Další díly seriálu

<< Server 8: zkušenostiServer 10: automatické odemknutí zašifrovaného pole >>