Bedste praksis for server virtualisering og tip til, hvad man ikke skal gøre

Virtualisering: Hvad virksomheder har brug for at vide Virtualisering er den nye standard i opsætning af datacentre - dette er nogle af grundene til.

Server virtualisering har vokset i popularitet i et årti, og nogle mennesker mener nu, at det ikke kun er populær, men standard praksis. Men hvad er det mest opdaterede råd til planlægning, implementering og vedligeholdelse af et virtualiseringsprojekt? Vi spurgte to eksperter: David Barker, grundlægger og teknisk direktør for 4D Data Centers i London, UK, og Peter Rittwage, partner og senior teknisk ingeniør hos IntelliSystems med kontorer i hele Georgia og South Carolina. ( Bemærk : Denne artikel om server virtualisering er tilgængelig som en gratis PDF-download.)

Koblentz: Beskriv den typiske størrelse på dine kundekonti.

Barker: Vores kunder spænder i størrelse fra små virksomheder med et par ansatte op til store virksomheder med over 1.000 ansatte. Den samlede klientdemografiske er en blanding af colocation, offentlig sky og private administrerede skyer. Mens colocation repræsenterer den største andel af vores forretning inden for rammerne af virtualisering, er hovedparten af ​​de mindre klienter bosat på den offentlige skyplatform, som vi driver, mens de større virksomheder har en tendens til at gå til private administrerede skyplatforme baseret på Microsoft Hyper- V eller Dell Technologies VMware.

Rittwage: Den typiske størrelse er omkring 25 brugere, selvom vi har nogle med 300+ og nogle med kun et par computere.

Koblentz: Hvad er de største udfordringer, når vi virtualiserer servere i disse dage?

Datacenter skal læses

  • 8 datacenters forudsigelser for 2020
  • 7 netværksforudsigelser for 2020: Automation, edge computing, Wi-Fi 6 og mere
  • Bedste praksis for server virtualisering og tip til, hvad man ikke skal gøre
  • Kvanteberegning: Syv sandheder, du har brug for at vide

Barker: Den største udfordring inden for virtualisering er stadig delingen af ​​ressourcer på tværs af din infrastruktur og applikationer. Uanset hvilken måde du ser på det skal nogle ting prioriteres frem for andre inden for infrastrukturen.

Når du designer en virtualiseret platform er det en afbalancerende handling mellem de konkurrerende ressourcer, og sandsynligvis vil du stadig have flaskehalser, men forhåbentlig flyttes disse flaskehalser til det sted, hvor de har mindst indflydelse på dine applikationer. Du skal overveje netværksforsyningen, både for ekstern WAN-trafik såvel som lagertrafik. Hvis du konsoliderer fra 100 fysiske maskiner hver med 1 Gb netværksgrænseflade, der er forholdsvis kraftigt anvendt ned til 10 hypervisor-knudepunkter, er det sandsynligt, at du bliver nødt til at støde netværket til mindst 10 Gb for at klare den kondenserede trafik i disse systemer kører på et reduceret antal NIC'er. Du kan ikke altid forvente at hente det eksisterende netværk og slippe det ind i et nyligt virtualiseret miljø.

Lignende problemer findes med lageret. De fleste virtualiserede implementeringer leverer stadig en central lagringsgruppe, og dette er ofte flaskehalsen til virtualiseret systeminstallation. Selvom det at have et lagringsnetværk på 10 Gb sandsynligvis give dig nok rå lagringstrøm gennem arrayet, overses ofte den rå disk I / O, der er tilgængelig fra de fysiske diske, fordi det er mindre problem, når applikationer er spredt over et antal fysiske servere. Dette betyder, at diske ikke kan følge med antallet af læse / skriv, der kastes mod dem fra antallet af virtuelle maskiner, og ydeevnen vil blive påvirket, især i ting som databaseapplikationer, der er meget afhængige af disk I / O .

Rittwage: Vi løber stadig ind i hardwaresikkerhedsdongler, der skal tilsluttes til USB, og nogle gange vil de ikke "gennemgå" virtualiseringslaget i VM-gæsten. Vi løber også lejlighedsvis ind i en softwareleverandør, der ikke "understøtter" virtualisering og så ikke hjælper med produktstøtten, men det er mere sjældent nu.

Koblentz: Hvad er løsningen til at tackle disse udfordringer, når du planlægger et virtualiseringsprojekt?

Barker: Selvom der er tekniske løsninger, der kan hjælpe med at afhjælpe nogle af disse problemer, såsom SSD-cache i opbevaringsgruppen eller flytte til en samlet oplagringsplatform, har de deres egne ulemper, som det ville være nødvendigt at overveje, når man ser på dem for at mindske udfordringerne.

En af de bedste måder til at afbøde problemerne er gennem detaljeret benchmarking af de nuværende fysiske servere og planlægning af, hvordan du skal virtualisere infrastrukturen. Inden du træffer beslutninger om hardware eller virtualisering, vil du vide, hvor meget båndbredde hver server bruger til WAN-trafik, nuværende CPU / RAM-anvendelse under normale belastninger, samt spidsbelastninger og mængden af ​​disk I / O, der foregår inden for hver server.

Ved at have disse oplysninger tidligt, kan du træffe beslutninger om hardwarekøb, som i det mindste vil levere den aktuelle ydelse og forhåbentlig forbedre ydelsen gennem nyere chipsæt, bedre hukommelse osv. Det lønner sig også at sikre, at du korrekt har kortlagt fejlscenarier inden for virtualiserede omgivelser, og at der er ledige hypervisorressourcer til rådighed til at understøtte i det mindste fiaskoen i en fysisk hypervisorknudepunkt, så de virtuelle maskiner, der kører, har ressourcer at migrere til uden at påvirke ydelsen af ​​virtuelle maskiner og applikationer, der allerede kører på disse noder.

Rittwage: Normalt er der en alternativ licensløsning tilgængelig bortset fra hardware nøgler, men du er nødt til at vide det før migreringen. Der er også software til at virtualisere USB-enheder.

Koblentz: Hvad er de almindelige ting, som folk gør forkert, når de rent faktisk installerer / konfigurerer / vedligeholder virtualiseringssoftware?

Barker: De sædvanlige ting, der går galt ved implementering af virtualisering, kunne opsummeres som følger:

1. Forkert afbalancering af nodens ressourcer. Dette ville være noget som at sætte 24 core CPU'er i med kun 64 GB RAM. I et virtualiseret miljø deles RAM ikke mellem virtuelle maskiner, og det er sandsynligt, at du løber tør for hukommelsen, før du løber tør for CPU (hvilket normalt kan overtegnes mere end oprindeligt planlagt, men en god tommelfingerregel er 1: 4 med 1 fysisk kerne til 4 virtuelle kerner).

2. Uoverensstemmende lagring efter behov. Det er sandsynligvis mere vigtigt at få en diskstørrelse korrekt end CPU - lagringsomkostninger eskalerer meget hurtigt sammenlignet med levering af CPU-kerner. Husk, at 10 Gb iSCSI er meget hurtig, og spindisken er faktisk meget langsom. Hvis du har en masse høje transaktionsdatabaser, som du prøver at virtualisere, har du brug for en masse disk I / O, hvilket sandsynligvis betyder en stor række 15 k diske.

3. For mange netværk og for mange virtuelle switches. Ganske ofte vil du se virtualiserede miljøer med en masse netværk med vLAN'er for hver gæstervirtuel maskine og administrations-IP-adressen på hypervisorknuden, der findes i hver vLAN. Dette er normalt ikke påkrævet (administrations-IP behøver ikke at være i de samme netværk som de virtuelle gæsteautomater) og øger kun kompleksiteten i din styring af platformen. Medmindre der er et meget specifikt krav til dette niveau af netværksseparation, skal du holde netværk til et minimum og bruge adgangslister eller firewall-regler til at administrere virtuel maskinseparation på netværket.

4. På lignende måde er der ganske ofte for mange virtuelle switches . Hvis du har brug for en masse vLAN'er til dit miljø, behøver du normalt ikke en separat virtuel switch til hver vLAN, og korrekt design af vLANs / virtual switches giver tilstrækkelig netværksisolering til de fleste anvendelsessager.

Rittwage: Miskonfiguration af vCPU'er, RAM eller opbevaring er almindeligt. De fleste problemer, jeg skal løse, er hvor en administrator har overforpligtet delt lagerplads. Du kan konfigurere store dynamiske drev, der ikke tager meget plads i starten, men hvis du lader dem vokse ud af kontrol, kan du løbe tør for plads til alle dine gæst-VM'er uden ordentlig planlægning. Du skal også være meget opmærksom på hardwarekvalitet og stabilitet, så du ikke skaber et farligt enkelt mislykkelsespunkt i dit netværk ved at konsolidere alle dine servere. Har altid overflødig hardware.

Koblentz: Den bedste måde at gøre noget i 2008 eller 2013 er ikke nødvendigvis den bedste måde at gøre det på i 2018. Hvilke tendenser fra virtualiseringens tidlige dage er forsvundet?

Barker: Det grundlæggende princip om virtualisering har forblevet det samme, da VMware introducerede sit arbejdsstationsprodukt i 1999 og ESX i 2001. Vi har set præstationsstigninger og øgede krav til lagring især.

Det største skift har sandsynligvis været inden for virtualiseringsstyring, netværk og migrering af virtuel maskine. I de tidlige dage havde virtuelle maskiner en tendens til at være meget statiske - du ville virtualisere en fysisk server og have flere virtuelle maskiner, der kører inden for denne server, der ikke flyttede nogen steder; og hvis den fysiske server mislykkedes, ville alle virtuelle maskiner på denne server også mislykkes. Introduktionen af ​​produkter som vMotion adresserede dette og sørgede for store klynger af hypervisorer, hvor virtuelle maskiner let kunne migrere mellem de fysiske servere i tilfælde af fejl; dette er taget videre med VMwares vMotion- og Hyper-Vs-replika, der tillader, at virtuelle maskiner replikeres i næsten realtid for at adskille klynger på fysisk separate steder og for at tackle risikoen for en komplet klyngefejl.

Rittwage: Opbevaring virtualisering plejede at være meget langsommere, så jeg ville se rå drevpartitioner eller drev tildelt til VM'er. Dette er ikke tilfældet mere eller nødvendigt. Der er lille eller ingen straf for lokal virtuel opbevaring.

Koblentz: Hvilke bekymringer om dens fremtid (nu) har vist sig at være ubegrundede? Omvendt, hvilke viste sig at være undervurderet?

Barker: Jeg tror, ​​at de største bekymringer, som begge viste sig at være ubegrundede, har været omkring sikkerheden ved at bruge virtualisering og risikoen for, at flere virtuelle maskiner kører inden for den samme fysiske infrastruktur. Selvom der for nylig er blevet frigivet sårbarheder med Specter og Meltdown inden for CPU-arkitekturerne, der har genigneret nogle af disse bekymringer, er patches blevet frigivet hurtigt, og udnyttelsen krævede root- eller administratoradgang til selve systemerne (hvis en hacker har disse oplysninger til din privat sky, det er et langt større problem). Generelt har ressourceisolering og virtuel maskineisolering vist sig at være fuldstændig sikker, og der opstår generelt problemer, når disse misforstås under installationen. Et korrekt designet virtuelt miljø med netværksisolering og lagringsisolering (hvis nødvendigt) er meget sikkert.

Rittwage : Der har altid været tale om malware / vira, der kunne angribe hypervisoren, men jeg har ikke set en. Jeg formoder, at det er meget vanskeligt at programmere sådan en ting.

Koblentz: I hvilken sammenhæng skal du vælge et mindre og / eller applikationsspecifikt virtualiseringsprodukt kontra at bruge de store drenge?

Barker: I 99 procent af brugstilfælde vil virtualisering ved hjælp af Hyper-V, VMware eller KVM / Xen være vejen at gå, og beslutningen kommer ned på de færdigheder, der findes til at administrere disse platforme, samt en appetit til at betale licensomkostninger (som skalerer fra KVM / Xen til Hyper-V og til VMware som den dyreste).

VMware har fremragende styringsværktøjer og en track record i leveringen af ​​hardware virtualisering, men det kommer til en relativt heftig pris, især hvis du samler en stor installation.

Hvis du primært er et Windows-miljø, og de fleste af gæstemaskinerne kører Windows Server, kan et Hyper-V-miljø muligvis være at foretrække. Licensomkostningerne kan være lavere, hvis de implementeres korrekt med Windows Data Center-udgave eller ved hjælp af Windows Server Hyper-V Core, og administrationsgrænsefladerne er kendte for brugerne.

KVM og Xen er begge fremragende open source-hypervisorplatforme, men de mangler styringsgrænseflader. Selvom der er muligheder for at tackle dette, såsom at gå efter et OpenStack-miljø eller bruge en front-end som OnApp, tilføjer disse en vis kompleksitet til designet, hvis du ikke tidligere har oplevet at bruge disse værktøjer eller open source-software generelt .

Rittwage: Jeg er ikke sikker på, at jeg ville indsætte noget bortset fra hovedfagene til enhver kritisk forretningsrolle, men til praksis og læring om produktet eller til midlertidige katastrofesituationer, har jeg set VirtualBox brugt.

Koblentz: I hvilken sammenhæng skal du vælge ikke at virtualisere en server?

Barker: De fleste arbejdsbelastninger kan virtualiseres, men hvis du har applikationer med særlig tung CPU / RAM-brug eller meget tung disk I / O, kan det være bedre at have dem som fristående servere i et bredere virtualiseret miljø. Du kan også få den fysiske server implementeret som en hypervisor, men med kun en enkelt virtuel maskine, der kører på den, hvilket kan være en god måde at sikre, at de krævede ressourcer er tilgængelige for den applikation, samtidig med at fordelene ved styring og migration, som en virtualiseret miljø kan bringe.

Ligeledes kan ældre applikationer være et problem at sætte i et virtuelt miljø - ikke alle applikationer sidder lykkeligt med virtuelle CPU'er eller virtuelle NIC'er, da de er designet til at tale med selve den fysiske hardware. På grund af modenheden på virtualiseringsmarkedet bliver disse applikationer langt færre og mindre bekymrede, når tiden går.

Rittwage: Generelt, hvis du planlægger at bruge alle ressourcerne til en bestemt høj CPU eller høj IOP-funktion, såsom en optaget SQL-server, er der ingen grund til at virtualisere det. Virtualisering handler om at dele den underliggende hardware med andre opgaver.

Koblentz: Ser du frem til yderligere fem år, hvad tror du vil være nye udfordringer / bekymringer inden for virtualisering, som endnu ikke er klar for de fleste?

Barker: Stort set har jeg mistanke om, at dette vil være omkring et skift til mere netværksvirtualisering på den fysiske netværkshardware for at understøtte arbejdsbelastninger og virtuelle maskiner, der regelmæssigt migrerer mellem hypervisor-noder, og det vil betyde at sikre, at den fysiske netværksinfrastruktur, der understøtter din virtuelle infrastruktur er korrekt designet til SDN, scripting og vxLAN.

Et andet område vil være den fortsatte stigning i brugen af ​​containerisering inden for de virtuelle maskiner - produkter som Docker og Kubernetes sørger for OS og applikations virtualisering inden for selve den virtuelle maskine. I tilfælde af korrekt brug medfører dette enorme fordele i hastigheden af ​​implementering, miljøets konsistens og evnen til at migrere applikationsarbejdsmængder øjeblikkeligt mellem virtuelle maskiner.

Rittwage: Det er temmelig modent på dette tidspunkt, så jeg er ikke sikker på, hvilke nye udfordringer der vil dukke op i de næste 5 år.

Koblentz: Hvilket andet råd har du generelt til folk, der har ansvaret for at implementere og vedligeholde server virtualiseringsprojekter?

Barker: Plan for vækst. I designfasen skal du sørge for at planlægge, hvordan du udvider platformen med nye hypervisorer eller yderligere lagring på en måde, der minimerer påvirkningen på miljøet, efter at du har fået en benchmarking af det eksisterende miljø. I virtualiserede miljøer er der en forventning om meget højere tilgængelighed, og du skal være i stand til at tilføje et andet sæt diske eller yderligere fire hypervisorer uden at skulle omarkitektere hele platformen, fordi der kun var nok switchporte til den oprindelige bygning .

Sørg også for, at du stadig har en god backup-strategi. Selvom alt nu er virtualiseret og sandsynligvis meget mere modstandsdygtigt over for fiaskoen i en fysisk komponent i infrastrukturen, går tingene stadig galt. At have alt virtualiseret åbner nogle andre sikkerhedskopieringsstrategier med snapshots af virtuelle maskiner og teknologier såsom backup-apparater, som kan gøre det at tage sikkerhedskopier, styre sikkerhedskopierne og gendanne langt lettere, end da alt var på sine egne individuelle servere.

Rittwage: Plan for ydeevne, vækst og redundans. Folk forventer at kunne bruge en dyr server i 5 år eller mere. Brug en konsulent, der med succes har flyttet mange virksomheder til virtualisering.

Datacenter Trends Nyhedsbrev

DevOps, virtualisering, hybrid sky, opbevaring og driftseffektivitet er blot nogle af de datacenteremner, vi vil fremhæve. Leveres mandage og onsdage

Tilmeld dig i dag

© Copyright 2021 | mobilegn.com