Lekcja 14: Strojenie I/O serwerów AIX/VIO z SDDDRV lub SDDPCM

Celem tego dokumentu jest prezentacja sposobu, w jaki IO jest przechowywane w kolejkach SDD, SDDPCM, sternika dysku oraz sternika adapterów dysków w celu wytłumaczenia jak manipulować tymi elementami w celu zwiększenia ich wydajności. Informacja prezentowana w tym dokumencie jest również użyteczna w przypadku maszyn nieużywających SDD i SDDPCM.


Od tłumacza:
Nie mając kontraktów z polską terminologią komputerową, użyłem następujące terminy jako najbliższe ich amerykańskich originałów:

sternik – device driver,
stos – stack,
wydajność – throughput
kolejka procesów obecnie obsługiwanych (kolejka obsługi) – service/working queue
kolejka procesów czekających na obsługę – waiting queue
liczba IO na sekundę – IOPS
cache – cache (specjalny rodzaj pamięci przechowującej dane mogące być ponownie użyte lub w oczekiwaniu ich użycia)
nurt pojedynczy – single threaded


Kolejność kolejek w stosie IO
Poniżej przedstawione są warstwy stosu IO:
                  Aplikacja
                  Folder
                  Manager Tomów Logicznych (nieobowiązkowy)
                  SDD lub SDDPCM (jeżeli użyty)
                  Kierownik hdisku
                  Kierownik adaptera
                  
                  System przechowujący dane
                  fig.1
Zwróć uwagę, że pomimo że dysk jest podłączony do adaptera, sternik hdisku jest użyty wcześniej niż sternik jego adaptera. Powyższy stos przedstawia kolejność egzekucji sterników na trasie przekazu danych. Dlaczego powinniśmy żądać od dysku więcej niż jedno IO?
Ponieważ to polepsza wydajność. Wydajność z punktu widzenia aplikacji. To jest szczególnie ważne w przypadku instalacji gdzie jeden wirtualny dysk (czy LUN) jest w rzeczywistości zbiorem wielu fizycznych dysków. W takiej sytuacji, jeżeli moglibyśmy wydać w danym czasie tylko jedno IO to szybko byśmy się przekonali, że mamy bardzo dobry czas jego obsługi bardzo niską wydajność.
Możliwość jednoczesnego wydania kilku IO do tego samego dysku, pozwala mu na ograniczenie ilości wymaganych do tego celu ruchóch jego głowicy (używając do tego celu algorytmu “windy”) pozwalając na większą liczbę operacji IO niż w przypadku indywidualnych poleceń IO wykonywanych jedno naraz. Użycie w tym przykładzie windy jest bardzo odpowiednie. Jak długo ludzie musieliby czekać na windę w przypadku kiedy jej użycie było ograniczone do tylko jednej osoby naraz? W takiej sytuacji, czas spędzony w kolejce na windę byłby długi (queueing time / czas w poczekalni), ale po wejściu do windy każda osoba szybko znalazłaby się na swoim docelowym piętrze (service time / czas obsługi).


Gdzie jest przechowywane IO?
AIX musi wiedzieć, w którym miejscu znajduję się obsługiwane przez niego obecne polecenia IO. Z uwagi na to, polecenia IO są przechowywane w kolejkach na każdym etapie jego podróży (fig.1). Ogólnie mówiąc, kolejka każdego etapu jest w stanie pomieści ograniczoną liczbę poleceń IO, pozostałe IO zostają przesłane do kolejki poleceń czekających na obsługę do czasu aż zwolni się miejsce w kolejce poleceń obsługiwanych danej warstwy stosu. Z czego wynika, że każda warstwa posiada dwie kolejki – kolejkę poleceń obsługiwanych oraz kolejkę poleceń czekających na obsługę (SDD oraz SDDPCM są nieco bardziej skomplikowane).

Na poziomie folderu (file system), jego własne kolejki ograniczają maksymalną liczbę możliwych do wydania poleceń IO – indywidualnie na poziomie każdego foldera. W warstwie SDD, IO jest przechowywane w jego własnych kolejkach, jeżeli wartość jego atrybutu queue_depth jest ustawiona na ‘yes’ (to jest również wartość domyślna tego atrybutu). Wcześniejsze wersje SDD nie posiadają własnych kolejek IO. SDDPCM w przeciwieństwie do SDD nie posiada żadnych kolejek służących do przechowywania IO przed przekazaniem go sternikowi dysków. Dyski mają swoją własną, maksymalną liczbę poleceń IO, które są w stanie obsłużyć określoną wartością atrybutu queue_depth. W przypadku adapterów FC ta kolejka nazywa się num_cmd_elements. Poniżej pokazane są atrybuty dysku typu ESS:

# lsattr -El hdisk33
PR_key_value none Reserve Key True
location Location Label True
lun_id 0x5515000000000000 Logical Unit Number ID True
lun_reset_spt yes Support SCSI LUN reset True
max_transfer 0x40000 N/A True
node_name 0x5005076300c096ab FC Node Name False
pvid none Physical volume identifier False
q_type simple Queuing TYPE True
qfull_dly 20 delay in seconds for SCSI TASK SET FULL True
queue_depth 20 Queue DEPTH True
reserve_policy single_path Reserve Policy True
rw_timeout 60 READ/WRITE time out value True
scbsy_dly 20 delay in seconds for SCSI BUSY True
scsi_id 0x620713 SCSI ID True
start_timeout 180 START unit time out value True
ww_name 0x5005076300cd96ab FC World Wide Name False

W przypadku queue_depth, jej wartość domyślna wynosi 20, w przypadku ESS, DS6000 czy DS8000 jej wartość może osiągnąć wartość równą 256. Poniżej, możesz się zapoznać z atrybutami typowego adaptera FC:

# lsattr -El fcs0
bus_intr_lvl 65703 Bus interrupt level False
bus_io_addr 0xdec00 Bus I/O address False
bus_mem_addr 0xe8040000 Bus memory address False
init_link al INIT Link flags True
intr_priority 3 Interrupt priority False
lg_term_dma 0x800000 Long term DMA True
max_xfer_size 0x100000 Maximum Transfer Size True
num_cmd_elems 200 Maximum number of COMMANDS to queue to the adapter True
pref_alpa 0x1 Preferred AL_PA True
sw_fc_class 2 FC Class for Fabric True

Wartość domyślna queue_depth (num_cmd_elems) w przypadku adapterów FC wynosi 200, ale może być zwiększona do 2048. Poniżej, pokazane są atrybuty urządzenia dpo pewnej wersji SDD:

# lsattr -El dpo
Enterpr_maxlun 600 Maximum LUNS allowed for Enterprise Products True
Virtual_maxlun 512 Maximum LUNS allowed for Virtualization Products False
persistent_resv yes Subsystem Supports Persistent Reserve Command False
qdepth_enable yes Queue Depth Control True

W przypadku kiedy qdepth_enable=yes, SDD przekaże do znajdującego się pod nim hdisk nie więcej poleceń IO niż wartość atrybutu queue_depth (gdzie queue_depth to wartość atrybutu queue_depth danego hdisk). Kiedy qdepth_enable=no, SDD przekazuje IO bezpośrednio do podlegającego mu hdisku. Czyli, różnica jest taka: jeżeli qdepth_enable=yes (wartość domyślna), IO przewyższające queue_depth będzie czekać w kolejkach SDD, jeżeli zaś qdepth_enable=no to IO przewyższające queue_depth będzie skierowane do kolejek własnych hdisk. Mówią inaczej, SDD z qdepth_enable=no i SDDPCM nie przechowują nadmiaru IO – nadmiar IO przekazują one do kolejek hdisków.
Zwróć uwagę, że do modyfikacji qdepth_enable używając SDD 1.6 polecam użycie polecenia datapath w miejsce chdev, ponieważ to pierwsze pozwala na wykonanie tej zmiany bez potrzeby zastartowania maszyny czy tego adaptera – datapath set qdepth disable ustawi jego wartość na ‘no’. Niektóre wersje SDD nie posiadają swoich własnych kolejek, niektóre je posiadają a jeszcze inne nie pokazują tego atrybutu. Sprawdź dokumentację twojej wersji lub spróbuj czy polecenie datapath jest w stanie wykonać tę zmianę.

Jeżeli używałeś SDD i SDDPCM, to może pamiętasz, że w przypadku SDD każda LUN jest związana z vpath, który z kolei jest związany (path) z jednym czy więcej hdiskami. W przypadku SDDPCM każdy hdisk reprezentuje tylko jedną LUN. W związku z czym, w SDD możesz wydać LUNie liczbę poleceń IO równającą się queue_depth x (liczba paths/hdisks), podczas gdy w przypadku SDDPCM można tylko przekazać do LUN liczbę IO nie większą niż queue_depth. Po zmianie sternika z SDD z czteroma ścieżkami (paths) na SDDPCM powinieneś ustawić queue_depath każdego SDDPCM hdisku na 4 * jej wartość w przypadku SDD. Polecam migrację do SDDPCM, którego użycie jest od dłuższego czasu preferowane przez AIX.

Zarówno hdisk, jak i sternik jego adaptera posiadają kolejki “obecnie obsługiwanych” i “czekających na obsługę” poleceń IO. Po wyczerpaniu się pojemności kolejki obecnie obsługiwanych IO, następne IO musi czekać na zakończenie obecnie obsługiwanego IO. Powstałe z tej przyczyny wolne miejsce zajmuje pierwsze IO przechowywane w kolejce IO czekającego na obsługę. Kolejka “obecnie obsługiwanych procesów jest również znana jako kolejka “obsługi”.

Warto powiedzieć, że wiele aplikacji nie produkuje ciągłego strumienia IO, szczególnie dotyczy to aplikacji pracujących zgodnie z protokołem jednej nurtu (single threaded) i nieużywających asynchronicznego IO. Aplikacje używające asynchronicznego IO z reguły produkują praktycznie stały strumień IO.

Jakimi narzędziami możemy monitorować kolejki?
Do monitorowania kolejek można użyć “iostat” w przypadku AIX (wer.5.3 lub później), lub “sar” (wer.5.1 lub później). Typowy output polecenia iostat -D jest pokazana poniżej:

hdisk6 xfer: %tm_act bps tps bread bwrtn
4.0  2.2M &nbsp19.0 &nbsp0.0 &nbsp2.2M
read: rps avgserv minserv maxserv timeouts fails
 &nbsp0.0 &nbsp0.0 &nbsp0.0 &nbsp0.0 &nbsp0 0
write: wps avgserv minserv maxserv timeouts fails
 &nbsp19.0 &nbsp38.9 &nbsp1.1 &nbsp190.2 &nbsp0 0
queue: avgtime mintime maxtime avgwqsz avgsqsz sqfull
15.0 &nbsp0.0 &nbsp83.7 &nbsp0.0 &nbsp0.0 &nbsp136

W powyższym przykładzie, avgwqsz to średnia liczba poleceń IO w kolejce IO czekającego na obsługę, a avgsqsz to średnia liczba poleceń IO w kolejce IO będącego w trakcie obsługi. Wartość sqfull uległa zmianie, początkowo reprezentując liczbę wydanych poleceń IO w czasie kiedy kolejki były już pełne a obecnie reprezentuje ona przyrost (ratę) IO wydanego w czasie kiedy kolejki były wypełnione.
Pokazany powyżej output, przedstawia wcześniejszy przypadek (pewna liczba IO została wydana podczas pełnej kolejki), podczas kiedy nowe wersje, systemu operacyjnego pokazują wartości dziesiętne deklarujące przyrost (rate). To dobrze, że iostat -D pokazuje oddzielnie czytanie i zapis danych, ponieważ oczekujemy, że czas obsługi IO jest funkcją (między innymi) tego czy system dysków jest wyposażony w cache czy też nie. Najbardziej przydatnym z punktu widzenia strojenie systemu IO jest output polecenia iostat -D, który jest w stanie dostarczyć statystykę od czasu startu systemu, zakładając, że system jest skonfigurowany do ciągłego przechowywania historii IO.

Polecenie sar -d uległo zmianie w AIX5.3 i obecnie jego output wygląda następująco:

16:50:59  device %busy avque  r+w/s Kbs/s avwait avserv
16:51:00 hdisk1    0   0.0    0     0      0.0    0.0
       hdisk0      0   0.0    0     0     0.0     0.0

Kolumny avwait i avserv przedstawiają średni czas spędzony w kolejce poleceń czekających na obsługę oraz w kolejce poleceń obecnie obsługiwanych. Wartości w kolumnie avserv odpowiadają wartością w kolumnie avgserv produkowanej przez polecnie iostat. Wartość kolumny avgue uległa zmianie. W AIX5.3 reprezentuje ona średnią liczbę poleceń IO przechowywanych w kolejce poleceń czekających na obsługę. Natomiast, przed AIX5.3 wartości w tej kolumnie reprezentowały średnią liczbę IO kolejki poleceń obsługiwanych.

SDD posiada polecenia datapath query devistats oraz datapath query adaptstats pokazujące statystyki kolejek hdisków i adapterów FC. W przypadku SDDPCM mamy polecenia pcmpath query devstats oraz pcmpath query adaptstats. Więcej informacji na ten temat możesz odtrzymać czytając odpowiednią dokumentację. Poniżej, możesz zobaczyć output polecenia devstats w przypadku jednej LUN:

Device #: 0
=============
Total Read Total Write Active Read Active Write Maximum
I/O: 29007501 3037679 1 0 40
SECTOR: 696124015 110460560 8 0 20480


Transfer Size: <= 512 <= 4k <= 16K <= 64K > 64K
21499 10987037 18892010 1335598 809036


and here’s some adaptstats output:


Adapter #: 0
=============
Total Read Total Write Active Read Active Write Maximum
I/O: 439690333 24726251 7 0 258
SECTOR: 109851534 960137182 608 0 108625


Patrząc na powyższy output, jesteśmy najbardziej zainteresowani kolumną Maximum, która podaje nam maksymalny numer IO dostarczonego do urządzenia od momentu startu maszyny. UWAGA: Maksymalna wartość (Maximum) dla devstats nie przekroczy (queue_depth x liczba ścieżek (hdisków)) w przypadku SDD z qdepth_enable=yes. Zauważ, że Maximum dla adapterów może przekroczyć num_cmd_elems, ponieważ reprezentuje ono maksymalną liczbę poleceń IO wydanych adapterowi i przechoywanych w jego dwóch kolejkach: kolejka poleceń obsługiwanych i kolejka poleceń czekających na obsługę. W takim przypadku, jeżeli mamy 2 ścieżki queue_depth=20 to 40 wskazuje, że wypełniliśmy kolejkę co najmniej raz i z tego powodu jej zwiększenie pomoże polepszyć wydajność systemu IO.

W podobny sposób można monitorować kolejki adaptera oraz ich IOPS. Szukając IOPS adaptera, wydaj polecenie iostat -at . Do wyprodukowania statystki kolejek danego adaptera, należy wydać polecenie iostat -aD, na życzenie możesz też dołączyć czas repetycji i ich liczbę.

Jak stroić?
Po pierwsze, nie należy bezkrytycznie zwiększać tych wartości. Rezultatem takiej akcji może być przeciążony system dysków czy problemy podczas startu maszyny. Sumowanie queue_depth wszystkich hdisków i użycie tego numeru do określenia wartości num_cmd_elems nie jest najrozsądniejszym rozwiązaniem. Strojąc system IO, lepiej nadaje się użycie maksymalnej wartości poleceń IO wydanych każdemu urządzeniu. Powiększenie wartości queue_depth wraz ze zwiększaniem liczby IO spowoduje zwiększenie się czasu obsługi IO przy zwiększonej wydajność. Kiedy czas obsługi IO zacznie się zbliżać do wartości timeout dysku to znaczy, że otrzymuje on więcej pleceń IO niż jest w stanie obsłużyć. Poprzednio zwiększone atrybuty należy zmniejszyć w przypadku pojawienia się IO timeouts oraz pojawienia się w errorlog informacji o niemożliwości ukończenia IO. Jeżeli ta akcja nie zmieni sytuacji, należy skupić swoją uwagę na analizę dysków.

Najlepsze metoda do strojenia queue_depth w przypadku małych, przypadkowych poleceń czytania czy zapisania danych to jej zwiększanie do momentu, w którym czas obsługi IO nie przekroczy 15ms lub kolejki nie ulegną wypełnieniu. Moment, w którym czas obsługi IO ulegnie widocznemu zwiększeniu oznacza osiągnięcie stanu, w którym dyski maszyny, ich adaptery i ich kolejki nie są już odpowiedzialne za jakość IO. Ta odpowiedzialność spoczywa teraz na środowisku SAN. Strojenia queue_depth można dokonać używając jednej z dwóch metod: 1) strojenie aplikacji (program) – dostosuj charakterystyki aplikacji zgodnie z charakterystyką twojego SANu. 2) używając narzędzia do testowania, określ maksymalne obciążenie, pod którym może pracować twój SAN i odpowiednio do tej wartości dostosuj kolejki danej maszyny. Takim narzędziem, jest na przykład ndisk – będący częścią zestawu nstress, który można pobrać z – http://www-941.ibm.com/collaboration/wiki/display/WikiPtype/nstress[/lang_pl
Pamięci podręczne (caches) wpływają na czas obsługi IO a tym samym na rezultaty twoich testów. Celność pamięci podręcznej w przypadku czytania danych zwykle ulega poprawie przy ponownej egzekucji testu co ma duży wpływ na powtarzalność wyników testów. Pamięć podręczna pisania danych pomaga wydajności do momentu, w którym jej pojemność ulegnie wyczerpaniu co natychmiast spowoduje degradację wydajności IO. Z tych przyczyn, długo trwające testy są dokumentują zmniejszającą się w funkcji czasu wydajności IO. W przypadku pamięci podręcznej czytania należy ją gruntować czy (co jest preferowane) opróżnić. W przypadku pamięci podręcznej pisania danych, rozważ potrzebę jej obserwacji w celu określenia czy ona wypełnia się szybciej niż polecenia zapisu są przekazywane do dysków. Strojąc systemy przechowujące dane, z których korzysta wielu użytkowników należy pamiętać, że wiarygodność testów jest uzależniona od IO maszyn korzystających z tego samego systemu dysków.

W przypadku SDD, jeżeli zauważysz analizując wyniki polecenia devstats, że Maximum = queue_depath x (liczba ścieżek/hdisków) oraz, że qdepth_enable=yes to wskazuje, że zwiększenie wartości queue_depth może zwiększyć wydajność hdisków – a w najgorszym przypadku spowoduje to, że IO zamiast gromadzenia się w kolejkach systemu operacyjnego będzie się gromadzić w kolejkach dysków. Nic nie stoi na przeszkodzie jednorazowemu zwiększeniu pojemności kolejek o 50% ich aktualnej wartości.

Mówiąc o parametrze qdepth_enable, jego wartość domyślna to ‘yes’ co znaczy, że sternik SDD obsługuje IO powyżej queue_depth. Ustawienie tej wartści na no powoduje, że to IO jest obsługiwane przez strnika hdisków. Mówiąc innymi słowami, SDD obsługuje kolejki czekającego na obsługę IO, kiedy queue_enable=yes, a w wypadku przeciwnym robi to sternik dysków. W przypadku dużej ilośći IO połączonej z dużą aktywnością kolejek SDD (qdepth_enable=yes) pozwolenie sterownikowi hdisków na obsługę relatywnie krótkich kolejek IO czekającego na wykonanie jest wydajniejsze niż pozwolenie SDD (qdepth_enable=no) obsługiwać jego własne, długie kolejki. Innymi słowami, SDD obsługuje swoje kolejki w trybie pojedynczego nurtu (single threaded) co znaczy, że kolejka każdego z jego dysków jest obsługiwana przez jeden strumień (thread).

Jeżeli zależy ci, żeby system był w stanie reagować na błędy środowiska SAN oraz zakładając, że dysk jest podłączony do przekaźnika (switch) SAN – to ustaw wartość atrybutu fc_err_recov=fast_fail w miejsce jego wartości domyślnej czyli delayed_fail. Jeżeli zdecydowałeś się na tę zmianę, to polecam ci zmianę atrybutu dyntrk adaptera logicznego fscsi na yes w miejsce jego wartości domyślnej – no. Oczywiście, przekaźnik SAN musi być w stanie rozumieć i reagować na te atrybuty.

W przypadku adapterów, spójrz na kolumnę nazwaną adaptstats i ustaw num_cmd_elems=Maximum lub 200, cokolwiek jest większe. W przeciwieństwie do devstats mającego qdepth_enable=yes, Maximum dla adaptstats może przekroczyć num_cmd_elems.

Po tych wszystkich zmianach, pozwól pracować twoim aplikacją, po czym spójrz ponownie na jej statystyki IO w czasie jej największego użycia.

Do ustalenia potrzeby zwiększenia wartości queue_depth można również użyć poleceń iostat -D oraz sar -d.

Negatywną cechą dania atrybutowi queue_depth za dużej wartośco jest to, że system przechowywania danych nie będzie w stanie w porę obsługiwać IO oraz może nawet dojść do sytuacji, w której polecenia IO są ignorowane czy nawet odrzucane. Rezultatem tego będzie przestój IO co z kolei spowoduje egzekucję funkcji mających na celu odzyskanie straconych poleceń IO. To nie jest pożądana sytuacja, w której CPU musi wykonać więcej pracy związanej z IO niż to naprawdę jest konieczne. Ewentualnie, system operacyjny nie będzie w stanie obsłużyć IO powodując katastrofalną awarię aplikacji czy systemu operacyjnego.

Pojemność kolejek w przypadku VIO
Używając VIO, administrator tworzy adaptery VSCSI (każdy wirtualny adapter po stronie VIOS (VIO Serwer) ma swój odpowiednik w adapterze VSCSI po stronie jego klienta (VIO Client). Te adaptery mają kolejki, których pojemność jest ustalona w funkcji ilości przypisanych adapterowi VSCSI LUNs.
Z 512 poleceń (komend) 2 są użyte przez adapter, każda VSCSI LUN w celu naprawy błędów rezerwuje dla siebie 3 elementy, reszta jest przeznaczona na polecenia IO. Jeżeli wartość queue_depth każdej VSCSI LUN wynosi 3 (wartość domyślna) to FC adapter jest w stanie kontrolować 85 LUN = (512 -2) / (3 + 3) =85 (zaokrąglone w dół). Jeżeli LUN potrzebuje dłuższe kolejki, to należy zmniejszyć liczbę LUNs obsługiwanych przez adapter. Na przykład, w przypadku queue_depth=25 to liczba dopuszczalnych LUN wynosi 510/28 = 18.
Do obsługi wielu LUNs, każda z nich wyposażona w kolejki o znacznej pojemność wymaga stworzenia wielu adapterów VSCSI – pamiętaj, że każdy z nich wymaga pamięci. Zaspokojenie dużych potrzeb IO może być dokonane tworząc wiele adapterów VSCSI na VIOC korzystającym z tego samego VIOS.

Pamiętaj, że wartość atrybutu queue_depth po stronie hdisku VIOC powinna być równa wartości queue_depth przpisanego dysku po stronie VIOS.

Maksymalna liczba LUN obsługiwana przez jeden wirtualny adapter SCSI (vhost na VIOS lub vscsi po strone VIOC) = INT (510 / (Q + 3)) gdzie Q jest queue_depth wszystkich LUN (zakładając, że są one takie same).

Zwróć uwagę, że zmiana wartości queue_depth na hdisku po stronie VIOS wymaga jego usunięcie oraz ponowne zdefiniowania po stronie VIOC.


Specjalna notatka na temat atrybutu max_xfer_size adapterów FC
Ten atrybut urządzenia fscsi nie tylko kontroluje maksymalny rozmiar IO jego sternik jest w stanie obsłużyć, ale również kontroluje on wielkość pamięci użytej przez adapter do przesyłania danych. Używając wartości umownej (max_xfer_size=0×100000) adapter otrzymuje do tego celu 16MB pamięci.
Dając temu atrybutowi jakąkolwiek inną dozwoloną wartość (powiedzmy 0×200000), ustali wielkość tego obszaru pamięci na 128MB.

W przypadku ciężkiego IO, szczególnie kiedy każde IO ma duży rozmiar (na przykład backup) należy ustawić max_xfer_size=0×200000.

Polecenie fcstat może być użyte do ustalenia czy zwiększenie num_cmd_elems lub max_xfer_size może pomóc w zwiększeniu wydajności systemu.

# fcstat fcs0
...
FC SCSI Adapter Driver Information
No DMA Resource Count: 0
No Adapter Elements Count: 0
No Command Resource Count: 0

Ostatni przykład pokazuje, że w przypadku tego adaptera, wartości elementów num_cmd_elems oraz max_xfer_size są wystarczające. Wartości inne niż 0 reprezentują adapter, który z braku mocy przerobowej nie jest w stanie obsłużyć przesłanego mu IO w związku z czym to IO musi czekać na obsługę w jego kolejkach. W takiej sytuacji, należy zwiększyć wartości num_cmd_elems oraz max_xfer_size.

Zwróć uwagę, że zmiana wartości parametru max_xfer_size powoduje użycie pamięci z układu scalonego znanego jako PCI Host Bridge przyłączonego do szyn typu PCI. Podręcznik “sprzedawcy” mówi to o adapterze FC PCI-X 4Gbps wyposażonego w dwa porty – “jeżeli ten adapter jest połączony z szyną PCI-X, która może współpracować z SDR lub/i ta szyna pracuje z częstotliwością 133MHz oraz jego dwa porty są w użyciu, to wartość max_xfer_size musi równać się jego wartości domyślnej wynoszącej 0×100000 (1 megabyte).

Duża liczba adapterów FC połączona z dużą liczbą LUNs często jest przyczyną kłopotów podczas ich konfiguracji. Tak wyglądają błędy sygnalizujące tę sytuację:

LABEL: DMA_ERR
IDENTIFIER: 00530EA6


Date/Time: Mon Mar 3 10:48:09 EST 2008
Sequence Number: 863
Machine Id: 00C3BCB04C00
Node Id: p595back
Class: H
Type: UNKN
Resource Name: PCIDMA
Resource Class: NONE
Resource Type: NONE
Location:


Description
UNDETERMINED ERROR


Probable Causes
SYSTEM I/O BUS
SOFTWARE PROGRAM
ADAPTER
DEVICE


Recommended Actions
PERFORM PROBLEM DETERMINATION PROCEDURES


Detail Data
BUS NUMBER
FFFF FFFF 9000 00E4
CHANNEL UNIT ADDRESS
0000 0000 0000 018B
ERROR CODE
0000 0000 1000 0003


Obecność tych błędów, wymaga zmiany wartości max_xfer_size – należy użyć jej wartości domyślnej. Mówiąc o SVC, warto wiedzieć, że obecnie każdy element SVC (node) może przyjąć maksymalnie 10,000 SCSI poleceń od jej klienta. Również, port każdego elementu (node) SVC może przyjąć 2048 poleceń. Mając to na uwadze, lepiej sprawdz, że jeżeli N reprezentuje liczbę LUNs obsługiwanych prze node SVC oraz Q jest pojemnością jej (LUN) kolejki to N x Q <= 10,000.

Na koniec, powinieneś rozważyć użycie SDDPCM w miejsce SDD. Pomimo że ta zmiana nie wymaga dużo czasu, wymaga to reboot maszyny. Pamiętaj, że ta zmiana ma wpływ na twoje queue_depth – w przypadku SDDPCM, wartość domyślna queue_depth wynosi 20. W przypadku SDD rzeczywista wartość queue_depth równa jest 20 x liczba ścieżek (path) do vpaths.

Migracja z SDD do SDDPCM (lub odwrotnie)
Migracja z SDD do SDDPCM (lub odwrotnie, pomimo tego ja przypuszczam, że większość to będą migracje z SDD do SDDPCM) jest dość prosta i nie wymaga dużo czasu. Ten proces jest opisany w dokumentacji, przebiega on w następujący sposób:
1. Varyoff wszystke SDD grupy dysków
2. Zatrzymaj proces sddsrv przy pomocy # stopsrc -s sddsrv
3. Usuń wszystkie urządzenia SDD (zarówno vpath jak i hdisk) używając pokazanych poniżej instrukcji.
4. Usuń urządzenie dpo
5. Usuń pliki programu SDD oraz jego dodatki.
6. Instaluj plik dodatkowy SDDPCM oraz pliki SDDPCM (jestem prawie pewny, że to wymaga reboot – output instalacji o tym cię powiadomi.)
7. Ustaw nowe dyski (reboot zrobi to dla ciebie, w przeciwnym razie użyj polecenia cfgmgr).
8. Varyong groupy dysków – jesteś ponownie gotowy do akcji.

Do usunięcia vpaths i ich hdisków możesz wykorzystać następujący skrypt wydany bezpośrednio z linii poleceń:

# for i in `lsdev -Cc disk | egrep "vpath|2105" | cut -f1 -d" "`
> do
> rmdev -dl $i
> done

A to jest jeszcze łatwiejsza metoda:


# rmdev -Rdl dpo  


, która za jednym razem usuwa urządzenia dpo, vpaths i hdisks.

Zauważ, że LVM przechowuje informację o fizycznych dyskach używając do tego celu PVID w związku z czym zmiany twoich Vgs z wpath na hdisk czy zmiany w nazwach tych urządzeń nie mają znaczenia. Dzięki temu nie jest wymagany export/import tych grup dysków. Jakiekolwiek zmiany wielkości queue_depth ulegną zniszczeniu w wyniku tej zmiany. Jeżeli twój system tego wymaga, to musisz te ponownie wprowadzić te zmiany do użytku (przed punktem 7).

Zwróć uwagę, że dla dysków przyłączonych do serwera VIO (VIOS), polecam użycie SDDPCM z tej przyczyny, że w przypadku VG bezpośrednio dołączonej do LPAR, której pojemność chcemy przekazać VIOS (czy też odwrotnie) to ta akcja nie wymaga żadnego backup/restore. Dotyczy to również użycia FlashCopy i jej przejęcie na innej maszynie.

Z poważaniem,
Dan Braden

Update History:
6/29/2009 – added formula for maximum number of LUNs per virtual SCSI adapter to avoid queueing at the adapter
3/31/2009 – added information on using fcstat
10/23/2008 – updates for changes in SDD and iostat
3/31/2008 – added section on VIO queue depths and that max_xfer_size applies to the 2 Gbps adapters and the error one gets if max_xfer_size is too big
10/11/2007 – update on tuning via IO service times and use of ndisk
6/25/2007 – update for SDD releases that do not queue IOs
1/24/2007 – typo on max_xfer_size=0×10000 changed to 0×100000
8/15/2006 – added sentence on adapter IOPS and queue monitoring
2/14/2006 – added info on the max_xfer_size attribute