Piszki Lab

Analiza przypadku w języku przodków…

Horizon Workspace Portal 2.1 – balansowanie ruchem za pomocą BIG-IP F5

| 0 comments

20Minęło sporo czasu od premiery Horizon Workspace 2.1, najwyższy czas zmierzyć się z upgrade 2.0 do 2.1. Nie będę ukrywał, że pierwszy raz wyjście nowej wersji jakiegoś produktu wywołało u mnie objawy podobne do szoku. Horizon Workspace jest bardzo skomplikowanym produktem, jego opanowanie wymaga ogromnej porcji czasu, to samo dotyczy implementacji. Proces absorpcji nowej technologii musi trwać. A tutaj z wersji na wersję zmiany są coraz większe. W trakcie migracji z 1.8 do 2.0 straciliśmy system zarządzania plikami, a z wersji 2.0 do 2.1 nastąpiło całkowite przemodelowanie środowiska. Jedyna ścieżka migracji to postawienie nowej instalacji 2.1 i migracja ustawień z 2.0! A więc tak naprawdę wszystko zaczynamy od początku! Ja ostatecznie uznałem, że nie będę wykonywał migracji ustawień tylko postawię nową wersję 2.1 i skonfiguruję wszystko od początku (wcześniejsze upgrade wywoływały sporo problemów). Zmiany wewnątrz Horizon Workspace nie są w końcu tak duże i da się to zrobić w miarę rozsądnym czasie. Na końcu po prostu podmienię adres IP Workspace FQDN ze starej instalacji na nową (wszystkie klienty desktopowe podłączą się do nowej wersji). Jako wstęp do tego postu proszę przeczytać wcześniejsze dwa o balansowaniu ruchem do gateway-va i connector-va w wersji 2.0.

ughp6

Autorem obrazka jest Peter Bjork.

Instalacja i wstępna konfiguracja Horizon Workspace Portal 2.1 nie odbiega mocno od wcześniejszych wersji i nie będzie tematem tego wpisu. Zanim przystąpicie do konfiguracji balansowania ruchem, postarajcie się jak najwięcej skonfigurować w samej maszynie  (np. proxy, pliki klientów desktopowych, ewentualny upgrade dla bash shellshock). Na tym etapie powinniśmy też zrobić konfigurację dostępową do portalu, czyli ustawić Workspace FQDN:

ughp5

Jeśli ten adres jest adresem internetowym, rozgłaszanym lokalnie poprzez NAT to na tym etapie musimy też skonfigurować naszą F5 (przechodzicie do odpowiedniej części tego postu). Jeśli jest to adres wewnętrzny (lub w naszym DNS mamy “fałszywą” zonę zewnętrzną) to wystarczy, że przygotujemy odpowiedni rekord A/PTR w naszym DNS i ustawimy Workspace FQDN (i czytamy dalej). Samo wygenerowanie kolejnych instancji odbiega od tego co było do tej pory, robimy po prostu klona nowej maszyny. Od razu nasuwa się pytanie, co w przypadku gdy ktoś używa wewnętrznej bazy danych? Taka konfiguracja jest wspierana, kolejne nody vPostgres pełnią funkcję SLAVE. Ja jednak od zawsze używam zewnętrznej bazy danych. Zaczynamy, na początek wykonujemy klona pierwszej maszyny Horizon Workspace Portal 2.1:

ugho1

Bardzo ważne jest, aby w trakcie tej operacji, w zakładce “vApp properties”, podać parametry nowej maszyny, a więc nowy adres IP i nową nazwę FQDN (nie zapomnijcie zrobić rekordu w serwerze DNS). Uruchamiamy sklonowaną maszynę i spokojnie czekamy, pamiętajmy tylko o jednym, jeśli zmienialiśmy strefę czasową na jednym nodzie, sprawdźmy czy jest taka sama na drugim (musza być spójne). Pamiętajmy też, że tak sklonowana maszyne jest jednocześnie nową instancją connectora (kiedyś connector-va) i wymaga osobnego skonfigurowania (przede wszystkim dodania do domeny AD):

ughp2

ughp3

Po dodaniu do domeny AD i wpisaniu hasła w sekcji “Directory” wszystko wraca do normy (reszta ustawień jest pobierana z pierwszego noda).

ughp4

Bardzo dużo zmian nastąpiło w sekcji “Identity Providers”, należy pamiętać, że wszystkie klony pierwszej maszyny będą miały ID=1, domyślnie jest włączona tylko autentykacja hasłem. Możemy włączyć autentykację typu Kerberos na głównych klonach ale wtedy w “Network Ranges” będziemy musieli używać ALL RANGES (dla obydwu typów autentykacji). Przy prawidłowo ustawionej sekwencji autentykacji będzie to działać OK. Jeśli jednak mamy dużo klientów działających poza domeną AD (lub wiele domen AD), lepiej jest wygenerować osobne instancje coonector-va i po staremu posłużyć się zakresami sieci (w takim przypadku obowiązuje ta sama konfiguracja F5 co kiedyś). Taką maszynę instalujemy zaznaczając opcję “connector only” w trakcie wgrywania pliku OVA Horizon Workspace Portal.

Przechodzimy do konfigurowania F5, posłużymy się tymi samymi komponentami co przy poprzedniej konfiguracji. Na początek profil HTTP w włączonym X-Forwarded-For:

ughp7

Teraz tworzymy profil persistence (wydłużamy czas oczekiwania sesji SSL):

ughp8

Tworzymy pulę, monitor to https_head_f5:

ughp9

ughp10

Na koniec tworzymy wirtualny serwer (Source Adress Translation = Auto Map, jak widać, używamy profilu SSL PULAB (nasz wildcard) dla klientów, połączenie do nodów jest szyfrowane ponownie:

ughp11

Podłączamy naszą pulę nodów, profile i politykę bezpieczeństwa (dokładnie tę samą z poprzedniej instalacji):

ughp12

I to wszystko, oczywiście przy większych instalacjach możemy włączyć wszystkie profile optymalizujące ruch sieciowy. Nowa metoda generowania kolejnych maszyn poprzez tworzenie klonów faktycznie upraszcza cały proces, każdy kolejny klon niesie wszystkie w sobie wszystkie usługi. W starej metodzie każdą usługę, np. service-va należało balansować osobno.

ughp13

Oceń ten artykuł:
[Głosów:0    Średnia:0/5]

Dodaj komentarz

Required fields are marked *.


.

Podobał się wpis? Wesprzyj Piszki Lab, kliknij w reklamę! :-)

.