Wysoka dostępność aplikacji w centrum danych

Prezentujemy podstawowe metody i mechanizmy, których wykorzystanie w serwerowni może istotnie zwiększyć poziom dostępności aplikacji dla użytkowników.

Firmy chcą być coraz bardziej mobilne i online, co sprawia, że IT przestaje być narzędziem biznesowym. Samo staje się biznesem, systemem, przez który przepływa większość transakcji. Jeśli firmowe systemy IT zawiodą, nie da się realizować bieżących operacji, a jeśli awaria się przedłuży, przedsiębiorstwo może nawet splajtować. Wysoka dostępność i tolerancja na błędy nabierają coraz większego znacznie za sprawą jeszcze innych czynników. Dzisiejsze centra danych są zdominowane przez wirtualizację. Skutki awarii serwera, na którym działa, np. 20 maszyn wirtualnych, będą znacznie poważniejsze, niż gdyby taka awaria wystąpiła w środowisku bez wirtualizacji. Z tego względu konieczność zapewnienie wysokiej dostępności jest dzisiaj znacznie silniejsza. Nawet jeśli wirtualizuje się mniej istotne aplikacje, to umieszczenie wielu takich aplikacji na jednym serwerze sprawia, że ten serwer staje się krytyczny.

Ciągłość działania nabrała znacznie większego znaczenia w erze wirtualizacji i cloud computingu, niż w czasach architektury klient-serwer, kiedy to oprogramowanie po stronie klienta realizowało na tyle dużo funkcji, że użytkownik mógł kontynuować pracę na swoim komputerze nawet jeśli doszło do awarii serwera. Aplikacje, w przypadku których nie dopuszczalne były przestoje, po prostu umieszczano na serwerach wyposażonych w mechanizmy tolerancji na błędy. Jednak zasięg technologii wysokiej dostępności znacznie się rozszerzył w środowiskach wirtualnych i chmurowych, w których na porządku dziennym są cienkie klienty czy urządzenia mobilne. W takich przypadkach, jeśli serwer nie jest dostępny, użytkownicy mają bardzo ograniczone możliwości kontynuowania pracy. Dlatego dostępność serwerów staje się bardzo istotna.

Zobacz również:

Jednocześnie firmy są coraz bardziej świadome kosztów przestojów. Rozwiązania wysokiej dostępności są poszukiwane, ponieważ znacznie wzrosła zależność od systemów IT. Inwestycje firm w rozwiązania HA (High Availability) zależą przede wszystkim od tego, jakie znaczenie mają chronione aplikacje, na ile wyceniania jest ich stała dostępność.

Wirtualizacja dla dostępności

Menedżerowie IT zajmujący się wirtualizacją stosują różne podejścia, żeby zapewnić ciągłość działania aplikacji. Są to mechanizmy stosowane na różnych poziomach: infrastruktury centrum danych (zasilanie awaryjne, nadmiarowe systemy chłodzenia), sprzętu (serwerów, macierzy, sieci), jak i samego oprogramowania. Wśród rozwiązań programowych najczęściej stosowane są te wbudowane w platformy wirtualizacyjne czy umożliwiające budowanie klastrów.

Mechanizmy dostępności są wbudowane, m.in. na poziomie hypervisora i dostępne we wszystkich popularnych platformach wirtualizacyjnych. Takie funkcje sprawdzają w regularnych, krótkich odstępach czasu dostępność maszyn wirtualnych, a w przypadku wykrycia problemów automatycznie podejmują środki zaradcze. Przykładowo, jeśli zostanie wykryty problem z systemem operacyjnym, dana maszyna wirtualna zostanie zrestartowana. Jeśli jednak problem wystąpił na poziomie serwera fizycznego, wszystkie działające na nim maszyny wirtualne zostają przeniesione na inną serwer. Z reguły podstawą takiego przełączania maszyn wirtualnych jest klaster działający w konfiguracji n+1, co zapewnia wystarczającą ilość nadmiarowych zasobów na wypadek awarii (czy innych sytuacji wymagających wyłączenia serwerów fizycznych, np. prac konserwacyjnych).

Jednak prosty klaster składający się z dwóch serwerów raczej nie będzie miał wystarczającej ilości mocy obliczeniowej i pamięci operacyjnej, aby w razie awarii jeden z tych serwerów obsłużył wszystkie maszyny wirtualne. W takim klastrze tolerancja na błędy zadziała dopiero, jeśli aż 50% zasobów będzie w nim zarezerwowanych na wypadek awarii. Klaster składający się z większej liczy serwerów oferuje większy poziom wykorzystania zasobów przy jednoczesnym zapewnieniu ciągłości działania w przypadku awarii jednej z maszyn. Przykładowo, klaster zbudowany z czterech serwerów będzie wymagał zarezerwowania 25% zasobów.

Trzeba przy tym wskazać, że takie rozwiązania są dobre dla użytkowników, którzy są w stanie zaakceptować krótkie przerwy w działaniu aplikacji, potrzebne na ich ponowne uruchomienie na nowym serwerze po awarii. Mogą się sprawdzić również w przypadku dużych klastrów, w których wiele maszyn wirtualnych tworzy klaster aplikacyjny i utrata jednego z węzłów na ma istotnego wpływu na działanie całego systemu.

Klastry aplikacyjne

Użytkownicy mogą również korzystać z szeregu innych mechanizmów HA wykraczających poza to, co oferują platformy wirtualizacyjne. Przykładowo, można budować klastry dla określonych aplikacji, np. baz danych SQL. W tym scenariuszu klaster składa się z aktywnego węzła obsługującego bazę danych SQL oraz z węzła pasywnego. Węzeł pasywny serwera SQL staje się aktywny w momencie awarii węzła aktywnego. Do budowy można używać technologii klastrowych Microsoft lub innych producentów.

Klaster serwera SQL zapewni wyższą dostępność niż standardowe mechanizmy wbudowane w platformy wirtualizacyjne. Tego rodzaju klaster jest bowiem ściślej zintegrowany z aplikacją. Natomiast platforma wirtualizacyjna nie jest „świadoma” aplikacji działających w maszynach wirtualnych. Wadą tego podejścia jest natomiast konieczność utworzenia dodatkowego klastra i zarządzania nim. Jeśli korzysta się z rozwiązań firm trzecich, jeszcze bardziej rośnie złożoność. Szereg producentów oferuje różne rozwiązania klastrowe, m.in. Microsoft, Dell, HP, IBM czy Intel.

Zalety i wady klastrów

Klastry umożliwiają sprostanie kilku wyzwaniom: zapewnieniu skalowalności, równoważeniu obciążenie i oczywiście osiągnięciu wysokiej dostępności. Ważnym elementem tych systemów są narzędzia do monitoringu, umożliwiające śledzenie pracy, np. systemu operacyjnego, sprzętu, sieci i pamięci masowych. Oprogramowanie klastrowe decyduje, kiedy wykonać awaryjne przełączenie, stale sprawdzając, tzw. bicie serca (heartbeat) aplikacji. Jeśli któryś z systemów będzie wykazywać objawy awarii, inny węzeł klastra przejmie jego zadania. Natomiast z zewnątrz klaster wydaje się być pojedynczym system, podczas gdy inteligentne mechanizmy redundancji umożliwiają osiągnięcie wysokiej dostępności.

Klastry serwerów mają trzy główne zalety:

• wysoka dostępność: eliminują pojedynczy punkt awarii;

• skalowalność: moc obliczeniową można zwiększać przez dodawanie kolejnych węzłów do klastra;

• zarządzalność: administrator widzi klaster jako pojedynczy system i może nim zarządzać z jednego miejsca.

Trzeba też mieć świadomość, jakie wyzwania wiążą się z klastrami. Zarządzanie środowiskiem klastrowym może być skomplikowane, szczególnie jeśli pracownicy IT nie mieli wcześniej styczności z tą technologią. Jeśli nie jest się w stanie przeprowadzić podstawowych testów, jak sprawdzenie, czy prawidłowo zainstalowano najnowsze aktualizacje oprogramowania we wszystkich węzłach klastra, może to doprowadzić do poważnych przestojów. Poza tym, jeśli pomiędzy aplikacjami są jakieś powiązania i zależności, trzeba je dobrze rozumieć, żeby wiedzieć, o co zadbać, aby utrzymać wysoką dostępność.

Bezpieczeństwo danych

Dostępność aplikacji to jedynie połowa wymagań. Dane, których aplikacje używają i zapisują, muszą być tak samo dostępne, aby zapewnić ciągłość biznesową. Tutaj stosuje się różne rozwiązania, m.in. konfiguracje RAID czy mirroring, aby przechowywać kilka kopii danych w różnych miejscach.

Mirroring jest centralnym komponentem w rozwiązaniach zapewniających najwyższy poziom dostępności oraz w scenariuszach DR (Disaster Recovery). Ta technika różni się od prostego backupu, którego celem jest tworzenie kopii zapasowych danych z określonego punktu w czasie. Mirroring tworzy dynamicznie kopie czasu rzeczywistego, które zmniejszają ilość danych zagrożonych utratą. Taką możliwość oferuje, m.in. dobrze znana konfiguracja RAID 1. Możne jej używać w macierzach lub ustawiać na dyskach podłączonych bezpośrednio do serwera.

Wśród zalet mirroringu można wymienić:

• ochronę przed utratą danych: redundancja zapewnia kopię zapasową w razie awarii sprzętu;

• ochrona przed klęskami żywiołowymi: możliwe jest szybkie przywracanie, nawet jeśli incydent obejmuje duży region;

• indywidualny dostęp do dysków: do każdego dysku lub zestawu dysków można uzyskać oddzielnie dostęp na potrzeby odczytu danych.

Mimo że mirroring jest bardzo istotny z punktu widzenia wysokiej dostępności, nie jest to kompletne rozwiązania do ochrony danych. Przykładowo, złośliwe oprogramowanie może zmodyfikować, uszkodzić lub skasować dane, może to zrobić nawet użytkownik (przypadkowo lub świadomie). Dlatego ochrona danych poprzez regularnie tworzenie kopii zapasowych jest nadal potrzebna.

Decydując się na wdrożeniu klastra i mirroringu jako elementów rozwiązania wysokiej dostępności i ciągłości biznesowej, trzeba zadbać o właściwe zarządzanie nimi, aby faktycznie osiągnąć zamierzone korzyści. Warto rozważyć następujące kwestie:

Pieniądze. System, który zapewnia ochronę i przywracanie liczone w godzinach lub dniach będzie tańszy niż taki, który ma całkowicie eliminować ewentualne przestoje. Dlatego trzeba przyjrzeć się wszystkim funkcjom i procesom zależnym od IT, a następnie odpowiedzieć sobie na pytanie, jakie będą skutki finansowe awarii poszczególnych usług. Warto zwrócić uwagę, że nadmierne przywiązywanie wagi do wysokiej dostępności może prowadzić do problemów z bezpieczeństwem danych i poufnością (większość budżetu idzie na zapewnienie ciągłości działania systemów, a niewiele środków jest przeznaczanych na zapobieganie utracie danych w przypadku awarii oraz na ochronę przed nieautoryzowanym dostępem). W efekcie organizacja może mieć problem ze zrealizowaniem rzeczywistych założeń ochrony danych i prawdopodobnie będzie wydawała na ten cel więcej, niż to konieczne.

Aplikacje na pierwszym miejscu. Kluczowym, pierwszym krokiem jest ustalenie, które aplikacje wymagają wysokiej dostępności. Ułatwieniem w tym zadaniu będzie rozrysowanie zależności między aplikacji, które powinny być dostępne. Pomocne jest utworzenie listy elementów, które są potrzebne, aby dana aplikacja działała (np. serwery, urządzenia sieciowe, punkty końcowe, itd.). Warto zauważyć, że nie wszystkie aplikacje muszą charakteryzować się takim samym poziomem wysokiej dostępności. Jednakże w przypadku aplikacji, od których oczekuje się wysokiej dostępności, wszystkie komponenty infrastruktury muszą być skonfigurowane na relatywnie zbliżonym poziomie ochrony. W przeciwnym razie najsłabsze ogniwo będzie zaniżało współczynnik wysokiej dostępności.

RPO, RTO: dla rozwiązań ciągłej dostępności należy określić dwa wymienione parametry. Pierwszy, RPO (Recovery Point Objective) oznacza, z jakiego okresu można pozwolić sobie na utratę danych. Mówiąc inaczej, jak często dane, np. backupowane. Z kolei RTO (Recovery Time Objective) mówi, jak długo maksymalnie powinno trwać przywracanie systemów do działania. Jeśli nastąpi awarii, jak długo może trwać przestój. Odpowiedź zależy od natury biznesu, który prowadzi firm oraz gotowości kierownictwa do podjęcia ryzyka biznesowej. Z tego względu ważne, żeby IT nie podejmowało samodzielnie decyzji co do wartości tych parametrów.

Pięć dziewiątek. Większość małych i średnich firm powinna dążyć do osiągnięcia niezawodności na poziomie pięciu dziewiątek, co oznacza, że systemy są dostępne przez 99,999% czasu. Nie każda firma jest w stanie lub potrzebuje tak wysokiej dostępności – w wielu przypadkach wystarczą cztery lub nawet trzy dziewiątki. Takie różnice po przecinku mogą wydawać się nieznaczące, ale odzwierciedlają znaczne okresy przestojów lub regularnych awarii. Załóżmy, że mamy do czynienia z systemem, który pracuje przez 40 godzin w tygodniu z niezawodnością wynoszącą 99,999%. To oznacza, że przez 2 minuty w roku jest on niedostępny. W przypadku dostępności na poziomie 99,99% trzeba się liczyć z przestojami wynoszącymi 20 minut w tym samym okresie. Jeśli niezawodność spadnie do 99,9%, przestoje mogą przekroczyć 3 godziny. Kierownictwo musi zdecydować, który poziom wybrać. Jakie znaczenie mają te 2 godziny dla biznesu, szczególnie jeśli nie ma się wpływu, kiedy wypadną te 2 godziny.

Outsourcing. Decyzja o korzystaniu z outsourcingu zależy od tego, czy firma jest w stanie samodzielnie zapewnić sobie wymagany przez aspekty biznesowe poziom dostępności systemów IT. Przykładowo, potrzebny jest administrator IT, który zajmie się utrzymaniem klastra czy innymi mechanizmami HA. Jeśli nie ma takiej osoby lub koszty samodzielnego utrzymania infrastruktury HA okazują się wysokie, warto rozważyć hosting lub skorzystać z zewnętrznego eksperta, który będzie zarządzać firmową infrastrukturą IT.

Testy. Mechanizmy HA są częścią planów ciągłości biznesowej, dlatego powinno się regularnie testować swoje systemy. Częstotliwość testowania zależy od dostępnego budżetu, ale zaleca się, żeby wykonywać przynajmniej 2 testy rocznie. Jeśli nie ma możliwości przetestowania całego systemu, powinno się regularnie testować przynajmniej najważniejsze aplikacje.

Inwestycja w macierze

Jeśli jakąś cześć infrastruktury można znacznie poprawić za stosunkowo niedużą kwotę, taka inwestycja będzie prawdopodobnie opłacalna. Jeśli firma stoi przed decyzją, czy zainwestować zbliżoną kwotę w poprawę dostępności macierzy, sieci, serwerów lub baz danych, warto wybrać macierze. Przemawia za tym fakt, że inwestycja w macierze, jeśli starannie przeprowadzona, poprawia nie tylko dostępność, ale również przekłada się na ochronę danych przed utratą. Dane są lepiej chronione przed utratą, ponieważ powstaje jedna lub więcej kopi, z których te dane można odtworzyć. To istotna korzyść, której, np. inwestycja w przełączniki sieciowe nie może zapewnić. DMF (Data Management Forum) wyróżniło pięć etapów wdrożenia ochrony danych: (1) pogrupowanie danych według ważności dla firmy, (2) zdefiniowanie najlepszego rozwiązania, (3) wybór konkretnych komponentów, (4) oszacowanie kosztów wdrożenia, (5) potwierdzenie decyzji lub wprowadzenie zmiany. Tak opisany proces wygląda rozsądnie, ale we wskazówkach dotyczących jego stosowania znajduje się ważne stwierdzenie. Jeśli koszty okażą się zbyt wysokie, zaleca się obniżenie ważności określonej grupy danych lub wybór innych komponentów.

Zawodność macierzy flash

Wprowadzanie do macierzy nośników SSD spowodowało, że do użytku powróciły systemy pamięci masowych wyposażone w jeden kontroler. Taka architektura, niezależnie czy chodzi o kontroler wbudowany w macierz lub o standardowy serwer pełniący tę rolę, to niestety pojedynczy punkt awarii. Dotychczas taką architekturę stosowano w najprostszych modelach macierzy adresowanych do małych i średnich firm. Większość rynku systemów pamięci masowych była zdominowana przez urządzenia wyposażone w podwójny kontroler. W razie awarii jednego drugi automatycznie przejmuje jego zadania.

Dlatego zaskakujące było wskrzeszenie urządzeń z jednym kontrolerem wraz z wprowadzeniem do macierzy nośników SSD. Przykłady takich macierzy to IBM Texas Memory Systems, Astute Networks VISX czy Nimbus Data S-Class. Wyższe ryzyko utraty danych w urządzeniach z jednym kontrolerem może być do zaakceptowania w przypadku niektórych aplikacji, jak systemy analityczne czy rozwiązania VDI. Jednak w większości przypadków trudno uzasadnić wydatek na te kosztowne urządzenia, które nie oferują wysokiej dostępności.

Ich zwolennicy sugerują, aby używać tych urządzeń w parach i z uruchomioną funkcją replikacji synchronicznej, co ma zapewniać wysoką wydajność. Jeśli producent wbudował taki mechanizm w swoje macierze z pojedynczym kontrolerem, to zbudowany z nich klaster zapewni poziom dostępności wystarczający dla większości aplikacji. Jednak to typowa konfiguracja pamięci masowych z podwójnym kontrolerem jest określana mianem klastra współdzielącego zasoby dyskowe, podobnie jak w klastrach Windows Server. Natomiast para urządzeń z pojedynczymi kontrolerami nie współdzieli żadnych zasobów.

W systemach pamięci masowych wykorzystujących twarde dyski uzasadnienie znajdowało używanie pojedynczego kontrolera, którego rolę pełnił standardowy serwer x86. To rekompensowało bowiem koszty wdrożenia drugiego zestawu dysków. Jeśli mamy do czynienia z nośnikami SSD, ich koszty mają znacznie większy udział w cenie macierzy niż ma to miejsce w przypadku twardych dysków. Dlatego kupowanie macierzy All-flash parami, aby zapewnić wysoką dostępność, jest bardzo kosztowne.

Można próbować korzystać z jednej macierzy All-flash i synchronicznie kopiować z niej dane na macierz z dyskami twardymi, ale to oznacza znaczny spadek szybkości zapisu danych na macierzy z nośnikami SSD. Wynika to z faktu, iż potwierdzenie zakończenia zapisu zostanie wysłane do aplikacji dopiero, kiedy obie macierze ukończą tę operację. To ogranicza wydajność zapisywania danych przez aplikacje do granicy wydajności wolniejszego systemu dyskowego.

Jeszcze poważniejsze konsekwencje może mieć replikacja asynchroniczna w celu zapisywania danych na wielu systemach pamięci masowych z wykorzystaniem mechanizmów aplikacyjnych. W ten sposób bowiem prosta awarii jednego urządzenia może spowodować poważny kryzys. Dla porównania, w faktycznym systemie HA awaria urządzenia nie powinna powodować utraty danych, a co najwyżej kilkusekundowe opóźnienie związane z przełączeniem. Użytkownicy są w stanie zaakceptować pewne przestoje, jeśli ich przyczyną są, np. katastrofy naturalne czy trudne do przewidzenia zjawiska. Będą jednak znacznie mniej wyrozumiali, jeśli źródłem problemów będzie dział IT.

Trzy, cztery lata temu, kiedy branża IT zachwycała się niesamowitą wydajnością macierzy All-flash, nie zwracano uwagi na inne funkcjonalności, w tym na wysoką dostępność. Jednak rynek tych urządzeń staje się już dojrzały i nie należy poświęcać wysokiej dostępności dla wysokiej wydajności. Jak podają analitycy Gartnera, zwiększenie poziomu dostępności przekłada się na ograniczenie bezpośrednich strat w zyskach, a także pozwala uniknąć w przyszłości problemów z wywiązywaniem się z zobowiązań w stosunku do klientów czy partnerów handlowych. Unika się również kosztów spowodowanych ewentualną utratą reputacji.

Czynnik ludzki

Tradycyjnie rozwiązania wysokiej dostępności koncentrują się na sprzęcie i oprogramowaniu, ale praktyka pokazuje, że poważną przyczyną przestojów bywają ludzie. Chodzi o zwykłe ludzkie pomyłki, które powodują awarie lub nieprawidłowe działanie aplikacji, co można zinterpretować jako przestój. Przykładem takich pomyłek jest wprowadzenie błędnej godziny czy wykonanie zadań w niewłaściwej kolejności. Można je ograniczać, stosując rygorystyczne procedury. Wszystkich nie da się jednak wyeliminować, ponieważ nie każdy ludzki błąd da się przewidzieć. A niektórym w ogóle nie da się zapobiec. Poza tym najnowszym czynnikiem powodującym awarie i przestoje są luki w szeroko pojmowanym bezpieczeństwie. Przykładem jest głośny atak na Sony, którego koszty firma wyceniła na 35 milionów dolarów.

Rzeczywisty poziom dostępności

Przywrócenie do działania komponentu, który uległ awarii, w wielu przypadkach nie oznacza, że w tym samym czasie dostępna staje się usługa, której działanie od niego zależało. Konieczne może być bowiem przywrócenie również innych komponentów, np. odbudowa macierzy RAID lub przywrócenie bazy danych do określonego stanu. Czas ich odzyskiwania może być krótszy lub równy czasowi odzyskiwania uszkodzonego sprzętu lub oprogramowania, ale równie dobrze może być znacznie dłuższy. Tymczasem jest to kwestia często pomijana (świadomie lub nie) podczas wyliczania poziomu dostępności. A przecież błąd, którego usunięcie zajmuje 2 minuty, ale przywrócenie dostępności usługi trwa 2 godziny, powoduje, że nie ma mowy o utrzymaniu założonego poziomu dostępności.

Za przykład niech posłuży pewna amerykańska firma zajmująca się handlem detalicznym, która w 2014 r. borykała się z przestojami swoich systemów informatycznych. Awaria została usunięta w ciągu godziny, ale przywracanie bazy danych do oryginalnego stanu trwało kilka godzin. Poprawny stan działania usług jest standardowo ujmowany w umowach SLA pomiędzy IT a biznesem. Użytkownika nie interesuje, w jaki sposób zapewnia się dostępność usługi. W przypadku awarii interesuje go wyłącznie przywrócenie usługi do działania.