Teď, na začátku meteorologického jara je poslední verze mého serveru v racku už téměř rok v provozu:

Prostě víceméně tak, jak jsme jej s kamarádem do racku před rokem natlačili, v takovém stavu jede dodnes bez jediného restartu.

Běží na něm šest virtuálních strojů, na jednom aplikační server (klasický LAMP a databáze), v apache2 mám na něm kolem třiceti virtual hosts.

Disky

Veškeré SSD v hlavním RAID6 poli jsem nahradila za 1TB verze, mám tedy k dispozici 4TB pro jednotlivé LVM disky, které se napřímo předávají virtuálním strojům. Zdá se, že si ještě pár let s touto kapacitou s přehledem vystačím, Raid6 je využit asi z poloviny. Má to blahodárný vliv na disky samotné. Některé z nich QLC, ale smart data i tak ve většině případů na 100% lifetime. “Nejhůře” je na tom TLC disk Kingston KC600 s udávaným time-left 96%, takže úplně v pořádku. Původní 512GB disky byly vytěžované více intenzivně, na některých z nich bylo třeba 93% time left.

2TB SSD se cenově v lowendu začínají pomalu propracovávat k cenám, za které jsem kupovala 1TB disky, ale preventivně je vyměňovat nebudu, pouze v případě potíží koupím už 2TB verzi.  Všechny disky se pod rozumné smart hodnoty asi nedostanou dřív, než po třech – čtyřech letech, dřív nepředpokládám, že bych na to musela nějak myslet.

Dvojice 5TB disků Seagate Barracuda 2.5 v Raid1 poli se stále drží. Jeden z nich má už několik let špatné sektory, před rokem jich bylo 440, po roce provozu přibylo dalších 8. Takže tento disk je zjevně načatý, ale odchází velmi pomalu. Těžko říct, kdy se jeho umírání zrychlí, až se to stane, začnu to řešit. Na tomto poli sice nemám žádná kritická data, ale i tak bych o ně nerada přišla. A řešila bych to asi dalším LVM diskem na hlavním Raid6 poli, které bych o ty dva rozšířila.

CPU

Výkonnostně je server absolutně skvělý, už jsem to tu v blogu kdesi psala: vyvíjela jsem nedávno jeden systém pro realizaci talentových zkoušek – nic složitého, jen taková komplikovaná datařina, relativně velké kompozitní objekty. Na mém dedikovaném vývojovém virtuálu se dvěmi jádry a 2GB RAM jsem se nedostala do stavu, že bych musela sáhnout po nějaké optimalizaci. Po nasazení systému do školy, na starší sice, ale profi server Dell PowerEdge R610 už optimalizovat budu muset, jsou tam citelné čekací časy na poskládání těch objektů, když jich je více. Nedívala jsem se na benchmarky, ale je to subjektivně vážně někde úplně jinde.

Zkrátka se na tom serveru vedle paralelně běžících spolehlivých a rychlých veřejných i soukromých služeb výborně vyvíjí. A to dokonce i tehdy, pokud slunce spustí poslední instanci vytěžovače – crypto miner. Tomu jsem dovolila využít asi půlku výkonu celého CPU, a jeho běh není na hlavních službách serveru nijak znát.

Vím, že AM4 Ryzeny jsou dnes už mírně překonané novějšími generacemi, je možné si podobný stroj postavit dvakrát rychlejší za podobné peníze, ale není to prostě třeba, nic mě netlačí.

RAM

Hypoteticky bych mohla narazit na RAM: utilizace na hypervizoru je přes 100%, protože je to ve swapu, nicméně je tam ještě pořád k dispozici cache, takže zatím mě to nijak neznepokojuje. Další virtuál bych si ale asi už rozmyslela. Možná v budoucnu, pokud zjistím, že by se mi hodil self-hosted cloud disk.

Taky se může stát (statisticky se to stát po nějakém čase musí, pokud se to už nestalo), že budu mít nějaké datové defekty díky tomu, že nepoužívám EEC, nýbrž obyčejné DDR4. Otázka je, jestli si takové chyby můžu všimnout. Nejzásadnější je databáze, úplná většina tabulek je InnoDb, a běží tam checksum. V error logu db serveru jsem zatím žádné chyby, ukazující na problém podle kontrolních součtů neviděla. Každopádně, mám denní snapshoty na btrfs, takže žádných velkých katastrof se asi tak úplně bát snad nemusím.

Rack

Tím, že je server v racku v technické místnosti, jako by nebyl. Jediná potíž tohoto řešení je to, že jde o prašnou místnost, ve které se aktuálně dost děla na projektech fotovoltaické elektrárny, a dost se tam práší. A protože rack je děravý ventilačními otvory na všech svých hranách, možná časem zvážím nějakou prodyšnou pěnu, kterou tyhle místa vyplním. Zatím jsem to vyřešila magneticky přichyceným prachovým filtrem na nasávacím ventilátoru na přední straně serveru. Který tedy potřebuje jednou za měsíc oprášit, to je pravda. Tohle ale doopravdy zvážím až tehdy, až bude nutné server kvůli nějaké údržbě otevřít.

Teploty procesoru se v běžném provozu pohybují kolem 30°, běžící miner to samozřejmě vytáhne na 80°, což je už na hraně, kvůli limitu chladiče. Proto vytěžovači už větší výkon nedám. Teplota na Nvme ssd s operačním systémem hypervizoru je kolem 50°.  A hotswap disky mají kolem 30°, takže až na teploty v zátěži s běžícím vytěžovačem je to v normě.

Spotřeba

Hrubým odhadem je průměrná spotřeba serveru nějaké 1,5kWh denně, řekněme 0,5MWh za rok. Z toho asi 70% bylo solární, tohle číslo se díky FVE 2.0 zvýší.

Problémy

Musím zaklepat – za rok provozu žádné. Vlastní chybou jsem si navodila pár restartů databáze při pracích na velké databázi valcMonitoru, ale to byl jednorázový problém, vyřešený. Jinak žádné potíže, o serveru nevím.

 

 

 

Další díly seriálu

<< Server 24: NAS HDD do šrotu?Server 26: Migrace Raid1 pole >>