Dlaczego (geo) Erasure Coding nie jest lekiem na wszystko?

Czy myślisz, że ktoś się jeszcze zastanawia nad tym, jakim modelem RAID zabezpieczyć dyski twarde w macierzy? Jakiś plan na pewno trzeba mieć w tym zakresie. Ale z doświadczenia widzę, że nie pochłania to już aż tyle energii, jak to miało miejsce jeszcze pięć lat temu i wcześniej. Pamiętam czasy, kiedy dobór najwłaściwszego modelu RAID był jednym z ważniejszych kroków w procesie szacowania wydajności podsystemu dyskowego macierzy. Co oznacza „najwłaściwszego”? Chodziło (i nadal chodzi) o to, aby spełnił on wymagania wydajnościowe oraz pojemnościowe i jednocześnie był najlepszym wyborem z ekonomicznego punktu widzenia. Oczywiście zarówno wtedy, jak i dzisiaj, najłatwiej byłoby wykorzystać „10-tkę” (RAID-10). Tylko kogo na to stać?

Zaraz, zaraz. Ale przecież miałem pisać o Erasure Coding. Proszę Cię o chwilę cierpliwości. Pozwól, że mimo wszystko zacznę od początku. A na początku był RAID.

Jaki RAID? A może nie RAID, tylko Erasure Coding?

Obecnie zaprojektowanie właściwego podsystemu dyskowego, który spełni wymagania wydajnościowe aplikacji jest oczywiście również ważne. W ostatnich latach pojawiły się jednak takie technologie (wide striping, automatyczny tiering, dyski flash), które sprawiły, że raczej nie zadajemy już sobie pytania o to, czy „piątka” (RAID-5) będzie wystarczająco wydajna? Tak naprawdę nie pamiętam, kiedy ostatnio projektowałem podsystem dyskowy w macierzy, który uwzględniałby wykorzystanie modelu RAID-10. Owszem, „jedynka” (RAID-1) jest nadal często wykorzystywana do zabezpieczenia niewielkiej przestrzeni przeznaczonej na system operacyjny. I to najczęściej na dyskach wewnętrznych serwerów. Jednak w przypadku przestrzeni dyskowej dla aplikacji, w większości środowisk obecnie króluje RAID-5. Dlaczego? W porównaniu z innymi modelami RAID dostarcza największej przestrzeni efektywnej. Inaczej mówiąc, z punktu widzenia pojemności po prostu jest najtańszy.

Ale co z tą wydajnością? Wartości parametrów SLO, które musimy dostarczyć i zagwarantować naszym aplikacjom są przecież jeszcze bardziej wymagające niż kiedyś. Czasy odpowiedzi najlepiej, gdyby zawsze dążyły do zera, a ilość operacji na sekundę i przepustowość – do nieskończoności. Dzisiaj po prostu tę wydajność dostarczamy w nieco inny sposób. A jeżeli Twoje aplikacje są nadal zainstalowane na dyskach zabezpieczonych modelem RAID-10, to chyba w którymś momencie coś poszło nie tak. 

Co ciekawe, RAID-5 w swojej popularności zaczyna być powoli doganiany przez RAID-6 (lub jego technologiczne odpowiedniki). Powód? Korzystamy z coraz większych dysków twardych. A to sprawia, że coraz dłużej trwa odbudowa grupy w przypadku awarii takiego dysku. Jestem przekonany, że nie muszę Ci tego tłumaczyć, ale zróbmy to dla porządku. Uszkodzenie jednego dysku w grupie RAID-5 oznacza, że cała nasza grupa staje się pojedynczym punktem awarii (SPOF – Single Point of Failure), który będziemy musieli zaakceptować na czas trwania odbudowy grupy. A w zależności od wielkości i rodzaju dysków może to być nawet do kilkunastu lub kilkudziesięciu godzin. Na ratunek przychodzi nam jednak RAID-6. Ten pozwala zabezpieczyć grupę na wypadek awarii nie jednego, ale dwóch dysków. To oznacza, że ryzyko utraty danych znacznie maleje, ale niestety kosztem wydajności. W tym również wydajności kontrolerów macierzowych, których procesory muszą liczyć dodatkowe sumy kontrolne (kody parzystości).

Mimo to, moim zdaniem można uznać, że „5-tka” oraz „6-stka” i wszystkie ich technologiczne odpowiedniki są dzisiaj najczęściej stosowanymi zabezpieczeniami dysków twardych w macierzach blokowych i plikowych. Ale na horyzoncie pojawia się również Erasure Coding (EC). Co ciekawe nie jest to absolutnie nic nowego na rynku. Postanowiłem trochę poszperać w Internecie i pierwsze artykuły, jakie udało mi się znaleźć na temat EC pochodzą z 2011 roku (a może Ty znajdziesz jeszcze starsze?). Ale chwileczkę. Erasure Coding jest przecież wykorzystywany także w rozproszonych systemach plików, na przykład w HDFSie (Hadoop Distributed File System), a początki Hadoop’a sięgają 2006 roku. Również usługi dostarczania pamięci masowej w chmurze publicznej „pod spodem” wykorzystują technologię EC jako jedno z zabezpieczeń przed utratą danych.

Praktycznie w każdym z powyżej opisanych przypadków (obiektowa pamięć masowa, rozproszone systemy plików i chmura publiczna) mówimy o naprawdę dużych przestrzeniach dyskowych oraz o wykorzystywaniu dysków o raczej dużych pojemnościach. Dla takich scenariuszy, EC okazuje się być efektywniejszy oraz bardziej niezawodny niż RAID. Czy to w związku z tym oznacza zmierzch technologii RAID? Moim zdaniem, niekoniecznie. Dla aplikacji i obciążeń, które wymagają wysokiej wydajności i krótkich czasów odpowiedzi, tradycyjny rodzaj zabezpieczenia RAID (i jego pochodne) są nadal najbardziej optymalnym rozwiązaniem. I aby pokazać Ci, dlaczego tak jest pozwól, że opowiem…

… jak działa Erasure Coding (EC) oraz jakie są jego wady i zalety.

Model zabezpieczenia EC jest opisywany w bardzo podobny sposób jak w przypadku grup RAID (np. 7+1, 6+2). Tutaj również wykorzystywana jest kombinacja dwóch liczb: m + n, które określają na ile fragmentów podzieliliśmy nasze dane (m) oraz ile dodatkowych kodów w grupie (n) zabezpiecza te dane przed awarią.  Weźmy przykład grupy EC, która działa w modelu 10+6:

Dane dzielone są tutaj na 10 fragmentów (od D1 do D10). A do nich dodawane są kody (od K1 do K6), które pozwalają na odzyskanie danych w przypadku utraty któregoś z fragmentów. W tym konkretnym przykładzie możemy „pozwolić sobie” na utratę (DL – Data Loss) do 6 fragmentów, znajdujących się na przykład na różnych dyskach twardych. To w takim przypadku oznacza, że możemy zaakceptować awarię nawet 6 dysków w naszej przykładowej grupie EC i nadal będziemy mieli dostęp do danych zapisanych w tej grupie. W przypadku technologii Erasure Coding można pójść o krok, a nawet o dwa kroki dalej:

• jeden krok dalej: fragmenty danych i dodatkowych kodów, które stanowią część tej samej grupy EC rozproszone są pomiędzy różnymi węzłami urządzenia, albo
• drugi krok dalej: pomiędzy różnymi urządzeniami, zainstalowanymi w różnych lokalizacjach.

Ten drugi przypadek na potrzeby artykułu nazwałem geo Erasure Coding (daj znać, jeżeli masz pomysł na lepszą, krótką nazwę). A ponieważ wiążą się z nim pewne „niebezpieczeństwa”, które należy wziąć pod uwagę podczas projektowania, dlatego wrócę do niego jeszcze w dalszej części artykułu.

Zanim jednak ruszymy dalej, kilka faktów na temat technologii Erasure Coding:

1. Po pierwsze. O ile w przypadku zabezpieczenia RAID-5 do liczenia kodów parzystości wykorzystywana jest logiczna funkcja XOR, to już w przypadku RAID-6 funkcja ta jest nieco bardziej skomplikowana i w niektórych rozwiązaniach „zahacza” również o kodowanie typu Reed-Solomon. To oznacza, że RAID-6 można uznać za jedną z form Erasure Coding.
2. Po drugie. Istnieją dwa podstawowe typy implementacji Erasure Coding:
   • implementacja typu Reed-Solomon – odnosząc się do wcześniejszego przykładu (EC 10+6), w tej implementacji jesteśmy w stanie zawsze odbudować grupę z każdej awarii nie więcej niż 6 dowolnych fragmentów,
   • drugi typ implementacji jest wydajniejszy (mniej odczytów podczas odbudowy), ale charakteryzuje się większym ryzykiem: tutaj możemy prawie zawsze odbudować grupę, z większości awarii nie więcej niż 6 fragmentów (ale nie z każdej awarii); inaczej mówiąc istnieją pewne zestawy „szóstek”, dla których nie da się odbudować grupy.
3. Po trzecie. Im większa ilość fragmentów w grupie EC k = m + n, tym bardziej skomplikowane obliczenia i tym większa moc obliczeniowa potrzeba do ich wykonania. Zwiększanie wartości m i n powoduje zwiększanie opóźnień oraz czasów odbudowy. Dlaczego? Mamy większą ilość fragmentów, którymi trzeba zarządzać. Fragmenty te są przechowywane w bazie danych, która musi być monitorowana w sposób ciągły. W dużej bazie danych, potrzeba więcej czasu na wyszukanie właściwego rekordu oraz „poskładanie” rekordów w kompletny obiekt.

Równanie k = m + n charakteryzuje się bardzo prostymi zależnościami:

• zwiększając wartość n, przy stałej wartości m, zwiększamy niezawodność,
• zwiększając wartość m, przy stałej wartości n, zmniejszamy niezawodność.

Stały, czy zmienny stripe size?

A to z kolei zależy od rodzaju rozwiązania, z którego korzystasz lub masz zamiar skorzystać. W przypadku jednej grupy urządzeń, dane (obiekty) dzielone są na fragmenty, których rozmiar dostosowuje się do rozmiaru całego obiektu. Metodologia ta ma jednak pewną słabość – nie radzi sobie najlepiej w przypadku obiektów o małych rozmiarach. Dlatego często w tych rozwiązaniach, aby nie dopuścić do zbyt dużych opóźnień dla obiektów o określonej wielkości (mniejszej niż), Erasure Coding jest zamieniany automatycznie na pełną replikę (mirror).

W rozwiązaniach z drugiej grupy stosowany jest stały rozmiar stripe. A dzięki temu można uniknąć problemów z wydajnością (tych opisanych wcześniej) oraz w efektywniejszy sposób wykorzystać dostępną przestrzeń.

Geo Erasure Coding. Zaczyna się robić ciekawie.

W tym przypadku mówimy o scenariuszu, w którym Erasure Coding jest realizowany pomiędzy geograficznie rozproszonymi urządzeniami. A w topologii EC uwzględnione są co najmniej dwa lub najlepiej więcej niż dwa urządzenia, zainstalowane w różnych ośrodkach (centrach danych). Każde z urządzeń udostępnia przestrzeń na prawach zarówno odczytu, jak i zapisu (active-active) i przechowuje albo całe obiekty (pełne kopie) albo fragmenty obiektów (to zależy od konfiguracji rozwiązania oraz często od wielkości obiektu).

W przypadku rozwiązań, które realizują geo Erasure Coding stosowane są zazwyczaj trzy scenariusze związane z tym, w jaki sposób obiekty są zapisywane i replikowane pomiędzy ośrodkami:

1. Opóźniony Erasure Coding z dystrybucją całych obiektów – obiekt zapisany lokalnie w jednym z urządzeń jest najpierw replikowany w całości do wszystkich pozostałych macierzy obiektowych. Po upływie określonego opóźnienia (jednego z parametrów geo EC) w każdej z macierzy obiektowych wykonywany jest Erasure Coding.
2. Opóźniony Erasure Coding z dystrybucją fragmentów danych i kodów parzystości – obiekt zapisany jest lokalnie w jednym z urządzeń. Kody parzystości obliczane są w tym urządzeniu. Fragmenty danych i kodów parzystości wysyłane są do pozostałych urządzeń. W lokalnym urządzeniu przez określony czas (opóźnienie) pozostawiany jest cały obiekt. A po upływie tego czasu, w miejsce obiektu zapisywany jest jego „brakujący” fragment.
3. Natychmiastowy Erasure Coding – obiekt zapisany jest lokalnie w jednym z urządzeń. Kody parzystości obliczane są w tym urządzeniu. Fragmenty danych i kodów parzystości wysyłane są do pozostałych urządzeń. W lokalnym urządzeniu od razu zostaje zapisany fragment danych (a nie cały obiekt, tak ja w scenariuszu drugim).

W każdym z powyższych scenariuszy, po upływie czasu określanego jako opóźnienie, otrzymujemy następujący rezultat:

Obiekt podzielony jest na fragmenty danych i kody parzystości, które rozdystrybuowane są pomiędzy wszystkimi urządzeniami, biorącymi udział w topologii geo EC.

Wybór jednego z powyższych scenariuszy będzie uzależniony między innymi od tego jakie mamy wymagania związane z opóźnieniami, jak intensywne będą odczyty oraz jaka jest przepustowość sieci WAN pomiędzy ośrodkami (wysyłanie fragmentów obiektu do zdalnych urządzeń nie będzie wymagało aż tak dużej przepustowości, jak wysyłanie całych obiektów).

W przypadku, gdy Erasure Coding jest realizowany pomiędzy urządzeniami geograficznie rozproszonymi nie możemy zapomnieć o jednym ważnym parametrze. Oprócz opóźnień związanych z obliczeniami EC, dodatkowo pojawiają się tutaj opóźnienia związane z transmisją danych w sieci WAN. Ma to znaczenie zarówno podczas odczytu, jak i w czasie odbudowy po awarii.

No właśnie. Zwróć uwagę, że w takim scenariuszu jak na rysunku powyżej obiekt jest rekonstruowany z wielu urządzeń nie tylko w przypadku awarii urządzenia, węzła czy dysku twardego, ale również w przypadku poprawnej pracy każdego z urządzeń, podczas zwykłej próby odczytu danych przez aplikację. W sytuacji, gdy jedna z macierzy otrzyma zapytanie odczytu obiektu, a obiekt ten nie będzie przechowywany lokalnie w całości, wówczas odpowiednie fragmenty danych będą musiały zostać wysłane z pozostałych urządzeń i „poskładane” lokalnie w żądany obiekt.

I na koniec jeszcze jedna uwaga, którą warto moim zdaniem przemyśleć. O ile przy awarii pojedynczego dysku odbudowa i rekonstrukcja obiektów pomiędzy urządzeniami (nawet uwzględniając opóźnienia sieci WAN) może nie być kłopotliwa, to wyobraź sobie co się będzie działo, gdy stracisz cały ośrodek i gdy trzeba będzie odbudować ogromne ilości danych (czyli również przesłać je siecią WAN).

Zaprojektuj „z głową”.

Absolutnie nie jest moim celem zniechęcanie kogokolwiek do technologii geo Erasure Coding. Warto jednak w odpowiedni sposób przemyśleć i zaprojektować topologię replikacji i geo EC w Twoim środowisku, biorąc przy tym pod uwagę między innymi wymagania w zakresie maksymalnych dopuszczalnych opóźnień, charakterystykę odczytów i dostępną przepustowość pomiędzy ośrodkami. Informacje te pomogą również w podjęciu decyzji jaki model (scenariusz) geo EC będzie najlepszym rozwiązaniem dla Twojej aplikacji.

Erasure Coding i owszem, może skonsumować mniejszą przestrzeń niż tradycyjna replikacja i na pewno pozwala na zabezpieczenie się przed awarią więcej niż dwóch elementów (dysków, węzłów, urządzeń). Pamiętaj jednak, że wykonywanie matematycznych algorytmów do kodowania i dekodowania danych bardzo mocno obciąża procesory urządzenia i wpływa na wydłużanie opóźnień. A te z kolei spowalniają zapisy oraz proces odbudowy w przypadku wystąpienia awarii. Dodatkowo w przypadku EC realizowanego pomiędzy geograficznie rozproszonymi urządzeniami do opóźnień związanych z obliczeniami należy dodać opóźnienia w sieci WAN.

Systemy geograficznie rozproszone, działające w oparciu o EC są zazwyczaj wolniejsze od systemów, które replikują pełne obiekty pomiędzy ośrodkami. Projektujesz system, w którym będą przetwarzane raczej aktywne dane, a przetwarzanie to powinno być wykonywane w możliwie jak najkrótszym czasie? Moim zdaniem, dla takiego systemu standardowa replikacja obiektów będzie lepszym sposobem zabezpieczenia danych. Jeżeli natomiast miałby to być system wykorzystywany raczej do archiwizacji, gdzie intensywność odczytów nie jest aż tak duża wówczas geo Erasure Coding może być rozwiązaniem wartym rozważenia.