Ostatnim razem rozmawialiśmy o możliwościach NSX Edge w kontekście routingu statycznego i dynamicznego, a dzisiaj zajmiemy się load balancerem.
Zanim przejdziemy do konfiguracji, chciałbym krótko przypomnieć o podstawowych rodzajach load balancingu.
Teoria
Wszystkie dzisiejsze rozwiązania do load balancingu najczęściej dzieli się na dwie kategorie: load balancing na czwartym (transportowym) i siódmym (aplikacyjnym) poziomie modelu . Model OSI nie jest najlepszym punktem odniesienia do opisywania metod load balancingu. Przykładowo, jeśli load balancer L4 obsługuje również terminację TLS, czy to czyni go load balancerem L7? Ale cóż, tak jest.
- Load balancer L4 najczęściej działa jako pośrednik między klientem a zestawem dostępnych backendów, który terminować połączenia TCP (tj. osobiście odpowiada na SYN), wybiera backend i inicjuje nowe połączenie TCP w kierunku tego backendu, samodzielnie wysyłając SYN. Ten typ to jeden z podstawowych, możliwe są również inne warianty.
- Load balancer L7 rozdziela ruch do dostępnych backendów w „subtelniejszy” sposób niż load balancer L4. Może podejmować decyzje o wyborze backendu na podstawie, na przykład, zawartości wiadomości HTTP (adres URL, plik cookie itp.).
Niezależnie od typu, load balancer może wspierać następujące funkcje:
- Odkrywanie usług – proces określania zestawu dostępnych backendów (Static, DNS, Consul, Etcd itp.).
- Sprawdzanie dostępności odkrytych backendów (aktywny „ping” backendu przy użyciu zapytania HTTP, pasywne wykrywanie problemów w połączeniach TCP, występowanie kilku pod rząd kodów 503 HTTP w odpowiedziach itp.).
- Sam load balancing (round robin, losowy wybór, hasz IP źródłowego, URI).
- Terminacja TLS i weryfikacja certyfikatów.
- Opcje związane z zapewnieniem bezpieczeństwa (uwierzytelnianie, zapobieganie atakom DoS, ograniczenie prędkości) i wiele innych.
NSX Edge oferuje wsparcie dla dwóch trybów wdrożenia load balancera:
Tryb proxy, czyli one-arm. W trybie tym NSX Edge przy wysyłaniu żądania do jednego z backendów używa swojego adresu IP jako adresu źródłowego. W ten sposób load balancer pełni jednocześnie funkcje Source i Destination NAT. Backend widzi cały ruch jako wysłany z load balancera i odpowiada mu bezpośrednio. W takim schemacie load balancer musi znajdować się w tej samej sieci co serwery wewnętrzne.
Oto jak to działa:
1. Użytkownik wysyła żądanie na adres VIP (adres load balancera), który jest skonfigurowany na Edge.
2. Edge wybiera jeden z backendów i wykonuje destination NAT, zastępując adres VIP adresem wybranego backendu.
3. Edge wykonuje source NAT, zamieniając adres wysyłającego żądanie użytkownika na swój własny.
4. Pakiet jest wysyłany do wybranego backendu.
5. Backend odpowiada nie bezpośrednio użytkownikowi, a Edge, ponieważ pierwotny adres użytkownika został zmieniony na adres load balancera.
6. Edge przekazuje odpowiedź serwera użytkownikowi.
Schemat poniżej.
Tryb przezroczysty, czyli inline. W tym scenariuszu load balancer ma interfejsy w sieci wewnętrznej i zewnętrznej. Przy tym nie ma bezpośredniego dostępu do sieci wewnętrznej z zewnątrz. Wbudowany load balancer działa jak brama NAT dla maszyn wirtualnych w sieci wewnętrznej.
Mechanizm jest następujący:
1. Użytkownik wysyła żądanie na adres VIP (adres load balancera), który jest skonfigurowany na Edge.
2. Edge wybiera jeden z backendów i wykonuje destination NAT, zastępując adres VIP adresem wybranego backendu.
3. Pakiet jest wysyłany do wybranego backendu.
4. Backend otrzymuje żądanie z pierwotnym adresem użytkownika (source NAT nie został wykonany) i odpowiada bezpośrednio.
5. Ruch znowu jest przechwytywany przez load balancer, ponieważ w trybie inline zazwyczaj działa jako domyślna brama dla farmy serwerów.
6. Edge wykonuje source NAT w celu wysłania ruchu do użytkownika, używając swojego VIP jako adresu source IP.
Schemat poniżej.
Praktyka
Na moim teście skonfigurowano 3 serwery z Apache, który jest skonfigurowany do pracy przez HTTPS. Edge będzie wykonywać load balancing zapytań HTTPS metodą round robin, proxy każdą nowe zapytanie do nowego serwera.
Zaczynamy.
Generujemy certyfikat SSL, który będzie używany przez NSX Edge.
Możesz zaimportować ważny certyfikat CA lub użyć certyfikatu samopodpisanego. W tym teście skorzystam z certyfikatu samopodpisanego.
- W interfejsie vCloud Director przechodzimy do ustawień usług Edge.
- Przechodzimy do zakładki Certyfikaty. Z listy działań wybieramy dodanie nowego CSR.
- Wypełniamy wymagane pola i klikamy Keep.
- Zaznaczamy właśnie utworzony CSR i wybieramy opcję self-sign CSR.
- Wybieramy okres ważności certyfikatu i klikamy Keep.
- Certyfikat samopodpisany pojawił się na liście dostępnych.
Konfigurujemy profil aplikacji.
Profile aplikacji dają pełniejszą kontrolę nad ruchem sieciowym, czyniąc zarządzanie nim proste i efektywne. Dzięki nim można określić zachowanie dla konkretnych typów ruchu.
- Przechodzimy do zakładki Load Balancer i włączamy balansowanie obciążenia. Opcja Acceleration enabled pozwala tutaj na użycie szybszego balansowania L4 zamiast L7.
- Przechodzimy do zakładki Application profile, aby ustawić profil aplikacji. Kliknij +.
- Nadajemy nazwę profilu i wybieramy typ ruchu, dla którego profil będzie zastosowany. Wyjaśnię niektóre parametry.
Persistence – zachowuje i śledzi dane sesji, na przykład: który konkretny serwer z puli obsługuje żądanie użytkownika. Pozwala to zapewnić, że żądania użytkownika są kierowane do tego samego członka puli przez cały czas trwania sesji lub kolejnych sesji.
Włącz SSL passthrough – wybierając tę opcję, NSX Edge przestaje terminować SSL. Zamiast tego, terminacja następuje bezpośrednio na serwerach, dla których wykonywane jest balansowanie.
Wstaw nagłówek HTTP X-Forwarded-For – pozwala określić oryginalny adres IP klienta łączącego się z serwerem WWW poprzez balansownik.
Włącz SSL po stronie puli – pozwala określić, że wybrana pula składa się z serwerów HTTPS.
- Ponieważ będę balansować ruch HTTPS, muszę włączyć SSL po stronie puli i wybrać wcześniej wygenerowany certyfikat w zakładce Virtual Server Certificates —> Service Certificate.
- Podobnie dla Pool Certificates —> Service Certificate.
Tworzymy pulę serwerów, której ruch będzie balansowany.
- Przechodzimy do zakładki Pools. Klikamy +.
- Nadajemy nazwę puli, wybieramy algorytm (będę używał round robin) i typ monitorowania dla health check backendu. Opcja Transparent wskazuje, czy pierwotne adresy IP klientów są widoczne dla wewnętrznych serwerów.
- Jeśli opcja jest wyłączona, ruch dla serwerów wewnętrznych pochodzi z adresu IP balansownika.
- Jeśli opcja jest włączona, wewnętrzne serwery widzą adresy IP klientów. W takiej konfiguracji NSX Edge powinien działać jako brama domyślna, aby zapewnić, że zwracane pakiety przechodzą przez NSX Edge.
NSX obsługuje następujące algorytmy równoważenia obciążenia:
- IP_HASH – wybór serwera na podstawie wyników funkcji haszującej dla źródłowego i docelowego adresu IP każdego pakietu.
- LEASTCONN – równoważenie przychodzących połączeń w zależności od liczby już istniejących na danym serwerze. Nowe połączenia będą kierowane do serwera z najmniejszą liczbą połączeń.
- ROUND_ROBIN – nowe połączenia są wysyłane do każdego serwera na przemian, zgodnie z przypisanym mu ciężarem.
- URI – lewa część URI (przed znakiem zapytania) jest haszowana i dzielona przez łączny ciężar serwerów w puli. Wynik wskazuje, który serwer otrzymuje żądanie, gwarantując, że żądanie zawsze kierowane jest do tego samego serwera, dopóki wszystkie serwery pozostają dostępne.
- HTTPHEADER – równoważenie na podstawie określonego nagłówka HTTP, który można wskazać jako parametr. Jeśli nagłówek jest nieobecny lub nie ma żadnej wartości, stosowany jest algorytm ROUND_ROBIN.
- URL – w każdym żądaniu HTTP GET wyszukiwany jest parametr URL wskazany jako argument. Jeśli za parametrem znajduje się znak równości i wartość, to wartość jest haszowana i dzielona przez łączny ciężar aktywnych serwerów. Wynik wskazuje, który serwer otrzymuje żądanie. Proces ten jest używany do śledzenia identyfikatorów użytkowników w żądaniach i zapewnienia, że ten sam identyfikator użytkownika zawsze jest wysyłany do tego samego serwera, dopóki wszystkie serwery pozostają dostępne.
- W sekcji Members klikamy +, aby dodać serwery do puli.
Tutaj należy podać:- nazwę serwera;
- adres IP serwera;
- port, na który serwer będzie odbierał ruch;
- port do sprawdzania stanu (Monitor healthcheck);
- ciężar (Weight) – za pomocą tego parametru można regulować proporcjonalną ilość otrzymywanego ruchu dla konkretnego członka puli;
- Max Connections – maksymalna liczba połączeń z serwerem;
- Min Connections – minimalna liczba połączeń, które serwer musi obsłużyć, zanim ruch zostanie przekierowany do następnego członka puli.
Tak wygląda ostateczna pula składająca się z trzech serwerów.
Dodajemy Virtual Server
- Przechodzimy do zakładki Virtual Servers. Klikamy +.
- Aktywujemy serwer wirtualny za pomocą Enable Virtual Server.
Nadajemy mu nazwę, wybieramy wcześniej utworzony profil aplikacji, pulę i podajemy adres IP, na który serwer wirtualny będzie przyjmował żądania z zewnątrz. Podajemy protokół HTTPS i port 443.
Opcjonalne parametry tutaj:
Limit połączeń – maksymalna liczba jednoczesnych połączeń, które może obsłużyć serwer wirtualny;
Limit połączeń (CPS) – maksymalna liczba nowych przychodzących żądań na sekundę.
Na tym konfiguracja balansu obciążenia jest zakończona, można sprawdzić jej działanie. Serwery mają najprostszą konfigurację, która pozwala zrozumieć, który z serwerów w puli obsłużył żądanie. Podczas konfiguracji wybraliśmy algorytm balansu Round Robin, a parametr Weight dla każdego serwera wynosi jeden, dlatego każde kolejne żądanie będzie obsługiwane przez następny serwer w puli.
Wprowadzamy w przeglądarkę zewnętrzny adres balansu obciążenia i widzimy:
Po odświeżeniu strony żądanie zostanie obsłużone przez następny serwer:
I jeszcze raz – aby sprawdzić również trzeci serwer w puli:
Podczas sprawdzania można zobaczyć, że certyfikat, który przesyła nam Edge, jest tym, który generowaliśmy na samym początku.
Sprawdzenie statusu balansu obciążenia z konsoli Edge gateway. W tym celu wpisz show service loadbalancer pool.
Konfigurujemy Service Monitor do sprawdzania stanu serwerów w puli
Dzięki Service Monitor możemy monitorować stan serwerów w zapleczu puli. Jeśli odpowiedź na żądanie nie odpowiada oczekiwanemu, serwer można wyłączyć z puli, aby nie otrzymywał nowych żądań.
Domyślnie skonfigurowane są trzy metody sprawdzania:
- TCP-monitor,
- HTTP-monitor,
- HTTPS-monitor.
Stwórzmy nowy.
- Przechodzimy do zakładki Monitoring Usług, klikamy +.
- Wybieramy:
- nazwę dla nowej metody;
- interwał, w jakim będą wysyłane żądania,
- czas oczekiwania na odpowiedź,
- typ monitorowania – żądanie HTTPS z użyciem metody GET, oczekiwany kod statusu – 200(OK) oraz URL żądania.
- Na tym konfiguracja nowego Service Monitor jest zakończona, teraz możemy go użyć przy tworzeniu puli.
Konfigurujemy zasady aplikacji
Zasady aplikacji – sposób manipulowania ruchem oparty na określonych wyzwalaczach. Dzięki temu narzędziu możemy tworzyć zaawansowane zasady balansu obciążenia, których konfiguracja może być niemożliwa za pomocą profili aplikacji lub z pomocą innych usług dostępnych na Edge Gateway.
- Aby utworzyć regułę, przechodzimy do zakładki Reguły aplikacji balancerów.
- Wybieramy nazwę, skrypt, który ma korzystać z reguły, i klikamy Zapisz.
- Po utworzeniu reguły musimy edytować już skonfigurowany Wirtualny Serwer.
- W zakładce Zaawansowane dodajemy utworzoną przez nas regułę.
W powyższym przykładzie włączyliśmy wsparcie dla tlsv1.
Kilka dodatkowych przykładów:
Przekierowanie ruchu do innej puli.
Za pomocą tego skryptu możemy przekierować ruch do innej puli balancerów, jeśli główna pula nie działa. Aby reguła zadziałała, na balancerze muszą być skonfigurowane kilka pul, a wszyscy członkowie głównej puli muszą być w stanie wyłączonym. Należy wskazać dokładnie nazwę puli, a nie jej ID.
acl pool_down nbsrv(PRIMARY_POOL_NAME) eq 0
use_backend SECONDARY_POOL_NAME if PRIMARY_POOL_NAME
Przekierowanie ruchu do zewnętrznego zasobu.
Tutaj przekierowujemy ruch na zewnętrzną stronę internetową, jeśli wszyscy uczestnicy głównej puli są w stanie wyłączonym.
acl pool_down nbsrv(NAME_OF_POOL) eq 0
redirect location http://www.example.com if pool_down
Jeszcze więcej przykładów .
Na tym kończymy temat balancerów. Jeśli masz pytania, pytaj, jestem gotów odpowiedzieć.
Źródło: habr.com
