Piszki Lab

Analiza przypadku w języku przodków…

Horizon Workspace: BIG-IP F5 i wiele instancji connector-va.

| 0 comments

W tym wpisie opiszę dalszą konfigurację Horizon Workspace 1.8.1 i BIG-IP F5. Przeszliśmy już etap balansowania ruchem do zduplikowanych maszyn gateway-va, teraz zajmiemy się powieleniem maszyn connector-va. Oprócz balansowania ruchem, skonfigurujemy wszystko tak, aby możliwa była autentykacja typu “Windows” z ustawioną opcją “Enable redirect” przy dostępie z Internetu. Dzięki temu, komputer który znajduje się z dala od domeny AD, może nadal wykorzystać autentykację Kerberos przy dostępie do aplikacji typu ThinApp (dostępnych bezpośrednio z portalu Workspace).

conn1

Na podstawie diagramu łatwo jest się domyśleć, że wirtualny adres connector-va musi być w pełni dostępny z Internetu i w lokalnej sieci (skonfigurowany NAT). Musi mieć też skonfigurowany poprawny FQDN (prawidłowy PTR w DNS lokalnym i internetowym) i zaimportowany poprawny certyfikat SSL (dlatego przy Horizon Workspace najlepszym rozwiązaniem jest certyfikat typu wildcard). Certyfikat maszyny connector-va jest generowany każdorazowo za pomocą skryptu wizardssl.hzn, w F5 użyjemy tego samego profilu SSL który stworzyliśmy dla adresu workspace.pulab.pl.

Konfigurację całości rozpoczynamy od przygotowania lokalnego rekordu DNS dla nowej maszyny connector-va. Następnie logujemy się do maszyny configurator-va i wydajemy polecenie:

ughocf1:~ # hznAdminTool addvm –type=CONNECTOR –ip=172.18.30.59 –useGatewayAsIDP=n –directoryPassword=xxx –activateOnly=n –maintenanceMode=n

conn4

Zgodnie z zasadą, że każda nowa maszyna w Horizon Workspace jest klonem ostatnio wygenerowanej (dotyczy to service-va lub gateway-va) lub klonem migawki powstałej w trakcie instalacji (dotyczy to connector-va i data-va (template)), przed generacją kolejnej, zawsze poprawnie należy skonfigurować poprzednią. W tym celu logujemy się do nowej instancji connector-va (https://ughocn2.pulab.local:8443/hc/admin), konfigurujemy podłączenie do domeny AD i wykonujemy wszystkie kroki z “Setup Wizard”. Z jednym wyjątkiem, poza pierwszą instancją, wszystkie kolejne muszą mieć wyłączoną opcję Directory Sync.

conn3

Opcja ta jest wykorzystywana wtedy, gdy używamy wielu domen AD (multiforest). Jeśli chcemy z niej skorzystać, i nowy connector-va został dodany do innej domeny niż pierwotny, to przed wykonaniem pierwszej synchronizacji, należy w panelu administracyjnym Horizon Workspace w sekcji Setting—>User Stores, dodać nowy magazyn użytkowników. Jeśli tego nie zrobimy, lub jeśli nie wyłączymy opcji “Directory Sync” przy jednej domenie AD, próba synchronizacji użytkowników zakończy się komunikatem “Sync actions cannot be calculated at this time. Please try again later (User store not found for sync client)”.

conn5

Na tym etapie to wszystko jeśli chodzi o konfigurowanie connectora-va, w kolejnym kroku należy przygotować zewnętrzny rekord DNS dla wirtualnego adresu F5 (connector.pulab.pl) i prawidłowo skonfigurować lokalny NAT tego adresu. Gdy to już zostanie zrobione, możemy przejść do konfigurowania BIG-IP F5. Zaczynamy od dodania nodów i przygotowania puli:

conn6

Wbrew temu co można znaleźć w Internecie, F5 Monitor https_head_f5 nie nadaje się do monitorowania ani gateway-va ani connector-va. Mimo, że w F5 wszystko świeci się na “zielono” to w logach maszyn odkłada się bardzo dużo wpisów o nie wspieranej metodzie dostępu do strony. Jeśli nikomu to nie przeszkadza to można to zostawić, ale bezpieczniej jest użyć monitora icmp_gateway.

conn7

Balansowanie ruchem ustawiamy standardowo, priorytet najmniej obciążonego członka puli.

conn8

Na końcu tworzymy wirtualny serwer. Robimy to tak samo jak robiliśmy w przypadku gateway-va. Absolutnie nie są do tego potrzebne kroki opisane tutaj (establish ssl trust), my załatwiamy to profilem SSL.

conn9

W przypadku tego wirtualnego serwera użyjemy tego samego profilu “persistence” jak w przypadku gateway-va.

conn10

Jest to tak zwana “sticky session”, zgodnie z dokumentacją Horizon Workspace, czas wygasania sesji SSL na load balancerze musi być większy od 30 minut.

conn11

W tym momencie konfiguracja F5 jest zakończona, mamy prawidłowo skonfigurowany wirtualny serwer z podłączonymi dwoma connector-va.

conn12

Do zrobienia pozostały ostatnie dwa kroki, logujemy się po kolei do wygenerowanych maszyny i w sekcji “Identity Provider” zmieniamy nazwę “IdP Hostname” na zgodną z naszym rekordem FQDN (connector.pulab.pl). Dzięki temu, że używamy profilu SSL na F5 nie musimy nic zmieniać w sekcji “SSL Certificate” (czyli lokalnie mamy SSL zgodny z lokalnym CA a zdalnie certyfikat wildcard!) .

conn13

Logujemy się teraz do panelu administracyjnego i w sekcji “Settings—>Identity Providers” zmieniamy kolejność tak, aby jako pierwsze na liście były maszyny z naszej puli F5.

conn14

Jak widać na rysunku, Application Manager wykrył zmianę adresu “IdP Hostname” na prawidłową, zgodną z naszymi wymaganiami. I to wszystko. Jeśli macie wrażenie, że cała instalacja Horizon Workspace działa niestabilnie, to dobrze jest po takich modyfikacjach w środowisku, zrestartować całego vApp. W naszym labie ta konfiguracja działa bez najmniejszego problemu.

Na koniec jeszcze jedna uwaga, pamiętajmy aby konto komputera w domenie AD, każdego nowo wygenerowanego connector-va, dodać do uprawnień katalogu z którego są udostępniane aplikacje ThinApp! To, że “Setup Wizard” kończy się prawidłowo, w tym z synchronizacją aplikacji ThinApp, nie oznacza że wszystko jest ok. Jeśli nie dodamy kont komputera do katalogu, żaden błąd się nie wyświetli ale aplikacje się nie zsynchronizują. Tym bardziej się nie skopiują lokalnie przy włączonej opcji “Enable account based access” i Agenci zainstalowani z opcją HTTP_DOWNLOAD nie będą mogli pobrać aplikacji.

horr1

English

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ę! :-)

.