Kluczowe aplikacje biznesowe, bazy danych z informacjami koniecznymi do poprawnej pracy firmy, strony internetowe, w przypadku których przerwa w działaniu równa się ogromnym stratom finansowym - istnieją takie elementy które, aby biznes mógł sprawnie funkcjonować, po prostu muszą być dostępne. Czy jedynym wyjściem jest wiara w swoją szczęśliwą gwiazdę i liczenie na to, że nic się nie wydarzy? Czy nie ma możliwości aby zagwarantować działanie wszystkich usług? Na szczęście, jest to możliwe. Istnieją różnorakie rozwiązania, mające na celu zabezpieczyć ciągłość pracy i zapewnić uptime rzędu pięciu dziewiątek - maksymalny czas niedostępności usług 26 sekund w skali miesiąca.
Sieć
Awaria switcha, uszkodzony kabel sieciowy, nie kontaktująca wtyczka lub gniazdo patchpanela. Zdarza się. W efekcie serwer traci połączenie z siecią i przestaje być widoczny dla świata. Co z tego, że usługi działają poprawnie, skoro nikt z nich nie może skorzystać? Receptą na to jest zastosowanie bondingu. Przy wykorzystaniu jednego z modułów Kernela Linuksa możemy skonfigurować sieć tak, aby system widział dwie karty sieciowe jako jedno fizyczne urządzenie. Dzięki temu każdą z nich możemy wpiąć do odrębnego segmentu sieci, aby zmniejszyć prawdopodobieństwo wystąpienia awarii. Jeśli problem występuje tylko w jednym segmencie, serwer będzie cały czas widoczny w sieci.
Usługi
Większość usług uruchamianych na serwerach posiada specyficzne dla siebie sposoby uzyskiwania wysokiej dostępności (HA - High Availability). Na potrzeby tego artykułu omówimy najpopularniejsze z nich.
Część wspólna
W ogólności można przyjąć, że koniecznym będzie istnienie przynajmniej dwóch instancji danej usługi (dwóch baz danych, dwóch serwerów Apache itp.), które będą miały identyczną konfigurację - tak aby po awarii jednego serwera drugi mógł przejąć jego rolę. Ważną kwestią jest więc to, aby na obu serwerach był dostęp do tych samych, aktualizowanych na bieżąco danych. Rozwiązań może być kilka. Serwery mogą przechowywać dane na macierzy SAN (Storage Area Network)- współdzielonej macierzy dyskowej, podpiętej do serwerów szybką, dedykowaną siecią FC ( Fiber Channel) bąd też 10Gbps Ethernet. Dane mogą też być replikowane poprzez sieć przy użyciu mechanizmów danej usługi (czy to wbudowanych, jak replikacja w MySQL, czy też realizowanych przez dodatkowe rozwiązania, jak PostgreSQL i Slony). Istnieje też moduł Kernela Linuksa, DRBD, który, w skrócie ujmując, udostępnia opcję podpięcia przez sieć dysku z innego serwera. Zapewnia on synchronizację danych i płynne, niezauważalne przepięcie w razie wystąpienia awarii.
Nasłuchiwanie uderzeń serca
Heartbeat to demon służący jako szwajcarski scyzoryk, jeśli chodzi o tworzenie architektury HA pod Linuksem. Uruchamiane są dwie instancje - na serwerze głównym i zapasowym. Działający na serwerze zapasowym demon, co pewien zadany czas, sprawdza czy serwer główny funkcjonuje. Jeśli nie, wykonywane są zadane skrypty podnoszące usługi na serwerze zapasowym. Ciągłość działania usług jest zapewniona. Jeśli serwer główny ponownie rozpocznie pracę, przejmuje on ruch z serwera zapasowego.
WWW
Przykładową konfiguracją zapewniającą HA będzie zestaw dwóch serwerów nginx, dwóch serwerów Apache i dwa demony heartbeat. Nginx to szybki serwer http, który ma także możliwość pracy jako proxy i przekierowywać przychodzące połączenia do innych serwerów. Stawiamy dwa serwery nginx - główny i zapasowy. Pracę głównego będziemy monitorować przy pomocy heartbeat'a. Nginx'a konfigurujemy tak, aby obsługiwał wszelkie żądania dotyczące plików statycznych (html, swf, grafika, dokumenty pdf, pliki do downloadu itp.), a żądania dotyczące skryptów php przekierowywał jako proxy do serwerów Apache. Przyjmujemy dwa Apache jako minimalną wartość, aby zapewnić HA, aczkolwiek można oczywiście przygotować ich więcej. Zyskamy wtedy na wydajności. Nginx bardzo ładnie radzi sobie z rozkładaniem obciążenia na podane mu w konfiguracji serwery. Jeśli wszystkie serwery działają, obciążenie jest równomierne. Gdy jeden z serwerów Apache przestanie działać, nginx automatycznie eliminuje go z puli i przekierowuje zapytania na pozostałe serwery. Gdy serwer rozpocznie pracę, ponownie zacznie otrzymywać przekazywane przez proxy połączenia.
Tego typu rozwiązanie gwarantuje nie tylko wysoką dostępność usług, ale także równomierne rozłożenie obciążenia (load balancing) pomiędzy wszystkie instancje Apache.
MySQL
W przypadku bazy danych MySQL najbardziej popularne są dwie metody. Pierwsza z nich, to NDB Cluster. Jest to natywna dla MySQL implementacja rozwiązania klastrowego, dzięki której uzyskujemy nie tylko wysoką dostępność (ilość serwerów w klastrze możemy sobie zwiększać, dostawiać nowe, wyłączać działające - wszystko to jest realizowane na poziomie oprogramowania klastra, przeroczyste dla użytkownika), ale też load balancing - obciążenie jest rozkładane na wszystkie serwery w klastrze. MySQL zapewnia w takiej sytuacji dystrybucję obciążenia, dystrybucję danych pomiędzy serwerami w klastrze (nie jest koniecznym korzystanie z zewnętrznych macierzy, dane są automatycznie replikowane przez MySQL) a także pełną redundancję.
Faktem jest, że NDB Cluster nie jest rozwiązaniem idealnym dla każdego zastosowania. Klaster wymaga stosowania specjalnego silnika bazodanowego, który posiada pewne ograniczenia w stosunku do MyISAM czy InnoDB. Czasami koniecznym jest zrezygnowanie z tego rozwiązania, bo potrzebujemy właśnie te klasyczne silniki. Czy musimy zrezygnować z zapewnienia wysokiej dostępności? Nie. Rozwiązaniem możliwym do zastosowania w takiej sytuacji jest kombinacja heartbeat + DRBD + MySQL.
Uruchamiamy dwa klasyczne serwery MySQL, z czego jeden jest traktowany jako główny, drugi jako zapasowy. Dane synchronizowane są przy pomocy DRBD działającego w trybie active - passive. Rozumiemy to tak, że wszelkie modyfikacje, zapisy itp. przeprowadzane są na serwerze głównym, a następnie przesyłane na serwer zapasowy tak, aby istniała tam identyczna co do bajta kopia danych. Do monitoringu działania serwerów wykorzystujemy heartbeat. W razie awarii serwera głównego heartbeat działający na serwerze zapasowym wyłapuje tą sytuację i wykonuje odpowiednie akcje. DRBD na serwerze zapasowym przechodzi z trybu "tylko do odczytu" w tryb normalny, zapasowy serwer MySQL podejmuje pracę posiadając identyczny zestaw danych co wyłączony serwer główny.
Rozwiązanie to, w przeciwieństwie do klastra, nie zapewnia load balancingu, nie ma możliwości zwiększenia wydajności poprzez dostawienie kolejnego serwera. Zapewnia natomiast wysoką dostępność usługi, o co nam chodziło.
Pewność
Rozwiązań zapewniających HA jest dużo. To co istotne, to to, aby upewnić się czy administratorzy opiekujący się serwerami potrafią je przygotować i wdrożyć. Nigdy nie wiadomo kiedy będziemy zmuszeni do zapewnienia jednej z usług dostępności na poziomie pięciu dziewiątek. Dobrze jest mieć wtedy sprawdzonego partnera.
Pamiętaj, że w Kei.pl zawsze możesz liczyć na pełne wsparcie. Jesteśmy do dyspozycji 7 dni w tygodniu, 24 godziny na dobę, by służyć Ci pomocą. Masz pytania, dzwoń! Pamiętaj, Kei.pl to Niezawodny Partner w Sieci.
Kei.pl - Niezawodny Partner w Sieci
Wiedza, która inspiruje...
www.kei.pl