Drobne błędy niszczą dane

Jeszcze dziesięć lat temu nikt nie zastanawiał się nad błędami w danych na sprawnych dyskach. Obecnie w środowiskach składujących duże ilości danych spotyka się błędy, których nie wykrywa ani kontroler, ani firmware dysków.

Co niszczy dane

Przyczyną uszkodzenia danych mogą być nie tylko błędy na talerzach dysków - oprócz nich występują także inne czynniki, takie jak:

- awarie mechaniczne lub elektryczne kabli połączeniowych;

- problemy z niestabilnym zasilaniem;

- uszkodzenia pamięci operacyjnej serwera;

- błędy w firmware kontrolerów macierzowych;

- błąd w sterowniku do kontrolera RAID lub HBA;

- wibracje;

- uszkodzenia przełączników Fibre Channel;

- promieniowanie kosmiczne i zakłócenia elektromagnetyczne;

- błędy w oprogramowaniu firmware.

Podsumowanie wszystkich czynników wskazuje, że błędy mogą zdarzać się częściej. Tak jest w rzeczywistości - badania prowadzone przez CERN udowodniły, że stopa błędów mierzona na poziomie systemu operacyjnego w systemach plików bez szczegółowej korekcji znacznie przekracza deklarowane przez producenta dysków 1:10^16.

W miarę wzrostu ilości tworzonych danych pojawiały się problemy z ich przechowywaniem. Początkowo podstawowym problemem była pojemność i wydajność macierzy, obecnie jednym z minusów jest trwałość informacji.

Mimo wysokiej trwałości samych nośników i napędów, w dużych instalacjach obserwuje się zjawisko niszczenia danych przez drobne błędy, które przechodzą niezauważone w typowych systemach plików, takich jak Ext3/Ext4, XFS, JFS, UFS, ReiserFS czy NTFS Microsoftu. Problem jest dość poważny i dotyczył nawet niektórych sprzętowych kontrolerów RAID.

Niekorygowane błędy to tylko jeden z problemów związanych z dużymi woluminami RAID. Niektórzy specjaliści uważają, że przy tak dużych zbiorach danych, jakie spotyka się w zastosowaniach klasy Big Data, wolumin RAID nie ma już zastosowania i lepszy będzie rozwój w modelu scale-out (skalowanie poziome, przez dodawanie kolejnych urządzeń do klastra zamiast rozbudowy pojedynczego urządzenia).

Duże zasoby RAID przynoszą problemy

Standardowe podejście przy tworzeniu zasobów dyskowych polega na skorzystaniu ze sprzętowego kontrolera RAID, dzięki czemu wolumin udostępniany systemowi operacyjnemu jest już zarządzany przez kontroler. W takim przypadku za nienaruszalność danych odpowiada kontroler. Nie zawsze jest on przygotowany do ochrony przed niekorygowanymi błędami z napędów. Niekiedy pojawiają się też inne problemy, oto kilka z nich:

Awarie chodzą parami

W praktyce dyski łączone później w wolumin RAID są kupowane razem, niekiedy pochodzą z tej samej serii. Pracują one przez taki sam czas w tych samych warunkach, a to oznacza, że awaria mechaniczna jednego dysku może pociągać za sobą uszkodzenie kolejnych. Według badań przeprowadzonych już w 1994 r. przez P. Chena, E.Lee, G. Gibsona i innych, zjawisko skorelowanych awarii mechanicznych w grupach RAID jest udowodnione statystycznie.

W praktyce możliwość kolejnej awarii, zanim zakończy się proces odbudowywania RAID, jest o wiele bardziej prawdopodobna od czterech losowych awarii, gdyż zdarzenia nie są niezależne. Możliwość dwóch awarii w dziesięciogodzinnym odstępie jest dwa razy wyższa od tej, która wynika z prostego rozkładu statystycznego dla pojedynczych dysków.

Należy podkreślić, że nie zawsze dyski określane jako serwerowe charakteryzują się dłuższą trwałością od konsumenckich. Dwa niezależne badania przeprowadzane przez Eduardo Pinheiro, Wolfa-Dietricha Webera i Luiza André Barroso z firmy Google oraz przez badaczy z uniwersytetu Carnegie Mellon udowodniły, że związek między klasą dysków a częstością awarii nie jest statystycznie istotny.

Błędy podczas odbudowy macierzy

Błędy na dyskach - są i będą

Nowoczesne dyski mają coraz większą pojemność i znaczną część surowej przestrzeni przeznaczają na dane służące do korekcji błędów. Wiele błędów powstaje przy normalnej pracy i są one korygowane przez oprogramowanie pracujące wewnątrz samego napędu - nie są widoczne dla zewnętrznych kontrolerów dyskowych. Niewielka część z tych błędów przechodzi jednak niezauważona i nie są one korygowane przez oprogramowanie w napędzie dyskowym (są to błędy UBE, Unrecoverable Bit Error). Producenci dopuszczają takie zjawisko - specyfikacja wielu dysków SAS klasy Enterprise szacuje stopę UBE na 1: 1016 bitów, dysk Seagate Cheetah T10 SAS charakteryzuje się stopą korygowanych błędów poniżej 10 na każde 1012 bitów przesłanych. Niekorygowane błędy w tym samym dysku są na poziomie poniżej 1 sektora na 1016 bitów przesłanych, a źle skorygowane na poziomie poniżej 1 sektora na 1021 bitów (dane z dokumentacji firmy Seagate Technology LLC). Nowoczesny dysk Fibre Channel klasy Enterprise, który obsługuje nowy standard ochrony przez błędami DIF (Data Integrity Field), również ma podobną stopę błędów.

Nieskorygowane błędy odczytu (UBE, Unrecoverable Bit Error) może powodować problemy z pracą RAID i mają coraz większe znaczenie w miarę wzrostu rozmiaru woluminów. Chociaż prawdopodobieństwo UBE jest niewielkie, przy dużych woluminach RAID-5 niesie ze sobą ryzyko utraty danych przy odbudowie dużych zasobów. Błąd odczytu sektora podczas odbudowy RAID-5 skutkuje błędem nie tylko sektora, ale także rekonstruowanych bloków zawierających dany sektor, obliczanych za pomocą mechanizmu sum kontrolnych. Wskutek takiego błędu woluminu RAID-5 nie udaje się odbudować. Woluminy z podwójnymi dyskami parzystości (RAID-6, raid_dp) niosą ze sobą większy narzut operacji zapisu. W praktyce stosuje się zatem RAID-10, ze względu na niższe ryzyko problemów spowodowanych niekorygowanymi błędami odczytu. Producenci macierzy wprowadzili proces czyszczenia błędów, odbywający się w tle i w sposób niewidoczny dla użytkownika wykrywają, odtwarzają poprawną zawartość za pomocą sum kontrolnych i remapują dane do nowego sektora. W ten sposób można ominąć problem, ale nie wszystkie macierze posiadają taką opcję. Jest ona za to wbudowana w system plików ZFS.

Wzrost czasu odbudowy woluminu

Pojemność dysków rośnie proporcjonalnie szybciej od prędkości transferu, a zatem czas odbudowy dużych woluminów liczy się w wielu godzinach, a nawet dniach. Rośnie on dodatkowo, jeśli macierz nadal obsługuje systemy IT. W takim przypadku dodatkowe obciążenie związane z odbudową woluminu przynosi radykalny wzrost prawdopodobieństwa wystąpienia błędów. W przypadku woluminów z pojedynczą nadmiarowością (RAID 3, 4 i 5) druga awaria niesie ze sobą całkowitą utratę danych. Ryzyko można obniżyć za pomocą systemów z potrójnymi dyskami parzystości. Czas odbudowy RAID-10 jest krótszy od RAID-5 i RAID-6, gdyż trzeba skopiować tylko dane pojedynczego uszkodzonego napędu - w innych poziomach do odtworzenia poprawnej struktury niezbędne jest odczytanie wszystkich sektorów macierzy. Należy pamiętać, że zwiększone obciążenie i możliwość pojawienia się różnych błędów sprawia, że ryzyko uszkodzenia woluminu RAID-5 jest najwyższe właśnie przy odbudowie woluminu po wymianie uszkodzonego dysku.

Niespójność danych spowodowana awarią systemu

Załamanie systemu lub przerwanie zapisu z innego powodu skutkuje stanem, w którym zapisane dane są niespójne i niezgodne z informacją zapisaną w systemie parzystości woluminu RAID. Przyczyna niespójności leży w tym, że proces zapisu nie ma cechy atomowości, czyli albo wykona się go w całości, albo nie zrobi w ogóle. Dane zapisane w niespójnym procesie nie mogą być użyte do poprawnego odtworzenia woluminu RAID, jeśli podsystem storage nie wykorzystuje księgowania transakcji. Opóźniony zapis na dyski nazywany popularnie write hole był przyczyną uszkodzeń wielu woluminów RAID, gdy korzystano z tanich niskiej klasy kontrolerów.

Zawodna pamięć cache

Mimo podtrzymania bateryjnego i powszechnego stosowania nieulotnej pamięci Flash, jako cache nadal pojawiają się zarzuty związane z możliwością utraty danych. System pamięci podręcznej w wielu macierzach sygnalizuje udany zapis na dysk zaraz po zapisaniu danych do cache, a proces "spłukania" pamięci cache na dyski odbywa się później. Jeśli proces zawiedzie, następuje utrata danych. Niespójność woluminów macierzy dyskowych i cache były jednymi z powodów problemów w odtworzeniu danych po awarii zasilania w firmie Beyond (operator usługi cloud computing e24cloud.pl).

Korekcja błędów w dyskach

Nowoczesne napędy mają wbudowaną korekcję błędów. Czas usuwania błędu i odtwarzania danych uszkodzonego sektora może zająć nawet minutę. Kontrolery dyskowe są często tak konfigurowane, że brak odpowiedzi dysku w ciągu kilku sekund oznacza jego uszkodzenie i powoduje wypadnięcie napędu z woluminu RAID. Zjawisko jest częste w starszych dyskach SATA.

Biorąc to pod uwagę, od ub. r. firmy Dell, Hitachi Data Systems, Seagate, NetApp, EMC i IBM zalecają unikać woluminów RAID-5 złożonych z dysków o dużej pojemności.

Błąd przechodzi niezauważony

Najgorsze są błędy, które nie zostały wykryte przez firmware dysku ani przez kontroler dyskowy, ani przez system plików w systemie operacyjnym. Firma NetApp przeprowadziła w ub. r. badania na dużej próbce dysków - ponad 1,5 mln sztuk napędów, które pracowały w macierzach tego producenta. Ustalono, że średnio w jednym na 90 napędów SATA wystąpi "cichy błąd", który nie zostanie wychwycony przez proces weryfikacji spójności macierzy w kontrolerze sprzętowym RAID. Dla poziomu RAID 5 oznacza to jeden błąd na każde 67 terabajtów odczytywanych danych. Oznacza to, że statystycznie każda duża odbudowa woluminu o znacznych rozmiarach wiąże się z istotnym ryzykiem uszkodzenia składowanej tam informacji.

Im pojemniejsze i szybsze dyski, tym gorzej

Początkowo użytkownicy niezwykle rzadko mieli niewykrywalne uszkodzenia, gdyż dyski były względnie powolne i mało pojemne. Razem z rozwojem bardzo pojemnych dysków i bardzo szybkich macierzy RAID, przetransferowanie 10^16 bitów stało się możliwe w krótkim czasie. Jeff Bonswick, jeden z twórców systemu plików ZFS stwierdził, że duża, szybka i silnie obciążona baza danych Greenplum, powszechnie używana przy wielkoskalowych obliczeniach klasy Big Data, doświadcza niekorygowanych błędów z podsystemu storage co około 15 minut. Pojawiające się błędy odczytu z dysków były jednym z powodów wdrożenia systemu plików ZFS w takich środowiskach. Nawet urządzenia desktopowe wyposażone w kilka dysków o pojemności 2 TB każdy doświadczają błędów co pewien czas, szczególnie w katalogach tymczasowych dla aplikacji związanych z edycją grafiki lub wideo. Ani NTFS (Windows), ani Ext4 (Linux) nie potrafi takich błędów wykryć i skorygować podczas operacji odczytu, gdyż systemy nie były projektowane pod tym kątem. Obecnie jedynym systemem plików, który potrafi wykryć podobny błąd w woluminie RAID, jest ZFS.

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200