vSphere Replication Appliance – dotkliwa luka w dokumentacji

Produkty VMware są nieustannie rozwijane, dlatego dobrze byłoby nadążać za nowymi rozwiązaniami. W wersji szóstej pojawił się nowy model SSO, a vCenter został rozdzielony na dwa elementy: Platform Service Controller oraz vCenter Server.

Nowy model wyeliminował Linked Mode, zniósł również konieczność użycia serwera Windows oraz wymóg na licencję vSphere Standard. Teraz możliwe okazało się w licencji Essential Plus połączenie wszystkich serwerów vCenter, co ułatwia zarządzanie całym środowiskiem poprzez użycie jednej konsoli (webowej oczywiście).

Przejście z vCenter with embedded Platform Controller na linksowy appliance VCSA with external PSC (jednocześnie zmieniając domenę SSO) wydawało się tak złożonym procesem (o ile wykonalnym), że postanowiłem pominąć proces migracji i konfigurację środowiska zacząć od nowa.

Na początku procesu miałem jeden linuksowy appliance z PSC oraz drugi z VCSA. Drugi serwer, vCenter, był na widows trybie embedded PSC. Dla każdego vCenter został skonfigurowany Replication Appliance oraz uruchomiona została replikacja maszyn wirtualnych pomiędzy nimi. Obok działającego vCenter z Windows wdrożyłem PSC i dołączyłem do domeny SSO (utworzonej w istniejącym wcześniej PSC). W kolejnym kroku wdrożyłem VCSA rejestrując w nowym PSC (pomijam tutaj wiele szczegółów, ale zamgliłby one obraz całości). Jeśli ktoś byłby zainteresowany pogłębieniem wiedzy, warto skorzystać z tego adresu, tego oraz tego.

Po wdrożeniu nowego vCenter przepiąłem do niego hosty ESXi. W konsekwencji istniejąca replikacja maszyn wirtualnych przestała działać, należało zatem w pierwszej kolejności przywrócić tę funkcjonalność. Wymagane jest wyrejestrowanie vRA ze starego vCenter. Niestety ponowna jego rejestracja do nowego vCenter nie udała się w 100%. VMware vCenter nie może się skutecznie skomunikować z vRA. W opisie pomijam wiele podjętych kroków, których celem była naprawa zaistniałej sytuacji. Nie chcąc tracić czasu, skasowałem istniejące vRA (zgodnie z procedurą podaną powyżej) i wdrożyłem je od początku. Konfigurując, zachowałem wszystkie ustawienia – w szczególności VRM Site name.

Przykładowy ekran konfiguracji vRA

Wszystko poszło świetnie, vRA widnieje w vCenter, nie sygnalizując żadnych błędów. W kolejnym kroku należy połączyć ze sobą oba vRA celem uruchomienia replikacji pomiędzy serwerami vCenter.

Niespodziewanie otrzymałem komunikat błędu:

The HMS service search did not return exactly one match

Ponieważ nie mogłem znaleźć rozwiązania problemu, a replikację należało w miarę szybko uruchomić, podjąłem drastyczne kroki – skasowałem oba vCenter i vRA. Wg dokumentacji vRA rejestruje się tylko w vCenter, więc wykonany krok powinien przeciąć ten gordyjski węzeł. Na koniec wyrejestrowałem oba serwery vCenter z PSC.

Kiedy wdrażałem nowe vRA, w nowych serwerach vCenter pojawił się kłopot – pewne ustawienia przeszły do PSC – jego rozwiązanie łatwo było znaleźć.

Konfigurując wszystko od początku, w wyniku zmęczenia, zapomniałem ustawić takie same VRM Site name jak poprzednio. Nieoczekiwanie jednak pomyłka pozwoliła uruchomić replikację pomiędzy serwerami vCenter. Na koniec, gdy wszystko zadziałało, został jeden kłopot – stare nazwy VRM Site name nadal były widoczne w konfiguracji.

VRM Site name ze starego środowiska widoczne w nowym

Pojawiło się pytanie o przyczynę braku możliwości uruchomienia nowego  vRA, pomimo skasowania starego. Wyglądało na to, że jakaś dodatkowa informacja o Replication Appliance zapisuje się także w PSC. Niestety dokumentacja VMware nic na ten temat nie wspomina. Nawet przejście kroków podanych tutaj nic nie daje.

Aby rozwikłać zagadkę skorzystałem ze wsparcia VMware. Rozwiązanie problemu wymaga zalogowania się przez SSH do PSC. Po uruchomieniu shell’a wydajemy komendę

/usr/lib/vmidentity/tools/scripts/lstool.py list –url http://localhost:7080/lookupservice/sdk | less

Wpisując ”/< VRM Site name>”, odnajdziemy interesujący nas wpis (pod warunkiem, że jest unikalny), możemy też wpisać ”/Virtual machine replication management and monitoring service”, aby przejrzeć wszystkie wpisy o istniejących w konfiguracji vRA.

Powinniśmy uzyskać coś podobnego:

——————————————————
Name: vrms-682df880-e270-4c10-af88-f7dc24b47c8b–94a6171b-d245-4d2d-8877-263c580df0f4
Description: Virtual machine replication management and monitoring service
Service Product: com.vmware.cis
Service Type: com.vmware.vr.vrms
Service ID: Primary:8351d631-eed3-48d8-9a17-eea7b6f47327
Site ID: primary
Owner ID: {Name: com.vmware.vr-682df880-e270-4c10-af88-f7dc24b47c8b, Domain: vsphere.local}
Version: 6.0.0.1
Endpoints:
Type: com.vmware.vim.hms
Protocol: vmomi
URL: https://XXXXXX:8043
SSL trust: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Attributes:
sitename: DRC
vc_proxy_port: 80
solution_username: com.vmware.vr-682df880-e270-4c10-af88-f7dc24b47c8b
config_url: http://XXXXXX/
——————————————————

Z powyższego możemy się dowiedzieć, że VRM Site name starego vRA występuje tutaj jako sitename. Informacja jaką potrzebujemy to: Service ID.

Ostatecznie, aby rozwiązać problem, wydajemy polecenie:

/usr/lib/vmidentity/tools/scripts/lstool.py unregister –user “Administrator@vsphere.local” –password “<AKTUALNE HASŁO>” –id Primary:8351d631-eed3-48d8-9a17-eea7b6f47327 –no-check-cert –url https://<PSC_FQDN>/lookupservice/sdk

Zakładam, że VMware niedługo zaktualizuje dokumentację lub wyda nowy dokument KB, prawdopodobnie w kolejnej wersji zachowanie systemu także się zmieni – tymczasem lepiej uważać, aby nowego vRA nie nazwać tak jak stare.