Virtuaalikone, kontti vai bare metal? Sopiva käyttötapa riippuu sovelluksesta, valmistajan tuesta ja ihmisistä, jotka ylläpitävät sitä pitkäjänteisesti. Kontti ei tee vanhasta ERP:stä automaattisesti ylläpidettävää. Fyysinen palvelin ei ole automaattisesti nopeampi. VM ei oikeuta laiminlyömään varmistuksia ja päivityksiä. DAXS aloittaa siksi todellisesta kuormasta: järjestelmästä, riippuvuuksista, datasta, palautuksesta ja mitattavasta käytöstä.
Vertailu vastaa kysymykseen, missä palvelua kannattaa ajaa. Jos sovelluskontit on jo valittu, seuraa toinen kysymys: Docker Compose vai Kubernetes ylläpitoon? Nämä päätökset on tehtävä erikseen.
Mitä oikeastaan erotetaan?
Virtuaalikone saa virtuaalisen laitteiston ja oman vieraskäyttöjärjestelmän. Samalla hypervisorilla voi olla esimerkiksi Windows Server -vieras Linux-vieraiden rinnalla. VM on rajattu yksikkö järjestelmäpäivityksille, tilannekuville ja palautukselle; sovellus tarvitsee silti johdonmukaisen varmistuksen. Proxmox VE käyttää tähän KVM:ää.
Kontti jakaa isännän ytimen. Erota kaksi käyttötapaa: Proxmox LXC -kontti on kevyt Linux-järjestelmä, kun taas OCI-sovelluskontti paketoi yleensä yhden sovelluksen riippuvuuksineen. Kumpikaan ei ole Windows-VM tai korvaa eristystä omalla ytimellä. OCI vaatii myös ylläpidetyn levykuvien rakennusprosessin, rekisterin, tietoturvapäivitykset ja harkitun ratkaisun pysyvälle datalle. Linux-VM kontti-isäntänä voi rajata ylläpitoa, varmistuksia ja oikeuksia; se ei ole tekninen pakko kaikissa tilanteissa.
Bare Metal ajaa järjestelmän ja sovelluksen suoraan fyysisellä palvelimella. Se voi sopia valmistajariippuvuuksiin, erikoislaitteisiin tai todennettuihin viivevaatimuksiin. Se kuitenkin vähentää isännän konsolidointia ja sitoo huoltoikkunat, varaosat ja palautuksen enemmän fyysiseen koneeseen. Tässäkin ratkaisevat mittaukset ja tukisitoumukset, eivät yleiset suorituskykyväitteet.
Viisi tavallista kuormaa ja ensimmäinen arviointipolku
Seuraavat polut ovat testin lähtökohtia, eivät tuotteiden yleisiä hyväksyntöjä. Valmistajan dokumentaatio, lisenssisopimus ja palautustesti tekevät päätöksestä luotettavan.
| Sovellus | Arviointipolku | Kriittinen kysymys |
|---|---|---|
| Windows-ERP, tietokanta ja valmistajatuki | VM luontevana lähtökohtana | Mikä vierasjärjestelmän, hypervisorin, SQL:n ja lisenssien yhdistelmä on todella tuettu? |
| Oma Linux-verkkopalvelu ja toistettava koonti | OCI-sovelluskontti, tarvittaessa Linux-VM:ssä | Kuka rakentaa ja päivittää kuvat, tarkistaa haavoittuvuudet sekä ylläpitää rekisteriä, salaisuuksia ja lokeja? |
| Valmistajan Linux-appliance | Tarkista ensin tuettu VM | Hyväksyykö valmistaja virtualisoinnin, virtuaalilaitteet ja suunnitellun varmistus-/palautuspolun? |
| Tietokanta, jolla on suuri kirjoituskuorma | VM tai bare metal mittausten mukaan; kontti vain testatulla pysyvyydellä | Miten p95-/p99-viive, IOPS, replikointi ja johdonmukainen palautus toimivat huippukuormassa? |
| Palvelu, jossa on dongle, erikoiskortti tai suora laitepääsy | Testaa VM:n läpivienti; harkitse bare metalia | Säilyvätkö valmistajatuki, laitekohdistus ja palautus mahdollisina isännän vaihdon jälkeen? |
Tietokantakontti ei ole lähtökohtaisesti väärin. Sen kirjoitettava tiedostojärjestelmä ei kuitenkaan sovi datalle, jonka pitää säilyä kontin vaihdon jälkeen. Suunnittele volyymit, johdonmukaisuus, varmistukset ja palautus erikseen. VM:kään ei tee testaamattomasta tietokantavarmistuksesta luotettavaa palautusta.
Kuusi tarkistusta päätökselle
- Valmistaja ja lisenssi: Tarkista tuetut järjestelmät, hypervisorit, konttimoottorit ja laitesidokset kirjallisesti. Windows Server -oikeudet riippuvat muun muassa versiosta, lisensoiduista ytimistä, virtuaaliympäristöjen määrästä ja sopimuksesta; ”yksi VM” ei tarkoita kiinteää hintaa.
- Eristys ja käyttöoikeudet: Mikä palvelu saa vaikuttaa toiseen? Konteilla on nimiavaruudet ja resurssirajat, mutta ne jakavat isännän ytimen. Suoritusympäristö, oikeudet, liitokset, verkko ja päivitykset kuuluvat tietoturvatarkastukseen.
- Mittaa suorituskyky: Kerää todellisella datalla CPU-, RAM- ja I/O-kuorma, p95-/p99-viive, huiput ja eräajoikkunat. Bare metalin valinta vain oletetun ”virtualisointilisän” vuoksi voi sitoa kallista kapasiteettia ratkaisematta todellista tallennus- tai verkko-ongelmaa.
- Data ja palautus: Määritä RPO ja RTO palvelukohtaisesti. Harjoittele täydellinen palautus toisella isännällä: tietokanta, määritykset, tunnukset ja riippuvuudet mukaan lukien.
- Muutokset ja henkilöstö: Kuka päivittää vierasjärjestelmän tai isännän ytimen? Kuka rakentaa konttikuvat uudelleen? Kuka selvittää yöllä epäonnistuneen palautuksen edelliseen versioon tai laitevaihdon? Osaaminen rajaa järkevästi rinnakkain ylläpidettävien alustojen määrää.
- Vika-alue: Arvioi isäntä, tallennus, verkko ja varmistus erikseen. Yksittäinen bare metal -palvelin tai useat saman isännän kontit eivät muutu korkean käytettävyyden ratkaisuksi nimensä ansiosta.
Vertaa työmäärää ennen säästölupauksia
Vertaa kolmen tai viiden vuoden aikana jokaisessa sarakkeessa samaa sovellusta samalla kuormalla ja palautustavoitteella. Laske mukaan alkuperäinen siirto ja rakentaminen, laitteisto varaosineen, järjestelmä- ja sovellusoikeudet, hypervisorin tai moottorin tuki, energia, varmistus, valvonta ja vuosittaiset työtunnit. OCI lisää esimerkiksi koontiputken, rekisterin, kuvien ylläpidon ja mahdollisen orkestroinnin. Bare metal voi edellyttää varalaitteistoa ja toista huoltoikkunaa. VM:issä huomioidaan isäntäkapasiteetti ja vierasjärjestelmät. Olemassa oleva klusteri on uudelle palvelulle ”ilmainen” vain, jos reservit, lisenssit ja ylläpitoresurssit todella ovat käytettävissä.
Tarkistettava peruskaava on: kokonaiskustannus ajalta n vuotta = kertaluonteinen rakentaminen ja siirto + n × (vuosilisenssit + tuki + energia + varmistus + ylläpitotunnit × sisäinen tuntihinta) + suunniteltu uudistaminen. n on kolme tai viisi. Mikään käyttötapa ei ole yleisesti halvempi ilman tarkkoja tarjouksia, kuormamittauksia ja tukiehtoja. Vertailussa pitää näkyä myös saavuttamatta jäävien RPO/RTO-tavoitteiden hinta, ei jättää sitä laskelman ulkopuolelle.
Miten DAXS valitsisi käyttötavan
DAXS laatisi ensin lyhyen sovelluslistan omistajineen, datavirtoineen, valmistajatukineen, riippuvuuksineen ja palautustavoitteineen. Kahta realistista ehdokasta testattaisiin lyhyesti: tuotannon kaltainen kuorma, päivityspolku, isännän tai laitteen vika ja palautus toisella koneella. Tuloksena on perusteltu sovelluskohtainen valinta, ei vaatimus siirtää kaikkia palveluja yhdelle alustalle.
Nykyisiä Windows- ja Linux-VM:iä voi usein arvioida vaiheittain; Proxmox yrityksessä kuvaa virtualisointipohjan. Jos kontit sopivat, Docker Composen ja Kubernetesin vertailu auttaa seuraavassa vaiheessa. Tietyn kuorman kohdalla Yhteystiedot tarjoaa reitin sopia DAXSin kanssa tukien, mittausten ja palautuksen muuttamisesta käyttöpäätökseksi.
Lähteet: Proxmox VE: KVM ja LXC · Docker Engine: tietoturvamalli · Docker Engine: pysyvä data · Microsoft: Windows Server Virtualization Licensing Guidance.
