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ę.
W poprzedniej części) skonfigurowałem macierz dyskową i pozakładałem na niej partycje. Teraz czas na przenoszenie danych
Przesłany: Sie 01, 11:29
Obiecana w ramach pierwszej części informacja o postępowaniu, gdy chcemy dołożyć jeden nowy dysk i zestawić go w macierz z istniejącym. A także uwaga o postępowaniu, gdy przed zakładaniem macierzy mamy już LVM.
Przesłany: Sie 05, 15:13
Właśnie miałem okazję przećwiczyć scenariusz awarii dysku należącego do prostej macierzy RAID. A przy okazji, ponieważ problem dotyczył drivera, a nie samego dysku, spinanie macierzy z powrotem.
Przesłany: Wrz 07, 18:15