Er virtuelle maskinservere bedre end bare metal?

En del af en Windows® ISV's strategi for applikationshosting er at vælge mellem at køre deres applikation på en bare metal eller en virtuel maskine (VM) server på deres udbyders cloud-tjeneste.

Hvad er forskellen mellem Bare Metal- og VM-servere?

Bare metal-servere er dedikerede fysiske maskinressourcer, der tilbydes af en cloud-tjenesteudbyder. Hele maskinen er dedikeret til ISV'en. Operativsystemet indlæses direkte på maskinen, ISV'ens app kører på det operativsystem, og appen har eksklusiv adgang til alle computerressourcer på maskinen.

I modsætning hertil kører servere til virtuelle maskiner (VM) på en fysisk maskine, men kræver, at der installeres en hypervisor på maskinen ud over operativsystemet. Hypervisoren opdeler den fysiske maskine i flere VM'er, der hver især kører deres eget operativsystem. Mens hver VM kører uafhængigt, deler alle VM'er på en fysisk maskine maskinens computerressourcer.

Når en ISV leverer sin app til brugerne fra en VM-server, bruger de hypervisorer, der er nødvendige for at opdele den fysiske maskine i VM'er, 5 til 10 % af serverens ressourcer, hvilket resulterer i en meget lille forsinkelse. For de fleste ISV'er har denne ventetid en ubetydelig indvirkning på brugeroplevelsen.

Men - hvis ISV'en også bruger en virtuel desktop-løsning som Citrix® til at levere sin applikation, vil ventetiden være mere problematisk. Hvorfor er det sådan?

Citrix' kompleksitet skaber ventetid.

Her er blot nogle få eksempler:

• Ud af boksen er Windows ikke optimeret til Citrix - eksperter tæller 100 eller flere mulige optimeringer, der kan gøres for at reducere ventetiden.
• Ud over installation og opsætning af selve Citrix kræver implementering af et Citrix-miljø koordinering af mange undersystemer, herunder SQL, storage og Microsoft® Active Directory. Enhver fejlkoordinering påvirker ventetiden.
• Selv små problemer i det overordnede design kan øge ventetiden, f.eks. en VM, der er bare en smule underdimensioneret.
• Forkert konfigurerede brugerprofiler vil påvirke applikationens ydeevne negativt.
• Fysisk placering af Citrix Gateway - for at minimere ventetid skal Gateway placeres tæt på serveren.
• Citrix NetScaler kan gøre netværkstrafikken langsommere på grund af fejlkonfiguration eller problemer uden for it-afdelingens kontrol, som CPU- eller hukommelsesspidser og timeouts for retransmission.

Hvorfor så ikke bare vælge en bare metal-server?

Penge.

Bare metal-servere er betydeligt dyrere end VM-servere, selv hvis serverne har identiske arbejdsbelastninger. For det første, hvis en ISV har valgt bare metal, betaler de for hele maskinen, uanset om de bruger alle ressourcerne på maskinen eller ej. For at strø salt i såret, hvis ISV'en har brug for en kold standby-server til disaster recovery (for eksempel en ISV, der har brug for en standby-server til overholdelse af lovgivningen), skal de betale for den maskine, uanset om de har brug for den eller ej.

Hvor mange penge taler vi om? I skrivende stund koster en Amazon Web Services (AWS) t3 large virtual instance (den største t3 virtual instance, som AWS tilbyder) $.10 pr. time. I modsætning hertil faktureres en dedikeret t3-instans fra AWS (dvs. en dedikeret fysisk server) med 5,50 dollars i timen.

Så i en 30-dages faktureringsperiode (720 timer) vil en ISV betale $720,00 for en stor virtuel t3-instans og $3.960,00 for en dedikeret t3-instans. Selvom dette ikke nødvendigvis er en sammenligning af æbler og pærer - vi mangler f.eks. oplysninger om, hvor mange brugere der kan understøttes på hver instans - er det en himmelråbende forskel i omkostninger.

{{CTAEMBED_IDENTIFIER}}

Fleksibilitet, smidighed og skalerbarhed

Ud over ekstra omkostninger får ISV'er, der bruger bare metal-servere, ikke den fleksibilitet og smidighed, som VM-servere leverer. En ny VM-server kan sættes op og implementeres på få minutter. VM'er kan også hurtigt flyttes til et nyt miljø eller en ny fysisk maskine. I modsætning hertil kan opsætningen af en ny bare metal-server tage timer eller endda dage, hvis ISV'en har usædvanlige krav. ISV'er, der bruger bare metal-servere, er nødt til at planlægge og forudsige deres ressourcebehov nøje; ISV'er, der bruger VM-servere, kan være meget mere reaktive og smidige.

VM-servere har en betydelig skalerbarhedsfordel i forhold til bare metal-maskiner på grund af deres iboende fleksibilitet. ISV'er kan justere deres applikationsmiljø ved at ændre størrelsen på VM'er op eller ned, opdele dynamiske arbejdsbyrder mellem maskiner og flytte arbejdsbyrder, apps og data fra en VM til en anden. Når en ISV derimod begynder at vokse ud af en bare metal-server, er den eneste mulighed at tilføje mere hardware, hvilket tager tid og kræver omhyggelig planlægning.

Eksempel fra den virkelige verden

Her hos GO-Global oplevede vi denne situation med en ny ISV-kunde, der brugte Citrix til at levere deres apps til finansielle institutioner fra en offentlig cloud-tjeneste. På grund af softwarens karakter forventede denne ISV's kunder en latenstid på næsten nul, hvilket førte til, at Citrix anbefalede bare metal-servere for at leve op til den forventning.

Efter i årevis at have absorberet omkostningerne ved at bruge Citrix plus bare metal-servere til at give kunderne adgang til skyen, begyndte ISV'ens infrastrukturstyringsteam at søge efter måder at spare på - og fandt GO-Global®.

Da GO-Global er en applikationsudgiver og ikke VDI som Citrix, kræver den ikke en hypervisor, hvilket eliminerer en af årsagerne til ventetid på serverniveau.

På et mere grundlæggende niveau reducerer GO-Global ventetiden på grund af den egenudviklede og patenterede RapidX Protocol (RXP), der bruges til al GO-Global klient-vært-datakommunikation. I stedet for at sende skærmbitmaps over netværket overfører RXP individuelle tegnekommandoer, hvilket giver hurtigere transmission og bedre datakomprimering end andre løsninger. RXP-displayprotokollen er næsten helt asynkron, hvilket betyder, at værten og klienten sjældent venter på et svar fra sin modpart. Til sammenligning sender Citrix tastetryk til applikationsserveren, som gentegner skærmen for hvert tastetryk.

I modsætning til Citrix duplikerer GO-Global desuden ikke offentlige cloud-infrastrukturkomponenter og skalerbarhedsfunktioner. I stedet udnytter GO-Global en skytjenestes eksisterende infrastruktur og skalerbarhedsfunktioner til at levere lignende funktionalitet med mindre kompleksitet og mindre ventetid.

Ovennævnte ISV er i øjeblikket ved at forberede lanceringen af deres nye infrastruktur til levering af applikationer ved hjælp af GO-Global og VM-servere. Skiftet til GO-Global reducerede deres licensomkostninger til levering af applikationer og vil gøre det muligt for dem at holde ventetiden lav for at opfylde kundernes forventninger. At gå fra bare metal-servere til VM-servere har også reduceret deres omkostninger betydeligt.

Som svar på spørgsmålet "Er virtuelle maskinservere bedre end bare metal?" må de fleste ISV'er vælge mellem lavere omkostninger med VM'er eller mindre ventetid med bare metal. Men for den ISV, der omtales i dette indlæg, behøvede de ikke at vælge det ene eller det andet ved at flytte til GO-Global med VM'er, de fik både overkommelige priser og en fantastisk brugeroplevelse.

Hvis du er en Windows ISV, der er på udkig efter en løsning til udgivelse af applikationer, som gør meget effektiv brug af computerressourcer, eliminerer unødvendig kompleksitet og reducerer ventetiden, så overvej GO-Global. GO-Global er en løsning til udgivelse af applikationer der er specialbygget til at udgive Windows-applikationer fra enhver sky - enkelt, nemt og omkostningseffektivt.

Hvis du vil vide mere om GO-Global, kan du anmode om en demo her eller downloade en gratis 30-dages prøveversion.