Är virtuella maskinservrar bättre än Bare Metal?

En del av en Windows® ISV:s strategi för applikationshosting är att välja mellan att köra sin applikation på en bare metal-server eller en virtuell maskin (VM) på leverantörens molntjänst.

Vad är skillnaden mellan Bare Metal- och VM-servrar?

Bare metal-servrar är dedikerade fysiska maskinresurser som erbjuds av en molntjänstleverantör. Hela maskinen är dedikerad till ISV:n. Operativsystemet laddas direkt på maskinen, ISV:s app körs på det operativsystemet och appen har exklusiv tillgång till alla dataresurser på maskinen.

Virtuella servrar (VM-servrar) körs däremot på en fysisk maskin, men kräver att en hypervisor installeras på maskinen utöver operativsystemet. Hypervisorn delar upp den fysiska maskinen i flera VM-servrar, som var och en kör sitt eget operativsystem. Även om varje VM körs självständigt delar alla VM på en fysisk maskin maskinens dataresurser.

När en ISV levererar sin app till användarna från en VM-server förbrukar de hypervisorer som krävs för att dela upp den fysiska maskinen i VM:er 5-10% av serverns resurser, vilket resulterar i en mycket liten fördröjning. För de flesta ISV:er har denna fördröjning en försumbar inverkan på användarupplevelsen.

Men - om ISV också använder en virtuell skrivbordslösning som Citrix® för att leverera sin applikation, kommer latensen att bli mer problematisk. Varför är det så?

Citrix komplexitet skapar fördröjning.

Här är bara några exempel:

• Windows är inte optimerat för Citrix - experter räknar till 100 eller fler möjliga optimeringar som kan göras för att minska latensen.
• Förutom installation och konfigurering av själva Citrix kräver implementering av en Citrix-miljö samordning av många delsystem, inklusive SQL, lagring och Microsoft® Active Directory. Eventuell felkoordinering påverkar latensen.
• Problem i den övergripande designen, även små sådana, kan öka latensen, till exempel en virtuell dator som är något underdimensionerad.
• Felkonfigurerade användarprofiler kommer att påverka applikationens prestanda negativt.
• Fysisk placering av Citrix Gateway - för att minimera fördröjningen bör Gateway placeras nära servern.
• Citrix NetScaler kan sakta ner nätverkstrafiken på grund av felkonfigurering eller problem som ligger utanför IT:s kontroll, som CPU- eller minnestoppar och timeouts för retransmission.

Varför inte bara välja en bare metal-server, då?

Pengar.

Bare metal-servrar är betydligt dyrare än VM-servrar, även om servrarna har identiska arbetsbelastningar. För det första, om en ISV har valt bare metal, kommer de att betala för hela maskinen oavsett om de använder alla resurser på maskinen eller inte. För att strö salt i såren, om ISV behöver en kall standby-server för katastrofåterställning (till exempel en ISV som behöver en standby-server för regelefterlevnad), kommer de att betala för den maskinen oavsett om de behöver den eller inte.

Hur mycket pengar pratar vi om? I skrivande stund kostar en Amazon Web Services (AWS) t3 large virtual instance (den största virtuella t3-instansen som erbjuds av AWS) $.10 per timme. Däremot faktureras en AWS dedikerad t3-instans (dvs. en dedikerad fysisk server) till 5,50 USD per timme.

Så under en 30-dagars faktureringsperiod (720 timmar) kommer en ISV att betala 720,00 USD för en stor virtuell t3-instans och 3 960,00 USD för en dedikerad t3-instans. Även om detta inte nödvändigtvis är en jämförelse mellan äpplen och äpplen - till exempel saknar vi information om hur många användare som kan stödjas på varje instans - är det en häpnadsväckande skillnad i kostnad.

{{CTAEMBED_IDENTIFIERARE}}

Flexibilitet, smidighet och skalbarhet

Förutom extra kostnader får ISV-leverantörer som använder bare metal-servrar inte den flexibilitet och smidighet som VM-servrar ger. En ny VM-server kan konfigureras och distribueras på några minuter. Virtuella datorer kan också snabbt flyttas till en ny miljö eller fysisk maskin. Däremot kan installationen av en ny bare metal-server ta timmar eller till och med dagar om ISV har ovanliga krav. ISV-leverantörer som använder bare metal-servrar måste planera och förutse sina resursbehov noggrant, medan ISV-leverantörer som använder VM-servrar kan vara mycket mer reaktiva och flexibla.

VM-servrar har en betydande skalbarhetsfördel jämfört med bare metal-maskiner tack vare sin inneboende flexibilitet. ISV:er kan justera sin applikationsmiljö genom att öka eller minska storleken på virtuella datorer, dela dynamiska arbetsbelastningar mellan maskiner och flytta arbetsbelastningar, appar och data från en virtuell dator till en annan. När en ISV däremot börjar växa ur en bare metal-server är det enda alternativet att lägga till mer hårdvara, vilket kräver tid och noggrann planering.

Exempel från den verkliga världen

Här på GO-Global stötte vi på den här situationen med en ny ISV-kund som använde Citrix för att leverera sina appar till finansinstitut från en offentlig molntjänst. På grund av programvarans natur förväntade sig denna ISV: s kunder nästan noll latens, vilket ledde till att Citrix rekommenderade bare metal-servrar för att leverera den förväntningen.

Efter att i åratal ha absorberat kostnaderna för att använda Citrix och bara metallservrar för att ge kunderna tillgång till molnet började ISV:s infrastrukturhanteringsteam att leta efter sätt att spara - och hittade GO-Global®.

Eftersom GO-Global är en applikationspublicerare, inte VDI som Citrix, kräver den ingen hypervisor, vilket eliminerar en av orsakerna till fördröjning på servernivå.

På en mer grundläggande nivå minskar GO-Global latensen tack vare det egenutvecklade och patenterade RapidX Protocol (RXP), som används för all datakommunikation mellan GO-Globals klient och värd. I stället för att överföra bitmappar över nätverket överför RXP enskilda ritkommandon, vilket ger snabbare överföring och bättre datakomprimering än andra lösningar. RXP:s visningsprotokoll är nästan helt asynkront, vilket innebär att värden och klienten sällan väntar på svar från sin motpart. I jämförelse överför Citrix tangenttryckningar till applikationsservern, som ritar om skärmen med varje tangenttryckning.

Till skillnad från Citrix duplicerar GO-Global dessutom inte infrastrukturkomponenter och skalbarhetsfunktioner för publika moln. Istället utnyttjar GO-Global en molntjänsts befintliga infrastruktur och skalbarhetsfunktioner för att leverera liknande funktionalitet med mindre komplexitet och mindre latens.

Den ovan nämnda ISV:n förbereder sig för närvarande för att lansera sin nya infrastruktur för applikationsleverans med hjälp av GO-Global och VM-servrar. Genom att byta till GO-Global sänkte de sina licenskostnader för applikationsleverans och kommer att kunna hålla latensen låg för att uppfylla kundernas förväntningar. Att gå från bare metal-servrar till VM-servrar har också minskat deras kostnader avsevärt.

Som svar på frågan "Är virtuella maskinservrar bättre än Bare Metal?" befinner sig de flesta ISV: er i valet mellan lägre kostnad med VM eller mindre latens med Bare Metal. Men för ISV som omfattas av detta inlägg, genom att flytta till GO-Global med VM, behövde de inte välja det ena eller det andra, de fick både överkomliga priser och en fantastisk användarupplevelse.

Om du är en Windows ISV som letar efter en lösning för applikationspublicering som utnyttjar dataresurser på ett mycket effektivt sätt, eliminerar onödig komplexitet och minskar latensen, överväg GO-Global. GO-Global är en lösning för applikationspublicering specialbyggd för att publicera Windows-applikationer från vilket moln som helst - enkelt, smidigt och kostnadseffektivt.

Om du vill veta mer om GO-Global kan du begära en demo här eller ladda ner en kostnadsfri 30-dagars testversion.