Wybór odpowiedniej wirtualnej maszyny zależy od środowiska fizycznego, w którym jest lokowana, architektury warstwy pośredniczącej oraz jej roli w cyklu życia systemów informatycznych.
4.1. Podział ze względu na środowisko uruchomieniowe
Lokalizacja fizyczna, w której działa wirtualna maszyna determinuje jej skalowalność, model zarządzania i koszty operacyjne:
- Wirtualna maszyna lokalna (Desktop VM) Środowisko uruchamiane na komputerze osobistym, stacji roboczej lub laptopie inżyniera z wykorzystaniem oprogramowania desktopowego (np. Oracle VM VirtualBox, VMware Workstation, UTM, Parallels Desktop). Desktop VM służy przede wszystkim do celów edukacyjnych, eksperymentów architektonicznych, analizy podejrzanego kodu w odizolowanej piaskownicy (malware analysis) i uruchamiania aplikacji dedykowanych dla innych systemów (np. dystrybucji Linuksa na stacji z systemem macOS). Jej wydajność i stabilność są ściśle ograniczone parametrami podzespołów komputera lokalnego.
- Wirtualna maszyna serwerowa (On-premise VM) Instancja funkcjonująca na dedykowanym klastrze serwerów fizycznych zlokalizowanych we własnej serwerowni lub prywatnym centrum danych przedsiębiorstwa. Zarządzana bezpośrednio przez wewnętrzny zespół inżynierów i administratorów za pośrednictwem platform takich jak VMware vSphere czy Proxmox VE. Pozwala na pełną kontrolę nad fizycznym sprzętem i ścisłą separację danych, jednak obarcza firmę wysokimi kosztami inwestycyjnymi (CapEx), koniecznością serwisowania podzespołów, wymiany zużytych dysków oraz zarządzania zasilaniem i chłodzeniem.
- Wirtualna maszyna w chmurze (Cloud VM / Cloud Instance) Obecny standard wdrażania infrastruktury, w którym instancja uruchamiana jest w elastycznym, redundantnym centrum danych dostawcy usług chmurowych. Użytkownik nie zarządza warstwą fizyczną, lecz zyskuje pełną kontrolę nad systemem operacyjnym poprzez konsolę webową, API lub narzędzia Infrastructure as Code. Wirtualna maszyna w chmurze gwarantuje bezprzerwowy dostęp do certyfikowanej infrastruktury klasy Enterprise (redundantne zasilanie, macierze NVMe, klastry High Availability) oraz rozliczenie godzinowe w modelu Pay-As-You-Go.
4.2. Podział ze względu na architekturę hypervisora
Warstwa, na której osadzony jest monitor maszyn wirtualnych, definiuje narzut wydajnościowy i stopień izolacji:
- Hypervisor Typu 1 (Bare-metal / Natywny) Działa bezpośrednio na surowym sprzęcie fizycznym serwera (bare-metal), bez pośrednictwa tradycyjnego systemu operacyjnego. Sam hypervisor pełni rolę ultralekkiego, zoptymalizowanego jądra systemowego zarządzającego czasem procesora, alokacją pamięci i magistralami I/O. Dzięki bezpośredniemu dostępowi do instrukcji Intel VT-x oraz AMD-V narzut wydajnościowy wynosi poniżej 1–2%, co czyni ten model standardem w środowiskach produkcyjnych, systemach bazodanowych oraz chmurach obliczeniowych. Przykłady: KVM (Kernel-based Virtual Machine), VMware ESXi, Microsoft Hyper-V Server, Xen.
- Hypervisor Typu 2 (Hosted / Aplikacyjny) Instalowany jako zwykła aplikacja w przestrzeni użytkownika tradycyjnego systemu operacyjnego (np. Windows 11, macOS, Ubuntu Desktop). W tym modelu każde odwołanie wirtualnej maszyny do sprzętu musi pokonać podwójną ścieżkę: z systemu gościa do hypervisora, a następnie z hypervisora do systemu gospodarza (host OS). Generuje to zauważalny narzut procesora i opóźnienia magistrali dyskowej, przez co hypervisory typu 2 stosowane są wyłącznie w celach deweloperskich i edukacyjnych.
4.3. Podział ze względu na zastosowanie w cyklu życia oprogramowania
W metodykach DevOps maszyny wirtualne są precyzyjnie kategoryzowane według ich roli w procesie wytwórczym:
- Maszyny deweloperskie (Dev VM) Środowiska robocze służące programistom do lokalnego lub zdalnego pisania i kompilacji kodu. Zapewniają identyczną konfigurację bibliotek i wersji interpreterów dla wszystkich członków zespołu, eliminując problemy niezgodności środowiskowej.
- Maszyny testowe i stagingowe (Test/Staging VM) Środowiska stanowiące wierną kopię architektury produkcyjnej pod względem wersji kernela, konfiguracji baz danych i topologii sieciowej. Służą zespołom QA do automatycznych testów regresyjnych, testów wydajnościowych oraz weryfikacji procedur wdrożeniowych (tzw. próby generalne przed publikacją). Po zakończeniu cyklu testów maszyny stagingowe mogą być automatycznie niszczone w celu oszczędzania budżetu.
- Maszyny produkcyjne (Prod VM) Krytyczne instancje realizujące zadania biznesowe, na których uruchomione są serwery aplikacji, platformy e-commerce oraz produkcyjne bazy danych. Cechują się rygorystycznymi umowami SLA (Service Level Agreement), twardą alokacją rdzeni procesora, ultraszybkimi dyskami Enterprise NVMe, automatycznymi politykami snapshotów oraz umieszczeniem w klastrach wysokiej dostępności (HA) z automatycznym przełączaniem awaryjnym (failover).
Nawigacja po przewodniku
← Poprzedni rozdział: 3. Jak działa wirtualna maszyna? Architektura techniczna
Następny rozdział: 5. Najczęstsze zastosowania wirtualnych maszyn →
