Virtual Server memory Oversubscription og Overcommit, en oppskrift på katastrofe?

Etter å ha feilsøkt en del sære feil på virtuelle maskiner i et ESX miljø, bestemte jeg meg for å finne ut mer om hvordan minnehåndtering fungerer i virtuelle miljøer generelt og VMWare spesielt. Jeg har ikke så mye erfaring med oppsett av virtuelle miljøer for produksjon. For meg er det mest en plattform som en del av serverne jeg drifter kjører på, og som jeg må forholde meg til fra den siden. Etter å ha forsket litt på saken kom jeg frem til at en del av mine problemer nok skyldtes Memory Overcommit og det beslektede Memory Oversubscription. Memory Overcommit er et mye brukt uttrykk som virker å ha forskjellig betydning ut fra hvilken bakgrunn man har, derfor begynner jeg med å definere begrepene slik jeg ser dem.

Hva er egentlig Oversubscription og Overcommit?

Det finnes en salig begrepsforvirring rundt Overcommit og Oversubscription. Det gjøres ikke bedre av at de fleste konsekvent omtaler Oversubscription som Overcommit. På noen diskusjonsforum prates det til og med om “Good Overcommit vs Bad Overcommit”.

Oversubscription kan oversettes med overtegning, som er et ord hentet fra finansverdenen. En enklere analogi for oss som ikke jobber i bank er kanskje å sammenligne med flyreiser. Flyselskapene selger rutinemessig flere plasser på en gitt flygning enn det er seter på flyet. Dette går i de fleste tilfeller bra fordi det alltid er noen som ikke når flyet, og et dyktig flyselskap har statistikk som gjør at de kan anslå rimelig nøyaktig hvor mange ekstra seter de kan selge på en gitt avgang. På samme måte kan man på en vertsmaskin for virtualisering som kjører enkelte hypervisor tildele mer minne til de virtuelle maskinene (gjestene) enn det som er tilgjengelig på den fysiske vertsmaskinen. Dette går bra fordi en gjest vanligvis ikke bruker alt minnet den er tildelt.

Overcommit er også et finansuttrykk, og brukes vanligvis for å omtale budsjetter som sprengt. For å fortsette fly-analogien så er det dette som skjer når flere passasjerer møter opp til en flygning enn det er plasser om bord i flyet. Da kan ikke alle være med, og noen må vente på neste fly eller finne en alternativ reiserute. Altså, gjestene bruker mer minne enn det som fysisk er tilgjengelig på vertsmaskinen.

Mer om Oversubscription

Det er selvsagt fordeler med dette, ellers er det lite trolig at hypervisorprodusentene hadde brukt ressurser på å oppfinne og videreutvikle det. Oversubscription av ressurser er en av grunnpilarene bak virtualisering av servere, det å kunne dele på ressursene slik t de utnyttes best mulig. Dog er ikke alle ressurser like lette å dele. En moderne prosessor for eksempel er spesielt utformet for å gjøre mange forskjellige ting samtidig. Den har flere kjerner som hver kan utføre sin oppgave, og i tillegg kan hver kjerne lett veksle mellom flere forskjellige oppgaver så fort at det for brukeren oppleves som om den utfører et mangfold av forskjellige oppgaver samtidig. På denne måten kan flere programmer kjøre samtidig på en datamaskin (multitasking), og det neste steget er å la flere virtuelle datamaskiner dele den samme prosessoren. Minne og disk, som er de andre ressursene som avgjør størrelsen på en server er ikke like lette å dele. De brukes begge til å lagre data, og det er vanskelig å lagre flere sett med data på den samme plassen samtidig. For å få til dette må man finne på noe lurt, og det har selvsagt noen gjort. Grunntanken bak memory Oversubscription er at når man har flere virtuelle gjester på en vertsmaskin så vil de ikke trenge like mye minne samtidig. Man drar nytte av at høy minnebelastning ikke opptrer samtidig på alle gjestene, og man kan også ta hensyn til at de fleste gjester tildeles mer minne enn de faktisk trenger sånn i tilfelle.

Fordelene med Oversubscription

Først og fremst sparer man penger. På en moderne server med mye minne, f.eks. 128GiB, vil prisen på minnebrikkene utgjøre mer enn halvparten av investeringskostnaden. Om vi ser bort fra det minnet som trengs av vertsmaskinen kan vi sette opp følgende regnestykke. Dersom vi setter inn servere som hver er tildelt 8GiB minne kan vi totalt få plass til 16 gjester uten Oversubscription (128/8). Om vi derimot antar at de i gjennomsnitt ikke bruker mer enn 5GiB og tar i bruk Oversubscription vil vi få plass til 25 gjester på den samme vertsmaskinen (128/5 rundet ned). I et virkelig miljø har man selvsagt servere med varierende størrelse, men prinsippet blir det samme, regnestykket blir bare mer komplisert.

Dersom man har et større virtualiseringsmiljø bruker man gjerne også en eller annen mekanisme for å oppnå høyest mulig oppetid. Det vanligste er noe som automatisk restarter en gjest på en annen vertsmaskin i samme cluster dersom en vertsmaskin slutter å fungere. Dette har forskjellige navn hos de forskjellige hypervisorprodusentene, men prinsippet er stort sett det samme. En annen mye brukt funksjon er muligheten for å flytte en gjest til en mellom vertsmaskiner i same cluster uten å stoppe gjesten, enten automatisk eller manuelt. Automatisk flytting brukes for å balansere ressursbehovet i clusteret slik at belastningen fordeles jevnt på vertsmaskinene. Manuell flytting brukes dersom man ønsker å ta ned en vertsmaskin for vedlikehold uten å påvirke gjestene. I begge disse tilfellene ofrer man ytelse for oppetid, så fremt man ikke tar høyde for dette og har ekstra minne slik at et visst antall vertsmaskiner i et cluster kan være nede uten at gjestene går tom for minne.

Hvorfor Overcommit oppstår

Dersom man har dimensjonert miljøet sitt feil og lagt til flere gjester enn vertsmaskinene kan levere minne til samtidig oppstår en større eller mindre Overcommit.

Det oppstår også Overcommit dersom det går ned flere vertsmaskiner i et cluster enn man har tatt høyde for. Man har kanskje designet et miljø med automatisk serverdistribusjon på vertsmaskinene og automatisk restart på en annen vert dersom en vertsamaskin stopper, såkalt High Availability (HA) eller høy tilgjengelighet på norsk. Dersom man da fortsetter å legge til nye gjester til overvåkingsverktøy forteller at nå er det for lite minne så har man for lenge siden tapt HA. En hver nedetid på en vertsmaskin vil da føre til at man enten får katastrofalt dårlig ytelse i hele miljøet, eller rett og slett må slå av en del av gjestene for at noen av dem skal kunne fungere.

Hva som skjer når det oppstår Overcommit

Når Overcommit oppstår må Hypervisoren begynne å veksle (swappe) minne ut til disk. En godt designet Hypervisor vil finne deler av minnet som gjesten bruker lite og veksle ut dette, og forhåpentligvis vil den kunne legge det tilbake i minnet før gjesten trenger det. Du tenker kanskje at jo, men det gjør de fleste operativsystemer uansett. Alle har hørt om virtuelt minne, swapfiler eller noe lignende, og det er en vanlig teknikk for å la brukeren kjøre flere samtidige programmer enn maskinen kan ha i minnet samtidig. Mange operativsystem har gode innebygde rutiner som håndterer dette bra. Men akkurat som det på en arbeidsstasjon kan oppstå problemer nå man har for mange vinduer oppe samtidig vil det også før eller senere oppstå problemer på en virtuell gjest. Dog kan disse ha større konsekvenser enn at man må vente litt før nettavisa kommer opp på skjermen. Det er to hovedårsaker til dette:

  • Den enorme aksesstidforskjellen. Selv de raskeste fiberchannel san-systemer har en random access tidsforsinkelse som måles i millisekund (1m s= 0,001s), mens minne har en tilsvarende aksesstid som måles i nanosekund (1ns = 0,000000001s). Det tar rundt 100 000 ganger lengre å hente noe fra disk vs å hente fra ram. Dersom vi sammenligner med flytransport igjen og sier det tar tre timer å sende en pakke fra A til B med fly, og lar det representere hastighetene på minne, så vil det ta 34 år å sende den samme pakken via disksystemet.
  • Gjesten vet ikke at en del av det den tror er minne egentlig ligger på disk, i motsetning til når den selv veksler deler av minne ut til disk. Og selv om hypervisoren skulle klare å informere operativsystemet om dette, så vil det før eller siden medføre en tidsforsinkelse ett eller annet sted som programmereren som lagde operativsystemet eller tjenesten som går på gjesten ikke har tatt hensyn til. Dermed krasjer noe. Eller data blir korrupt. Eller tjenester slutter bare å virke, for så å begynne å virke igjen etter en stund.

Dermed får vi feil hvor det er vanskelig, om ikke umulig, å koble årsak og virkning fordi feilen forårsakes av en situasjon som skjer utenfor gjesten som opplever feilen. Det kan ta månedsvis å finne årsaken til slike feil, og ofte ender det med at noen foreslår å “devirtualisere” gjesten for å prøve om det fungerer bedre. Sim Salabim, og som ved et trylleslag er problemet borte. Istedenfor sitter man igjen med en fysisk server som egentlig kunne vært virtuell. Noe som koster penger, både på investering og vedlikeholdsbudsjettet. Nå skal det sies at enkelte servertyer etter min mening aldri skulle vært virtualisert i utgangspunktet, men det er et annet tema.

Hva ESX og Hyper-V gjør for å motvirke Overcommit

Hypervisorprodusentene bruker forskjellige metodikker for å motvirke problemene med memory Overcommit. VMWare ESX bruker en ballooning driver på gjesten som vil begynne å kreve store mengder minne på gjestene når en vertsmaskinen går tom for fysisk minne. Dersom mulig, vil gjestene veksle minne ut til disk fra andre programmer, og vmware tildeler minnet som er brukt av balloning-driveren til andre gjester, siden den da vet med sikkerhet at det ikke er i bruk. I tillegg bruker de Transparent Page Sharing, som er en form for deduplisering av minnet på vertsmaskinen. Minneblokker som er identiske på flere gjester lagres bare en gang i minnet. Dette gjør at minnet utnyttes bedre, men koster litt ytelse da det innfører en viss grad av overhead.

Microsoft Hyper-V bruker en fundamentalt forskjellig teknologi, der en gjest har definert et dynamisk minneområde den kan bruke. Den må ha minimum x MiB med minne, men kan bruke opptil y MiB dersom det er ledig minne på vertsmaskinen. Vertsmaskinen kommuniserer da hele tiden med gjestene og styrer hvor mye minne den enkelte gjest får tildelt. Dersom det ikke er mer minne på verten enn det som trengs til å gi alle gjestene sin minimumsverdi, vil man ikke få lov til å starte flere gjester. Slik prøver man å unngå Overcommit, men det forutsetter selvsagt at minimumsverdien er satt riktig av administrator.

Hvordan man unngår Overcommit

Det er egentlig veldig enkelt: Overvåk, overvåk og overvåk. Når man ser at det minker på ledig minne må man slutte å ta i bruk flere virtuelle servere til man har fått fatt i mer minne og/eller flere vertsmaskiner.

Konklusjon

Moralen er at Oversubscription er en fantastisk mulighet for å spare penger og ta i bruk overskuddskapasitet, så lenge man har rutiner for å overvåke minnebruken og passer på at det ikke oppstår Overcommit. Det beste bruksområdet for Oversubscription slik jeg ser det, er som buffer for å håndtere nedetid på en eller flere vertsmaskiner i et cluster. Dersom man bruker Oversubscription i et produksjonsmiljø slik at man har fare for Overcommit ved en normalsituasjon så designer man sin egen virtuelle grevling som før eller siden vil sprette opp og bite en i baken. Når Overcommit oppstår så påvirker det alle gjestene på samme vertsmaskin i større eller mindre grad.

Author: DizzyBadger

SQL Server DBA, Cluster expert, Principal Analyst

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.