VBR 13.1 - Proxmox - wreszcie coś więcej niż tylko podstawowy backup

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, moich wewnętrznych runbookach, rozmowach technicznych albo materiałach szkoleniowych. W końcu trzeba jednak zacząć.

Od dnia premiery pracuję już produkcyjnie na VBR 13.1. Mam za sobą kilkanaście aktualizacji i wdrożeń, w tym środowiska VCC. Serię zaczynam więc od zmiany, na którą czekałem najbardziej - Proxmox przestaje być dla Veeam wyłącznie platformą backupową, momentami traktowaną trochę po macoszemu.

VBR 13.1 rozszerza istniejącą ochronę Proxmox o natywną replikację VM. W 13.1 pojawił się także Instant VM Recovery uruchamiany na Proxmox. Miałem już okazję sprawdzić go razem z Entire VM Restore (dostępnym już jakiś czas) w kilku scenariuszach migracyjnych i awaryjnych. Trzeba jednak rozdzielić kierunki odtwarzania, bo nie wszystkie są nowością 13.1 i nie wszystkie mają ten sam status wsparcia.

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 -> mount server i worker -> uruchomienie VM na Proxmox -> migracja na storage produkcyjny

Źródłem może być również kopia znajdująca się w VCC 😀 Tutaj trzeba jednak rozdzielić operację wykonywaną przez tenanta od managed recovery prowadzonego przez providera. Dokumentacja 13.1 nie jest w tym miejscu całkowicie spójna, dlatego opiszę ten wariant osobno po kolejnych testach.

Worker, sieć zarządzająca, sieć transportowa, mapowanie VLAN i wydajność storage stają się więc częścią RTO.

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 (nareszcie - ile było zabawy przy ponownych wdrożeniach 😃) 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 (Proxmox nie wygląda już jak „biedniejszy kuzyn” vSphere i Hyper-V 😅);
• szerszą obsługę Proxmox w Web UI (chyba powoli trzeba będzie się przesiąść, jak to miało miejsce lata temu z vCenter - ktoś jeszcze pamięta narzekania na vCenter Web UI? Ja ostatnio miałem okazję u dwóch klientów migrować coś z vCenter 5.5… powiem Wam, że nic przyjemnego 😐);
• Advanced RBAC dla zarządzania ochroną Proxmox (jeśli ktoś naprawdę granularnie wszystko buduje).

Backup VM Proxmox można również uruchomić przez Instant Recovery na VMware vSphere, Microsoft Hyper-V albo Nutanix AHV. To odwrotny kierunek niż nowy Instant VM Recovery uruchamiany na Proxmox i nie jest objęty tym samym statusem Experimental Support.

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, które wykorzystałem już w projektach produkcyjnych:

• budowę DR na Proxmox bez dokładania innej platformy tylko na potrzeby odtwarzania;
• migrację obciążeń z VMware lub Hyper-V do Proxmox przy użyciu istniejących backupów;
• szybszą odbudowę środowiska, gdy docelowa platforma po awarii nie musi (albo nie może) 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 i należy je brać pod uwagę zawsze, a nie dopiero po wystąpieniu problemów:

• What's New oraz Veeam Product Management wskazują status Experimental Support dla Instant VM Recovery uruchamianego na Proxmox. Tego oznaczenia nie powtarzają jednak szczegółowa instrukcja ani Release Notes. Z punktu widzenia formalnego wsparcia traktuję więc tę funkcję jako eksperymentalną. Przed wpisaniem jej do SLA potwierdziłbym aktualny status z Veeam Support, mimo że miałem już okazję używać jej produkcyjnie.
• Advanced RBAC dla Proxmox również jest oznaczone jako Experimental Support.

Nie traktowałbym tych elementów tak samo jak funkcji objętych pełnym wsparciem produkcyjnym. 

Experimental Support dotyczy Instant VM Recovery uruchamianego na Proxmox. Nie dotyczy:

• Entire VM Restore;
• replikacji Proxmox-Proxmox;
• Instant Recovery backupu Proxmox do VMware, Hyper-V lub Nutanix AHV.

Natywna ochrona kontenerów LXC nie jest (niestety 😑) częścią tego scenariusza. Projekt obejmujący LXC nadal wymaga osobnego podejścia (strategii) dla systemu, danych aplikacyjnych i odtwarzania.

Ograniczenia istotne w projekcie (na które warto zwrócić uwagę, bo np. środowiska konsolowe nie są wciąż 1:1 i lepiej się nie zaskoczyć)

• 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, dysków passthrough, 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 Proxmox. Backup zapisujemy najpierw w zwykłym repozytorium, a następnie wysyłamy do VCC przez Backup Copy. Taka kopia może zostać wykorzystana przez providera do managed recovery, ale dostępne metody odtwarzania zależą od platformy docelowej, uprawnień tenanta, a także szyfrowania.

Co sprawdzić przed użyciem produkcyjnym

Mój minimalny plan testów, sprawdzony już w praktyce, obejmuje:

1. Replikację host-to-host w tej samej lokalizacji.
2. Replikację pomiędzy lokalizacjami i różnymi typami storage.
3. Failover, failback i zachowanie punktów przywracania.
4. Instant VM Recovery backupu z innej platformy do Proxmox.
5. Start systemu po wstrzyknięciu VirtIO oraz poprawność usług aplikacyjnych.
6. Mapowanie VLAN dla workera i odtwarzanej VM.
7. Migrację uruchomionej maszyny na storage produkcyjny i pełne sprzątnięcie sesji restore.
8. 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 (istotne przy aktualnych cenach storage, z którymi mierzymy się wszyscy);
• jak wygląda u Was test failover, test aplikacyjny i późniejsze sprzątanie środowiska;
• czy Instant VM Recovery ze statusem Experimental Support dopuszczacie wyłącznie w laboratorium, czy także jako kontrolowany wariant awaryjny, a może już produkcyjnie;
• jakie RTO udało się uzyskać przy rzeczywistych rozmiarach VM i dostępnej przepustowości (ktoś to mierzy?🤣).

Jeśli macie już wyniki z 13.1, ogólny wariant topologii, przybliżoną wielkość VM i najważniejsze ograniczenie, na które natrafiliście.

Źródła

• What's New - Hypervisor Protection
• What's New - Web UI
• System Requirements - Proxmox VE
• Proxmox VE - ograniczenia
• Proxmox VE - licencjonowanie
• VBR 13.1 Release Notes

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.