my personal page

Ostatnio wokół mnie sporo zamieszania w temacie przechowywania danych. W pracy kolega marudzi, że programowy RAID jest „niekoszerny”, na forach przewijają się pytania o kontrolery i ich „nielogiczne” zachowanie, a serwery migają wesoło na czerwono i nie wiadomo co im jest. Spróbujmy to wszystko chociaż odrobinę uporządkować.

Po kolei – RAID, czyli „nadmiarowa macierz niezależnych dysków”(*) jest to połączenie dwóch lub więcej dysków, które umożliwia osiągnięcie dodatkowych możliwości (w stosunku do pojedynczego napędu). Może to być zwiększenie wydajności, uodpornienie na awarie, lub powiększenie pojemności pojemności widzianej jako jedna całość.

Podział macierzy dyskowych możemy zrobić na podstawie ich poziomów oraz sposobu implementacji.

I tak w teorii – którą można znaleźć na Wikipedii, w mądrych książkach i na niezliczonej ilości stron i blogów – poziomów RAIDu jest całkiem sporo, jednak w praktyce spotyka się tylko kilka z nich:
– RAID0 (stripe), który polega na połączeniu minimum dwóch dysków w celu zwiększenia wydajności. W żaden sposób nie zabezpiecza danych w razie awarii sprzętu. Można powiedzieć, że taka konfiguracja jest nawet mniej bezpieczna, niż kilka oddzielnych dysków, bo w przypadku awarii jednego z nich możemy utracić wszystkie dane. Teoretycznie wydajność takiej macierzy skaluje się liniowo, a podstawowe ograniczenie stanowi sam kontroler,
– RAID1 (mirror) – podstawowy sposób zabezpieczenia danych przed utratą wskutek awarii dysku. Szybkość działania zależy od mechanizmów zaimplementowanych w kontrolerach lub – w przypadku programowej macierzy – sterowniku. Przykładowo: przy Linuksowym (programowym) mirrorze złożonym z dwóch dysków, podczas pojedynczego odczytu (test przy pomocy polecenia dd) system korzystał tylko z jednego dysku, chociaż teoretycznie mógłby czytać dane „po kawałku” z obydwu urządzeń,
– RAID5 – najtańsza (pojemność rzeczywista przy N takich samych dysków wynosi N-1) forma ochrony danych przed awariami napędów dyskowych. Szybka przy odczycie, za to zdecydowanie wolniejsza podczas zapisu. Odporna na awarię jednego (dowolnego) dysku,
– RAID6 – j.w., ale z podwójną parzystością (odporna na awarię dwóch dysków).
– RAID10 – macierz o organizacji RAID0 (stripe), której elementami nie są pojedyncze dyski, tylko macierze RAID1 (mirror). Dzięki takiej organizacji osiągamy wydajność zbliżoną do poziomu RAID0 i jednoczesną ochronę danych.
– RAID50/60 – j.w., ale stripe nałożony na RAID5/6.

Jeżeli zaś chodzi o sposób implementacji, to są jedynie trzy:
– macierz sprzętowa (ang. hardware-based array) – do zbudowania i obsługi macierzy używany jest specjalny kontroler, który wszystkie potrzebne operacje jest w stanie wykonać sam, bez wsparcia ze strony systemu operacyjnego, sterowników ani dodatkowych programów lub urządzeń. Przykładami takich kontrolerów są Adaptec 2230S z interfejsem SCSI oraz Adaptec 5405 dla SAS.
– macierz programowa – (ang. software-based array) – przez niektórych administratorów uważana za zło konieczne i rozwiązanie zdecydowanie mniej „profesjonalne”, niż opisane powyżej. Tutaj możemy wykorzystać dowolny kontroler i dowolne urządzenia blokowe (nawet pendrive i karty CF), a cała logika zarządzana jest na poziomie sterowników i oprogramowania w systemie operacyjnym. Wbrew pozorom to rozwiązanie nie jest dużo wolniejsze od jego ich sprzętowego brata, ale o tym trochę później.
– fakeraid (ew. hostraid) – sposób zarządzania dyskami „mieszający” obie powyższe metody. Sama definicja i konfiguracja macierzy odbywa się w BIOSie kontrolera, zarządzaniem i monitorowaniem zajmuje się specjalny sterownik do systemu operacyjnego, a przeliczanie sum kontrolnych i rozkład poszczególnych danych na dysków realizowany jest przez procesor komputera. I właśnie z tym rodzajem związana jest zdecydowana większość problemów, na które napotykają administratorzy i użytkownicy. FakeRAIDami są np. wszystkie kontrolery oparte o układ Sil3112 lub Sil3114.

Tyle teorii, teraz zajmijmy się (moją, subiektywną) praktyką.

Po pierwsze – nazywanie macierzy „sprzętowymi” nie jest tak do końca precyzyjne. Bo przecież logika realizowana jest także tutaj przez oprogramowanie. Fakt, że zaszyte w odrębnej pamięci i operujące na dedykowanym do tego celu procesorze nic nie zmienia.

Po drugie – macierze programowe (czyli te realizowane przez elementy systemu operacyjnego) wcale nie muszą być wolniejsze od ich sprzętowych odpowiedników. I dość często nie są. Za przykład niech posłużą testy dwóch konfiguracji, które zrobiliśmy kilka lat temu:

W przypadku Adapteca użyto dysków Fujitsu MAW3073NC, natomiast do kontrolera 3ware były podłączone Raptory WD360. Jak widać z powyższej tabelki, rozbieżności nie są bardzo duże. Różnic pomiędzy testami 4. a 5. nie jestem w stanie wyjaśnić. Mogę jedynie podejrzewać, że testy zrobiliśmy na zbyt małej ilości danych lub ustawiliśmy różne wartości chunk size, które tak bardzo wpłynęły na otrzymane wyniki.

Po trzecie (które trochę łączy się z poprzednim punktem) – macierze programowe nie są takie złe. Szczególnie w przypadku porównania z kontrolerami, które nie są już produkowane. Rozważmy co możemy zrobić w przypadku awarii kontrolera (w większości konfiguracji, które widziałem jest to jednak dość krytyczny element). Jeżeli używamy programowej macierzy linuksowej (zbudowanej i obsługiwanej za pomocą narzędzia mdadm), to przekładamy zestaw dysków do dowolnego komputera, który takie napędy obsłuży (czyli da się je fizycznie podłączyć i zostaną zauważone jako pojedyncze urządzenia) i uruchamiamy normalnie system. W przypadku awarii kontrolera sprzętowego, musimy zaopatrzyć się w takie samo, lub chociaż podobne (np. Adaptec umożliwia migrację macierzy z jednych kontrolerów na inne) urządzenie i zmigrować konfiguracją na nowy kontroler. Przywiązuje nas to do producenta kontrolerów i może być problematyczne w przypadku stosowania konfiguracji już nie produkowanych (ale to się przecież w systemach produkcyjnych nie zdarza :-)). Tutaj ciekawostka: Adaptec umożliwia migrację macierzy z kontrolerów HostRAID do ich „pełnych” wersji. Można sobie o tym poczytać chociażby tutaj.

Po czwarte – wobec dostępności na rynku i obecnych cen dysków twardych, sensowność stosowania poziomu RAID5 (w porównaniu z RAID6) staje się coraz bardziej dyskusyjna. W zamian za konieczność instalacji dodatkowego dysku zyskujemy większą odporność na awarię oraz brak czasu bez ochrony danych (od momentu awarii jednego z dysków do chwili całkowitego odbudowania macierzy). Jednak migracja RAID5->RAID6 związana jest z kilkoma aspektami:
– Wspomniany już większy koszt macierzy. Różnicach w kosztach może ograniczyć się tylko do konieczności zakupu dodatkowego dysku. Jednak w przypadku braku miejsca na ten dysk, konieczny może okazać się zakup dodatkowej obudowy na dyski, co może znacznie podrożyć konfigurację,
– RAID6 wymaga większej mocy obliczeniowej, która potrzebna jest do przeliczenia sum kontrolnych przechowywanych danych, co wymaga wydajniejszych procesorów – niezależnie od tego, czy stosujemy macierz sprzętową czy programową,
– Wydajność zapisu macierzy z dwoma dyskami nadmiarowymi jest nieznacznie mniejsza, niż w przypadku RAID5.

Ufff, na razie chyba wystarczy :-)

(*) samo rozwinięcie tego skrótu jest trochę zwodnicze, bo tutaj nadmiarowość nie zawsze oznacza coś, co podnosi bezpieczeństwo i zabezpiecza nasze dane w przypadku awarii.