🥇Analyse af VM-ydeevne i VMware vSphere. Del 3: Storage

Del 1. Om CPU
Del 2. Om Hukommelse

I dag vil vi se nærmere på metrics for disksystemet i vSphere. Problemer med lagring er den mest almindelige årsag til en langsom virtuel maskine. Hvis vi i tilfælde af CPU og RAM slutter fejlfindingen på hypervisorens niveau, så skal vi ved problemer med disken måske også se på netværket for datatransmission og lagringssystemet.

Jeg vil tage emnet op ved at give et eksempel på blokadgang til lagringssystemet, selvom tællerne er cirka de samme ved filadgang.

Lidt teori

Når man taler om ydeevnen af disksystemet til virtuelle maskiner, fokuserer man typisk på tre relaterede parametre:

antal input/output operationer pr. sekund (Input/Output Operations Per Second, IOPS);
båndbredde (Throughput);
forsinkelse af input/output operationer (Latency).

Antallet af IOPS er særligt vigtigt for belastninger af tilfældig karakter (random): adgang til blokke på disken, der er placeret forskellige steder. Eksempler på sådan belastning kan være databaser, forretningsapplikationer (ERP, CRM) osv.

Båndbredde er vigtig for belastninger af sekventiel karakter: adgang til blokke, der er placeret efter hinanden. For eksempel kan sådan belastning genereres af filservere (men ikke altid) og overvågningssystemer.

Båndbredden er relateret til antallet af input/output operationer som følger:

Throughput = IOPS * Blokstørrelse, hvor Blokstørrelse er størrelsen på blokken.

Blokstørrelsen er en ret vigtig egenskab. Moderne versioner af ESXi tillader blokke op til 32.767 KB. Hvis blokken er endnu større, deles den op i flere. Ikke alle lagringssystemer kan effektivt håndtere så store blokke, så i Advanced Settings i ESXi findes parameteren DiskMaxIOSize. Denne kan bruges til at reducere den maksimale blokstørrelse, som hypervisoren tillader (læs mere her). Jeg anbefaler at konsultere producenten af lagringssystemet, før dette parameter ændres, eller i det mindste at teste ændringerne på et laboratorium.

En stor blokstørrelse kan have en negativ indvirkning på ydeevnen af lagringssystemet. Selv hvis antallet af IOPS og throughput er relativt lavt, kan der ved store blokke observeres høje forsinkelser. Så vær opmærksom på denne parameter.

Forsinkelse er den mest interessante parameter for ydeevnen. Forsinkelsen af input/output operationer for den virtuelle maskine består af:

forsinkelsen inden i hypervisoren (KAVG, Average Kernel MilliSec/Read);
forsinkelse, som dataoverførselsnetværket og storage systemet giver (DAVG, Gennemsnitlig Driver MilliSec/Command).

Den samlede forsinkelse, der vises i gæste-OS'et (GAVG, Gennemsnitlig Gæst MilliSec/Command), er summen af KAVG og DAVG.

GAVG og DAVG måles, mens KAVG beregnes: GAVG–DAVG.

Kilde

Lad os se nærmere på KAVG. Under normale forhold bør KAVG tendere mod nul eller i det mindste være meget lavere end DAVG. Den eneste kendte situation, hvor KAVG forventes at være høj, er begrænsningen på IOPS på VM-diskene. I så fald vil KAVG stige, hvis der forsøges at overskride grænsen.

Den mest betydningsfulde komponent af KAVG er QAVG – ventetid for behandling inden for hypervisoren. De andre komponenter af KAVG er ubetydelige.

Køen i diskadapterdriveren og køen til lunene har en fast størrelse. For meget belastede miljøer kan det være nyttigt at øge denne størrelse. Her beskriver, hvordan man øger køerne i adapterdriveren (køen til lunene vil også blive øget). Denne indstilling fungerer, når der kun er én VM, der arbejder med en lun, hvilket sjældent er tilfældet. Hvis der er flere VMer på lunen, skal parameteren Disk.SchedNumReqOutstanding (instruktionen her). Ved at øge køen reducerer du QAVG og KAVG tilsvarende.

Men igen, sørg for først at læse dokumentationen fra HBA-udbyderen og teste ændringerne på et laboratoriemiljø.

Køens størrelse til lunen kan påvirkes af aktiveringen af SIOC-mekanismen (Storage I/O Control). Den sikrer jævn adgang til lunen fra alle servere i klyngen ved dynamisk at ændre køen til lunen på serverne. Det vil sige, hvis en VM på en af værterne kræver uforholdsmæssigt meget ydeevne (noisy neighbor VM), reducerer SIOC længden af køen til lunen på den pågældende vært (DQLEN). Læs mere her.

Vi har styr på KAVG, nu lidt om DAVG. Her er det enkelt: DAVG er den forsinkelse, som det eksterne miljø (dataoverførselsnetværk og storage system) medfører. I enhver moderne og mindre moderne storage har man sine præstationsmålinger. For at analysere problemer med DAVG giver det mening at se på dem. Hvis alt er i orden fra ESXi og storage, så tjek netværket.

For optimal performance, choose the right Path Selection Policy (PSP) for your storage system. Almost all modern storage systems support the Round-Robin PSP (with ALUA, Asymmetric Logical Unit Access, or without it). This policy allows the use of all available paths to the storage system. In the case of ALUA, only the paths to the controller that owns the LUN are used. Not all storage systems on ESXi have default rules that set the Round-Robin policy. If your storage system lacks these rules, use the vendor’s plugin to create the appropriate rule across all cluster hosts, or create the rule yourself. Details her.

Some storage system manufacturers also recommend changing the IOPS count per path from the standard value of 1000 to 1. In our experience, this has allowed us to 'squeeze' more performance from the storage system and significantly reduce the time required for failover in the event of controller failure or upgrade. Check with the vendor's recommendations, and if there are no contraindications, try changing this parameter. Details her.

Key performance counters for the virtual machine’s disk subsystem

The performance counters for the disk subsystem in vCenter are assembled in the Datastore, Disk, Virtual Disk sections:

I sektionen Datastore contains metrics for vSphere disk storages (datastores) where the VMs' disks are located. Here you will find standard counters for:

IOPS (Average read/write requests per second),
throughput (Read/Write rate),
latency (Read/Write/Highest latency).

The names of the counters are quite self-explanatory. I would like to emphasize that the statistics here are not for a specific VM (or VM disk), but general for the entire datastore. In my opinion, this statistics is more conveniently viewed in ESXTOP, particularly since the minimum measurement period there is 2 seconds.

I sektionen Disk contains metrics for the block devices used by the VMs. Here, there are summation-type IOPS counters (the number of input/output operations during the measurement period) and several counters related to block access (Commands aborted, Bus resets). In my opinion, this information is also more conveniently viewed in ESXTOP.

Partition Virtual Disk – den mest nyttige for at identificere ydeevneproblemer i diskundersystemet for VMs. Her kan man se ydeevnen for hver virtuel disk. Denne information er nødvendig for at forstå, om der er et problem med en bestemt virtuel maskine. Udover de standardmål for antal input/output operationer, læse-/skrivevolumen og forsinkelse, findes der nyttige målinger i denne sektion, som viser blokstørrelsen: Læse-/skriveanmodningsstørrelse.

På billedet nedenfor er grafen for VM-diskens ydeevne, hvor man kan se antallet af IOPS, forsinkelser og blokstørrelse.

Yderligere kan ydeevnemetrikker også ses for hele datalageret, hvis SIOC er aktiveret. Her præsenteres grundlæggende information om gennemsnitlig latens og IOPS. Som standard kan denne information kun ses i realtid.

ESXTOP

I ESXTOP er der flere skærme, der præsenterer information om hostens diskundersystem generelt, specifikke virtuelle maskiner og deres diske.

Lad os starte med informationen om de virtuelle maskiner. Skærmen "Disk VM" aktiveres med tasten "v":

NVDISK – antallet af diske for VM. For at se information om hver disk, tryk "e" og indtast GID for den ønskede VM.

Værdien af de andre parametre på denne skærm er tydelig ud fra deres navne.

En anden nyttig skærm til at finde problemer er Disk adapter. Den aktiveres med tasten "d" (på billedet nedenfor er felterne A, B, C, D, E, G valgt):

NPTH – antallet af stier til lunerne, der kan ses fra denne adapter. For at få information om hver sti på adapteren, tryk "e" og indtast navnet på adapteren:

AQLEN – maksimal størrelse af køen på adapteren.

På denne skærm er der også målinger for forsinkelser, som jeg tidligere har nævnt: KAVG/cmd, GAVG/cmd, DAVG/cmd, QAVG/cmd.

På skærmen Disk device, som aktiveres med tasten "u", præsenteres information om individuelle blokenheder – lunerne (på billedet nedenfor er felterne A, B, F, G, I valgt). Her kan man se tilstanden på køen til lunerne.

DQLEN – størrelsen på køen for blokenheden.
ACTV – antallet af input/output kommandoer i kernen af ESXi.
QUED – antallet af input/output kommandoer i køen.
%USD – ACTV / DQLEN × 100%.
LOAD – (ACTV + QUED) / DQLEN.

Hvis %USD er højt, bør man overveje muligheden for at øge køen. Jo flere kommandoer i køen, desto højere er QAVG, og derfor KAVG.

På skærmen for disk enheden kan du se, om VAAI (vStorage API for Array Integration) fungerer på SAN'en. For at gøre dette skal du vælge felterne A og O.

VAAI-mekanismen gør det muligt at flytte noget af arbejdet fra hypervisoren direkte til SAN'en, for eksempel nulstilling, blokkopiering eller låsning.

Som vist på billedet ovenfor, fungerer VAAI på denne SAN: primitivere som Zero og ATS bruges aktivt.