Kompendium wiedzy o load balancingu oraz omówienie load balancerów firmy Cisco, Juniper i F5

• podniesienie wydajności data center i zasobów w nim znajdujących się,
• postępująca migracja aplikacji typu klient-serwer do architektury, w której klientem jest przeglądarka internetowa (architektury opartej o protokoły HTTP, HTTPS).

Typologia wdrożenia i umiejscowienia Load balancera, który ewoluował na przestrzeni lat, została przedstawiona na Rys.1. W telegraficznym skrócie, działanie load balancera opiera się na inteligentnym pośredniczeniu w transakcjach pomiędzy klientami a serwerami. Inteligencja ta polega na optymalnym wyborze serwera, który będzie obsługiwał zapytania klientów tak, aby zminimalizować możliwość wystąpienia przeciążeń serwerów i niedostępności usług w chwili, gdy pozostałe serwery w danej farmie nie są zajęte. Optymalny wybór serwera jest możliwy dzięki próbkowaniu, realizowanym przez load balancer, czyli badaniu dostępności i zajętości konkretnych serwerów, będących częścią farmy widzianej przez klienta pod jednym adresem VIP. Wybór konkretnego serwera dokonywany jest przez algorytm load balancingu oraz na podstawie polityki (reguł) zdefiniowanych na load balncerze.

Należy zwrócić szczególną uwagę na fakt, iż balansować można nie tylko usługi serwerowe (HTTP, FTP), ale również pozostały ruch pojawiający się w data center, tj. ruch podlegający inspekcji firewall, bądź IPS. Dzięki temu możliwe jest balansowanie nie tylko usług, ale i urządzeń.

W ofercie Solidex znaleźć można następujące urządzenia umożliwiające balansowanie ruchu:

• Cisco: urządzenia z serii ACE, CSM, CSS;
• Juniper: urządzenia z serii DX;
• F5: urządzenia z serii BIG-IP.

W niniejszym artykule skoncentrujemy się na tym, w jaki sposób działają współczesne load balancery, z jakich mechanizmów i technologii korzystają oraz omówimy wybrane z oferty Solidex urządzenia balansujące Cisco ACE i Juniper DX oraz F5 BIG-IP. Szczegółowo zostaną omówione rodzaje i technologie balansowania ruchu, akceleracji, dostępności, zarządzania, które umożliwią czytelnikowi sprecyzowanie oczekiwań wobec współczesnych urządzeń balansujących. Wspomniane zostaną również funkcje bezpieczeństwa realizowane przez load balancery.

Ewolucja urządzeń balansujących

Patrząc z dzisiejszego punktu widzenia, pierwsze load balancery realizowały jedynie typowe balansowanie L4, w których decyzja dotycząca przekierowania ruchu na konkretny serwer mogła być i zazwyczaj była podejmowana na podstawie pierwszego pakietu. Load balancer L4 wykrywa nadchodzące flowy do serwerów znajdujących się w grupie VIP na podstawie flagi SYN bit set. Balansowanie flowów realizuje poprzez wybranie najlepszego kandydata do dostarczenia pakietu TCP SYN, jednak bez terminacji sesji TCP. Istotą balansowania L4 jest fakt, iż load balancer nie uczestniczy w terminowaniu sesji TCP. Decyzja o przekierowaniu ruchu podejmowana jest w oparciu o informacje z warstw L2-L4 i z tego powodu load balancer L4 jest kompletnie przezroczysty dla protokołów warstw wyższych.

Dość szybko okazało się, iż balansowanie ruchu, jedynie na podstawie informacji zawartych w warstwie czwartej, nie jest optymalne. Niebagatelne znaczenie miała w tym wypadku rozbudowa infrastruktury serwerów oraz ich podział warstwowy na serwery typu front-end (WWW), serwery aplikacyjne oraz serwery back-end (bazy danych). Naturalnym więc rozwinięciem balancerów L4 stały się load balancery L4-L7 (application switche). Zasadnicza różnica w stosunku do ich poprzedników polega na tym, iż load balancery L4-L7 'przerywają' oryginalny flow i terminują sesję TCP na obu końcach - po stronie klienta (przeglądarki) i serwera. Load balancer L4-L7 posiada świadomość aplikacji, dlatego może dokonać balansowania L5-L7, jednak dzieje się to dopiero po ustaleniu i zbuforowaniu sesji L4 (TCP). Balancery L4-L7 inspekcjonują aplikacje (np. HTTP) na poziomie obiektowym w sposób ciągły, a inspekcja ta jest niezależna od kierunku sesji (flowa).

Kolejnym krokiem na drodze ewolucji load balancerów stała się optymalizacja urządzeń w data center, a konkretnie ich integracja. Postępująca ewolucja w zakresie technologii wykorzystywanych w data center spowodowała wzrost liczby urządzeń dedykowanych do realizacji konkretnych zadań, tj. akceleracji, inspekcjonowania ruchu HTTP, terminacji sesji SSL, itp. Współczesne load balancery integrują te funkcje, są zatem nie tylko urządzeniami realizującymi balansowanie, ale również urządzeniami podnoszącymi poziom bezpieczeństwa w data center. Prowadzone przez instytut Gartnera badania jednoznacznie wskazują, że wielousługowe load balancery mają przed soba przyszłość. Niekwestionowanym argumentem przemawiającym za ich rozwojem jest fakt zarządzania. Patrząc z tej perspektywy, utrzymywanie w data center wielu urządzeń, takich jak klasyczne load balancery, terminatory sesji SSL, itp., często pochodzących od różnych producentów, jest kosztowne i rodzi wiele problemów natury administracyjnej. Dodatkowo instalacja wielousługowych (zintegrowanych) load balancerów minimalizuje niedogodności związane z opóźnieniami i niestabilnością wprowadzaną przez wiele urządzeń.

Patrząc na ewolucję urządzeń balansujących, kwestią czasu wydaje się być zaimplementowanie w nich aplikacyjnych mechanizmów balansujących. Umożliwią one balansowanie ruchu kierowanego, np. do baz danych (Oracle, DB2, Postgress), nie tylko na podstawie zapytań SQL, ale również w oparciu o zaimplementowane wewnętrzne protokoły komunikacyjne dla konkretnych baz danych.

Rys.2 Trendy w ewolucji load balancerów do urządzeń wielousługowych

Load balancing - omówienie metod rozkładania i próbkowania ruchu

Mimo, iż współczesne load balancery integrują wiele funkcji, jednak ich zasadniczą rolą jest balansowanie i akceleracja ruchu. Load balancery umożliwiają balansowanie protokołów HTTP, HTTPS, FTP oraz pozostałego ruchu TCP, UDP. Mogą pracować też w różnych trybach, w zależności od realizowanego typu balansowania. Gdy urządzenie realizuje balansowanie L4, pracuje jako switch L4, natomiast gdy balansuje ruch do warstwy siódmej włącznie, pracuje w trybie reverse-proxy. W obu przypadkach load balanacery realizują translację adresów (NAT). Destination NAT realizowany jest domyślnie i polega na tym, iż klienci odwołują się do adresu VIP farmy serwerów, który zostaje zmieniony na adres konkretnego serwera z grupy VIP. Invers NAT z kolei powoduje, iż klienci nie widzą rzeczywistych adresów IP serwerów i widzą jedynie wirtualny adres VIP.

Balansowanie polega na optymalnym (równomiernym) rozłożeniu ruchu i możliwe jest dzięki algorytmom lb i definiowanym regułom. Oczywiście różni producenci implementują odmienne algorytmy, zależy to również od konkretnego modelu, nie mniej jednak do najbardziej popularnych spośród nich, implementowanych w load balancerach należą:

• Round Robin: klasyczne balansowanie - kolejna sesja przekierowywana jest sekwencyjnie na kolejny serwer,
• Weighted Round Robin: Round Robin wzbogacony o możliwość przypisania wag serwerom,
• Least Conncetions: ruch jest przekierowywany do serwera z najmniejszą liczbą aktywnych połączeń,
• Weighted Least Connections: Least Connections wzbogacone o możliwość przypisania wag serwerom,
• Maximum Connections: ruch jest przekierowywany na inny serwer wówczas, gdy na obecnym liczba aktywnych połączeń osiągnie zdefiniowaną, maksymalną wartość,
• Backup Chaining: ruch jest przekierowywany na inny serwer, gdy obecny ulegnie awarii - wykorzystywany zazwyczaj, gdy serwery posiadają redundancję typu fail-over,
• Hashing (IP, URL, Cookie, HTTP Header): algorytm ten hashuje (podpisuje funkcją skrótu) np. URL,
• Fewest Outstanding Request: algorytm balansowania ruchu HTTP, HTTPS. Algorytm ten bierze pod uwagę kontekst transakcji HTTP, a nie tylko kryteria warstw niższych. Dostępny na platformie Juniper DX po wykupieniu dodatkowej licencji.

W kontekście balancingu bardzo ważne jest próbkowanie (health checking, keepalive). Ono bowiem dostarcza informacji do algorytmów balansujących na temat dostępności, a więc możliwości wyboru serwerów do obsłużenia połączeń. Serwery są odpytywane cyklicznie, co pewien czas, a w przypadku braku odpowiedzi na kilka kolejnych próbek uznawane są za nieaktywne i niebierze się ich pod uwagę w trakcie balansowania ruchu. Obecnie próbkowanie wykonywane przez load balancery, nie jest trywialne. Load balancery potrafią sprawdzić dostępność serwera, nie tylko standardowo na poziomie warstwy trzeciej (za pomocą pakietów ICMP), ale również w oparciu o warstwy wyższe: L4-L7. Ponadto load balancery umożliwiają również definiowanie własnych próbek (skryptów), które mogą badać odpowiedzi na określony ciąg znaków wysłany do serwera, a także ich czas. W przypadku Junipera, aby skorzystać ze skryptów, konieczne jest wykupienie dodatkowej licencji OverDrive. W Cisco, podobnie jak w F5, mechanizm próbkowania jest znacznie bardziej rozbudowany i nie wiąże się z zakupem licencji. Istnieje wiele metod badania dostępności serwerów, a wśród najpopularniejszych możemy wyróżnić:

• Layer 3:
  o ICMP (ping),
• Layer 4:
  o TCP/UDP (Ustanawianie połączeń TCP/UDP, TCP SYN),
  o Echo/Finger,
  
• Layer 5-7:
  o HTTP (Weryfikacja kodu odpowiedzi serwera WWW na żądania HTTP GET,
  o HTTPS (Ustanawianie prawdziwych sesji SSL) o FTP (Weryfikacja kodu odpowiedzi serwera FTP na żądania GET, LS),
  o Telnet (Wykonywanie połączeń na port 22, wysyłanie komend QUIT i badanie kodu odpowiedzi),
  o SMTP (Wykonywanie połączeń na port 25, wysyłanie wiadomości HELO/QUIT i badanie kodu odpowiedzi),
  o POP3/IMAP - (Weryfikacja kodu odpowiedzi po odebraniu maila),
  o RADIUS (Możliwość skonfigurowania NAS-IP)
  o LDAP (Wykonywanie zapytań LDAP),
  o DNS (Wykonywanie zapytań DNS).

Akceleracja - zwiększenie poziomu wydajności data center

Load balancery są urządzeniami, które poprzez balansowanie mogą podnosić dostępność zasobów data center, a także wydajność, zmniejszając konieczność inwestowania w nowe serwery. Omówiona poniżej akceleracja odnosi się do load balancerów L4-L7,pracujących w trybie reverse-proxy. Do podstawowych mechanizmów akcelerujących możemy zaliczyć:

• TCP Reuse (TCP Offload, Server Offload): Ideą tej metody jest przyspieszenie działania aplikacji web-based przez odciążenie serwerów. TCP Offload umożliwia multipleksowanie wielu tysięcy, milionów zapytań kierowanych od klientów do serwerów. Umożliwia to redukcję wielu zapytań do kilku stałych (persistant) sesji TCP, utrzymywanych między load balancerem a farmą serwerów, w ramach których przekazywane są dane dotyczące warstw wyższych (HTTP). W ten sposób odciążane są serwery, które nie muszą zajmować się zarządzaniem tysiącami TCP nawiązywanymi przez poszczególnych klientów. Należy zwrócić jednak uwagę na fakt, że TCP Offload, w związku z wykorzystaniem sesji persistant, wymaga metod zapobiegających problemowi 'shopping cart'. Problem ten jest szczególnie dokuczliwy w przypadku zakupów online przez Internet. Polega na tym, iż kilka serwerów uczestniczy w transakcji kupna, np. sesja przeglądania produktów obsługiwana jest przez jeden serwer, wybór produktów i umieszczenie ich w koszyku przez drugi serwer, a samo potwierdzenie i zapłata przez trzeci. Może zdarzyć się, że w ramach sesji persistant nie zostaną odpowiednio przekazane informacje na temat klienta, przedmiotu transakcji kupna pomiędzy serwerami i transakcja nie dojdzie do skutku. Aby temu zapobiec, load balancery wykorzystują poniższe metody:
  o stickiness - Load balancer wysyła połączenia z tego samego serwera do tego samego klienta,
  o identyfikacji klienta - Source IP, Cookie, SSL ID, HTTP Redirect.
  

Firma Juniper podaje, iż współczynnik multipleksowania może kształtować się na poziomie 2000:1. Testy praktyczne pokazują, iż odpowiednią skuteczność można osiągnąć przy współczynniku 100:1.

• Cachowanie: Jest funkcją realizowaną przez load balancer on-the-fly (w locie), w całości wykonywaną w pamięci RAM. Umieszczane są w niej elementy stron WWW (np. obrazki, video), do których najczęściej sięgają klienci. W przypadku, w którym przychodzi zapytanie klienta, w pierwszej kolejności następuje sprawdzenie, czy obiekt jest przechowywany w cache'u oraz czy jest aktualny. Po pomyślnej weryfikacji obiekt przesyłany jest do klienta z pominięciem serwerów. Cała komunikacja jest przezroczysta dla użytkownika, a serwery w wyniku cachowania są znacznie mniej obciążone.
• Kompresja danych: Jest funkcją realizowaną przez load balancer (podobnie jak cachowanie) on-the-fly (w locie), w całości wykonywaną w pamięci RAM lub jak w F5 - w przeznaczonych do tego specjalnych kartach sprzętowych. Kompresji poddawane są obiekty 'łatwokompresowalne' takie jak tekst, a algorytm kompresji można określić jako przeglądarka klienta. Wykorzystywany jest tutaj fakt, że nagłówek HTTP zawiera parametr 'Content-Encoding', oznaczający, że przeglądarka jest w stanie zaakceptować zawartość skompresowaną. Standardowo obsługiwane są dwie metody kompresji: deflate i gzip. Przeglądarka klienta, po odebraniu treści skompresowanych, dokonuje ich dekompresji. Z praktycznych badań wynika, że Mozilla Firefox lepiej obsługuje kompresję gzip a Internet Exporer deflate. Kompresja wpływa istotnie na oszczędność pasma, ponieważ przesyłane są obiekty skompresowanea nie oryginalnej wielkości.
• SSL Offloading: Niewątpliwie SSL Offloading można zaliczyć do mechanizmów akcelerujących, ponieważ load balancery terminując sesje SSL, odciążając serwery od zasobożernych operacji kryptograficznych. SSL Offloading zostanie omówiony dalej w kontekście bezpieczeństwa.

Bezpieczeństwo

Zintegrowane urządzenia balansujące, oprócz balansowania i akceleracji, mogą być aktywnymi elementami w infrastrukturze IT, podnoszącymi bezpieczeństwo. Przy czym bezpieczeństwo należy rozumieć tu dwojako, ponieważ współczesne load balancery pozwalają nie tylko zabezpieczyć ruch klientów, ale również samą infrastrukturę IT.

• SSL Offloading: W architekturze protokołów internetowych, SSL znajduje się pomiędzy warstwą czwartą (TCP) a warstwą aplikacji (np. HTTP). Skoro więc load balancery realizują L4 balancing oraz application switching, mogą bez większego problemu zająć się obsługą warstw pośrednich. Funkcje deszyfracji SSL można znaleźć w urządzeniach security, np. sondy IPS McAfee z serii Intrushield. Nie jest to jednak SSL Offloading, a jedynie deszyfracja SSL wykonywana na potrzeby przeinspekcjonowania ruchu pierwotnie zaszyfrowanego i skierowanego do serwerów web. Load balancery posiadają pełną funkcjonalność SSL Offloadingu. Mogą koncentrować sesje szyfrowane od klientów i przesyłać do serwerów czysty ruch HTTP, odciążając je w ten sposób od realizacji zadań nie związanych z udostępnianiem zawartości. Poniższy rysunek obrazuje przepływ ruchu, jaki występuje w trakcie terminiowania sesji SSL przez dedykowane urządzenia. Zobrazowane jest balansowanie ruchu SSL, którego terminacją zajmują się dedykowane urządzania - SSL Offloadery. Należy jednak pamiętać, iż zintegrowane load balancery, same potrafią terminować sesje SSL.

  

  Rys.3 Akceleracja SSL (terminowanie i balansowanie)

• Ochrona przed atakami DoS (Denial of Service): Load balancery L4-L7 są urządzeniami działającymi w architekturze reverse-proxy i z zasady posiadają mechanizmy ochrony przed atakami DoS i DDoS - połączenia użytkowników do serwerów są terminowane i w sposób ciągły monitorowane, czy ilość połączeń do danego hosta nie przekracza zdefiniowanych wartości progowych.
• Ochrona zawartości: Większość load balancerów, mimo że jest to domeną firewalli, IPS i firewalli aplikacyjnych, posiada mechanizmy chroniące kontent i serwery przed typowymi atakami aplikacyjnymi HTTP, tj. SQL Injection, XSS i zmianą zawartości treści.

Dostępność

Load balancery, podobnie jak pozostałe urządzenia aktywne znajdujące się w data center, muszą umożliwiać i posiadać mechanizmy wysokiej dostępności, takie jak:

• Klastrowanie: Zasadniczo wyróżnia się dwa rodzaje klastrów: o act/stdby (typowy tryb fail-over),
  o act/act (w trybie tym w dwa urządzenia pracują jednocześnie).
  

  Juniper wspiera dodatkowo tryb ActiveN, który zostanie omówiony dalej.

• GSLB (Global Server Load Balancing): W przypadku load balancerów posiadają one mechanizm geograficznej redundancji i kierowania ruchem w zależności od odległości. GSLB umożliwia dynamiczne rozkładanie ruchu pomiędzy lokalizacjami rozproszonymi geograficznie, poprzez przekierowywanie zapytań do najszybszych lokalizacji z punktu widzenia poszczególnych klientów. W chwili awarii jednego z oddziałów, jest on automatycznie usuwany z grupy do momentu, kiedy znów stanie się dostępny. GSLB polega na manipulowaniu rekordami DNS. Kiedy klient pyta o nazwę hosta, otrzymuje od serwera DNS odpowiedź zawierającą adresy IP, z którymi może się skontaktować. Następnie próbuje połączyć się z pierwszym adresem z listy, a gdy kontakt z nim nie jest możliwy, wybiera kolejny.

Zarządzanie i monitoring

Zarządzanie jest istotnym elementem każdego systemu znajdującego się w data cetner. W przypadku load balancerów absolutną podstawą, jaką powinien dostarczać system monitoringu, są szczegółowe statystyki dotyczące każdej transakcji TCP (ze względu na wykonywaną obowiązkowo translację adresów NAT) oraz statystyki dotyczące transakcji w warstwach wyższych (HTTP/HTTPS). Ze względu na spore różnice odnośnie aplikacji zarządzających, kwestia ta zostanie omówione poniżej w trakcie prezentacji load balancerów Cisco i Juniper.

Cisco ACE - prezentacja i omówienie load balancerów Cisco ACE

Cisco w swojej ofercie posiada kilka load balancerów:

• urządzenia wolnostojące: CSS11501, 11503, 11506;
• moduł CSM (Cisco Switching Module);
• moduł ACE (Application Control Engine);
• urządzenie wolnostojące: ACE4710 (nowość!).

Moduł ACE, podobnie jak CSM, jest modułem usługowym do cat6500 i jest zintegrowanym load balancerem L4-L7. Obecnie dostępna jest wersja 1.0 oprogramowania dla modułu ACE. Pojawienie się wersji 2.0, planowane jest na pierwszy kwartał 2007. Wówczas moduł ACE będzie posiadał wszystkie funkcje znane z load balancerów CSS/CSM. Moduł ACE nie posiada dodatkowych licencji włączających poszczególne funkcje programowe. Licencjonowane są jedynie SSL Offloading i wydajność. Moduł ACE dostępny jest w trzech wersjach wydajnościowych:

• 4Gb/s,
• 8Gb/s,
• 16Gb/s.

Zmiana wersji modułu ACE na bardziej wydajną nie wiąże się ze zmianami hardwarowymi, a polega wyłącznie na wgraniu odpowiedniej licencji. Ciekawostką jest fakt, że niezależnie od prędkości jaką daje nam moduł ACE, jest on w stanie obsłużyć zawsze tą samą maksymalną ilość połączeń, tj. 350.000 na sec. Oprócz tego domyślnie, w każdej wersji, moduł ACE udostępnia możliwość SSL Offloadingu na poziomie 1.000 sesji na sec. Aby uzyskać większą wydajność SSL potrzebne są dodatkowe licencje. Moduł ACE może terminować do 15.000 sesji SSL na sec.

Cat6500 umożliwia instalację do 4 modułów ACE, z których każdy ma podłączenie do backplane na poziomie 16Gb/s.

Rys. 4 Cisco ACE

Moduł ACE nie jest, jak większość load balancerów, oparty o architekturę x86 (PC), ale ma złożoną architekturę wewnętrzną i większość funkcji realizuje sprzętowo, co niewątpliwie jest jego cechą wyróżniającą na tle innych load balancerów. Posiada bardzo wydajną matrycę przełączającą - 60Gb/s, dwa procesory sieciowe NP. (Network Processor), oddzielny moduł zajmujący się akceleracją funkcji kryptograficznych (SSL Offloading) oraz - co najważniejsze - dwa sloty na karty rozszerzeń (Daughter Card).

Rys.5 Architektura wewnętrzna modułu ACE

W obecnej wersji IOS - 1.0, moduł ACE nie udostępnia funkcji akcelerujących, takich jak kompresja i cachowanie. Wraz z nową wersją oprogramowania planuje się również premierę karty rozszerzeń (Daughet Card), której zadaniem będzie kompresja HTTP. Wydajność tej karty ma być na poziomie 3Gb/s. Z funkcji typowo akcelerujących balansowanie, moduł ACE udostępnia TCP Offload. W wersji IOS 2.0 pojawi się również próbkowanie za pomocą SNMP.

Mimo, iż cachowanie będzie dostępne w wersji 2.0, Cisco umożliwia uruchomienie cachowania na module ACE. Cachowanie można uzyskać poprzez instalację modułu ACE wraz z urządzeniem wolnostojącym AVS (Application Velocity System). AVS jest typowym firewallem aplikacyjnym, który prócz cachowania daje możliwość inspekcji FW/IPS przesyłanej zawartości.

Podstawowym zadaniem wykonywanym przez każdy load balancer, niezależnie od wykonywanego balancingu (L4 albo L4/L7) jest translacja adresów (NAT). Moduł ACE to bardzo wydajna architektura, która jest w stanie (niezależnie od wersji wydajnościowej) realizować NAT z prędkością 1.000.000 sesji na sec. Istotną rzeczą jest fakt, że moduł ACE działa na zasadzie firewalla z white-listami, tzn. ruch nie wskazany jawnie w konfiguracji jako permit, zostanie zablokowany. Do kontroli przepływu ruchu używane są access-listy (ACL).

Rzeczą wyróżniającą Cisco na tle innych konkurentów jest wirtualizacja. Wirtualizacja polega na możliwości stworzenia w pełni funkcjonalnych i odseparowanych, wirtualnych modułów ACE. Jest to możliwe poprzez konfigurację kontekstów, których moduł ACE może obsłużyć aż 250. Z punktu widzenia zarządzania ważne jest, że istnieje podstawowy kontekst administracyjny, z poziomu którego tworzone są inne konteksty i przypisywane są im zasoby, tj. pamięć, interfejsy, itd. Każdy kontekst posiada własną konfigurację i jako taki jest niezależnym urządzeniem, którego problemy konfiguracyjne czy restart, nie wpływa na urządzenie fizyczne, czyli również na pozostałe konteksty. Wirtualizacja jest szczególnie przydatna w dużych centrach hostingowych o złożonej topologii, gdzie na jednym urządzeniu fizycznym można uruchomić wiele load balancerów.

Rys.6 Wirtualizacja na module ACE

Moduł ACE - dzięki wirtualizacji - posiada jeszcze inną, ciekawą funkcję. Umożliwia bowiem uruchomienie na jednym urządzeniu fizycznym kilku load balancerów, pracujących w różnych trybach konfiguracyjnych, tj.:

• w trybie bridge'owanym (bridged mode);
• w trybie routowalnym (routed mode);
• w trybie one-arm.

Dzięki takiemu podejściu można tworzyć naprawdę skomplikowane i niebanalne konfiguracje, dostosowane do topologii i potrzeb data center, bez konieczności inwestowania w dodatkowe urządzenia. W ramach kontekstu wirtualnego można również tworzyć domeny.

Cisco ACE umożliwia konfigurację trybów redundancji: act/act i act/stbdby. Słowo komentarza należy się jednak w przypadku trybu act/act, ponieważ Cisco realizuje ten tryb dostępności nieco inaczej niż konkurencja. Tryb act/act można skonfigurować tylko w trybie wielokontekstowym i polega on na tym, że część kontekstów uruchamiana jest na jednym urządzeniu ACE a pozostała część na drugim.

W zakresie bezpieczeństwa moduł ACE, prócz wspomnianego SSL Offloadingu, oferuje śledzenie zawartości treści i normalizacji zapytań. Do mechanizmów normalizujących (wygładzających, poprawiających) zaliczyć można:

• TCP/IP Normalization, które jest oczywiście realizowane sprzętowo,
• HTTP Inspection (URL Normalization). Inspekcji poddawane są dodatkowo FTP, Strict FTP, RSTP, ICMP, DNS, HTTPS. Inspekcja wykonywana jest przez procesory sieciowe (NP.).

Rys.7 Normalizacja na Cisco ACE

Moduł ACE, jeżeli chodzi o funkcje bezpieczeństwa, jest bardzo podobny do innego modułu usługowego cat6500, będącego typowym firewallem - modułu FWSM. Cisco ACE, w zakresie funkcjonalności firewall, umożliwia konfigurację acces-list, statefull firewall, deep packet inspection, (HTTP), a także posiada szereg rozszerzeń dotyczących inspekcji, np. FTP, TCP.

Zarządzenie jest bardzo mocną stroną load balancera ACE. Niewątpliwie wpływ na to ma zaimplementowany mechanizm RBAC (Role Based Access Control), za pomocą którego można tworzyć, modyfikować, monitorować i debugować rolami administracyjnymi. RBAC umożliwia tworzenie różnych ról (administratorów) poprzez uprawnienie konkretnej roli do określonych komend administracyjnych. W ten sposób możemy tworzyć administratorów odpowiedzialnych za load balansowanie serwerów lub tylko ich monitorowanie. Dodatkowo role administracyjne można dowolnie przypisywać do kontekstów, dzięki czemu konkretny administrator, z pełnymi prawami do jednego kontekstu, nie będzie miał dostępu do pozostałych kontekstów. Listy RBAC można przypisywać również do domen tworząc w ten sposób wirtualnych administratorów, którzy mogą zarządzać wieloma kontekstami w ograniczonym obszarze. Cisco proponuje nam dwa zasadnicze interfejsy, z poziomu których możemy zarządzać modułem ACE:

• MPC (Modular Policy CLI): MPC to interfejs konfiguracyjny bazujący na C3PL (Cisco Common Class-based Policy Language). Jest niezwykle przejrzysty, klarowny oraz bardzo intuicyjny. Jest on ukierunkowany i posiada szereg udogodnień, jeżeli chodzi o konfigurację class-map, policy-map, za pomocą których tworzymy reguły i polityki balansowania. Osoby zaprzyjaźnione z CLI Cisco, nie będą miały z jego obsługą większych problemów.
• NM (Application Network Manager): Jest graficzną aplikacją, służącą do zarządzania modułem ACE. Standardowo jest ona płatna, natomiast przy zamówieniu dwóch modułów ACE jest ona dołączana gratisowo. W chwili obecnej dostępna jest wersja 1.1 tego oprogramowania i wspiera ona tylko Linux RedHat Enterprise. W wersji 1.2, której premiera planowana jest na przyszły rok, ANM1.2 będzie obsługiwał wszystkie load balancery Cisco, tj. CSS, CSM, ACE1.0, ACE4710. Obsługiwany również będzie ACE z IOS w wersji 2.0.

Rzeczą wyróżniającą Cisco pod względem zarządzania jest możliwość konfigurowania tzw. checkpoint'ów. Checkpointy konfiguruje się w trakcie typowej pracy administracyjnej, podczas konfiguracji pozostałych funkcjonalności modułu ACE. Umożliwiają one bezpieczne cofnięcie się (rollback) do ostatnio działającej konfiguracji. Można skonfigurować do 10 checkpointów na kontekst i -co najważniejsze- rollback do ostatnio działającej konfiguracji, nie wymaga restartu urządzenia.

Rys.8 Zarządzenie modułem Cisco ACE

Na przełomie listopada/grudnia 2007 Cisco wprowadza do swojej oferty nowy load balancer - ACE4710. W odróżnieniu od modułu usługowego ACE, ACE4710 jest to urządzeniem wolnostojącym, nie mniej architekturalnie wywodzącym się z modułu ACE. Cisco ACE4710 dostępny będzie w dwóch wersjach wydajnościowych:

• 1Gb/s,
• 2Gb/s.

Urządzenie to jest w pełni zintegrowanym load balncerem udostępniającym:

• load balancing L4 i L4/L7,
• funkcje akcelerujące takie jak: cachowanie i kompresja,
• funkcje bezpieczeństwa (SSL Offloading, DoS protection, TCP/IP/HTTP Normalization, etc.).

Rys.9 Cisco ACE 4710

Juniper DX - prezentacja i omówienie load balancerów Juniper z serii DX

Firma Juniper posiada w swojej ofercie zasadniczo dwa zintegrowane load balancery. Są to urządzenia wolnostojące z serii DX, opatrzone numerami DX3200 i DX3600. Produkty te były znane wcześniej jako linia E/X oraz T/X firmy Redline Networks, jednego z liderów na rynku "Application Delivery", która w wyniku akwizycji w kwietniu 2005 została przejęta przez Juniper Networks. Oba typy load balancerów z serii DX posiadają te same oprogramowanie DX OS, obecnie dostępne w wersji 5.1. Nie różnią się one funkcjonalnie, a jedynie wydajnościowo. Oba posiadają tę samą architekturę wewnętrzną, opartą są o x86 (PC) z dedykowanymi procesorami sieciowymi.

Rys.10 DX3200/3280 i DX3600/3680

Load balancery firmy Juniper są bogate w funkcje, jednak w przeciwieństwie do urządzeń Cisco dodatkowe funkcjonalności są licencjonowane. Pomijając jednak na chwilę kwestię licencjonowania, urządzenia z serii DX wykonują pełen load balancing L4 i L4/L7. W zakresie balansowania Juniper umożliwia wykorzystanie swojego własnego algorytmu balansowania Fewest Outstanding Request, który został omówiony na początku artykułu. Posiadają dodatkowo mechanizmy akceleracji, takie jak TCP Offload, Cache i Kompresja.

Load balancery firmy Juniper realizują caching trzeciej generacji (3GCaching). Przy pomocy reguł AppRules w dowolny sposób można określać, które obiekty mają znaleźć się w cachu oraz na jak długo. W przypadku kompresji istnieje możliwość modyfikacji skompresowanych, również z wykorzystaniem reguł AppRules Page Translator Content (PTC), na poziomie nagłówków lub treści. Za ich pomocą można określić, które obiekty mają zostać poddane kompresji, w zależności np. od typu MIME. Należy jednak pamiętać, iż wykorzystanie reguły AppRules obwarowane jest koniecznością wykupienia licencji OverDrive.

W ramach bezpieczeństwa load balancery z serii DX oferuje pełen SSL Offloading, w którym również istnieje możliwość zastosowania reguł AppRules do analizy lub modyfikacji przetwarzanych danych. Urządzenie DX może pracować również jako SSL forwarder, pełniąc rolę koncentratora dla sesji SSL, po czym może ponownie zaszyfrować ruch i przesłać do serwerów - jest to tzw. SSL end-to-end. W celu uwierzytelnienia klientów i serwerów urządzenia te mogą wykorzystać certyfikaty wystawione przez Trusted Root CA lub certyfikaty wystawione przez samego właściciela serwerów (tzw. self-signed). Należy zaznaczyć, iż SSL Offloading i inne funkcje kryptograficzne realizowane są na urządzeniach 3200 i 3600 softwarowo, natomiast urządzenia 3280 i 3680 posiadają hardwarowe wsparcie SSL. Możliwe jest również uwierzytelnianie zgodnie z modelem AAA (Authorization, Authentication, Accouting) z wykorzystaniem serwerów RADIUS, LDAP oraz RSA SecurID.

Urządzenia z serii DX wspierają wszystkie najpopularniejsze algorytmy szyfrowania i uwierzytelniania DES, 3DES, AES, RC2, RC4, IDEA, MD5, SHA1.

Jeśli chodzi o dostępność to Juniper oferuje nam na swoich load balancerach szeroką gamę funkcjonalności. Dostępne jest pełne klastrowanie act/stdby oraz act/act. Dodatkowo, aby zwiększyć wydajność klastra urządzenia DX, Juniper oferuję możliwość klastra ActiveN. Funkcjonalność ta daje możliwość jednoczesnej pracy do 64 urządzeń DX, które mogą być widziane nawet jako jeden adres VIP, bez konieczności użycia zewnętrznego load balancera do podejmowania decyzji, o tym jakie urządzenie powinno zająć się konkretną transakcją. W trybie tym jeden load balancer pracuje jako tzw. master, dystrybuując ruch do pozostałych członków klastra oraz sprawdzając ich dostępność. Elekcja kolejnego mastera w momencie awarii poprzedniego następuje bez przerw w ruchu. Dodawanie kolejnych urządzeń do klastra nie wymaga zmian ani w strukturze datacenter, ani w konfiguracji pozostałych urządzeń sieciowych, co jest konieczne w przypadku tradycyjnych konfiguracji active-standby i active-active.

Load balancery firmy Juniper wspierają również mechanizm dostępności i kierowania ruchem GSLB, omówiony wcześniej. Poniżej zostały przedstawione parametry wydajnościowe platformy DX:

Rys.10 Wydajność SLB i GSLB

Rys.11Wydajność balansowania L4-L7 i SSL Offloadingu

Biorąc pod uwagę zarządzanie i system monitoringu, na load balancerach z serii DX zbierane są najistotniejsze statystyki dotyczące ich pracy i serwerów: obciążenie pamięci i procesora, zajętość łączy, status VIP-a i poszczególnych serwerów - członków farm serwerów, ilość bajtów danych przesłanych do klientów, liczba zaakceptowanych i odrzuconych połączeń, obsłużone zapytania, a także liczbę zaoszczędzonych danych. Dostępne jest również dedykowane środowisko programistyczne OverDrive, którego interfejs API- przy pomocy intuicyjnego zestawu reguł "if-then"- umożliwia zmianę kodu HTML. Zbiór tych reguł nosi nazwę Application Rules, a ich wykorzystanie zostało pokrótce omówione powyżej. Licencjonowanie, wspominane wcześniej, jest dość rozbudowane w Juniperze. Dostępne są następujące licencje:

• DX Base (Layer4 SLB), w ramach którego uzyskujemy dostęp do funkcjonalności: terminowanie SSL, ochrona przed DoS, NAT, Failover, Radius, LDAP, próbkowanie podstawowe;
• AFE (Layer7 SLB), w ramach którego uzyskujemy dostęp do funkcjonalności: akceleracja, kompresja, scrubbing, HTML rewriting, monitorowanie SLA, ActiveN, próbkowanie zaawansowane (FOR);
• AFE Advanced: 3G, w ramach którego uzyskujemy dostęp do funkcjonalności: caching, OverDrive, AutoSSL, Transaction, Assurance.

Dodatkowo w przypadku licencji AFE i AFE Advanced 3G istnieje możliwość wykupienia licencji uruchamiających funkcjonalność GSLB.

F5 BIG-IP - prezentacja i omówienie load balancerów F5 Networks

Pisząc o load balancerach, nie sposób pominąć rozwiązań oferowanych przez firmę F5 Networks z rodziny BIG-IP, które cechują się nie tylko bogatą funkcjonalnością, ale również wysoką wydajnością.

W ofercie F5 dostępnych jest sześć modeli urządzeń BIG-IP, od BIG-IP 1500 do BIG-IP 8400, różniących się między sobą przede wszystkim wydajnością, ale również ilością interfejsów sieciowych, możliwością instalacji dodatkowych kart funkcjonalnych czy ilością możliwych do uruchomienia programowych modułów funkcjonalnych. Poniżej przedstawione jest zróżnicowanie- z uwagi na wydajność modeli BIG-IP.

Rys.13 Porownywanie wydajności urządzeń F5 BIG-IP

Pod względem funkcjonalności rozwiązania F5 również należą do światowej czołówki. Wszystkie opisywane w pierwszej części artykułu funkcjonalności są dostępne na platformie BIG-IP. Podstawą rozwiązania jest specjalnie opracowana architektura sprzętowa oraz dedykowany system operacyjny TMOS z zaimplementowanym, własnym, optymalizowanym stosem TCP-IP, pełnym proxy aplikacyjnym czy wirtualną segmentacją sieciową. Otwarta architektura TMOS pozwala na implementację na jednej platformie wielu ciekawych funkcjonalności, takich jak:

• load balancing,
• connection pooling
• inteligentna kompresja (realizowana sprzętowo),
• caching (Fast Cache Module),
• akceleracja SSL (realizowana sprzętowo),
• zaawansowany routing,
• moduł zaawansowanego uwierzytelnienia klientów,
• moduł obsługujący IPv6,
• moduł kształtujący ruch (L7 Rate Shaping Module),
• firewall aplikacyjny.

Wartym uwagi, z punktu funkcjonalności, elementem architektury BIG-IP jest interfejs programowy iRules. Pozwala on na tworzenie własnych skryptów pisanych w języku TCL, które mogą wykonywać przeróżne działania na danych, analizowanych przez load-balancer. Sztandarowym przykładem takiego działania jest balansowanie połączeń HTTP, przychodzących od klientów do serwerów końcowych na podstawie określonego URL-a. Możliwe są również inne operacje ograniczone w zasadzie jedynie wyobraźnią i wydajnością poszczególnych platform.

Bezpieczeństwo

Ciekawą funkcjonalnością oferowaną przez F5 jest możliwość instalacji kart terminujących SSL, posiadających certyfikację FIPS 140-2 (Federal Information Processing Standard) - standardu publicznego stworzonego przez rząd federalny Stanów Zjednoczonych. Karty FIPS mogą być montowane w urządzeniach BIG-IP, od modelu BIG-IP 6400 i wyższych. Realizują one funkcję sprzętowego modułu kryptograficznego HSM (Hardware Security Module), wspomagając proces szyfrowania ruchu SSL oraz zapewniając odpowiedni, zdefiniowany w standardzie FIPS 140-2 poziom bezpieczeństwa przechowywania kluczy oraz certyfikatów. Karta FIPS SSL, jako bezpieczne repozytorium kluczy prywatnych, bierze udział na przykład w negocjacji kluczy symetrycznych, przekazując funkcje szyfrowania sprzętowym kartom SSL, dostępnym w każdym z modeli BIG-IP w standardzie.

Inną funkcją, istotną punktu bezpieczeństwa, jaką może posiadać również load balancer BIG-IP to firewall aplikacyjny. Firma F5 oferuje moduł programowy Application Security Manager, który może zostać zainstalowany jako dodatkowy element systemu równoważenia ruchu, dostępny także jako osobne rozwiązanie wolnostojące.

W przeciwieństwie do tradycyjnych systemów ochrony aplikacji, takich jak systemy wykrywania i blokowania włamań, moduł ASM wykorzystuje tzw. pozytywny model bezpieczeństwa, aby osłaniać chronione aplikacje. Pozytywny model oznacza sytuację, w której definiowane jest poprawne zachowanie chronionej aplikacji, a wszelkie próby wyjścia poza to poprawne zachowanie jest blokowane. Aby zdefiniować poprawne zachowanie, trzeba mieć świadomość całej aplikacji - firewall aplikacyjny musi się jej nauczyć. Istnieje wiele sposobów na poznanie aplikacji,od wykorzystania automatycznych silników analizowania aplikacji wekowych np. crowler, po ręczne definicje. Wygodnym jest również tryb nauki, podczas którego firewall aplikacyjny przygląda się zachowaniu aplikacji w trakcie użytkowania jej przez końcowych użytkowników. Następnie koniecznym jest zdefiniowanie poprawnych zachowań - na przykład określenie jakie znaki mogą być używane w konkretnych polach lub też zdefiniowanie kolejności przepływu informacji przez poszczególne formatki. Przełączenie firewalla w tryb blokowania spowoduje, że tylko poprawne zapytania pochodzące od klientów aplikacji będą akceptowane a wszystkie inne będą blokowane. Co ważne, kontrola następuje dwukierunkowo, dlatego można również zdefiniować poprawne odpowiedzi, jakie mogą być przesyłane z serwera aplikacyjnego do klientów. Dzięki temu ASM ma możliwość zablokowania przesyłania na przykład poufnych informacji, takich jak numery kont, numery kart płatniczych itd.

Mariusz Sawczuk

(Inżynier Konsultant)

mariusz.sawczuk@solidex.com.pl

Witold Mazanek

(Inżynier Konsultant)

witold.mazanek@solidex.com.pl