Gæstebloggen

5 myter om virtualisering

Virtualisering er et område med mange myter, som det er på tide at punktere een gang for alle. Det gælder især myter om virtualisering af forretningskritiske applikationer.

Faktum er, at virksomheder ikke kan sikre konstant tilgængelighed til data og applikationer, hvis forretningskritiske applikationer ikke kører virtuelt. Og virksomheder, som fravælger virtualisering, går glip af muligheden for at reducere omkostninger, styrke pålidelighed og forbedre fleksibilitet.

Her er en liste over fem hyppige myter om virtualisering, som kan få virksomheder til at tage nogle forkerte beslutninger.

Myte 1 – Applikationer kører bedre på fysiske systemer

Mange tvivler på, at virtuelle systemer kan levere same ydelse som fysiske servere. Selvom det engang var tilfældet, er det ikke længere korrekt. Med de rigtige løsninger kan virtuelle systemer faktisk opnå en bedre ydelse end fysiske systemer.

Samtidig gør virtuelle maskiner det muligt at sikre tilgængelige data 24/7 og tilpasse virksomhedens systemer efter behov.

Når man kan opnå bedre ydelse med en virtuel maskine, imødekomme de øgede behov og sikre, at systemet altid er oppe, giver det mening at afvikle så mange applikationer som muligt virtuelt.

Myte 2 – Virtualisering (eller always-on) er alt for dyrt

Denne myte er fundamentalt forkert! Både i forhold til server- og licensomkostninger. De indledende investeringer i nye servere udlignes, når omkostninger til strøm og serverkøling reduceres.

Og så er der besparelser at hente på licenser, fordi nogle udbydere tilbyder særlige løsninger for virtuelle miljøer.

Myte 3 – Man kan ikke tage ordentlig backup af virtuelle maskiner

It-ansvarlige skal imødekomme hårde SLA’er for forretningskritiske applikationer. Derfor har de brug for at vide, at deres backup- og gendannelsessoftware er til at stole på, så de kan sikre datatilgængelig til enhver tid.

Det er en myte, at virtuelle maskiner ikke har ordentlige muligheder for backup. Rent faktisk kan moderne backupløsninger reducere RPO’er og RTO’er til mindre end 15 minutter. Og det er uanset om applikationen kører virtuelt eller ej. Virtuelle systemer tilbyder faktisk betydeligt hurtigere genetablering af forretningskritiske applikationer end fysiske systemer.

Myte 4 – Virtualisering er ikke sikkert for forretningskritiske applikationer

I modsætning til den almene opfattelse, kører forretningskritiske applikationer bedst i virtuelle systemer. Med nye storage-løsninger og cloud-strategier er det moderne datacenter den bedst mulige platform for forretningskritiske applikationer – og det moderne datacenter er kendetegnet ved visualisering, som bidrager med konstant tilgængelighed og øjeblikkelig skalerbarhed.

Dermed understøtter virtualisering de forretningskritiske applikationer og gør det muligt for virksomheder at leve op til kundernes forventninger.

Myte 5 – En kompromitteret applikation udgør en risiko for øvrige applikationer
Det er en myte, at en kompromitteret applikation er en risiko for alle øvrige applikationer. Frygten er ubegrundet, fordi virtualisering med grundprincipperne om isolation og adskillelse har en indbygget beskyttelse mod vira, som ikke kan spredes på tværs af virtuelle servere.
Derudover har moderne hypervisors fået en meget lille og hårdfør overflade, som gør det endnu sværere at kompromittere end en virtuel maskine.

Fremskridt indenfor netværksvirtualisering har også gjort et komplet virtuelt netværk med firewalls, routers og switches til en realitet. Det virtuelle netværk kan således kontrolleres og sikres på samme måde som et fysisk netværk.

Kommentarer (17)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Brian Hansen

Der IKKE har virtualiseret alt i serverparken endnu?
Og hvis ja, hvorfor?
Hvis du f.eks. har 20 servere der hver bruger 400w med tilhørende disksystem, så kan du med 3 større servere og et SAN spare ca. 100k om året i strøm.
Investeringen kan gøres for omtrent 300k, så efter bare 3år kommer der 100k ud af IT budgettet pr. år.
Og næste gang hardwaren skal opgraderes kan det laves i arbejdstiden, uden nedetid what so ever (hvis vmware vcenter, hyper-v er jeg ikke sikker på kan)

Flemming Riis

Der IKKE har virtualiseret alt i serverparken endnu?

pga visse applikationer og leverandøre har et meget underligt forhold til licenser i den virtuelle verden

Samt mængden af blame game der starter mellem kunde og leverandør nogle gange overstiger værdien hvis en app er langsom.

Men de fleste applikations leverandøre kunne starte med at komme med krav spec der passer til virkeligheden , og begrunde deres krav

Claus Juul

Det er en noget unuanceret historie der gives her.

"Samtidig gør virtuelle maskiner det muligt at sikre tilgængelige data 24/7"
Det kræver så lige en HA løsning på både Hypervisor og Storage

"Man kan ikke tage ordentlig backup af virtuelle maskiner"
Du har ret, selvfølgelig kan man det, men det kræver indsigt og forståelse for de udfordringer der er i virtualisering.

"Det er en myte, at en kompromitteret applikation er en risiko for alle øvrige applikationer"
Hvis din applikation er kompromitteret, så har du et problem, for din applikation arbejder sjældent alene, den kommunikere måske med andre applikationer, så der vil være en mulighed for at kommunikere (kompromittere) andre applikationer.
OG så lå Hacking team ind med sårbarheder der i HyperV kunne udnyttes til fra gæsten at kompromittere hosten, og det er usandsynligt at der ikke findes flere sårbarheder i samme genre.

Mads Bendixen

Og hvis ja, hvorfor?


1) Vi har nogle fysiske domain controllere. 1 unit, 1 low-voltage cpu i hver. Det er rart at AD'et i det mindste virker, når det virtuelle cluster går i hegnet af ukendt årsag.
2) Vi har et par fysiske database-servere pga. genbrug af licenser. Der var dengang ikke økonomi i et købe nye licenser, som var nødvendigt hvis de skulle virtualiseres.
3) Vi har et par fysiske frontend web-servere, som inden for ~1 år konverteres til loadbalancere.

Morten Wegelbye Nissen

Vil jeg stille mig skeptisk overfor.

Jeg kan ikke forstille mig andet end at der nok skal vise sige nogle fejl i enten hw eller sw der gøre at Dr. Evil fra en virtuel maskine kan bryde og og komme til at kører på host maskinen og derigennem alt hvad hjertet ønsker.

Jeg ved godt at forskellige sælgere og konsulenter mener det er sikkert nok og at man bare kan lave et virtuelt net osv. osv. Men jeg kan ikke se hvorfor leverandørne af de forskellige løsninger ikke skulle have en sikkerhedsfejl eller to gemt rundt omkring.

Men hvad med punkt 6 :) Jeg hører stadig fra enkelte at specielt en database server typsk performer bedre på dedikeret hardware, har du en holdning til det?

Baldur Norddahl

Der IKKE har virtualiseret alt i serverparken endnu?

NTP server på en virtuel server giver et skuffende resultat. Do not do it.

10G og 40G netkort kræver nogle gange adgang til den fysiske hardware hvis du skal have maksimalt ud af det. Og selvom du kan overføre et PCI device til en VM, så forsvinder pointen lidt hvis der kun er én VM per fysisk maskine der så kan køre applikationen.

Grafikkort kan udnyttes til tunge beregninger og det er også et område hvor der ikke helt er plads til virtualisering. I det hele taget er der ikke så meget pointe i klassisk virtualisering hvis din applikation kræver en hel cluster af maskiner.

Og så lige et andet alternativ: Jeg har lige installeret nogle servere med Ubuntu 16.04 LXD. Det giver meget bedre udnyttelse af hardwaren end traditionel virtualisering: https://insights.ubuntu.com/2015/05/18/lxd-crushes-kvm-in-density-and-sp...

LXD achieves 14.5 times greater density than KVM
LXD launches instances 94% faster than KVM
LXD provides 57% less latency than KVM

Ovenstående vil også passe selvom man udskifter KVM med VMWare.

Jens Jönsson

Men hvad med punkt 6 :) Jeg hører stadig fra enkelte at specielt en database server typsk performer bedre på dedikeret hardware, har du en holdning til det?

De nyeste MS SQL server versioner er optimeret til et virtuelt miljø. Det er svært direkte at måle om det performer dårligere, for når du opgraderer går du typisk fra gammel fysisk hardware til ny virtualiseret.
Jeg vil i øvrigt tro at det samme er gældende for f.eks. MySQL...

Jeg har visualiseret mange servere i gennem tiden og er faktisk ikke i nævneværdig grad stødt på problemer, som myterne omtaler. Faktisk har afvikling på hardware givet de nævnte problemer, f.eks. Disaster Recovery, hvor det engang var en udfordring at tage en ny hardware boks i brug og smide OS+data retur, pga. manglende driverkompatibilitet...

De udfordringer der har været har typisk været relateret til at applikationen, der skulle afvikles, krævede en eller anden form for speciel hardware, f.eks. licensdongle, kommunikationsinterface (f.eks. serielt) osv.
Men mange gange kunne det lade sig gøre ved at være kreativ, f.eks. med USB netværksserver osv.

Carsten Hansen

Hvis den virtuelle software fejler, så står man med et meget stort problem pga. Single-Point-Of-Failure
http://www.computerworld.dk/art/152464/vmware-boss-beklager-esx-fejl-lov...

Derudover så har jeg haft AD og backupserver udenfor VMWare.

Det kan være, at der er brug for specielle indstikskort eller porte, så det er nemmere med en fysisk server. Det kan også være, at software-/telefonleverandøren ikke "understøtter"/anbefaler virtuelle servere.

Der kan være problemer med at skalere, hvis SAN'et er ved at være fyldt op. Så kan det nemmeste være at købe nogle fysiske servere indtil den næste store investering.

Der kan opstår problemer med licensen, hvis der skal betales for den fysiske servers CPU'er og ikke den enkelte virtuelle server:
https://www.version2.dk/artikel/hvad-skal-jeg-betale-virtualisere-min-da...

NB:
Ellers har jeg været meget tilfreds med virtuelle servere.

Morten Brørup

Til almindelige servere er virtualisering rigtig godt, og i store træk er jeg enig i, at performancedegradering ved virtualisering er en myte.

Nu vil jeg skrive lidt om virtuelle netværksappliances, som jeg har førstehåndserfaring med. Undervejs får I også et vigtigt tip om at vælge den rigtige virtuelle NIC til jeres virtuelle servere og appliances. :-)

I SmartShare Systems udvikler vi udstyr til båndbreddeoptimering. Vi har også udviklet en virtuel appliance til VMware, "SmartShare StraightShaper VM".

I udviklingsfasen testede vi de forskellige vNIC-drivere. Den optimerede VMXNET3-driver er klart bedst, E1000-driveren performer hæderligt, og de andre alternativer er håbløse. Så en forudsætning for god netværksperformance på en virtuel maskine med meget netværkstrafik er, at den benytter VMXNET3-driveren (eller E1000-driveren).

StraightShaper VM har vi testet til at kunne håndtere 1 Gbit/s fuld duplex, svarende til en af vores fysiske modeller, "SmartShare StraightShaper 8000". StraightShaper VM bruger kun 1 vCPU, så vores test beviste helt utvetydigt, at virtuelle maskiner kan performe rigtig godt!

Men så stopper festen, når det kommer til netværksappliances.

For vi har kun testet StraightShaper VM i et kontrolleret miljø, dvs. på en VMware-certificeret fysisk server, der ikke lavede andet end at køre vores virtuelle appliance.

Vi designer, udvikler og tester vores isenkram til specifik performance - ganske som de fleste andre producenter af netværksudstyr. Og det betyder, at vi kan oplyse og stå inde for modellernes kapacitet. Derimod afhænger en virtuel appliance's performance af især tre ting:
1. at den virtuelle appliance er egnet til virtualisering,
2. at den fysiske server er dimensioneret korrekt, og
3. at de andre virtuelle maskiner på den samme fysiske server ikke i for stor grad påvirker de ressourcer, der bliver delt med den virtuelle appliance. Og her taler jeg ikke kun om CPU og RAM, men også om hypervisorens netværksstak, den fysiske servers NIC og båndbredden på serverens PCIe-busser.

Så vi kan altså ikke stå inde for en virtuel appliance's performance, når den afhænger af faktorer, som er udenfor vores kontrol. (Flemming har allerede nævnt "blame game" - og i netværksbranchen er der tradition for, at producenterne oplyser udstyrets performance, så man har mulighed for at dimensionere netværket korrekt.)

Netværksnørderne her på Version2s debatforum har måske også bemærket, at fx Juniper, som ellers altid har været gode til at specificere deres udstyrs garanterede performance ved IMIX, heller ikke specificerer garanteret performance for deres virtuelle netværksappliances.

Med venlig hilsen

Morten Brørup
CTO, SmartShare Systems

Morten Brørup

"NTP server på en virtuel server giver et skuffende resultat. Do not do it."

Det kan fikses ved at reservere 25 ~ 50 MHz ti den givne maskine, det er nok til at holde uret i gang... ellers sætter hypervisoren den på hold fordi det "ser ud som om den ikke laver noget".

Som Baldur nævner, er der for meget latency og jitter på virtuelle maskiner til systemer med krav om ekstremt høj tidspræcision, fx NTP.

Tilbage i 2007, under udviklingen af vores SmartShare StraightShaper VM, fik jeg fra VMware svar om, at default scheduling quantum er 50 ms, men kan konfigureres til lavere værdier, fx 5 ms. Dengang kunne man på en server med flere kørende virtuelle maskiner ikke garantere under 1 ms latency (for schedulering af en specifik virtuel maskine), selv hvis der var reserveret et antal MHz til den pågældende virtuelle maskine.

Ifølge mine informationer fra dengang er Maciejs løsning rigtig god, og nok det mest optimale, men den kan ikke garantere latency under 1 ms. Men det kan naturligvis godt være blevet endnu bedre i dag - det var trods alt 9 år siden.

Desuden er det muligt, at 1 ms latency/jitter er tilstrækkeligt til almindelige NTP-behov. Personligt betragter jeg det som sandsynligt.

For at vende tilbage til myte 1, vil jeg påstå, at en korrekt optimeret virtuel server kørende på en korrekt optimeret fysisk server, i mange tilfælde kan bringes tæt på performance svarende til en fysisk server. (Omend det kan være på bekostning af de andre virtuelle servere på samme fysiske server, hvilket introducerer mere kompleksitet, hvis man vil undgå "blame game".)

PS: I kan jo kigge på Poul-Hennings arbejde, hvis I vil vide mere om NTP. ;-)

Med venlig hilsen

Morten Brørup
CTO, SmartShare Systems

Henrik Jacobsen

En ledende medarbejder i et firma, som lever af virtualiseringsløsninger, skriver om hvor fantastisk virtualisering er, og hvordan ulemperne er totalt ikke eksisterende. Suk...
Uanset at pointerne sikkert er rigtige langt hen ad vejen.

Michael Hansen

Generelt kører 98% virtuelt her, det eneste der ikke er, er reelt et stort MS SQL AG setup (hver node har >2TB mem/40/(80) cores, bevares det kunne virtualiseres, men så ville det køre med 1 VM per host anyway pga. det kører noget mega performance kritisk), så gav ikke rigtigt nogen fordele at virtualisere for os med vores specifikke workload.

Men vi er faktisk ved at se på at trække nogle ting tilbage ud på alm. fysiske servere igen, specielt vores web servere, hvor hver node idag gladeligt spiser 20-30Ghz cpu hver, der er intet specielt ved dem, så hvis en enkelt node ryger ud smider load balancerne alligevel bare noden ud af rotationen, så hver node behøver som sådan ikke være videre højt tilgængelig, skal det reinstalleres er det bogstaveligt bare F12, vent lidt tid og done, de har intet state liggende lokalt.
(og jo det er meget meget billigere i licenser i det her konkrete tilfælde, vi har lavet beregningen, vi sparer en del vSphere Ent Plus licenser/support aftaler (ikke billigt med de mange fysiske cpu sockets vores host servere kræver), og der er en del web nodes.

Men igen det er 2 meget specifikke cases her hvor jeg er, men ellers er jeg ret enig, det meste kan virtualiseres idag, men forskellige setups kan have forskellige cases der gør man ikke nødvendigvis vil virtualisere alt selvom man sagtens kunne rent teknisk.

Mads Bendixen

I kunne overveje noget i stil med Citrix Provisioning Services. Det er ment til brug i forbindelse med Xenapp/Xendesktop, men burde kunne bruges til alt mulig andet også.
Noderne streamer bare (det nødvendige) dele af et (read-only) image fra PVS-serveren. De lokale diske i noden er bare til cache og evt. persistente data, som f.eks. eventlogs.

Men på den anden side, så lader det til fordelen i jeres tilfælde udelukkende er "turn-around" tiden - reboot vs network install.

Log ind eller Opret konto for at kommentere
Brugerundersøgelse Version2
maximize minimize