RAID i zdrowie dysków

Wstęp

Dyski umierają. Nie „jeśli”, tylko „kiedy”. Talerzowe mają ruchome części, SSD zużywają komórki przy każdym zapisie. W serwerowni z setką dysków któryś umiera regularnie, jak żarówki w dużym biurowcu.

Admin, który ma jeden dysk w serwerze, ma w kalendarzu niezapisany dzień katastrofy. Admin, który ma RAID, dostaje maila „dysk drugi padł”, idzie po kawę, wymienia dysk i serwer przez cały ten czas działa.

Dziś zbudujemy ten drugi scenariusz. Złożymy RAID, celowo zabijemy w nim dysk, wymienimy go na żywo i nauczymy się pytać dysk o zdrowie, zanim sam się poskarży.

RAID, czyli kilka dysków udaje jeden

RAID to Redundant Array of Independent Disks, nadmiarowa macierz niezależnych dysków. Kilka dysków pracuje razem i system widzi je jako jeden. Po co? Żeby było szybciej, żeby było bezpieczniej albo jedno i drugie. Sposób łączenia to poziom RAID.

Wyobraź sobie biuro rachunkowe i segregatory z dokumentami.

RAID 0, paski. Dwóch księgowych dzieli dokumenty na pół: strona pierwsza do Ani, druga do Bartka, trzecia do Ani. Pracują równolegle, więc jest dwa razy szybciej i dwa razy więcej miejsca. Ale jeśli Bartek zachoruje, każdy dokument ma dziury co drugą stronę. Padł jeden dysk, padło wszystko. Zero w nazwie to dokładnie tyle bezpieczeństwa, ile dostajesz.

RAID 1, lustro. Każdy dokument jest kserowany i obaj księgowi mają identyczny komplet. Bartek choruje? Ania ma wszystko. Miejsca jest tyle, ile na jednym dysku, bo drugi to kopia. Płacisz za dwa, używasz jednego, śpisz spokojnie.

RAID 5, parzystość. Trzech lub więcej księgowych. Dokumenty są podzielone jak w RAID 0, ale do każdego kompletu ktoś dopisuje kartkę kontrolną, z której da się odtworzyć dowolną brakującą stronę. Te kartki są rozrzucone po wszystkich, żeby nikt nie był wąskim gardłem. Przy trzech dyskach masz miejsce z dwóch, przy czterech z trzech. Jeden dysk może paść. Dwa naraz to koniec.

RAID 10, lustra w paskach. Cztery dyski: dwie pary luster, a dane rozdzielone między pary jak w RAID 0. Szybkość paska, bezpieczeństwo lustra, a miejsce z połowy dysków. Ulubiony poziom pod bazy danych.

I najważniejsze zdanie lekcji: RAID to nie jest kopia zapasowa. Lustro wiernie kopiuje wszystko, także rm -rf i zaszyfrowanie przez ransomware. RAID chroni przed śmiercią dysku. Przed śmiercią rozsądku chroni tylko backup.

Sprzętowy czy programowy?

RAID może robić karta w serwerze, wtedy system widzi jeden dysk i o niczym nie wie. Może go też robić jądro Linuksa. To jest programowy RAID, w Linuksie sterownik md, a narzędzie do zarządzania nazywa się mdadm. Pakiet mdadm w obu rodzinach. Dziś zajmujemy się nim, bo działa na każdej maszynie wirtualnej i tego wymagają egzaminy.

Składamy lustro

mdadm --create zapisuje na dyskach własne nagłówki. Tylko puste dyski, tylko maszyna wirtualna, lsblk przed każdym Enterem.

Dokładasz do maszyny wirtualnej trzy dyski po 1 GB. Dwa na lustro, trzeci na późniejszą wymianę. Niech będą to /dev/vdb, /dev/vdc i /dev/vdd.

lsblk
sudo mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/vdb /dev/vdc

mdadm: Note: this array has metadata at the start and
    may not be suitable as a boot device.  If you plan to
    store '/boot' on this device please ensure that
    your boot-loader understands md/v1.x metadata, or use
    --metadata=0.90
Continue creating array? y
mdadm: array /dev/md0 started.

mdadm ostrzega, że z takiej macierzy może być trudno uruchamiać system. Na dane jest w sam raz, więc y. Od tej chwili istnieje nowe urządzenie /dev/md0 i z nim pracujesz jak z każdym dyskiem:

sudo mkfs.ext4 /dev/md0
sudo mkdir -p /raid
sudo mount /dev/md0 /raid

I możesz od razu, bo synchronizacja dysków trwa w tle.

/proc/mdstat: tablica stanu macierzy

Najważniejszy plik dzisiejszej lekcji. Jak wszystko w /proc, nie leży na dysku, jądro generuje go na żywo.

cat /proc/mdstat
watch cat /proc/mdstat

Tak wygląda macierz RAID 5 z czterech dysków w trakcie odbudowy, przykład z dokumentacji Red Hata:

Personalities : [raid4] [raid5] [raid6]
md0 : active raid5 sdf[5] sde[4] sdc[1] sdb[0]
      6282240 blocks super 1.2 level 5, 512k chunk, algorithm 2 [4/3] [UU_U]
      [==============>......]  recovery = 72.0% (1509820/2094080) finish=0.0min speed=215688K/sec

unused devices: <none>

Czytamy jak tablicę odjazdów:

• md0 : active raid5 — nazwa, stan i poziom.
• sdf[5] sde[4]... — które dyski są w środku. Dysk padnięty ma tu dopisek (F), od failed.
• [4/3] — powinny być cztery, działają trzy.
• [UU_U] — najważniejsze. Każde U to dysk na posterunku, każde podkreślenie to dziura. Zdrowe lustro to [UU]. Widzisz [U_]? Jedziesz na jednym kole.
• recovery = 72.0% — odbudowa w toku, z szacowanym czasem do końca.

A szczegóły jednej macierzy:

sudo mdadm --detail /dev/md0

Pokazuje poziom, rozmiar, stan i tabelkę dysków ze stanem każdego: active sync, spare rebuilding, faulty.

Macierz na stałe

Żeby system po restarcie złożył macierz pod tą samą nazwą, zapisujemy jej opis do pliku konfiguracyjnego:

sudo mdadm --detail --scan

[Ubuntu] Plik to /etc/mdadm/mdadm.conf, a na jego początku sam Debian zostawił kartkę: po zmianach uruchom update-initramfs -u.

sudo mdadm --detail --scan | sudo tee -a /etc/mdadm/mdadm.conf
sudo update-initramfs -u

[RHEL] Plik to /etc/mdadm.conf:

sudo mdadm --detail --scan | sudo tee -a /etc/mdadm.conf

Potem wpis do /etc/fstab przez UUID z blkid /dev/md0, jak w lekcji o montowaniu. W tym samym pliku mdadm.conf jest linijka MAILADDR root. To adres, na który usługa monitorująca wyśle maila, gdy dysk padnie. Ustaw tam prawdziwy adres i działającą pocztę, bo alarm, który trafia do skrzynki, której nikt nie czyta, jest jak czujnik dymu bez baterii.

Ćwiczenia z śmierci dysku

Teraz najfajniejsze. Udajemy, że /dev/vdc umarł. W prawdziwym życiu jądro zrobi to samo i zostawi w dzienniku wpis w stylu Disk failure on sdd, disabling device. My strzelamy sami:

sudo mdadm --manage /dev/md0 --fail /dev/vdc
cat /proc/mdstat

W /proc/mdstat przy vdc pojawia się (F), a stan lustra to [U_]. Plik w /raid dalej się otwiera. Serwer nawet nie mrugnął. To jest cały sens RAID.

Wyjmujemy trupa:

sudo mdadm --manage /dev/md0 --remove /dev/vdc

I wkładamy nowy dysk:

sudo mdadm --manage /dev/md0 --add /dev/vdd
watch cat /proc/mdstat

W /proc/mdstat pojawia się pasek recovery, a w mdadm --detail nowy dysk ma stan spare rebuilding. Jądro kopiuje na niego dane z ocalałego dysku. Kiedy skończy, stan zmienia się na active sync, a lustro wraca do [UU].

Uwaga z dokumentacji Red Hata: jeśli macierz nie przeżyje kolejnej awarii, czyli w lustrze został jeden dysk, to w czasie odbudowy jedziesz bez zapasu. Nie rób wtedy eksperymentów, nie wyciągaj żadnych innych dysków i najlepiej miej świeży backup. Odbudowa mocno męczy ocalały dysk, a dyski z jednej partii lubią umierać parami.

smartctl: badanie okresowe dysku

RAID mówi Ci, że dysk już umarł. A da się wiedzieć wcześniej? Często tak. Dyski prowadzą własny dziennik zdrowia, który nazywa się S.M.A.R.T.: liczą przepracowane godziny, błędy odczytu, uszkodzone sektory, temperaturę. Czytasz go narzędziem smartctl z pakietu smartmontools, w obu rodzinach tak samo.

sudo smartctl -H /dev/sda
sudo smartctl -a /dev/sda
sudo smartctl -a /dev/nvme0

-H to szybka diagnoza w jednej linijce:

SMART overall-health self-assessment test result: PASSED

Albo FAILED!, i wtedy nie czekasz. Zamawiasz dysk dzisiaj.

Ale PASSED to jeszcze nie świadectwo zdrowia. To tylko informacja, że dysk nie przekroczył progów ustawionych przez producenta, a producent ustawia je bardzo wyrozumiale. Jak lekarz, który mówi „żyje pan”. Dlatego admin patrzy w smartctl -a na kilka konkretnych wierszy w tabeli atrybutów. Dla dysków SATA:

W kolumnie RAW_VALUE patrzysz na surową liczbę. Pierwsze trzy wiersze w zdrowym dysku powinny mieć zero.

Dla dysków NVMe tabela wygląda inaczej. Tam patrzysz na Critical Warning, które powinno być zerem, Available Spare, czyli zapas komórek, Percentage Used, czyli szacowane zużycie dysku w procentach, i Media and Data Integrity Errors.

Dysk może też sam się przebadać:

sudo smartctl -t short /dev/sda
sudo smartctl -l selftest /dev/sda

Krótki test trwa minuty, długi (-t long) potrafi trwać godzinami. Wynik czytasz potem przez -l selftest.

I żeby nie musieć pamiętać o badaniach, jest usługa smartd, która robi je za Ciebie i pisze, kiedy coś się pogarsza:

sudo systemctl enable --now smartd

[Ubuntu] Konfiguracja w /etc/smartd.conf, domyślnie z linijką DEVICESCAN, czyli „pilnuj wszystkich dysków, jakie znajdziesz”.

Jak to działa pod spodem

Sterownik md to warstwa w jądrze między systemem plików a dyskami. System plików pisze do /dev/md0 jeden blok. W RAID 1 md wysyła ten blok do obu dysków. W RAID 5 liczy kartkę kontrolną, czyli parzystość, operacją XOR: jeśli masz bajty A i B, to kontrolny jest A XOR B, a z kontrolnego i B zawsze odzyskasz A. Prosta matematyka z liceum ratuje terabajty.

Każdy dysk w macierzy ma swój superblok, nagłówek z UUID macierzy i swoim miejscem w niej. Dlatego po restarcie albo nawet po przeniesieniu dysków do innego serwera mdadm --assemble --scan składa macierz sam, niezależnie od tego, czy dyski nazywają się teraz sdb czy sdx. Podejrzysz to przez mdadm --examine /dev/vdb.

A S.M.A.R.T. to oprogramowanie w samym dysku. smartctl tylko o nie pyta specjalnymi komendami przez kontroler. Dlatego na wirtualnych dyskach, które są plikami na serwerze gospodarza, zwykle usłyszysz „SMART support is: Unavailable”. Wirtualny dysk nie ma czego zgłaszać. Zdrowie prawdziwych dysków sprawdza się na gospodarzu, na przykład na serwerze Proxmox.

Ściąga flag