Idag kommer vi att analysera måtten för diskundersystemet i vSphere. Ett lagringsproblem är den vanligaste orsaken till en långsam virtuell maskin. Om, när det gäller CPU och RAM, felsökningen slutar på hypervisornivån, om det finns problem med disken, kan du behöva ta itu med datanätverket och lagringssystemet.
Jag kommer att diskutera ämnet med exemplet med blockering av åtkomst till lagringssystem, även om räknarna för filåtkomst är ungefär desamma.
Lite teori
När man talar om prestandan hos diskundersystemet för virtuella maskiner, uppmärksammar folk vanligtvis tre inbördes relaterade parametrar:
- antal in-/utgångsoperationer (Input/Output Operations Per Second, IOPS);
- genomströmning;
- fördröjning av in-/utgångsoperationer (latens).
Antal IOPS vanligtvis viktigt för slumpmässiga arbetsbelastningar: åtkomst till diskblock som finns på olika platser. Ett exempel på en sådan belastning kan vara databaser, affärsapplikationer (ERP, CRM) etc.
Bandbredd viktigt för sekventiella belastningar: åtkomst till block placerade efter varandra. Till exempel kan filservrar (men inte alltid) och videoövervakningssystem generera en sådan belastning.
Genomströmningen är relaterad till antalet I/O-operationer enligt följande:
Genomströmning = IOPS * Blockstorlek, där Blockstorlek är blockstorleken.
Blockstorlek är en ganska viktig egenskap. Moderna versioner av ESXi tillåter block upp till 32 767 KB i storlek. Om blocket är ännu större är det uppdelat i flera. Alla lagringssystem kan inte fungera effektivt med så stora block, så det finns en DiskMaxIOSize-parameter i ESXi Advanced Settings. Genom att använda den kan du minska den maximala blockstorleken som överhoppas av hypervisorn (mer information ). Innan du ändrar denna parameter rekommenderar jag att du rådgör med tillverkaren av lagringssystem eller åtminstone testar ändringarna på en laboratoriebänk.
En stor blockstorlek kan ha en skadlig effekt på lagringsprestanda. Även om antalet IOPS och genomströmning är relativt litet, kan höga latenser observeras med en stor blockstorlek. Var därför uppmärksam på denna parameter.
Latens – den mest intressanta prestandaparametern. I/O-latensen för en virtuell maskin består av:
- fördröjningar inuti hypervisorn (KAVG, Average Kernel MilliSec/Read);
- fördröjning från datanätverket och lagringssystemet (DAVG, Average Driver MilliSec/Command).
Den totala latensen som är synlig i gästoperativsystemet (GAVG, Average Guest MilliSec/Command) är summan av KAVG och DAVG.
GAVG och DAVG mäts och KAVG beräknas: GAVG–DAVG.
Låt oss ta en närmare titt på KAVG. Under normal drift bör KAVG tendera till noll eller åtminstone vara mycket mindre än DAVG. Det enda fallet jag känner till där KAVG förväntas vara hög är IOPS-gränsen på VM-disken. I det här fallet, när du försöker överskrida gränsen, kommer KAVG att öka.
Den viktigaste komponenten i KAVG är QAVG - bearbetningskötiden inuti hypervisorn. De återstående komponenterna i KAVG är försumbara.
Kön i diskadapterns drivrutin och kön till månarna har en fast storlek. För mycket belastade miljöer kan det vara användbart att öka denna storlek. beskriver hur man ökar köerna i adapterdrivrutinen (samtidigt kommer kön till månarna att öka). Den här inställningen fungerar när endast en virtuell dator arbetar med månen, vilket är sällsynt. Om det finns flera virtuella datorer på månen måste du också öka parametern Disk.SchedNumReqOutstanding (instruktioner ). Genom att öka kön minskar du QAVG respektive KAVG.
Men igen, läs först dokumentationen från HBA-leverantören och testa ändringarna på en labbbänk.
Storleken på kön till månen kan påverkas av införandet av SIOC-mekanismen (Storage I/O Control). Det ger enhetlig åtkomst till månen från alla servrar i klustret genom att dynamiskt ändra kön till månen på servrarna. Det vill säga, om en av värdarna kör en virtuell dator som kräver oproportionerligt mycket prestanda (brusiga granne-VM), minskar SIOC kölängden till månen på denna värd (DQLEN). Fler detaljer .
Vi har sorterat ut KAVG, nu lite om DAVG. Allt är enkelt här: DAVG är fördröjningen som introduceras av den externa miljön (datanätverk och lagringssystem). Varje modernt och inte så modernt förvaringssystem har sina egna prestandaräknare. För att analysera problem med DAVG är det vettigt att titta på dem. Om allt är bra på ESXi- och lagringssidan, kontrollera datanätverket.
För att undvika prestandaproblem, välj rätt Path Selection Policy (PSP) för ditt lagringssystem. Nästan alla moderna lagringssystem stöder PSP Round-Robin (med eller utan ALUA, Asymmetric Logical Unit Access). Denna policy tillåter dig att använda alla tillgängliga sökvägar till lagringssystemet. I fallet med ALUA används endast vägarna till styrenheten som äger månen. Inte alla lagringssystem på ESXi har standardregler som anger Round-Robin-policyn. Om det inte finns någon regel för ditt lagringssystem, använd en plugin från lagringssystemtillverkaren, som skapar en motsvarande regel på alla värdar i klustret, eller skapa en regel själv. Detaljer .
Vissa tillverkare av lagringssystem rekommenderar också att ändra antalet IOPS per sökväg från standardvärdet 1000 till 1. I vår praxis gjorde detta det möjligt att "pressa ut" mer prestanda ur lagringssystemet och avsevärt minska tiden som krävs för failover i händelse av styrenhetsfel eller uppdatering. Kontrollera säljarens rekommendationer, och om det inte finns några kontraindikationer, försök att ändra denna parameter. Detaljer .
Grundläggande prestandaräknare för virtuell maskindiskundersystem
Diskundersystems prestandaräknare i vCenter samlas in i avsnitten Datastore, Disk, Virtual Disk:
I avsnitt Datalagring det finns mätvärden för vSphere-disklagringar (datalagringar) där VM-diskarna finns. Här hittar du standardräknare för:
- IOPS (Genomsnittlig läs/skrivbegäran per sekund),
- genomströmning (läs/skrivhastighet),
- fördröjningar (Läs/Skriv/Högsta latens).
I princip framgår allt av namnen på diskarna. Låt mig återigen uppmärksamma er på det faktum att statistiken här inte är för en specifik VM (eller VM-disk), utan generell statistik för hela datalagret. Enligt min mening är det bekvämare att titta på denna statistik i ESXTOP, åtminstone baserat på det faktum att minsta mätperiod där är 2 sekunder.
I avsnitt Disk det finns mätvärden på blockenheter som används av den virtuella datorn. Det finns räknare för IOPS av summeringstypen (antal in-/utdataoperationer under mätperioden) och flera räknare relaterade till blockering (kommandon avbrutna, bussåterställningar). Enligt min åsikt är det också bekvämare att se denna information i ESXTOP.
Avsnitt Virtual Disk – den mest användbara ur synvinkeln för att hitta prestandaproblem för VM-diskundersystemet. Här kan du se prestandan för varje virtuell disk. Det är denna information som behövs för att förstå om en viss virtuell maskin har ett problem. Förutom standardräknare för antalet I/O-operationer, läs/skrivvolym och fördröjningar, innehåller detta avsnitt användbara räknare som visar blockstorleken: Läs/skrivbegärans storlek.
På bilden nedan är en graf över VM-diskens prestanda, där du kan se antalet IOPS, latens och blockstorlek.
Du kan också se prestandamått för hela datalagret om SIOC är aktiverat. Här är grundläggande information om genomsnittlig latens och IOPS. Som standard kan denna information endast ses i realtid.
ESXTOP
ESXTOP har flera skärmar som ger information om värddiskundersystemet som helhet, enskilda virtuella maskiner och deras diskar.
Låt oss börja med information om virtuella maskiner. Skärmen "Disk VM" kallas upp med "v"-tangenten:
NVDISK är antalet VM-diskar. För att se information för varje disk, tryck på "e" och ange GID för den virtuella datorn av intresse.
Innebörden av de återstående parametrarna på denna skärm framgår tydligt av deras namn.
En annan användbar skärm vid felsökning är Diskadapter. Anropas av "d"-tangenten (fälten A,B,C,D,E,G är valda i bilden nedan):
NPTH – antalet vägar till månarna som är synliga från denna adapter. För att få information för varje sökväg på adaptern, tryck på "e" och skriv in namnet på adaptern:
AQLEN – maximal köstorlek på adaptern.
På den här skärmen finns också fördröjningsräknarna som jag pratade om ovan: KAVG/cmd, GAVG/cmd, DAVG/cmd, QAVG/cmd.
Skärmen Diskenhet, som tas fram genom att trycka på "u"-tangenten, ger information om enskilda blockenheter - månar (fälten A, B, F, G, I är valda på bilden nedan). Här kan du se status för kön till månarna.
DQLEN – köstorlek för en blockenhet.
ACTV – antal I/O-kommandon i ESXi-kärnan.
QUED – antal I/O-kommandon i kön.
%USD – ACTV / DQLEN × 100 %.
LADDA – (ACTV + QUED) / DQLEN.
Om %USD är hög bör du överväga att öka kön. Ju fler kommandon i kön, desto högre QAVG och följaktligen KAVG.
Du kan också se på skärmen Diskenhet om VAAI (vStorage API for Array Integration) körs på lagringssystemet. För att göra detta, välj fälten A och O.
VAAI-mekanismen låter dig överföra en del av arbetet från hypervisorn direkt till lagringssystemet, till exempel nollställning, kopiering av block eller blockering.
Som du kan se på bilden ovan fungerar VAAI på detta lagringssystem: Noll- och ATS-primitiver används aktivt.
Tips för att optimera arbetet med diskundersystemet på ESXi
- Var uppmärksam på blockstorleken.
- Ställ in den optimala köstorleken på HBA.
- Glöm inte att aktivera SIOC på databutiker.
- Välj en PSP i enlighet med lagringssystemtillverkarens rekommendationer.
- Se till att VAAI fungerar.
Användbara artiklar om ämnet:
Källa: will.com