Om feilsøking av prosessorrelaterte ytelsesproblemer på virtuelle gjester som kjører i et VMware miljø.
Jeg har skrevet en del om hvordan tilgang på fysiske minne- og prosessorressurser påvirker ytelsen til virtuelle gjester på generell basis her og her. Som jeg nevner er det primært mengden fysisk minne som avgjør hvor mange/store gjester man kan ha på en vertsmaskin. Dersom man først oversubscriber, som gjerne er hele poenget med virtualisering av servere, vil man selvsagt oversubscribe prosessorene også. Når det gjelder minne er det egentlig ganske enkelt å se når det oppstår overcommit, siden det medfører såpass store ytelsesmessige konsekvenser. På prosessorsiden oppstår feilen dog mer gradvis. Jeg har i det siste jobbet litt med å identifisere årsak til en del rare problemer på virtuelle gjester, og har i den sammenheng forsøkt å sette meg inn i hvordan man på VMWare vCenter 4 henter inn de nødvendige grunnlagsdata og analyserer disse.
Avdeling for enkle konklusjoner
Som med alt annet rundt virtualisering finnes det omtrent like mange meninger som konsulenter om hvor stor belastning en fysisk vert tåler, men jeg har på grunnlag av diverse veiledninger og eksperimentering kommet frem til følgende grenseverdier og konklusjoner:
· Dersom core oversubscriptiongraden er mindre eller lik 2.0 unngår du de fleste problemer selv med gjester som trekker mye prosessorkraft. Verdier opp til 3.0 fungerer stabilt dersom en overvekt av gjestene har lav belastning, og dersom alle serverne er lite eller ikke brukt vil selv enda større verdier fungere stabilt. Dersom man har en eller flere gjester som stiller krav til lav ventetid bør man ikke overstige 2.0 selv om lasten er lav.
· Gjester som deler samme vert bør ha likt antall virtuelle prosessorer.
· Dersom man har mange gjester per vert (mer enn 4) bør ikke hver gjest ha mer enn en virtuell prosessor.
· En gjest skal aldri ha flere virtuelle prosessorer en det er kjerner på hver fysiske prosessor på verten. Dvs, har man firekjerners fysiske prosessorer kan ikke gjestene ha mer enn fire virtuelle prosessorer per gjest.
· CPU Ready bør være mindre enn 300ms per 20s. Dersom du overstiger 600ms på en produksjonsserver vil du kunne få problemer som brukerne merker uansett hva slags type gjest du har.
· CPU usage på verstmaskinen bør ligge under 80 prosent til vanlig og ikke ha lange perioder der den ligger på 100% på noen av kjernene.
Core oversubscriptiongrad
Grenseverdien er tatt fra Microsoft sine anbefalinger for Exchange og Lync servere. Dette er prosessorintensive tunge servere som bruker store mengder fysiske ressurser dersom man har en viss brukermengde og kjører i produksjon. Siden de skal virke fint ved en grad på 2.0 antar jeg at de fleste systemer som støtter virtualisering uten å oppgi data for krav til fysiske ressurser vil fungere opptil en grad på 2.0. Det finnes sikkert systemer som krever en lavere oversubscriptiongrad, så undersøk dokumentasjonen for ditt spesifikke system. En må selvsagt også at hensyn til at den fysiske prosessoren er kraftig nok, det er forskjell på en Pentium 3 og en Xeon Nehalem.
Jeg har ikke klart å finne en enkel måte å summere dette i vCenter managementet, så man må telle for hver gjest og vert. Vær obs på at vCenter teller en fysisk kjerne med Hyperthreading eller lignende som to logiske kjerner, mens oversubscriptongraden beregnes ut fra antall fysiske kjerner. Sjekk spesifikasjonen for den fysiske prosessoren om du er i tvil.
Antall virtuelle prosessorer
På en fysisk server vil man naturlig nok ønske seg så mange og kraftige prosessorkjerner som man klarer å få finansiering til å anskaffe. Det er da lett å tenke seg at det samme gjelder i et virtuelt miljø. Dersom man virtualiserer en server med 2 firekjerners prosessorer vil den også normalt bli satt opp med 8 virtuelle prosessorer. Dette kan medføre ytelsesproblemer. VMWare er nemlig slikt satt sammen at når en gjest med n virtuelle prosessorer ber om prosessortid, så må den tildeles n fysiske kjerner. Dette gjelder selv om den bare kjører en enkelt tråd. Dersom det er mange gjester per vert kan dette øke ventetiden på å få ledige ressurser, siden den da må vente på at det er n ledige kjerner samtidig. Denne ventetiden kalles CPU Ready i VMWare, se eget kapittel. I tillegg ønsker VMWare å kjøre alle de virtuelle prosessorene på samme fysiske prosessor. Dette skyldes prosessorcache, stakk og andre interne prosessoravhengige faktorer som gjør at ytelsen går ned når man må splitte en kommando på flere fysiske prosessorer. Dermed vil en gjest med 5 virtuelle prosessorer sannsynligvis oppleves som tregere enn samme gjest med fire virtuelle prosessorer dersom verten har fysiske prosessorer med fire kjerner. Man bør derfor ha et antall virtuelle prosessorer som går opp i antall fysiske kjerner på verten, og som ikke er større enn antall fysiske kjerner. Eksempel: Ved fire fysiske kjerner på vertens prosessorer kan man ha 1, 2 eller 4 virtuelle prosessorer per gjest.
Man bør også ha mest mulig likt antall virtuelle prosessorer på gjester som går på samme vert for å holde CPU Ready lavest mulig. Dersom ytelsesberegninger for systemet som kjører på en gjest viser at det trenger to eller fire virtuelle prosessorer bør dette da kjøre sammen med andre gjester som har samme antall virtuelle prosessorer. De fleste tyngre systemer som databaser og epost krever 2 eller flere virtuelle prosessorer per gjest for å fungere i et virtuelt miljø. Antall virtuelle prosessorer per gjest bestemmer antall gjester som kan gå samtidig på samme vert (se core oversubscriptiongrad).
CPU Ready
CPU Ready er en verdi man kan hente ut statistikk på fra vSphere. Den defineres som summen av antall millisekund (ms) som en spesifikk gjest har ventet på ledig prosessortid i løpet av et gitt tidsrom. Analyse av denne verdien viser om en gjest faktisk opplever prosessor overcommit. Det er verdiene fra siste time som gir best bilde av situasjonen (kalles real-time). Disse verdiene bør observeres på et tidspunkt når miljøet opplever høy belastning, og/eller på et tidspunkt der brukerne av systemet opplever lav ytelse. Disse verdiene måles per 20 000ms (1sekund = 1 000ms). En verdi på 100ms betyr at gjesten i løpet av de siste 20 sekundene brukte 100 millisekund på å vente på tilgang til fysisk prosessor.
Det finnes statistikk bakover i tid, men denne aggregeres for å spare lagringsplass i loggen. Dermed er ikke statistikken like detaljert, men den gir et godt bilde av trender. Alle tall og eksempler her baserer seg på data innhentet med 20 000ms intervall, som er standardintervallet for real-time data. Loggintervallene i vCenter 4 er som standard per dag, per uke, per måned og per år, med henholdsvis 5m, 30m, 2t og 1d som intervaller:
Mer om statistikk fra virtual center: http://communities.vmware.com/docs/DOC-5230
Eksempel på real-time data fra en printserver som har problemer med treg utskrift og utskrifter som forsvinner:
Som vanlig er det ikke en definert grense for hvor stor denne verdien bør være, men ut fra eksperimenter og andre eksempler har jeg komet frem til følgende antagelse:
Alt over 150ms kan føre til problemer og feil på timing-sensitive applikasjoner som videostreaming, lyd osv. Ved verdier over 300ms er det målbar treghet på applikasjoner som snakker direkte med brukerne. Ved verdier over 600 begynner ting å gå tregt eller feile på de fleste typer tjenester. Jeg har lest et sted at VMWare tidligere definerte 5% som en øvre anbefalt grense for produksjon, altså 1 000ms, men jeg finner ikke igjen linken dessverre. Dog har jeg sett produksjonssystemer som opplever 10 000ms CPU Ready uten at brukerne klager, så det avhenger av systemet som kjører på gjesten og av hvor mye brukerne klager. Dersom det rapporteres om problemer med lav ytelse på en gjest med CPU Ready over 600ms kan det ikke utelukkes at den opplever en overcommit, altså mangel på fysiske ressurser. Og dersom en gjest blir stående flere sekunder å vente på prosessortid (i løpet av en 20 sekunders periode) er det nødt til å få konsekvenser et sted.
Konsekvenser
I de fleste tilfeller er den eneste konsekvensen av en prosessor overcommit at systemet oppleves som tregt for brukerne, eller at en automatisk jobb tar lengre tid enn den ellers ville gjort. Det er ikke sikkert at noen klager, og så lenge man har tilgang på nok minne vil mange systemer leve fint med ganske høye CPU Ready verdier. Noen ganger fører det dog til at noe svikter. Problemet er at slike feil er tilnærmet umulige å finne årsaken til, fordi de gjerne oppstår når den totale belastningen på verten stiger, noe som igjen ofte skyldes aktivitet på andre gjester som kjører på samme vert. Selv ikke med en CPU Ready < 100ms kan man garantere at problemet på gjesten ikke skyldes et overcommit-problem. Noen systemer er så følsomme for tidsforsinkelser at de ikke takler virtualisering med oversubscrition. Derimot, dersom gesten opplever en CPU Ready over 600ms og har en feilsituasjon eller noen klager på dårlig ytelse så har du definitivt en mulig årsak. Løsningen er da å skaffe til veie flere fysiske ressurser til det virtuelle miljøet, eller å flytte problemgjesten ut på en egen fysisk maskin. Selv om hypervisorprodusentene blir flinkere og flinkere til å støtte sære systemer så er det fortsatt mange systemer som rett og slett ikke virker i et virtuelt miljø, eller som krever så store ressurser at det ikke lønner seg å virtualisere dem.
Data i denne artikkelen er hentet ut fra et VMware miljø, men om man holder core oversubscriptiongraden på 2.0 eller mindre vil man etter all sannsynlighet unngå problemer relatert til prosessorytelse også på andre hypervisorplattformer.
