kopia

Transkrypt

kopia

27.5.2014
LVM na RAID5 i dysku z sektorami 4KB | timor's site
timor's site
Linux configuration, Automation, Security – Sysadmin/DevOps blog
LVM na RAID5 i dysku z sektorami
4KB
HOWTO bash, ext4, Linux, LVM, mdadm, RAID
Po zakupie nowych dysków zamierzam utworzyć zdegradowaną macierz RAID5 z dwóch dysków (na
trzecim na razie znajdują się dane), potem utworzyć wolumen LVM, sformatować go, przekopiować
dane z pojedynczego dysku na macierz i dołączyć trzeci dysk do macierzy odbudowując parzystość.
Zadanie będzie o tyle ciekawe że dysk ma 4KB sektory i trzeb będzie dbać o wyrównanie zasobu do
rozmiaru sektora, a w przypadku LVM’a wyrównanie do chunk’a z macierzy.
7 November 2012
Prawidłowe wyrównanie partycji
Kupując nowy dysk (o pojemności od 500GB w górę), mamy spore szanse że trafimy na sztukę, która
wykorzystuje 4KB sektory do alokacji danych. Ponieważ statystyczny rozmiar przechowywanych plików
rośnie i nawet proste zdjęcie ma powyżej 1MB to wykorzystanie bloków o tym rozmiarze większym niż
512 bajtów jest jak najbardziej uzasadnione – zresztą większość systemów plików i tak wykorzystuje bloki
4~8KB. Jest tylko jedno ALE: jeżeli nie uwzględnimy tego podczas partycjonowania dysku to sektory 4KB
systemu plików zamiast znajdować się w równo w odpowiadających im fizycznych 4KB sektorach dysku
– mogą zachodzić na 2 sektory fizyczne – w takiej sytuacji każde odwołanie to takiego sektora w
systemie plików wymaga odczytania/zapisanie dwóch sektorów fizycznych. Co prawda w dyskach
stosuje się mechanizmy, które powinny zoptymalizować takie sytuacje ale jak potwierdzają benchmarki
źle wyrównane partycja mogą znacznie obniżyć wydajność dysku. A jeszcze zabawniej jest jeśli kupimy
dysk SSD bo w nich bardzo często fizyczne bloki są 128~512KB i żeby było zabawniej to bardzo często
dyski SSD deklarują (choćby przez SMART’a) że mają bloki 512B – SIC!
Jeśli mamy fart i nasz dysk raportuje rozmiar fizycznego sektora to możemy to sprawdzić tak:
1
cat /sys/block/sda/queue/physical_block_size
U mnie to polecenie zwróciło 4096 czyli 4KB co jest zgodne z deklaracją producenta.
Dobre podejście do tematu wyrównania partycji zaproponował Teo Tso czyli wybranie takich
parametrów głowic/sektorów na ścieżce by fdisk automatycznie wyrównywał partycje do oczekiwanej
przez nas wielkości bloku. Teo proponował użycie 224 głowic i 56 sektorów – co da wyrównanie do
128KB dla wszystkich partycji z wyjątkiem pierwszej (pierwsza będzie wyrównana do 4KB o ile nie
wymusimy startu z 256 sektora). Jeżeli mamy dysk z blokami 4KB lub pierwszą partycję zamierzamy
wykorzystać jako np. /boot (gdzie wydajność nie ma aż takiego dużego znaczenia) to jest to ok. Ale jeśli
kompatybilność z DOS’em mamy w poważaniu to możemy w fdisku utworzyć pierwszą partycję
wyrównaną do 128KB lub 1MB.
http://gagor.pl/2012/11/lvm-na-raid5-i-dysku-z-sektorami-4kb/
1/11
27.5.2014
Przeważnie wolałem cfdiska od fdiska (bo po co się męczyć z topornym interfejsem) ale nie udało mi się
skubańca zmusić by tworzył pierwszą partycję w sposób nie kompatybilny z DOS’em. fdisk pomimo
toporności po podaniu liczby głowic i sektorów w ścieżce podpowiedział mi poprawne wyrównanie
partycji (a gdybyśmy posiadali starszą wersję, która nie jest tak sprytna to przynajmniej możemy podać
ręcznie od którego sektora ma zaczynać się partycja).
Wyrównanie do 128KB
1
fdisk -u -H 224 -S 56 /dev/sdX
Opcja -u zmienia domyślną jednostkę na sektory (mamy wtedy mniejsze liczby, które łatwiej się
przelicza). Dla wyrównania do 128KB pierwsza partycja powinna się zaczynać na 256 sektorze. Do
wyrównania do 4KB wystarczy zacząć na 56 sektorze (wystarczające przy części nowszych dysków
twardych).
Wyrównanie do 1MB
Jeśli jednak dysponujemy dyskiem SSD z ciężko powiedzieć jak dużym blokiem to lepiej wykorzystać
wyrównanie do 1MB – zmarnujemy trochę więcej miejsca (tych parę MB jakoś przeżyjemy) ale w tym
rozmiarze na pewno zmieści się każdy sektor (a może nawet Erase Block, który obecnie przeważnie ma
512KB choć zdarzają się sztuki z 4MB). Można to osiągnąć z ustawieniem 64 głowic i 32 sektorów na
ścieżkę, robimy to tak:
1
fdisk -u -H 64 -S 32 /dev/sdX
Pierwsza partycja powinna się zaczynać na 2048 sektorze dla wyrównania do 1MB lub 8192 sektorze jeśli
chcemy zacząć od 4MB.
Po odpaleniu fdiska z tymi parametrami wybieramy opcję n i lecimy dalej zgodnie z podpowiedziami,
np.:
fdisk -u -H 224 -S 56 /dev/sdc
Polecenie (m wyświetla pomoc): m
Polecenie
a zmiana flagi rozruchu
b modyfikacja etykiety dysku BSD
c zmiana flagi kompatybilności z DOS-em
d usunięcie partycji
l wypisanie znanych typów partycji
m wyświetlenie tego menu
n dodanie nowej partycji
o utworzenie nowej, pustej DOS-owej tablicy partycji
p wypisanie tablicy partycji
q zakończenie bez zapisywania zmian
s utworzenie nowej, pustej etykiety dysku Suna
t zmiana ID systemu partycji
u zmiana jednostek wyświetlania/wprowadzania
2/11
27.5.2014
v weryfikacja tablicy partycji
w zapis tablicy partycji na dysk i zakończenie
x dodatkowe funkcje (tylko dla ekspertów)
Polecenie (m wyświetla pomoc): n
Partition type:
p primary (0 primary, 0 extended, 4 free)
e extended
Select (default p):
Using default response p
Numer partycji (1-4, domyślnie 1):
Przyjęto wartość domyślną 1
Pierwszy sektor (2048-15240575, domyślnie 2048):
Przyjęto wartość domyślną 2048
Ostatni sektor, +sektorów lub +rozmiar{K,M,G} (2048-15240575,
domyślnie 15240575): +100M
Polecenie (m wyświetla pomoc): p
Dysk /dev/sdc: 7803 MB, bajtów: 7803174912
głowic: 224, sektorów/ścieżkę: 56, cylindrów: 1214, w sumie
sektorów: 15240576
Jednostka = sektorów, czyli 1 * 512 = 512 bajtów
Rozmiar sektora (logiczny/fizyczny) w bajtach: 512 / 512
Rozmiar we/wy (minimalny/optymalny) w bajtach: 512 / 512
Identyfikator dysku: 0xc3072e18
Urządzenie Rozruch Początek Koniec Bloków ID System
/dev/sdc1 2048 206847 102400 83 Linux
Polecenie (m wyświetla pomoc): w
Tablica partycji została zmodyfikowana!
Wywoływanie ioctl() w celu ponownego odczytu tablicy partycji.
UWAGA: ponowny odczyt tablicy partycji zakończył się błędem 16:
Urządzenie lub zasoby zajęte.
Jądro nadal używa starej tablicy. Nowa tablica będzie używana po
następnym restarcie systemu albo po uruchomieniu partprobe(8) lub
kpartx(8)
Synchronizacja dysków.
P.S. Po co w ogóle partycjonować – można użyć
całych urządzeń
Co prawda w przypadku gdy zamierzam całe dyski poświęcić na RAID’a mógłbym ich nie partycjonować
tylko użyć całych urządzeń i zadbać tylko by mdadm poprawnie się wyrównał (co zresztą robi
automatycznie do 4KB), ale obawiałem się jak względem takich dysków zachowają się inne systemy
które mam zainstalowane na komputerze – nie chciałbym aby przypadkiem uznały że to jakiś
uszkodzony dysk po czym zainicjowały tablicę partycji… Może to nieuzasadniona fobia ale wiem że
względem partycji RAID Autodetect nic takiego mi się nie przytrafi
3/11
27.5.2014
Tworzenie macierzy RAID
Jak już utworzymy pożądane partycje na pierwszym dysku to musimy je powielić na wszystkich
pozostałych dyskach, które zamierzamy włączyć do macierzy – najprościej zrobić to sfdisk’iem:
1
sfdisk -d /dev/sdX | sfdisk /dev/sdY
Przy czym dysk sdX to źródłowy dysk z gotowymi partycjami, a dysk sdY to każdy na którym chcemy
odtworzyć partycje. Można by zrobić na to ładną pętelkę jeśli mamy więcej tych dysków ale celowo tego
nie zrobię bo jak znam życie to kiedyś ktoś to skopiuje ze znakiem nowego wiersza i wrzuci do konsoli…
Teraz tworzę zdegradowaną (z dwóch dysków) macierz RAID5… Ale na dobrą sprawę bezpieczniej
byłoby utworzyć macierz RAID1 z dwóch dysków (o ile miejsca byłoby wystarczająco na przeniesienie
danych) a po przeniesieniu danych na macierz dodanie trzeciego dysku i powiększenie macierzy z
reshapingiem do RAID5 – postanowiłem pominąć takie rozwiązanie bo nie bałem się utraty danych,
miałem dokładną kopię na innej macierzy
Więc tworzymy macierz:
1
mdadm --create /dev/md0 --level=5 --raid-devices=2 --chunk=512k /dev/sdX1 /dev/sdY1
Na dobrą sprawę z powyższych opcji tylko chunk nadaje się do “dopasowania” – ja mam zamiar
utworzyć macierz z dość dużych zasobów (3x2TB) i przechowywać na niej raczej duże pliki więc 512KB
wydaje mi się dobrą wartością. Gdybyśmy jednak potrzebowali większej liczby I/O dla małych pliczków
to mniejsza wartość może być lepsza. Warto zrobić kilka benchmarków dla różnych wartości chunk’a i
dopasować do przewidywanego przez nas obciążenia.
Aby macierz była widoczne już w czasie startu systemu należy dodatkowo wykonać polecenie:
1
mdadm --detail --scan >> /etc/mdadm/mdadm.conf
Warto też w pliku /etc/mdadm/mdadm.conf odkomentować i wpisać jakieś sensowne wartości dla
HOMEHOST, MAILADDR.
I teraz możemy odbudować obraz initrd:
1
update-initramfs -u
Optymalizacja macierzy RAID5
Sam proces tworzenia macierzy może zająć kilka/kilkanaście godzin – dlatego warto mu pomóc
kilkoma zmianami.
speed_limit_xxx
Na pierwszy rzut – domyślne wartości dla minimalnej i maksymalnej prędkości
4/11
27.5.2014
budowania/regenerowania/odtwarzania macierzy RAID5, można je sprawdzić:
1
2
3
4
cat /proc/sys/dev/raid/speed_limit_max
200000
cat /proc/sys/dev/raid/speed_limit_min
1000
Domyślnie jest to minimum 1MB/s i maksimum 200MB/s. Podbijając minimalną prędkość do 10~50MB/s
można kosztem większego obciążenia systemu zmusić macierz by odbudowywała się szybciej. Osobiście
uważam tą optymalizację za mało znaczącą bo cały mechanizm dość elastycznie reaguje na obciążenie
systemu i jeśli nic nie robimy to prędkości odbudowy są dość wysokie. Ale można to zrobić tak:
1
echo 50000 > /proc/sys/dev/raid/speed_limit_min
lub tak:
1
sysctl -w dev.raid.speed_limit_min=50000
stripe_cache_size
Ta optymalizacja pomogła mi dużo – ok. 30% wzrost wydajności macierzy (również w czasie odbudowy
parzystości). Możemy sprawdzić wartość tego parametru, np. tak:
1
cat /sys/block/md0/md/stripe_cache_size
Domyślnie jest to wartość 128 – bida z nędzą, u mnie ustawienie na 32768 (maksymalna wartość tego
parametru) dało największy wzrost wydajności – ale już 8192 znacznie poprawiło wydajność.
1
2
3
4
5
6
7
8
for i in 256 512 1024 2048 4096 8192 16384 32768;
do
echo "Testowanie $i"
echo $i > /sys/block/md0/md/stripe_cache_size
sync
echo 3 > /proc/sys/vm/drop_caches
dd if=/dev/zero of=file bs=1M count=10000
done
Wyłączenie NCQ dla wszystkich dysków w
macierzy
Wydało mi się to nieco kontrowersyjne bo NCQ powinno pomagać przy losowych odczytach/zapisach –
ale zapuściłem test bonnie++ i okazało się że z włączonym NCQ czasy dostępu dla niektórych obciążeń
rosną nawet dziesięciokrotnie! Warto więc sprawdzić tą opcję pod przewidywanym przez nas
scenariuszem obciążenia.
NCQ dla poszczególnych dysków można wyłączyć np. tak:
1
2
3
for d in sdb sdc sdd
do echo 1 > /sys/block/$d/device/queue_depth
done
Wyłączenie cache dyskowych
5/11
27.5.2014
Wyłączenie wbudowanej w dyski pamięci cache akurat nie zwiększa wydajności ale w przypadku awarii
zasilania (lub innej gwałtownej awarii systemu) zwiększa szanse macierzy na przeżycie takiego
incydentu. Obecnie większość systemów plików korzysta z opóźnienia zapisu by bardziej optymalnie
zapisać dane na dysku – dlatego gdy zapisujemy dany to najpierw trafiają one do cache systemowego.
Dopiero po sync’u są przesyłane do cache dyskowego skąd dopiero po pewnym czasie trafiają na dysk.
Wyłączenie pamięci cache na dyskach “usuwa” nam to drugie opóźnienie.
1
hdparm -W0 /dev/sd*
Zmiana parametrów odczytu z wyprzedzeniem
Bardzo ważnym parametrem mającym wpływ na wydajność macierzy jest odpowiednie ustawienie
odczytu z wyprzedzeniem. Obecnie ustawioną wartość możemy sprawdzić tak (wartość wyrażona jest w
512 bajtowych sektorach):
1
blockdev --getra /dev/md0
U mnie domyślnie było 4096 (a na innym starszym systemie tylko 1536) to może być zbyt mało dla
konfiguracji RAID. Większe wartości można ustawić np. tak:
1
blockdev --setra 65536 /dev/md0
A tak można wykonać sprawdzanie, która wartość będzie dla nas najbardziej optymalna:
1
2
3
4
5
6
7
8
9
dd if=/dev/zero of=file bs=1M count=10000
for i in 1536 4096 8192 16384 32768 65536 131072 262144 524288;
do
echo "Testowanie $i"
blockdev --setra $i /dev/md0
sync
echo 3 > /proc/sys/vm/drop_caches
dd if=file of=/dev/null bs=1M
done
Tworzenie zasobu LVM
Mając już macierze tworzę na niej volumen LVM – najpierw przygotowanie zasobu:
1
pvcreate /dev/md0
Jeżeli w /etc/lvm/lvm.conf mamy ustawione opcje:
md_component_detection = 1
md_chunk_alignment = 1
data_alignment_detection = 1
To LVM powinien automatycznie wykryć rozmiar chunk’a z RAID’a i dostosować swoje metadane, oraz
początek danych tak by wszystko było prawidłowo wyrównane względem macierzy.
6/11
27.5.2014
Jeśli nie mamy szczęścia (bardzo stare jajko/LVM) to będziemy musieli użyć opcji –metadatasize i/lub –
dataalignment:
1
pvcreate --metadatasize 500k /dev/md0
Teraz ciekawostka – LVM potrzebuje na 192KB na dane nagłówkowe każdego wolumenu i każdy
utworzony później zasób byłby o te 192KB przesunięty, więc … trafia nasze wyrównanie do 128KB.
Dlatego zmuszamy LVM’a by zaalokował nieco więcej – tutaj 256KB. OK – ale w poleceniu jest 250 – WTF?
I to aby było zabawnie jest to jak najbardziej prawidłowa wartość – nie wiem jaka w tym logika, ale by
metadane zajmowały 256KB podajemy 250k, by zajmowały 512KB podajemy 500k itd…
Inaczej jest z opcją –dataalignment, tutaj najbardziej optymalnie należy podać rozmiar chunk’a*ilość
aktywnych dysków (dla RAID5 odejmujemy jeden) – albo minimalnie rozmiar chunka, np.:
1
pvcreate --dataalignment 512K /dev/md0
Poprawność możemy sprawdzić poleceniem:
1
2
3
pvs /dev/md0 -o+pe_start
PV
VG
Fmt Attr PSize PFree 1st PE
/dev/md0 vgraid lvm2 a- 1,82t 488,89g 512,00k
U mnie 1st PE zaczyna się na 512KB, więc jest OK.
Teraz tworzymy grupę:
1
vgcreate vgraid /dev/md0
Polecenie vgcreate posiada parametr -s który pozwala określić do wielokrotności jakiej wartości będzie
zaokrąglana wielkość wolumenu – wartość ta powinna być wielokrotnością chunk’a z macierzy.
Domyślnie ma ona wartość 4MB więc wszystko będzie ładnie wyrównane.
I możemy zacząć tworzyć volumeny logiczne:
1
lvcreate -L1T -nsrv vgraid
Formatowanie
To teraz formatowanie – tutaj też czasem trzeba się wysilić by utworzony przez nas filesystem działał
możliwie optymalnie na macierzy i bloku o odpowiednim rozmiarze. W przypadku filesystemu na
macierzy są dwa ważne parametry: stride i stripe-width. Stride powinien odpowiadać rozmiarowi
podanemu jako chunk podczas tworzenia macierzy ale wyrażonego w blokach systemu plików
(domyślnie 4KB). Stripe-width powinno być ustawione na: stride * N, gdzie N to ilość aktywnych dysków
w macierzy (dla RAID5 jest to ilość dysków minus 1) – przykładowo dla bloku 4KB i chunk’a 512KB, stride
powinien wynosić 128 (512/4). Z kolei stripe-width dla 3 dysków to 128*(3-1)=256. Prawidłowe dobranie
tych parametrów może dać wzrost wydajności rzędu 40% (według moich testów). Teoretycznie na
nowszych systemach tworzone systemy plików automatycznie powinny wykryć najbardziej optymalne
wyrównanie – możemy więc spróbować puścić format bez tych parametrów i później skontrolować ich
wartości poleceniem:
7/11
27.5.2014
1
tune2fs -l /dev/vgraid/srv
Na początek przykład dla systemu plików dla małych i średnich plików:
1
mkfs.ext4 -E stride=128,stripe-width=256,resize=4T -m0 /dev/vgraid/srv
Jeden dodatkowy parametr to resize – pozwala on zmienić domyślne ustawienie maksymalnego
rozmiaru do którego możemy powiększyć dany filesystem – domyślnie jest to wartość 1000 razy większa
od początkowej wielkości – ciut przekozaczone. Może nie oszczędzi to dużo miejsca na dysku
(kilkadziesiąt/kilkaset MB) ale na pewno skróci czas fsck’a.
Kolejny dodatek to -m0 które wyłącza alokację 5% przestrzeni dyskowej dla root’a i usług systemowych –
po prostu tutaj tego nie potrzebuję a 5% z 1TB to 50GB marnującego się miejsca!
Jeśli wiemy że będziemy przechowywać na danym zasobie tylko stosunkowo duże pliki to można użyć
takich opcji:
1
mkfs.ext4 -E stride=128,stripe-width=256,resize=4T -T largefile -m0 /dev/vgraid/srv
Opcja -T to wykorzystanie szablonów opcji dla tworzenia systemów plików, które można edytować i
dodawać w pliku: /etc/mke2fs.conf. Szablon largefile wykorzystuje mniejszą liczbę inodów dla nowego
filesystemu, jeśli zamierzamy przechowywać głównie duże pliki to zmniejszy to czas formatowania i
późniejszych fsck’ów na tym systemie plików.
Testowanie wydajności
Zalecałbym testowanie wydajności na kolejnych etapach przygotowania dysków i powtarzać te same
benchmarki po każdej zmianie, tak więc testujemy:
1. Na początek wszystkie dyski, z których zamierzamy zbudować RAID’a by wykluczyć ewentualne
“padaki”/uszkodzone kable, itp. Np. hdparm/dd na czystym dysku i dodatkowo iozone/bonnie++
na filesystemie by sprawdzić czy nie skopaliśmy wyrównania partycji.
2. Po zbudowaniu RAID’a powtarzamy testy – na całym urządzeniu (dd) i po sformatowaniu
(iozone/bonnie++) by upewnić się że RAID jest prawidłowo wyrównany (przy czym przy RAID5
możemy się spodziewać wyników przy zapisie niższych niż przy odczycie – jest to OK). Jest to też
dobry moment na sprawdzenie kilku optymalizacji dla macierzy: stripe_cache_size, wyłączenie
NCQ, ustawienia odczytu z wyprzedzeniem, wyłączenie cache dysków – po każdej z tych zmian
ponawiamy benchmarki by upewnić się że uzyskaliśmy poprawę/lub nie.
3. Po przygotowaniu LVM’a – ponawiamy benchmarki na volumenie by upewnić się że nie
skopaliśmy wyrównania partycji/chunk’a/itd…
4. Dopieszczamy opcje formatowania filesystemu i jego montowania (np. noatime, commit, data,
itd) – i znów posiłkujemy się benchmarkami by potwierdzić że pniemy się z wydajnością w górę.
Jeśli myślicie że to dużo to zalecałbym powtórzenie części benchmarków 2~3 krotnie by upewnić się że
wyniki nie odbiegają znacznie od siebie. Dodatkowo powinniśmy czyścić przed każdym banchmarkiem
cache dyskowy aby mieć pewność że lepsze wyniki nie są skutkiem wczytania danych do pamięci. Z tego
samego powodu jeśli uruchamiamy benchmarki to ilość zapisywanych/odczytywanych danych powinna
być minimum 1,5~2 razy większa niż pamieć RAM zainstalowana w systemie by na pewnie wszystkie
dane nie zmieściły się w cache’u. Oczywiście można to zlać ale później nie ma się co dziwić że system
8/11
27.5.2014
działa wolno – a na produkcyjnej maszynie dużo trudniej zaorać całą konfiguracją i utworzyć od
początku z prawidłowym wyrównaniem.
Zalecane jest wykorzystanie IOZone lub Bonnie++ ponieważ testują one nie tylko prosty sekwencyjny
odczyt, ale również tworzenie/kasowanie plików o różnych rozmiarach i w różnej ilości – to pozwala
lepiej sprawdzić opóźnienia występujące przy przewidywanych przez nas obciążeniach oraz upewnić się
że cała zabawa z wyrównywaniem zasobów miała sens. Oczywiście to tylko zalecenia
hdparm
W przypadku macierzy wykorzystanie prostego hdparm’a do testów:
1
hdparm -tT /dev/md0
nie zwróci realnych i sensownych wyników. Pomiar jest zbyt krótki by uzyskać sensowne wyniki – lepiej
wykorzystać dd z dużą ilością danych do odczytu.
dd
Narzędzie jakże prymitywne a tak przydatne. Możemy nim zmierzyć sekwencyjny odczyt/zapis z/do
macierzy i uzyskać bardziej realne wyniki niż hdparm’em. Wystarczy wymusić operację na ok.
dwukrotnie większej ilości danych niż ilość pamięci RAM. Dodatkowo czyścimy cache’e przed i po
mierząc całościowy czas, np. tak:
1
sync; echo 3 > /proc/sys/vm/drop_caches; time (dd if=/dev/zero of=/mnt/test/test
Jest to szczególnie przydatne np. przy dopasowywaniu optymalnej dla nas wartości parametru
stripe_cache_size, wystarczy przygotować odpowiednią pętlę:
1
2
3
4
5
6
for i in 128 256 512 1024 2048 4096 8192 16384 32768;
do
echo "stripe_cache_size $i"
echo $i > /sys/block/md0/md/stripe_cache_size
sync; echo 3 > /proc/sys/vm/drop_caches; time (dd if=/dev/zero of=/mnt/test/test
done
Parametr bs określa bufor wykorzystywany przy operacjach odczytu/zapisu – można go dostosować do
rozmiaru chunk’a/stripe-width/itp.. count określa jak dużo takich buforów odczytać/zapisać – w
powyższym przypadku jest to 10 tys. jednomegabajtowych buforów więc łącznie 10GB.
bonnie++
Bonnie++ wymaga nieco przygotowania ale wyniki w moim przypadku bardzo odpowiadały
rzeczywistym. Co pokrótce trzeba zrobić:
1
2
3
mkdir /srv/test
chown -R guest:guest /srv/test
bonnie++ -d /srv/test -s 16g -m nazwa_maszyny -f -u guest
9/11
27.5.2014
Możemy dodać opcję -b by po każdej operacji wykonywany był sync – to byłoby coś podobnego do
systemów bazodanowych lub pocztowych. Jeżeli chcemy zasymulować standardowe operacje na
plikach to nie potrzebujemy tej opcji.
iozone
W najprostszym wykonaniu:
1
iozone -a
Wykona to serię pomiarów na różnych rozmiarach plików, ilości powtórzeń itd. Najbardziej interesująca
opcją w konfiguracji RAID jest “Stride read”.
1
iozone -S 8192 -t 1
Parametr -S przekazuje rozmiar pamięci cache procesora – wykorzystywany do alokacji pamięci
blokami itp (sprawdzałem czy to cokolwiek pomoże.. ale nie widziałem dużej różnicy).
Parametr -t 1 to benchmark przepustowości dysku a parametr cyfrowy określa liczbę równoczesnych
wątków, które będą odczytywać/zapisywać – można w ten sposób zasymulować np. równoczesny
streaming dla wielu źródeł, itp.
1
iozone -S 8192 -a -s 40960
Tutaj parametr -s wskazuje na jakim rozmiarze pliku w KB ma być prowadzony benchmark – tutaj
40MB.
Podsumowanie
Ogólnie zadowolony jestem że udało mi się to wszystko zebrać w jednym poście bo dotychczas miałem
to zapisane w wielu różnych zakładkach i spory problem gdy potrzebowałem “właśnie tego jednego
polecenia”. Ale niezadowolony jestem z tego że nie udało mi się ustalić całości tego postępowania dla
dysków o sektorach/erase block’ach większych niż 4 KB. Chodzi mi szczególnie o brak jasnego
wyjaśnienia czy RAID5 jest prawidłowo wyrównywany bo według jednych tak właśnie jest, a według
innych tak nie jest. Stąd niektórzy zalecają by stosować format metadanych dla macierzy w wersji 0.9
lub 1.0 zamiast 1.2 ale nie ma jasnych źródeł tego rozumowania. Mam nadzieję że kiedyś uda mi się to
jednoznacznie rozsądzić – na pewno zaktualizuję wtedy tego posta.
Źródełka na których oparłem to
HOWTO
http://serverfault.com/questions/390294/mdadm-raid5-too-slow-when-writing
http://serverfault.com/questions/250707/why-does-mdadm-write-unusably-slow-when-mountedsynchronously
http://serverfault.com/questions/416321/mdadm-raid-5-failed-with-2-drives-while-rebuilding
http://www.cyberciti.biz/tips/linux-raid-increase-resync-rebuild-speed.html
10/11
27.5.2014
http://askubuntu.com/questions/20852/making-stripe-cache-size-permanent
http://h3x.no/2011/07/09/tuning-ubuntu-mdadm-raid56
https://raid.wiki.kernel.org/index.php/Performance
http://www.mjmwired.net/kernel/Documentation/md.txt
http://wiki.hetzner.de/index.php/Partition_Alignment/en
http://www.fhgfs.com/wiki/wikka.php?wakka=PartitionAlignment
O tym że LVM na RAID5 sam się wyrównuje:
http://marc.info/?l=linux-raid&m=126267824425009&w=2
http://www.redhat.com/archives/linux-lvm/2009-September/msg00092.html
MDADM metadata format 1.2 wyrownuje sie do 4KiB:
http://www.redhat.com/archives/linux-lvm/2009-September/msg00092.html
Kalkulator stride’a
http://busybox.net/~aldot/mkfs_stride.html
Format raid’a:
https://raid.wiki.kernel.org/index.php/RAID_superblock_formats
Wyrównanie do 4kb – choć wydaje mi się że gościu robi to na czuja i ledwie mu się udało:
http://blog.bigsmoke.us/2010/05/13/aligning-partitions-with-raid-and-lvm-on-drives-with-4-kb-sectors
2 thoughts on “LVM na RAID5 i dysku z sektorami
4KB”
19 March 2013 at 07:21
ufo99
Świetny art. właśnie stawiam RAID10 na 4 x 2TB dyskach na debianie i to czego mi
zabrakło, to rozwiązanie problemu GPT (fdisk sobie nie radzi), czyli jak prawidłowo
wyrównać czymś innym niż fdisk.
1 April 2013 at 13:23
Dlatego postanowiłem to spisać, by przy kolejnych podejściach nie wymyślać tego
na nowo.
timor
11/11

kopia

Transkrypt

Podobne dokumenty

CloneZilla – klonowanie dysków

Instytut Fizyki\Prac_Komp

karta-sata-pci-raid-4p-wew

Wykład 8 - Politechnika Wrocławska

GParted (Gnome Partition Editor) to darmowy program, który

Instalacja systemy Linux

Zagadnienia - ZSR, Wola Osowińska

JAK ZAINSTALOWAć WINDOWS XP