Piszki Lab

Analiza przypadku w języku przodków…

vCloud Director 5.5: balansowanie ruchem za pomocą BIG-IP F5

| 0 comments

Ten temat był poruszany w Internecie wielokrotnie, ale zawsze warto przypomnieć i odświeżyć wiedzę. Szczególnie, że nowe wersje oprogramowania pojawiają się co chwila, często różniąc się od siebie dość mocno. Poza tym, to że VMware ostatnio traktuje vCloud Director z lekką niechęcią, nie oznacza, że wszyscy nagle przenieśli się na vCAC. Dodatkowo skupię tutaj się dość mocno na balansowaniu ruchem przy dostępie do wirtualnych maszyn poprzez Console Proxy (vmrc). Na ten temat trudno jest znaleźć wyczerpujące informacje.

vcd16

W pierwszym kroku, jeśli jeszcze tego nie mamy, musimy wygenerować kolejnego noda (Cell) vCloud Director. Wszystkie nody muszą współdzielić, poprzez NFS, katalog “transfer” (/opt/vmware/vcloud-director/data/transfer), dlatego należy się zastanowić skąd go zamontujemy. Może to być zewnętrzny serwer NAS lub katalog wyeksportowany z pierwszego noda (tak jest w moim przypadku). Osobiście używam systemu CentOS 6.4 jako nośnika dla vCloud Director (zamiast Red Hat), ułatwia to dość mocno administrację. Przygotowanie kolejnego noda jest bardzo proste, wystarczy sklonować pierwszego! Oczywiście za pierwszym razem uruchamiamy go w trybie izolacji sieciowej, wyłączamy na nim vCD (service vmware-vcd stop), rekonfigurujemy karty sieciowe na nowe adresy IP i podnosimy interfejsy. Na pierwszym nodzie (nasz CentOS), jeśli jeszcze nie mamy, instalujemy i uruchamiamy serwer NFS:

yum install nfs-utils nfs-utils-lib
chkconfig nfs on
service rpcbind start
service nfs start

Do pliku /etc/exports dopisujemy linię:

/opt/vmware/vcloud-director/data/transfer       172.18.60.128 (rw,sync,no_root_squash,no_subtree_check)

I wydajemy polecenie: exportfs –a

W tym momencie mamy wyeksportowany po NFS katalog “transfer”. Kopiujemy do niego plik /opt/vmware/vcloud-director/etc/responses.properties (zawiera on podstawową konfigurację która zostanie użyta przez kolejnego noda). Teraz przechodzimy do przygotowania certyfikatów SSL dla obydwu nodów. Jest to bardzo ważny krok i musi być wykonany poprawnie. Dlaczego modyfikacje musimy wprowadzić na obydwu nodach? Ponieważ zgodnie z tym KB, jeśli chcemy balansować ruchem w połączeniach VMRC, to wszystkie nody powinny mieć wspólny certyfikat SSL dla Console Proxy. Nazwa hosta w certyfikacie musi być zgodna z wpisem VCD public console proxy:

vcd1

W innym wypadku możemy spotkać się z błędem “Exception during handshake: javax.net.ssl.SSLException: Received fatal alert: certificate_unknown”. Jak zawsze najlepszym rozwiązaniem jest posiadanie certyfikatu typu Wildcard (w formacie pkcs12). Spreparowanie pliku certificates.ks na podstawie pkcs12 (pfx) jest bardzo proste:

Przygotowanie pustego keystore typu JCEKS:

keytool -keystore certificates.ks -storetype JCEKS -storepass xxxxxxx -genkey -keyalg RSA -keysize 2048 -alias http

keytool -delete -alias http -keystore certificates.ks

Importujemy certyfikaty CA i Intermediate (tyle ile trzeba, nazwy aliasów mogą być np. intermediate1, intermediate2 etc):

keytool -storetype JCEKS -storepass xxxxxxx -keystore certificates.ks –importcert –file ca1 –alias root

keytool -storetype JCEKS -storepass xxxxxxx -keystore certificates.ks -importcert -file ca2 -alias intermediate

Importujemy certyfikat wildcard razem z kluczem:

keytool -v -importkeystore -srckeystore pulab.pfx -srcstoretype PKCS12 -destkeystore certificates.ks -deststoretype JCEKS -alias http

keytool -v -importkeystore -srckeystore pulab.pfx -srcstoretype PKCS12 -destkeystore certificates.ks -deststoretype JCEKS –alias consoleproxy

I to wszystko, po kolei, na obydwu nodach wyłączamy usługę vCloud Director (service vmware-vcd stop), usuwamy stary plik keystore i uruchamiamy /opt/vmware/vcloud-director/bin/configure. Program sam wykryje zmianę pliku certificates.ks i zaproponuje jego zaimportowanie do konfiguracji. Po uruchomieniu obydwu nodów (w tym nowego) powinniśmy zobaczyć następujący rezultat:

vcd2

W tym momencie możemy przejść do konsoli F5. Przygotowanie odpowiedniej konfiguracji zaczniemy od stworzenia właściwych monitorów, jeden dla vCloud Director a drugi dla Console Proxy:

vcd3

vcd4

W kolejnym kroku tworzymy profil utrzymania sesji (Persistence) dla vCD, Console Proxy nie potrzebuje takiego profilu:

vcd5

Teraz tworzymy profil SSL dla vCD, w naszym wypadku użyjemy jak zwykle tego samego profilu Wildcard:

vcd6

Dodajemy kolejne Nody (na tym etapie wystarczającym monitorem jest ICMP):

vcd7

Tworzymy pierwszą pulę dla vCloud Director:

vcd8

vcd9

Tworzymy drugą pulę dla Console Proxy:

vcd10

vcd11

Na tym etapie mamy wszystko, co jest potrzebne do stworzenia Virtualnych Serwerów. Jako pierwszy tworzymy VIP dla vCloud Director:

vcd12

vcd13

Jest to standardowy zestaw dla serwera WWW, użycie profilu http pozwala na użycie polityki bezpieczeństwa (ASM) w dostępie do vCloud Director. Użycie profilu SSL nie jest obligatoryjne, możemy wykonać też pełne przekazanie sesji do nodów (jeśli mamy ten sam certyfikat dla wszystkich nodów). Jeśli nie używamy synchronizacji katalogów pomiędzy różnymi chmurami to możemy mieć dla każdego noda (Cell) wygenerowany oddzielny certyfikat SSL podpisany przez lokalne CA (dotyczy tylko dostępu przez WWW). W ostatnim kroku tworzymy VIP dla Console Proxy:

vcd14

vcd15

W tym przypadku nie używamy profilu http, Console Proxy nie jest zwykłą usługą HTTPS. W związku z tym nie możemy też użyć ASM dla niej!

EDIT:

Wpis dostał 5 gwiazdek, znaczy się, ktoś go przeczytał, w związku z tym, uzupełnię go :-)

SSL w vCloud Director to delikatny temat, przy balansowaniu jest wiele zmiennych, opis powyżej doprowadzi niestety do tego, że przestanie poprawnie działać zintegrowana autentykacja SSO z vSphere. Rozwiązanie jest takie: każdy node powinien mieć własny, lokalny certyfikat (niezależnie od SSL-offload na F5), ale nie dotyczy to consoleproxy, na każdym node powinien być ten sam wildcard.

P.S. Piszcie o własnych doświadczeniach z vCloud Director! :-)

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

Dodaj komentarz

Required fields are marked *.


.

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

.