Live Migration – przenoszenie działającej maszyny wirtualnej
Live Migration to technologia pozwalająca przenieść działającą maszynę wirtualną z jednego hosta na drugi bez jej normalnego wyłączania.
To jedna z najważniejszych funkcji współczesnych platform wirtualizacyjnych, takich jak Hyper-V, VMware vSphere czy KVM/Proxmox.
Najprościej:
HOST A HOST B
+---------+ +---------+
| VM | =================> | VM |
| RUNNING | Live Migration | RUNNING |
+---------+ +---------+
Użytkownik korzystający z aplikacji może nawet nie zauważyć migracji.
Po co stosuje się Live Migration?
Najczęstsze zastosowania:
- konserwacja hosta,
- aktualizacje hypervisora,
- wymiana sprzętu,
- równoważenie obciążenia,
- HA,
- optymalizacja wykorzystania CPU/RAM,
- przenoszenie workloadów między hostami.
Przykład:
HOST-A
CPU: 90%
RAM: 85%
HOST-B
CPU: 25%
RAM: 30%
Możemy przenieść część VM:
HOST-A
|
| Live Migration
v
HOST-B
bez klasycznego shutdownu VM.
Co właściwie jest przenoszone?
Najważniejszym elementem jest stan VM.
W uproszczeniu:
VM
|
+-- CPU state
+-- RAM
+-- Virtual devices
+-- Network state
+-- VM configuration
Największym problemem jest pamięć RAM.
Przykład:
VM RAM = 64 GB
Hypervisor musi doprowadzić do sytuacji, w której host B posiada odpowiedni stan pamięci VM.
Klasyczna migracja
Bez Live Migration:
1. Shutdown VM
2. Copy VM
3. Start VM
Czyli:
HOST A
|
v
VM STOP
|
| Copy
v
HOST B
|
v
VM START
Przerwa może być długa.
Live Migration
W Live Migration VM nadal działa:
HOST A
|
| VM RUNNING
|
+------ Memory copy ------> HOST B
|
| VM continues running
|
+------ Final state ------> HOST B
|
v
VM RUNNING
Pre-Copy Migration
Jednym z klasycznych algorytmów jest pre-copy.
Proces:
VM on Host A
|
v
Copy RAM to Host B
|
v
VM keeps running
|
v
Copy changed pages
|
v
Copy again
|
v
Final switchover
Dirty Pages
Podczas kopiowania RAM aplikacja nadal działa.
Oznacza to, że VM może zmienić dane, które właśnie zostały skopiowane.
Takie strony pamięci nazywamy w tym kontekście dirty pages.
Przykład:
RAM Host A
Page 1 → copied
Page 2 → copied
Page 3 → modified
Page 4 → copied
Page 5 → modified
Hypervisor musi ponownie przesłać:
Page 3
Page 5
Proces migracji
W uproszczeniu:
START
|
v
Copy memory
|
v
Track dirty pages
|
v
Copy dirty pages
|
v
Repeat
|
v
Short VM pause
|
v
Transfer final state
|
v
Resume VM on Host B
|
v
DONE
Dlaczego VM musi zostać na chwilę zatrzymana?
W pewnym momencie trzeba przenieść ostatni fragment stanu:
CPU registers
Virtual device state
Remaining dirty memory
Wtedy VM jest na bardzo krótko zatrzymywana.
Schemat:
RUNNING
|
v
FINAL SYNC
|
v
SHORT PAUSE
|
v
TRANSFER
|
v
RUNNING
To właśnie ta krótka przerwa jest określana jako downtime migracji.
Im więcej zmian w RAM, tym trudniej
Wyobraź sobie VM:
RAM = 128 GB
która bardzo intensywnie zmienia pamięć.
Jeżeli:
Memory write rate > Migration bandwidth
hypervisor może mieć problem z dogonieniem zmian.
Przykład:
VM zmienia:
20 GB/s
Sieć migracyjna:
10 GB/s
Wtedy:
Dirty pages
↑
|
+---- rosną szybciej,
niż można je wysyłać
Live Migration staje się trudniejsza.
Sieć jest bardzo ważna
Najlepiej mieć dedykowaną sieć migracyjną:
Production Network
|
VM
|
+------+------+
| |
Host A Host B
Migration Network
25/40/100 GbE
| |
Host A Host B
Dzięki temu kopiowanie RAM nie konkuruje bezpośrednio z ruchem aplikacji.
Przykład
VM:
RAM = 32 GB
Sieć:
25 Gb/s
Teoretycznie:
25 Gb/s ÷ 8 ≈ 3.125 GB/s
Pierwsze 32 GB mogłyby zostać przesłane w idealnych warunkach w około:
32 / 3.125 ≈ 10.2 s
W praktyce będzie dłużej ze względu na:
- dirty pages,
- protokoły,
- storage,
- CPU,
- inne obciążenie sieci.
Shared Storage
Live Migration może działać w środowisku ze wspólnym storage.
Przykład:
Shared Storage
|
+---------+---------+
| |
Host A Host B
| |
VM1 VM1
W takim przypadku dyski VM nie muszą być za każdym razem kopiowane pomiędzy hostami.
Przenoszony jest przede wszystkim stan VM.
Storage Live Migration
Istnieje również migracja VM wraz z jej dyskami.
HOST A
|
+-- VM
|
+-- Disk
|
| Storage Migration
v
HOST B
|
+-- Disk
To znacznie większa operacja.
Shared vs Local Storage
Shared Storage
Host A ----+
|
+---- SAN/NFS/Ceph
|
Host B ----+
VM korzysta ze wspólnego storage.
Local Storage
Host A
|
SSD-A
|
VM
Host B
|
SSD-B
Przy migracji trzeba również zapewnić dostęp do danych na Host B.
Live Migration w Hyper-V
W środowisku Hyper-V funkcja Live Migration pozwala przenosić działające VM między kompatybilnymi hostami.
Schemat:
Hyper-V Host A
|
| Live Migration
v
Hyper-V Host B
|
v
Running VM
W praktyce często łączy się ją z:
Failover Cluster
+
CSV
+
Live Migration
Live Migration w KVM/QEMU
W KVM/QEMU migracja może wyglądać:
KVM Host A
|
QEMU
|
| Migration
v
KVM Host B
|
QEMU
|
VM
QEMU przesyła stan VM pomiędzy hostami.
Live Migration w Proxmox
Proxmox VE wykorzystuje mechanizmy KVM/QEMU.
Typowy scenariusz:
Proxmox Node 1
|
VM
|
| Migrate
v
Proxmox Node 2
|
VM
W zależności od konfiguracji migracja może działać zarówno ze storage współdzielonym, jak i w odpowiednich scenariuszach z lokalnym storage.
Live Migration a CPU
Host docelowy musi być kompatybilny z VM.
Przykład:
Host A
Intel CPU
|
v
VM
|
v
Host B
Intel CPU
Jeżeli host B ma inną generację CPU, mogą pojawić się problemy z dostępnymi instrukcjami procesora.
Dlatego hypervisory oferują mechanizmy typu:
CPU compatibility
CPU baseline
CPU mode
CPU Compatibility
Możemy ograniczyć zestaw instrukcji CPU widoczny dla VM:
Physical CPU
|
v
Compatibility Mode
|
v
VM
Dzięki temu VM może być łatwiej migrowana pomiędzy różnymi hostami.
Ceną może być niewykorzystanie części najnowszych możliwości procesora.
Live Migration a VirtIO
VirtIO bardzo dobrze pasuje do Live Migration.
Dlaczego?
Ponieważ VM korzysta z:
virtio-net
virtio-scsi
virtio-blk
czyli urządzeń wirtualnych.
Nie jest przywiązana do konkretnego fizycznego NIC czy kontrolera.
Host A
|
VirtIO
|
VM
|
VirtIO
|
Host B
Live Migration a PCI Passthrough
Tutaj sytuacja jest znacznie trudniejsza.
Przykład:
Host A
|
GPU
|
VM
Po migracji:
Host B
|
GPU?
|
VM
Host B musi posiadać kompatybilne urządzenie.
Dlatego PCI Passthrough może ograniczać:
- Live Migration,
- HA,
- automatyczny scheduling.
Live Migration a SR-IOV
SR-IOV również może komplikować migrację.
VM:
VM
|
VF
|
Physical NIC
Po migracji:
VM
|
VF ?
|
Physical NIC on Host B
Host B musi zapewnić odpowiednią Virtual Function.
Dlatego w środowiskach, gdzie migracja jest priorytetem, VirtIO bywa prostszym rozwiązaniem.
Network State
Podczas migracji trzeba również zachować ciągłość sieci.
Przykład:
VM
MAC = AA:BB:CC:DD:EE:FF
IP = 10.0.0.20
Po migracji:
Host B
|
VM
|
MAC = AA:BB:CC:DD:EE:FF
IP = 10.0.0.20
Sieć musi zostać odpowiednio poinformowana, gdzie znajduje się VM.
Może to wymagać mechanizmów takich jak:
ARP
ND
virtual switch
overlay network
SDN
Storage + Network + Compute
W rzeczywistości Live Migration jest problemem obejmującym trzy obszary:
Live Migration
|
+-----------+-----------+
| | |
CPU RAM Network
| | |
+-----------+-----------+
|
Storage
Wszystkie muszą być odpowiednio zaprojektowane.
Live Migration nie oznacza zero downtime
To ważne rozróżnienie.
Live Migration
≠
0 ms downtime
Zazwyczaj występuje krótka faza:
VM
|
RUNNING
|
SHORT PAUSE
|
RUNNING
Dobrze zaprojektowane środowisko może ograniczyć tę przerwę do bardzo krótkiego czasu, ale nie należy automatycznie zakładać absolutnego braku przerwy.
Co może uniemożliwić migrację?
Najczęstsze problemy:
❌ niekompatybilny CPU
❌ brak storage
❌ brak odpowiedniej sieci
❌ PCI Passthrough
❌ różne konfiguracje VM
❌ brak kompatybilnych urządzeń
❌ zbyt duża liczba dirty pages
❌ przeciążona sieć
❌ brak odpowiednich uprawnień
Live Migration i HA
Te technologie często współpracują.
Cluster
|
+----------+----------+
| |
Host A Host B
| |
VM1 VM2
Jeżeli Host A wymaga konserwacji:
Host A
|
| Live Migration
v
Host B
Administrator może wyłączyć Host A bez zatrzymywania usług VM.
Maintenance Mode
Typowy scenariusz:
1. Host A
2. Uruchom maintenance
3. Migruj VM
4. Host A = 0 VM
5. Aktualizuj host
6. Restart
7. Przywróć workload
To ogromnie upraszcza utrzymanie infrastruktury.
Automatyczne Load Balancing
W dużych środowiskach migracja może być automatyczna.
Host A
CPU 95%
|
v
Scheduler
|
v
Live Migration
|
v
Host B
CPU 40%
System może przenosić VM tam, gdzie są dostępne zasoby.
Live Migration w klastrze
Docelowa architektura może wyglądać tak:
Cluster
|
+-------------+-------------+
| | |
Node 1 Node 2 Node 3
| | |
VM1 VM2 VM3
| | |
+-------------+-------------+
|
Shared / Distributed
Storage
VM mogą być przenoszone pomiędzy węzłami.
Live Migration – pełny proces
HOST A
|
v
Running VM
|
v
Pre-copy VM memory
|
v
Track dirty pages
|
v
Copy changed pages
|
v
Final sync
|
Short pause
|
v
Transfer state
|
v
HOST B
|
v
Resume VM
|
v
DONE
Najważniejsze technologie
Live Migration jest często elementem większego stosu:
Hypervisor
|
+-- CPU Virtualization
|
+-- Memory Management
|
+-- Virtual Networking
|
+-- Storage
|
+-- Live Migration
|
+-- HA
|
+-- Cluster
Live Migration vs Cold Migration
| Cecha | Live Migration | Cold Migration |
|---|---|---|
| VM działa podczas kopiowania | ✅ | ❌ |
| Downtime | bardzo mały | większy |
| Wymagania | większe | mniejsze |
| Złożoność | większa | mniejsza |
| Produkcja | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ |
| Maintenance | świetne | gorsze |
Live Migration vs Backup
To również zupełnie różne funkcje.
Live Migration
→ przeniesienie działającej VM
natomiast:
Backup
→ utworzenie kopii danych umożliwiającej odtworzenie
Live Migration nie chroni przed:
ransomware
usunięciem danych
korupcją danych
błędem administratora
Do tego potrzebujesz backupu.
Najważniejsze do zapamiętania
Live Migration
|
v
Running VM
|
v
Memory pre-copy
|
v
Dirty pages
|
v
Final synchronization
|
v
Short pause
|
v
Host B
|
v
VM continues running
Live Migration pozwala utrzymać ciągłość działania VM podczas przenoszenia jej pomiędzy hostami. Największym wyzwaniem jest synchronizacja pamięci RAM oraz zapewnienie kompatybilności CPU, storage i urządzeń wirtualnych.
I właśnie dlatego wcześniejsze tematy VirtIO, SR-IOV i PCI Passthrough są ze sobą tak mocno powiązane: VirtIO maksymalizuje elastyczność migracji, SR-IOV daje więcej wydajności kosztem części elastyczności, a PCI Passthrough zapewnia najbardziej bezpośredni dostęp do sprzętu, ale najbardziej komplikuje migrację.
🛠️ Aktualizacja i patchowanie platform wirtualizacyjnych oraz systemów gości Wirtualizacja to podstawa współczesnej infrastruktury IT. Umożliwia efektywne wykorzystanie zasobów, automatyzację Czytaj dalej
🌍 Jak naprawić problemy z zdalnym dostępem do maszyn wirtualnych? 🧠 Wprowadzenie: Rola zdalnego dostępu w środowiskach opartych o wirtualizację Czytaj dalej
