- Server 1: historie a záměr
- Server 2: koncept UPS
- Server 3: realizace UPS
- Server 4: komponenty UPS
- Server 5: návrh HW pro server
- Server 6: Konstrukce a chlazení
- Server 7: software
- Server 8: zkušenosti
- Server 9: upgrade a zašifrování RAID pole
- Server 10: automatické odemknutí zašifrovaného pole
- Server 11: přechod na RAID6
- Server 12: UPS baterie umřela
- Server 13: upgrade CPU
- Síť
- NAS a zálohovací server
- Server 14: Výměna disku za pochodu
- Server 15: využití zahálejícího výkonu
- Server 16: výměna chladiče a poučná zkušenost
- Server 17: Virtualizace serveru
- Server 18: Racková skříň a montáž
- Server 19: Spuštění rackového serveru
- Server 20: konečně SAS řadič a další výzva
- Server 21: Zálohy reloaded
- Server 22: Výměna základní desky
- Server 23: Rack
Uvolněný starý server lze zapojit do velmi užitečné práce. Jednak může posloužit jako souborový server a taky lze na něj přenést pravidelnou otročinu týkající se pravidelného zálohování provozního serveru i pracovní části sdílených souborů. Spotřebu v idle má tuším něco kolem 6W bez disků, svou spolehlivost prokázal už v několikaletém provozu. Jeho čtyřjádrový procesor J 3600 je samozřejmě v porovnání s Ryzenem úplné ořezávátko, nicméně na Sambu a související služby stačí bez potíží. 16GB RAM se zdá být taky dostačující – a je to pro tuto desku maximum. A zálohování provozního serveru – v noci se nikam nespěchá. Zálohování napájení jsem nechala původní – baterie oddělená diodou od DC rozvodů, přes pojistku přímo na desku. Pro proudy, které tam tečou (odhad max kolem 5A) je to úplně v pohodě.
Deska J3600DC ITX je vybavena čtyřmi SATA porty. Já do něj potřebovala nacpat dva 5TB HDD na fotky, filmy a muziku, jeden 1,5T na zálohy, čtyři SDD na pracovní share a samozřejmě ještě systémový disk. Celkem tedy 8 disků – chybějící čtyři SATA porty poskytla rozšiřující karta.
Vytvořila jsem jedno RAID 1 pole (zrcadlení) z páru pětiterových disků a další RAID 5 pole ze čtyř disků. Obě pole jsem zašifrovala, a zašfrovala jsem i zálohovací disk. Odemykání šifrovaných úložišť jsem provedla podobně jako u provozního serveru, přičemž záznam v crypttab i fstab musí v případě zálohovacího HDD odkazovat na UUID tohoto disku.
Mechanické SMR disky v Raidu
Mimochodem – do skříně starého serveru se vejdou jen malé 2,5 disky, takže i ty velkokapacitní (dva 5TB v RAIDu 1 a 1,5TB zálohovací) jsou s “šindelovou” technologií zápisu (SMR), podle různých zdrojů na internetu tedy nevhodných pro RAID pole. No, musím zaklepat, ale zatím žádné potíže opravdu nepozoruju.
Když jsem na vlastní kůži zažila nemilou zkušenost ztráty MDADM hlavičky u jednoho z disků pole, provedla jsem partitioning i u SMR disků RAID 1 pole. Protože jsem neměla po ruce potřebnou volnou diskovou kapacitu (2TB), provedla jsem změnu tak, že jsem nejdříve vyjmula jeden z disků z pole (mdadm –remove), na uvolněný disk jsem vytvořila GPT , vytvořila jediný oddíl a ten přidala do nového Raid 1 pole. Nové pole s tímto jediným diskem jsem tradičně zašifrovala a zkopírovala na něj data ze starého pole. Toto kopírování dat o objemu cca 2TB trvalo téměř tři dny, což si neumím vysvětlit jinak, než že si SMR disk spustil procesy reorganizace dat. Pak, až kopírování doběhlo, jsem zrušila původní raid 1 pole a uvolněný disk upravený o nový GPT přidala do pole nového. Ačkoliv bych si tipla, že mdadm resync raid1 pole je co do objemu dat stejně náročný jako kopírování, tenhle resync trval jen pár hodin. Takže SMR disky jsou dost nevyzpytatelné, nicméně v softwarovém raidu podle mých zkušeností fungují spolehlivě.
Server zvládá managovat dvě různá RAID pole a tři šifrované kontejnery úplně v pohodě, při rychlostech kolem 70MBs Sambou je typicky zatíženo jediné jádro na nějakých 50%, další jádra si pak rozdělují menší objemy prací týkajících se šifrování a mdadm. Pokud pošlu do Samby nějaký velký soubor (třeba nějaký film), lze v topu pozorovat, jak se data nejdřív nasoukají do RAM, případně z malé části do swapu, a teprve pak lze vidět procesy, které data uloží do raidu fyzických disků, a ještě několik vteřin doznívají. Data po síti putují téměř maximální rychlostí cca 70MB/s (1GB LAN).
Zálohování
Denně v noci se spouští moje scripty, které zálohují rsyncem a nástrojem mysqlDump provozní databáze, weby, poštu i vybrané shares. Jednou za měsíc se nejmladší zálohy zabalí do taru a nabídnou se k odložení na externí úložiště, kam jej pak odkládám na různá média a jsem schopná data obnovit z dat až tři měsíce starých v případě, že by zhavaroval zálohovací disk. Pokud je zálohovací disk ok, mám zálohy na měsíční bázi k dipozici až téměř rok dozadu.
Server provádí i další menší práce – jede na něm cron spouštějící valcLogger pro sběr dat z elektrárny, a další crony pro některé pravidelné akce aplikací provozního serveru. Jako další úlohu jsem mu svěřila kontrolu SSL certifikátů všech provozovaných webů, jejichž počet, je vzhledem k počtu domén a subdomén už značný a ruční kontrola prakticky nepřipadá v úvahu. Dozvím se tak včas, že musím nainstalovat prodloužené SSL certifikáty, a hostované weby tak jedou plynule s platnými certifikáty.