🥇Prestandaanalys av VM i VMware vSphere. Del 3: Lagring

Del 1. Om CPU
Del 2. Om minnet

Idag ska vi gå igenom metrik för lagringssystemet i vSphere. Lagringsproblem är den vanligaste orsaken till långsam prestanda hos virtuella maskiner. Medan felsökning av CPU och RAM ofta avslutas på hypervisor-nivå, kan det vid diskproblem vara nödvändigt att titta på datanätverket och lagringssystemet.

Jag kommer att diskutera detta ämne med hjälp av blockåtkomst till lagringssystemet, även om mätvärdena är ungefär desamma vid filåtkomst.

Lite teori

När man pratar om prestanda hos lagringssystem för virtuella maskiner, fokuserar man vanligtvis på tre sammanlänkade parametrar:

antalet in- och utdataoperationer (Input/Output Operations Per Second, IOPS);
bandbredd (Throughput);
fördröjningen av in- och utdataoperationer (Latency).

Antalet IOPS är vanligtvis viktigt för belastningar av slumpmässig karaktär: åtkomst till block på disken som ligger på olika platser. Exempel på sådana belastningar kan vara databaser, affärsapplikationer (ERP, CRM) etc.

Bandbredd är viktiga för belastningar av sekventiell karaktär: åtkomst till block som ligger efter varandra. Till exempel kan sådana belastningar genereras av filservrar (men inte alltid) och system för videoövervakning.

Bandbredden är relaterad till antalet in- och utdataoperationer på följande sätt:

Throughput = IOPS * Blockstorlek, där Blockstorlek är storleken på blocket.

Blockstorleken är en ganska viktig egenskap. Moderna versioner av ESXi tillåter blockstorlekar upp till 32 767 KB. Om blocket är ännu större delas det upp i flera. Inte alla lagringssystem kan effektivt hantera sådana stora block, därför finns det en parameter i avancerade inställningar i ESXi som heter DiskMaxIOSize. Genom denna kan man minska den maximala blockstorlek som hypervisorn tillåter (mer information här). Jag rekommenderar att man rådfrågar tillverkaren av lagringssystemet innan man ändrar denna parameter, eller åtminstone testa ändringarna på en laboratoriestand.

En stor blockstorlek kan negativt påverka prestandan hos lagringssystemet. Även om antalet IOPS och throughput är relativt lågt, kan det vid stor blockstorlek uppstå höga fördröjningar. Så var uppmärksam på denna parameter.

Fördröjning – den mest intressanta parametern för prestanda. Fördröjningen för in- och utdataoperationer för den virtuella maskinen består av:

fördröjningar inuti hypervisorn (KAVG, genomsnittlig kärna milliSec/Läs);
fördröjningar orsakade av datanät och LUN (DAVG, genomsnittlig drivrutin milliSec/kommando).

Den totala fördröjningen som syns i gäst-OS (GAVG, genomsnittlig gäst milliSec/kommando) är summan av KAVG och DAVG.

GAVG och DAVG mäts, medan KAVG beräknas: GAVG–DAVG.

Källa

Låt oss titta närmare på KAVG. Vid normal drift bör KAVG sträva mot noll eller åtminstone vara mycket mindre än DAVG. Det enda jag känner till där KAVG förväntas vara hög är diskens IOPS-begränsning för VMen. I sådana fall kommer KAVG att öka vid försök att överskrida gränsen.

Den mest signifikanta komponenten av KAVG är QAVG – tiden i kö för behandling inuti hypervisorn. Övriga komponenter av KAVG är försumbar små.

Kön i diskdrivrutinen och köerna till LUNarna har en fast storlek. För högbelastade miljöer kan det vara användbart att öka denna storlek. Här beskriver hur man ökar köerna i adapterdrivrutinen (samtidigt ökar kön till LUNarna). Denna inställning fungerar när bara en VM arbetar med LUNen, vilket är sällan. Om flera VMar är anslutna till LUNen, måste även parameter Disk.SchedNumReqOutstanding (instruktion här). Genom att öka kön minskar du QAVG och KAVG i enlighet med detta.

Men, som alltid, bekanta dig först med dokumentationen från HBA-leverantören och testa ändringarna på ett laboratorium.

Kön till LUNen kan påverkas av aktiveringen av SIOC-mekanismen (Storage I/O Control). Den säkerställer jämn tillgång till LUNen från alla servrar i klustret genom att dynamiskt ändra kön till LUNen på servrarna. Det vill säga, om en VM på en av värdarna kräver oproportionerligt mycket prestanda (noisy neighbor VM), minskar SIOC längden på kön till LUNen på den värden (DQLEN). Mer information här.

Vi har förstått KAVG, nu lite om DAVG. Här är allt enkelt: DAVG är den fördröjning som den externa miljön (datanät och LUN) ger. I varje modern och även äldre LUN finns det egna prestandaindikatorer. För att analysera problem med DAVG är det meningsfullt att titta på dem. Om allt ser bra ut från ESXi och LUN, kontrollera datanätverket.

För att undvika prestandaproblem, välj rätt Path Selection Policy (PSP) för din lagringslösning. Nästan alla moderna lagringssystem stödjer PSP Round-Robin (med ALUA, Asymmetric Logical Unit Access, eller utan). Denna policy möjliggör utnyttjande av alla tillgängliga vägar till lagringssystemet. I fallet med ALUA används endast vägar till den kontroller som äger LUN:en. Det finns inte alltid standardregler för alla lagringssystem på ESXi, som ställer in policyn Round-Robin. Om det inte finns några regler för ditt lagringssystem, använd leverantörens plugin för att skapa motsvarande regel på alla värdar i klustret, eller skapa regeln själv. Mer information här.

Även vissa lagringssystemstillverkare rekommenderar att ändra antalet IOPS per väg från standardvärdet 1000 till 1. I vår praktik har detta gjort det möjligt att "pressa ut" mer prestanda från lagringssystemet och avsevärt minska den tid som krävs för failover vid hårdvarufel eller uppgraderingar av kontrollerna. Kontrollera med leverantörens rekommendationer, och om det inte finns några kontraindikationer, prova att ändra detta parameter. Mer information här.

Huvudsakliga prestandaindikatorer för diskunderlaget i den virtuella maskinen

Prestandaindikatorerna för diskunderlaget i vCenter är samlade i avsnitten Datastore, Disk, Virtual Disk:

I avsnittet Datastore här finns metrik för diskstorage vSphere (datastores) där virtuella maskinens diskar ligger. Här hittar du standardindikatorer för:

IOPS (genomsnittligt antal läs-/skrivförfrågningar per sekund),
bandbredd (läs-/skrivhastighet),
fördröjningar (läs-/skriv-/högsta fördröjning).

Från namnen på indikatorerna framgår i princip allt. Jag vill återigen påpeka att här statistiken inte gäller en specifik virtuell maskin (eller disk i den virtuella maskinen), utan är generell för hela datastoren. Enligt min mening är det lättare att se denna statistik i ESXTOP, även med tanke på att den minimi mätperioden där är 2 sekunder.

I avsnittet Disk här finns metrik för blocklagringsenheterna som används av den virtuella maskinen. Här finns indikatorer för IOPS av typen summation (antal in- och utdataoperationer under mätperioden) och flera indikatorer relaterade till blockåtkomst (Aborterade kommandon, Bussåterställningar). Denna information, enligt min mening, är också lättare att se i ESXTOP.

Avsnitt Virtuell disk – den mest användbara när det gäller att söka efter prestandaproblem i diskunderlaget för VM. Här kan du se prestanda per virtuell disk. Denna information är avgörande för att förstå om det finns ett problem med en specifik virtuell maskin. Förutom de standardräknare för in-/utdataoperationer, läs-/skrivvolymer och fördröjningar, finns det användbara räknare i denna avsnitt som visar blockstorlek: Read/Write request size.

I bilden nedan visas diskens VM-prestandadiagram, där du kan se antalet IOPS, fördröjningar och blockstorlek.

Du kan också se prestandametrik för hela datastoren om SIOC är aktiverat. Här presenteras grundläggande information om genomsnittlig latency och IOPS. Som standard kan denna information bara ses i realtid.

ESXTOP

I ESXTOP finns flera skärmar som visar information om värdens diskunderlag, specifika virtuella maskiner och deras diskar.

Vi börjar med information om virtuella maskiner. Skärmen 'Disk VM' aktiveras med tangenten 'v':

NVDISK – är antalet diskar för VM. För att se information om varje disk, tryck på 'e' och ange GID för den intressanta VM:n.

Värdena för de övriga parametrarna på denna skärm är tydliga från deras namn.

En annan användbar skärm när man söker efter problem är Disk adapter. Den aktiveras med tangenten 'd' (i bilden nedan har fälten A, B, C, D, E, G valts):

NPTH – antalet vägar till lun som syns från denna adapter. För att få information om varje väg på adaptern, tryck på 'e' och ange namnet på adaptern:

AQLEN – den maximala storleken på kön på adaptern.

Dessutom visas räknare för fördröjningar på denna skärm, om vilka jag talade tidigare: KAVG/cmd, GAVG/cmd, DAVG/cmd, QAVG/cmd.

På skärmen Disk device, som aktiveras med tangenten 'u', visas information om enskilda blockenheter – lun (i bilden nedan har fälten A, B, F, G, I valts). Här kan du se köstatus för lun.

DQLEN – storleken på kön för blockenheten.
ACTV – antalet in-/utdataoperationer i ESXi-kärnan.
QUED – antalet in-/utdataoperationer i kön.
%USD – AACTIVE / DQLEN × 100%.
LOAD – (ACTV + QUED) / DQLEN.

Om %USD är högt, bör du överväga att öka kön. Ju fler kommandon i kön, desto högre QAVG och, i sin tur, KAVG.

På Disk-enhets-skärmen kan du också se om VAAI (vStorage API for Array Integration) fungerar på lagringssystemet. För att göra detta måste du välja fälten A och O.

VAAI-mekanismen möjliggör att en del av arbetet flyttas från hypervisorn direkt till lagringssystemet, till exempel nollställning, blockkopiering eller blockering.

Som visas på bilden ovan fungerar VAAI på detta lagringssystem: primitiverna Zero och ATS används aktivt.