Każda nowoczesna usługa lub aplikacja internetowa udostępniona użytkownikom powinna wyróżniać się kilkoma cechami, m.in. powinna oferować wygodny i przejrzysty interfejs, udostępniać funkcje przydatne użytkownikowi, a przetwarzane przez nią dane powinny być odpowiednio zabezpieczone. Jest jeszcze kilka wyróżników definiujących dobrą usługę, ale jednym z najważniejszych jest jej dostępność. Na nic przecież zda się aplikacja, która nie jest zdatna do użytku na każde życzenie klienta. Duże zainteresowanie użytkowników generuje duże obciążenie całego systemu, na które należy być odpowiednio wcześniej przygotowanym. Kluczową kwestią jest więc zapewnienie skalowalności aplikacji. Skalowalność można postrzegać jako funkcjonalność dostosowującą dostępną konfigurację architektury systemu, w ramach którego działa dana aplikacja, do faktycznego zapotrzebowania aplikacji na zasoby. Aby osiągnąć taką funkcjonalność, wymagane jest użycie loadbalancera, który jest dostępny jako jeden z zasobów Microsoft Azure (lub wchodzi w skład innych zasobów). Niniejszy artykuł ma na celu zaznajomienie Czytelników CentrumXP z zasadą działania tego elementu nowoczesnej infrastruktury sieciowej.
Podstawowe informacje
Loadbalancer to element sieci komputerowej odpowiedzialny za równomierne obciążenie zasobów wewnątrz wydzielonego segmentu sieci komputerowej. Z pojęciem równomiernego obciążenia można spotkać się również w kontekście wykorzystania zasobów serwera, takich jak zużycie mocy obliczeniowej procesora czy dysków, ale niniejszy artykuł będzie poświęcony technologii równomiernego obciążenia zasobów sieci komputerowej. Tematyka ta może być znana tym Czytelnikom CentrumXP, którzy mają doświadczenia z urządzeniami sieciowymi, takimi jak przełączniki i routery. Za pomocą odpowiedniej konfiguracji - np. protokołu STP (Spanning Tree Protocol) - można za pomocą tych urządzeń wymusić zrównoważone obciążenie interfejsów warstwy drugiej modelu ISO/OSI. Jest to jednak tematyka związana bezpośrednio z sieciami komputerowymi i konfiguracją urządzeń, do których nie mamy dostępu w usługach takich jak Microsoft Azure. Zajmiemy się więc poznaniem mechanizmów równomiernego obciążenia w wyższych warstwach sieciowych. Wiedza ta jest niezbędna do uruchomienia i poprawnego skonfigurowania nowoczesnej skalowalnej usługi działającej w chmurze.
Przykładowy scenariusz użycia
Jaki jest powód do użycia loadbalancera w sieci? Tu odpowiedzi może być kilka, ale skupmy się na opisaniu podstawowego scenariusza użycia. Jednym z najczęściej udostępnianych zasobów w sieci Internet są strony internetowe oraz działające w ich ramach aplikacje. Załóżmy więc, że dysponujemy serwerem dostępnym pod publicznym adresem IP oraz rozpoznawalną zarejestrowaną nazwą DNS. Jest to jeden serwer fizyczny na którym działa jedna instancja oprogramowania, działającego jako serwer HTPP (np. Microsoft IIS lub Apache). Użytkownik po wpisaniu adresu IP serwera lub nazwy DNS zostanie połączony z serwerem HTTP nasłuchującym na porcie 80. Mamy więc do czynienia z podręcznikowym przykładem wykorzystania własnego serwera do hostowania strony dostępnej poprzez sieć Internet.
Wraz ze wzrostem popularności naszej witryny oraz jej ciągłą rozbudową o kolejne moduły i funkcje, jako sprawni administratorzy powinniśmy zauważyć pewne zagrożenia, wynikające z przyjętej przez nas architektury. Przede wszystkim w godzinach, w których witryna jest najchętniej odwiedzana przez użytkowników, powinniśmy stwierdzić znaczne spowolnienie w działaniu strony oraz wysokie obciążenia zasobów fizycznych serwera. Kwestią, która powinna nie pozwolić nam zasnąć w nocy, jest możliwość awarii elektrycznej w naszej serwerowni, co spowoduje, że nasza strona będzie niedostępna przez jakiś czas. Oczywistym rozwiązaniem jest zapewnienie nadmiarowości naszych zasobów tj. dokupienie drugiego serwera fizycznego uruchomionego w innej lokalizacji oraz skonfigurowanie na nim identycznej konfiguracji serwera HTPP. Teoretycznie w razie awarii pierwszego serwera możemy zmienić wpisy DNS naszej domeny w taki sposób, aby adres IP wskazywał na drugi serwer i w ten sposób zapewnić ciągłość działania naszej witryny. W praktyce jest to jednak niemożliwe, bo czas, który potrzebny jest na rozpropagowania nowych wpisów DNS, spowoduje, że przynajmniej dla części użytkowników strona będzie przez jakiś czas niedostępna. Dokładnie w takim przypadku należy zastanowić się nad możliwością wykorzystania loadbalancera.
Mechanizmy równomiernego obciążenia
Zgodnie z opisanym wyżej scenariuszem publiczny adres IP oraz nazwa domenowa powinny wskazywać na loadbalancer, który w swojej konfiguracji ma zapisane adresy naszych serwerów. W momencie, gdy na adres loadbalancera zostanie wysłane zapytanie HTTP o zasób naszej witryny, zostanie ono przekierowane na jeden z serwerów. Najczęściej podstawowa konfiguracja loadbalancera przekierowuje pierwszego użytkownika witryny na adres pierwszego serwera w puli, drugiego użytkownika na adres drugiego serwera w puli, trzeciego użytkownika znów na adres pierwszego serwera itd. Jest to tak zwany algorytm round-robin, znany też jako algorytm karuzelowy. Jedną z najistotniejszych cech loadbalancera jest fakt, iż mechanizm ten nie ma wpływu na doświadczenie użytkownika końcowego, ponieważ z jego perspektywy połączenie jest ciągle nawiązywane z tym samym adresem (który w rzeczywistości jest adresem loadbalancera). Część z Czytelników CentrumXP już pewnie zauważa pewien problem, który może pojawić się, jeśli użytkownik korzysta z naszej strony przy pomocy unikalnego identyfikatora sesji i ciasteczek (w skrócie – jeśli nasza strona zawiera mechanizm logowania i zapisywania indywidualnych danych o użytkowniku np. historię ostatnio przeglądanych artykułów). Wrócimy do tego zagadnienia w przedostatnim akapicie.
Wiedząc już, kiedy warto używać mechanizmu loadbalancingu w sieci, najwyższa pora zastanowić się, czym tak właściwie jest loadbalancer. Może być to dedykowane urządzenie (znajdziemy takie choćby w ofercie Cisco czy F5) lub serwer z zainstalowanym dedykowanym oprogramowaniem (np. Microsoft Network Load Balancer, ngnix, HAproxy). Wybór jednego z rozwiązań zależy od tego, jakich dodatkowych funkcjonalności oczekujemy od mechanizmu równomiernego obciążenia. W dziedzinie loadbalancerów istnieje podział na dwie podstawowe kategorie, tj. podział na urządzenia działające w warstwie czwartej modelu ISO/OSI (warstwa transportowa) oraz te, działające w warstwie siódmej (warstwa aplikacji). Jak łatwo się domyślić, różnice w działaniu wymienionych typów loadbalancerów wynikają z różnicy pomiędzy działaniem protokołów sieciowych w wymienionych warstwach.
Podstawowym działaniem loadbalancera jest wykorzystanie protokołu TCP lub UDP do badania dostępności zasobów (najczęściej serwerów) skonfigurowanych w puli. Jest to możliwe poprzez wysłanie odpowiedniego pakietu na wcześniej zdefiniowany port serwera dodanego do puli. Na podstawie czasu odpowiedzi serwera (lub jej braku) podejmowana jest decyzja o tym, czy testowany serwer jest w stanie obsłużyć wymaganą przez użytkownika operację. Serwery badane są co pewien ustalony interwał czasowy. Im krótszy czas pomiędzy kolejnymi iteracjami testu, tym szybsza reakcja mechanizmów równomiernego obciążenia na niedostępność danego zasobu. Loadbalancer działający w warstwie czwartej modelu ISO/OSI pozwala na przekierowanie zapytań użytkownika, opierając się jedynie o mechanizmy działające w warstwie transportowej i warstwach niższych. Najczęściej spotykany scenariusz przewiduje przesłanie pakietu do serwera w puli w oparciu o analizę informacji o źródłowym adresie IP oraz docelowym porcie TCP. Bardzo często loadbalancer działa jednocześnie jako router NAT, a więc zmienia źródłowy adres IP pakietu na adres używany wewnątrz naszej sieci serwerów (gdzie wykorzystywana jest adresacja prywatna). Taka konfiguracja wymaga, aby serwery należące do puli wykorzystywały adres prywatny loadbalancera jako adres bramy domyślnej. Dzięki temu wszystkie pakiety przychodzące i wychodzące są odbierane i wysyłane przez loadbalancer.
Na wstępie zaznaczyliśmy, że wykorzystanie mechanizmów równomiernego obciążenia sieci jest szczególnie przydatne w przypadku stron i aplikacji internetowych. Nie oznacza to jednak, że każda aplikacja i strona internetowa jest przystosowana do pracy w takiej architekturze. Szczególną uwagę należy zwrócić na aplikacje, które wymagają autoryzacji użytkownika i utrzymania identyfikatora sesji. Jak łatwo sobie wyobrazić, posiadając w puli loadbalancera dwa serwery aplikacyjne, należy znaleźć rozwiązanie pozwalające na błyskawiczną synchronizację danych pomiędzy serwerami. W innym przypadku - jeśli zalogowanie i rozpoczęcie sesji zostało obsłużone przez pierwszy serwer aplikacyjny, a następnie loadbalancer przekieruje kolejne żądanie tego samego użytkownika na drugi serwer - to użytkownik zostanie ponownie poproszony o dane logowania i zostanie mu przyznany nowy identyfikator sesji (ponieważ drugi serwer nie posiada danych o sesji nawiązanej z pierwszym serwerem). Twórcy aplikacji i administratorzy serwerów aplikacji mogą poradzić sobie z tym problemem poprzez użycie współdzielonej pamięci dla wszystkich serwerów działających w puli równomiernego obciążenia. Alternatywnym rozwiązaniem jest wykorzystanie jednej wspólnej bazy danych do przechowywania danych o użytkownikach. Sam loadbalancer również może posiadać opcję śledzenia użytkownika, tzn. przechowywania informacji o źródłowym adresie IP i wykorzystywania jej do tego, aby pakiety z danego adresu zawsze trafiały do tego samego serwera w puli. Nie jest to jednak rozwiązanie optymalne, ponieważ źródłowy adres IP pakietu, który ma zostać obsłużony przez mechanizm równomiernego obciążenia, jest wielokrotnie zmieniany poprzez działanie mechanizmów routingu sieciowego na trasie klient-serwer docelowy. Dwa pakiety TCP wysłane przez klienta do serwera w krótkim odstępie czasu mogą zostać przetransmitowane i przetworzone przez loadbalancer z różną wartością adresu źródłowego IP. Upraszczając – każdy z pakietów może zostać przetransmitowany do loadbalancera poprzez różną trasę routingu i finalnie każdy pakiet może trafić do innego serwera aplikacji pomimo tego, że oba pakiety zostały wysłane poprzez tego samego klienta. Jest to oczywista wada wykorzystania urządzenia zapewniającego równomierne obciążenie w warstwie czwartej modelu ISO/OSI. Właśnie z tego powodu część administratorów sieci decyduje się na wykorzystanie loadbalancerów działających w warstwie siódmej modelu ISO/OSI. Są to urządzenia lub dedykowane oprogramowanie, które w procesie przetwarzania pakietu jest w stanie odczytać zawartość warstwy aplikacji pakietu, np. informacje zawarte w nagłówku HTTP. Dzięki temu możliwe jest podtrzymanie sesji użytkownika właśnie w oparciu o dane sesji zawarte w warstwie aplikacji pakietu. Oczywiście jest to zadanie odpowiednio bardziej złożone, wymagające dużej mocy obliczeniowej i czasu. Proces inspekcji danych w pakiecie może być odpowiednio utrudniony i bardziej wymagający w przypadku, w którym dane aplikacji są transmitowane z wykorzystaniem protokołu wykorzystującego szyfrowanie np. HTTPS. W takiej sytuacji loadbalancer odpowiedzialny jest również za operacje związane z odkodowaniem i zakodowaniem zawartości pakietu. Poprzez podane powyżej powody zalecaną praktyką jest wykorzystanie urządzeń równomiernego obciążenia działających w warstwie transportowej jako rozwiązania efektywniejszego i prostszego w konfiguracji.
Podsumowanie
W niniejszym artykule pokrótce przedstawiliśmy najważniejsze informacje dotyczące podstawowego komponentu w architekturze chmury. Dzięki urządzeniom, takim jak loadbalancer, możliwe jest wykorzystanie platformy Azure w celu uruchomienia nowoczesnej skalowalnej aplikacji o wysokim współczynniku dostępności. Jest to wstęp teoretyczny, w którym zawarto dużo dodatkowych informacji, które nie są bezpośrednio wymagane w celu uruchomienia jakiejkolwiek usługi w Azure. Niniejszy tekst pozwala jednak na lepsze zrozumienie wymagań i możliwości, jakie daje Czytelnikom CentrumXP chmura Microsoftu. W niedługim czasie zostanie opublikowana druga część artykułu, która w formie poradnika opisze, w jaki sposób skonfigurować swoją pierwszą aplikację w Azure i jak skonfigurować opcje dotyczące równomiernego obciążenia.
341f31d.png)