Virtuální stroj, kontejner nebo bare metal? Vhodný způsob provozu vychází z aplikace, podpory jejího výrobce a lidí, kteří ji budou dlouhodobě spravovat. Kontejner automaticky neudělá ze starého ERP snadno udržovatelný systém. Fyzický server není automaticky rychlejší. A VM není omluvou pro zanedbání záloh a aktualizací. DAXS proto začíná konkrétní zátěží: systémem, závislostmi, daty, obnovou a měřitelným provozem.
Toto porovnání odpovídá na otázku, kde má služba smysluplně běžet. Pokud už padla volba na aplikační kontejnery, následuje jiná otázka: Docker Compose nebo Kubernetes pro provoz? Obě rozhodnutí je třeba přijímat odděleně.
Co se vlastně odděluje?
Virtuální stroj dostává virtuální hardware a vlastní hostovaný operační systém. Na stejném hypervizoru tak může běžet například Windows Server vedle hostovaných systémů Linux. VM je dobře ohraničená jednotka pro aktualizace systému, snapshoty a obnovu; aplikace přesto potřebuje konzistentní zálohování. V Proxmox VE se tato cesta opírá o KVM.
Kontejner sdílí jádro hostitele. Rozlišujte dvě formy: kontejner Proxmox LXC je lehký linuxový systém, aplikační kontejner OCI obvykle balí jednu aplikaci se závislostmi. Ani jeden není Windows VM a nenahrazuje izolaci samostatným jádrem. OCI vyžaduje také udržovaný build obrazů, registry, bezpečnostní aktualizace a promyšlená trvalá data. Linuxová VM jako hostitel kontejnerů může dobře oddělit provoz, zálohy a oprávnění; není technickou povinností v každé situaci.
Bare Metal spouští operační systém a aplikaci přímo na fyzickém serveru. To může vyhovět vazbám výrobce, speciálnímu hardwaru či prokázaným požadavkům na latenci. Omezuje však konsolidaci daného hostitele a více váže údržbu, náhradní díly a obnovu na fyzický stroj. I zde rozhodují měření a závazky podpory, nikoli obecné tvrzení o výkonu.
Pět typických zátěží a první směr ověření
Následující cesty jsou výchozí body pro test, nikoli obecné schválení produktů. Spolehlivé rozhodnutí vyžaduje dokumentaci výrobce, licenční smlouvu a zkoušku obnovy.
| Aplikace | Směr ověření | Klíčová otázka |
|---|---|---|
| Windows ERP s databází a podporou výrobce | VM jako přirozený výchozí bod | Jaká kombinace hostovaného systému, hypervizoru, SQL a licencí je skutečně podporována? |
| Vlastní linuxová webová služba s reprodukovatelným buildem | Aplikační kontejner OCI, případně na linuxové VM | Kdo vytváří a aktualizuje obrazy, kontroluje zranitelnosti a spravuje registry, tajné údaje a logy? |
| Linuxová appliance výrobce | Nejprve ověřit podporovanou VM | Přijímá výrobce virtualizaci, virtuální zařízení a zamýšlený postup záloh a obnovy? |
| Databáze s vysokou zátěží zápisu | VM nebo bare metal podle měření; kontejner jen s ověřenou perzistencí | Jak se při špičce chovají latence p95/p99, IOPS, replikace a konzistentní obnova? |
| Služba s donglem, speciální kartou nebo přímým přístupem k zařízení | Otestovat passthrough VM; zvážit bare metal | Zůstanou podpora výrobce, přiřazení zařízení a obnova možné po výměně hostitele? |
Databázový kontejner není zásadně chybný. Jeho zapisovatelný souborový systém však není místem pro data, která musí zůstat po nahrazení kontejneru. Svazky, konzistenci, zálohy a obnovu je třeba plánovat výslovně. Naopak VM neudělá z neotestované databázové zálohy spolehlivou obnovu.
Šest kontrol pro rozhodnutí
- Výrobce a licence: Písemně ověřit podporované systémy, hypervizory, runtime kontejnerů a hardwarové vazby. Práva Windows Server závisejí mimo jiné na edici, licencovaných jádrech, počtu virtuálních prostředí a smlouvě; z „jedné VM“ neplyne paušální cena.
- Izolace a oprávnění: Která služba smí ovlivnit jinou? Kontejnery mají namespaces a omezení zdrojů, ale sdílejí jádro hostitele. Runtime, privilegia, připojené svazky, síť a aktualizace patří do bezpečnostního posouzení.
- Měřit výkon: Z reálných dat zjistit zátěž CPU, RAM a I/O, latence p95/p99, špičky i dávková okna. Volba bare metal jen kvůli domnělé „virtualizační režii“ může vázat drahou kapacitu bez vyřešení skutečného problému úložiště nebo sítě.
- Data a obnova: Definovat RPO a RTO pro každou službu. Vyzkoušet úplnou obnovu na jiném hostiteli včetně databáze, konfigurace, přihlašovacích údajů a závislostí.
- Změny a pracovníci: Kdo aktualizuje hostovaný systém nebo jádro hostitele? Kdo znovu sestaví obrazy? Kdo v noci zvládne neúspěšný rollback či výměnu hardwaru? Dostupné schopnosti omezují počet platforem, které má smysl provozovat souběžně.
- Doména selhání: Hostitele, úložiště, síť a zálohu posuzovat odděleně. Ani jeden bare-metal server, ani více kontejnerů na jediném hostiteli nejsou díky názvu vysoce dostupné.
Porovnat náročnost před tvrzením o úsporách
Pro tři či pět let porovnávat v každém sloupci stejnou aplikaci se stejnou zátěží a cílem obnovy. Zahrnout počáteční migraci a vybudování, hardware a díly, práva systémů a aplikací, podporu hypervizoru či runtime, energii, zálohy, monitoring a roční hodiny pracovníků. U OCI přibývá například build pipeline, registry, údržba obrazů a případná orchestrace. Bare metal může vyžadovat náhradní hardware a jiné okno údržby. U VM se počítá kapacita hostitele a hostované systémy. Stávající cluster je pro novou službu „zdarma“ jen tehdy, když skutečně existují rezervy, licence a provozní zdroje.
Ověřitelný základní vzorec je: celkové náklady za n let = počáteční vybudování a migrace + n × (roční licence + podpora + energie + zálohy + provozní hodiny × interní hodinová sazba) + plánovaná obnova. n je tři nebo pět. Bez konkrétních nabídek, měření a podmínek podpory nemá žádná forma obecnou nákladovou výhodu. Porovnání musí ukázat také cenu nedosaženého RPO/RTO, nikoli ji z výpočtu vynechat.
Jak by DAXS zvolil způsob provozu
DAXS by nejprve vytvořil krátký seznam aplikací s vlastníkem, datovými toky, podporou výrobce, závislostmi a cílem obnovy. Dva realistické kandidáty by následně prověřil krátký test: zátěž blízká produkci, aktualizace, selhání hostitele či zařízení a obnova na jiném stroji. Výsledkem je doložitelné rozhodnutí pro aplikaci, nikoli povinnost přesunout všechny služby na stejnou platformu.
Stávající Windows a Linux VM lze často hodnotit postupně; Proxmox ve firmě popisuje virtualizační základ. Pokud vyhoví kontejnery, porovnání Docker Compose a Kubernetes pomůže v dalším kroku. Pro konkrétní zátěž lze přes Kontakt s DAXS převést schválení, měření a obnovu do provozního rozhodnutí.
Zdroje: Proxmox VE: KVM a LXC · Docker Engine: bezpečnostní model · Docker Engine: trvalá data · Microsoft: Windows Server Virtualization Licensing Guidance.
