Konfigurowanie prostego RAID pod Ubuntu Linuksem - część pierwsza

Dyski potaniały, robiąc backupy ciągle o czymś zapominam, postanowiłem zrobić prosty RAID, by zaasekurować się od fizycznego uszkodzenia dysku. Poniżej szczegółowy opis kolejnych czynności. Testowane na Ubuntu 8.04, gros operacji powinna być podobna na innych dystrybucjach (główna specyfika Ubuntu poniżej dotyczy montowania dysków po UUID, nie jest to krytyczne dla całości).

Cel zabawy

Chcę zestawić dwa dyski jako mirror (RAID 1), chcę też wykorzystywać nad nim LVM do płynnego zarządzania partycjami. Ogólnie, planuję konfigurację podobną np. do opisanej tutaj - szczegółowy opis trochę dalej.

LVM używam od lat, jest to fantastyczna technika tworzenia wirtualnych partycji, którym można płynnie regulować rozmiar, rozpinać je nad kilkoma fizycznymi dyskami, eksperymentować z różnymi filesystemami - itd. W szczególności LVM w całości zastępuje RAID 0 (dając większą odeń funkcjonalność).

Mam o tyle łatwą sytuację, że wsadziłem dwa nowe dyski do komputera działającego na razie na starym dysku (stary dysk planuję później wyjąć i wykorzystać gdzie indziej). Postępowanie, gdy dokładamy drugi dysk do używanego, a także, gdy chcemy instalować nowy system od zera od razu na macierzy, opiszę w jednej z dalszych części.

Uwagi wstępne

Użytkownik Linuksa ma trzy techniki RAID do wyboru:

• prawdziwy hardware RAID (drogi, najtańsze karty to ok. 300$)
• fałszywy hardware (fake-RAID) - dostępny na niektórych płytach głównych, także w formie tanich kart (np. Adaptecowe HostRaid)
• czysto softwareowy RAID

Hardware RAID zapewnia najlepszą wydajność ale wydawanie na kartę więcej niż na dyski uznałem za przesadę. Rozwiązanie to ma też jedną wadę - w razie awarii kontrolera trzeba zakupić drugi identyczny kontroler, dysków nie da się np. przełożyć do innego komputera. Softwareowy RAID można zrekonstruować gdziekolwiek.

Fake RAID jest de facto softwareowym RAID-em, całą synchronizację obsługuje procesor. Rozwiązanie to jest właściwie plombą umożliwiającą implementację softwareowego RAID pod Windows. Można go używać pod Linuksem (patrz pakiet dmraid i jego dokumentacja, także strona FakeRaidHowto). Jako że rozwiązanie to nie daje zauważalnych korzyści w porównaniu z czysto softwareowym RAID (zalecane jest głównie, gdy ktoś ma maszynę dual-boot i chce używać tej samej macierzy pod Linuxem i pod Windows na zmianę), a utrudnia nieco konfigurację (min. polega na ustawieniach BIOSu) i jest mniej popularne - odpuściłem sobie.

Software RAID to czysto Linuksowe rozwiązanie, z RAID implementowanym przez dedykowany program wsparty przez jądro Linuksa. Odpowiednim narzędziem jest mdadm. Tego mechanizmu będę używał.

Przygotowanie

Kupiłem i wsadziłem do komputera nowe dyski (dbając by na razie stary był podpięty jako SATA1), uruchomiłem komputer, sprawdziłem, że są poprawnie widziane przez BIOS i przez Linuksa.

W ramach dygresji, zareklamuję dyski Samsunga z rodziny SpinPoint. Ich naprawdę prawie nie słychać....

Zainstalowałem potrzebne narzędzia:

$ sudo apt-get install mdadm lvm2 parted gparted

Partycjonowanie

RAID można zestawić na dwa sposoby - bądź parując całe dyski, bądź też partycjonując je i zestawiając w RAID wybrane partycje. Parowanie dysków upraszcza nieco konfigurację, ale poza tym nie ma chyba istotnych zalet. Parowanie partycji daje pewne korzyści:

• można w razie potrzeby (przy wymianie uszkodzonego napędu) dołożyć nowy dysk innej wielkości, po prostu tworząc na nim tak samo dużą partycję,

• mogę w oparciu o tą samą parę dysków zestawić dwa niezależne mirrory (w moim wypadku będzie to mały mirror niewielkich partycji startowych, przeznaczonych do bootowania - i niezależny, duży mirror, nad którym postawię LVM),

• przy włożeniu takiego dysku do innego komputera, nawet z innym systemem, zostanie rozpoznana tablica partycji.

Bootowanie z LVM jest ponoć możliwe, ale skomplikowane i prowokujące problemy przy upgrade czy rekonfiguracjach. Mała partycja bootująca należąca do RAID-1 może być nawet czytana przez BIOS jako zwykły, nie należący do macierzy dysk.

Uruchamiłem gparted (jak ktoś woli command-line, może użyć parted), wybrałem pierwszy z nowych dysków (/dev/sdb). Założyłem na nim trzy partycje:

• pierwszą wielkości 10240 MB (pod przyszły boot)
• drugą wielkości 4096 MB (pod swap, patrz komentarz niżej)
• trzecią zajmującą resztę dysku (pod przyszłe dane) - zgodnie z widzianym gdzieś zaleceniem zaokrągliłem to leciutko w dół (ewentualny przyszły dysk na wymianę może mieć odrobinę mniejszą pojemność)

Wszystkie partycje skonfigurowałem jako primary, pierwszą i trzecią zostawiłem niesformatowane, drugą sformatowałem jako swap.

Swap mógłbym zrobić już na LVM, ale nie jestem jeszcze zdecydowany, czy będę chciał go mieć na RAID. Swap na RAID oznacza nieco wolniejsze działanie systemu, swap bez RAID to crash w razie awarii dysku, na którym jest swap. W każdym razie, wydzielenie go na osobną partycję, zostawia mi wolną rękę.

Tak samo spartycjonowałem drugi dysk. W obu wypadkach przed założeniem partycji gparted spytał o zgodę na założenie etykiety dysku (czyli tablicy partycji).

Po zweryfikowaniu, że partycje na obu dyskach mają parami ten sam rozmiar, nakazałem gparted zastosować zmiany. Partycje zostały utworzone.

Zostało jeszcze przeklikanie się przez wszystkie cztery partycje na dane (swapa na razie nie RAID-uję) i ustawienie im typu Linux RAID. W przypadku gparted oznaczało to prawy klik, Manage Flags, raid. Analogicznie oznaczyłem pierwsze partycje z obu nowych dysków jako bootowalne.

Inicjalizacja macierzy

Dwie proste komendy (inicjalizuję dwa niezależne mirrory):

 $ mdadm --create --verbose /dev/md0 --level=1 \
         --raid-devices=2 /dev/sdb1 /dev/sdc1

 $ mdadm --create --verbose /dev/md1 --level=1 \
         --raid-devices=2 /dev/sdb3 /dev/sdc3

Można się tu zastanawiać nad rozmiarem bloku (np. nad --chunk=256). Są tu możliwe różnice w wydajności, zależne od rodzajów dysków, rozmiaru ich cache, profilu wykorzystania. Patrz np. ta dyskusja Ostatecznie jednak zostałem przy defaultach.

Po puszczeniu komend zerknąłem parę razy na /proc/mdstat, wizualizujące pierwszą synchronizację dysków. Zostawiłem to na razie w spokoju. Małe partycje zsynchronizowały się szybko, dużym zajęło to dwie godziny.

Mimo trwającej synchronizacji (będącej na razie kopiowaniem pustki), partycji można już używać, co po części robiłem.

Zerknąłem też na /etc/mdadm/mdadm.conf. Zostawiłem domyślne ustawienia (autodetekcja), zmieniłem MAILADDR (adres wysyłania alarmów).

MAILADDR może specyfikować tylko jeden adres email. Dlatego najwygodniej jest wpisać tu coś specyficznego, na przykład

 MAILADDR diskalarm

a następnie zmapować ten adres jako alias pocztowy, np. (Postfix) wpisać to /etc/aliases:

 diskalarm root, mymail@gmail.com

i wykonać newaliases. No i przetestować

 mail diskalarm

Formatowanie partycji na RAID

Mniejszą partycję chcę wykorzystywać bezpośrednio. Tedy:

 $ mkfs.ext3 /dev/md0

W przypadku RAID5 ma sens przypatrzenie się niektórym zaawansowanym opcjom (rozmiary bufora, ilości bloków). Widziałem np. sugestię by dla domyślnego chunka 64kB (parametr mdadm) podać

   $ mkfs.ext3 -b 4096 -E stride=16 /dev/md0

(iloczyn 16 * 4096 daje pełny chunk). Dla RAID1 nie wydaje się to istotne, charakterystyka wykorzystania jest podobna jak przy pojedynczym dysku.

Od tej chwili /dev/md0 mogłem normalnie zamontować i używać. Dla testu:

 $ mount /dev/md0 /mnt
 $ echo "Test" > /mnt/test.file
 $ umount /mnt

Konfiguracja LVM

Przerobiłem drugą z partycji raidowych na fizyczny wolumen LVM:

 $ pvcreate /dev/md1

Stworzyłem grupę LVMową, dodając od razu do niej powyższy wolumen:

 $ vgcreate vgmk /dev/md1

(nazwa grupy - tu vgmk - może być dowolna, warto użyć czegoś w miarę nietypowego, a przynajmniej innego niż częste w dokumentacji vg - jeśli będziemy kiedykolwiek musieli przełożyć dyski do innego komputera, nie podmontujemy ich jeśli będzie na nim grupa o tej samej nazwie)

Zweryfikowałem ich status:

 $ vgdisplay vgmk
 $ pvdisplay /dev/md1

Zacząłem zakładać partycje (logiczne wolumeny). Nie będę tu drobiazgowo opisywał mojej konfiguracji, ale były to operacje typu:

 $ lvcreate --size 20G --name vgmkhome vgmk
 $ mkfs.ext3 /dev/vgmk/vgmkhome

(po czym np. mount /dev/vgmk/vgmkhome /mnt).

Występuje pewien dualizm nazewniczy, można pisać /dev/vgmk/vgmkhome albo /dev/mapper/vgmk-vgmkhome, oba zapisy działają i odnoszą się do tej samej partycji. Z przyzwyczajenia (z czasów jeszcze LVM1) stosuję ten pierwszy zapis, bardziej oficjalny jest chyba ten drugi (i to jego lepiej stosować w /etc/fstab).

Listę stworzonych partycji i ich rozmiary można w dowolnym momencie sprawdzić poleceniem

 $ lvdisplay

(albo po prostu ls /dev/vgmk/)

Przy używaniu LVM dość naturalne jest tworzenie stosunkowo dużej ilości partycji, np. robienie dedykowanej partycji dla bazy danych, dedykowanej na katalog logów, dedykowanej na tmp (o ile nie używamy tmpfs) itd. Pozwala to wykorzystywać różne filesystemy, niezależnie ograniczać rozmiar różnych obiektów, z większą granulacją wykonywać niektóre operacje administracyjne. Oczywiście - każdy ma tu swoje preferencje.

Uwaga: formatowanie przy pomocy mkfs.ext3 odbywa się bez żadnych potwierdzeń, przy pomyleniu formatowanej partycji można sobie w ten sposób zniszczyć dane. Dlatego zalecam założenie i sformatowanie wszystkich partycji przed rozpoczęciem kopiowania danych. Alternatywą jest założenie partycji przy pomocy lvcreate a następnie formatowanie ich w gparted.

To ostatnie jest niewygodne, gparted wyświetla LVMową partycję jako dysk, chcąc tworzyć w jej wnętrzu tablicę partycji (oczywisty nonsens). Można oszukiwać robiąc disklabel typu loop a następnie dodając jedną partycję ale jest to kłopotliwe.

Natomiast bardzo wygodnie można w gparted przejrzeć, które logiczne wolumeny są już sformatowane, a które nie.

Przegenerowanie initramfs

Zgodnie z wyczytaną gdzieś poradą, uruchomiłem (mając już działającą macierz)

$ dpkg-reconfigure mdadm

Efektem polecenia było przegenerowanie na nowo initramfs (z umieszczeniem tamże mdadm montującego moją macierz). Nie jestem pewien, czy nie zrobiło się to automatycznie wcześniej, ale przynajmniej w starszej wersji Ubuntu tak się niekiedy nie działo.

Na systemach spoza rodziny Debiana trzeba przegenerować initramfs w odpowiedni dla nich sposób (mkinitramfs ?).

Wstępne podsumowanie

RAID działa, LVM działa, mam pozakładane nowe partycje, można je montować. Ciąg dalszy - za chwilę.