VBR 13.1: replikacja VM w Proxmox - możliwości, wymagania i ograniczenia

Cześć wszystkim,

długo odkładałem dzielenie się takimi materiałami, bo większość obserwacji z Veeam kończyła dotąd w dokumentacji projektowej, runbookach albo rozmowach technicznych. W końcu trzeba jednak zacząć. Od dnia premiery pracuję już produkcyjnie na VBR 13.1, na razie w kontrolowanym zakresie. Serię zaczynam od zmiany, na którą czekałem najbardziej - Proxmox przestaje być dla Veeam wyłącznie platformą backupową.

VBR 13.1 rozszerza istniejącą ochronę Proxmox o natywną replikację VM. Osobno dodaje Instant VM Recovery uruchamiane na Proxmox. W aktualnym What’s New ten konkretny kierunek Instant Recovery jest oznaczony jako Experimental Support. Tego oznaczenia nie powtarzają jednak szczegółowa strona procedury ani Release Notes. Nie dotyczy ono Entire VM Restore, natywnej replikacji ani Instant Recovery backupu Proxmox na inną platformę.

Jak to wygląda od strony technicznej

Są tu dwa osobne przepływy:

replikacja: VBR -> plug-in Proxmox -> worker -> host i storage źródłowy -> host i storage docelowy

Instant VM Recovery: backup repository -> worker -> uruchomienie VM na Proxmox -> migracja na storage produkcyjny

Worker, sieć zarządzająca, sieć transportowa, mapowanie VLAN i wydajność storage stają się więc częścią RTO. Samo utworzenie repliki albo uruchomienie VM bez testu sieci, zależności i późniejszej migracji nie potwierdza gotowości DR.

Co się zmieniło

Replikacja VM obejmuje dwa podstawowe scenariusze:

bezpośrednią replikację host-to-host, także w mniejszych środowiskach bez współdzielonego storage;
replikację pomiędzy centrami danych, również pomiędzy różnymi typami storage.

Poza replikacją VBR 13.1 dodaje:

Instant VM Recovery do Proxmox z backupów image-level pochodzących z innych wspieranych platform;
przypisywanie tagów VLAN do workerów oraz odtwarzanych VM;
automatyczne wstrzykiwanie sterowników VirtIO przy odtwarzaniu maszyn spoza Proxmox;
dokładniejsze statystyki i widok postępu operacji restore w Web UI;
szerszą obsługę Proxmox w Web UI;
Advanced RBAC dla zarządzania ochroną Proxmox.

Osobną funkcją Web UI jest Instant Recovery backupu image-level z dowolnego wspieranego hypervisora na VMware vSphere, Microsoft Hyper-V albo Nutanix AHV. To nie jest to samo co uruchomienie workloadu bezpośrednio z backupu na Proxmox. Status Experimental Support wskazany w What’s New dotyczy celu Proxmox, a nie wszystkich operacji restore z backupami Proxmox.

Dlaczego ma to znaczenie w projektach

Nowy typ joba to dopiero początek. W DR liczy się cały ciąg:

backup lub replika -> uruchomienie VM -> poprawne mapowanie sieci -> migracja na storage produkcyjny -> test aplikacji

Widzę tu trzy konkretne zastosowania:

budowę DR na Proxmox bez dokładania innej platformy tylko na potrzeby odtwarzania;
migrację workloadów z VMware lub Hyper-V do Proxmox przy użyciu istniejących backupów;
szybszą odbudowę środowiska, gdy docelowa platforma po awarii nie musi być taka sama jak źródłowa.

Wymagania i status wsparcia

Dla wydania 13.1.0.411 aktualna dokumentacja wskazuje:

Proxmox VE 8.2-9.2, zainstalowany z oficjalnego obrazu ISO;
Veeam Plug-in for Proxmox VE 4, build 13.4.0.300;
workery oparte na Veeam JeOS 9.6;
jedną instancję VUL na chronioną VM, przy czym maszyna pozostaje liczona jako chroniona przez 31 dni od utworzenia punktu przywracania.

Dwie informacje są szczególnie ważne:

What’s New oraz wypowiedź Veeam Product Management wskazują Experimental Support dla Instant VM Recovery uruchamianego na Proxmox. Szczegółowa instrukcja tej operacji i Release Notes nie powtarzają tego oznaczenia, dlatego przed wpisaniem funkcji do SLA potwierdziłbym aktualny status z Veeam;
Advanced RBAC dla Proxmox również jest oznaczone jako Experimental Support.

Nie przenosiłbym tego zastrzeżenia na Entire VM Restore, replikację Proxmox ani odtwarzanie backupu Proxmox do VMware, Hyper-V lub Nutanix AHV. Te operacje trzeba oceniać według ich własnych wymagań i ograniczeń.

Natywna ochrona kontenerów LXC nie jest częścią tego scenariusza. Projekt obejmujący LXC nadal wymaga osobnej strategii dla systemu, danych aplikacyjnych i odtwarzania.

Ograniczenia istotne w projekcie

Zadanie replikacji konfiguruje się w desktopowej Remote Console, nie w Web UI.
W Web UI klaster nie jest prezentowany jako jeden obiekt. Poszczególne węzły trzeba dodać oddzielnie.
Przy replikacji w obrębie tego samego klastra MAC źródłowej VM nie jest zachowywany.
Zadanie może się nie udać, jeżeli wielkość dysku źródłowego nie jest wielokrotnością block size storage docelowego.
Natywna ochrona nie obejmuje między innymi LXC, template VM, passthrough disks, dysków iSCSI podłączonych do gościa oraz VM znajdujących się na BTRFS lub custom storage.
Cloud Repository nie może być bezpośrednim celem joba backupowego VM Proxmox. Taki backup trzeba najpierw zapisać w zwykłym repozytorium, a następnie wysłać do Cloud Repository przez Backup Copy. VCC obsługuje Proxmox jako źródło pierwszego Backup Copy, ale nie obsługuje dla niego kolejnego Backup Copy tworzonego z istniejącego Backup Copy. Po stronie tenanta odtwarzanie kopii Proxmox przechowywanej w VCC jest ograniczone do File-Level Restore. Provider może natomiast wykonać Instant Recovery takiej kopii do VMware vSphere, a według What’s New 13.1 również do Microsoft Hyper-V. Do Nutanix AHV, Proxmox VE, oVirt KVM, Scale Computing HyperCore i HPE Morpheus VM Essentials dostępny jest po stronie providera Entire VM Restore. Szczegółowy Cloud Connect Guide nadal wskazuje VMware vSphere jako jedyny cel Instant Recovery, co jest niespójne z What’s New 13.1 i przed użyciem Hyper-V wymaga potwierdzenia dla konkretnego builda.

Co sprawdzić przed użyciem produkcyjnym

Mój minimalny plan testów obejmuje:

Replikację host-to-host w tej samej lokalizacji.
Replikację pomiędzy lokalizacjami i różnymi typami storage.
Failover, failback i zachowanie punktów przywracania.
Instant VM Recovery backupu z innej platformy do Proxmox.
Start systemu po wstrzyknięciu VirtIO oraz poprawność usług aplikacyjnych.
Mapowanie VLAN dla workera i odtwarzanej VM.
Migrację uruchomionej maszyny na storage produkcyjny i pełne sprzątnięcie sesji restore.
Rzeczywisty RTO, wykorzystanie workerów, sieci i repozytorium.

Wyniki takiego testu są ważniejsze niż samo zakończenie zadania statusem Success. VM musi się uruchomić, mieć właściwą sieć, dostęp do zależności i przejść test aplikacyjny.

Jak Wy projektujecie DR dla Proxmox?

Samo potwierdzenie, że replikacja działa, niewiele jeszcze mówi o późniejszym utrzymaniu. Inaczej zachowa się prosty układ host-to-host w oddziale, inaczej druga serwerownia z osobnym storage, a jeszcze inaczej Proxmox użyty jako cel migracji z innej platformy.

Jestem ciekaw, jak rozwiązujecie kilka rzeczy:

kiedy wybieracie replikację, a kiedy pozostajecie przy Backup Copy i pełnym restore;
jak separujecie sieć replikacji, workerów i ruch maszyn uruchamianych po awarii;
czy stosujecie ten sam, czy inny typ storage po stronie docelowej i jak wpływa to na czas synchronizacji;
jak wygląda u Was test failover, test aplikacyjny i późniejsze sprzątanie środowiska;
czy Instant VM Recovery uruchamiane na Proxmox, opisane w What’s New jako Experimental Support, dopuszczacie wyłącznie w laboratorium, czy także jako kontrolowany wariant awaryjny;
jakie RTO udało się uzyskać przy rzeczywistych rozmiarach VM i dostępnej przepustowości.

Jeśli macie już wyniki z 13.1, podajcie build, ogólny wariant topologii, przybliżoną wielkość VM i najważniejsze ograniczenie. Bez nazw organizacji i wrażliwych szczegółów nadal da się zebrać użyteczne dane.

Źródła

Czy ktoś z Was ma już wyniki replikacji pomiędzy różnymi typami storage albo Instant VM Recovery z VMware lub Hyper-V do Proxmox? Interesują mnie szczególnie czasy uruchomienia, mapowanie sieci i etap migracji na storage produkcyjny.