Virtualizace

Virtualizované stroje jsem využívala už dřív, ale většinou jsem je používala jen jako testovací nebo vývojové prostředí. Teprve když mi se nějaký postup osvědčil, nasadila jsem novinku na produkční server, jedoucí na fyzickém železe. Takto mi to vyhovovalo dlouho, ale přinášelo to i řadu nevýhod, jako třeba nižší schopnost záloh systému a konfigurace mnoha služeb. Dál to byl i problém bezpečnostní – celý produkční server je připojen k DMZ, takže nebylo možné jej použít na projekty, které potřebuji schovat v relativním bezpečí domácí sítě. Takže třeba domácí NAS jsem provozovala na jiném stroji, ačkoliv na tom novém produkčním bylo výkonu na rozdávání.

Po minulé události jsem se rozhodla přestat s provizórii v podobě podomácku vyrobených skříní a umístit server do pořádné rackové krabice vhodné do 19″ racku. A při této příležitosti jej i upgradovat na vyšší CPU, doplnit RAM a osadit silnější zdroj.

Bylo mi jasné, že tohle asi nestihnu za jediný den, byť bych se připravila sebelíp. Měla jsem totiž podezření, že v serveru něco hodně skřípe.

Virtualizace produkčních strojů by mi umožnila přenést produkci alespoň na nutný čas na starý servřík s čtyřjádrem Intel J3160, který má uptime už sedm let a běží na něm tuším šestka Debian, a já bych se tak vyhnula neurčitě dlouhé odstávce služeb. U některých z nich to ostatně ani nepřicházelo v úvahu.

Proto jsem s pracemi na virtualizaci začala prakticky hned poté, co jsem se k upgrade serveru rozhodla.

Na stroj s čtyřjádrovým Celeronem (TDP 6W, 16GB DDR3 RAM) jsem nainstalovala Qemu / KVM hypervizor, nainstalovala jsem tam nejnovější Debian. Nebylo to nijak přitažlivě svižné, ale ani o moc pomalejší, než práce na reálném HW tohoto starého stroje. Koneckonců, benchmarky srovnávající výkon konkrétní úlohy běžící na reálném železe s výkony VM na tomtéž HW ukazují, že se režií hypervizora ztrácí jen jednotky procent.

Dobrá, přesunula jsem práci s instalacemi VM na pracovně přívětivý produkční server, protože jsem si už mohla být jistá, že zasloužilý důchodce pak hotové VM zvládne převzít.

Nejdřív bylo potřeba namyslet splitting serverů: jediný produkční server obstarával veškeré služby, takže na něm jela databáze, webový server, různé další služby za proxy webového serveru, git, poštovní server, a rozhraní pro poštovní klienty (Dovecot). Zabalit to všechno znovu do jediného stroje mi v budoucnu ztíží aktualizace a modernizace jednotlivých komponent, protože takové operace mohou ovlivnit i komponenty, pro které to myšleno nebylo. Rozhodla jsem se udělat řez mezi databázovým a webovým serverem a poštou.

Protože ale jak Exim4 tak Dovecot mám nakonfigurovaný na db lookup, a naopak webový server se v aplikaci webmailu připojuje ke službám Dovecotu na poštovní server, vznikla mi škaredá oboustranná závislost. Správnější by tedy bylo rozdělit aplikační a databázový server na dvě virtuální mašiny. Později, až bude čas a bude-li dostatek RAM, vytáhnu databázi ven na další VM.

Rozhodně fakt oddělení webů od pošty mi připravilo jisté potíže s mailováním z webů, které především komunitní weby používají hojně. Původně se tento task odehrával lokálně, nezabezpečeně na portu 25, a výsledné maily byly řádně podepsané DKIM klíčem. Po novu bylo nutné komunikaci přesměrovat přes zabezpečené porty na mailový server, což nebylo tak jednoduché, jak to může znít.

Dalšími kandidáty na virtualizaci je můj pracovní NAS a samozřejmě vytěžovací server, který kromě vytěžování Monera v čase hojnosti solární energie nemá žádnou jinou funkci.

NAS je ale soukromá záležitost, patří do domácí sítě, nikoliv do DMZ. Serveru jsem proto dopřála další síťovku, protože jsem tušila, že nebudu mít dost času řešit si VLAN splitting přímo na stroji. Nová síťovka je vyhrazená virtuálním strojům v DMZ a je připojená k DMZ VLAN. Konfigurace sítě na straně hypervizora byla velmi intiutivní, prostě klasický direct-mac-vtap s jiným síťovým rozhraním.

virsh net-define:

<network>
<name>direct-macvtap</name>
<forward dev=’eno1′ mode=’bridge’>
<interface dev=’eno1’/>
</forward>
</network>

<network>
<name>direct-macvtap-DMZ</name>
<forward dev=’enp4s0′ mode=’bridge’>
<interface dev=’enp4s0’/>
</forward>
</network>

Hypervizor a data storage

Po pár týdnech rozmýšlení, studiu a zkoušení jsem se pak vykašlala na klikací řešení jako Proxmox nebo TrueNas Scale a další, protože ačkoliv jde jistě o skvělé produkty, neumí jednoduše pracovat s mdadm poli, které zatím za ZFS nahrazovat nechci. A ani migrace existujícího virtuálního stroje v podobě disku qcow2 není na ně úplně bez potíží – je potřeba provést konverzi. Takže jsem zůstala u QEMU / KVM s pouze nutnými nástroji pro správu, jako virsh. Jehož princip jsem pochopila rychle a umím si v něm docela efektivně připravit konfiguraci stroje podle svých představ.

Takže hypervizor v mém podání je prakticky holá instalace aktuálního Debianu pouze s nutným doinstalovaným software. Jako architekturu úložiště jsem zvolila sendvič, jehož nejnižším patrem je mdadm pole, na něm luks kontejner, který si server při bootu odemkne, na luksu pak LVM a nejvyšší vrstvou jsou logické disky. Jeden z nich slouží jako skladiště virtuálních strojů, další pak jako datové disky jednotlivých virtuálních mašin. Většina z nich má tedy disky dva – malý systémový qcow2 a pak ten datový, se kterým pracují aplikace. Server si tedy při restartu mountuje pouze LVM disk s VM stroji, zbytek se předává jako RAW block device skrze UUID disku virtuálním strojům. Na úrovni hypervizoru jde o velikostně flexibilní, paritou chráněné a šifrované úložiště. Virtuální stroje jsou od této komplexnosti odizolované a vidí pouze blokové zařízení, které mají pod svou správou. Tak neví nic o úkonech, jako je výměna disků v poli či o nějaké změně pole; něco většího k nim dobublá až s potřebou nafitovat velikost filesystému.

Tohle mi připravilo drobnou komplikaci – cryptsetup s argumentem noauto nefunguje správně v kombinaci s fstab, ve kterém se neodkazuje na celé šifrované pole, ale jen na jeden z vícero logických disků v další vrstvě LVM. Takže se tedy pole sice správně sestavilo, ale šifrovaný kontejner se neodemknul, protože LVM není pro tenhle proces asi dostatečně průhledné, fstab následně selhalo a boot nabíhal do nouzového režimu. Bylo třeba nahradit noauto v crypttabu za nofail, a tentýž argument přidat i do příslušného záznamu v fstab.

cryptTab:
srvData /dev/md0 [key-file] luks,nofail

fstab:
# KVM machines
UUID=[UUID] /mnt/machines ext4 noatime,nofail

Takhle to funguje dobře.

Jedinou alternativou k takto funkčnímu řešení storage hypervizora je ZFS, které by elegantně řešilo všechny vrstvy: od raid pole až po logické disky. LVM mi ale přijde flexibilnější, protože výsledné logické disky mohou mít každý svůj vlastní filesystém.

 

Další díly seriálu

<< Server 16: výměna chladiče a poučná zkušenostServer 18: Racková skříň a montáž >>