🥇VM teljesítményének elemzése a VMware vSphere-en. 3. rész: Tárolás

1. rész. CPU-val kapcsolatosan
2. rész. A Memóriáról

Ma a vSphere lemezkialakításának metrikáit fogjuk megvitatni. A lemezzel kapcsolatos problémák a leggyakoribb okai a virtuális gép lassú működésének. Míg CPU és RAM esetén a hibakeresés a hipervizor szintjén ér véget, addig lemezproblémák esetén lehet, hogy a tárolóhálózattal és a tárolórendszerrel is foglalkozni kell.

A téma elemzése során a blokk alapú hozzáférést használt tárolórendszert fogom példaként felhozni, bár fájl alapú hozzáférésnél a számlálók körülbelül ugyanezek.

Egy kis elmélet

Amikor a virtuális gépek lemezmeghajtó teljesítményéről beszélünk, általában három, egymással összefüggő paraméterre hívjuk fel a figyelmet:

bemeneti/kimeneti műveletek száma (Input/Output Operations Per Second, IOPS);
átviteli sebesség (Throughput);
bemeneti/kimeneti műveletek késleltetése (Latency).

Az IOPS száma általában fontos a véletlenszerű jellegű terhelések számára: hozzáférés a lemez különböző helyein lévő blokkokhoz. Ilyen terhelést például az adatbázisok, üzleti alkalmazások (ERP, CRM) generálhatnak.

Sávszélesség fontos a sorozatos jellegű terhelésekhez: hozzáférés a blokkokhoz, amelyek egymás után helyezkednek el. Például ilyen terhelést generálhatnak a fájl kiszolgálók (de nem mindig) és a videómegfigyelő rendszerek.

Az átvitel sebessége az I/O műveletek számával a következőképpen van összefüggésben:

Throughput = IOPS * Blokkméret, ahol a Blokkméret a blokk mérete.

A blokk mérete meglehetősen fontos jellemző. A modern ESXi verziók akár 32 767 KB méretű blokkot is átengednek. Ha a blokk még ennél is nagyobb, akkor több részre osztódik. Nem minden tárolórendszer tud hatékonyan működni ilyen nagy blokkokkal, ezért az ESXi Advanced Settings menüjében megtalálható a DiskMaxIOSize paraméter. Ezzel a paraméterrel csökkenthető a hipervizor által átengedett blokk maximális mérete (további részletek itt). Mielőtt ezt a paramétert módosítaná, javaslom, hogy konzultáljon a tárolórendszer gyártójával, vagy legalább tesztelje a módosításokat egy laboratóriumi környezetben.

A nagy blokk méret kedvezőtlen hatással lehet a tárolórendszer teljesítményére. Még akkor is, ha az IOPS és az átvitel viszonylag alacsony, nagy blokk méret esetén magas késleltetés figyelhető meg. Ezért figyeljen erre a paraméterre.

Késleltetés – a teljesítmény legérdekesebb paramétere. A virtuális gép bemeneti/kimeneti műveleteinek késleltetése a következőkből áll:

a hypervisoron belüli késlekedések (KAVG, Átlagos Kernel MilliSec/Read);
a betáplált adatátviteli hálózat és a tárolórendszer által okozott késlekedések (DAVG, Átlagos Driver MilliSec/Command).

A vendég operációs rendszerben látható általános késlekedés (GAVG, Átlagos Vendég MilliSec/Command) a KAVG és DAVG összege.

A GAVG és DAVG mérhetők, míg a KAVG kiszámítandó: GAVG–DAVG.

Forrás

Részletesebben foglalkozzunk a KAVG. Normál működés esetén a KAVG-nak a nullához kell közelesnie, vagy legalábbis jelentősen kisebbnek kell lennie, mint a DAVG. Az egyetlen eset, amikor KAVG várhatóan magas, az a VM lemezén lévő IOPS korlátozás. Ekkor a korlát túllépésénél a KAVG nőni fog.

A KAVG legjelentősebb összetevője a QAVG - az előfeldolgozásra várakozási idő a hypervisoron belül. A KAVG többi összetevője elhanyagolható.

A lemezes adapter meghajtóban és az lunokhoz való várólisták fix méretűek. Nagy terhelésű környezetekben érdemes lehet megnövelni ezt a méretet. Itt leírja, hogyan lehet növelni a várólistákat az adapter meghajtóban (ezzel együtt a lunokra való várólistát is). Ez a beállítás működik, amikor a lunon csak egy VM van, ami ritka eset. Ha a lunon több VM működik, akkor azt is meg kell növelni, Disk.SchedNumReqOutstanding (utasítás itt). A várólista megnövelésével csökkenti a QAVG-t és a KAVG-t is.

De először is nézze meg a gyártó HBA dokumentációját, és tesztelje a változtatásokat egy laboratóriumi környezetben.

A lunhoz való várólista méretét befolyásolhatja az SIOC (Storage I/O Control) mechanizmus aktiválása. Ez biztosítja a lunhoz való egyenletes hozzáférést a klaszter összes szervere számára azáltal, hogy dinamikusan megváltoztatja a lunhoz való várólistát a szervereken. Tehát ha az egyik gazdagépen működik egy VM, amely aránytalanul sok teljesítményt igényel (noisy neighbor VM), a SIOC csökkenti a lunra vonatkozó várólista hosszát az adott gazdagépen (DQLEN). Bővebben itt.

A KAVG-nál végzünk, most pedig egy kicsit a DAVG. Itt minden egyszerű: a DAVG az a késlekedés, amelyet a külső környezet (adatátviteli hálózat és a tárolórendszer) okoz. Minden modern és kevésbé modern tárolórendszer rendelkezik saját teljesítménymérőivel. A DAVG problémák elemzésekor érdemes ezeket figyelni. Ha az ESXi és a tárolórendszer oldaláról minden rendben van, ellenőrizze az adatátviteli hálózatot.

A teljesítménnyel kapcsolatos problémák elkerülése érdekében válassza ki a megfelelő Path Selection Policy (PSP) beállítást a tárolórendszeréhez. A szinte minden modern tárolórendszer támogatja a Round-Robin PSP-t (ALUA, Asymmetric Logical Unit Access, használatával vagy anélkül). Ez a politika lehetővé teszi, hogy az összes elérhető útvonalat használja a tárolórendszerhez. ALUA esetén csak azok az útvonalak használhatók, amelyek a lun-t kezelő vezérlőhöz vezetnek. Nem minden tárolórendszerhez vannak alapértelmezett szabályok az ESXi-n, amelyek a Round-Robin politikát állítják be. Ha az Ön tárolórendszeréhez nincs ilyen szabály, használjon a tárolórendszer gyártójától származó plugint, amely létrehozza a megfelelő szabályt az összes cluster gazdagépén, vagy hozza létre saját maga a szabályt. Részletek itt.

A tárolórendszerek egyes gyártói azt is javasolják, hogy a IOPS számát állítsa át az alapértelmezett 1000-ről 1-re. Gyakorlatunkban ez lehetővé tette, hogy „többet hozzunk ki” a tárolórendszerből és jelentősen csökkentsük a failover-hez szükséges időt, ha a vezérlők meghibásodnak vagy frissítésre kerülnek. Ellenőrizze a gyártó ajánlásait, és ha nincs ellenjavallat, próbálja meg módosítani ezt a paramétert. Részletek itt.

A virtuális gép tárolórendszerének teljesítménymérői

A vCenter-ben gyűjtött tárolórendszer teljesítménymérői a Datastore, Disk, Virtual Disk szakaszokban találhatók:

A részben Datastore itt találhatók a vSphere tároló (datastore) statisztikái, ahol a virtuális gépek diszkjei találhatók. Itt megtalálja a következő standard teljesítménymérőket:

IOPS (átlagos olvasási / írási kérések másodpercenként),
áteresztő képesség (olvasási / írási sebesség),
késleltetés (olvasási / írási / legmagasabb késleltetés).

A mérők nevéből mindent megérthetünk. Ismét hangsúlyozom, hogy itt a statisztika nem egy adott virtuális gépre (vagy virtuális gép lemezére) vonatkozik, hanem az egész datastore-ra. Véleményem szerint a statisztikát kényelmesebb az ESXTOP-ban nézni, legalábbis abból a szempontból, hogy a legkisebb mérési időtartam ott 2 másodperc.

A részben Lemez itt találhatók a blokkeszközökre vonatkozó statisztikák, amelyek a virtuális gépek által használt. Itt van IOPS típusú summation (a mérési időszak alatt végrehajtott bemeneti/kimeneti műveletek száma) és számos blokk-hozzáféréshez kapcsolódó mérő (Commands aborted, Bus resets). Véleményem szerint ezt az információt szintén kényelmesebb az ESXTOP-ban megtekinteni.

Rész Virtual Disk – a leghasznosabb az adatbázis teljesítményproblémáinak keresése szempontjából a VM. Itt megtekinthetjük a teljesítményt minden virtuális lemezen. Ez az információ szükséges ahhoz, hogy megértsük, van-e probléma egy adott virtuális gépnél. A standard belső/külső műveletek számlálói, a beolvasott/írt terjedelem és késleltetések mellett ebben a részben hasznos számlálók találhatók, amelyek a blokk méretét mutatják: Read/Write request size.

Az alábbi képen látható a VM lemez teljesítménygrafikonja, amelyen láthatjuk az IOPS számát, késleltetéseket és a blokk méretét.

A teljesítménymutatók a teljes tárolón is megtekinthetők, ha az SIOC be van kapcsolva. Itt található az átlagos Latency és IOPS alapinformációi. Alapértelmezés szerint ezt csak valós időben lehet megtekinteni.

ESXTOP

Az ESXTOP-nak több képernyője van, amelyen a gazda diszk alrendszerére vonatkozó információk, különböző virtuális gépek és azok lemezei találhatók.

Kezdjük a virtuális gépek információival. A "Disk VM" képernyő az "v" billentyű megnyomásával hívható elő:

NVDISK – a VM-ek lemezeinek száma. A részletes információk megtekintéséhez a következő lemezre kattintva nyomja meg az "e" billentyűt és írja be a kívánt VM GID-jét.

A többi paraméter értéke ezen a képernyőn a nevükből világosan érthető.

Egy másik hasznos képernyő a problémák kereséséhez – Disk adapter. Az "d" billentyű megnyomásával hívható elő (az alábbi képen az A, B, C, D, E, G mezők vannak kiválasztva):

NPTH – az adott adapterről látható utak száma a lunokhoz. Az adapteren levő minden út információjának megtekintéséhez nyomja meg az "e" billentyűt és írja be az adapter nevét:

AQLEN – az adapter maximális sorozatmérete.

Ezen a képernyőn a már említett késleltetéseket mutató számlálók is láthatók: KAVG/cmd, GAVG/cmd, DAVG/cmd, QAVG/cmd.

A Disk device képernyőn, amely az "u" billentyű megnyomásával hívható elő, az egyes blokkeszközökről – lunokról (az alábbi képen az A, B, F, G, I mezők vannak kiválasztva) található információ. Itt látható a lunokhoz tartozó sor állapota.

DQLEN – a blokkeszköz sorszáma.
ACTV – a beépített ESXi kernelben levő belső/külső műveletek száma.
QUED – a sorban levő belső/külső műveletek száma.
%USD – ACTV / DQLEN × 100%.
LOAD – (ACTV + QUED) / DQLEN.

Ha a %USD magas, érdemes megfontolni a sorozat növelését. Minél több művelet van a sorban, annál magasabb a QAVG és ennek megfelelően a KAVG.

A Disk device képernyőn megnézheti, hogy a tárolórendszeren működik-e a VAAI (vStorage API for Array Integration). Ehhez ki kell választania az A és O mezőket.

A VAAI mechanizmusa lehetővé teszi, hogy a hypervisor munkájának egy részét közvetlenül a tárolórendszerre helyezzük, például a nullázást, blokkok másolását vagy blokkolást.

Ahogy a fenti képen látható, ezen a tárolórendszeren működik a VAAI: aktívan használják a Zero és az ATS primitíveket.