Arkana apokalipsy i aktualizacja vCenter

Parny wieczór potęgował emocje. Wszyscy mówili, że to konieczne. Niepewność, jednak pozostawiała te nieprzyjemne uczucie rwania w żołądku. Jest jeszcze szansa zawrócić… Drzwi pachniały kadzidłem, ich abstrakcyjna zieleń wśród szarości korytarza odcinała się od rzeczywistości zapowiadając oczekującą w środku zagadkę.

Przedpokój przywitał chłodem. Dywany rozlane w korytarzu jak wielowarstwowa tkanka skórna, bezwzględnie odcinały świat zewnętrzny od trzewi pomieszczenia. Ciężkie kolonialne meble tłoczyły się przy ścianach emanując dostojeństwem i tajemnicą. Pogłoski o tym miejscu bywały różne – niektórzy wychodzili rozbawieni, inni pełni nadziei, zdarzali się i tacy, którym ścieżki losu zwiastowały tragedię. Wszyscy jednak bezsprzecznie mówili, że to jedyny sposób aby uzyskać choć strzępek informacji o tym czy update vCenter do nowej wersji się powiedzie… 

Tak, chyba niema innej drogi niż Tarot, czy też wróżka aby to przewidzieć. Rozważałem jeszcze wypad do Szeptuchy, ale wszystkie, które znam niestety umarły… Dość jednak tych żarcików, temat jest dość poważny. To już kolejny raz kiedy zespół VMware stawia mnie w dość niezręcznej sytuacji. Aktualizacja infrastruktury vSphere, bo o tym mowa, jest chyba najbardziej niedopracowanym procesem w całym światku produktów VMware. Ma być z założenia prosta, ale jest taka chyba tylko w przypadku instalacji laboratoryjnych. Zawsze coś idzie nie tak. Tym razem problem pojawił się z moimi ulubionymi technologiami – czyli SSO, Java i Tomcat, istne arkana apokalipsy.

Może zacznijmy od tego, kiedy problem może się objawić… Przeprowadzałem aktualizacje vCenter z wersji 5.5 do 5.5 Update 2B. Sprawa zdawała się trywialna jak poderwanie nastolatki na darmową fajkę. Jednak gdy przyszło co do czego fajka okazała się pochodnią a dziewczyna wilkołakiem.

Standardowa procedura aktualizacji vCenter mówi o tym, że należy ją wykonywać w kolejności SSO -> Web Client -> Inventory -> Server. Tak też i postąpiłem. Wszytko działało wyśmienicie, aż do drugiego kroku, czyli aktualizacji Web Client’a. Jakież było moje zdziwienie i tak znaczną poprawą procedury – w końcu wywaliła się dopiero na drugim kroku, cóż, niestrudzenie rozpocząłem poszukiwania. Generalnie warto przeanalizować logi z instalatora, mogą one nam przedstawić gdzie leży problem – może brak uprawnień, może uszkodzony plik instalatora… a może brak komunikacji z webservice SSO?

Można by napisać wiele nienawistnych artykułów na temat przejrzystości komunikatów błędów w produktach VMware. Zatem gdy uzyskacie następujące wpisy w logach instalatora:

VMware vSphere Web Client-build-1304121: 12:03:23 Util_Launch::done Res: 1
VMware vSphere Web Client-build-1304121: 12:03:23 Return code is 1 (successful operation however may not necessarily need return code 0).
VMware vSphere Web Client-build-1304121: 12:03:23 SSO Registration tool launched
VMware vSphere Web Client-build-1304121: 12:03:23 SSO registration tool failed with return code 1
VMware vSphere Web Client-build-1304121: 12:03:23 Please see vm_ssoreg.log in system temporary folder

To znaczy że macie problem z webservice SSO. Intuicyjne nieprawdaż? Chwileczkę, ale przecież SSO zainstalowało się poprawnie, a nie działa? Internet pełen jest materiałów dotyczących rozwiązywania problemów z SSO, niestety skupiają się one głównie na kwestiach związanych z instalacją modułów, lub certyfikatów , a nie na rozwiązywaniu ewentualnych problemów które mogą się wydarzyć w ich własnym działaniu. Zatem gdy spotykamy się z problemem pustego ekranu na https://sso.cmentarnapolka.pl:7444/lookupservice/sdk, lub w ogóle braku jakiejkolwiek strony pod tym adresem to zaczyna się robić nieprzyjemnie. Oczywiście pozostaje serwis producenta, gdzie po kilku dniach pałowania się z Hindusami w końcu dotrzemy do kogoś kompetentnego… ale nic. Co robić w takiej sytuacji?

Należy sprawdzić Javę. VMware ma swój instalator bardzo specyficznej jej wersji, który umieszcza pliki w lokalizacji:

C:\Program Files\Common Files\VMware\VMware vCenter Server – Java Components

Tam powinny się znajdować pliki Java Runtime Environment, jak również i w to miejsce powinny nas kierować zmienne w serwerze Tomcat na którym działają webservice. Plik konfiguracyjny wrappera dla TC Servera, czyli małego Tomcata znajduje się tutaj:

C:\ProgramData\VMware\CIS\runtime\VMwareSTS\conf\wrapper.conf

Plik ten odpowiada za ustawienie serwera Tomcat, czyli zawiera w sibie wszytko co niezbęde, aby zadziałał, lub jak w naszym przypadku nie. Odnajdzmy w nim linie zawierajacą zmienną “set.JAVA_HOME”, powinna być ona ustawiona tak, jak wspomniałem na Javę od VMware, zatem zmieniamy ją na:

set.JAVA_HOME=C:\Program Files\Common Files\VMware\VMware vCenter Server – Java Components

W pliku konfiguracji wrappera powinny nas zainteresować również zmienne:

set.CATALINA_HOME=C:\Program Files\Common Files\VMware\VMware vCenter Server – tc Server
set.CATALINA_BASE=C:\ProgramData\VMware\CIS\runtime\VMwareSTS
wrapper.java.command=%JAVA_HOME%\bin\java

Dwa pierwsze parametry definują miejsce w którym spoczywa nasz Tomcat i elementy które mamy zamiar przez niego uruchamiać. Dobrze by było aby te parametry były jak najbardziej zbliżone do powyższych. Trzecim elementem jest lokalizacja binarki javy. Plik “java” musi się znajdować w scieżce inaczej nicic z działania.

Ok restartujemy serwisy SSO lub serwer. Dalej pusta strona, lub jej brak? Nie przejmujcie się u mnie było podobnie, kiedy już spróbowałem wydawało mi się wszystkiego:

• Wyczyściłem wszystkie cache, foldery tymczasowe (CIS w Program Files i ProgramData, %TEMP% i Temp właściwy), klucze rejestru,
• Odinstalowałem wszytko z serwera. Nowa instalacja kończyła się tym samym – bezbłędnie działające SSO, które nie udostępnia webservice, czyli nie działa.
• Przeinstalowałem Jave, dodałem wpisy do pliku hosts na vC bo zdawało mi się, że jakoś dziwnie resolvował, wyłączyłem vShield, nic nie pomogło, przestawiłem zaawansowane priorytety kart sieciowych w Windows.
• Usunąłem usługi z services.msc, uruchomiłem ręcznie warppery javy z plikami konfiguracyjnymi – nie pojawiły się żadne błędy, a dalej nie działało.
• Zmieniłem użytkowników usługi z lokalnych na domenowe – nie pomogło, tak samo bezbłędnie a brak webservice.

Zastała mnie trzecia w nocy. Postanowiłem postawić zatem czysty serwer na Windows 2012. Swoją droga wiecie, że aby zadziałało w ogóle SSO w powiązaniu z AD na Win 2K12 należy podmienić plik systemowy %WINDIR%\System32\idm.dll na spcejalnie spreparowany przez VMware? Nie, proszę tu jest KB. Tak więc po przygotowaniu, aktualizacji i kofiguracji systemu (wyłączenia Windows Firewall, UAC itp.) zainstalowałem na świeżo SSO. Jakież było moje zaskoczenie gdy również nie zadziałało.

Postanowiłem podejść do sprawy nieco inaczej – transplantacja. Wyłączyłem serwisy SSO i podmieniłem Javę na starą, z poprzedniej wersji. Restart, dalej nic. Kolejny krok, usunąłem TC Server z lokalizacji…

C:\Program Files\Common Files\VMware\VMware vCenter Server – tc Server

…i wgrałem na jego miejsce starą wersję, z 5.5. Restart i działa. Operację powtórzyłem dwa razy. Za każdym razem po powrocie do snapshota czystego systemu, instalacji SSO i wymianie plików znajdujących się w katalogu VMware vCenter Server – tc Server wszytko magicznie się uruchamiało. Zatem, uwaga dla tych co planują aktualizację – poza wizytą na szybkiego tarocika, zróbcie backup nie tylko bazy SSO, ale i binarek, gdyż mogą się przydać do szybkiej, ratującej życie transplantacji.

Więcej informacji o debuggowaniu SSO możecie znaleźć między innymi w tej prezentacji – http://www.slideshare.net/fbuechsel/sso-51-startup-issues.