RAID nie ochroni danych sam z siebie. Lepiej znać koszty odbudowy
02:37 w nocy monitor w serwerowni pokazuje "failed disk 3" w macierzy RAID5 z sześcioma dyskami i natychmiastowy spadek IOPS o ~80% — to moment, w którym teoria spotyka się z kosztami realnej awarii.
Jak działa rebuild i dlaczego boli
RAID5 formalnie toleruje jedną awarię dysku. W praktyce po wypadnięciu jednego nośnika system zaczyna odtwarzanie (rebuild) na pozostałych dyskach, czy to na hot spare czy na nowym dysku. Rebuild to intensywny odczyt i zapis; tablice parity wymagają dodatkowych operacji CPU i I/O. Efekt: IOPS spadają gwałtownie (w moim przypadku ~80%), a opóźnienia rosną, bo każdy odczyt może wymagać rekalkulacji parzystości.
Przykład liczbami: 6×4 TB w RAID5 daje używalne ~20 TB (5×4 TB). Rebuild przy małym obciążeniu to często kilkanaście godzin, przy dyskach 10–14 TB to już >24–48 godzin. Dłuższy rebuild to dłuższa ekspozycja na drugą awarię i większe prawdopodobieństwo napotkania URE podczas odczytu.
RAID 0, 1, 5, 10 — co daje w praktyce
RAID0: brak redundancji.
RAID1: lustro i prostota; rebuild jest szybszy niż w parzystości. Dla 2×4 TB masz 4 TB używalne. Rebuild to skopiowanie danych z jednego dysku na drugi — zwykle krócej niż w RAID5/6, ale przy dużych wolumenach nadal może trwać wiele godzin.
RAID5: jedna parzystość, write penalty ≈4 (read-modify-write) dobra pojemność użyteczna, ale ryzyko związane z czasem odbudowy rośnie z rozmiarem dysków i liczbą danych.
RAID10: połączenie mirroringu i stripingu. Write penalty ≈2, znacznie szybsze odbudowy, mniejsza ekspozycja na URE podczas rebuildu, ale mniejsza efektywna pojemność; przykładowo 6 dysków 4 TB w RAID10 daje ~12 TB używalne (3×4 TB).
Parzystość kontra mirroring — koszt operacyjny
RAID5/6 obciążają CPU i I/O przy zapisie (penalty 4 i 6). RAID10 obciąża mniej przy zapisach, ale wymaga większej liczby dysków dla tej samej pojemności używalnej. Wybór to kompromis między kosztem dysków a czasem przywracania i degradacją wydajności podczas rebuildu.
Ryzyko podczas rebuildu i cicha korupcja
Większe dyski to dłuższy rebuild i większe okno, w którym może wystąpić kolejna awaria albo nieodwracalny błąd odczytu. Nowoczesne dyski mają URE rzędu 10^14–10^15 bitów; przy petabajtach danych statystyka zaczyna być nieprzyjemna. Dodatkowo pamięć i kontrolery potrafią wprowadzić cichą korupcję danych. inwestycję w pamięć ECC tam, gdzie to ma sens operacyjny.
Rebuild to nie tylko czas pracy dysków. To zużycie CPU, wzrost temperatur, przeciążenie kontrolera, a czasem przeniesienie ruchu sieciowego do miejsca które nie przetrzyma dodatkowego obciążenia. Koszt operacyjny to utracone sprzedaże, spowolnione aplikacje i praca zespołu serwisowego poza godzinami.
Mała anegdota z serwisu: klient z RAID1, baza krytyczna zaczęła się degradować (korupcja metadanych na jednym z dysków). Zamiast od razu włączać rebuild, na żywca skopiowałem aktywną bazę na zewnętrzny serwer i przywróciłem integralność. Rebuild był późniejszy; kopia pozwoliła uniknąć przestoju biznesowego. To nie bohaterstwo, to procedura, którą testuję regularnie.
Operacyjne metryki, które trzeba mierzyć przed wyborem macierzy: przewidywany czas rebuildu dla konkretnej pojemności (h), write penalty dla wybranej konfiguracji, dostępność hot spare i MTTR oraz koszt utraty wydajności (przychód/załadowanie) podczas degradacji.
Marketing mówi o ilości dysków, procentach dostępności i „redundancji”. Inżynier liczy okno odbudowy, ryzyko napotkania URE i rzeczywisty koszt operacyjny. Jeśli nie potrafisz policzyć czasu rebuildu dla swojej pojemności i obciążenia, kupujesz obietnice zamiast rozwiązania.