VBR 13.1 - VSA i VIA - co zmieniło się w praktyce

Cześć wszystkim,

VSA i VIA obserwuję od premiery VBR 13. Pierwsze wydanie pokazało kierunek, ale w projektach szybko wychodziły ograniczenia związane ze storage, transportem danych i późniejszym utrzymaniem oraz ich rozwojem. W 13.1 kilka z tych braków wreszcie znika.

VSA i VIA korzystają z Veeam JeOS, ale pełnią inne funkcje. To rozróżnienie jest ważne, bo nie wdraża się ich według jednej wspólnej procedury (choć sama instalacja przebiega podobnie).

Najpierw: czym różnią się VSA i VIA

VSA jest kompletnym serwerem VBR.

VIA jest hostem dla wybranych ról infrastruktury i po instalacji dodaje się ją do istniejącego serwera VBR.

Po instalacji z ISO lub OVA pierwszą konfigurację wykonuje się w kreatorze. W przypadku VIA na tym etapie wybiera się profil appliance, na przykład Infrastructure Server, iSCSI & NVMe/TCP albo Hardened Repository. Ustawienia systemu - sieć, czas, użytkowników, certyfikaty, storage i aktualizacje - obsługuje się później w HMC: jako ​​​​​​Host Management Web UI lub TUI.

Dopiero po tej konfiguracji VIA jest dodawana do VBR i otrzymuje właściwe role infrastruktury. Zadania backupowe konfiguruje się w konsoli VBR lub, w obsługiwanym zakresie, w VBR Web UI. Samo podłączenie dysku w HMC nie tworzy repozytorium, a wybór profilu VIA nie jest jeszcze przypisaniem roli proxy, WAN Acceleratora czy Cloud Gateway.

Najważniejsze zmiany wspólne

Zmiany wspólne dla appliance obejmują między innymi:

• obsługę lokalnych urządzeń, Fibre Channel i iSCSI wraz z multipathingiem w HMC;
• możliwość przeniesienia logów na osobny zamontowany wolumen przez wskazanie własnej ścieżki w HMC;
• Veeam JeOS 9.6;
• możliwość wykorzystania Enterprise Managera jako lokalnego źródła aktualizacji, bez bezpośredniego pobierania pakietów przez każdy appliance;
• konfigurację MFA także z Host Management Web UI oraz rozszerzone zarządzanie użytkownikami;
• import zaufanych certyfikatów do systemowego magazynu i użycie własnego certyfikatu TLS dla HMC;
• podgląd użycia CPU, pamięci i dysków w HMC, wysyłanie zdarzeń do sysloga oraz metryki Node Exportera zgodne z Prometheusem. Node Exporter wymaga licencji VUL.

Zmiany specyficzne dla VSA

Do działającego VSA można dokładać dyski 😁. Nowe urządzenie można zarejestrować jako kolejne repozytorium, a następnie wykorzystać na przykład jako dodatkowy extent istniejącego SOBR. Nie oznacza to dowolnego powiększania już używanego LUN-u albo systemu plików, a nowy storage nie staje się repozytorium automatycznie.

What's New i help center odnośnie rodzajów transportu opisują HotAdd dla VSA all-in-one na VMware vSphere. To istotne, gdy appliance jest jednocześnie serwerem VBR i proxy. Aktualna strona ograniczeń VSA nadal podaje jednak wyłącznie transport Network, więc przed użyciem produkcyjnym sprawdziłbym status dla konkretnego builda (nie sprawdziłem jeszcze, bo chwilowo gównie Proxmox 😉). 

W trybie automatycznym VSA używa HotAdd, jeśli funkcja została włączona w HMC i tryb transportu jest dostępny. W przeciwnym razie przechodzi na tryb Network. Dodanie lokalnego, iSCSI lub FC storage do VSA restartuje usługę HotAdd. Trwające backupy i operacje odtwarzania korzystające z tego transportu zakończą się błędem, dlatego z taką zmianą trzeba poczekać do zakończenia zadań.

Rozszerzono również wdrożenie bezobsługowe VSA (unattended deployment). Instalacja może od razu otworzyć ograniczone czasowo okno na podłączenie VSPC / VCC (brakowało tego), Veeam ONE lub Veeam Recovery Orchestrator oraz przygotować VSA do późniejszego dodania do klastra HA. Nie rejestruje to automatycznie VSA w systemie zarządzającym i nie konfiguruje klastra.

VSA automatycznie zwiększa limit miejsca przeznaczonego na wewnętrzną bazę, gdy zaczyna go brakować, i alarmuje, jeżeli kończy się pojemność samego wolumenu. Dla Hyper-V dostępny jest już  również gotowy obraz VSA.

Zmiany specyficzne dla VIA

VIA można nareszcie wdrożyć w wariancie Single Disk, bez osobnego dysku na dane. Przydaje się to dla proxy korzystającego ze zdalnego repozytorium albo VIA w roli Hardened Repository, na którym ma działać np. Application Backup Repository (także ciekawa nowość). Repozytorium można wtedy utworzyć w ścieżce /var/lib/veeamdata/backup lub pod nią.

Przy instalacji trzeba uważać: w wariancie Single Disk instalator formatuje wszystkie lokalne dyski podłączone w tym momencie do serwera.

VIA korzysta teraz ze wspólnego menu startowego. Profil Infrastructure Server, iSCSI & NVMe/TCP albo Hardened Repository wybiera się później w kreatorze Initial Configuration.

Wariant VIA z iSCSI & NVMe/TCP może działać jako VMware backup proxy korzystające z Direct SAN przez FC lub iSCSI. Produkcyjne LUN-y VMFS muszą być widoczne dla proxy, ale nie wolno ich formatować ani dodawać w HMC jako storage repozytorium. LUN pozostaje źródłowym datastore VMware. Multipathing dla linuksowego proxy zapewnia przełączenie na drugą ścieżkę, ale nie równoważy ruchu pomiędzy ścieżkami.

To zupełnie inny przypadek niż podłączenie nowego dysku pod repozytorium. Takie urządzenie dodaje się w HMC, a później tworzy na nim repozytorium w VBR. Aktualne ograniczenia zabraniają też instalacji VSA lub VIA na maszynie, która ma już skonfigurowane urządzenia multipath.

Gdzie ja widzę zastosowanie

Te zmiany są praktyczne w kilku typach projektów:

• VSA działające jako maszyna VMware i jednocześnie jako serwer VBR oraz proxy, gdzie HotAdd może zastąpić część ruchu Network (docelowo po potwierdzeniu ograniczeń dla używanego builda);
• repozytoria oparte na nowych urządzeniach lokalnych, FC albo iSCSI dodawanych przez HMC;
• VIA jako VMware backup proxy korzystające z Direct SAN, z produkcyjnymi LUN-ami prezentowanymi wyłącznie do odczytu danych;
• automatyczne wdrożenia VSA przygotowywane pod późniejsze podłączenie do VSPC, Veeam ONE albo klastra HA;
• VIA jako wyspecjalizowany proxy ze zdalnym repozytorium albo Hardened Repository z ABR w wariancie Single Disk;
• środowiska z ograniczonym dostępem do Internetu, korzystające z Enterprise Manager jako lokalnego źródła aktualizacji.

Ważna rozbieżność w dokumentacji którą zauważyłem

Na dzień dzisiejsz, oficjalne strony Veeam nie są w pełni spójne:

• What's New 13.1 oraz Host Management opisują dodawanie nowych urządzeń lokalnych, iSCSI i FC;
• strony Veeam Software Appliance Considerations and Limitations oraz Veeam Infrastructure Appliance Considerations and Limitations, oznaczone jako właściwe dla builda 13.1.0.411, nadal mówią, że po wdrożeniu nie można dodawać urządzeń ani zmieniać ich rozmiaru;
• What's New 13.1 i strona HotAdd opisują HotAdd dla VSA all-in-one, natomiast strona ograniczeń VSA dla tego samego builda nadal mówi o wyłącznej obsłudze transportu Network;
• strony ograniczeń nie pozwalają instalować VSA ani VIA na maszynie, która ma już urządzenia multipath, mimo że późniejsze podłączanie FC/iSCSI i multipathing są opisane jako nowość.

Dopóki dokumentacja jest niespójna, ciężko to jednoznacznie rozstrzygnąć. Urządzenie dodane jako storage w HMC nie staje się automatycznie repozytorium VBR i trzeba je osobno skonfigurować w konsoli. Nie dotyczy to LUN-ów prezentowanych wyłącznie na potrzeby Direct SAN - tych nie wolno konfigurować jako repozytorium. Prawdopodobnie na dniach zostanie to zaktualizowane i poprawione, ale jeśli strony nadal będą sobie przeczyć, przed wdrożeniem produkcyjnym potrzebne jest potwierdzenie z Veeam Support dla konkretnego wariantu wdrożenia.

Pozostałe granice architektoniczne

• Serwer VBR działający po stronie usługodawcy Veeam Cloud Connect nadal musi pracować na Windows (niestety - bo na to baaardzo czekam 😑).
• Migracja działającego VBR z Windows do VSA nie jest obsługiwana w wersji 13.1. Release Notes zalecają zainteresowanym pozostać na najnowszym wydaniu 13.0 i skontaktować się z Veeam Support przed rozpoczęciem takiego projektu ,a Tomek Krajewski pisał o tym tu .
• VSA nie jest automatycznym zamiennikiem każdego istniejącego serwera Windows. Decyzja zależy od wymaganych funkcji, integracji (pluginów), modelu licencjonowania i planowanej ścieżki migracji.

Ile czasu przeznaczyć na aktualizację VSA lub VIA

Aktualizacja VSA lub VIA obejmuje nie tylko komponenty Veeam. Veeam Updater instaluje również poprawki systemu i bezpieczeństwa, sprawdza zależności, restartuje usługi, a gdy jest to potrzebne - cały appliance. Restart VSA oznacza niedostępność HMC i VBR Web UI oraz utratę połączenia konsoli z serwerem VBR. Przy restarcie VIA niedostępne są HMC i role działające na tej konkretnej appliance, ale główny serwer VBR pozostaje dostępny, o ile jego bieżąca operacja nie zależy od aktualizowanej VIA.

Veeam nie podaje jednego czasu aktualizacji dla wszystkich konfiguracji. Na VSA i VIA rezerwowałbym większe okno niż na aktualizację zwykłego komponentu Veeam. Wolniejsze dyski, mniejsza liczba zasobów CPU i wolniejsze pobieranie pakietów mogą wyraźnie wydłużyć instalację.
U mnie najdłuższa aktualizacja trwała około 4 godzin, a najkrótsza zamknęła się w oknie 30 minutowym.

Mam już za sobą kilka aktualizacji środowisk VCC do 13.1. Same serwery VBR zaktualizowały się bez problemu. Dodatkowej uwagi wymagały pojedyncze VIA pracujące jako WAN Acceleratory i Cloud Gateway. W jednym przypadku aktualizację VIA musiałem uruchomić ręcznie z Host Management.

Release Notes opisują podobny, ale węższy przypadek dla VIA z rolą WAN Accelerator: po przejściu z 13.0 do 13.1 host może pozostać w stanie Out of Date po nieudanej aktualizacji systemu. Veeam zaleca wtedy ponowne uruchomienie Host Upgrade Wizard. Nie rozszerzałbym tego automatycznie na wszystkie Cloud Gateway - to osobna obserwacja z mojego wdrożenia.

Przed aktualizacją dokumentacja zaleca utworzenie backupu konfiguracji. W praktyce sprawdzam też, czy ostatnia sesja zakończyła się sukcesem, backup jest zaszyfrowany i znajduje się poza aktualizowanym VSA. Bez szyfrowania backup konfiguracji nie zawiera poświadczeń, kluczy szyfrowania ani certyfikatów.

W przypadku VIA chodzi o backup konfiguracji zarządzającego serwera VBR. Nie jest to pełny obraz systemu VIA, dlatego zapisuję też jego profil, ustawienia sieci, podłączony storage i przypisane role.

Jeżeli appliance działa jako VM, ręczny snapshot na poziomie hypervisora może być jedynie krótkotrwałym zabezpieczeniem pomocniczym po zatrzymaniu zadań i sprawdzeniu spójności całego wdrożenia. Nie jest standardową procedurą odtworzenia, nie zastępuje backupu konfiguracji i nie powinien być wykonywany przez zadanie backupu lub replikacji tego samego VBR. Po weryfikacji aktualizacji snapshot trzeba usunąć.

Bezpośrednio po aktualizacji serwera VBR lub VSA nie warto jeszcze oceniać jego wydajności. Zadanie optymalizujące bazę konfiguracji może pracować do około godziny, zależnie od jej rozmiaru. Nie dotyczy to każdej samodzielnej VIA.

Checklista którą już realizowałem, a sobie rozpisałem

1. Potwierdzić dokładny build VBR, VSA/VIA i JeOS.
2. Wykonać świeży, zaszyfrowany backup konfiguracji i sprawdzić dostępność pliku poza aktualizowanym appliance.
3. Dla VIA zapisać profil, sieć, podłączony storage i role przypisane w VBR.
4. Jeśli architektura i granice wsparcia na to pozwalają, utworzyć krótkotrwały snapshot jako dodatkowe zabezpieczenie i zaplanować jego usunięcie.
5. Zweryfikować aktualne strony ograniczeń dla dokładania dysków i HotAdd.
6. Dla nowego repozytorium dodać urządzenie przez HMC zgodnie z potwierdzoną procedurą, a następnie utworzyć repozytorium w VBR.
7. Dla Direct SAN zaprezentować VIA produkcyjne LUN-y bez montowania i formatowania ich jako repozytorium oraz zweryfikować mapowanie datastore.
8. Dla FC/iSCSI sprawdzić utratę i powrót jednej ścieżki oraz pamiętać, że multipathing na linuksowym proxy nie zapewnia równoważenia ruchu.
9. Porównać wydajność HotAdd i Network na tej samej grupie testowej VM.
10. Przetestować wdrożenie bezobsługowe VSA, a następnie sprawdzić podłączenie VSPC lub Veeam ONE w otwartym oknie zdalnego dostępu.
11. Sprawdzić aktualizację appliance bezpośrednio oraz przez lokalne źródło aktualizacji w Enterprise Managerze.
12. Po aktualizacji zweryfikować HMC i Web UI, status usług i hostów, pierwsze zadania oraz ewentualny stan Out of Date VIA.

Co sprawdziło się u Was?

VSA i VIA trafiają na bardzo różną infrastrukturę: lokalne dyski, macierze FC, iSCSI, VMware, Hyper-V, ograniczony Internet i istniejący monitoring. Udana instalacja to dopiero początek. Więcej mówią warunki brzegowe.

Dajcie znać:

• jak rozdzielacie urządzenia przeznaczone na repozytorium od LUN-ów prezentowanych VIA wyłącznie dla Direct SAN;
• jak zachowuje się multipathing podczas utraty i powrotu jednej ścieżki oraz jaki wpływ ma brak równoważenia ruchu;
• czy HotAdd w VSA all-in-one daje u Was przewagę nad Network transport i dla jakiej skali;
• ile realnie trwa aktualizacja całego appliance na szybkiej i na mniej wydajnej infrastrukturze;
• gdzie przechowujecie zaszyfrowany backup konfiguracji, aby był dostępny także po awarii aktualizowanego systemu;
• czy stosujecie snapshot VM jako krótkotrwałe zabezpieczenie pomocnicze i jakie macie zasady jego usuwania;
• czy i jak wykorzystujecie Prometheus, syslog i lokalne źródło aktualizacji w Enterprise Managerze w środowiskach odseparowanych.

Podawajcie konkretny build, bo przy szybko rozwijanym appliance różnica pomiędzy What's New, stroną ograniczeń i zachowaniem danego wydania ma znaczenie.

Źródła

• What's New - VSA i VIA
• About Veeam Host Management
• Host Management - Managing Storage
• VSA Unattended Deployment
• Transport Modes
• Direct SAN Access
• Virtual Appliance - HotAdd
• VSA Considerations and Limitations
• VIA Considerations and Limitations
• Updating Veeam Appliances
• How Appliance Updates Work
• Installing Appliance Updates
• Configuration Backup
• Encrypted Configuration Backups
• After Upgrading VBR
• VBR 13.1 Release Notes

Czy ktoś otrzymał już jednoznaczne potwierdzenie dotyczące dodawania nowych dysków i HotAdd dla builda 13.1.0.411? Jeśli dokumentacja zostanie ujednolicona, warto dopisać wynik bezpośrednio w tym wątku.