JK
Optymalizacja działania i dostępności usług
Optymalizacja działania i dostępności usług oraz serwerów jest kluczowym, obok bezpieczeństwa, zagadnieniem przy projektowaniu data center. Głównymi argumentami, które przemawiały za pojawieniem się pierwszych load balancerów (content switch'y) były:
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 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ń.
Aplikacyjne mechanizmy balansujące
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
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.
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.
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.
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).
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 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.
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.).
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, TC
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ądzeni
1
Justyna Krawiec