Kiedy rozważać wysoką dostępność?

“Wysoka dostępność to nie coś, co się kupuje – to coś, co się robi.” – John Nicholson

Niewiele rzeczy jest w IT tak powszechnie pożądanych jak rozwiązania High Availability (HA). Dosłownie — wystarczy wymówić te słowa, a każdy specjalista IT natychmiast powie, że tego chce. HA dla swoich serwerów, aplikacji, storage, a oczywiście nawet desktopów. Gdyby obok każdego systemu znajdowało się pole wyboru z napisem “HA”, dlaczego mielibyśmy go nie zaznaczyć? Oczywiście byśmy zaznaczyli. Nikt dobrowolnie nie chce systemu, który często się psuje. Awarie złe, sukcesy dobre.

Najpierw jednak musimy zdefiniować HA. HA może oznaczać wiele rzeczy. Co najmniej HA musi oznaczać, że dostępność danego systemu jest wyższa niż “normalna”. Co jest normalne? Samo to jest wystarczająco trudne do zdefiniowania. HA to co najwyżej pojęcie luźne. W kontekście jego najczęstszego użycia, czyli typowych aplikacji działających na standardowym sprzęcie enterprise, proponuję następujący punkt wyjścia do dyskusji o HA:

Normalna lub standardowa dostępność (SA) byłaby definiowana jako dostępność z typowego serwera mainline z typowym enterprise systemem operacyjnym i typową aplikacją enterprise w środowisku najlepszych praktyk z enterprise wsparciem. Dobrymi przykładami mogą być Exchange działający na Windows Server na HP Proliant DL380 (najpopularniejszy mainline serwer klasy commodity) lub BIND (serwer DNS) działający na Red Hat Enterprise Linux na Dell PowerEdge R730. To jedynie przykłady służące do wyznaczenia przybliżonej linii bazowej. Nie ma dobrego sposobu na jej zmierzenie, ale przy dobrym kontrakcie wsparcia i szybkiej naprawie lub wymianie w rzeczywistości niezawodność systemu tego rodzaju szacuje się na poziomie czterech do pięciu dziewiątek (99,99% uptime lub wyżej) przy wykluczeniu błędu ludzkiego.

Wysoka dostępność (HA) powinna być powszechnie definiowana jako dostępność znacznie wyższa niż standardowa. Znacznie wyższa powinna oznaczać co najmniej jeden rząd wielkości więcej. A więc co najmniej pięć dziewiątek niezawodności, a bardziej prawdopodobnie sześć dziewiątek (99,9999% uptime).

Niska dostępność (LA) byłaby powszechnie definiowana jako dostępność znacznie niższa niż standardowa, gdzie “znacznie” ponownie oznacza co najmniej jeden rząd wielkości. LA byłoby zatem typowo zakładane na poziomie 99% do 99,9% lub niżej.

Pomiar jest tutaj bardzo trudny, ponieważ czynniki ludzkie, środowiskowe i inne odgrywają ogromną rolę w określaniu czasu pracy różnych konfiguracji. Ten sam sprzęt używany w jednej roli może osiągnąć pięć dziewiątek, podczas gdy w innej nie osiągnie nawet jednej. Jakość centrum danych, umiejętności personelu wsparcia, szybkość wymiany części, granularność monitoringu i wiele innych czynników znacząco wpłynie na ogólną niezawodność. Nie musi to być jednak dla nas problemem. W większości przypadków możemy oceniać te części projektu systemu, nad którymi mamy kontrolę, w taki sposób, że można określić względną niezawodność, dzięki czemu możemy przynajmniej wykazać, że jedno podejście będzie lepsze od drugiego — co pozwala na podejmowanie świadomych decyzji, nawet jeśli dokładne modele wskaźnika awarii nie są łatwe do skonstruowania.

Ważne jest, by zauważyć, że poza dostarczeniem przykładowego zestawu linii bazowych nie ma w definicjach wysokiej i niskiej dostępności niczego, co mówi o tym, jak te poziomy mają być osiągnięte — to nie jest to, co te terminy oznaczają. Terminy opisują wynikowe poziomy niezawodności względem linii bazowej i nic więcej. Istnieje wiele sposobów na osiągnięcie wysokiej dostępności bez stosowania powszechnie zakładanych podejść i praktycznie nieograniczona liczba sposobów na osiągnięcie niskiej dostępności.

Oczywiście HA można definiować na każdej warstwie. Możemy mieć platformy lub systemy operacyjne HA, ale kruche aplikacje na ich szczycie. Dlatego bardzo ważne jest, by w danym momencie rozumieć, o której warstwie mówimy. Na koniec dnia firmy będą dbać tylko o wysokodostępne dostarczanie usług, niezależnie od tego, jak i gdzie jest to osiągane. Liczy się wynik końcowy, a nie szczegóły techniczne — lub jak zawsze: cel uświęca środki.

Dziś niezwykle często zdarza się, że działy IT rozpraszają się nowymi i błyszczącymi narzędziami HA na warstwie platformy i zapominają szukać HA wyżej i niżej w stosie, by zapewnić wysoko dostępne usługi dla biznesu — zamiast patrzeć tylko na jedną warstwę i zostawiać firmę równie lub bardziej narażoną niż kiedykolwiek.

W rzeczywistości HA nie zawsze jest opcją i, gdy jest dostępna, wiąże się z kosztem. Ten koszt jest prawie zawsze finansowy i zazwyczaj pociąga za sobą dodatkową złożoność. A jak dobrze wiemy, każda złożoność niesie dodatkowe ryzyko — i to ryzyko może, jeśli nie będziemy ostrożni, spowodować, że próba osiągnięcia HA faktycznie zawiedzie i może nawet zostawić nas z LA, czyli niską dostępnością.

Gdy zrozumiemy ten niezbędny język opisujący, co mamy na myśli, możemy zacząć rozmawiać o tym, kiedy wysoka dostępność, standardowa dostępność, a nawet niska dostępność mogą być dla nas odpowiednie. Stosujemy ten wysoki poziom granularności, ponieważ pomiar niezawodności systemów jest tak trudny, że zbytnie wchodzenie w szczegóły staje się bezwartościowe.

Konceptualnie wszystkie systemy niosą ryzyko przestojów i nic nie może być zawsze dostępne — to niemożliwe. Niezawodność kosztuje pieniądze, ogólnie rzecz biorąc, przy wszystkich innych czynnikach równych. Aby więc określić, jaki poziom dostępności jest najbardziej odpowiedni dla danego obciążenia, musimy określić koszt ograniczenia ryzyka (kwotę pieniędzy potrzebną do zmiany średniego czasu przestoju) i porównać go z kosztem samego przestoju.

Robi się to skomplikowane, ponieważ samo określenie kosztu przestoju jest wystarczająco trudne, a określenie ryzyka przestoju jest jeszcze trudniejsze. W wielu przypadkach przestój nie jest stałą liczbą, choć może nią być. Koszt ten można wyrazić jako 5 USD/minutę lub 20 000 USD/dzień czy podobnie. Ale jeszcze lepszym narzędziem byłoby stworzenie “krzywej wpływu strat”, która pokazuje, jak pieniądze są tracone w czasie (w rozsądnym przedziale).

Na przykład firma może z łatwością nie ponosić żadnych strat przez pierwsze pięć minut, z powoli rosnącymi, ale małymi stratami aż do około czterech godzin, kiedy praca zatrzymuje się, bo ludzie nie mogą już korzystać z papierowych alternatyw i straty gwałtownie rosną. Albo niektóre firmy mogą ponosić ogromne straty w momencie, gdy systemy padają, ale straty powoli maleją w czasie. Straty mogą być znaczące tylko o określonych porach dnia. Może awarie w nocy lub w porze lunchu są trywialne, ale w środku rana lub po południu są poważne. Wpływ, ryzyko i zdolność do jego ograniczenia są w każdej firmie inne, często dramatycznie różne.

Czasem sprowadza się to do pracowników firmy. Czy wszyscy chętnie skorzystają z potrzebnych przerw na toaletę, kawę, przekąskę, a nawet lunch, gdy system zawiedzie, by wrócić do pracy po jego naprawieniu? Czy ludzie wcześniej wyjdą do domu i wcześniej przyjdą jutro, by nadrobić poważną awarię? Czy maszyny będą stać bezczynnie? Czy możliwość reagowania na klientów zostanie zakłócona? Czy systemy podtrzymywania życia zawiodą? Istnieje niezliczona liczba potencjalnych wpływów i niezliczona liczba potencjalnych sposobów łagodzenia różnych typów awarii. Wszystko to musi zostać wzięte pod uwagę. Koszt przestoju może stanowić ułamek przychodów korporacyjnych z minuty na minutę lub przestój może powodować utratę klientów lub zaufania, która jest bardziej dotkliwa niż przychody generowane z minuty na minutę.

Gdy mamy już pewne przybliżone liczby dotyczące strat, mamy przynajmniej punkt wyjścia. Nawet jeśli wiemy tylko, że przychody wynoszą ~10 USD/minutę, a straty szacuje się na ~5 USD/minutę, mamy jakiś punkt wyjścia. Jeśli mamy pełną krzywą lub badanie z bardziej szczegółowymi liczbami, tym lepiej. Teraz musimy z grubsza określić, jaka będzie nasza linia bazowa. Dobrze utrzymany serwer, działający lokalnie, z dobrym kontraktem wsparcia i dobrymi procedurami backupu i przywracania może dość łatwo osiągnąć cztery dziewiątki niezawodności. Oznacza to, że doświadczylibyśmy około pięciu godzin przestoju co pięć lat. To faktycznie mniej niż ogólnie oczekiwany przestój SA w większości środowisk i potencjalnie znacznie mniej niż w doskonałych środowiskach, takich jak wysokiej jakości centra danych z pobliskimi częściami i serwisem.

Tak więc, na podstawie naszego przykładu bazowego — około pięciu godzin co pięć lat — możemy określić nasze potencjalne ryzyko. Jeśli tracimy ~5 USD/minutę i oczekujemy około 300 minut przestoju co pięć lat, patrzymy na potencjalną stratę 1 500 USD co półdekady.

Oznacza to, że w skrajnym przypadku nie moglibyśmy nigdy wydać 1 500 USD na ograniczenie tego ryzyka — byłoby to finansowym absurdem. Dzieje się tak z kilku powodów. Jednym z największych jest to, że jest to tylko ryzyko; wydawanie 1 500 USD na ochronę przed utratą 1 500 USD ma mało sensu, ale to bardzo powszechny błąd popełniany przez osoby, które nie analizują tych liczb uważnie.

Najważniejszym czynnikiem jest to, że żadna technika ograniczania ryzyka nie jest w pełni skuteczna. Jeśli uda nam się przesunąć system czterech dziewiątek do systemu pięciu dziewiątek, zredukujemy tylko 90% średniego przestoju, przenosząc nas z 1 500 USD strat do 150 USD strat. Jeśli wydamy 1 500 USD na tę redukcję, łączna “strata” nadal wyniesie 1 650 USD (koszt ochrony jest formą straty finansowej). Koszt ograniczenia ryzyka łącznie z przewidywanym pozostałym wpływem musi być niższy niż przewidywany koszt ryzyka bez ograniczenia, w przeciwnym razie samo ograniczenie jest bezcelowe lub aktywnie szkodliwe.

Wielu może pytać, dlaczego łączny koszt ograniczenia ryzyka musi być niższy, a nie równy — czy to nie oznaczałoby “progu rentowności ryzyka”? Na pozór wydaje się to prawdą, ale ponieważ mamy do czynienia z ryzykiem, tak nie jest. Ograniczenie ryzyka to pewny koszt — finansowa szkoda ponoszona z góry w nadziei na ograniczenie strat jutro. Ale ryzyko jutra to domysł, miejmy nadzieję dobrze oszacowany, ale tylko domysł. Dzisiejszy koszt jest pewny. Ponoszenie pewnej szkody dzisiaj w nadziei na ograniczenie możliwej szkody jutro ma sens tylko wtedy, gdy dzisiejsza szkoda jest mała, a oczekiwana lub możliwa jutrzejsza szkoda jest bardzo duża, a skuteczność ograniczenia jest znaczna.

W idei “pewnego kosztu z góry” w celu redukcji “możliwego kosztu jutro” zawiera się koncepcja wartości pieniądza w czasie. Nawet gdyby awaria była znana co do rozmiaru i czasu, nie wydalibyśmy tej samej kwoty dziś, by jej zapobiec jutro, ponieważ nasze pieniądze są dziś więcej warte.

W najbardziej dramatycznych przypadkach zdarza się, że działy IT żądają wydania dziesiątek lub setek tysięcy dolarów z góry, by uniknąć ewentualnej straty kilku tysięcy dolarów — być może wiele lat w przyszłości. Strategię tę można nazwać “strzelaniem sobie w twarz dziś, by uniknąć ewentualnego bólu głowy jutro.”

W ramach koncepcji oceny ograniczenia ryzyka warto szczególnie wspomnieć, że w przypadku sprzętu IT istnieje wiele przykładów prób ograniczenia ryzyka, które mogą nie być tak skuteczne, jak się wydaje. Na przykład posiadanie dwóch serwerów stojących w tym samym racku może być bardzo skuteczne w ograniczaniu ryzyka awarii sprzętu hosta, ale nie ochroni przed klęskami żywiołowymi, utratą obiektu, pożarem, większością przypadków przepięcia, uruchomieniem systemu gaśniczego, przerwami sieciowymi, większością awarii aplikacji, atakiem ransomware ani innymi uzasadnionymi katastrofami.

Urządzenia storage często wyposażane są w “podwójne kontrolery”, co daje silne wrażenie wysokiej niezawodności, ale zazwyczaj te kontrolery znajdują się w jednej obudowie ze współdzielonymi komponentami, a nawet jeśli komponenty nie są współdzielone, często firmware jest współdzielony, a komunikacja między komponentami jest złożona — co często prowadzi do awarii, gdzie uszkodzenie jednego komponentu wywołuje awarię innego — czyniąc je nierzadko urządzeniami LA, a nie SA czy HA, jakiej oczekiwali kupujący. Dlatego krytyczne jest rozważenie, przed jakim ryzykiem chroni dana strategia ograniczania ryzyka i czy technika ograniczania jest prawdopodobnie skuteczna. Żadna technika nie jest w pełni skuteczna, zawsze istnieje szansa na awarię, ale niektóre strategie i techniki są szerzej skuteczne od innych, a niektóre są po prostu mylące lub wręcz kontrproduktywne. Jeśli nie będziemy ostrożni, możemy wdrożyć kosztowne produkty lub techniki, które aktywnie podważają nasze cele.

Niektóre techniki i produkty stosowane w dążeniu do wysokiej dostępności są dość drogie — może to obejmować zakup redundantnego sprzętu, wynajem innego budynku, instalację kosztownych generatorów lub licencjonowanie specjalnego oprogramowania. Istnieją też niskokosztowe techniki i oprogramowanie, ale w większości przypadków każdy ruch w kierunku wysokiej dostępności skutkuje odpowiednio dużym nakładem kapitału inwestycyjnego. Absolutnie kluczowe jest pamiętanie, że wysoka dostępność to proces — nie ma możliwości po prostu kupić wysokiej dostępności. Osiągnięcie HA wymaga dobrej dokumentacji, procedur, planowania, wsparcia, sprzętu, inżynierii i wiele więcej. W świecie systemów HA jest zwykle osiągana najpierw z perspektywy środowiskowej — poprzez awaryjne generatory zasilania, redundantne systemy HVAC, kondycjonowanie zasilania, filtrację powietrza, systemy gaśnicze i inne, by zapewnić odpowiednie środowisko dla dostępności. To samo w sobie może często sprawić, że dalsze inwestycje będą zbędne, dostarczając niezwykłych wyników. Następnie przychodzi projekt systemu HA zapewniający, że nie tylko jedna warstwa stosu technologicznego jest wysoko dostępna, ale cały stos umożliwia zachowanie funkcjonalności krytycznych aplikacji, danych lub usług przez jak najdłuższy czas. Potem przychodzi redundancja między lokalizacjami, pozwalająca na przetrwanie powodzi, huraganów, zamieci itp. Istnieją oczywiście zupełnie inne techniki, takie jak korzystanie z usług cloud computing hostowanych zdalnie. Ważne jest to, że wysoka dostępność wymaga szerokiego myślenia i planowania, nie może być po prostu zakupiona jako pozycja w budżecie i jest oceniana przez zdolność do zwrócenia czynnika ryzyka zapewniającego wynikowy czas pracy lub prawdopodobieństwo czasu pracy znacznie wyższe niż “standardowy” projekt systemu.

To, co często jest zaskakujące, prawie szokujące, dla wielu firm, a zwłaszcza specjalistów IT — którzy rzadko podejmują finansową analizę ryzyka i którym stale mówi się, że HA jest koniecznością dla każdej firmy i że kupowanie najnowszych produktów HA jest bezwzględnie właściwym sposobem wydawania budżetów — jest to, że gdy liczby są przeliczone i uwzględniona zostaje rzeczywistość kosztów i skuteczności strategii ograniczania ryzyka, okazuje się, że wysoka dostępność ma bardzo małe miejsce w jakiejkolwiek organizacji, szczególnie tych małych lub o mocno rozproszonych obciążeniach. Na rynku małych i średnich firm prawie powszechne jest stwierdzenie, że koszt i złożoność (co z kolei niesie ryzyko — głównie w postaci braku doświadczenia w zakresie technik i oceny ryzyka) podejść HA jest zbyt wysoka, by kiedykolwiek zrównoważyć potencjalne szkody spowodowane przez przestój, przed którym ograniczenie miało chronić. Są oczywiście wyjątki i wiele firm, dla których rozwiązania HA są absolutnie sensowne, ale są to wyjątki, a nie norma.

Sensowne jest również myślenie o potrzebach wysokiej dostępności w oparciu o konkretne obciążenie, a nie cały dział, firmę czy technologię. W małej firmie często wszystkie obciążenia współdzielą wspólną platformę, a potrzeba HA jednego obciążenia może pociągnąć za sobą inne, mniej krytyczne. To jest jak najbardziej w porządku i świetny sposób na rozłożenie kosztu ograniczania ryzyka krytycznego obciążenia na pomocnicze korzyści dla mniej krytycznych. W większej organizacji, gdzie dla różnych obciążeń stosuje się wiele podejść do platform, zwykle tylko niektóre obciążenia — zarówno wysoce krytyczne (pod względem ryzyka wynikającego z wpływu przestoju), jak i praktycznie możliwe do ograniczenia ryzyka (zdolność do ograniczania ryzyka może się dramatycznie różnić między różnymi typami obciążeń) — mają zastosowanie HA, a inne obciążenia pozostawia się standardowym technikom.

Przykładami obciążeń, które mogą być krytyczne i można skutecznie objąć wysoką dostępnością, może być system zamówień online, gdzie opóźnienie wynikające z wieloregionalnej replikacji ma niewielki wpływ na ogólny system, ale utrata zamówień może być bardzo dotkliwa finansowo w przypadku awarii systemu. Przykładem obciążenia, gdzie HA może być łatwa do wdrożenia, ale bezskuteczna, może być wewnętrzna strona intranetowa z odpowiedziami na najczęstsze pytania działu HR — po prostu nie byłoby opłacalne unikanie niewielkich, okazjonalnych przestojów takiego systemu. Przykładem systemu, w którym ryzyko jest wysokie, ale koszt lub skuteczność ograniczania ryzyka czyni go niepraktycznym lub wręcz niemożliwym, może być finansowa baza danych “tick” wymagająca przetwarzania ogromnych ilości danych o niskiej latencji, gdzie utrzymanie repliki byłoby nie tylko niezwykle kosztowne, ale mogłoby wprowadzić latencję podważającą zdolność systemu do odpowiedniego działania. Każda firma i każde obciążenie są unikalne i powinny być starannie oceniane.

Oczywiście techniki HA można wdrażać etapami — to nie jest podejście wszystko albo nic. Może być praktyczne ograniczenie ryzyka awarii na poziomie systemu poprzez tolerancję błędów na warstwie aplikacji w celu ochrony przed awarią sprzętu systemowego, platformy wirtualizacyjnej lub storage. Ale dla tego samego obciążenia może nie być wartościowe chronienie przed utratą jednej lokalizacji. Jeśli obciążenie obsługuje tylko konkretną lokalizację lub po prostu nie jest wystarczająco cenne, by uzasadnić dużą inwestycję w zapewnienie pracy awaryjnej między lokalizacjami, może łatwo znaleźć się “pośrodku.” Bardzo powszechne jest, że obciążenia implementują tylko częściowe rozwiązania HA, często dlatego, że dział IT może odpowiadać tylko za część z nich i nie mieć wpływu na takie rzeczy jak zasilanie i HVAC, ale prawdopodobnie najczęściej dlatego, że niektóre techniki HA są postrzegane jako wysokoprofilowe i łatwe do sprzedania kierownictwu, podczas gdy inne — jak wysokiej jakości zasilanie i klimatyzacja — często nie są, mimo że mogą zapewniać lepszy stosunek wartości do kosztu. Istnieją dobre powody, dla których pewne techniki mogą być wybierane, a inne nie, ponieważ wpływają na różne komponenty ryzyka, a niektóre ryzyka mogą mieć różny wpływ na konkretną firmę lub obciążenie.

Wysoka dostępność wymaga starannego przemyślenia, czy warto ją rozważać, a jeszcze staranniejszego przemyślenia wdrożenia. Budowanie prawdziwych systemów HA wymaga znacznego wysiłku i wiedzy specjalistycznej oraz zazwyczaj znacznych kosztów. Zrozumienie, które komponenty HA są wartościowe, a które nie, wymaga nie tylko rozległej wiedzy technicznej, ale także umiejętności finansowych i menedżerskich. Działy muszą intensywnie ze sobą współpracować, by naprawdę zrozumieć, jak HA wpłynie na organizację i kiedy będzie warta inwestycji. Kluczowe jest pamiętanie, że potrzeba wysokiej dostępności w organizacji lub dla obciążenia nie jest w żadnym razie czymś oczywistym i nie powinno być żadnym zaskoczeniem, że rozległa praktyka HA lub nawet przypadkowe praktyki HA okazują się ekonomicznie niepraktyczne.

W wielu aspektach wynika to z faktu, że standardowa dostępność osiągnęła taki poziom, że coraz mniej ryzyka trzeba ograniczać. Komponenty technologiczne stosowane w infrastrukturze biznesowej — w szczególności serwery, sprzęt sieciowy i storage — stały się tak niezawodne, że ilość przestojów, przed którą musimy się chronić, jest bardzo niska. Większość przekonania o potrzebie odruchowej wysokiej dostępności pochodzi z innej ery, kiedy niezawodny sprzęt był nieosiągalny finansowo, a nawet najdroższy sprzęt był dość zawodny według dzisiejszych standardów. To poczucie nieuchronnej zagłady — że dowolne urządzenie może zawiść w każdej chwili — pochodzi ze starszej ery, nie z obecnej. Nowoczesny sprzęt, choć oczywiście nadal niesie ryzyko, jest zadziwiająco niezawodny.

Oprócz innych ryzyk nadmierne inwestowanie w rozwiązania HA niesie finansowe i biznesowe ryzyko, które może być znaczne. Zwiększa dług techniczny w obliczu niepewności biznesowej. Co jeśli firma nagle się rozrośnie, lub co gorsza, nagle się skurczy, zmieni kierunek, zostanie przejęta lub całkowicie zbankrutuje? Inwestycja w HA jest już poniesiona, nawet jeśli potrzeba ochrony znika. Co jeśli zmieni się technologia lub lokalizacja? Część lub całość inwestycji w HA może zostać utracona przed jej oczekiwanym końcem życia.

Jako praktycy IT ocena korzyści, ryzyk i kosztów rozwiązań technologicznych leży w sercu naszej pracy. Podobnie jak wszystko inne w infrastrukturze biznesowej, określenie rodzaju ograniczenia ryzyka, wartości ochrony i właściwego finansowo poziomu jest naszym kluczowym obowiązkiem i nie może być pomijane ani ignorowane. Nigdy nie możemy po prostu zakładać, że HA jest potrzebna, ani że można ją pominąć. W analizach tego rodzaju IT wnosi do organizacji największą część swojej wartości. Tutaj mamy potencjał, by błyszczeć najbardziej.