Virtuális gép, konténer vagy bare metal? A megfelelő forma az alkalmazástól, gyártói támogatásától és a tartós üzemeltetésért felelős emberektől függ. Egy konténer nem tesz automatikusan karbantarthatóvá egy régi ERP-t. A fizikai szerver nem automatikusan gyorsabb. A VM nem indok a mentés és frissítés elhanyagolására. A DAXS ezért a konkrét feladattal kezd: rendszer, függőségek, adatok, helyreállítás és mérhető terhelés.
Az összevetés arra válaszol, hol érdemes futtatni a szolgáltatást. Ha az alkalmazáskonténerek mellett már megszületett a döntés, új kérdés következik: Docker Compose vagy Kubernetes az üzemeltetéshez? A két döntést külön kell meghozni.
Mi kerül valójában elválasztásra?
A virtuális gép virtuális hardvert és saját vendég operációs rendszert kap. Így ugyanazon a hipervizoron például Windows Server és Linux vendégek futhatnak. A VM jól körülhatárolt egység rendszerfrissítésekhez, pillanatképekhez és helyreállításhoz; az alkalmazás ettől még konzisztens mentést igényel. A Proxmox VE ehhez KVM-et használ.
A konténer osztozik a gazda kernelén. Két formát különítsünk el: a Proxmox LXC-konténer könnyű Linux-rendszer, az OCI-alkalmazáskonténer általában egy alkalmazást csomagol a függőségeivel. Egyik sem Windows VM vagy saját kernellel biztosított izoláció. OCI-hoz karbantartott image-build, registry, biztonsági frissítések és tudatos perzisztensadat-megoldás is kell. A konténergazdaként használt Linux VM hasznos határ lehet üzemeltetés, mentés és jogok szempontjából; nem minden helyzetben technikai kötelezettség.
Bare Metal közvetlenül fizikai szerveren futtatja a rendszert és az alkalmazást. Gyártói kötöttségek, speciális hardver vagy igazolt késleltetési igény esetén lehet megfelelő. Csökkenti azonban az adott gazda konszolidációját, és jobban a fizikai géphez köti a karbantartást, alkatrészeket és helyreállítást. Itt is mérés és támogatási vállalás dönt, nem általános teljesítményígéret.
Öt tipikus terhelés és az első vizsgálati irány
Az alábbi utak tesztkiindulópontok, nem általános termékjóváhagyások. Gyártói dokumentáció, licencszerződés és helyreállítási teszt alapozza meg a döntést.
| Alkalmazás | Vizsgálati irány | Kritikus kérdés |
|---|---|---|
| Windows ERP adatbázissal és gyártói támogatással | VM mint kézenfekvő kiindulópont | Mely vendégrendszer-, hipervizor-, SQL- és licenckombináció támogatott ténylegesen? |
| Saját Linux-webszolgáltatás reprodukálható builddel | OCI-alkalmazáskonténer, szükség esetén Linux VM-en | Ki építi és frissíti az image-eket, ellenőrzi a sérülékenységeket, és üzemelteti a registryt, titkokat és naplókat? |
| Gyártói Linux-appliance | Először támogatott VM vizsgálata | Elfogadja-e a gyártó a virtualizációt, virtuális eszközöket és a tervezett mentési/helyreállítási utat? |
| Nagy írási terhelésű adatbázis | VM vagy bare metal mérések alapján; konténer csak tesztelt perzisztenciával | Hogyan alakul a p95/p99 késleltetés, az IOPS, a replikáció és a konzisztens helyreállítás csúcsterheléskor? |
| Dongle-t, speciális kártyát vagy közvetlen eszközhozzáférést használó szolgáltatás | VM-passthrough tesztelése; bare metal mérlegelése | Gazdacsere után is biztosítható a gyártói támogatás, eszközhozzárendelés és helyreállítás? |
Az adatbázis-konténer önmagában nem hibás. Írható fájlrendszere azonban nem a konténercserét túlélő adatok helye. Köteteket, konzisztenciát, mentést és helyreállítást külön kell tervezni. A VM sem változtat egy teszteletlen adatbázismentést megbízható helyreállítássá.
Hat ellenőrzés a döntéshez
- Gyártó és licenc: Írásban ellenőrizni kell a támogatott rendszereket, hipervizorokat, konténerkörnyezeteket és hardverkötöttségeket. A Windows Server-jogok függnek többek között a kiadástól, licencelt magoktól, virtuális környezetek számától és szerződéstől; az „egy VM” nem jelent átalányárat.
- Izoláció és jogosultságok: Melyik szolgáltatás befolyásolhat másikat? A konténerek névtereket és erőforráskorlátokat használnak, de a gazda kernelén osztoznak. Futtatókörnyezet, privilégiumok, csatolások, hálózat és frissítések a biztonsági ellenőrzés részei.
- Teljesítménymérés: Valós adatokkal mérje a CPU-, RAM- és I/O-terhelést, a p95/p99 késleltetést, csúcsokat és kötegelt ablakokat. A bare metal választása pusztán feltételezett „virtualizációs többlet” miatt drága kapacitást köthet le a tényleges tárolási vagy hálózati probléma megoldása nélkül.
- Adatok és helyreállítás: Szolgáltatásonként meg kell adni az RPO-t és RTO-t. Másik gazdán teljes visszaállítást kell gyakorolni adatbázissal, konfigurációval, hozzáférési adatokkal és függőségekkel.
- Változások és személyzet: Ki frissíti a vendégrendszert vagy a gazda kernelét? Ki építi újra az image-eket? Ki old meg éjjel egy sikertelen rollbacket vagy hardvercserét? A meglévő tudás korlátozza az értelmesen párhuzamosan üzemeltethető platformok számát.
- Hibatartomány: A gazdát, tárolót, hálózatot és mentést külön értékelje. Sem egyetlen bare metal szerver, sem több konténer egy gazdán nem lesz a nevétől magas rendelkezésre állású.
A ráfordítást a megtakarítás ígérete előtt hasonlítsa össze
Három vagy öt évre minden oszlopban ugyanaz az alkalmazás, terhelés és helyreállítási cél szerepeljen. Számolni kell a migrációval és kiépítéssel, hardverrel és alkatrészekkel, rendszer- és alkalmazásjogokkal, hipervizor- vagy runtime-támogatással, energiával, mentéssel, monitorozással és éves munkaórákkal. OCI esetén ehhez build pipeline, registry, image-karbantartás és esetleges orkesztráció társul. Bare metalnál tartalék hardver és más karbantartási ablak is kellhet. VM-eknél a gazdakapacitás és a vendégrendszerek számítanak. Egy meglévő klaszter csak akkor „ingyenes” az új szolgáltatásnak, ha valóban rendelkezésre áll a tartalék, licenc és üzemeltetési erőforrás.
Az ellenőrizhető alapképlet: teljes költség n évre = egyszeri kiépítés és migráció + n × (éves licencek + támogatás + energia + mentés + üzemeltetési órák × belső óradíj) + tervezett megújítás. n értéke három vagy öt. Konkrét ajánlatok, mérések és támogatási feltételek nélkül egyik formának sincs általános költségelőnye. A nem teljesült RPO/RTO árát is láthatóvá kell tenni, nem kihagyni a számításból.
Hogyan választaná ki a DAXS az üzemeltetési formát?
A DAXS először rövid alkalmazáslistát készítene felelőssel, adatfolyammal, gyártói támogatással, függőségekkel és helyreállítási céllal. Két reális jelöltre rövid műszaki teszt következne: termelésközeli terhelés, frissítési út, gazda- vagy eszközhiba és visszaállítás másik gépen. Az eredmény alkalmazásonként indokolható döntés, nem minden szolgáltatás egy platformra költöztetésének előírása.
A meglévő Windows és Linux VM-ek gyakran lépésenként értékelhetők; Proxmox a vállalatnál bemutatja a virtualizáció alapját. Ha a konténeres út megfelelő, a Docker Compose és Kubernetes összehasonlítása segít a következő lépésben. Konkrét terhelésnél a Kapcsolat oldalon a DAXS-szal együtt üzemeltetési döntéssé alakíthatók a jóváhagyások, mérések és helyreállítás.
Források: Proxmox VE: KVM és LXC · Docker Engine: biztonsági modell · Docker Engine: perzisztens adatok · Microsoft: Windows Server Virtualization Licensing Guidance.
