SPOF — kilka słów o „Single point of failure"
24.04.2016 | aktual.: 24.04.2016 21:35
[img=domino]
Ostatnie tygodnie obfitowały w wiele atrakcji w moim życiu zawodowym - głównie z powodu kilku poważniejszych awarii, które dość mocno wymęczyły mnie zarówno fizycznie, jak i psychicznie. To jeden z tych momentów, gdy w organizmie z powodu niedospania, przemęczenia i braku magnezu w rozmowie o tym, że: "jaką to masz dobrą pracę - nie dość, że lubisz co robisz, to jeszcze ci za to płacą" budzą się demony i agresor w stosunku do rozmówcy. No ale nie o tym... W ubiegłym tygodniu niby przewidywalna rzecz - część miasta bez prądu, bo ktoś postanowił ukarść przewody miedziane ze stacji transformatorowej (pożar i straty na ponad €10mln). Tu oczywiście awarie w firmach, mimo UPSów (a to główny firewall autoamgicznie podpięty poza zasilaniem awaryjnym i podobne). Potem wyjątkowo upiorna awaria w oddziale w UK, gdzie w kilka godzin trzeba było przygotować plan awaryjny, wsiąść w samolot o 7‑mej rano i mając w bagażu głównym trochę gratów serwerowych coś poskładać naprędce.
Wszystko zaczęło się kilka tygodni wcześniej. Krótki opis sytuacji: firma, która praktycznie w kilka lat z 5 pracowników urosła do blisko 200‑osobowego zespołu, całkiem solidne zaplecze sprzętowe. Dość świeże kosztowe środowisko (zarządzalne przełączniki sieciowe, dwie mocne 2‑procesorowe serwery z blisko 100GB RAM każdy w klastrze HA, SAN i porządny storage).
Piątek, piąteczek, piątuniek... Końcówka piąteczka, system praktycznie czysty od jakiś bardzo poważnych zgłoszeń. Godzina około 16‑stej, wpada alert, że "wyskoczył" z RAID jeden z dysków zasobie dyskowym, gdzie siedzą wszystkie maszyny wirtualne. W sumie spokój, bo RAID redundanty z dodatkowo nieużywanym jednym z dyskiem ("hot-spare"). Dla mniej wtajemniczonych: RAID redundantny oznacza, że może się w macierzy uszkodzić jeden dowolny dysk, to jednak nie spowoduje utraty danych - ot, taka sztuczka z rodzieleniem danych / deduplikacji i sum kontrolnych. Dodatkowy dysk, który czeka nieużywany przejmuje rolę tego uszkodzonego - włącza się do macierzy i w kika godzin odbudowuje swoje dane (czyli w teorii mogą uszkodzić się nawet dwa napędy(. Problem jednak w tym, że nagle poznikały serwery wirtualne a w sieci pozostały widoczne tylko hipernadzorcy*.
Logowanie na hypervisory już mocniej zaniepokoiło - brak komunikacji z zasobami maszyn na NAS po iSCSI. Dziwna sprawa, bo można "pingować" a cały czas jestem podłączony do NASa przez interfejs https... oznacza to wstępnie poważną awarię "klatki" dyskowej, albo kontrolera. Po chwili jednak dyski wracają na swoje miejsce, jednak macierz już delkiatnie mówiąc rozjechana i trzeba przywracać z backupu, co zajmuje sporo czasu.
Dojście do tego co się stało okazało się dość proste, bo klient nie kręcił - zbyt poważni ludzie i nie było próby odwrócenia kota ogonem. Ja jednak byłem dość mocno zaskoczny. Sytuacja dość podobna, jak w przy katastrofie lotu Aerofłot 593 (oczywiście nie z takimi konsekwencjami i tragedią) - czynnik ludzki i właśnie SPOF, o którym jeszcze będzie w tym wpisie.
W firmie impreza z dziećmi pracowników, dziwnym sposobem doszło do zwiedzania pomieszczenia serwerwoni (w sumie dość sporo urządzeń, bo poza starymi i nowymi serwerami, NASami, kilkunastoma switchami, UPSami routerami, centralką telefoniczą i CCTV robią się z tego trzy spore szafy). No i niestety jedno z dzieci, które przez chwilkę nie było pod opieką zafascynowało się migającymi lampkami i malutkim zachęcającymi czerwonymi przyciskami.
Śmieszne? Oj, nie bardzo.
"Pojedynczy punkt awarii"
Najprościej jak można by to opisać - pojedynczy element infrastruktury (serwer, przełącznik sieciowy, okablowanie), serwis / usługa (DNS, DHCP, SQL), których awaria/wyłączenie powoduje spore problemy w działaniu biznesowym a gorszych sytuacjach efekt domina prowadzący do całkowitej katastrofy. Ja jeszcze dodaję do jednego worka (co nie jest zbyt popularne) czynnik ludzki - np. dla mnie takim "SPOFem" było odejście głównego administratora 2be.pl. Jak ja rozumiem zminimalizowanie efektu SPOF od strony czysto technicznej - po wejściu do serwerown można:
[item]wypiąć dowolny jeden kabel zasilający (w teorii większość porządnych urządzeń ma dwa zasilacze, jeden może przejąć prądowo np. cały serwer),[/item][img=StorageReview-Dell-PowerEdge-R720-Power-Supplies]
[item]wypiąć z serwera kabel sieciowy (intefejsy w 'teamingu'),[/item][img=AOC-UG-I4]
[item]może "paść" dowolny switch (czuwa nad tym IS‑IS, SPB, OSPF - podwójne okablowanie, krzyżowe połączenia),[/item][img=221831]
[item]odłączyć serwer - drugi przejmie na siebie wszystkie wirtualne serwery "w locie" albo klaster na poziomie aplikacyjnym bez przestoju produkcyjnego.[/item][img=HV]
Może trywialny przykład z serwerem DHCP. Przychodzą pracownicy rano w poniedziałek, włączają komputery, które nie potrafią skorzystać z infrastruktury. Dla kilku maszyn nie jestem problemem podejść i ustawić to "ręcznie", ale w przypadku kilkuset, czy kilku tysięcy zaczyna być ciepło. Drugi przykład (znam to osobiście...), gdzie administrator WSUS nie zastosował się do wytycznych i wypchnął niewinnie wyglądającą łatkę na wszystkie stacje robocze, które po restarcie nie chciały już uruchamiać najważniejszej dla działania firmy aplikacji...
To oczywiście bardzo ogólnikowe podejście do tematu - w całość jeszcze mogą wchodzić UPSy, agregaty prądotwórcze, duplikacja na poziomie całych serwerowni, czy nawet miast no i procedury.
Czy zmniejsza to możliwość awarii? Wręcz przeciwnie - skutecznie zwiększa. Kilkadsiesiąt dysków, kabli, switchy, skomplikowanych konfiguracji. Awaria jednak nie oznacza w tym przypadku przestoju całej infrastruktury. Kolejny problem to oczywiście koszt - dobrze przemyślane środowisko jest często poza zasięgiem finansowym. Nie oznacza to jednak, że nie można chociaż usunąć kilka punktów zapalnych. Najpowszechniejszcze są macierze dyskowe RAID1/RAID5, czy dwa zasilacze w serwerze. Życie ułatwia też wirtualizacja i np. hybryda z chmurą (np. Azure, usługi Amazonu i podobne).
Najsłabsze ogniwo
Jest jeszcze jeden typu SPOF, ten najgorszy - o którym wszyscy wiedzą, ale boją się głośno mówić.... taki "sam wiesz kto" jak w Harrym Pottere. Nie ważne, czy jest to 10‑osobowa firma, czy korporacja z wielomilionowym budżetem. On tam siedzi i może uczynić zniszczenia i poważne straty finansowe. Taki koszmarek pojawiający się w snach lokalnego administratora, albo zewnętrznej firmy zarządzajacej IT. Taka stara wyschnięta kocia kupa, która po ruszeniu może zacząć wyjątkowo śmierdzieć - stary, 10Mbit hub z zasilaczem 0.5A, który po wyłączeniu w kilka minut blokuje całą sieć. Wielokrotne próby wymiany na inny model, lub zwykłego pominięcia go nie przynoszą skutku. Musi być KONRETNIE TO URZĄDZENIE. Może to być stara aplikacja napisania przez pana Henia. Program działa nieprzerwanie i bezbłędnie od 25 lat a jedyna możliwość uruchomienia go na komputerach klienckich to sztuczki z wirtualizacją (XP‑Mode i inne vApp). Trzy firmy próbowały już go przepisać i wdrożyć, ale bezskutecznie - gdyby nastąpiła awaria bazy danych, to nikt nie potrafi tego naprawić z prostego wzblędu, że pan Heniek ostatnie dwa lata spędził na Powązkach w Warszawie, albo na Osobowicach we Wrocławiu.
Podsumowanie
Wyliminowanie SPOF jest bardzo trudne, głównie ze względów finansowych i organizacyjnych. Z IT i administracją systemami jest znany pewnie wielu z Was problem:
przecież działa od tylu lat dobrze, po co siać panikę?
Jak już jednak dochodzi do awarii, wszystkie oczy skupiają się na osobie odpowiedzialnej za infrastrukture i padają niewygodne pytania ("czy musiało do tego dojść? Jak można było zapobiec?").
Już kiedyś o tym wspominałem: jak to nie Twoja własna firma, należy mieć koniecznie podkładki: maile, dokumenty z wyszczególnieniem co się może wydarzyć i jakie są tego konsekwencje. Że np. zdobyć nowy kontroler RAID do 10‑letniego HP czwartej generacji będzie bardzo trudno, kupno nowego serwera zajmie kilka dni a uruchomienie starych aplikacji może być nawet niemożliwe.
* hipernadzorcy (hypervisor)- jak mnie to tłumaczenie śmieszy