36 godzin, 47 remapów i decyzja — co działa naprawdę: RAID vs ZFS kontra Btrfs
36‑godzinny rebuild macierzy RAID6 podczas którego dysk 3 zgłosił 47 remapów i system doznał kolejnej degradacji, skończył się pilnym przełączeniem usług i kilkoma nocnymi godzinami pracy zespołu.
Jak to się psuje i co to znaczy w praktyce
Tradycyjny sprzętowy RAID6 czy mdadm RAID6 przy degradacji zachowuje się prosto: rekonstruuje zawartość całego dysku, bit po bicie. To oznacza pełne odczyty na wszystkich powierzchniach pozostałych dysków setki lub tysiące godzin I/O przy dużych pojemnościach i wysoki poziom ryzyka podczas operacji naprawczej.
ZFS stosuje sumy kontrolne na poziomie bloków i copy‑on‑write, podczas resilvera kopiuje tylko te bloki, które są faktycznie potrzebne. W praktyce często skraca to czas odbudowy o dziesiątki procent w porównaniu z pełnym rebuildem RAID, ale wymaga pamięci (ARC) i CPU — przy małym sprzęcie koszt CPU może rosnąć.
Btrfs ma podobne podejście do checksumów i COW.
Checksumy kontra mechanizmy korekcji i ich znaczenie dla SLA
Checksum wykryje uszkodzenie bloku, mechanizm korekcji (RAID6 parity, ZFS RAIDZ) pozwoli odtworzyć dane. To, co łamie SLA, to nie sama korekcja, a czas i wpływ na bieżące I/O. Pełny rebuild 10‑TB woluminu w RAID6 potrafi obciążyć kontroler i dyski tak, że wydajność produkcyjna spada o 60–90% przez dni. Resilver ZFS zwykle robi mniej pracy, ale podczas dużego równoległego I/O też widziałem spadki przekraczające 50%.
Do tego dochodzi efekt remapów. Dysk z 47 remapami już sygnalizuje niestabilność powierzchni; kolejne remapy najczęściej przychodzą w niesprzyjającym momencie, podczas intensywnego I/O — wtedy degradacja staje się domino. Koszt to nie tylko wymiana dysku: to czas inżynierów, czas przestojów okryty SLA, ryzyko utraty transakcji.
Koszty operacyjne — liczby, które trudno zignorować
Przykład: 36 godzin rebuildu dwóch inżynierów na dyżurze (łącznie ~28 godzin roboczych) dodatkowe testy i failovery — sumarycznie około 3–4 tys. PLN kosztu pracy tylko tego zdarzenia, plus utracone SLA i dodatkowe procedury postmortem. Dodaj do tego zużycie prądu zwiększone o 150–300 W w czasie intensywnych operacji I/O przez 36 godzin i masz kolejne kilkadziesiąt złotych do bilansu.
Przewidywalność degradacji ma większą wartość niż kilka punktów procentowych dostępności deklarowanej z papieru. Systemy z lepszą telemetrią i łatwiejszymi mechanizmami odczytu stanu (ZFS z zpool status, regularne scruby) pozwalają zaplanować wymiany i ograniczyć pracę ad hoc. Słaba telemetria lub brak testów rebuildu oznaczają wyższy koszt operacyjny w czasie awarii.
Krótka historia z jors.pl — co zrobiłem i czego mnie to nauczyło
Pracując nad serwerami jors.pl trafiłem na sytuację, gdzie błąd ludzki nadpisał część danych produkcyjnych. Mieliśmy snapshoty, ale główny backup był częściowo niekompletny, więc pierwszym krokiem było zatrzymanie zapisu, zrobienie świeżego zrzutu stanu i wysłanie kopii na drugi pólka z wykorzystaniem send/receive. ZFS pozwolił przywrócić brakujące pliki z kilku snapshotów, a scruby ujawniły kilka poprzednich błędów na jednym dysku, które zostały naprawione przez wymianę przed kolejną degradacją.
W osobnym środowisku testowałem Btrfs dla mniejszych zestawów — snapshoty i send/receive działały szybko i przyjemnie, wymiany urządzeń były proste, ale przy dużych woluminach balance potrafił zająć cały dysk i mocno obniżyć wydajność. Z tych doświadczeń wyniosłem prostą zasadę operacyjną: planuj procedury odzysku, przećwicz je i mierz czas każdej operacji na realnym sprzęcie.
Przed każdą aktualizacją lub zmianą konfiguracji robiłem też kopię zgodnie z procedurą opisaną w Najlepsze praktyki backupu danych na serwerze domowym, co w jednym przypadku uratowało nas przed całkowitą przebudową środowiska.