Beste praksis for server virtualisering og tips om hva du ikke skal gjøre

Virtualisering: Det bedrifter trenger å vite Virtualisering er den nye standarden i datasenteroppsett - dette er noen av grunnene til.

Server virtualisering har vokst i popularitet i et tiår, og noen mennesker tror nå det ikke bare er populær, men standard praksis. Men hva er de mest oppdaterte rådene for planlegging, gjennomføring og vedlikehold av et virtualiseringsprosjekt? Vi spurte to eksperter: David Barker, grunnlegger og teknisk direktør for 4D Data Centers i London, Storbritannia, og Peter Rittwage, partner og senior teknisk ingeniør ved IntelliSystems med kontorer i hele Georgia og South Carolina. ( Merk : Denne artikkelen om servervirtualisering er tilgjengelig som en gratis PDF-nedlasting.)

Koblentz: Beskriv den typiske størrelsen på kundekontoer.

Barker: Våre kunder varierer i størrelse fra små bedrifter med noen få ansatte til store bedrifter med over 1000 ansatte. Den generelle klientdemografien er en blanding av colocation, offentlig sky og private administrerte skyer. Mens samlokalisering representerer den største andelen av virksomheten vår innenfor kontekst av virtualisering, er de fleste av de mindre kundene bosatt på den offentlige skyplattformen som vi driver, mens de større virksomhetene har en tendens til å gå til private administrerte skyplattformer basert på Microsoft Hyper- V eller Dell Technologies VMware.

Rittwage: Den typiske størrelsen er omtrent 25 brukere, selv om vi har noen med 300+ og noen med bare noen få datamaskiner.

Koblentz: Hva er de største utfordringene når du virtualiserer servere i disse dager?

Datasenter må leses

  • 8 datasenterprognoser for 2020
  • 7 nettverksvarslinger for 2020: Automatisering, edge computing, Wi-Fi 6, mer
  • Beste praksis for server virtualisering og tips om hva du ikke skal gjøre
  • Kvanteberegning: Syv sannheter du trenger å vite

Barker: Den største utfordringen innen virtualisering er fortsatt deling av ressurser på tvers av infrastrukturen og applikasjonene dine. Uansett hvilken måte du ser på det, noen ting må prioriteres fremfor andre innen infrastrukturen.

Når du designer en virtualisert plattform er det en balansegang mellom de konkurrerende ressursene, og mest sannsynlig vil du fortsatt ha flaskehalser, men forhåpentligvis flyttet flaskehalsene dit de har minst innvirkning på applikasjonene dine. Du må vurdere nettverksforsyningen, både for ekstern WAN-trafikk og lagringstrafikk. Hvis du konsoliderer fra 100 fysiske maskiner hver med 1 Gb nettverksgrensesnitt som er ganske tungt brukt ned til 10 hypervisor noder, er det sannsynlig at du vil trenge å støte nettverket til minst 10 Gb for å takle den kondenserte trafikken til disse systemene kjører på et redusert antall NIC-er. Du kan ikke alltid forvente å plukke opp det eksisterende nettverket og slippe det til et nylig virtualisert miljø.

Lignende problemer eksisterer med lagringen. De fleste virtualiserte distribusjoner har fortsatt en sentral lagringsgruppe, og dette er ofte flaskehalsen for virtualisert systemdistribusjon. Selv om det å ha et lagringsnettverk på 10 Gb sannsynligvis vil gi deg nok rålagringsgjennomstrømning til matrisen, overses ofte I / O for rå disk fra de fysiske disker på grunn av at det er mindre problem når applikasjoner er spredt over en rekke fysiske servere. Dette betyr at platene ikke kan følge med antall lese / skriver som blir kastet på dem fra antall virtuelle maskiner, og ytelsen vil begynne å bli påvirket, spesielt i ting som databaseprogrammer, som er veldig avhengige av disk I / O .

Rittwage: Vi har fortsatt harddisksikkerhetsdongler som må kobles til USB, og noen ganger vil de ikke "rote gjennom" virtualiseringslaget i VM-gjesten. Vi har også noen ganger frem til en programvareleverandør som ikke "støtter" virtualisering og da ikke vil hjelpe med produktstøtten, men det er mer sjelden nå.

Koblentz: Hva er løsningene for å møte disse utfordringene når du planlegger et virtualiseringsprosjekt?

Barker: Selv om det er tekniske løsninger som kan bidra til å lindre noen av disse problemene, for eksempel SSD-hurtigbufring i lagringsenheten eller flytte til en gruppert lagringsplattform, har de imidlertid sine egne ulemper som må vurderes når de ser på dem for å avbøte utfordringene.

En av de beste måtene å avbøte problemene på er gjennom detaljert benchmarking av de nåværende fysiske serverne og planlegging av hvordan du skal virtualisere infrastrukturen. Før du tar beslutninger om maskinvare eller virtualisering, vil du vite hvor mye båndbredde hver server bruker for WAN-trafikk, gjeldende CPU / RAM-bruk under normale belastninger, så vel som toppbelastning og hvor mye disk I / O som foregår i hver server.

Ved å ha denne informasjonen tidlig, kan du ta beslutninger om innkjøp av maskinvare som i det minste vil levere den nåværende ytelsen og forhåpentligvis forbedre ytelsen gjennom nyere brikkesett, bedre minne, etc. Det lønner seg også å sikre at du riktig har kartlagt feilscenarier innenfor virtualiserte omgivelser, og at det er ledige hypervisorressurser tilgjengelig for å støtte i det minste svikt i en fysisk hypervisor-node, slik at de virtuelle maskinene som kjører har ressurser å migrere til uten å påvirke ytelsen til virtuelle maskiner og applikasjoner som allerede kjører på disse nodene.

Rittwage: Vanligvis er det en annen lisensieringsløsning tilgjengelig annet enn maskinvarenøkler, men du må vite om den før overføringen. Det er også programvare for å virtualisere USB-enheter.

Koblentz: Hva er de vanlige tingene folk gjør galt når de faktisk installerer / konfigurerer / vedlikeholder virtualiseringsprogramvare?

Barker: De vanlige tingene som går galt ved implementering av virtualisering kan oppsummeres som følger:

1. Feil balansering av nodens ressurser. Dette vil være noe som å sette inn 24-kjerne CPUer med bare 64 GB RAM. I et virtualisert miljø deles ikke RAM mellom virtuelle maskiner, og det er sannsynlig at du går tom for minne før du går tom for CPU (som vanligvis kan overtegnes mer enn opprinnelig planlagt, men en god tommelfingerregel er 1: 4 med en fysisk kjerne til 4 virtuelle kjerner).

2. Overensstemmende lagring til krav. Det er sannsynligvis viktigere å få riktig størrelse på platen enn CPU - lagringskostnadene vil veldig raskt eskalere sammenlignet med levering av CPU-kjerner. Husk at 10 Gb iSCSI er veldig raskt, og spinningsdisken er veldig langsom. Hvis du har mange høye transaksjonsdatabaser som du prøver å virtualisere, trenger du mye I / O-disk, noe som sannsynligvis betyr et stort utvalg av 15k disker.

3. For mange nettverk og for mange virtuelle brytere. Ganske ofte vil du se virtualiserte omgivelser med mange nettverk med vLAN-er for hver virtuelle gjestemaskin og administrasjons-IP-adressen til hypervisor-noden som finnes i hver vLAN. Dette er vanligvis ikke påkrevd (administrasjons-IP trenger ikke å være i de samme nettverkene som de virtuelle gjesteautomatene), og gir bare kompleksiteten til din ledelse av plattformen. Med mindre det er et veldig spesifikt krav for det nivået av nettverksseparasjon, må du holde nettverk til et minimum og bruke tilgangslister eller brannmurregler for å administrere virtuell maskinseparasjon i nettverket.

4. På lignende måte er det ganske ofte for mange virtuelle brytere . Hvis du trenger mye vLAN-er for miljøet, trenger du vanligvis ikke en separat virtuell bryter for hvert vLAN, og riktig design av vLAN-er / virtuelle brytere vil gi nok nettverksisolasjon for de fleste brukssaker.

Rittwage: Feilkonfigurasjon av vCPUer, RAM eller lagring er vanlig. De fleste problemene jeg må løse, er hvor en administrator har overforpliktet delt lagring. Du kan konfigurere store dynamiske stasjoner som ikke tar mye plass med det første, men hvis du lar dem vokse ut av kontroll, kan du gå tom for plass til alle gjestevm-er uten riktig planlegging. Du må også være veldig nøye med maskinvarekvalitet og stabilitet, slik at du ikke skaper et farlig eneste feilpunkt i nettverket ditt ved å konsolidere alle serverne dine. Ha alltid overflødig maskinvare.

Koblentz: Den beste måten å gjøre noe i 2008 eller 2013 er ikke nødvendigvis den beste måten å gjøre det i 2018. Hvilke trender fra virtualiseringens første dager har gått bort?

Barker: Grunnprinsippet om virtualisering har holdt seg det samme da VMware introduserte arbeidsstasjonsproduktet i 1999 og ESX i 2001. Vi har sett ytelsesøkninger og økte krav til lagring spesielt.

Sannsynligvis har det største skiftet vært områdene virtualiseringsadministrasjon, nettverk og migrering av virtuell maskin. I de første dagene hadde virtuelle maskiner en tendens til å være veldig statiske - du ville virtualisere en fysisk server og ha flere virtuelle maskiner som kjørte på den serveren som ikke beveget seg noe sted; og hvis den fysiske serveren mislyktes, vil alle virtuelle maskiner på den serveren også mislykkes. Innføringen av produkter som vMotion tok for seg dette og sørget for store klynger av hypervisorer der virtuelle maskiner lett kunne migrere mellom de fysiske serverne i tilfelle feil; Dette er tatt videre med VMwares vMotion og Hyper-Vs Replica som gjør at virtuelle maskiner kan replikeres i nær sanntid for å skille klynger på fysisk separate steder og for å løse risikoen for fullstendig klyngefeil.

Rittwage: Lagervirtualisering pleide å være mye tregere, så jeg ville se partisjoner eller harddiskpartisjoner tildelt til VMer. Dette er ikke tilfelle lenger eller nødvendig. Det er liten eller ingen straff for lokal virtuell lagring.

Koblentz: Hva bekymringer for fremtiden (nå) har vist seg å være grunnløs? Motsatt, hvilke viste seg å være undervurdert?

Barker: Jeg tror de største bekymringene, som begge viste seg å være ubegrunnet, har handlet om sikkerheten ved å bruke virtualisering og risikoen for å ha flere virtuelle maskiner som kjører innenfor den samme fysiske infrastrukturen. Selv om det nylig har blitt frigitt sårbarheter med Specter og Meltdown i CPU-arkitekturene som har reignert noen av disse bekymringene, er patcher blitt frigitt raskt, og utnyttelsen krevde root- eller administratortilgang til systemene selv (hvis en angriper har den informasjonen til privat sky, det er et langt større problem). Generelt har ressursisolering og virtuell maskinisolering blitt funnet å være helt sikre, og problemer oppstår generelt når disse er feilkonfigurert under utplasseringen. Et riktig designet virtuelt miljø med nettverksisolering og lagringsisolasjon (om nødvendig) er veldig sikkert.

Rittwage : Det har alltid vært snakk om malware / virus som kan angripe hypervisoren, men jeg har ikke sett en. Jeg mistenker at det er veldig vanskelig å programmere noe slikt.

Koblentz: I hvilken sammenheng bør du velge et mindre og / eller applikasjonsspesifikt virtualiseringsprodukt kontra å bruke de store guttene?

Barker: I 99 prosent av tilfellene vil virtualisering ved bruk av Hyper-V, VMware eller KVM / Xen være veien å gå, og beslutningen kommer ned til ferdighetene som er til stede for å administrere disse plattformene, samt en appetitt til å betale lisensieringskostnader (som skalerer fra KVM / Xen til Hyper-V og til VMware som den dyreste).

VMware har utmerkede styringsverktøy og en track record i å tilby maskinvarevirtualisering, men det kommer til en relativt heftig pris, spesielt hvis du setter sammen en stor distribusjon.

Hvis du først og fremst er et Windows-miljø og de fleste gjestemaskinene kjører Windows Server, kan et Hyper-V-miljø være å foretrekke. Lisensieringskostnadene kan være lavere hvis de distribueres riktig med Windows Data Center-utgaven eller bruker Windows Server Hyper-V Core, og administrasjonsgrensesnittene vil være kjent for brukerne.

KVM og Xen er begge utmerkede open source hypervisor plattformer, men de mangler styringsgrensesnitt. Selv om det er alternativer for å adressere dette som å gå for et OpenStack-miljø eller bruke en front-end som OnApp, legger disse til litt kompleksitet i designet hvis du ikke tidligere har hatt erfaring med å bruke disse verktøyene eller open source-programvaren generelt .

Rittwage: Jeg er ikke sikker på at jeg ville distribuere noe bortsett fra hovedårene for en hvilken som helst kritisk forretningsrolle, men for å øve og lære om produktet, eller for midlertidige katastrofesituasjoner, har jeg sett VirtualBox brukes.

Koblentz: I hvilken sammenheng bør du velge å ikke virtualisere en server?

Barker: De fleste arbeidsmengder kan virtualiseres, men hvis du har applikasjoner med spesielt tung CPU / RAM-bruk eller veldig tung disk I / O, kan det være bedre å ha dem som frittstående servere i et større virtualisert miljø. Du kan også få den fysiske serveren distribuert som en hypervisor, men med bare en eneste virtuell maskin som kjører på den, noe som kan være en god måte å sikre at de nødvendige ressursene er tilgjengelige for den applikasjonen, samtidig som du beholder fordelene ved administrasjon og migrering som en virtualisert miljø kan bringe.

På samme måte kan gamle applikasjoner være et problem å sette inn i et virtuelt miljø - ikke alle applikasjoner vil sitte glade med virtuelle CPUer eller virtuelle NIC-er, ettersom de er designet for å snakke med selve den fysiske maskinvaren. På grunn av løpetiden til virtualiseringsmarkedet blir disse applikasjonene langt færre og mindre bekymringsfulle etter hvert som tiden går.

Rittwage: Generelt, hvis du planlegger å bruke alle ressursene til en spesifikk høy-CPU- eller høy-IOP-funksjon, for eksempel en travel SQL-server, er det liten grunn til å virtualisere det. Virtualisering handler om å dele den underliggende maskinvaren med andre oppgaver.

Koblentz: Ser du frem til ytterligere fem år, hva tror du vil være nye utfordringer / bekymringer innen virtualisering som ennå ikke er klart for folk flest?

Barker: Stort sett mistenker jeg at dette vil være rundt et skifte til mer nettverksvirtuellisering på den fysiske nettverksmaskinvaren for å støtte arbeidsmengder og virtuelle maskiner som regelmessig migrerer mellom hypervisor-noder, og det vil bety å sikre at den fysiske nettverksinfrastrukturen som støtter din virtuelle infrastruktur er riktig designet for SDN, scripting og vxLAN.

Et annet område vil være den fortsatte økningen i bruk av containerisering innen de virtuelle maskinene - produkter som Docker og Kubernetes sørger for operativsystem og applikasjonsvirtualisering i selve den virtuelle maskinen. I tilfeller med riktig bruk gir dette enorme fordeler med hastigheten på distribusjon, miljøets konsistens og muligheten til å migrere arbeidsmengder umiddelbart mellom virtuelle maskiner.

Rittwage: Det er ganske modent på dette tidspunktet, så jeg er ikke sikker på hvilke nye utfordringer som dukker opp i løpet av de neste 5 årene.

Koblentz: Hvilke andre råd har du generelt for folk som har ansvar for å implementere og vedlikeholde server virtualiseringsprosjekter?

Barker: Plan for vekst. I designfasen, etter at du har standardisert det eksisterende miljøet, må du planlegge hvordan du utvider plattformen med nye hypervisorer eller ekstra lagring på en måte som minimerer påvirkningen på miljøet. Med virtualiserte miljøer er det en forventning om mye høyere tilgjengelighet, og du må kunne legge til et annet sett med disker eller ytterligere fire hypervisorer uten å måtte arkitektere hele plattformen fordi det bare var nok bryterporter til den første byggingen .

Sørg også for at du fremdeles har en god sikkerhetskopieringsstrategi. Selv om alt nå er virtualisert og sannsynligvis mye mer motstandsdyktig mot svikt i en fysisk komponent i infrastrukturen, går ting fortsatt galt. Å ha alt virtualisert åpner opp noen andre sikkerhetskopieringsstrategier med øyeblikksbilder av virtuelle maskiner og teknologier som backup-apparater, som kan gjøre å ta sikkerhetskopier, administrere sikkerhetskopiene og gjenopprette langt enklere enn når alt var på egne servere.

Rittwage: Plan for ytelse, vekst og redundans. Folk forventer å kunne bruke en dyr server i 5 år eller mer. Bruk en konsulent som med suksess har flyttet mange selskaper til virtualisering.

Datasenter Trender Nyhetsbrev

DevOps, virtualisering, hybridsky, lagring og driftseffektivitet er bare noen av datasentertemaene vi vil trekke frem. Leveres mandager og onsdager

Registrer deg i dag

© Copyright 2020 | mobilegn.com