Koszta, czyli wąż w kieszeni wcale nie musi być jadowity …

Teraz przedstawiam ostatnią część referatu dotyczącego budowaniu środowisk wysokodostępnych. Kolejne odcinki będą już dotyczyły Disaster Recovery. Zapraszam.

Koszta, czyli wąż w kieszeni wcale nie musi być jadowity …

    Pierwszym i podstawowym pytaniem jakie zadają sobie szefowie działów IT w dużych czy małych firmach jest: Ile rozwiązania wysoko dostępne kosztują? Faktem jest iż kosztują więcej niż środowiska całkowicie bez zabezpieczeń. Czasami kosztują aż dwukrotnie więcej, czasami nawet trzykrotnie więcej, czasami mniej, ta granica jest bardzo płynna. Aby precyzyjnie odpowiedzieć na pytanie czy firmie się to po prostu opłaca należało by dla każdego konkretnego przypadku wykonać szczegółową analizę w ramach analizy ryzyka operacyjnego istniejącego w firmie. Temat zarządzania ryzykiem znacznie wykracza poza ramy tego referatu w związku z czym skupimy się na bardzo ogólnej charakterystyce wymagań. Dla najprostszego przypadku potrzebować będziemy kilku danych, w tym kosztów jakie firma ponosi z tytułu przestoju/niedziałania usługi, wariantów kosztów związanych z różnymi poziomami zabezpieczeń jakie jesteśmy w stanie wdrożyć (może także w powiązaniu z prawdopodobieństwem wystąpienia różnych awarii przed którymi będziemy się zabezpieczać). Warto by także zorientować się jak wygląda sprawa z przeniesieniem odpowiedzialności/ryzyka związanego z awarią na podmiot trzeci, czyli po naszemu: ile kosztuje serwis. Teraz stosując kolejne uproszczenie analizy porównujemy koszta wdrożenia zabezpieczeń czy serwisu względem strat jakie poniesie firma jeśli by tych zabezpieczeń nie wdrożyła, w zakładanym okresie czasu. Dla bardziej dokładnych proponuję pobawić się w analizę z wykorzystaniem prawdopodobieństwa awarii wyliczonego z deklarowanych przez producentów MTBF (ang. Mean Time Between Failure) dla każdego z analizowanych komponentów.
Projektując naszą wysoko-dostępną infrastrukturę musimy pamiętać o następujących uwarunkowaniach: koszt zabezpieczenia usługi w przypadku farm balansowanych maleje wraz ze wzrostem ilości serwerów – poziom zabezpieczenia N+1. Dodatkowo przy przekroczeniu pewnej liczby serwerów w farmie (z doświadczenia powyżej 10) każdy z serwerów może być traktowany jako pojedyncza jednostka obliczeniowa która zapewnia redundancję jako całość, w związku z czym stosowanie dodatkowych zabezpieczeń w ramach takiego serwera nie jest uzasadnione. Mniejszym kosztem jesteśmy w stanie dostarczyć dodatkowy serwer niż ponosić koszta związane z zabezpieczeniem poszczególnych warstw infrastruktury. W tym wypadku nawet niewielkie oszczędności na pojedynczym serwerze należy przemnożyć w skali całej farmy. Z tego też powodu w takich warunkach najczęściej stosowane są serwery blade, zwane też kasetowymi. Serwery takie praktycznie nie mają możliwości rozbudowy a ilość dostępnych portów sieciowych czy kart IO spełnia minimalne akceptowalne wielkości. Całkowicie inaczej sprawa wygląda w przypadku klastrów systemowych, tutaj przy klasycznym podejściu projektowym koszt zabezpieczenia pojedynczej usługi może spokojnie przekroczyć dwukrotność kosztów środowiska bez zabezpieczeń. Taka architektura klastra opisywana jest jako active-standby i zazwyczaj zapewnia maksymalny poziom świadczenia usługi nie tylko ze względu na dostępność ale także ze względu na wydajność – drugi węzeł klastra w pełnej gotowości zwyczajnie czeka na jakieś problemy z głównym węzłem. W tym przypadku do pomocy przychodzą nam alternatywne możliwości wykorzystania klastra opisywane jako active-active czy wręcz architektura opisywana jako N+1. Opcje takie są interesujące z kilku powodów: jak pokazują statystyki średnie obciążenie serwerów UNIX waha się w okolicach 20%, w przypadku budowania kilku środowisk dla usług wysoko-dostępnych w klasycznym podejściu otrzymamy sporą ilość sprzętu oczekującego na awarię i generującego koszta zamiast zarobku, dodatkowo koszta administrowania klastra z jedną usługą klastrową są praktycznie takie same jak klastra z kilkoma usługami klastrowymi. Stąd już bardzo blisko do wniosku że zbudowanie klastra dla co najmniej dwóch usług klastrowych jest znacznie bardziej opłacalne niż budowanie dwóch oddzielnych środowisk klastrowych. Oczywiście dodatkowym kosztem w tym przypadku będzie potencjalne obniżenie wydajności usług klastrowych w przypadku wystąpienia awarii kiedy obie usługi będą okupowały jeden serwer. Z drugiej strony taka sytuacja nie powinna się zbyt często zdarzać więc potencjalne zyski powinny być spore (a jakie to powinniśmy wyliczyć w ramach wspomnianej analizy ryzyka operacyjnego). Jeśli jednak spadek wydajności w trakcie awarii jest nie do zaakceptowania to można pokusić się o wdrożenie klastra w architekturze N+1, czyli N serwerów aktywnych + 1 serwer standby. Dzięki temu koszta zbudowania takiego środowiska dla co najmniej dwóch usług klastrowych powinny być mniejsze niż w klasycznym podejściu, choć wyższe niż w przypadku active-active. Dzięki temu jeśli zdarzy się awaria jednego dowolnego węzła aktywnego to usługa klastrowa na nim działająca będzie w stanie ze 100% wydajnością pracować na jednym zapasowym serwerze. Architektura ta ma także wady: przełączenie dwóch usług klastrowych w jednym czasie na serwer zapasowy oznacza degradację wydajności (nie wspominając o większej ich liczbie), utrudnione jest także administrowanie takim klastrem, szczególnie kiedy ilość aktywnych węzłów klastra będzie większa, ma także niewidoczne na pierwszy rzut oka zalety: daje możliwość elastycznej rozbudowy mocy obliczeniowej klastra, gdzie rozbudowie podlegają wyłącznie: jeden węzeł aktywny klastra oraz węzeł zapasowy tylko w przypadku kiedy ma on niewystarczającą moc obliczeniową. W przypadku klastrów active-standby czy active-active rozbudowa musi być wykonana zawsze dla dwóch węzłów jednocześnie.

Wyższy poziom wtajemniczenia, czyli Disaster Recovery …

“I nadeszły te czasy kiedy usługi i aplikacje były ciągle dostępne. I pracowały bez wytchnienia dla dobra firm wszelakich. Aż nastał czas próby kiedy to jedyna serwerownia katastrofą została dotknięta i zastanowił się administrator czy aby nic już się nie dało zrobić?” – Ale o tym opowiemy już w następnym odcinku.

Radosław Korzeniewski