Ydeevnen på et virtuelt serversystem er bestemt af de samme fire hovedfaktorer som i en fysisk server: Processorer, arbejdslager, disk og netværk.
Men virtualiseringen indebærer, at meget alligevel er anderledes.
Alfa og omega for at få et velfungerende virtuelt system er, at man måler på de applikationer, der skal virtualiseres, så man kender deres behov.
Det fortæller en af de tekniske eksperter hos VMware, Robin Prudholm:
“Flaskehalsen i dag er den RAM, du har i kassen. Det skyldes, at de moderne processorer med to eller fire kerner har enorm kapacitet. Men der er også et overhead ved virtualisering. Det kommer af, at hver enkelt virtuel maskine ikke må skrive direkte til RAM. I stedet skriver den til virtualiseret RAM, som så skal mappes til fysisk RAM. Det kræver ekstra plads,” siger han.
Gode krumspring
Til gengæld kan nogle tekniske krumspring sørge for mere RAM.
Således kan hypervisor-programmet, der er bindeleddet mellem de virtuelle maskiner og den fysiske hardware, udnytte RAM mere effektivt.
Hvis man har flere virtuelle maskiner med samme operativsystem på en fysisk server, vil mange områder af RAM indeholde identiske data.
Så kan hypervisoren dele det, så data kun gemmes en gang, selvom hver enkelt virtuel maskine tror, at den har det for sig selv.
“Hvis du fylder en VMware ESX Server op med RAM-tunge applikationer, vil du få en omkostning i form af højere memoryforbrug. Men hvis den både kører tunge og lette applikationer, vil det samlede RAM-behov altid være mindre end i en tilsvarende samling fysiske servere,” siger Robin Prudholm.
Start med infrastruktur
Som eksempler på “lette” applikationer nævner han infrastrukturtjenesterne i et netværk: Filservere, print, DNS, WINS, Active Directory og lignende.
Der kører typisk...fortsættes
...én applikation pr. fysisk server, og serveren vil oftest kun blive udnyttet 5-15 procent.
“Det er de lavthængende frugter: De er nemme at gøre virtuelle, og der er penge at spare ved det. Så den er let at sælge til ledelsen. Den dårligste kandidat til virtualisering er derimod den server, der er 100 procent udnyttet,” siger Robin Prudholm.
Som eksempler på applikationer, der ofte vil være svære at virtualisere, nævner han nogle terminalservere og store databaser.
“Vi ser alligevel mange kunder, der virtualiserer Citrix. Men de gør det ikke for at få bedre performance, men for at få andre fordele,” forklarer han.
De andre fordele kan for eksempel være, at serveren ved et hardwarenedbrud kan komme i luften igen i løbet af tre minutter.
Og der er mulighed for nemmere backup og genskabelse af data end ved fysiske servere.
Hvad angår brugen af processoren, giver virtualisering ikke nogen større ekstra belastning.
Det skyldes, at processoren ikke virtualiseres – kun adgangen til den splittes op mellem de virtuelle maskiner. Der er alligevel et overhead på processoren.
Det skyldes, at der går nogle processorressourcer til at køre hypervisoren og virtualisere adgangen til RAM, netværk og disk.
Netværk og diske
“Når det gælder netværk, skal man kende sit behov for I/O. Og så er det vigtigt at bruge fysiske netværkskort, der er beregnet til at sidde i servere. De kan udføre en række funktioner i hardware, som ellers ligger i styresystemet,” siger han.
Adgangen til diske og andre former for datalagring er et område, hvor man tidligere har skullet være meget omhyggelig i planlægningen.
“Det er blevet nemmere, fordi vi nu har mulighed for at flytte filer fra et storage array til et andet, mens systemet er i drift. Så en fejl i designet er mindre alvorlig. Et vigtigt spørgsmål er, hvor mange virtuelle maskiner man vil køre pr. LUN (Logical Unit Number, red.). Vi anbefaler...fortsættes
... højst 16, hvis de kræver høj performance. Men jeg kender en kunde, der kører over 100 virtuelle maskiner pr. LUN, og det kører fint. Så det er helt afhængigt af belastningen,” bemærker han.
Planlæg kapacitet
Før man virtualiserer sine servere, skal man måle deres ressourceforbrug.
Derefter skal man planlægge det virtuelle system.
Hvis serverne skal kunne køre videre efter et hardwarenedbrud, skal man afgøre, om det skal være med fuld kapacitet.
I så fald skal der indkøbes ekstra computerkraft, der giv er plads til at fordele belastningen fra den ramte server på de øvrige.
Når først systemet er oppe at køre, er der ingen garanti for, at det bare kører videre uden problemer.
Derfor anbefaler Robin Prudholm, at man løbende måler miljøets performance.
Der findes også værktøjer, som automatisk griber ind, når performance på en virtuel maskine falder. Så flytter de rundt på opgaverne, så der er en mere ligelig fordeling af virtuelle maskiner på de fysiske servere.
Tidsproblemer
Robin Prudholm nævner et område, hvor virtuelle servere typisk får problemer: De følger ikke med tiden.
Det skyldes, at computere bruger processorens ur til at vide, hvad klokken er.
Men skønt en virtuel maskine tror, at den er alene om at bruge processoren, deler den i virkeligheden adgangen med flere andre.
Så når den tror, der er gået et sekund, kan der være gået mere.
“Jeg anbefaler tidssynkronisering mod ESX Server, som igen er styret af ekstern tidskilde. Det kan for eksempel være den fysiske domain controller eller en NTP-server,” siger han.
