Kiedy zastanawiamy się nad pojęciem wysokiej dostępności (ang. high availability) w systemach informatycznych - o ile w ogóle niektórzy zastanawiają się - to warto nadmienić tutaj o ważnej nowości, którą podzielił się w ostatnich dniach Amazon w ramach konferencji AWS re:Invent 2020. Ten wpis to rozważania nad wysoką dostępnością w skrócie HA, jak możemy ją zdefiniować, jakie miary ją definiują i jakie techniczne zagadki nas czekają, kiedy mówimy, że "chcemy wdrożyć HA".
Wprowadzenie do HA
Wysoką dostępnością określamy stan systemu, kiedy jego funkcjonalności biznesowe, czyli te z punktu widzenia użytkownika końcowego w całości są dostępne do użycia. W języku polskim określa się to nawet skrótem SWN (system wysokiej niezawodności), z którym spotkałem się rzadziej niżeli przyjętym skrótem HA. Zasadniczo nie wszyscy rozumieją, że nie chodzi tutaj o dostępność wszystkich komponentów systemu, bo nie zawsze klikanie np: ikonki Like jest kluczowe dla biznesu. Dla jednego (patrz: Facebook) to core biznes, dla innego np: wirtualnej galerii sztuki to po prostu dodatek. Z tego też banalnego punktu widzenia, posiadanie wysokiej dostępności to sprawa zależna od core biznesu.
Na pewno nie można dyskutować o płynności HA, w niektórych bardzo specyficznych dziedzinach t.j. medycyna, lotnictwo, obronność, przemysł kosmiczny, sterowanie ruchem, autonomiczne pojazdy, roboty przemysłowe i wiele innych. Jak widać, są zastosowania, gdzie warto nieco przedefiniować podejście do wysokiej dostępności. A może po prostu zastosować HA zgodnie z obowiązującymi normami :-)
Wydaje się niektórym młodszym przedstawicielom IT, że HA to ostatni nabytek branży IT i to tutaj tak dba się o wysoką dostępność. Otóż, założenie to jest obarczone błędem, bo HA również towarzyszyło pierwszym konstruktorom z różnych dziedzin np: w motoryzacji - silników, w przemyśle kosmicznym - napędów rakiet, od którego zależy powodzenie misji załogowej. Widać po tych przykładach, że HA, to nie jest kilka zasad i koniec. Na prawdziwe HA składa się wiele detali - szkoły inżynierskie, praktyka starszych inżynierów i szkolenie młodych adeptów sztuki, monitoring, audyty, testy chaosu, fuzzing, dzielenie się wiedzą, bezpieczeństwo z podejściami blue/red i stałą eksploracją branży, budowanie standardów i norm, zasady i higiena w miejscu pracy, dyskutowanie o wyzwaniach i dzielenie się wiedzą, posiadanie patentów, poddawanie testom obciążeniowym tego co wytwarzamy i wiele więcej różnych tematów. Tak, na HA składa się dość sporo doświadczenia ludzi z różnych działów, aby w końcu je jakoś zapisać. Warto zapisać, bo do momentu posiadania "wirtualnego SLA", nie wiemy z czym się technicznie mierzymy.
Tak przy okazji, kiedy lecicie samolotem tam też są komputery, których HA jest wyliczone i jest taka mini serwerownia, która zapewnia redundancję, kiedy zawiedzie sekacja A. Nasze życie ratuje wówczas sekcja B oraz dalsze reakcje zgodnie z procedurami pilotów. Jak zaufać autopilotowi w takiej sytuacji ? Otóż, SLA takiego zachowania zostało określone w normach i testy, awarie, incydenty, wypadki wykazały, że pewne rozwiązania działają sprawniej od innych. Tym samym, są znane kroki, które podwyższają HA działania samolotów. Ba, są instytucje, które piszą standardy, abyśmy w powietrzu czuli się zdecydowanie lepiej niżeli w powietrznym PKSie ;-) Nie jest to uwaga do tanich linii lotniczych - polubiłem je kiedyś i nawet dają dreszczyk emocji czasami, gratis.
Jak przedstawić HA w postaci mierzalnej metryki
Zapisanie formalnie jaki jest poziom wysokiej dostępności (ang. HA) w naszym systemem dobrze jeśli będzie odbywał się w sposób pół-automatyczny i bazował na wskaźniku umownym Service Level Agreement (ang. SLA, - pol. umowa o gwarantowanym poziomie świadczenia usług). Tutaj słowo wyjaśnienia, bo SLA dla nas samych może wydawać się żartem, ale nim nie jest. Jest za to prawdziwym przedsięwzięciem, postawieniem na nogi wielu działów w firmie, dzięki czemu każdy w swoim zespole zastanawia się przy okazji: co mógłby zrobić jutro lepiej? na co nie było być może czasu wczoraj. A może był czas, ale zarządzanie nim nie było efektywne? A może klient nie zapłacił za SLA na poziomie wyższym niżeli mamy obecnie?
Takie i inne ważne pytania warto zadać sobie w zespole, aby powiedzieć np: mamy SLA na poziomie zmierzonym od miesiąca wynoszącym 99,999 % !!! No na pewno nie będzie nikomu wstyd, jeśli takie SLA posiada, bo podana wartość to zmierzona niedostępność systemu 5 minut na rok :-)
Czemu warto walczyć o więcej 9-tek w swoim SLA?
Tak, są firmy, które walczą o więcej dziewiątek w swoim umownym zapisie o dostępności SLA i uwierzcie tysiące ludzi dbają o to, aby po roku rozliczyć się sumiennie z tego. Tak, bo inżynieria a nie amatorka polega na tym, że jeśli zgadzamy się w zespole na SLA i umawiamy, że będzie to grało na poziomie X, to robimy jako inżynierowie wszystko, aby do tego doszło.
Nie zawsze w zespole są inżynierowie z tytułami, lecz dobrze jeśli znajdzie się taki dla uzupełnienia ekipy ;-). Warto wiedzieć, że obecnie w branży IT są obecni ludzie po technikach, po filozofii i innych szkołach i branża bardzo szanuje każdego, bo brakuje zwyczajnie chętnych osób o otwartych umysłach do stałej nauki nowości IT. Zapewniam Was, że niekiedy nieinżynierowie mają więcej odwagi/energii/zamozaparcia do zrobienia HA na solidnym poziomie, niżeli tzw. "
inżynierowie z petrobudowy" jak śpiewał kiedyś Kazik. Ta dygresja wynika z doświadczenia, a nie jest to obraza dla szeroko rozumianej inżynierii. Mam tutaj na myśli fakt, że nie jeden inżynier w karierze zawodowej spotkał młodzika, który robił coś i szybko uczył się, po czym jego poziom realizacji zadań przewyższył poziom oferowany przez inżyniera. To w tych czasach IT może być zgubne, jak szybko ludzie spoza branży są w stanie, przy odpowiedniej motywacji stać się ekspertami. Zapewne jest to kwestia urodzenia obok tabletu :-) albo z wrośniętym 9-tym bitem, hahaa.
Tutaj znajdziecie
kalkulacje dostępności dla SLA. Istnieją w sieci też kalkulatory online dla SLA, gdzie wpisując 9-tki zobaczymy jak bardzo dostępny powinien być system IT wg. określonego SLA.
Wracając do tematu kolejnych 9-tek w SLA, warto powiedzieć, że niektórym firmom HA zwyczajnie się to opłaca. Np: weźmy pod uwagę Allegro.pl, czyli taki najbardziej namacalny przykład polecanego e-commerce w naszym kraju :-) Doceniam inżynierię, jaką tam mogłem poznać i współtworzyć. To jak Allegro.pl podchodzi o SLA to właśnie przykład powagi i odpowiedzialności, dojrzałości zespołowej, gdzie na końcu Pan Kowalski kupując żyrafkę w pacyfki wnuczce w prezencie, po prostu klika "Kup teraz" i np: mając podpiętą kartę kredytową, nie musi się martwić tym, czy towar dotrze na miejsce. Tak, towar dotrze, bo większa grupa dojrzałych inżynierów jest świadoma tego, jakie ma SLA i to motywuje ich do dostarczania radości klientom :-)
Szukając przykładów bardziej globalnych, które też mają w swoich celach dostarczanie radości klientom, skupię się na SLA firmy Amazon, bo ciekawostka jakiej się dowiedziałem może Was zmotywować do pracy nad własnym HA.
Jak bardzo AWS zwiększył wysoką dostępność na poziomie centrum danych?
Centrum danych (ang. data center) tzn. serwerownia to zestaw wielu serwerów, na których działają obliczenia oraz przez które przemieszczają się różne dane klientów ew. towarów. Budowanie DC jest to dość nowa dziedzina, która zapewnia zbudowanie centrum obliczeniowego na wymaganym poziomie. Okazuje się, że wymagania z roku na rok rosną. Nie jest prawdą, że serwerownie mają jedno łącze do internetu i radośnie sobie wszystko działa, bo admin Janek czuwa nad stabilnością. Nie te czasy minęły ok. 15 lat temu. Obecnie serwerownie to miejsca ze specjalnymi klimatyzatorami, szynami wielu kanałów zasilających, awaryjnych UPSów, agregatów awaryjnych, które napędzane silnikami diesla pozwalają przetrwać serwerom braki i niestabilności zasilania. Prawdą jest, że kupując miejsce w DC mamy zazwyczaj jasno określone zasady HA np: przez podanie SLA i zasad wspierania HA, albo na różne inne sposoby, które są często tajemnicą wewnętrzną danego centa danych.
W tym roku Amazon w ramach konferencji podzielił się pewną architekturą, jaką chciałbym przedstawić tutaj i pokazał, jak fajnie przeskalować i uzyskać kolejną 9-tkę wysokiej dostępności, fizyczną architekturą wspierającą ten cel.
Otóż, kiedy popatrzymy na typowy obraz DC i zapewnienia podtrzymania zasilania, mamy taki ogólny diagram:
Wszystko jest tutaj dość łatwo rozpoznawalne dla wprawnych oczu z infrastruktury :-) Dla pewności omówię: mamy zewnętrznego dostawcę prądu i awaryjny agregat prądotwórczy, do tego logikę przełączników, baterię akumulatorów. Kiedy dostawca prądu powie nie mam fazy, wówczas na chwilę przełączania na agregat działamy z banków energii, jakimi są akumulatory. Tak, agregat rozgrzewa się jak stary
zbawiciel diesel :-) Wiadomo, dolewamy paliwa do diesla, to agregat działa, jeśli nie dolewamy, to ma to często kilka do kilkunastu godzin działać, aż naprawią trakcję elektryczną.
Wygląda dość racjonalnie i teraz zobaczcie, co zrobił Amazon:
Jak widać na pierwszy rzut oka 99.99997 % SLA - tak, to nie błąd po przecinku są cztery 9-tki i jedna 7-ka. Co daje niedostępność ich infrastruktury serwerowej na poziomie ..... 9 sekund rocznie !!!!
Brawo, dla ich zapału, innowacji i inżynierii - to jest mega dobry wskaźnik jakości.
Dodali drugi tor z agregatem prądotwórczym i silą z elektrowni :-)
To ciekawe, a zapewne drogie rozwiązanie, ale to nie jest koniec. Amazon przede wszystkim uznał, że wszystkie podsystemy po drodze tzn. UPS, logika w sterownikach, agregaty oparte są też o software i jak wiadomo, software ma błędy :-) Idąc dalej tym tropem, uznali, że sami stworzą sobie oprogramowanie a docelowo hardware dla swoich serwerowni. I tutaj pewnie uznacie, że to koniec zabawy, bo zrobienie własnego racka (szafki na serwery) jest bardzo spoko, ale własny UPS, to ambitny produkt.
Oto, jak prawdopodobnie mogło się to rozegrać w praktyce: inżynierowie teoretyczni spotkali praktyków, mieli wspólne rozmowy, zapewne poleciało kilka nieudanych prób i nagle, po wykonaniu jednego komponentu kompleksowo okazało się, że działa tak jak chcemy i mamy do niego testy.
Jeśli nasi testerzy wiedzą jak to działa i gwarantują nasze standardy jakości, to zaczyna się nieźle.
Suma podwyższonych standardów jakości działów w Amazon, spowodowała, że te mniejsze SLA na poziomie poszczególnych zespołów wytworzyły wartość globalną jaką jest podwyższenie HA w produkcie AWS. Tak, przerabiali też hardware, ale jak widać, inaczej się nie da - tzn. nikt nie podzielił się taką wiedzą, jak to realnie zrobić inaczej.
Coś, co widać i warto wspomnieć: Amazon uzyskał redundancję w DC, rozdzielając podsystem podtrzymania zasilania dla dwóch torów zasilania, które są w ich szafach z serwerami. Bo wiedzą, że przełączanie zasilania to też ryzyko i tym samym wypadki na tej linii mają z głowy. Okazuje się, że to dość wrażliwa sprawa :-) i wiem też z praktyki, że bardzo newralgiczna dla ludzi z utrzymania infrastruktury z wysokim HA.
Uznaję tą prezentację "Infrastructure Keynote" za lekcję, że jeśli zespół otrzymuje ambitne i czasami niemożliwe wyzwanie, wówczas odpowiednia ilość PoC, burzy mózgów, wiedzy, radości jako pozytywny miks, dają wartość biznesową innym. Tak, znam to uczucie - fajnie jest uczestniczyć w takim procesie twórczym ;-)
Wprowadzenie HA często niweluje tzw. jeden punkt awarii (ang. Single Point of Failure), pozwala zapewnić większą redundancję (ang. redundancy), czyli odporność na wymieniony SPoF. Z tym wiąże się często obserwacja i monitorowanie (ang. abservability and monitoring). Tak się składa, że świetnie się to wpisuje w
filozofię DevOps, którą opisuję
tutaj. Stosuję ją na co dzień w pracy i widzę, że bywa przekonująca dla wielu inżynierów :-) Bardzo pożądaną konsekwencją podwyższonego SLA jest też spadek zgłoszeń technicznych do działu kontaktu z klientami. Same plusy - tak, ale wiemy, że to inwestycja, która przenosi poziom organizacji na wyższy status. Nie wszystkich stać, ale Ci, którzy wdrożyli liczą pozytywne efekty dość szybko.
Jeśli macie jakieś przemyślenia związane z budowaniem większej dostępności w IT, napiszcie w komentarzach. Chętnie poznam Wasze punkty widzenia.
Posty
