Cichy zabójca danych

Nawet najlepsze nośniki i urządzenia składowania danych są podatne na błędy. Najgroźniejsze są te, których nie wykrywa kontroler RAID ani firmware dysków. Może je wykryć system plików ZFS.

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 (duża liczba zgłoszeń korekcji błędów zfs scrub czasami wskazuje na taką awarię);

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

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

- wibracje (w tym także na pozór słabe, np. głośne dźwięki w otoczeniu komputera);

- uszkodzenia przełączników Fibre Channel;

- promieniowanie kosmiczne i zakłócenia elektromagnetyczne;

- błędy w oprogramowaniu firmware (aż 5-10% ogółu problemów związanych ze składowaniem danych).

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.

Jednym z najciekawszych systemów plików jest ZFS, opracowany przez firmę Sun Microsystems, dostępny na licencji open source i obecny w systemie Solaris. ZFS, dzięki mechanizmowi sum kontrolnych, niejednokrotnie umożliwił wykrycie problemów sprzętowych, które umykały nawet specjalizowanym programom diagnostycznym. Trudno nazwać system plików narzędziem diagnostycznym, ale praktyka administratorów systemów typu UNIX pokazuje, że ZFS, podobnie jak niektóre aplikacje, przywiązuje wielką wagę do spójności danych i podnosi alarm w przypadku wykrycia błędów.

Jedną z przyczyn wprowadzenia do ZFS silnego mechanizmu kontroli błędów jest niedostateczna ochrona przed drobnymi przekłamaniami, które przechodzą niezauważone w typowych systemach plików, takich jak Ext2/Ext3, XFS, JFS, UFS, ReiserFS czy NTFS. Problem jest poważny i dotyczył nawet niektórych sprzętowych kontrolerów RAID. Doświadczenia sprawiły, że zagadnieniami zajęli się badacze, którzy analizowali podatność danych na uszkodzenie w nowoczesnych systemach storage.

Skąd się biorą błędy?

Nowoczesne dyski twarde 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, a zatem nie są widoczne dla zewnętrznych kontrolerów dyskowych. Niewielka część tych błędów przechodzi niezauważona: oprogramowanie w napędzie dyskowym ich nie koryguje.

Producenci dopuszczają takie zjawisko - przykładowa specyfikacja dysków SAS klasy Enterprise szacuje stopę niekorygowalnych błędów na 1: 1016 bitów. Przykładowy dysk Seagate Cheetah T10 SAS charakteryzuje się stopą korygowanych błędów poniżej 10 na każde 1012 bitów przesłanych, niekorygowanych błędów na poziomie poniżej 1 sektora na 1016 bitów przesłanych (w przypadku błędnego bitu za uszkodzony traktuje się cały sektor), a źle skorygowanych na poziomie poniżej 1 sektora na 1021 bitów (dane z dokumentacji firmy Seagate Technology LLC).

Nowoczesny dysk Fibre Channel (także klasy Enterprise), który korzysta z sektorów o rozmiarze 520 bitów i obsługuje nowy standard ochrony przez błędami DIF (Data Integrity Field), również ma podobny współczynnik błędów. Najgorszym typem błędów są te, które nie zostały wykryte przez firmware dysku ani przez kontroler dyskowy, ani przez system plików w systemie operacyjnym. Zjawisko drobnych uszkodzeń nazywane jest czasem "cichym niszczeniem danych". Badania przeprowadzone przez firmę NetApp na dużej próbce dysków (ponad 1,5 mln egzemplarzy), które pracowały w macierzach tego producenta, udowodniły, ze średnio w jednym na 90 napędów SATA wystąpi błąd, który nie został wychwycony w trakcie weryfikacji spójności macierzy w kontrolerze sprzętowym RAID. Dla poziomu RAID 5 oznacza to z grubsza jeden błąd (jeden przekłamany bit) na każde 67 terabajtów odczytywanych danych.

Im pojemniejsze i szybsze dyski, tym gorzej

Początkowo "ciche niszczenie danych" nie było problemem, gdyż dyski i macierze były względnie małe i powolne. Użytkownicy niezwykle rzadko doświadczali niewykrywalnych uszkodzeń, a zatem zjawisko to nie wymagało działań zaradczych. Razem z rozwojem bardzo pojemnych dysków oraz szybkich macierzy RAID przetransferowanie 10^16 bitów stało się możliwe w krótkim czasie.

Jeff Bonswick, jeden z twórców ZFS, stwierdził, że szybka baza danych Greenplum, powszechnie używana dziś przy wielkoskalowych obliczeniach hurtowni danych i analityki biznesowej, doznaje niekorygowanych uszkodzeń danych średnio co 15 minut. Była to jedna z przyczyn, dla których podobne bazy wykorzystują właśnie system plików ZFS, gdyż zawiera on mechanizmy korekcji błędów.

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, a sam system operacyjny nie musi ponosić żadnego narzutu związanego z utrzymaniem redundancji danych na wszystkich dyskach. Niestety, w takim przypadku za nienaruszalność danych odpowiada kontroler dyskowy, który nie zawsze jest przygotowany do ochrony przed niewykrywanymi zmianami sektorów na dysku.

Jeśli instalacja jest na tyle duża, że zjawisko losowej utraty danych może być problemem, to warto skorzystać z bezpośredniego dołączania dysków do systemu operacyjnego lub skonfigurować kontroler RAID do trybu połączenia pojemności wszystkich dysków (JBOD). Wtedy odpowiednio skonfigurowany system plików ZFS poradzi sobie z ochroną danych składowanych na tych dyskach. Przy konfiguracji dysków za pomocą kontrolera RAID należy także wziąć pod uwagę możliwość "wypadania" dysków z zasobów w przypadku braku odpowiedzi lub przypadkowych błędów.

Ze względu na różną stopę błędów sposób zarządzania zasobami zależy także od tego, jakie dyski tworzą dany wolumin. W przypadku tańszych dysków SATA automatyczna kontrola błędów za pomocą polecenia scrub powinna być przeprowadzana co tydzień, jeśli mamy do czynienia z dyskami SAS klasy Enterprise - co miesiąc. W odróżnieniu od chkdsk w Windows czy fsck w Linuksach, polecenie zpool scrub pracuje na zamontowanym do zapisu systemie plików, nie wymaga przerwy w pracy, ale generuje przy tym bardzo duży ruch wejścia/wyjścia.

Kto skorzysta z ZFS

Niestety, nie wszystkie systemy operacyjne mogą skorzystać z systemu plików ZFS. Nie potrafi tego na przykład Microsoft Windows, a w Linuksach implementacja jest nadal obarczona niedostatkami i nie zawsze nadaje się do pracy produkcyjnej (prace nad usprawnieniem tego portu trwają w Lawrence Livermore National Laboratory na mocy kontraktu rządowego w USA). Problemy z rozwojem ZFS dla Linuksa są związane z różnicami licencyjnymi - jądro Linuksa jest wydane na licencji GNU GPL (GNU General Public License), a kod ZFS na licencji CDDL (Common Development and Distribution License). Chociaż obie licencje są zgodne ze standardem open source, nie są zgodne między sobą, a zatem nie można będzie włączyć kodu ZFS do jądra Linuksa - musiałby on zostać od nowa napisany.

ZFS jest obecny we FreeBSD, prace nad obsługą tego systemu plików wykonał Paweł Jakub Dawidek. FreeBSD można zainstalować w całości na ZFS - z takiej konfiguracji korzystają niektórzy operatorzy hostingowi w Polsce. Z obsługi ZFS we FreeBSD skorzystały także inne projekty wykorzystujące ten system, np. FreeNAS czy NAS4Free. Jednak najlepszą implementacją ZFS może poszczycić się system Oracle Solaris, w którym jest to domyślny system plików.

RAID, ale nie za pomocą kontrolera

Często stosowaną konfiguracją jest połączenie dwóch dysków w zasób z kopią lustrzaną (mirror). Chociaż wiele kontrolerów RAID oferuje taką funkcjonalność, warto pamiętać, że w przypadku niedostatecznie dopracowanych kontrolerów, a takich niestety jest większość, wszystkie błędy nieskorygowane przez kontroler napędu będą propagowane na oba dyski. Tej wady nie ma programowy mirror uruchomiony z użyciem opcji mirror oprogramowania zpool, gdyż system plików będzie dokładnie kontrolował dane składowane na każdym z dysków. W razie błędów - zostaną one poprawione.

Najbezpieczniejsza konfiguracja przewiduje zbudowanie kilku par mirrorów, przy czym dobra praktyka zaleca przygotowanie co najmniej jednego dysku jako gorącej rezerwy (hot spare), co bardzo przyspieszy odbudowanie macierzy po wymianie uszkodzonego dysku.

Zamiast RAID-5 na kontrolerze warto zbudować grupę z kilku dysków w formie RAID-Z (jeden dysk parzystości) lub RAID-Z2, która zakłada wykorzystanie dwóch dysków parzystości, podobnie jak RAID-6 lub raid_dp w macierzach NetApp. Najbezpieczniejsza konfiguracja to RAID-Z3, w której do ochrony danych przeznacza się trzy aż fizyczne dyski. Taka konfiguracja w połączeniu z gorącą rezerwą daje bardzo dobrą niezawodność składowania danych nawet na tanich dyskach.

Programowy RAID w ZFS umożliwia wykrycie dysku, który nie wydaje się uszkodzony, gdyż odpowiada na komendy SATA czy SCSI, ale zwraca błędne dane. W przypadku sześciu dysków klasy konsumenckiej połączonych w RAID-Z autor tego tekstu obserwował pojedyncze błędy sum kontrolnych co około pół roku.

Wydajność systemów RAID-Z jest porównywalna ze sprzętowymi kontrolerami macierzowymi, mimo bardzo dużego zapotrzebowania na pamięć operacyjną. Rozwiązanie programowe ma jednak dużą zaletę - jest niezależne od stosowanego kontrolera dyskowego. Dzięki temu zasoby będzie można odtworzyć nawet w przypadku awarii kontrolera dyskowego i jego wymiany na nowszy model lub konieczności przełożenia wszystkich dysków do serwera o zupełnie innym kontrolerze - wystarczy wtedy skonfigurować kontroler, by nie tworzył macierzy RAID, a dostarczał dyski tak, jak są, do systemu operacyjnego, a następnie zamontować zasoby 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