Dit VMware miljø startede med at have masser af ressourcer men efter du har tilføjet en række nye servere så kører det ikke helt optimalt mere. Du har ikke et værktøj ti specifik overvågning af det virtuelle miljø og ved ikke helt hvilke parametre du bør kigge på for at løse performanceproblemerne. Men fortvivl ikke. I nedenstående artikel finder du en gennemgang af de vigtigste målepunkter inden for det delte virtuelle objekter så som CPU, MEM, DISK og NET. Det er muligvis lidt teknisk men det er det virtuelle miljø jo også, så god læselyst!
CPU Metrikker:
CPU orienterede målinger er de mest almindelige målinger, der analyseres. De er også de mest misforståede i virtuelle miljøer.
cpu.extra.summation
cpu.extra.summation metrikken måles på VM niveau og den indikerer , om der er uoverensstemmelse imellem I/O traffik og CPU proceshastighed. Denne uoverensstemmelse forårsager tidsforsinkelser kendt som I/O Wait på VM processer – og dette opfattes som et performance problem.
Hvis denne metrik er analyseret alene, vil man ikke få særlig meget nyttigt information; og VMWare har oplyst at cpu.extra.summation metrikken er upålidelig , da oplysningerne kan være misvisende.
VMware har derfor fjernet cpu.extra.summation fra vSphere 4.0. Dér hvor man tidligere kunne vælge metrikken, er der nu en blankt rubrik med teksten ”n/a”.
Metrikken er derimod stadig nyttig, når man vil finde performance problemer. Cpu.extra.summation er en indikator af mulige CPU Ready problemer og den kan give viden, når den bruges som en relativt værdi under fejlfinding blandt flere virtuelle objekter.
Høje cpu.extra.summation værdier i et bestemt område af en virtuel infrastruktur opstår, når en VM ikke har nok processorkraft allokeret, eller fordi der er CPU Ready problemer.
VMs, som lider af CPU flaskehalse, kan adresseres ved at allokere flere CPU ressourcer eller ved at løse CPU Ready problemerne.
cpu.ready.summation
Bemærk: En værdi i denne metrik indikerer, at der findes en flaskehals i det virtuelle miljø.
cpu.ready.summation metrikkern måles på VM niveau i real-time, og den vurderer, om en VM har CPU Ready problemer. CPU Ready problemer er et resultat af overudnyttelse og dette sker, når VMs er i strid med hinanden om brugen af et begrænset antal fysiske kerner. Denne strid skaber ventetid.
Ventetiden opstår, når en VM venter på, at transaktionen hos den en anden VM afsluttes, så den selv kan fuldføre sin egen transaktion. Ventetiden, som er et resultat af, at CPU Ready forårsager langsommelige transaktioner, hvilket opfattes som et performance problem.
Den bedste praksis på VM niveau siger, at en CPU Ready flaskehals opstår, når mere end 5 % af tiden brugt i en CPU transaktion er ventetid på ledige fysiske CPU ressourcer.
Selvom VMware forsøger at skedulere en VM til at bruge en fysisk kerne – på en måde hvor belastningerne balanceres - så kan denne skedulering distribueres for bredt og tyndt, hvis (alt)for mange virtuelle kerner er provisioneret pr. antal fysiske kerner.
For at undgå tynd distribution af CPU ressourcer, vil mange organisationer forsøge at rationere 3 virtuelle CPUer til en fysisk CPU som maksimum ressourcetildeling.
CPU Ready problemer kan være svære at opdage og dette er årsagen til mange performance problemer. Løsningen på CPU Ready problemer er at re-balancere VM belastninger ved at sprede brugen af fysisk CPU eller ved at ”right-size” en VMs CPU ressource allokering. CPU Ready problemer kan undgås ved at monitorere CPU forbruget med cpu.usagemhz.average og cpu.extra.summation.
cpu.usagemhz.average
cpu.usagemhz.average metrikken viser det fysiske CPU forbrug og dette er målt på VM niveau. En høj måling i cpu.usagemhz.average metrikken viser, at CPU forbruget for en fysisk CPU ressource nærmer sig, eller har nået - fuld udnyttelse. Det er muligt, at VMs med en høj værdi i denne metrik oplever ventetider i performance, da overudnyttelse af CPU kan føre til CPU Ready problemer. Her venter kommandoer på tilgængelige ressourcer.
Selvom en høj cpu.usagemhz.average metrik alene ikke er ensbetydende med, at en flaskehals finder sted, så kan det være en indikator for, at værdierne skal følges nøje. Denne metrik kan hjælpe en systemadministrator med proaktivt at undgå performance problemer. Denne metrik kan også bruges til at isolere årsagen til flaskehalsen på CPU ressourcen.
Nogle VMs vil lejlighedsvis bruge 100 % af de allokerede ressourcer, baseret på deres behandlingskrav, som kan føre til problemer med andre VMs, som skal dele disse ressourcer. VMs med høje cpu.usagemhz.average værdier bør undersøges i en længere periode, for at vurdere hvordan CPU forbruget udvikler sig gennem VMens aktive perioder. Den eneste måde at løse CPU relaterede flaskehalse er at allokere flere CPU ressourcer til VMs, som oplever problemer, der opstår som følge af CPU overudnyttelse.
Disk Metrikker:
disk.busResets.summation
Bemærk: En værdi i denne metrik indikerer, at der findes en flaskehals i det virtuelle miljø.
En disk bus reset er, når alle kommandoer, som har ventet i en kø i en HBA eller Disk Bus, er blevet slettet. disk.busResets.summation metrikken måler, hvornår en disk bus reset har fundet sted. Denne metrik er målt på VM niveau i real time.
Hvis disk.busReset.summation metrikken har en værdi på en VM, kan det indikere, at der er et alvorligt diskrelateret problem. Det er muligt at:
· en disk er blevet overbelastet af for megen trafik fra:
- For mange VMs som tilgår denne disk
- For mange instrukser, der stammer fra de VMs, som tilgår disken
· der er andre overførselsrelaterede problemer
· der er sket en hardware fejl
VMs med en disk.busResets.summation værdi vil lide af træghed og kan fryse eller crashe.
Systemadministratorer kan forsøge at fejlfinde dette problem ved at kigge på VM trafik på disken for at se, om der er et overførselsproblem fra de VMs, som tilgår disken. Det kan være nødvendigt med assistance fra en storage-administrator for at identificere kerneproblemet. Løsningen på problemet, som er identificeret ved brug af disk.busResets.summation metrikken, kan muligvis kræve et hardware fix eller typisk en re-balancering af VM trafikken ved at flytte VMs over til en anden datastore med mere kapacitet.
disk.commandsAborted.summation
Bemærk: En værdi i denne metrik indikerer, at der findes en flaskehals i det virtuelle miljø.
disk.commandsAborted.summation metrikken er en metrik, som viser antallet af mislykkede forespørgsler, der blev sendt til en disk. Denne metrik er målt på VM niveau i real time. Værdierne for denne metrik for hvert VM burde være 0. Hvis værdien er alt andet end 0, er det en indikation på, at der er et alvorligt disk relateret problem, som straks skal undersøges. VMs med en disk.busResets.summation værdi vil lide af træghed og kan fryse eller crashe. Årsagerne til at denne metriks værdi er alt andet end 0 er:
· en disk er blevet overbelastet af for meget trafik fra:
- For mange VMs som tilgår denne disk
- For mange instrukser, der stammer fra de VMs, som tilgår disken
· Der er andre overførselsrelaterede problemer
· Der er sket en hardware fejl
En systemadministrator kan fejlsøge dette problem ved at kigge på VM trafikken ned til disken og på denne måde se, om der er en gennemløbsfejl. Typisk vil det være nødvendigt med assistance fra en storage administrator for at identificere det problem, der skaber en værdi under disk.commandsAborted.summation metrikken. Løsningen til dette problem kræver typisk en re-balancering af VM trafikken ved at (her mangler vist et ord??) VMs til andre datastores med mere tilgængelig kapacitet eller et hardware fix.
disk.totalLatency.average
Bemærk: En værdi i denne metrik indikerer, at der findes en flaskehals i det virtuelle miljø.
disk.totalLatency.average metrikken viser hvor meget disk latency/latenstid, der forekommer på en disk.
Denne metrik er målt på host niveau i real time. Disk latenstid er den tid det tager at generere et svar, efter en besked er blevet leveret til disken. Denne metrik kan hjælpe med at vurdere, om et storage miljø oplever performance problemer, for hvis latenstiden er høj, så må der være et problem - men eftersom mange problemer kan skabe disk latenstid, er disk.totalLatency.average metrikken ikke præcis og yderligere fejlfinding er nødvendig for at lokalisere det problem, der skaber disk latency.
Disse problemer kan opstå som følge af problemer med hukommelsen eller disk gennemløbet. VMs, som lider af disk latenstid, vil reagere trægt under brug. Disk.totalLatency.average problemer kan løses ved at lave load balancing – find de mest ressourcekrævende VMs og right-size deres ressourcer og/eller flytte disse VMs til andre datastores.
disk.queueLatency.average
Bemærk: En værdi i denne metrik indikerer, at der findes en flaskehals i det virtuelle miljø.
disk.queueLatency.average metrikken angiver den tid en forespørgsel venter i en kø for at blive behandlet af disken. Metrikken er målt på host niveau i real time. Mens tiden hvori en forespørgsel venter i kø stiger, så vil VM performance falde. En høj disk.queueLatency.average værdi opstår som regel samtidigt med disk.totalLatency.average, eftersom forespørgsler venter i kø på grund af den øgede tid det tager disken at behandle dem. Hvis disk.queueLatency.average metrikken viser en høj værdi, skal man også kontrollere disk.totalLatency.average metrikken. Hvis disk latency er et reel problem som nævnt i disk.totalLatency.average sektionen, er der andre performance flaskehalse, som skaber dette problem, og en fuld fejlfinding i hukommelse og gennemløb metrikker skal udføres.
Ligesom problemer med disk latency, kan disk.queueLatency.average problemer løses ved at lave load balancing - altså finde de mest ressource krævende VMs og right-size deres ressourcer og/eller flytte disse VMs til andre datastores eller i sidste ende ved at skifte hardware, hvis der er hardware fejl.
Gennemløb: Et gennemsnit af disk.read.average og disk.write.average
disk.read.average metrikken referer til mængden af trafik, der genereres af at læse forespørgsler mens disk.write.average metrikken refererer til mængden af trafik, som genereres ved at skrive forespørgsler til disken. Disse metrikker er målt på VM niveau i real time. Gennemsnittet af de to metrikker tilsammen bliver måleenheden for gennemløbet. Diskgenneløbet refererer til den gennemsnitlige trafikkapacitet som en VM har i sin forbindelse til disken. Ved at kigge på gennemløbet på tværs af alle VMs kan man identificere hvilke VMs, der genererer den største mængde trafik til disken.
Throughput kan afbildes over tid for at, se om en VM har haft performance problemer på forskellige tidspunkter og aktivitetsniveauer, og hvis denne forøgelse af aktivitet har skabt performance problemer for andre VMs ved at optage alt gennemløb til disken. VMs som lider af gennemløbsproblemer, eller på hosts hvor gennemløbet er begrænset, vil virke træge ved brug. Høje gennemløbsværdier vil pege på disk latenstidsproblemer samt andre disk-problemer som Commands Aborted og Bus Resets. Gennemløbsproblemer kan løses ved at re-balancere belastninger og/eller flytte VMs til andre steder, hvor de vil have nok kapacitet, eller hvor de ikke vil optage kapaciteten som andre VMs kræver.
Memory Metrikker:
mem.active.average
mem.active.average metrikken indsamles på VM niveau, og den måler antallet af hukommelsessider (memory pages), som bruges aktivt af en VM på et givent tidspunkt. Typisk vil en VM ikke bruge al sin allokerede hukommelse på et givent tidspunkt. En del af allokeringen indeholder andre data, som har været brugt for nyligt, men som ikke/ikke længere er aktivt i brug. Eftersom en VM har mere hukommelse allokeret end det, som er i brug på et givent tidspunkt, vil mem.active.average metrikken ikke repræsentere hvor meget hukommelse, en VM har brugt. I virkeligheden er mem.active.average metrikken mere nøjagtig, når et indblik i det samlede hukommelsesforbrug skal dannes. Men man burde stadig evaluere mem.active.average for at få et indblik i, hvor meget aktiv hukommelse, der bliver brugt af en VM på et givent tidspunkt. Ved at evaluere denne metrik sammen med mem.consumed.averagevil kan man vurdere, om en VM har fået allokeret en tilstrækkelig mængde hukommelse. Det eneste måde at løse problemer, som relaterer til mem.active.average, er at allokere mere hukommelse til VM’et eller flytte VM’et til en host, som har mere hukommelse.
mem.consumed.average
mem.consumed.average metrikken indsamles på VM niveau, og den måler mængden af hukommelse, der ialt bliver brugt af en VM. En VM bruger mere end blot den aktive hukommelse, som findes i VM’ets hukommelsessider. En del af den brugte hukommelse indeholder hukommelse, som er blevet brugt for nyligt, men som ikke er aktivt i brug på det nuværende tidspunkt. Den aktive hukommelse og ”tilbageholdt hukommelse” udgør tilsammen det samlede hukommelsesforbrug af en VM – og dette er hvad mem.consumed.average måler.
Evaluering af mem.consumed.average værdier kan være værdigfuld (pun intended), når man vurderer indvirkningen af hukommelsesmangel på performance i en VM. Det er vigigt at vurdere mem.active.average samtidigt for at se, om en VM virkelig lider af hukommelsesmangel. Ved nøje undersøgelse af denne metrik i ressourceforbruget mens en VM arbejder på højt plan, kan man danne et sig et indblik i, hvor meget hukommelse VM’en skal have allokeret. Vigtigst er forståelsen for, at visse VMs vil bruge al den hukommelse, der er til rådighed, og hvis en VM viser høje mem.consumed.average værdier, vil det være nødvendigt at undersøge, om det er en af ”memory hog” applikationerne, som er skyld i problemt. For disse typer VMs vil brug af mem.consumed.average metrikken som en tærskel til fremtrædende hukommelsesmangel ikke virke. Den eneste måde at løse hukommelsesmangel som mem.consumed.average og mem.active.average på er ved at tilføje eller allokere mere hukommelse til VM’en eller ved at flytte den til en host, som har mere hukommelse.
mem.overhead.average
mem.overhead.average metrikken måler mængden af hukommelse, som bruges til at administrere allokeret hukommelse og som indsamles på VM niveau pr. host. På grund af måden VMs – og computere generelt – bruger deres hukommelse, skal en del af hukommelsen bruges til at administrere sig selv. Denne process er den måde, en computer holder styr på, hvad dens egne ressourcer laver. En vigtig bemærkning til denne adfærd er, at det supplerende overhead tilføjer et krav til mere hukommelsesbrug af en VM end det, som er allokeret af systemadministratoren. Jo større mængde hukommelse, der allokeres til en VM, jo mere hukommelse skal bruges til overhead. Tabellen nedenfor fremstillet af VMware viser en akkurat læsning for hvor meget overhead, der er behov for – pr. VM - baseret på hukommelse og antal CPUer for en given VM. Eftersom hukommelse er den mest begrænsende ressource, er iagttagelse af mem.overhead.average metrikken afgørende for at undgå noget, der kan føre til hukommelsesmangler, der ikke fremgår tydeligt.
Kilde: vmware.com [Link]
Memory Swapping: mem.swapin.average, mem.swapout.average og mem.swapped.average
Bemærk: Værdier i disse metrikker indikerer, at der findes en flaskehals i det virtuelle miljø.
mem.swapin.average, mem.swapout.average og mem.swapped.average metrikkerne evalueres samtidigt for at måle, om der opstår memory swapping flaskehalse. Disse metrikker måles på VM niveau, og det samlede gennemsnit bruges til at danne en procent værdi. Memory swapping er en handling, som computere gennemfører for at administrere deres hukommelse. Hvis en computer’s hukommelse er fuld og der er ikke yderligere kapacitet for at forvalte informationer, vil computeren tage noget af indholdet i sin hukommelse og ”swappe” det ned i storage på en disk, for at den så kan tage imod nye informationer i den nu ledige hukommelsesplads. Hvis noget af den hukommelse, som er blevet swappet skal bruges, vil VMen forespørge i den gamle hukommelse fra disken og swappe den ind igen, så den kan bearbejdes. Denne process er ekstremt tidskrævende og kan forårsage meget lange (læs:meget lange) proces tider, da informationen skal bevæge sig igennem netværket til disk systemet og derefter skal behandles af disken(e). Ligeledes vil denne meget lange proces opstå, når informationen skal swappes tilbage til hukommelsen fra disken. Som følge af de massive ventetider vil performance niveauet synke drastisk, hvis VMer swapper hukommelse. Memory swapping kan tilgengæld skabe andre flaskehalse, da swapping af store data blokke kan tilstoppe gennemløbet. Forøget gennemløb vil have en negativ effekt på disken, og dette vil resultere i disk latenstid samt andre disk problemer.
Memory swap er i det hele taget en indikator på, at der ikke er allokeret nok hukommelse til VMen, eller der kan opstå ballooning, og dette nedskærer hukommelsen til en VM på en host. For at løse en memory swapping flaskehals skal man tildele mere hukommelse til VMen og udføre yderligere fejlsøgning for at finde ud af, om swapping sker som følge af ballooning.
mem.vmmemctl.average (balloon)
Bemærk: En værdi i denne metrik indikerer, at en flaskehals forekommer i det virtuelle miljø.
En værdi i mem.vmmemctl.average metrikken er en indikator på, at der foregår ballooning. Ballooning opstår, når VMer bruger flere hukommelsesressourcer og begynder at nå grænsen, enten fysisk eller defineret i ressource grænsen i VMware. VMware vil, som følge af forøget aktivitet i en VM, administrere og bevilge hukommelse til den VM, der har mest brug for det. Ballooning er af afgørende betydning, da den er direkte forbundet til memory swapping, som er en væsentlig årsag til performance problemer. VMware skaber ballooning for at forhindre hukommelsesmangel, men denne process vil skade ”uskyldige tilskuer” VMs. Problemerne opstår, når en VM er blevet frataget sine hukommelsesressourcer og begynder at forøge bruget af hukommelse. VMen vil herefter begynde at swappe hukommelse ned til disken for at gøre plads til flere informationer, som den skal behandle. Denne handling fører til de tidligere nævnte memory swapping problemer. Som før nævnt, kan memory swapping herefter skabe gennemløbs- og disk-problemer. Disse forekommende flaskehalse vil sænke en VMs performance gevaldigt! Værdier i mem.vmmemctl.average metrikken skal undersøges omgående. Endvidere er det muligt, at ballooning sker, fordi VMware har lavet begrænsninger – begrænsninger som systemadministratoren ikke har kendskab til.
Måden at løse flaskehalse, der opstår som følge af ballooning, på er ved at right-size hukommelse for alle VMs, om nødvendigt tilføje mere hukommelse, flytte VMs for at balancere ressource forbuget og vigtigst, se om der er sat begrænsninger i Vmware, som ikke passer til de VMs, der administreres.
Netværksmetrikker:
net.received.average, net.transmitted.average og net.usage.average
net.received.average, net.transmitted.average og net.usage.average metrikker måler VM forespørgsler, netværkstrafik og forbrug. Disse metrikker måles på VM niveau og ligner den information, som opfanges i disk gennemløbet, men disk gennemløbet er direkte relateret til den trafik, der kommer fra en datastore til serveren. Denne metrik kan give indblik i, om iSCSI eller NFS storage er i brug, da kommunikationen for datastore trafikken måles i netværkstrafikken.
Disse metrikker rapporterer på områder, som hvad flaskehalse angår er så små, at store værdier i en mærkbar mængde kun vil blive set på cluster eller datacenterniveau. Selv på disse niveauer repræsenterer net.received.average, net.transmit.average og net.usage.average minimale mængder trafik, hvis de sammenlignes med andre metrikker. Netværksmetrikker er meget sjældent – hvis nogensinde – årsagen til performance flaskehalse.
At finde og løse problemer med analyser fra disse målinger:
For at finde problemer i data leveret af disse metrikker skal et datacenter kunne trække rådata ud og behandle dem med avancerede analyser for at sammenligne værdier og afvigende værdier og se om problemer opstår på specifikke tidspunkter. Derudover skal visse metrikker analyseres på VM niveau samt host, cluster og ressourcepool niveau. Endnu vigtigere er det, at et problem i en metrik for en VM kan være forårsaget af hændelser, som sker på et andet VM. Disse beregninger kan være komplicerede at sætte op og kræver store mængder proceskapacitet for, at de kan fuldføres. Mens ressourcer deles, skal analysen vurdere, hvordan VMs interagerer med hinanden og samtidigt analysere enkelte VMs, hosts, clusters og ressourcepools.
Løsning af eksisterende problemer gennem analyse af de to metrikker:
Løsningen til problemer, som de 20 metrikker afslører gennem analyse af data fra vCenter, omfatter normalt konfiguration af indstillinger for miljøet, right-sizing af ressource allokeringer for en VM, rebalancering af VMs på tværs af udstyret for at distribuere belastninger bedre eller undersøgelse af hardware, hvis en flaskehals muligvis opstår som følge af et hardware problem. Efter man har opdaget en flaskehals, er yderligere analyse af data nødvendigt for at finde ud af, hvad den begræsnende ressource er eller for at undersøge et mønster, som kan give dig et hint om, hvad problemet er.
Konklusion:
Deling af ressourcer i et datacenter gør det mere komplekst at sikre, at en VM har de ressourcer, den har brug for for at kunne fungere, som den skal. De 20 metrikker beskrevet ovenfor bør monitoreres aktivt, når man skal administrere et miljø og sikre høj performance af alle VMs. På grund af de store mængder oplysninger, der genereres i real-time, skal data fra disse 20 metrikker analyseres rettidigt for ikke blot at identificere en flaskehals, men for at forhindre flaskehalse i at opstå, når tidlige varslingsindikatorer identificeres.
Bemærk: Værdier i disse metrikker indikerer, at der er en flaskehals i det virtuelle miljø.
Draware A/S
