Najsłabsze ogniwo: jak zależności łańcuchowe wpływają na ryzyko systemowe

Oceniając scenariusze ryzyka systemowego, bardzo łatwo przeoczyć zależności "łańcuchowe". Jesteśmy przyzwyczajeni do patrzenia na ryzyko na poziomie "węzła", pytając "jak prawdopodobne jest, że ten jeden element zawiedzie". Ale ryzyko systemowe jest znacznie bardziej skomplikowane.

W większości systemów niektóre komponenty są zależne od innych komponentów. Najczęściej patrzymy na to przy projektowaniu storage dla serwerów, ale dotyczy to każdego projektu systemu. Innym dobrym przykładem jest to, jak aplikacje webowe potrzebują zarówno hostów aplikacyjnych, jak i hostów baz danych, aby funkcjonować.

Najłatwiej wyjaśnić zależności łańcuchowe na przykładzie. Przyjrzymy się standardowemu projektowi wirtualizacji z pamięcią masową SAN, aby zrozumieć, gdzie istnieją granice domen awarii, gdzie istnieją zależności łańcuchowe i jaką rolę odgrywa redundancja w ograniczaniu ryzyka na poziomie systemu.

W standardowym projekcie SAN (sieci pamięci masowej) dla wirtualizacji mamy hosty wirtualizacyjne (które dla uproszczenia nazwiemy "serwerami"), przełączniki SAN (przełączniki dedykowane dla sieci storage) i same macierze dyskowe. Każda z tych trzech "warstw" jest zależna od pozostałych, aby system jako całość mógł funkcjonować. Gdybyśmy mieli najprostszy możliwy zestaw z jednym serwerem, jednym przełącznikiem i jedną macierzą dyskową, mamy wyraźnie trzy urządzenia reprezentujące trzy odrębne punkty awarii. Awaria któregokolwiek z trzech powoduje awarię całego systemu. Żaden z elementów nie jest użyteczny sam w sobie. Jest to zależność łańcuchowa, a łańcuch jest tak silny, jak jego najsłabsze ogniwo.

W naszym uproszczonym przykładzie każde urządzenie reprezentuje domenę awarii. Możemy zmniejszać ryzyko, poprawiając niezawodność każdej domeny. Możemy dodać drugi serwer i wdrożyć strategię wysokiej dostępności lub tolerancji błędów warstwy wirtualizacji, aby zmniejszyć ryzyko awarii serwera. To poprawia niezawodność jednej domeny awarii, ale pozostawia dwie bez zmian i równie ryzykowne jak wcześniej. Następnie możemy zająć się warstwą przełączania, dodając redundantny przełącznik i konfigurując strategię multipathing, aby obsłużyć utratę jednej ścieżki przełączania, zmniejszając ryzyko na tej warstwie. Teraz dwie domeny awarii zostały zaadresowane. Na koniec musimy zająć się domeną awarii storage, co jest realizowane podobnie przez dodanie redundancji poprzez drugą macierz dyskową, mirrorowaną do pierwszej i zdolną do przełączenia awaryjnego w przypadku awarii.

Teraz, gdy wzmocniliśmy nasz system, nadal mamy trzy domeny awarii w łańcuchu zależności. To, co zrobiliśmy, to uczynienie każdego "ogniwa" w łańcuchu, każdej domeny awarii, bardziej odpornym na własną rękę. Ale łańcuch nadal istnieje. Oznacza to, że system jako całość jest znacznie mniej niezawodny niż jakakolwiek pojedyncza domena awarii w łańcuchu sama w sobie. Stworzyliśmy coś znacznie lepszego niż na początku, ale nadal mamy wiele domen awarii. Te ryzyka sumują się.

Trudnością w określaniu ogólnego ryzyka jest to, że musimy ocenić ryzyko każdego elementu, następnie określić nowe ryzyko po ograniczeniu (poprzez dodanie redundancji), a następnie znaleźć skumulowane ryzyko każdej z domen awarii razem w łańcuchu, aby określić całkowite ryzyko całego systemu. Niezwykle trudno jest określić ryzyko w każdej domenie awarii, ponieważ sposób ograniczania ryzyka odgrywa znaczącą rolę. Na przykład klaster macierzy dyskowych, który przełącza się awaryjnie zbyt wolno, może spowodować ogólną awarię systemu, nawet gdy sam klaster storage wydaje się działać poprawnie. Nawet zdefiniowanie wyraźnej awarii może być zatem trudne.

Często kuszące jest dokonanie oceny ryzyka z perspektywy "odgórnej", co jest bardzo niebezpieczne, ale bardzo powszechne dla osób, które nie są regularnymi praktykami oceny ryzyka. Tendencja tutaj polega na patrzeniu na ryzyko jedynie przez pryzmat "najwyższej" domeny awarii – generalnie serwerów w takim przypadku – i ignorowaniu wszelkich ryzyk poniżej tego punktu, uznając je za "pod maską", a nie za część oceny ryzyka. Łatwo jest ignorować bardziej techniczne, mniej widoczne i gorzej rozumiane komponenty, takie jak sieci i storage, i skupiać się na stosunkowo łatwych do zrozumienia i intensywnie promowanych aspektach niezawodności warstwy najwyższej. Ten "widok odgórny" oznacza, że ryzyka pod poziomem najwyższym są zasłonięte i generalnie ignorowane, prowadząc do wysokiego ryzyka bez dobrego zrozumienia dlaczego.

Zrozumienie koncepcji zależności łańcuchowych wyjaśnia, dlaczego złożone systemy, nawet ze złożonymi strategiami ograniczania ryzyka, często okazują się znacznie bardziej kruche niż prostsze systemy. W naszym powyższym przykładzie moglibyśmy zrobić kilka rzeczy, aby "zwinąć" łańcuch, co skutkuje bardziej niezawodnym systemem jako całością.

Najbardziej oczywistym komponentem, który można zwinąć, jest domena awarii sieci. Gdybyśmy usunęli przełączniki całkowicie i podłączyli storage bezpośrednio do serwerów (nie zawsze możliwe, oczywiście), efektywnie wyeliminowalibyśmy jedną całą domenę awarii i usunęli ogniwo z naszego łańcucha. Teraz zamiast trzech łańcuchów, każdy z pewnym potencjałem awarii, mamy tylko dwa. Prostsze jest lepsze, przy wszystkich innych czynnikach równych.

Moglibyśmy, teoretycznie, również zwinąć domenę awarii storage, przechodząc z zewnętrznego storage na storage lokalny dla samych serwerów, efektywnie przechodząc z dwóch domen awarii do jednej – ta pozostała domena, oczywiście, niesie więcej złożoności niż przed zwinięciem, ale ogólna złożoność systemu jest znacznie zmniejszona. Ponownie, przy wszystkich innych czynnikach pozostających równymi.

Innym podejściem do rozważenia jest uczynienie pojedynczych węzłów bardziej niezawodnymi samymi w sobie. Dziś jest modne patrzeć na większe systemy i podchodzić do ograniczania ryzyka w ten sposób, dodając redundantne, tanie węzły, aby dodać niezawodność domeną awarii. Ale tradycyjnie nie była to domyślna ścieżka do niezawodności. Znacznie powszechniejsze było w przeszłości, jak pokazuje dawna przewaga mainframe'ów i podobnych klasy systemów, budowanie wysokiego stopnia niezawodności w jeden węzeł. Mainframe'y i wysokiej klasy systemy storage, na przykład, nadal to robią. Może to być faktycznie niezwykle skuteczne podejście, ale nie radzi sobie z wieloma scenariuszami i jest zazwyczaj niezwykle kosztowne, często wzmacniane potrzebą częściowego lub nawet całkowitego utrzymania systemów przez dostawcę. Działa to zazwyczaj tylko w specjalnych niszowych okolicznościach i nie jest praktyczne w szerszym zakresie.

Zatem w każdym systemie tego rodzaju mamy trzy kluczowe strategie ograniczania ryzyka do rozważenia: poprawę niezawodności pojedynczego węzła, poprawę niezawodności jednej domeny lub zmniejszenie liczby domen awarii (ogniw) w łańcuchu zależności. Łączenie ich w sposób odpowiedni może pomóc nam osiągnąć poziom ograniczenia ryzyka odpowiedni dla naszego scenariusza biznesowego.

Prawdziwa trudność istnieje i będzie pozostawać w porównywaniu różnych strategii ograniczania ryzyka. Ryzyko pojedynczego węzła można generalnie szacować z pewnym stopniem pewności. Strategia redundancji w ramach jednej domeny ma znacznie mniejszą zdolność do oszacowania – niektóre strategie redundancji są wysoce skuteczne, tworząc niezwykle niezawodne domeny awarii, podczas gdy inne mogą faktycznie przynieść odwrotny skutek i zmniejszyć niezawodność domeny! Złożoność, która często towarzyszy strategiom redundancji, nigdy nie jest bez zastrzeżeń i choć zazwyczaj się opłaca, rzadko niesie stopień korzyści w niezawodności, który jest początkowo oczekiwany. Szacowanie ryzyka łańcucha zależności jest zatem jeszcze trudniejsze, ponieważ wymaga jasnego zrozumienia ryzyk związanych z każdą z domen awarii indywidualnie, a także zrozumienia możliwości awarii istniejącej na granicach domen (jak wspomniana wcześniej awaria opóźnienia przełączenia awaryjnego storage).

Przyjrzyjmy się kwestiom związanym z określaniem ryzyka w dwóch bardzo powszechnych podejściach do tego samego scenariusza, bazując na tym, co omówiliśmy powyżej.

Dwa skrajne przykłady tej samej sytuacji, którą omawialiśmy, to pojedynczy serwer z wewnętrznym storage używany do hostowania maszyn wirtualnych kontra sześciourządzeniowy "łańcuch" z dwoma serwerami i rozwiązaniem wysokiej dostępności na warstwie serwera, dwoma przełącznikami z redundancją na warstwie przełączania i dwiema macierzami dyskowymi zapewniającymi wysoką dostępność na warstwie storage. Jeśli zmienimy dowolny duży czynnik, możemy zazwyczaj dać dość wyraźne oszacowanie względnego ryzyka – jeśli którakolwiek z domen awarii nie ma niezawodnej redundancji, na przykład – możemy dość wyraźnie stwierdzić, że pojedynczy serwer jest ogólnie bardziej niezawodnym systemem, z wyjątkiem przypadków, gdy do pojedynczego węzła przypisana jest ekstremalna ilość niezawodności na poziomie węzła, co jest zazwyczaj niepraktyczną strategią finansowo. Ale przy każdej domenie awarii utrzymującej redundancję jesteśmy zmuszeni porównywać względne ryzyka niezawodności wewnątrzdomeny (łańcuch redundantny) z niezawodnością między domenami (zwinięty łańcuch, pojedynczy serwer).

Przy dwóch zupełnie różnych podejściach nie ma rozsądnego sposobu oceny porównawczego ryzyka dwóch środków ograniczania ryzyka. Ogólnie przyjmuje się, że podejście sześcio- (lub więcej) węzłowe z rozbudowanym ograniczaniem ryzyka wewnątrzdomenowego jest bardziej niezawodne i prawie na pewno jest to, generalnie, prawda. Ale nie zawsze jest to prawda i rzadko to podejście przewyższa strategię pojedynczego węzła o naprawdę znaczący margines, podczas gdy powszechnie kosztuje cztery do dziesięciu razy więcej niż strategia z pojedynczym serwerem. Jest to potencjalnie bardzo wysoki koszt za to, co jest prawdopodobnie małym zyskiem w niezawodności i małym potencjalnym ryzykiem utraty niezawodności. Każdy dodatkowy element redundancji dodaje złożoność, którą człowiek musi wdrożyć, monitorować i utrzymywać, a ze złożonością i interakcją ludzką wiąże się coraz więcej ryzyka. Unikanie błędów ludzkich może być często ważniejsze niż unikanie awarii mechanicznych.

Musimy również wziąć pod uwagę koszt odtworzenia. Jeśli dojdzie do awarii, zazwyczaj jest trywialne odtworzenie po awarii prostego systemu. Niezwykle złożony system, który uległ awarii, może wymagać dużego wysiłku, aby przywrócić go do stanu roboczego. Złożone systemy wymagają również znacznie szerszego i głębszego doświadczenia i pewności do utrzymania.

Nie ma łatwej odpowiedzi na określanie niezawodności systemów. Nowoczesne systemy dostarczania informacji są po prostu zbyt duże i zbyt złożone, z zbyt wieloma nieokreślonymi czynnikami, aby można je było oceniać we wszystkich przypadkach. Dzięki dobremu zrozumieniu zależności łańcuchowych jednak i zrozumieniu strategii ograniczania ryzyka możemy podejmować praktyczne kroki w celu określenia w przybliżeniu względnych poziomów ryzyka, zobaczyć, gdzie podobne scenariusze ryzyka porównują się pod względem kosztów, zidentyfikować punkty kruchości, rozpoznać domeny awarii i łańcuchy zależności oraz docenić, jak zmiany w projekcie systemu wyraźnie przybliżą nas do lub oddalą od niezawodności.