I dag skal vi analysere beregningene til diskundersystemet i vSphere. Et lagringsproblem er den vanligste årsaken til en treg virtuell maskin. Hvis, når det gjelder CPU og RAM, feilsøking slutter på hypervisornivå, så hvis det er problemer med disken, må du kanskje forholde deg til datanettverket og lagringssystemet.
Jeg vil diskutere emnet ved å bruke eksemplet med blokkering av tilgang til lagringssystemer, selv om tellerne for filtilgang er omtrent de samme.
Litt teori
Når man snakker om ytelsen til diskundersystemet til virtuelle maskiner, tar folk vanligvis hensyn til tre sammenhengende parametere:
- antall input/output-operasjoner (Input/Output-operasjoner per sekund, IOPS);
- gjennomstrømning;
- forsinkelse av input/output-operasjoner (latens).
Antall IOPS vanligvis viktig for tilfeldige arbeidsbelastninger: tilgang til diskblokker plassert på forskjellige steder. Et eksempel på en slik belastning kan være databaser, forretningsapplikasjoner (ERP, CRM), etc.
båndbredde viktig for sekvensielle belastninger: tilgang til blokker plassert etter hverandre. For eksempel kan filservere (men ikke alltid) og videoovervåkingssystemer generere en slik belastning.
Gjennomstrømning er relatert til antall I/O-operasjoner som følger:
Gjennomstrømning = IOPS * Blokkstørrelse, der blokkstørrelsen er blokkstørrelsen.
Blokkstørrelse er en ganske viktig egenskap. Moderne versjoner av ESXi tillater blokker opp til 32 767 KB i størrelse. Hvis blokken er enda større, deles den i flere. Ikke alle lagringssystemer kan fungere effektivt med så store blokker, så det er en DiskMaxIOSize-parameter i ESXi Advanced Settings. Ved å bruke den kan du redusere den maksimale blokkstørrelsen som hypervisoren hopper over (flere detaljer ). Før du endrer denne parameteren, anbefaler jeg at du rådfører deg med lagringssystemprodusenten eller i det minste tester endringene på en laboratoriebenk.
En stor blokkstørrelse kan ha en skadelig effekt på lagringsytelsen. Selv om antallet IOPS og gjennomstrømming er relativt lite, kan høye latenstider observeres med en stor blokkstørrelse. Vær derfor oppmerksom på denne parameteren.
Ventetid – den mest interessante ytelsesparameteren. I/U-latenstiden for en virtuell maskin består av:
- forsinkelser inne i hypervisoren (KAVG, Average Kernel MilliSec/Read);
- forsinkelse levert av datanettverket og lagringssystemet (DAVG, Average Driver MilliSec/Command).
Den totale latensen som er synlig i gjeste-OS (GAVG, Average Guest MilliSec/Command) er summen av KAVG og DAVG.
GAVG og DAVG måles og KAVG beregnes: GAVG–DAVG.
La oss se nærmere på KAVG. Under normal drift bør KAVG ha en tendens til null eller i det minste være mye mindre enn DAVG. Det eneste tilfellet jeg vet om hvor KAVG er forventet høy er IOPS-grensen på VM-disken. I dette tilfellet, når du prøver å overskride grensen, vil KAVG øke.
Den viktigste komponenten i KAVG er QAVG - behandlingskøtiden inne i hypervisoren. De resterende komponentene i KAVG er ubetydelige.
Køen i diskadapterdriveren og køen til månene har en fast størrelse. For svært belastede miljøer kan det være nyttig å øke denne størrelsen. beskriver hvordan man kan øke køene i adapterdriveren (samtidig vil køen til månene øke). Denne innstillingen fungerer når bare én VM jobber med månen, noe som er sjeldent. Hvis det er flere VM-er på månen, må du også øke parameteren Disk.SchedNumReqOutstanding (bruksanvisning ). Ved å øke køen reduserer du henholdsvis QAVG og KAVG.
Men igjen, les først dokumentasjonen fra HBA-leverandøren og test endringene på en laboratoriebenk.
Størrelsen på køen til månen kan påvirkes av inkluderingen av SIOC-mekanismen (Storage I/O Control). Det gir enhetlig tilgang til månen fra alle servere i klyngen ved dynamisk å endre køen til månen på serverne. Det vil si at hvis en av vertene kjører en VM som krever uforholdsmessig mye ytelse (støyende nabo VM), reduserer SIOC kølengden til månen på denne verten (DQLEN). Mer informasjon .
Vi har sortert ut KAVG, nå litt om DAVG. Alt er enkelt her: DAVG er forsinkelsen introdusert av det eksterne miljøet (datanettverk og lagringssystem). Hvert moderne og ikke fullt så moderne oppbevaringssystem har sine egne ytelsesmålere. For å analysere problemer med DAVG-er, er det fornuftig å se på dem. Hvis alt er i orden på ESXi- og lagringssiden, sjekk datanettverket.
For å unngå ytelsesproblemer, velg riktig Path Selection Policy (PSP) for lagringssystemet. Nesten alle moderne lagringssystemer støtter PSP Round-Robin (med eller uten ALUA, Asymmetric Logical Unit Access). Denne policyen lar deg bruke alle tilgjengelige stier til lagringssystemet. Når det gjelder ALUA, brukes bare banene til kontrolleren som eier månen. Ikke alle lagringssystemer på ESXi har standardregler som setter Round-Robin-policyen. Hvis det ikke er noen regel for lagringssystemet ditt, bruk en plugin fra lagringssystemprodusenten, som vil lage en tilsvarende regel på alle verter i klyngen, eller lage en regel selv. Detaljer .
Noen lagringssystemprodusenter anbefaler også å endre antall IOPS per bane fra standardverdien på 1000 til 1. I vår praksis gjorde dette det mulig å "klemme" mer ytelse ut av lagringssystemet og redusere tiden som kreves for failover betydelig. i tilfelle kontrollerfeil eller oppdatering. Sjekk leverandørens anbefalinger, og hvis det ikke er noen kontraindikasjoner, prøv å endre denne parameteren. Detaljer .
Grunnleggende ytelsestelere for undersystem for virtuell maskindisk
Diskundersystemytelsestellere i vCenter er samlet i Datastore, Disk, Virtual Disk-seksjonene:
I avsnitt Datastore det finnes beregninger for vSphere-disklagringer (datalagre) som VM-diskene er plassert på. Her finner du standardtellere for:
- IOPS (gjennomsnittlig lese-/skriveforespørsler per sekund),
- gjennomstrømning (lese-/skrivehastighet),
- forsinkelser (lese/skrive/høyeste ventetid).
I prinsippet er alt klart av navnene på tellerne. La meg igjen gjøre oppmerksom på det faktum at statistikken her ikke er for en spesifikk VM (eller VM-disk), men generell statistikk for hele datalageret. Etter min mening er det mer praktisk å se på denne statistikken i ESXTOP, i alle fall basert på at minimum måleperiode der er 2 sekunder.
I avsnitt Disk det er beregninger på blokkenheter som brukes av VM. Det er tellere for IOPS av summeringstypen (antall input/output-operasjoner i løpet av måleperioden) og flere tellere knyttet til blokkering av tilgang (Kommandoer avbrutt, Bus-resets). Etter min mening er det også mer praktisk å se denne informasjonen i ESXTOP.
Seksjon Virtual Disk – den mest nyttige med tanke på å finne ytelsesproblemer til VM-diskundersystemet. Her kan du se ytelsen for hver virtuelle disk. Det er denne informasjonen som trengs for å forstå om en bestemt virtuell maskin har et problem. I tillegg til standardtellere for antall I/O-operasjoner, lese/skrivevolum og forsinkelser, inneholder denne delen nyttige tellere som viser blokkstørrelsen: Read/Write request size.
På bildet nedenfor er en graf over VM-diskytelse, hvor du kan se antall IOPS, latency og blokkstørrelse.
Du kan også se ytelsesberegninger for hele datalageret hvis SIOC er aktivert. Her er grunnleggende informasjon om gjennomsnittlig latens og IOPS. Som standard kan denne informasjonen bare vises i sanntid.
ESXTOP
ESXTOP har flere skjermer som gir informasjon om vertsdiskundersystemet som helhet, individuelle virtuelle maskiner og deres disker.
La oss starte med informasjon om virtuelle maskiner. "Disk VM"-skjermen kalles opp med "v"-tasten:
NVDISK er antall VM-disker. For å se informasjon for hver disk, trykk "e" og skriv inn GID-en til VM-en du er interessert i.
Betydningen av de resterende parameterne på denne skjermen er tydelig fra navnene deres.
En annen nyttig skjerm ved feilsøking er Diskadapter. Kalt opp av "d"-tasten (feltene A,B,C,D,E,G er valgt på bildet nedenfor):
NPTH – antall veier til månene som er synlige fra denne adapteren. For å få informasjon for hver bane på adapteren, trykk "e" og skriv inn navnet på adapteren:
AQLEN – maksimal køstørrelse på adapteren.
Også på denne skjermen er forsinkelsestellerne som jeg snakket om ovenfor: KAVG/cmd, GAVG/cmd, DAVG/cmd, QAVG/cmd.
Skjermbildet Diskenhet, som kalles opp ved å trykke på "u"-tasten, gir informasjon om individuelle blokkenheter - måner (felt A, B, F, G, I er valgt på bildet nedenfor). Her kan du se status for køen til månene.
DQLEN – køstørrelse for en blokkenhet.
ACTV – antall I/O-kommandoer i ESXi-kjernen.
QUED – antall I/O-kommandoer i køen.
%USD – ACTV / DQLEN × 100 %.
LAST – (ACTV + QUED) / DQLEN.
Hvis %USD er høy, bør du vurdere å øke køen. Jo flere kommandoer i køen, jo høyere QAVG og følgelig KAVG.
Du kan også se på skjermbildet Diskenhet om VAAI (vStorage API for Array Integration) kjører på lagringssystemet. For å gjøre dette, velg feltene A og O.
VAAI-mekanismen lar deg overføre deler av arbeidet fra hypervisoren direkte til lagringssystemet, for eksempel nullstilling, kopiering av blokker eller blokkering.
Som du kan se på bildet ovenfor, fungerer VAAI på dette lagringssystemet: Null- og ATS-primitiver brukes aktivt.
Tips for å optimalisere arbeidet med diskundersystemet på ESXi
- Vær oppmerksom på blokkstørrelsen.
- Still inn den optimale køstørrelsen på HBA.
- Ikke glem å aktivere SIOC på databutikker.
- Velg en PSP i henhold til lagringssystemprodusentens anbefalinger.
- Sørg for at VAAI fungerer.
Nyttige artikler om emnet:
Kilde: www.habr.com