Ogólna architektura
Film instruktażowy dostępny na dole strony
High Availability
Na wstępie warto zaznaczyć, że wszystkie load balancery tworzone w usłudze Atman Cloud wykorzystują wysoką dostępność. Oznacza to, że w wypadku awarii serwera wirtualizacyjnego hostującego dany load balancer, adres vIP danego load balancera zostanie automatycznie przeniesiony na zapasowy wirtualny load balancer znajdujący się na innym serwerze.
Flavoury
Podczas tworzenia load balancera użytkownik wybiera maksymalną przepustowość interfejsów sieciowych, którą obsłuży dany load balancer.
Aktualnie w ofercie Atman Cloud znajdują się 3 rodzaje (flavoury) load balancerów, których nazwa tożsama jest limitowi przepustowości na interfejsie sieciowym load balancera:
- 200 Mbps,
- 500 Mbps (domyślny rodzaj w wypadku braku wyboru konkretnego flavoura),
- 1000 Mbps.
Jak wcześniej zaznaczono, wszystkie rodzaje tworzone są w wysokiej dostępności (HA – High Availability). Warto zaznaczyć, że po stworzeniu load balancera niemożliwa jest zmiana jego flavoura. W takim wypadku wymagane jest stworzenie load balancera na nowo.
Adres vIP load balancera
Każdy load balancer posiada dokładnie jeden przypisany adres IP. Za pomocą tego adresu w dalszej części będziemy konfigurować usługi wykorzystywane w ramach load balancera. Podczas tworzenia obiektu load balancera musimy wybrać jedną z sieci dostępnych w naszym projekcie, w której zostanie utworzony port przypisany do naszego load balancera. Dla standardowych sieci tworzonych przez użytkownika posiadających prywatny adres IP, do adresu vIP load balancera możliwe jest przypisanie adresu floating IP z puli publicznej.
Listener
W skrócie listener jest to port sieciowy, na którym nasłuchuje load balancer. Każdy load balancer może mieć kilka listenerów, które posiadają wspólny adres vIP oraz różną konfigurację backendów, do których przekierowywany jest ruch.
Wybór typu protokołu dla listenera jednocześnie definiuje typ listenera.
Dostępne są:
- HTTP – load balancing pozwalający na manipulację ruchem HTTP oraz przekierowujący taki ruch z listenera do backendów
- TCP – load balancing pozwalający na proste przekierowanie ruchu z portów TCP listernera do portów TCP w backendzie
- TERMINATED_HTTPS – load balancer nasłuchujący na protokole HTTPS (niezbędne jest dostarczenie certyfikatu SSL), “rozpakowujący” ten ruch oraz przekazujący odszyfrowany ruch HTTP do backendów
- HTTPS – efektywnie zasada działania jest identyczna jak dla load balancera TCP przekazującego ruch HTTPS – zaszyfrowany ruch przekazywany jest bezpośrednio do backendu
- UDP – load balancing pozwalający na przekierowanie ruchu z portów UDP
- SCTP – load balancing wykorzystujący protokół SCTP
- PROMETHEUS (niedostępny przez panel www – Horizon, konfiguracja możliwa z poziomu CLI/API) – typ listenera wystawiający statystyki load balancera w formacie exportera Prometheus
Każdy z typów listenerów posiada specyficzne opcje konfiguracyjne (niektóre z nich zostaną omówione dalej), dla wszystkich typów poza ustawieniem portu można skonfigurować maksymalną liczbę połączeń (domyślnie ustawioną na -1 czyli brak limitu) oraz klasy adresowe z których komunikacja będzie dozwolona (domyślnie ruch dozwolony jest ze wszystkich klas adresowych czyli 0.0.0.0/0)
Pool
Pula zawiera w sobie backendy oraz sposób ich monitorowania. W puli możemy wybrać sposób dystrybucji ruchu:
- ROUND_ROBIN
- LEAST_CONNECTIONS
- SOURCE_IP
Dodatkowo (opcjonalnie) istnieje możliwość wyboru podtrzymania sesji (session persistence), następującymi sposobami:
- SOURCE_IP – podtrzymanie sesji na podstawie skrótu (hasha) adresu IP
- HTTP_COOKIE – na podstawie ciasteczka wygenerowanego przez load balancer
- APP_COOKIE – na podstawie ciasteczka z nadaną przez użytkownika nazwą
Member
Jest to backend, do którego przekazywany jest ruch poprzez load balancer.
Możemy wybrać jedną z instancji dostępnych w naszym projekcie bądź wskazać dowolny adres IP (w kolokacji, serwerach dedykowanych lub poza infrastrukturą Atman), sieć przez którą wychodzić będzie ruch do “membera” – interfejs z tej sieci będzie podłączony do load balancera, port sieciowy na który przekazywany będzie ruch oraz wagę.
Waga określa dystrybucję ruchu pomiędzy backendami.
Prawdopodobieństwo przesłania jest równe wadze danego serwera podzielonej przez sumę wszystkich wag. Stąd też w przypadku pojedynczego backendu waga nie ma znaczenia, pozostałe przykłady:
- member1 waga 10, member2 waga 20 – ~33% ruchu będzie przekazywane do member1 oraz ~67% do member2
- member1 waga 1, member2 waga 1, member3 waga 98 – 1% ruchu przekazywane będzie do member1, 1% do member2, 98% do member3
Health Monitor
Zasób ten określa typ monitorowania backendów (memberów). W wypadku problemów z konkretnym backendem load balancer za pomocą health monitora wyłącza niesprawny backend z puli serwerów, do których przekazywany jest ruch. Stworzenie health monitorów dla puli jest opcjonalne.
Aktualnie dostępne typy health monitorów to:
- HTTP
- HTTPS
- PING
- TCP
- TLS-HELLO
- UDP-CONNECT
- SCTP
Przykładowy schemat load balancera wykorzystujący dotychczas omówione składowe
Reguły warstwy 7 (funkcjonalność dostępna jedynie poprzez CLI/API)
Zaawansowany load balancer może wykorzystywać reguły warstwy aplikacji w celu dokonywania decyzji o przekierowaniu ruchu.
Przykładem wykorzystania takich reguł jest obsługa wielu aplikacji webowych wykorzystujących wspólny load balancer (adres IP) oraz wspólny listener (port sieciowy), różniących się nazwą domenową lub ścieżką dostępu (lub w ogólności adresem URL).
Za pomocą reguł warstwy 7 load balancer bazując na URL może przekierować ruch do jednej z wielu pul (load balancer pool) skonfigurowanych w ramach jednego load balancera.
Backendy (members) znajdujące się w różnych pulach mogą obsługiwać różne aplikacje dzięki czemu backendy w ramach różnych pul dla tego samego load balancera nie muszą być identyczne.
Reguły warstwy 7 mogą bazować na następujących właściwościach dostępnych w warstwie aplikacji (L7 rule type):
- FILE_TYPE – typ pliku, czyli ostatnia część adresu URL
- PATH – ścieżka w adresie URL
- COOKIE – zawartość wskazanego pliku cookie
- HOST_NAME – adres serwera
- HEADER – nagłówek
- SSL_CONN_HAS_CERT – sprawdzenie czy zapytanie klienta posiada certyfikat
- SSL_VERIFY_RESULT – sprawdzenie czy certyfikat klienta został pomyślnie zweryfikowany
- SSL_DN_FIELD – pole DN w certyfikacie SSL
oraz po spełnieniu określonych reguł wykonać jedną z akcji (L7 policy type):
- REDIRECT_TO_URL – przekierowanie do wskazanego URL
- REDIRECT_TO_POOL – przekierowanie do wskazanej puli
- REDIRECT_PREFIX – przekierowanie do wskazanego prefiksu URL (np. przekierowanie zapytanie HTTP na HTTPS)
- REJECT – odrzucenie zapytania/pakietu
Wizualizacjach działania polityk warstwy 7