Czym są IOPS'y? Skrót pochodzi od 'Input/Output Operations Per Second' i oznacza względne możliwości i skalowalność macierzy dyskowych używanych
w sieciach SAN. Producenci prześcigają się w oferowaniu urządzeń o coraz lepszych parametrach, jednak są to zazwyczaj dane dotyczące możliwości samych kontrolerów w maksymalnie rozbudowanych konfiguracjach. Decydując się na zakup, wydajność zestawu będzie daleka od cyferek oferowanych w broszurach, bo zależna jest tylko i wyłącznie od ilości półek (przepustowość), ilości dysków (iops) i ich prędkości (czas dostępu) oraz metody połączenia miedzy kontrolerami
i półkami.
Pojedynczy IOPS jest równoważny 4.096 kB/s wykorzystanej przepustowości i wraz ze wzrostem IOPS'ów rośnie również czas oczekiwania na dane. Przy całkowicie losowym odczycie (czyli takim z jakim spotykamy się na co dzień), liczba maksymalnych możliwych operacji dysku również maleje, ze względu na czas, jaki głowica musi spędzić na 'odnajdywaniu' odpowiednich sektorów. W lepszej sytuacji są scenariusze odczytów sekwencyjnych, jednak spotykane są tylko w platformach udostępniających dane strumieniowane.
W niedalekiej przyszłości talerze zostaną zastąpione o wiele świeższą technologią pamięci SSD, które w niektórych sytuacjach potrafią być nawet do 30 razy szybsze. Jednak do czasu ich implementacji na większą skalę, będziemy jeszcze przez chwile skupiać się na technologii ferro–magnetycznej. Bazy danych, serwery webowe, pocztowe i aplikacyjne to zdecydowanie największy procent usług hostowanych w formie wirtualnych maszyn, gdzie najszybciej dostrzeżemy wyższość dysków o prędkości 15.000 rpm. Pojedynczy dysk SATA/FATA 7200 jest w stanie dostarczyć ok. 50 IOPS, dysk FC/SAS 10k – 100–140 IOPS, FC 15k to już ponad 200 IOPS, wiec wszędzie tam gdzie poszukujemy szybkiego dostępu do danych a nie maksymalnych przepustowości – warto zdecydować się na najszybsze. 
Latency
W rozwiązaniach, w których korzystamy z klastrów serwerów pracujących ze współdzielonymi dyskami, warto zatroszczyć się o każdy nawet najmniejszy szczegół. Najnowszy firmware dysków potrafi zoptymalizować i przyspieszyć ich prace w określonych poziomach RAID. Równoważenie dostępu do LUN'ów alternatywnymi linkami pomiędzy portami kart HBA, switchami FC i mniej obciążonymi kontrolerami macierzy nie będzie powodować przeciążania kolejek SCSI i tym samym dłuższego oczekiwania przez kernele maszyn wirtualnych na dane.
W domyślnej konfiguracji każdy ESX wykorzystuje pierwszy wykryty link do udziału z macierzy, powodując sytuację, w której wszelkie dane będą obsługiwane tylko przez jeden kontroler (dotyczy zarówno konfiguracji Active/Active jak i kontrolerów Active/Passive), w dodatku nawet tym samym portem powodując przepełnianie kolejek kart HBA i/lub kontrolera. Podczas konfiguracji należy pamiętać, aby każdy z serwerów w klastrze wykorzystywał do I/O tą samą ścieżkę (np. port A kontrolera B). W przeciwnym wypadku serwery będą doświadczać sytuacji, w których dany LUN będzie chwilami niedostępny dla pewnej grupy serwerów klastra. Jest to tzw. path thrashing i występuje ze względu na brak współdzielenia zawartości pamięci cache pomiędzy kontrolerami Active/Passive.
Większość rozwiązań Active/Active w praktyce pracuje również jako A/P (jeden kontroler główny, mający kontrolę nad danym LUN'em). Jeżeli mamy pewność, że wąskim gardłem w obsłudze I/O jest sam VMkernel, warto przyglądnąć się statystykom dostępnym poprzez 'esxtop' (na zakładce dotyczącej dysków: d, rozwijamy vmhba który ma duże obciążenie – CMDS/s: E i np. vmhba1). Duża ilość skolejkowanych poleceń SCSI widoczna w 'QUED' może świadczyć o zbyt małej kolejce portu karty FC.
esxTop
Dla produktów Qlogic i Emulex warto je zwiększyć, np. do poziomu 64 lub 128. Każde środowisko różni się od siebie i to co działa dla nas, niekoniecznie może sprawdzić się w systemach o innych schematach obciążeniowych. Dlatego wszelkie zmiany powinny być poparte testami i dowodami ich pozytywnego wpływu na wydajność.
# esxcfg–module –g qla2300_707_vmw
qla2300_707_vmw enabled = 1 options = 'ql2xmaxqdepth=64'
# esxcfg–module –g lpfc_740
lpfc_740 enabled = 1 options = 'lpfc0_lun_queue_depth=64
lpfc1_lun_queue_depth=64 lpfc2_lun_queue_depth=64 lpfc3_lun_queue_depth=64
lpfc4_lun_queue_depth=64 lpfc5_lun_queue_depth=64'
#esxcfg–advcfg –s 64 /Disk/SchedNumReqOutstanding
Dwa bardzo istotne parametry często pomijane w konfiguracjach to Disk.UseLunReset oraz Disk.UseDeviceReset,. Określają one zachowania magistrali SCSI, która podczas jej resetu czyści wszystkie rezerwacje SCSI urządzenia a nie konkretnego udziału, który nas zazwyczaj interesuje. W przypadku dysków lokalnych takie zachowanie jest jak najbardziej poprawne, skąd wynikają domyślne ustawienia każdego ESX. W środowiskach opartych o udziały współdzielone siecią SAN, powoduje to nadmierne i niepożądane zaburzenia całej sieci.
#esxcfg–advcfg –s 1 /Disk/UseLunReset
#esxcfg–advcfg –s 0 /Disk/UseDeviceReset
Jeżeli nadzwyczajne obciążenie generuje jedna określona wirtualna maszyna, warto zastanowić się nad przeniesieniem jej danych na dedykowany udział. Najczęstszym tego typu przypadkiem są serwery SQL, działające np. w roli Mastera w procesie replikacji. Podłączenie oddzielnego dysku w trybie RAW
w wydajniejszym poziomie RAID–1/10 lub 50, umieszczonego na grupie dyskowej nie będącej współdzieloną z innymi VM'ami wpłynie znacząco na poprawę wydajności. Dedykowany RAID do zauważonego przez nas typu operacji I/O, zmniejszy nam czas zapisu i/lub odczytu, a oddzielny LUN nie będzie generował konfliktów rezerwacji, które mają miejsce na przeciążonych zasobach.
ESX 3.5.4 Reservation conflict:
May 8 15:01:14 hemicuda vmkernel: 9:22:42:41.132 cpu0:1043)WARNING: SCSI: 119: Failing I/O due to too many reservation conflicts
May 8 15:01:14 hemicuda vmkernel: 9:22:42:41.132 cpu0:1043)WARNING: FS3: 4787: Reservation error: SCSI reservation conflict
Konflikty rezerwacji poleceń SCSI są przyczyna zbyt wielu operacji na filesystemie vmfs, przechowującym wirtualne maszyny. Są to operacje na meta-danych, tj. klonowanie maszyny, tworzenie i usuwanie snapshotów, dodawanie extendów do partycji. W systemach gościa widoczne są pod postacią timeout'ów w dostępie do danych czy też zawieszaniu się procesów na operacjach I/O powodując 100% wykorzystanie CPU. Jedynym sposobem przeciwdziałania takim sytuacjom jest ograniczenie liczby VM'ów korzystających jednocześnie ze współdzielonego LUN'a. Średnio jest to liczba 20 do 30 maszyn uzależniona od generowanego przez nie obciążenia. Warto monitorować wykorzystanie poszczególnych udziałów macierzy i w miarę równomiernie rozkładać pomiędzy nimi ruch I/O. Aby uniknąć przerwy
w działaniu usług najlepiej skorzystać w takiej sytuacji z mechanizmu Storage VMotion.
Kernele systemów Linux/UNIX w podstawowej konfiguracji są bardzo czułe pod względem dostępności do danych z dysku. Na chwilowe większe obciążenia macierzy reagują natychmiastowo, traktując je jako awarie komponentów pamięci masowej, często przełączając dostępne lokalne dla siebie systemy plików w tryb tylko-do-odczytu. Do tego typu sytuacji może dojść nawet podczas procesu VMotion, przełączającego kontekst działającej maszyny wirtualnej na świat innego VMkernel'a.
FreeBSD 7.0–RELEASE:
(da0:mpt0:0:0:0): WRITE(10). CDB: 2a 0 0 71 4b c7 0 0 20 0
(da0:mpt0:0:0:0): CAM Status: SCSI Status Error
(da0:mpt0:0:0:0): SCSI Status: Check Condition
(da0:mpt0:0:0:0): UNIT ATTENTION asc:2a,6
(da0:mpt0:0:0:0): Reserved ASC/ASCQ pair
(da0:mpt0:0:0:0): Retrying Command (per Sense Data)
(da1:mpt0:0:1:0): READ(10). CDB: 28 0 0 45 26 9f 0 0 20 0
(da1:mpt0:0:1:0): CAM Status: SCSI Status Error
(da1:mpt0:0:1:0): SCSIS Status: Check Condition
(da1:mpt0:0:1:0): UNIT ATTENTION asc:3f,e
(da1:mpt0:0:1:0): Reserved ASC/ASCQ pair
(da1:mpt0:0:1:0): Retrying Command (per Sense Data)
Odpowiednia konfiguracja kerneli systemów Open Source'owych jest w stanie zaradzić tego typu problemom, systemy rodziny Windows mają natomiast możliwość zmiany zachowania kernela za pomocą rejestru systemowego.