Od doby, kdy jsem začala vyvíjet na volné noze, a to je už nějaký ten pátek, používám domácí servery. Původně sloužil vlastně jen jako print a fileserver a šlo jen o další pc s MS systémem. V okamžiku, kdy jsem se seznámila s linuxem, stal se ze serveru zcela pod mou kontrolou nedocenitelný pomocník. Evoluce pak pokračovala logickou cestou – na vlastní server jsem si přesunula i své domény a spustila jsem i vlastní poštovní server a spoustu dalších služeb, které usnadňují vývoj, jako git, RMS a další. Dnes na tomto serveru hostuji více domén, a funguje k mé spokojenosti. A ve skutečnosti už provozuji serverů vícero, kvůli redundanci a především kvůli bezpečnosti.

Toto je díl 15 z 23 seriálu Projekt domácího serveru

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.

 

Další díly seriálu<< SíťServer 14: Výměna disku za pochodu >>