Klart det kan virtualiseres!

Det er svaret man får i 19 av 20 tilfeller om man spør noen som skal ha greie på virtualisering om en gitt tjeneste kan virtualiseres. Og de har stort sett rett. Problemet er at man stiller feil spørsmål. Isteden må man spørre seg: “Bør jeg virtualisere tjeneste x i mitt virtualiseringsmiljø? Og “Passer det med min virtualiseringsstrategi?”

Det er nemlig ikke gitt at forskjellige tjenester passer sammen i det samme virtuelle miljøet. Særlig ikke om man har satset og investert tungt i automatisk lastbalansering og høy oppetid.

Virtualisering er fremtiden, ingen tvil om det. Det gjør at man kan utnytte hardware mye mer effektivt en før, man kan spare store penger på strømutgifter og hardwarekostnader, og man kan oppfylle målsetninger om grønn IT og lavere karbonfotavtrykk. Det er ikke uvanlig å kjøre over 20 virtuelle servere på en fysisk vertsmaskin. Nå skal man riktignok ikke legge for mye i slike tall, for dersom man måtte kjøpe fysiske maskiner isteden hadde man sannsynligvis hatt færre servere med flere tjenester på hver server.

Man får også andre fordeler, som muligheten til å skifte ut hardware uten at serveren merker det, og muligheten til å flytte en virtuell server mellom flere vertsmaskiner mens den går slik at vedlikehold blir enklere. Det er rett og slett et stort fremskritt, noe som gjør at man lett sier at alt skal virtualiseres så langt det lar seg gjøre. Og det kan man stort sett oppnå, men det er ikke sikkert at det alltid er like lurt. Dersom man har et cluster med vertsmaksiner der gjennomsnittsserveren er tildelt 5GiB minne er det ikke sikkert at man bør legge inn servere som drar 50GiB i samme cluster.

Jeg skal ikke påstå å ha inngående kjennskap til virtualiseringsplattformer, men jeg har jobbet med optimalisering av Windows-servere siden NT 4, og en server med en gitt tjeneste trenger en viss mengde ressurser uansett om den er fysisk eller virtuell. Denne artikkelen handler mest om mine erfaringer med drift av forskjellige servertyper i virtuelle miljø. Se også artikkelen om Memory Overcommit der jeg skriver om problemer som kan oppstå om man ikke følger med på hvor mye minne som er i bruk på vertsmaskinene.

Virtualisering trenger en plan

Man kan selvsagt bare sette opp et par vertsmaskiner og installere virtuelle gjester til noe slutter å virke, men det er en smule upraktisk i et produksjonsmiljø. Man må gjøre seg tanker om hva slags gjester man skal virtualisere, og sørge for at vertsmaskinene kan levere de nødvendige fysiske ressursene som trengs for å oppnå den ytelsen man ønsker. Videre trenger man en plan for feiltoleranse. De fleste virtualiseringsplattformer beregnet på produksjon har mekanismer som kan starte serveren på nytt på annen hardware dersom en vertsmaskin går ned, og det finnes også lastbalanseringsmekanismer som fordeler gjestene automatisk i et cluster slik at ressursene utnyttes optimalt.

Hvor stor er en server?

Størrelsen på en virtuell gjest avgjøres primært av hvor mye minne den bruker. Man skal ikke se bort fra prosessor og nettverksbelastning, men det er vanligvis minnet som er den avgjørende faktoren. Prosessorkjerner kan vanligvis Oversubscribes med minst 100%. Har man 2 fysiske prosessorer med 6 kjerner i hver, totalt 12, kan man altså tildele minst 24 virtuelle prosessorer med en kjerne. Prosessorsykluser er rimelig lett å fordele, slik at ytelseskurven når alle kjernene går på full last er rimelig lineær etter hvert som man legger til virtuelle prosessorer. 100% på grafen tilsvarer at antall fysiske og virtuelle kjerner er likt.

clip_image001

At alle de virtuelle prosessorene skal gå i 100% last samtidig er svært lite sannsynlig, så man kan trygt oversubscribe prosessorkjernene. Og selv om det skulle blir behov for flere prosessorsykluser enn vertsmaskinen kan levere så vil det ikke føre til at hele vertsmaskinen stopper opp.

Nettverksytelse på en annen side handler stort sett utelukkende om hastighet. Dersom man har ett eller flere 10GB nettverkskort i vertsmaskinen skal man ha svært nettverksintensive gjester for at man skal nå taket her. Det er også både enkelt og relativt billig å legge til flere nettverkskort på en vertsmaskin, så man kan trenger vanligvis ikke bekymre seg for dette.

Minneressurser er derimot ikke like lett. Det samme minnet kan vanskelig brukes samtidig av mer enn en server. Det finnes metodikker for deduplisering av minne, men det er begrenset hvor mye man tjener på dette, samtidig som det kan gi ytelsestap. Hovedproblemet er dog at dersom man Oversubscriber minne vil man ha god ytelse til man når et punkt der ytelsen faller katastrofalt på alle gjestene.

clip_image002

Dette skjer når mengden minne som er i bruk på gjestene overskrider mengden fysiske minne som er tilgjengelig på vertsmaskinen. Det kalles memory overcommit, og er noe man må gjøre sitt beste for å unngå.

Databaseservere

De fleste databaseservere er designet for å utnytte alt minne serveren tildeles når den settes under belastning. De bruker dette minnet til å cache data, slik at dataforespørsler går raskere. Man kan gjerne styre hvor stor denne cahcen er, og vanligvis prøver en å sette det opp slik at man har rundt 500MiB minne ledig ved full cache. Dermed sikrer en at databasetjenesten holder ytelsen opp når operativsystemet trenger ressurser til andre ting, som for eksempel sikkerhetskopiering. Cachingen gjør at det ligger en del data i minnet som aksesseres relativt sjelden, noe som gjør at virtualiseringssystemet kan finne på å veksle dette ut til disk dersom andre gjester trenger mer minne. På grunn av dette bør man ikke oversubscribe minne som brukes på databaseservere, de bør ha dedikert fysisk minne.

Exchange

Exchange mailboksservere fungerer på samme måte som databaseservere når det gjelder minnebehov. Det finnes verktøy for å kalkulere hvor mye minne en mailboksserver bør ha basert på antall epostkontoer og trafikkmønster, og på samme måte som databaseservere bør disse ha dedikert minne. CAS-servere bruker også minne primært til cache, så det samme gjelder for dem.

Cluster oppå Cluster

Det finnes en del anbefalinger for å bruke cluster på cluster, for eksempel å kjøre MSSql cluster eller Exchange DAG cluster på toppen av et VMWare cluster med vmotion. Dette er en særs dårlig ide. For det første så betaler man dobbel pris for høy oppetid, siden dette er noe som koster ekstra både på gjestene og på virtualiseringsverten. Og siden man ikke har kontroll på hvor vmotion flytter nodene risikerer man at flere noder i det samme clusteret går på samme fysiske server. Man bør velge en av metodene, og et cluster med to fysiske eller en fysisk og en virtuell vil normalt gi best oppetid. Et slikt oppsett vil ha en fysisk server som går selv om den andre feiler slik at det bare er tjenesten som må restartes. Med vmware HA og lignende teknologier blir hele gjesteserveren restartet automatisk på en annen fysisk vert, noe som tar lengre tid i de fleste tilfeller. En slik løsning beskytter heller ikke mot feilkonfigurasjon og korrupte installasjoner, siden man bare har en node, men det er bedre enn ikke å ha noe cluster i det hele tatt. Man sparer også lisenser på gjesten, siden man bare trenger os og tjenestelisenser for en node. Hvilken modell man velger vil alltid være en vurderingssak, men cluster oppå cluster er alltid dårlig ide.

Noe som gir god utnyttelse og samtidig høy oppetid er å sette opp vertsmaskiner med virtuelle gjester tilhørende forskjellige cluster. Om man for eksempel har fire databasecluster vil man normalt ha 8 fysiske servere, der halvparten er inaktive noder. Isteden kan man bruke fire fysiske vertsmaskiner som hver kjører to virtuell noder, en som normalt er aktiv og en som normalt er passiv. Så lenge man har nok minne kan man da miste to av de fire serverne, så lenge man ikke mister begge nodene i ett av clustrene. Dersom man i tillegg legg på virtualiseringscluster, slik at hvert databasecluster har en node i hvert virtualiseringscluster kan man i en ekstremsituasjon kjøre alt sammen på en fysisk server. Dette blir kostbart, men gir god oppetid uten at man har maskiner som er passive. Dermed sparer man strøm, noe som hjelper på miljøprofilen.

Fil

Filservere er etter min erfaring svært virtualiseringsvennlige. Man skal bare være obs på at automatisk defragmentering kan påvirke ytelsen på andre gjester som kjører på samme vertsmaskin, da slike systemer overvåker ressursbruken og kjører defragmentering når det er ledige systemressurser. De kan dog ikke se hvor mye som er i bruk på andre gjester på samme vertsmaskin, og dermed kan de dra ned ytelsen en smule. Det finnes spesielle defragmenteringsverktøy for virtuelle servere som løser dette, for eksempel Diskeeper V-locity som fungerer på vmware og hyper-v.

Et annet potensielt problem er tjenester som krever filservere med konsekvent lav tidsforsinkelse, som videostreaming i sanntid og enkelte grafiske program som jobber med store datasett. Dette vil forhåpentligvis bli løst etter hvert, men per i dag er det fortsatt en del tjenester som fungerer dårlig mot en virtuell filserver. “Vanlige” filtjenester derimot fungerer aldeles utmerket.

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.