Jak wykonać aktualizację środowiska EUC tak, aby nie zrobić sobie krzywdy

Infrastruktura przeznaczona na potrzeby wirtualizacji stacji roboczych jest u niektórych niejednokrotnie ważniejsza niż zwirtualizowane serwery. Sprawa jest oczywista, nie ma „stacji roboczych” wszyscy nie mogą pracować. Nie ma serwerów, ludzie również nie mogą pracować, ale potencjalnie nie wszyscy. Powinniśmy zatem dbać równie starannie o oba środowiska. Niestety czasem zdarza się, że uaktualnienie któregoś ze środowisk jest bardziej problematyczne. Wpływa na to wiele czynników takich jak wsparcie producenta sprzętu i oprogramowania, wielkość okna serwisowego o ile takie jest potrzebne, duży przeskok między wersjami oprogramowania i energia jaką musimy spalić podczas takich prac. Czasem również spotykam się z podejściem „przecież działa” po co cokolwiek ruszać. Nie sposób się z tym nie zgodzić, ale często warto mieć aktualne środowisko choćby dla nowych funkcjonalności wprowadzonych w nowszych wersjach lub działania samego backendu dzięki czemu wiele rzeczy może wykonywać się automatycznie lub szybciej. Dodatkowo dbamy o bezpieczeństwo.

Jak wiemy doskonale VMware w swoim portfolio posiada produkt, który pozwala nam wirtualizować systemy operacyjne Windows, Linux czy Mac OSX i serwować je do terminali. VMware View bo tak początkowo się nazywał produkt został wydany w wersji 3.1.3 w maju 2009r. Tego samego roku pojawiła się wersja 4, a w 2012 wersja 5. Od wersji 6 zmieniono nazwę na VMware Horizon. Aktualnie najnowszą wersją jest VMware Horizon 7.9 (stan na 19.09.2019 r.). Elementami składowymi infrastruktury w wydaniu VMware są m.in. vCenter Server, ESXi, Horizon Connection Server, View Composer, Horizon Agent, Security Server, Persona Management czy VMware ThinApp. Widzimy już na początku, że infrastruktura zawiera kilka dodatkowych elementów w porównaniu z tą klasyczną na potrzeby serwerów. Dodatkowo w przypadku vCenter Serwer może wykorzystywać zewnętrzną bazę danych opartą na MS SQL czy Oracle lub wbudowaną opartą w przypadku Windows vCenter Server na PostgreSQL (która swoją drogą ma spore ograniczenia). Czyli dodatkowo widzimy, że dochodzą kolejne elementy powiązane z infrastrukturą. Z pomocą przychodzi nam sam producent, który posiada specjalną stronę, na której znajdziemy pełną matrycę kompatybilności produktów. Podczas aktualizacji jest ona niezbędna aby nie zapędzić się w kozi róg.

Mając kilka słów wstępu przechodzimy do samej aktualizacji. Załóżmy, że wychodzimy od wersji vCenter Server 6.0.0 zainstalowanego na Windows Server 2012 z zewnętrzną bazą danych MS SQL, dwa Connection Server’y 6.2.1, Composer Server 6.2.0 i ESXi w wersji 5.5.0. No to zaczynamy aktualizacje, tylko pytanie brzmi, od którego elementu? Sprawa jest na pozór bardzo oczywista, zaczynamy od vCenter Server, w końcu nawet pewien ekspert VMware napisał: „It’s recommended to upgrade vCenter first, then the ESXi and then Horizon.”  

No i tutaj pojawiają się problemy w postaci kompatybilności produktów. Gdy chcemy podnieść wersję vCenter do najnowszej stracimy wsparcie dla wersji VMware Horizon 6. To samo dotyczy samych serwerów ESXi, pewne funkcjonalności mogą nie działać poprawnie, no i sam ESXi 5.5U3 nie wspiera najnowszej wersji Horizon 7. W takich wypadkach aktualizacje musielibyśmy przeprowadzać na wszystkich elementach w jednym czasie. Może się to wiązać z dłuższym czasem, który jest potrzebny do ukończenia procesu aktualizacji, oraz mogą występować problemy z dostępnością usług. Brzmi to niezbyt dobrze gdy mamy 4 tys. użytkowników działających na swoich wirtualnych desktopach. Aby odpowiednio się przygotować do aktualizacji musimy zerknąć w kilka miejsc. Podstawową stroną, którą każdy powinien mieć w ulubionych jest VMware’owy HCL (Link). Drugą stroną, którą warto przejrzeć jest VMware Product Interoperability Matrices (Link). Dostępne są na niej wszelkie zależności między produktami VMware, zależnościami wersji baz danych czy to Oracle czy Microsoftu, no i możliwe ścieżki aktualizacji określonych produktów. Czyli tak naprawdę wszystko to, co tygrysy lubią najbardziej. Polecam również przeczytać artykuł spod klawiatury Sebastiana. Opisuje on aktualizację vCloud Directora oraz proces przygotowania się do takiego przedsięwzięcia oraz co zrobić po. Sebastian przedstawia schemat działania oraz jak się przygotować. Co prawda dotyczy to vCD, ale podobny schemat działań możemy zastosować niemal do każdego produktu, nie tylko VMware.

Wcześniej wspomniałem o kilku elementach, z których składa się rozwiązanie. Przyjrzyjmy się jak to wygląda. Poniżej schemat środowiska.

Teraz jak już wiemy jak to wygląda logicznie możemy przystąpić do samej aktualizacji. Aktualizować możemy bezpośrednio do wersji Horiozon 7.9 przy pewnych założeniach. Jednym z nich jest aby posiadać najnowszą wersje Horizon View 5.3,Horizon 6 (with View) lub VMware Horizon 6 w wersji 6.1 lub 6.2. W przypadku VMware Horizon 6 mówimy tutaj o wersji 6.2.9, która pojawiła się stosunkowo niedawno. Jeżeli nie posiadamy najnowszych wersji to należy takową aktualizacje wykonać. Przejście między wersjami gdzie zmienia się nam trzecia cyfra po kropce (x.x.9) przechodzi stosunkowo bez większych komplikacji. Przynajmniej ja osobiście nie natknąłem się na jakiś problem. Oczywiście jeżeli posiadamy już wersję 7.x sama aktualizacja jest już nieco łatwiejsza i szybsza. Kolejną rzeczą jest tzw. FIPS mode. Wraz z wersją 6.2 i nowszymi możemy instalować komponenty właśnie w tym trybie. Sam FIPS (Federal Information Processing Standards) jest lub są standardami, które zostały zdefiniowane przez rząd USA  w zakresie zatwierdzania oprogramowania kryptograficznego. Standardy FIPS określają najlepsze praktyki i wymagania bezpieczeństwa dotyczące implementacji algorytmów kryptograficznych, schematów szyfrowania, obsługi ważnych danych oraz pracy z różnymi systemami operacyjnymi i sprzętem, ilekroć systemy bezpieczeństwa oparte na kryptografii muszą być używane do ochrony wrażliwych, cennych danych. FIPS definiuje określone metody szyfrowania i określone metody generowania kluczy szyfrowania, których można użyć.

Zgodność z FIPS jest obowiązkowa dla komputerów rządowych w USA, co oznacza, że ​​wszystkie komputery używane do pracy rządowej muszą być zgodne z FIPS. Organizacje rządowe / federalne, spółki zależne i ich kontrahenci muszą zapewnić zgodność z FIPS, ponieważ mają do czynienia z informacjami chronionymi przepisami federalnymi. Twórcy aplikacji, którzy muszą przetestować swoje oprogramowanie na komputerach rządowych, muszą upewnić się, że przeprowadzają testy na komputerach zgodnych z FIPS. Wracając do wymagań, Horizon 7 nie wspiera aktualizacji z instalacji non-FIPS do instalacji FIPS. Jak wspomniałem wcześniej tryb FIPS nie jest obsługiwany w wersjach wcześniejszych niż 6.2. Jeśli włączymy tryb FIPS w systemie Windows i zaktualizujemy View Composer lub View Agent z wersji wcześniejszej niż 6.2 do 7.0, opcja trybu FIPS może zostać wyświetlona jako dostępna. Nie można jednak wybrać opcji trybu FIPS, ponieważ aktualizacja z trybu innego niż FIPS do trybu FIPS nie jest obsługiwana. Zamiast tego należy wykonać nową instalację, aby zainstalować Horizon 7 w trybie FIPS. No i jeszcze jedna rzecz, gdy posiadamy rożne wersje podczas aktualizacji np. 6.2.9 i 7.9 nie działają nam operacje na maszynach wirtualnych. Nie możemy wykonać provisioningu i recomposing linked-clone. Dlatego kolejność aktualizacji też jest ważna.

W zależności od ilości komponentów wykorzystywanych w naszym środowisku musimy wykonać odpowiednią ilość kroków. Standardowo jest to 14 kroków. Oczywiście jest to umowna liczba ponieważ ilość tych kroków będzie odpowiednio mniejsza lub większa w zależności od np. wersji vCenter i baz danych, czy View Composer jest na jednej maszynie z vCenter czy osobno itp.

W takim razie zaczynamy… ale! Przed krokiem 1 warto sprawdzić czy mamy dokumentację środowiska wraz z nazewnictwem, adresacją itp. Czasem bywa ona nieocenioną pomocą w tego typu aktualizacjach.

Krok 1. Aktualizacja Horizon Client na urządzeniach końcowych użytkownika. W tym wypadku musimy oczywiście sprawdzić kompatybilność z danym systemem operacyjnym. Teoretycznie bez aktualizacji też powinno działać. Aktualizacja jest jednak rekomendowana i obejmuje uruchomienie nowej wersji instalatora klienta Horizon bez uprzedniego usunięcia starszej wersji. Jeżeli posiadamy system Windows i klienta 4.6.0 lub starszy to w takim wypadku wymagane jest odinstalowanie go i instalacja nowej wersji. Oczywiście w tym wypadku wymagane są odpowiednie uprawnienia. Tego typu instalacje możemy wykonać również za pomocą polityk GPO.

Przykładowe znane błędy w przypadku Horizon Client 5.1 dla Windows:

Nie można wpisywać znaków akcentowanych w języku polskim, naciskając prawy klawisz Alt (AltGr) w trybie Continuum. Naciśnięcie prawego klawisza Alt w trybie Continuum jest rozpoznawane jako naciśnięcie lewego klawisza Alt i aktywacja menu.

Krok 2. Wykonanie kopii zapasowych i przygotowanie systemów do aktualizacji. Tutaj w pierwszej kolejności sprawdzamy wymagania sprzętowe nowych systemów. Sprawdzamy czy mamy zainstalowane patche dla ESXi i vCenter, które obsługują TLSv1.1 i TLSv1.2. Jeżeli takich patchy nie posiadamy, uruchamiamy TLSv1.0 na vCenter oraz ESXi na potrzeby połączeń z serwera View Composer. W przypadku gdy vCenter Server jest zainstalowany jako wirtualna maszyna wykonujemy jej snapshot. Ograniczamy ilość znaków w przypadku nazw hostów do mniejszej niż 15 znaków. Wykonujemy kopie zapasowe baz danych vCenter Serwer oraz View Composer. Sam mechanizm zależy w tym wypadku od użytej bazy danych. Sprawdzamy kompatybilność nowych wersji systemów z bazami danych. Warto aby już w tym momencie zrezygnować ze współdzielonej bazy danych przez vCenter i inne komponenty i użyć innej bazy danych na przechowywanie zdarzeń z Horizon 7 i View Composer. Kopiujemy katalog %ALLUSERSPROFILE%\Application Data\VMware\VMware VirtualCenter gdzie znajdują się certyfikaty. Dla wszystkich puli wyłączamy provisioning dla nowych maszyn wirtualnych oraz przestawiamy Delete or refresh machine on logoff na Never. W przypadku linked-clones zapobiega to występowaniu błędów gdy nowo zaktualizowany View Composer próbuje odświeżyć pulpit, na którym agent nie został jeszcze zaktualizowany. Na koniec musimy anulować wszelkie zadania wykonywane w trakcie aktualizacji.

Krok 3. Aktualizacja View Composer. Sama aktualizacja tego elementu po przygotowaniach trwa około 15 do 30min. Jak zwykle musimy posiadać odpowiednie uprawnienia aby wykonać aktualizacje. Musimy sprawdzić czy serwer posiada wszystkie niezbędne certyfikaty, jeżeli zostały one wygenerowane na potrzeby serwera. Po uruchomieniu samego instalatora przechodzimy krok po kroku przez kreator. W pewnym momencie możemy zostać zapytani o to czy schematy bazy danych mają zostać zaktualizowane. Możemy to również wykonać ręcznie po zakończeniu aktualizacji. Niejednokrotnie zdarza się, że pojawia się komunikat Database upgrade completed with warnings. Ten błąd należy do tych, które możemy bezpiecznie zignorować. Zdarza się jednak, że pojawiają się problemy z dostępnością desktopów. W takim wypadku zaglądamy do logu i sprawdzamy jakiego typu mamy problem.

Krok 4. Przygotowanie do aktualizacji Connection Server’ów. Przed przystąpieniem do tego kroku Wykonujemy snapshot maszyn wirtualnych, ponieważ zakładam, że każdy posiada dwa takie serwery. Jeżeli kiedykolwiek będzie potrzeba przywrócenia tego snapshotu  oraz jeżeli posiadamy inne instancje serwera w grupie replikacji musimy odinstalować tę instancję, zanim przywrócimy na serwerze master migawkę. Po przywróceniu ponownie instalujemy instancje, która będzie się replikować i wskazujemy instancję, która została cofnięta. Co ciekawe, VMware zaleca, aby otworzyć globalne ustawienie, ustawienia naszych wirtualnych desktopów oraz pulę i wykonać np. zrzut ekranu, jako dodatkowe zabezpieczenie konfiguracji. Przy okazji możemy wykonać kopię zapasową bazy LDAP za pomocą narzędzia vdmexport.exe.  Sama aktualizacja również jak w przypadku Composer’a trwa około 15 do 30 minut na każdą instancję. Musimy mieć również nowe klucze, ponieważ na pewno zostaniemy o nie zapytanie. W ramach takiej konfiguracji nie musimy zmieniać nic w aktualnie działających loda-balancerach, z doświadczenia wiemy, że warto przekierować aby wykorzystywane były te serwery, które aktualnie nie są aktualizowane.

Krok 5. Z poziomu administracyjnego na określonym serwerze ustawiamy, że będzie on wyłączony (Disable) i zatwierdzamy. Uruchamiamy instalator pobrany ze strony producenta i przechodzimy przez kreator instalacji. Sam kreator instalacji zatrzyma i uruchomi serwisy automatycznie, ale przed aktualizacją warto zrobić restart całej maszyny. Podczas aktualizacji usługa VMwareVDMDS musi być uruchomiona, aby zaktualizować bazę danych LDAP. Instalator po wykryciu, że istnieje starsza wersja przeprowadza aktualizację i wyświetla mniejszą liczbę opcji instalacji niż w przypadku nowej instalacji. Przed wykonaniem aktualizacji instalator sprawdza status replikacji, aby ustalić, czy serwer może komunikować się z innymi serwerami w replikowanej grupie i czy serwer może pobierać aktualizacje LDAP z innych serwerów w grupie. Jeśli sprawdzenie stanu nie powiedzie się, aktualizacja nie będzie kontynuowana. Po aktualizacji musimy zweryfikować certyfikat. Jeżeli z jakiegoś powodu status replikacji oznaczony jest na czerwono musimy sprawdzić czy aby na pewno cała wymagana komunikacja jest akceptowana na firewall’u, czy serwis VDMDS działa na Connection Serverze, czy nie ma problemów z połączeniem sieciowym. Pamiętajmy, że po uaktualnieniu instancji serwera połączeń do najnowszej wersji nie można obniżyć wersji tej instancji do wcześniejszej wersji. Po uaktualnieniu wszystkich instancji serwera połączeń w replikowanej grupie nie można dodać innej instancji, o niższej wersji.

Krok 6. Jeżeli wykorzystujemy Security Server’y, wykonujemy kopie zapasowe i zrzut konfiguracji ustawień systemowych. Jeżeli korzystamy z load-balancerów warto jak w przypadku Connection Server’ów zmienić ustawienia tak aby uniknąć przestojów.

Domyślnie komunikacja między serwerem bezpieczeństwa, a sparowaną instancją serwera połączeń jest regulowana regułami IPsec. Jeśli istniejące reguły IPsec nie zostaną usunięte przed aktualizacją lub ponowną instalacją, parowanie między serwerem bezpieczeństwa a serwerem połączeń nie powiedzie się, a po aktualizacji nie będzie można ustanowić nowego zestawu reguł IPsec.

Krok 7. Aktualizujemy w takim razie Security Server’y. Jeżeli wykonamy aktualizacje jeden pod drugim oraz sparowane z nimi Connection Server’y możemy osiągnąć zerowy przestój. Co jest bardzo oczekiwane przez wszystkich.

Krok 8. Jeden z najprostszych czyli aktualizacja polityk GPO w Active Direcotry. Pobieramy pliki i wrzucamy je w odpowiednie miejsce i koniec pracy.

Krok 9. Aktualizujemy komponenty środowiska wirtualnego tj. np. vCenter Server. Podczas aktualizacji serwera vCenter Server istniejące sesje pulpitu zdalnego i aplikacji nie zostaną rozłączone. Komputery zdalne będące w stanie provisioning nie zostaną włączone podczas aktualizacji serwera vCenter Server, nowe komputery stacjonarne nie mogą zostać uruchomione, a operacje View Composer nie są dozwolone podczas aktualizacji serwera vCenter Server.

Krok 10. Aktualizacja hostów ESXi oraz maszyn wirtualnych.  Uaktualnienie hostów i maszyn wirtualnych jest najbardziej czasochłonną fazą aktualizacji Horizon 7. Oczywiście wykorzystując vMorion minimalizujemy przestój maszyn do zera. Aktualizujemy w tym kroku przy okazji wirtualny hardware oraz VMware Tools’y.

Krok 11. Jeżeli wykorzystujemy Windows Terminal Services jako źródło naszych desktopów musimy zrobić aktualizację do Windowsa Server 2008 R2 lub nowszego oraz oczywiście musimy zweryfikować czy rola RDS Host jest zainstalowana. W tym kroku musimy się również upewnić czy serwery Horizon Connection Server są zaktualizowane. Musi to być wykonane w pierwszej kolejności. Wymagane jest to, aby mechanizm parowania JMS mógł współpracować z agentem Horizon.  

Krok 12. Aktualizujemy Horizon Agent lub View Agent, które są używane jako źródła pulpitu, jako pełne komputery klienckie w puli oraz jako pojedyncze komputery stacjonarne w puli ręcznej. Jeżeli posiadamy Windows 8 i chcemy go uaktualnić do wersji 8.1 musimy odinstalować agenta, wykonać aktualizacje systemu i ponownie zainstalować agenta dla tego systemu. Możemy również wykonać czystą instalację Windowsa 8.1 i instalacje agenta.  Dodatkowo instalator agenta Horizon zawiera teraz wszystkie składniki, które wcześniej były zawarte w programie Remote Experience Agent, który był częścią pakietu funkcji VMware Horizon View. Aby zaktualizować funkcje zainstalowane z programem Remote Experience Agent, wystarczy uruchomić instalator programu Horizon Agent. Ten instalator usuwa agenta Remote Experience przed wykonaniem aktualizacji.

Krok 13. Krok przedostatni czyli aktualizacja pul utworzonych w View Composer. Należy w tym wypadku starannie zaplanować okno serwisowe, tak aby odtworzenie i utworzenie pul nie dobiło się  czkawką na macierzy dyskowej lub hostach ESXi.

Krok 14. Krok ostatni to aktualizacja Cloud Pod Architecture. O ile z takiej funkcjonalności korzystamy. Funkcja Cloud Pod Architecture wykorzystuje standardowe komponenty Horizon 7 w celu zapewnienia administracji między centrami danych. Dzięki funkcji Cloud Pod Architecture łączysz ze sobą wiele modułów, aby stworzyć jedno duże środowisko do zarządzania pulpitem i aplikacjami. Moduł składa się z serwera baz danych, Connection Server, storage współdzielonego, środowiska vSphere oraz infrastruktury sieciowej wymaganej do hostowania puli desktopów i aplikacji. Aby wykonać aktualizacje Cloud Pod Architecture należy wykonać aktualizację wszystkich instancji Connection Server w pojedynczym module (pod) według standardowej procedury. Krok powtarzamy do momentu aż każdy serwer nie zostanie zaktualizowany we wszystkich modułach (podach).

Na koniec samej aktualizacji należy pamiętać o tym iż usunięto funkcję VMware View Client z trybem lokalnym do korzystania z komputerów offline. Zamiast funkcji Tryb lokalny, VMware zaleca używanie VMware Mirage, który jest zawarty w VMware Horizon 6.0 i późniejszych wersjach.

Aktualizacja się udała i wszystko działa poprawnie, oczywiście to najbardziej optymistyczny scenariusz. Ale gdy pojawią się problemy czy możemy sami sobie poradzić z ich rozwiązaniem? Odpowiedź brzmi: to zależy. Niektóre problemy nie pojawią się gdy zadbamy o to odpowiednio wcześnie np. pamiętając o tym, że na serwerze View Composer 7.2 lub nowszym musimy mieć zainstalowanego .Net framework 4.6.1. W innym przypadku instalacja się nie powiedzie. Kolejną rzeczą jest zadbanie o kompatybilność VMware Tools’ów. Niekompatybilność lub stara wersja może powodować problemy z redukcją wielkości dysków maszyn. Komunikaty o błędach wyglądają tak: “Failed to perform space reclamation on machine COMPUTER NAME in Pool POOL NAME” lub “A general system error occurred: Wipe Disk failed: Failed to complete wipe operation.” Oczywiście sprawa dotyczy starych maszyn, jeżeli wykonamy odświeżenie lub „recompose” problem powinien ustąpić, ale nie zawsze możemy wykonać ten zabieg. Dodatkowo jak wspomniałem powrót do starszej wersji Horizon jest możliwy tylko poprzez przywrócenie kopii zapasowej LDAP’a, ponieważ klucze użyte do ochrony danych LDAP uległy zmianie w nowszych wersjach. Ciekawą zmianą jest też „TLS handshakes” na porcie 443. Począwszy od wersji 7.2.2 operacja ta musi zakończyć się w ciągu 10 sekund lub 100 sekund jeżeli korzystamy z uwierzytelnienia za pomocą karty inteligentnej. W poprzednich wersjach Horizon 7 trwało to zawsze 100 sekund. Opcjonalnie klient, który jest odpowiedzialny za przekroczenie limitu uzgadniania TLS, może zostać automatycznie dodany do czarnej listy. Nowe połączenia od klientów z czarnej listy są opóźnione o konfigurowalny okres przed przetworzeniem, tak aby połączenia od innych klientów miały priorytet.

Czasami gdy tworzymy pełne klony lub linked klony, z użyciem modyfikacji Sysprep zdarza się, że na systemie Windows 10 pojawiają się problemy z dodaniem do domeny. W tym wypadku z pomocą przychodzi Microsoft ze swoim KB (https://support.microsoft.com/en-us/help/2769827), który powinien rozwiązać problem.

Jak widzimy sama aktualizacja nie jest skomplikowana, niestety jednak należy pamiętać o podstawowych sprawach jak sprawdzenie kompatybilności produktów, sprawdzenie kolejności samej aktualizacji elementów środowiska nie tylko odpowiedzialnego za bezpośrednie zarządzanie stacjami roboczymi, ale również pokrewne jak vCenter Server, ESXi lub nawet same bazy danych, z których korzystają te rozwiązania. Pamiętajmy, że wszystkiego nie możemy przewidzieć, ale możemy się maksymalnie dobrze do wszelkich problemów przygotować. Dlatego zachęcam Was, aby przed rozpoczęciem prac przeczytać „znane problemy”, bo może coś tam się znaleźć co dotyczy właśnie waszej infrastruktury. Nie śpieszmy się również z wrzuceniem najnowszej wersji na produkcje, może to skończyć się nie zbyt dobrze dla ciągłości działania środowiska. Tak czy inaczej przy każdej aktualizacji niech moc będzie z Wami.