Palvelimen virtualisoinnin parhaat käytännöt ja vinkit siihen, mitä ei tehdä

Virtualisointi: Yritysten on tiedettävä, että virtualisointi on uusi standardi datakeskuksen asennuksessa - nämä ovat muutamia syitä.

Palvelimen virtualisoinnin suosio on kasvanut vuosikymmenen ajan, ja jotkut ihmiset uskovat nyt, että se ei ole vain suosittu, vaan vakiokäytäntö. Mutta mikä on päivitetyin neuvo virtualisointiprojektin suunnittelulle, toteuttamiselle ja ylläpitämiselle? Kysyimme kahta asiantuntijaa: David Barker, Lontoossa, Isossa-Britanniassa sijaitsevan 4D Data Center -yrityksen perustaja ja tekninen johtaja, sekä Peter Rittwage, kumppani ja vanhempi tekninen insinööri IntelliSystemsillä, jolla on toimistot kaikkialla Georgiassa ja Etelä-Carolinassa. ( Huomaa : Tämä artikkeli palvelimen virtualisoinnista on saatavana ilmaisena PDF-latauksena.)

Koblentz: Kuvaile asiakastilien tyypillinen koko.

Barker: Asiakkaidemme koko vaihtelee pienistä yrityksistä, joissa on muutama työntekijä, suuriin yrityksiin, joissa on yli 1000 työntekijää. Asiakkaiden kokonaisväestötiedot ovat sekoitus sijoittumisesta, julkisesta pilvestä ja yksityisistä hallituista pilvistä. Vaikka sijoittaminen edustaa suurinta osaa liiketoiminnastamme virtualisoinnin puitteissa, suurin osa pienemmistä asiakkaista asuu käyttämämme julkisella pilvialustalla, kun taas suuremmilla yrityksillä on taipumus mennä yksityisiin hallinnoituihin pilvialustoihin, jotka perustuvat Microsoft Hyper- V tai Dell Technologies VMware.

Rittwage: Tyypillinen koko on noin 25 käyttäjää, vaikka meillä on jo yli 300 ja toisilla vain muutama tietokone.

Koblentz: Mitkä ovat suurimpia haasteita virtualisoidessaan palvelimia nykyään?

Tietokeskuksen lukemat

  • 8 tietokeskuksen ennustetta vuodelle 2020
  • 7 verkkonäköennustetta vuodelle 2020: automaatio, reunalaskenta, Wi-Fi 6 ja enemmän
  • Palvelimen virtualisoinnin parhaat käytännöt ja vinkit siihen, mitä ei tehdä
  • Kvanttilaskenta: Seitsemän totuutta, jotka sinun on tiedettävä

Barker: Suurin haaste virtualisoinnissa on edelleen resurssien jakaminen infrastruktuurin ja sovellusten välillä. Kumpaankin tapaan katsot, jotkut asiat on asetettava etusijalle muihin infrastruktuurin sisällä.

Suunniteltaessa virtualisoitua alustaa se on tasapainottava kilpailevien resurssien välillä. Todennäköisesti sinulla on edelleen pullonkauloja, mutta toivottavasti siirrät nämä pullonkaulat sinne, missä ne vaikuttavat sovelluksiin vähiten. Sinun on harkittava verkon tarjoamista sekä ulkoiselle WAN-liikenteelle että tallennusliikenteelle. Jos konsolidoit 100: sta fyysisestä koneesta, joissa jokaisessa on 1 Gb: n verkkoliitäntä ja joita käytetään melko voimakkaasti jopa 10 hypervisor-solmua, on todennäköistä, että joudut siirtämään verkon vähintään 10 Gb: n verran selviytymäänksesi näiden järjestelmien tiivistyneestä liikenteestä. käynnissä pienemmällä määrällä NIC-kortteja. Et voi aina odottaa hakevansa olemassa olevaa verkkoa ja pudottavan sen vasta virtualisoituun ympäristöön.

Samanlaisia ​​ongelmia esiintyy myös tallennuksessa. Useimmat virtualisoidut käyttöönotot tarjoavat edelleen keskitetyn tallennusmatriisin, ja tämä on melko usein pullonkaula virtualisoidun järjestelmän käyttöönotolle. Vaikka 10 Gt: n tallennusverkko antaa todennäköisesti riittävästi raa'an tallennuskapasiteetin joukkoon, fyysisiltä levyiltä saatavissa oleva raa'an levyn I / O-asemat jätetään usein huomiotta, koska se on vähemmän ongelma, kun sovellukset jakautuvat useille fyysisille levyille palvelimia. Tämä tarkoittaa, että levyt eivät voi pysyä niiden lukumäärien / kirjoitusten määrän suhteen, jotka heitetään heille virtuaalikoneiden lukumäärästä, ja suorituskyky alkaa vaikuttaa, etenkin tietokantasovelluksissa, jotka riippuvat suuresti levyn I / O-toiminnoista. .

Rittwage: Jatkamme edelleen laitteistoturvallisuusdongit, jotka on liitettävä USB: hen, ja toisinaan ne eivät "pistä" virtualisointikerroksen läpi VM-vieraana. Olemme myös silloin tällöin joutumassa ohjelmistovalmistajaan, joka ei "tue" virtualisointia eikä sitten auta tuotetuessa, mutta se on nyt harvinaisempaa.

Koblentz: Mitkä ovat ratkaisut näihin haasteisiin vastaamiseksi, kun suunnittelet virtualisointiprojektia?

Barker: Vaikka on olemassa teknisiä ratkaisuja, jotka voivat auttaa lievittämään joitain näistä ongelmista, kuten SSD-välimuisti tallennusmatriisin sisällä tai siirtyminen klusteroituun tallennusalustaan, niillä on kuitenkin omat haitat, jotka olisi otettava huomioon tarkasteltaessa niitä lieventää haasteita.

Yksi parhaimmista tavoista vähentää ongelmia on nykyisten fyysisten palvelimien yksityiskohtainen esikuva-analyysi ja suunnittelu siitä, miten aiot virtualisoida infrastruktuurin. Ennen laitteisto- tai virtualisointipäätösten tekemistä haluat tietää, kuinka paljon kaistaleveyttä kukin palvelin käyttää WAN-liikenteeseen, prosessorin nykyistä käyttöä normaalissa kuormituksessa sekä huippukuormituksia ja kunkin laitteen sisällä olevan levyn I / O-määrän määrää palvelimelle.

Jos sinulla on nämä tiedot jo varhaisessa vaiheessa, voit tehdä päätöksiä laitteistohankinnoista, jotka tuottavat ainakin nykyisen suorituskyvyn ja toivottavasti parantavat suorituskykyä uudempien piirisarjojen, paremman muistin jne. Avulla. Lisäksi on tärkeää varmistaa, että olet kartoittanut virheelliset skenaariot oikein virtualisoituun ympäristöön ja että käytettävissä on ylimääräisiä hypervisor-resursseja ainakin fyysisen hypervisor-solmun vikaantumisen tukemiseksi, jotta käynnissä olevilla virtuaalikoneilla on resursseja siirtyäkseen vaikuttamatta liikaa näillä solmuilla jo käynnissä olevien virtuaalikoneiden ja sovellusten suorituskykyyn.

Rittwage: Yleensä on saatavana vaihtoehtoinen lisensointiratkaisu kuin laitteistoavaimet, mutta sinun on tiedettävä se ennen siirtymistä. USB-laitteiden virtualisoimiseksi on myös ohjelmisto.

Koblentz: Mitkä ovat yleiset asiat, joita ihmiset tekevät väärin, kun he todella asentavat / määrittävät / ylläpitävät virtualisointiohjelmistoja?

Barker: Tavalliset asiat, jotka menevät pieleen virtualisoinnin käyttöönoton yhteydessä, voidaan tiivistää seuraavasti:

1. Solmuresurssien virheellinen tasapainotus. Tämä olisi jotain kuin 24 ytimen suorittimen asentaminen vain 64 Gt RAM-muistilla. Virtualisoidussa ympäristössä RAM-muistia ei jaeta virtuaalikoneiden kesken, ja muistisi loppuu todennäköisesti ennen suorittimen loppumista (jota voi yleensä tilata enemmän kuin alun perin suunniteltiin, mutta hyvä nyrkkisääntö on 1: 4). 1 fyysisestä ytimestä 4 virtuaaliseen ytimeen).

2. Varasto ei vastaa vaatimuksia. On todennäköisesti tärkeämpää saada levyn koko oikein kuin CPU - tallennuskustannukset kasvavat erittäin nopeasti verrattuna CPU-ytimien tarjoamiseen. Muista, että 10 Gt iSCSI on erittäin nopea ja kehruulevy on todella hidasta. Jos sinulla on paljon korkeita tapahtumatietokantoja, joita yrität virtualisoida, tarvitset paljon levyn I / O-resursseja, mikä tarkoittaa todennäköisesti suurta joukkoa 15 kt levyjä.

3. Liian monta verkkoa ja liian monta virtuaalista kytkintä. Melko usein näet virtualisoituja ympäristöjä, joissa on paljon verkkoja, joissa on vLAN-verkot jokaiselle vieraana virtuaalikoneelle ja jokaisessa vLAN: ssa olevan hypervisor-solmun hallinta-IP-osoite. Tätä ei yleensä tarvita (hallinta-IP: n ei tarvitse olla samoissa verkoissa kuin vieraiden virtuaalikoneet), ja se lisää vain alustan hallinnan monimutkaisuutta. Jollei verkon erotustasolle ole asetettu erityisiä vaatimuksia, pidä verkot minimissä ja käytä pääsyluetteloita tai palomuurisääntöjä hallitsemaan virtuaalikoneiden erotusta verkossa.

4. Samalla tavoin virtuaalisia kytkimiä on melko usein liian paljon . Jos tarvitset paljon vLAN-verkkoja ympäristöllesi, et yleensä tarvitse erillistä virtuaalista kytkintä jokaiselle vLAN: lle, ja vLAN: ien / virtuaalisten kytkinten asianmukainen suunnittelu tarjoaa riittävän verkon eristyksen useimpiin käyttötapauksiin.

Rittwage: vCPU: ien, RAM: n tai tallennustilan väärät määritykset ovat yleisiä. Suurin osa ongelmia, jotka minun on korjattava, on järjestelmänvalvojan suorittama jaettu tallennustila. Voit määrittää suuret dynaamiset asemat, jotka eivät vie aluksi paljon tilaa, mutta jos annat niiden kasvaa hallitsematta, voit tyhjentää tilaa kaikille vieraskäyttöön ilman asianmukaista suunnittelua. Laitteiden laatuun ja vakauteen on myös kiinnitettävä erittäin tarkkaa huomiota, jotta et muodosta vaarallista yksittäistä vikakohtaa verkkoon yhdistämällä kaikki palvelimet. Aina on tarpeeton laitteisto.

Koblentz: Paras tapa tehdä jotain vuonna 2008 tai 2013 ei välttämättä ole paras tapa tehdä se vuonna 2018. Mitkä trendit virtualisoinnin alkuaikoista ovat kadonneet?

Barker: Virtualisoinnin perusperiaate on pysynyt samana siitä ajasta, jolloin VMware esitteli työasematuotteensa vuonna 1999 ja ESX: n vuonna 2001. Olemme nähneet suorituskyvyn nousun ja lisääntyneen vaatimuksen etenkin tallennustilaa varten.

Todennäköisesti suurin muutos on tapahtunut virtualisoinnin hallinnan, verkkojen ja virtuaalikoneiden siirtymisen aloilla. Alkuaikoina virtuaalikoneet olivat yleensä erittäin staattisia - virtualisoit fyysisen palvelimen ja sillä palvelimella on käynnissä useita virtuaalikoneita, jotka eivät siirry mihinkään; ja jos fyysinen palvelin epäonnistui, myös kaikki kyseisen palvelimen virtuaalikoneet epäonnistuvat. Tuotteiden, kuten vMotion, käyttöönotto ratkaisi tämän ja tarjosi suuria hypervisoreiden klustereita, joissa virtuaalikoneet voisivat helposti siirtyä fyysisten palvelimien välillä vian sattuessa; Tätä on jatkettu VMwaren vMotion- ja Hyper-Vs-kopioilla, joiden avulla virtuaalikoneita voidaan replikoida melkein reaaliajassa erotella klusterit fyysisesti erillisissä paikoissa ja puuttua kokonaisen klusterivirheen riskiin.

Rittwage: Varastointi virtualisointi oli aiemmin paljon hitaampaa, joten näkisin raaka-asemaosioita tai asemia, jotka oli allokoitu VM: ille. Näin ei enää ole tai sitä ei tarvita. Paikallisesta virtuaalisesta tallennuksesta on vähän tai ei lainkaan rangaistusta.

Koblentz: Mitkä sen tulevaisuuden huolet (nyt) ovat osoittautuneet perusteettomiksi? Toisaalta mitkä osoittautuivat aliarvioituiksi?

Barker: Mielestäni suurimpia huolenaiheita, jotka molemmat osoittautuivat perusteettomiksi, ovat olleet virtualisoinnin käytön turvallisuus ja riskit siitä, että useita fyysisiä infrastruktuureja voi käyttää useita virtuaalikoneita. Vaikka CPU-arkkitehtuureissa, jotka ovat herättäneet osan näistä huolenaiheista, on äskettäin julkaistu Specter- ja Meltdown-haavoittuvuuksia, korjaustiedostot on vapautettu nopeasti ja hyödynnettävä vaadittava pääkäyttäjän tai järjestelmänvalvojan pääsy järjestelmiin itse (jos hyökkääjällä on nämä tiedot sinun yksityinen pilvi, se on paljon suurempi ongelma). Resurssien ja virtuaalikoneiden eristämisen on yleisesti havaittu olevan täysin turvallinen, ja ongelmia syntyy yleensä, kun ne on määritetty väärin käyttöönoton aikana. Oikein suunniteltu virtuaaliympäristö verkon eristämisellä ja varastoinnin eristämisellä (tarvittaessa) on erittäin turvallinen.

Rittwage : Aina on puhuttu haittaohjelmista / viruksista, jotka voisivat hyökätä hypervisoriin, mutta en ole nähnyt sellaista. Epäilen, että on erittäin vaikea ohjelmoida sellainen asia.

Koblentz: Missä yhteydessä sinun tulisi valita alaikäinen ja / tai sovelluskohtainen virtualisointituote verrattuna isojen poikien käyttämiseen?

Barker: 99 prosentilla käyttötapauksista Hyper-V: n, VMware: n tai KVM / Xenin avulla tapahtuva virtualisointi tulee olemaan tietä, ja päätös johtuu nykyisistä taitoista hallita näitä alustoja sekä halukkuuteen maksaa lisensointikustannukset (jotka vaihtelevat KVM / Xen: stä Hyper-V: hen ja VMware: iin kalleimpana).

VMwarella on erinomaiset hallintatyökalut ja edistystä laitteiston virtualisoinnin tarjoamisessa, mutta se tulee suhteellisen kovaan hintaan, varsinkin jos sijoitat suuren käyttöönoton.

Jos olet pääasiassa Windows-ympäristö ja useimmat vieraskoneet käyttävät Windows Serveriä, Hyper-V-ympäristö voi olla parempi. Lisensointikustannukset voivat olla alhaisemmat, jos ne otetaan käyttöön oikein Windows Data Center -version kanssa tai käyttämällä Windows Server Hyper-V Core -sovellusta, ja hallintarajapinnat ovat käyttäjille tuttuja.

KVM ja Xen ovat molemmat erinomaisia ​​avoimen lähdekoodin hypervisor-alustoja, mutta niiltä puuttuu hallintarajapinnat. Vaikka tähän ratkaisemiseksi on vaihtoehtoja, kuten OpenStack-ympäristön käyttäminen tai käyttöliittymän, kuten OnApp, käyttäminen, nämä lisäävät suunnitteluun jonkin verran monimutkaisuutta, jos sinulla ei ole aikaisempaa kokemusta näiden työkalujen tai avoimen lähdekoodin ohjelmistojen käytöstä yleensä .

Rittwage: En ole varma, etten lähettäisi mitään muuta kuin pääaineita mihinkään kriittiseen liiketoimintaan liittyvään rooliin, mutta olen nähnyt VirtualBoxin käytöstä tuotteen käytännössä ja oppimisessa tai väliaikaisissa hätätilanteiden palauttamistilanteissa.

Koblentz: Missä yhteydessä sinun ei pitäisi virtualisoida palvelinta?

Barker: Suurin osa työmääristä voidaan virtualisoida, mutta jos sinulla on sovelluksia, joissa CPU / RAM-käyttö on erityisen raskaata tai erittäin raskas levyn I / O, niin voi olla parempi, että ne ovat itsenäisiä palvelimia laajemmassa virtualisoidussa ympäristössä. Voit myös asettaa fyysisen palvelimen käyttöön hypervisorina, mutta vain yhdellä virtuaalikoneella on käynnissä, mikä voi olla hyvä tapa varmistaa, että sovellukselle on saatavana tarvittavat resurssit säilyttäen samalla virtualisoidun hallinnoinnin ja siirron edut. ympäristö voi tuoda.

Samoin vanhat sovellukset voivat olla ongelma virtuaaliympäristöön asettamisessa - kaikki sovellukset eivät istu onnellisesti virtuaalisten CPU: n tai virtuaalisten NIC: ien kanssa, koska ne on suunniteltu puhumaan itse fyysiseen laitteistoon. Virtualisointimarkkinoiden kypsyyden vuoksi nämä sovellukset ovat vähentyneet ja vähemmän huolissaan ajan myötä.

Rittwage: Yleensä, jos aiot käyttää kaikkia resursseja tiettyyn korkeaan suorittimeen tai korkeaan IOP-toimintoon, kuten varattuun SQL-palvelimeen, ei ole mitään syytä virtualisoida sitä. Virtualisoinnin tarkoituksena on jakaa taustalla oleva laitteisto muiden tehtävien kanssa.

Koblentz: Odotatko vielä viittä vuotta eteenpäin uusia virtualisoinnin haasteita / huolenaiheita, jotka eivät ole vielä selviä useimmille ihmisille?

Barker: Useimmiten epäilen, että kyseessä on siirtyminen enemmän fyysisen verkkolaitteiston verkkovirtualisointiin, jotta voidaan tukea työkuormitusta ja virtuaalikoneita, jotka siirtyvät säännöllisesti hypervisor-solmujen välillä, ja se tarkoittaa, että fyysisen verkkoinfrastruktuurin, joka tukee virtuaalista verkkoasi infrastruktuuri on suunniteltu oikein SDN-, skripti- ja vxLAN-verkkoja varten.

Toinen alue on jatkuva konteineroinnin käytön lisääntyminen virtuaalikoneissa - Dockerin ja Kubernetesin kaltaiset tuotteet tarjoavat käyttöjärjestelmien ja sovellusten virtualisoinnin itse virtuaalikoneessa. Oikeissa käyttötapauksissa tämä tuo valtavia etuja käyttöönoton nopeuteen, ympäristön johdonmukaisuuteen ja kykyyn siirtää sovellusten työmäärät heti virtuaalikoneiden välillä.

Rittwage: Se on aika kypsä tässä vaiheessa, joten en ole varma mitä uusia haasteita ilmestyy seuraavan viiden vuoden aikana.

Koblentz: Mitä muita neuvoja sinulla on yleensä palvelimien virtualisointiprojektien toteuttamisesta ja ylläpidosta vastaaville ihmisille?

Barker: Kasvusuunnitelma. Suunnitteluvaiheen aikana, kun olet tehnyt nykyisen ympäristön vertailuanalyysin, muista suunnitella, kuinka voit laajentaa alustaa uusilla hypervisioilla tai lisävarastoilla tavalla, joka minimoi ympäristövaikutukset. Virtualisoituissa ympäristöissä on odotettavissa huomattavasti korkeampi käytettävyys, ja sinun on voitava lisätä toiseen levyjoukkoon tai neljään muuhun hypervisioon joutumatta suunnittelemaan koko alustaa uudelleen, koska ensimmäiseen rakennukseen oli vain tarpeeksi kytkinportteja. .

Varmista myös, että sinulla on edelleen hyvä varmuuskopiointistrategia. Vaikka kaikki on nyt virtualisoitu ja todennäköisesti paljon kestävämpi infrastruktuurin fyysisen komponentin vikaantumisen suhteen, asiat menevät silti pieleen. Kaiken virtualisoituminen avaa joitain muita varmuuskopiointistrategioita virtuaalikoneiden ja tekniikoiden, kuten varmuuskopiolaitteiden, kanssa, jotka voivat tehdä varmuuskopioiden ottamisesta, varmuuskopioiden hallinnasta ja palauttamisesta paljon helpompaa kuin silloin, kun kaikki oli omilla erillisillä palvelimillaan.

Rittwage: Suorituskyvyn, kasvun ja irtisanomissuunnitelma. Ihmiset odottavat pystyvänsä käyttämään kallista palvelinta vähintään viiden vuoden ajan. Käytä konsulttia, joka on onnistuneesti siirtänyt monet yritykset virtualisointiin.

Datakeskuksen trendit -uutiskirje

DevOps, virtualisointi, hybridi pilvi, tallennus ja toiminnan tehokkuus ovat vain joitain tietokeskuksen aiheista, joita korostamme. Toimitetaan maanantaisin ja keskiviikkoisin

Rekisteröidy tänään

© Copyright 2020 | mobilegn.com