Ostatni raz rozmawialiśmy o możliwościach NSX Edge w zakresie routingu statycznego i dynamicznego, a dzisiaj zajmiemy się modułem równoważenia obciążenia.
Zanim zaczniemy konfigurować, chciałbym krótko przypomnieć o głównych rodzajach równoważenia.
Teoria
Wszystkie współczesne rozwiązania w zakresie równoważenia ładunku najczęściej dzieli się na dwie kategorie: równoważenie na czwartym (transport) i siódmym (aplikacyjnym) poziomie modelu . Model OSI nie jest najlepszym punktem odniesienia przy opisywaniu metod bilansowania. Na przykład, jeśli moduł równoważący L4 obsługuje również terminację TLS, czy staje się modułem równoważącym L7? Ale tak właśnie jest.
- Balanser L4 najczęściej jest to środkowy proxy stojący pomiędzy klientem a zbiorem dostępnych backendów, który kończy połączenia TCP (czyli samodzielnie odpowiada na SYN), wybiera backend i inicjuje nową sesję TCP w jego kierunku, niezależnie wysyłając SYN. Ten typ jest jednym z podstawowych, możliwe są inne opcje.
- Balanser L7 dystrybuuje ruch pomiędzy dostępnymi backendami „bardziej wyrafinowanymi” niż robi to moduł równoważący L4. Może zdecydować, który backend wybrać na podstawie np. zawartości wiadomości HTTP (adres URL, plik cookie itp.).
Niezależnie od typu wyważarka może obsługiwać następujące funkcje:
- Wykrywanie usług to proces określania zestawu dostępnych backendów (statyczny, DNS, Consul, itp.).
- Sprawdzenie funkcjonalności wykrytych backendów (aktywne „pingowanie” backendu za pomocą żądania HTTP, pasywne wykrywanie problemów w połączeniach TCP, obecność kilku kodów HTTP 503 w odpowiedziach itp.).
- Samo równoważenie (okrężne, losowy wybór, hash źródłowego IP, URI).
- Zakończenie protokołu TLS i weryfikacja certyfikatu.
- Opcje związane z bezpieczeństwem (uwierzytelnianie, zapobieganie atakom DoS, ograniczanie prędkości) i wiele więcej.
NSX Edge oferuje obsługę dwóch trybów wdrażania modułu równoważenia obciążenia:
Tryb proxy lub jednoramienny. W tym trybie NSX Edge używa swojego adresu IP jako adresu źródłowego podczas wysyłania żądania do jednego z backendów. Zatem balanser jednocześnie realizuje funkcje źródłowego i docelowego NAT. Backend widzi cały ruch jako wysłany z modułu równoważącego i bezpośrednio na niego reaguje. W takim schemacie balanser musi znajdować się w tym samym segmencie sieci co serwery wewnętrzne.
Oto jak to działa:
1. Użytkownik wysyła żądanie na adres VIP (adres balansera) skonfigurowany na urządzeniu Edge.
2. Edge wybiera jeden z backendów i wykonuje docelowy NAT, zastępując adres VIP adresem wybranego backendu.
3. Edge wykonuje źródłowy NAT, zastępując adres użytkownika, który wysłał żądanie, własnym.
4. Pakiet zostaje wysłany do wybranego backendu.
5. Backend nie odpowiada bezpośrednio użytkownikowi, ale Edge'owi, gdyż pierwotny adres użytkownika został zmieniony na adres Balancera.
6. Edge przesyła do użytkownika odpowiedź serwera.
Schemat znajduje się poniżej.
Tryb przezroczysty lub wbudowany. W tym scenariuszu balanser posiada interfejsy w sieci wewnętrznej i zewnętrznej. Jednocześnie nie ma bezpośredniego dostępu do sieci wewnętrznej z sieci zewnętrznej. Wbudowany moduł równoważenia obciążenia działa jako brama NAT dla maszyn wirtualnych w sieci wewnętrznej.
Mechanizm jest następujący:
1. Użytkownik wysyła żądanie na adres VIP (adres balansera) skonfigurowany na urządzeniu Edge.
2. Edge wybiera jeden z backendów i wykonuje docelowy NAT, zastępując adres VIP adresem wybranego backendu.
3. Pakiet zostaje wysłany do wybranego backendu.
4. Backend otrzymuje żądanie z oryginalnym adresem użytkownika (nie wykonano źródłowego NAT) i bezpośrednio na nie odpowiada.
5. Ruch jest ponownie akceptowany przez moduł równoważenia obciążenia, ponieważ w schemacie wbudowanym zwykle działa jako brama domyślna dla farmy serwerów.
6. Edge wykonuje źródłowy NAT, aby wysłać ruch do użytkownika, używając swojego adresu VIP jako źródłowego adresu IP.
Schemat znajduje się poniżej.
Praktyka
Moje stanowisko testowe ma 3 serwery z uruchomionym Apache, który jest skonfigurowany do pracy przez HTTPS. Edge będzie równoważyć żądania HTTPS metodą okrężną, przesyłając każde nowe żądanie do nowego serwera.
Zacznijmy.
Generowanie certyfikatu SSL, który będzie używany przez NSX Edge
Możesz zaimportować ważny certyfikat CA lub użyć certyfikatu z podpisem własnym. Do tego testu użyję podpisu własnego.
- W interfejsie vCloud Director przejdź do ustawień usług Edge.
- Przejdź do zakładki Certyfikaty. Z listy akcji wybierz dodanie nowego CSR.
- Wypełnij wymagane pola i kliknij Zachowaj.
- Wybierz nowo utworzony CSR i wybierz opcję CSR z podpisem własnym.
- Wybierz okres ważności certyfikatu i kliknij Zachowaj
- Certyfikat z podpisem własnym pojawi się na liście dostępnych.
Konfigurowanie profilu aplikacji
Profile aplikacji zapewniają pełniejszą kontrolę nad ruchem sieciowym oraz sprawiają, że zarządzanie nim jest proste i skuteczne. Można ich używać do definiowania zachowań dla określonych typów ruchu.
- Przejdź do zakładki Load Balancer i włącz moduł równoważenia. Włączona tutaj opcja Przyspieszenie pozwala wyważarce na użycie szybszego równoważenia L4 zamiast L7.
- Przejdź do zakładki Profil aplikacji, aby ustawić profil aplikacji. Kliknij +.
- Ustaw nazwę profilu i wybierz rodzaj ruchu, dla którego profil będzie stosowany. Pozwólcie, że wyjaśnię niektóre parametry.
Uporczywość – przechowuje i śledzi dane sesji, na przykład: który konkretny serwer w puli obsługuje żądanie użytkownika. Dzięki temu żądania użytkowników są kierowane do tego samego elementu puli przez cały okres istnienia sesji lub kolejnych sesji.
Włącz przekazywanie SSL – Po wybraniu tej opcji NSX Edge przestaje przerywać protokół SSL. Zamiast tego zakończenie następuje bezpośrednio na serwerach, które są równoważone.
Wstaw nagłówek HTTP X-Forwarded-For – umożliwia określenie źródłowego adresu IP klienta łączącego się z serwerem WWW poprzez moduł równoważenia obciążenia.
Włącz SSL po stronie basenu – pozwala określić, że wybrana pula składa się z serwerów HTTPS.
- Ponieważ będę równoważył ruch HTTPS, muszę włączyć Pool Side SSL i wybrać wcześniej wygenerowany certyfikat w zakładce Certyfikaty serwera wirtualnego -> Certyfikat usługi.
- Podobnie dla Certyfikatów puli -> Certyfikat usługi.
Tworzymy pulę serwerów, ruch do którego będzie zbilansowany Pule
- Przejdź do zakładki Baseny. Kliknij +.
- Ustalamy nazwę puli, wybieramy algorytm (ja użyję działania okrężnego) i rodzaj monitorowania backendu sprawdzania kondycji.Opcja Transparent wskazuje, czy początkowe źródłowe adresy IP klientów są widoczne dla serwerów wewnętrznych.
- Jeśli opcja jest wyłączona, ruch dla serwerów wewnętrznych pochodzi ze źródłowego adresu IP modułu równoważącego.
- Jeśli opcja jest włączona, serwery wewnętrzne widzą źródłowy adres IP klientów. W tej konfiguracji NSX Edge musi działać jako brama domyślna, aby mieć pewność, że zwracane pakiety przechodzą przez NSX Edge.
NSX obsługuje następujące algorytmy równoważenia:
- IP_HASH – wybór serwera na podstawie wyników funkcji skrótu dla źródłowego i docelowego adresu IP każdego pakietu.
- LASTCONN – bilansowanie połączeń przychodzących, w zależności od ich liczby dostępnej już na danym serwerze. Nowe połączenia będą kierowane do serwera z najmniejszą liczbą połączeń.
- ROUND_ROBIN – nowe połączenia wysyłane są kolejno do każdego serwera, zgodnie z przypisaną mu wagą.
- URI – lewa część URI (przed znakiem zapytania) jest mieszana i dzielona przez całkowitą wagę serwerów w puli. Wynik wskazuje, który serwer odbiera żądanie, zapewniając, że żądanie jest zawsze kierowane do tego samego serwera, o ile wszystkie serwery pozostają dostępne.
- NAGŁÓWEK HTTP – równoważenie w oparciu o konkretny nagłówek HTTP, który można określić jako parametr. Jeżeli nagłówka brakuje lub nie ma on żadnej wartości, stosowany jest algorytm ROUND_ROBIN.
- URL – Każde żądanie HTTP GET wyszukuje parametr adresu URL określony jako argument. Jeśli po parametrze następuje znak równości i wartość, wartość jest mieszana i dzielona przez całkowitą wagę działających serwerów. Wynik wskazuje, który serwer odbiera żądanie. Proces ten służy do śledzenia identyfikatorów użytkowników w żądaniach i zapewnia, że ten sam identyfikator użytkownika jest zawsze wysyłany do tego samego serwera, o ile wszystkie serwery pozostają dostępne.
- W bloku Członkowie kliknij +, aby dodać serwery do puli.
Tutaj musisz wskazać:- Nazwa serwera;
- Adres IP serwera;
- port, na którym serwer będzie odbierał ruch;
- port do kontroli stanu (Monitoruj kontrolę stanu);
- waga – za pomocą tego parametru możesz dostosować proporcjonalną ilość ruchu odbieranego dla konkretnego członka puli;
- Max Connections – maksymalna liczba połączeń z serwerem;
- Min Connections – minimalna liczba połączeń, które serwer musi przetworzyć, zanim ruch zostanie przekazany do następnego członka puli.
Tak wygląda ostateczna pula trzech serwerów.
Dodawanie serwera wirtualnego
- Przejdź do zakładki Serwery wirtualne. Kliknij +.
- Aktywujemy serwer wirtualny za pomocą opcji Enable Virtual Server.
Nadajemy mu nazwę, wybieramy utworzony wcześniej Profil Aplikacji, Pulę i wskazujemy adres IP, na który Serwer Wirtualny będzie otrzymywał żądania z zewnątrz. Podajemy protokół HTTPS i port 443.
Parametry opcjonalne tutaj:
Limit połączenia – maksymalna liczba jednoczesnych połączeń, jakie może obsłużyć serwer wirtualny;
Limit szybkości połączenia (CPS) – maksymalna liczba nowych przychodzących żądań na sekundę.
Na tym kończy się konfiguracja balansera, można sprawdzić jego funkcjonalność. Serwery mają prostą konfigurację, która pozwala zrozumieć, który serwer z puli przetworzył żądanie. Podczas konfiguracji wybraliśmy algorytm równoważenia Round Robin, a parametr Weight dla każdego serwera jest równy jeden, więc każde kolejne żądanie będzie przetwarzane przez kolejny serwer z puli.
Wpisujemy w przeglądarkę zewnętrzny adres balansera i widzimy:
Po odświeżeniu strony żądanie zostanie przetworzone przez następujący serwer:
I jeszcze raz - aby sprawdzić trzeci serwer z puli:
Sprawdzając, widać, że certyfikat, który przesyła nam Edge, jest tym samym, który wygenerowaliśmy na samym początku.
Sprawdzanie statusu balansera z poziomu konsoli Edge Gateway. Aby to zrobić, wejdź pokaż pulę modułu równoważenia obciążenia usługi.
Konfigurowanie Monitora usług w celu sprawdzania stanu serwerów w puli
Za pomocą Service Monitor możemy monitorować stan serwerów w puli backendu. Jeśli odpowiedź na żądanie nie jest zgodna z oczekiwaniami, serwer można usunąć z puli, aby nie otrzymywał żadnych nowych żądań.
Domyślnie skonfigurowane są trzy metody weryfikacji:
- monitor TCP,
- Monitor HTTP,
- Monitor HTTPS.
Stwórzmy nowy.
- Przejdź do zakładki Monitorowanie usługi, kliknij +.
- Wybierać:
- nazwa nowej metody;
- częstotliwość, z jaką będą wysyłane żądania,
- przekroczenie limitu czasu oczekiwania na odpowiedź,
- typ monitorowania – żądanie HTTPS metodą GET, oczekiwany kod statusu – 200(OK) i adres URL żądania.
- To kończy konfigurację nowego Monitora usług; teraz możemy go używać podczas tworzenia puli.
Konfigurowanie reguł aplikacji
Reguły aplikacji to sposób manipulowania ruchem w oparciu o określone wyzwalacze. Za pomocą tego narzędzia możemy tworzyć zaawansowane reguły równoważenia obciążenia, które mogą nie być możliwe za pośrednictwem profili aplikacji lub innych usług dostępnych na Edge Gateway.
- Aby utworzyć regułę przejdź do zakładki Reguły aplikacji w balanserze.
- Wybierz nazwę i skrypt, który będzie korzystał z reguły, i kliknij Zachowaj.
- Po utworzeniu reguły należy dokonać edycji już skonfigurowanego Serwera Wirtualnego.
- Na karcie Zaawansowane dodaj utworzoną przez nas regułę.
W powyższym przykładzie włączyliśmy obsługę protokołu tlsv1.
Jeszcze kilka przykładów:
Przekieruj ruch do innej puli.
Za pomocą tego skryptu możemy przekierować ruch do innej puli równoważącej, jeśli główna pula nie działa. Aby reguła działała, w module równoważącym musi być skonfigurowanych wiele pul, a wszyscy członkowie głównej puli muszą być w stanie wyłączenia. Należy podać nazwę puli, a nie jej identyfikator.
acl pool_down nbsrv(PRIMARY_POOL_NAME) eq 0
use_backend SECONDARY_POOL_NAME if PRIMARY_POOL_NAME
Przekieruj ruch do zasobu zewnętrznego.
Tutaj przekierowujemy ruch do zewnętrznej strony internetowej, jeśli wszyscy członkowie głównej puli nie działają.
acl pool_down nbsrv(NAME_OF_POOL) eq 0
redirect location http://www.example.com if pool_down
Jeszcze więcej przykładów .
To tyle jeśli chodzi o balanser. Jeśli masz jakieś pytania, pytaj, jestem gotowy odpowiedzieć.
Źródło: www.habr.com