Kiedy Brak Redundancji Jest Bardziej Niezawodny – Mit Redundancji

Ryzyko to trudna koncepcja i wymaga dużo szkolenia, przemyśleń i analizy, aby właściwie ocenić dane scenariusze. Często, ponieważ oceny ryzyka są tak trudne, zastępujemy analizę ryzyka po prostu dodaniem podstawowej redundancji i zakładamy, że odpowiednio ograniczyliśmy ryzyko. Ale bardzo często tak nie jest. Wprowadzenie złożoności lub dodatkowych trybów awarii często towarzyszy dodaniu redundancji, a te nowe formy awarii mogą dodać więcej ryzyka niż usunęła dodana redundancja. Systemy pamięci masowej są szczególnie podatne na tego rodzaju procesy decyzyjne, co jest niestety o tyle niekorzystne, że niewiele – jeśli w ogóle – systemów jest tak podatnych na awarie i tak ważnych do ochrony.

RAID jest doskonałym przykładem tego, gdzie brak całościowego myślenia o ryzyku może prowadzić do dziwnych decyzji. Jeśli przyjrzymy się niezbyt rzadkiemu scenariuszowi, zobaczymy, gdzie cel ochrony przed awarią dysku może faktycznie prowadzić do wzrostu ryzyka, nawet gdy dodana zostaje redundancja. W tym scenariuszu porównamy macierz dwunastu dysków składającą się z dwunastu trzyterbajtowych dysków twardych SATA w jednej macierzy. Nierzadko można usłyszeć o ludziach wybierających RAID 5 dla tego scenariusza, aby uzyskać “maksymalną pojemność i wydajność” przy “odpowiedniej ochronie przed awariami”.

Chodzi o to, że RAID 5 chroni przed utratą jednego dysku, który można wymienić, a macierz odbuduje się, zanim drugi dysk ulegnie awarii. Świetnie w teorii, ale rzeczywiste ryzyko macierzy tej wielkości – trzydziestu sześciu terabajtów pojemności dysków – nie pochodzi z wielokrotnych awarii dysków, jak zazwyczaj podejrzewamy, lecz z niemożności niezawodnego odbudowania macierzy po awarii jednego dysku lub z awarii samej macierzy bez awarii żadnego dysku. Ryzyko awarii drugiego dysku jest niskie – nie zerowe, ale dość niskie. Dyski są dziś bardzo niezawodne. Gdy jeden dysk ulegnie awarii, zwiększa prawdopodobieństwo awarii drugiego, co jest dobrze udokumentowane, ale nie chcę, aby to ryzyko odwróciło naszą uwagę od prawdziwych zagrożeń – ryzyka nieudanej operacji resilvering.

Co nas przeraża podczas operacji resilvering RAID 5 to to, że może wystąpić nieodwracalny błąd odczytu (URE). Gdy tak się stanie, operacja resilvering zatrzymuje się i macierz pozostaje w bezużytecznym stanie – wszystkie dane na macierzy są tracone. Na typowych dyskach SATA wskaźnik URE wynosi 10^14, czyli raz na każde dwanaście terabajtów operacji odczytu. Oznacza to, że sześcioterabajtowa macierz podczas resilvering ma mniej więcej pięćdziesięcioprocentową szansę na trafienie URE i awarię. Pięćdziesięcioprocentowe prawdopodobieństwo awarii jest niesamowicie wysokie. Wyobraź sobie, że twój samochód miałby pięćdziesięcioprocentową szansę na odpadnięcie kół za każdym razem, gdy nim jedziesz. Tak więc przy małej (jak na dzisiejsze standardy) sześcioterabajtowej macierzy RAID 5 z dyskami SATA o URE 10^14, jeśli stracimy jeden dysk, mamy tylko pięćdziesięcioprocentową szansę na odbudowanie macierzy, zakładając natychmiastową wymianę dysku. Nie obejmuje to ryzyka awarii drugiego dysku – tylko ryzyko błędu URE. Zakłada też, że dyski są całkowicie bezczynne poza operacją resilvering. Jeśli dyski są intensywnie używane do innych zadań w tym samym czasie, szanse na wystąpienie czegoś złego – albo URE, albo awarii drugiego dysku – dramatycznie rosną.

Przy dwunastoterabajtowej macierzy szanse na całkowitą utratę danych podczas operacji resilvering zaczynają zbliżać się do stu procent – co oznacza, że RAID 5 nie ma w takim przypadku żadnej funkcjonalności. Zawsze istnieje szansa na przeżycie, ale jest bardzo mała. Przy sześciu terabajtach możesz porównać operację resilvering do rosyjskiej ruletki z jedną kulą i sześcioma komorami, gdzie musisz pociągnąć za spust trzy razy. Przy dwunastu terabajtach musisz pociągnąć sześć razy! To złe szanse.

Ale nie mówimy o dwunastoterabajtowej macierzy. Mówimy o trzydziestosześcioterabajtowej macierzy – która brzmi dużo, ale to rozmiar, który ktoś mógłby mieć dziś nawet w domu, nie mówiąc już o firmie. Każdy główny producent serwerów, a także niemal wszyscy tani dostawcy pamięci masowej, produkuje systemy pamięci masowej poniżej 10 000 dolarów w tym zakresie pojemności. Resilvering macierzy RAID 5 z awarią jednego dysku na macierzy trzydziestosześcioterabajtowej jest jak rosyjska ruletka z jedną kulą, sześcioma komorami i pociągnięciem za spust osiemnaście razy! Twoje dane nie mają wielu szans. Do tego dochodzi niesamowita ilość czasu potrzebna do resilvering macierzy tej wielkości, a ryzyko awarii drugiego dysku w trakcie tego okna resilvering zaczyna być dość znaczącym zagrożeniem. Widziałem szacunki czasu resilvering sięgające tygodni lub miesięcy na niektórych systemach. To długi czas bez możliwości utraty kolejnego dysku. Gdy mówimy o godzinach lub dniach, ryzyko jest dość niskie, ale wciąż obecne. Gdy mówimy o tygodniach lub miesiącach nieprzerwanej eksploatacji – a operacje resilvering są niezwykle intensywne dla dysków – wskaźniki awarii drastycznie rosną.

Przy macierzy tej wielkości możemy praktycznie założyć, że utrata jednego dysku oznacza utratę całej macierzy, nie pozostawiając nam żadnej ochrony przed awarią dysków. Jeśli teraz spojrzymy na dysk o tej samej lub lepszej wydajności i tej samej lub lepszej pojemności w RAID 0, który również nie zapewnia ochrony przed utratą dysku, musimy użyć tylko jedenastu z tych samych dysków, których potrzebowalibyśmy dwunastu dla naszej macierzy RAID 5. Oznacza to, że zamiast dwunastu dysków twardych, z których każdy ma mniej więcej trzyprocentowe roczne prawdopodobieństwo awarii, mamy tylko jedenaście. Samo w sobie sprawia to, że nasza macierz RAID 0 jest bardziej niezawodna, bo jest mniej dysków, które mogą ulec awarii. Nie tylko mamy mniej dysków, ale nie ma potrzeby zapisywania bloku parytetu ani pomijania bloków parytetu przy odczycie, co nieznacznie zmniejsza mechaniczne zużycie macierzy RAID 0 przy tym samym obciążeniu, dając jej bardzo nieznaczną dodatkową przewagę w niezawodności. Macierz RAID 0 z jedenastu dysków będzie identyczna pod względem pojemności jak dwunastodyskowa macierz RAID 5, ale będzie miała nieco lepszą przepustowość i opóźnienia. Samo w sobie jest to korzyść. Plus oszczędność kosztów braku potrzeby dodatkowego dysku.

Widzimy więc, że w dużych macierzach (dużych pod względem pojemności, nie liczby dysków) RAID 0 faktycznie wyprzedza RAID 5 w pewnych scenariuszach. Przy użyciu typowych dysków SATA dzieje się to przy pojemnościach doświadczanych nawet przez zaawansowanych użytkowników domowych i wiele małych firm. Jeśli przejdziemy na korporacyjne dyski SATA lub dyski SAS, pojemność, przy której to następuje, staje się bardzo duża i nie jest dziś problemem, ale będzie za kilka lat, gdy pojemności dysków jeszcze wzrosną. Podkreśla to jednak, jak niebezpieczny jest RAID 5 w rozmiarach, z którymi mamy dziś do czynienia. Każdy rozumie niesamowite ryzyko RAID 0, ale może być trudno uświadomić sobie, że problemy RAID 5 są tak ekstremalne, że może być faktycznie mniej niezawodny niż RAID 0.

To, że RAID 5 może być mniej niezawodny niż RAID 0 w macierzy tej wielkości wyłącznie na podstawie operacji resilvering, to tylko początek. W tak dużej macierzy czas resilvering może trwać tak długo i tak bardzo obciążać dyski, że awaria drugiego dysku zaczyna być mierzalnym ryzykiem. A potem są dodatkowe ryzyka spowodowane błędami kontrolera macierzy, które mogą wykorzystywać algorytmy resilvering do zniszczenia całej macierzy, nawet gdy żaden dysk nie uległ awarii. Ponieważ RAID 0 (ani RAID 1 czy RAID 10) nie mają algorytmów resilvering, nie cierpią z tego dodatkowego powodu. To są trudne do skwantyfikowania ryzyka, ale ważne jest, że są to dodatkowe ryzyka, które narastają przy użyciu bardziej złożonego systemu, gdy prostszy system – bez redundancji – był od początku bardziej niezawodny.

Teraz, gdy ustaliliśmy, że RAID 5 może być mniej niezawodny niż RAID 0, wskażę oczywiste niebezpieczeństwa RAID 0. RAID ogólnie jest używany do zmniejszenia ryzyka awarii jednego, samotnego dysku twardego. Wszyscy obawiamy się, że pojedynczy dysk po prostu ulegnie awarii i wszystkie dane zostaną utracone. RAID 0, będąc dużym stripem dysków bez żadnej formy redundancji, bierze ryzyko utraty danych z awarii pojedynczego dysku i mnoży je przez liczbę dysków, gdzie awaria któregokolwiek dysku powoduje całkowitą utratę danych na wszystkich dyskach. W naszym przykładzie z jedenastu dyskami, jeśli którykolwiek z jedenastu dysków ulegnie awarii, wszystko przepada. Jasno widać, że jest to dramatycznie bardziej niebezpieczne niż używanie pojedynczego dysku.

Staram się tu wskazać, że redundancja nie oznacza niezawodności. To, że coś jest redundantne, jak RAID 5, nie gwarantuje, że zawsze będzie bardziej niezawodne niż coś, co redundantne nie jest.

Moja ulubiona analogia to domy podczas tornada. W pierwszym scenariuszu budujemy dom z cegły i zaprawy. W drugim scenariuszu budujemy dwa redundantne domy, każdy ze słomy (nasi budowniczowie to widocznie świnie). Gdy nadejdzie tornado (lub wielki zły wilk), który dom ma większą szansę przetrwania? Wyraźnie jeden murowany dom ma istotne zalety w niezawodności nad redundantnymi domami ze słomy. Redundancja nie miała znaczenia – w końcu liczyła się niezawodność.

Redundancja często wprowadza w błąd, ponieważ jest łatwa do skwantyfikowania, ale trudna do jakościowej oceny. Redundancja to pytanie czarno-białe: Czy jest redundantna? Tak lub nie. Proste. Niezawodność nie jest tak prosta. Niezawodność dotyczy wskaźników awarii i prawdopodobieństw. Chodzi o statystyki i analizę. Ponieważ trudno jest skwantyfikować niezawodność w sensowny sposób – szczególnie przy sprzedaży projektu osobom z biznesu – redundancja często staje się prostym substytutem tego złożonego pojęcia.

Koncepcja używania redundancji do przekierowania pytań o niezawodność kończy się zastosowaniem do podsystemów w bardzo zawiłych sposób. Zamiast uczynić “system” redundantnym, powszechne stało się uczynienie wysoce niezawodnego i taniego podsystemu redundantnym i traktowanie redundancji podsystemu jako odnoszącej się do całego systemu. Najpowszechniejszym przykładem są kontrolery RAID w produktach SAN. Zamiast posiadać redundantny SAN (oznaczający dwa SANy), producenci często czynią redundantnym ten jeden komponent, który nie jest często redundantny w normalnych serwerach, a następnie nazywają SAN redundantnym – co oznacza SAN zawierający redundancję, co wcale nie jest tym samym.

Dobra analogia to porównanie posiadania redundantnych samochodów, czyli dwóch kompletnych, działających samochodów, z posiadaniem jednego samochodu z zapasową pompą wody w bagażniku na wypadek awarii głównej. Wyraźnie zapasowa pompa wody nie jest złą rzeczą. Ale jest to trywialna ilość ochrony przed awarią samochodu w porównaniu z posiadaniem drugiego gotowego do drogi. W jednym przypadku cały system jest redundantny, włącznie z nadwoziem. W drugim czynimy redundantnym tylko jeden, wysoce niezawodny komponent wewnątrz nadwozia. To nawet nie jest porównywalne z posiadaniem zapasowej opony, która przynajmniej jest komponentem samochodu z wyższym prawdopodobieństwem awarii.

Podobnie jak mit niezawodności RAID 5 i niezawodność systemu/podsystemu, technologie współdzielonej pamięci masowej, takie jak SAN i NAS, są często traktowane w ten sam sposób, szczególnie w odniesieniu do wirtualizacji. Istnieje typowy scenariusz, w którym podejmowany jest projekt wirtualizacji i ludzie instynktownie wpadają w panikę, ponieważ pojedynczy host wirtualizacji stanowi pojedynczy punkt awarii (SPOF), a jego awaria może spowodować jednoczesną awarię wielu systemów.

Używanie terminu “pojedynczy punkt awarii” wywołuje uczucie paniki i jest świetnym sposobem na kierowanie rozmową. Ale SPOF, jak lubimy go nazywać, choć chcemy go eliminować gdy to możliwe, może nie być końcem świata. Pomyśl o naszym murowanym domu. To SPOF. Nasze dwa domy ze słomy nie są. Jednak jeden podmuch wiatru niszczy nasze redundantne rozwiązania szybciej niż nasz niezawodny SPOF. Szukanie SPOF-ów to świetny sposób na znalezienie punktów kruchości w systemie, ale nie trzeba uważać, że każdy SPOF musi być redundantny w każdym scenariuszu. Większość firm znajdzie najlepszą wartość, mając wiele SPOF-ów w miejscu. Naszym prawdziwym celem jest niezawodność przy odpowiednim koszcie; redundancja, jak widzieliśmy, nie jest substytutem niezawodności – to po prostu narzędzie, którego możemy użyć do osiągnięcia niezawodności.

Teoria, którą wielu ludzi stosuje przy wirtualizacji, jest taka, że biorą swój host wirtualizacji i mówią: “Ten host to SPOF, więc muszę mieć dwa z nich i używać funkcji High Availability, aby umożliwić transparentny failover!” Jest to podsycane przez wiodącego dostawcę wirtualizacji, który zarabia przede wszystkim na sprzedaży drogich dodatków HA, a po drugie jest własnością dużego dostawcy pamięci masowej – więc sprzedaż niepotrzebnej lub wręcz niebezpiecznej dodatkowej współdzielonej pamięci masowej jest dla nich wielką korzyścią finansową i mogłaby być łatwo powodem, dla którego od początku wspierali przestrzeń wirtualizacji. Redundantne hosty wirtualizacji ze współdzieloną pamięcią masową brzmią świetnie, ale mogą być niezwykle błędne z kilku powodów.

Pierwszym powodem jest to, że wyeliminowanie początkowego SPOF – hosta wirtualizacji – zostaje zastąpione nowym SPOF – współdzieloną pamięcią masową. To nic nie daje. Zakładając, że używamy porównywalnej jakości serwerów i współdzielonej pamięci masowej, zrobiliśmy tylko tyle, że przenieśliśmy ryzyko, nie zmieniliśmy jego wielkości. Prawdopodobieństwo awarii systemu pamięci masowej jest mniej więcej równe prawdopodobieństwu awarii oryginalnego serwera. Ale oprócz przesuwania SPOF jak w grze w trzy karty, zrobiliśmy coś znacznie, znacznie gorszego – wprowadziliśmy łańcuchowe lub kaskadowe zależności awaryjne.

W naszym oryginalnym scenariuszu mieliśmy jeden serwer. Jeśli serwer działał, byliśmy bezpieczni; jeśli zawiódł, nie byliśmy. Proste. Teraz mamy dwa hosty wirtualizacji, jeden serwer pamięci masowej (SAN, NAS, cokolwiek) i sieć łączącą je ze sobą. Już ustaliliśmy, że ryzyko awarii współdzielonej pamięci masowej jest mniej więcej równe całkowitemu ryzyku systemu w oryginalnym scenariuszu. Ale teraz mamy dodatkowe zależności od sieci i dwóch front-end węzłów wirtualizacji. Każdy z tych komponentów jest bardziej niezawodny niż krucha współdzielona pamięć masowa (wszystko z dyskami mechanicznymi będzie kruche), ale to, że mają niższe ryzyko, nie jest problemem; problemem jest to, że ryzyka sumują się.

Jeśli którykolwiek z tych trzech komponentów (pamięć masowa, sieć lub front-end węzły) ulegnie awarii, wszystko zawodzi. Rozwiązaniem jest uczynienie współdzielonej pamięci masowej redundantną samą w sobie i uczynienie sieci redundantną samą w sobie. Przy wystarczającej pracy możemy pokonać kruchość i ryzyko, które wprowadziliśmy dodając współdzieloną pamięć masową, ale sama współdzielona pamięć masowa nie jest formą mitygacji ryzyka – jest sama w sobie ryzykiem, które musi być mitygowane. Spirala złożoności się zaczyna, a koszty związane z doprowadzeniem tego nowego systemu do parytetu niezawodności z oryginalnym systemem z jednym serwerem mogą być astronomiczne.

Teraz, gdy mamy całą tę redundancję, mamy jeszcze jedno ryzyko do martwienia się. Zarządzanie całą tą redundancją, wszystkimi tymi ruchomymi częściami, wymaga znacznie więcej wiedzy, umiejętności i przygotowania niż zarządzanie prostym, pojedynczym serwerem. Przeszliśmy od prostego rozwiązania do bardzo złożonego. W moim własnym anegdotycznym doświadczeniu prawdziwe niebezpieczeństwa takich rozwiązań nie pochodzą z awarii sprzętu, lecz z błędu ludzkiego. Nie tylko niewiele zrobiono, aby uniknąć błędu ludzkiego powodującego awarię tego nowego systemu, ale dodaliśmy niezliczone punkty, gdzie człowiek mógłby przypadkowo doprowadzić do awarii całego systemu – redundancji i wszystkiego. Sam to widziałem; słyszałem przerażające historie. Im bardziej złożony system, tym bardziej prawdopodobne, że człowiek przypadkowo wszystko zepsuje.

Kluczowe jest, aby jako specjaliści IT cofnąć się i spojrzeć na kompletne systemy oraz rozważyć niezawodność i ryzyko, traktując redundancję po prostu jako narzędzie do osiągnięcia niezawodności. Redundancja sama w sobie nie jest panaceum. Ani prostota. Niezawodność to złożony problem do rozwiązania. Unikanie uproszczonych zastępstw to ważny pierwszy krok w przejściu od ukrywania problemów z niezawodnością do ich stawiania czoła i rozwiązywania.