I dag vil vi analysere metrikerne for diskundersystemet i vSphere. Et lagerproblem er den mest almindelige årsag til en langsom virtuel maskine. Hvis, i tilfælde af CPU og RAM, fejlfinding slutter på hypervisor-niveau, så hvis der er problemer med disken, skal du muligvis håndtere datanetværket og lagersystemet.
Jeg vil diskutere emnet ved at bruge eksemplet med blokadgang til lagersystemer, selvom tællerne for filadgang er omtrent de samme.
Lidt teori
Når man taler om ydeevnen af diskundersystemet på virtuelle maskiner, er folk normalt opmærksomme på tre indbyrdes relaterede parametre:
- antal input/output operationer (Input/output operationer per sekund, IOPS);
- gennemløb;
- forsinkelse af input/output operationer (Latency).
Antal IOPS normalt vigtigt for tilfældige arbejdsbelastninger: adgang til diskblokke placeret forskellige steder. Et eksempel på en sådan belastning kunne være databaser, forretningsapplikationer (ERP, CRM) osv.
gennemløb vigtigt for sekventielle belastninger: adgang til blokke placeret efter hinanden. For eksempel kan filservere (men ikke altid) og videoovervågningssystemer generere en sådan belastning.
Gennemløbet er relateret til antallet af I/O-operationer som følger:
Gennemløb = IOPS * Blokstørrelse, hvor Blokstørrelse er blokstørrelsen.
Blokstørrelse er en ret vigtig egenskab. Moderne versioner af ESXi tillader blokke op til 32 KB i størrelse. Hvis blokken er endnu større, er den delt op i flere. Ikke alle lagersystemer kan effektivt arbejde med så store blokke, så der er en DiskMaxIOSize-parameter i ESXi Advanced Settings. Ved at bruge det kan du reducere den maksimale blokstørrelse, som hypervisoren springer over (flere detaljer ). Før du ændrer denne parameter, anbefaler jeg, at du rådfører dig med lagersystemets producent eller i det mindste tester ændringerne på en laboratoriebænk.
En stor blokstørrelse kan have en skadelig effekt på opbevaringsydelsen. Selvom antallet af IOPS og gennemløb er relativt lille, kan høje latenstider observeres med en stor blokstørrelse. Vær derfor opmærksom på denne parameter.
Latency – den mest interessante præstationsparameter. I/O-latenstiden for en virtuel maskine består af:
- forsinkelser inde i hypervisoren (KAVG, Average Kernel MilliSec/Read);
- forsinkelse leveret af datanetværket og lagersystemet (DAVG, Average Driver MilliSec/Command).
Den samlede latenstid, der er synlig i gæsteoperativsystemet (GAVG, Average Guest MilliSec/Command) er summen af KAVG og DAVG.
GAVG og DAVG måles, og KAVG beregnes: GAVG–DAVG.
Lad os se nærmere på KAVG. Under normal drift bør KAVG have en tendens til nul eller i det mindste være meget mindre end DAVG. Det eneste tilfælde, jeg kender til, hvor KAVG forventes at være højt, er IOPS-grænsen på VM-disken. I dette tilfælde, når du forsøger at overskride grænsen, vil KAVG stige.
Den vigtigste komponent i KAVG er QAVG - behandlingskøtiden inde i hypervisoren. De resterende komponenter i KAVG er ubetydelige.
Køen i diskadapterdriveren og køen til månerne har en fast størrelse. For meget belastede miljøer kan det være nyttigt at øge denne størrelse. beskriver, hvordan man øger køerne i adapterdriveren (samtidig øges køen til månerne). Denne indstilling fungerer, når kun én VM arbejder med månen, hvilket er sjældent. Hvis der er flere VM'er på månen, skal du også øge parameteren Disk.SchedNumReqOutstanding (instruktioner ). Ved at øge køen mindsker du henholdsvis QAVG og KAVG.
Men igen, læs først dokumentationen fra HBA-leverandøren og test ændringerne på en laboratoriebænk.
Størrelsen af køen til månen kan blive påvirket af inklusion af SIOC (Storage I/O Control) mekanismen. Det giver ensartet adgang til månen fra alle servere i klyngen ved dynamisk at ændre køen til månen på serverne. Det vil sige, at hvis en af værterne kører en VM, der kræver en uforholdsmæssig mængde ydeevne (støjende nabo-VM), reducerer SIOC kølængden til månen på denne vært (DQLEN). Flere detaljer .
Vi har ordnet KAVG, nu lidt om DAVG. Alt er simpelt her: DAVG er den forsinkelse, der indføres af det eksterne miljø (datanetværk og lagersystem). Ethvert moderne og ikke så moderne opbevaringssystem har sine egne ydeevnetællere. For at analysere problemer med DAVG giver det mening at se på dem. Hvis alt er i orden på ESXi- og lagersiden, så tjek datanetværket.
For at undgå ydeevneproblemer skal du vælge den korrekte Path Selection Policy (PSP) til dit lagersystem. Næsten alle moderne lagersystemer understøtter PSP Round-Robin (med eller uden ALUA, Asymmetric Logical Unit Access). Denne politik giver dig mulighed for at bruge alle tilgængelige stier til lagersystemet. I tilfælde af ALUA bruges kun stierne til controlleren, der ejer månen. Ikke alle lagersystemer på ESXi har standardregler, der sætter Round-Robin-politikken. Hvis der ikke er nogen regel for dit lagersystem, skal du bruge et plugin fra lagersystemproducenten, som vil oprette en tilsvarende regel på alle værter i klyngen, eller oprette en regel selv. detaljer .
Nogle lagersystemproducenter anbefaler også at ændre antallet af IOPS pr. sti fra standardværdien på 1000 til 1. I vores praksis gjorde dette det muligt at "presse" mere ydeevne ud af lagersystemet og reducere den tid, der kræves til failover. i tilfælde af en controllerfejl eller opdatering. Tjek leverandørens anbefalinger, og hvis der ikke er kontraindikationer, prøv at ændre denne parameter. detaljer .
Grundlæggende tællere for ydelse af undersystem for virtuel maskindisk
Diskundersystemets ydeevnetællere i vCenter er samlet i Datastore, Disk, Virtual Disk sektionerne:
I afsnit Datalager der er målinger for vSphere-disklager (datalagre), som VM-diskene er placeret på. Her finder du standardtællere til:
- IOPS (Gennemsnitlige læse-/skriveanmodninger pr. sekund),
- gennemløb (læse/skrivehastighed),
- forsinkelser (læse/skrive/højeste forsinkelse).
I princippet fremgår alt af tællernes navne. Lad mig endnu en gang henlede din opmærksomhed på, at statistikken her ikke er for en specifik VM (eller VM-disk), men generel statistik for hele datalageret. Efter min mening er det mere bekvemt at se på disse statistikker i ESXTOP, i det mindste baseret på det faktum, at den mindste måleperiode der er 2 sekunder.
I afsnit Disk der er målinger på blokenheder, der bruges af VM'en. Der er tællere for IOPS af summeringstypen (antal input/output-operationer i måleperioden) og flere tællere relateret til blokadgang (Kommandoer afbrudt, Bus-nulstilling). Efter min mening er det også mere praktisk at se disse oplysninger i ESXTOP.
Sektion Virtual Disk – den mest nyttige med henblik på at finde ydeevneproblemer i VM-diskundersystemet. Her kan du se ydeevnen for hver virtuel disk. Det er disse oplysninger, der er nødvendige for at forstå, om en bestemt virtuel maskine har et problem. Ud over standardtællerne for antallet af I/O-operationer, læse/skrivevolumen og forsinkelser, indeholder dette afsnit nyttige tællere, der viser blokstørrelsen: Læse/skriveanmodningsstørrelse.
På billedet nedenfor er en graf over VM-diskens ydeevne, hvor du kan se antallet af IOPS, latency og blokstørrelse.
Du kan også se ydeevnemålinger for hele datalageret, hvis SIOC er aktiveret. Her er grundlæggende oplysninger om gennemsnitlig latens og IOPS. Som standard kan disse oplysninger kun ses i realtid.
ESXTOP
ESXTOP har flere skærmbilleder, der giver information om værtsdiskens undersystem som helhed, individuelle virtuelle maskiner og deres diske.
Lad os starte med information om virtuelle maskiner. "Disk VM"-skærmen kaldes op med "v"-tasten:
NVDISK er antallet af VM-diske. For at se oplysninger for hver disk skal du trykke på "e" og indtaste GID'et for den VM, du er interesseret i.
Betydningen af de resterende parametre på denne skærm fremgår tydeligt af deres navne.
En anden nyttig skærm ved fejlfinding er Diskadapter. Kaldes af "d"-tasten (felterne A,B,C,D,E,G er valgt på billedet nedenfor):
NPTH – antallet af veje til månerne, der er synlige fra denne adapter. For at få oplysninger om hver sti på adapteren, tryk på "e" og indtast navnet på adapteren:
AQLEN – maksimal køstørrelse på adapteren.
Også på denne skærm er forsinkelsestællerne, som jeg talte om ovenfor: KAVG/cmd, GAVG/cmd, DAVG/cmd, QAVG/cmd.
Diskenhedsskærmen, som kaldes frem ved at trykke på "u"-tasten, giver information om individuelle blokenheder - måner (felterne A, B, F, G, I er valgt på billedet nedenfor). Her kan du se status for køen til månerne.
DQLEN – køstørrelse for en blokenhed.
ACTV – antal I/O-kommandoer i ESXi-kernen.
QUED – antal I/O-kommandoer i køen.
%USD – ACTV / DQLEN × 100 %.
BELASTNING – (ACTV + QUED) / DQLEN.
Hvis %USD er høj, bør du overveje at øge køen. Jo flere kommandoer i køen, jo højere QAVG og følgelig KAVG.
Du kan også se på diskenhedsskærmen, om VAAI (vStorage API for Array Integration) kører på lagersystemet. For at gøre dette skal du vælge felterne A og O.
VAAI-mekanismen giver dig mulighed for at overføre en del af arbejdet fra hypervisoren direkte til lagersystemet, for eksempel nulstilling, kopiering af blokke eller blokering.
Som du kan se på billedet ovenfor, arbejder VAAI på dette lagersystem: Nul- og ATS-primitiver bruges aktivt.
Tips til optimering af arbejdet med diskundersystemet på ESXi
- Vær opmærksom på blokstørrelsen.
- Indstil den optimale køstørrelse på HBA.
- Glem ikke at aktivere SIOC på databutikker.
- Vælg en PSP i overensstemmelse med lagersystemproducentens anbefalinger.
- Sørg for, at VAAI virker.
Nyttige artikler om emnet:
Kilde: www.habr.com