Jos olet uusi virtualisoinnin maailmassa, verkkomääritykset voivat olla yksi vaikeimmista käsitteistä. Verkostoituminen on myös erilaista Hyper-V:ssä kuin muissa hypervisoreissa, joten jopa vuosien kokemuksen omaavat voivat kompastua, kun kohtaavat Hyper-V:n ensimmäistä kertaa. Tämä artikkeli alkaa tarkastelemalla virtuaalisen verkon käsitteellistä suunnittelua Hyper-V:ssä, konfigurointia ja sen jälkeen parhaiden toteutuskäytäntöjen läpi.
Ennen aloittamista saattaa olla hyödyllistä varmistaa, että sinulla on vankka käsitys Ethernet- ja TCP/IP-verkon perusteista yleensä. Useat artikkelit, jotka selittävät yleisiä näkökohtia, alkavat tällä OSI-mallin selityksellä.
Hyper-V:n verkkokäytön tärkein yksittäinen komponentti on virtuaalinen kytkin. Tässä blogissa on perusteellinen artikkeli Hyper-V-virtuaalikytkimestä, mutta tämän artikkelin vuoksi annan sinulle perusesittelyn konseptiin laajemmassa kuvassa.
Avain ymmärtämiseen on ymmärtää, että se todella on kytkin, aivan kuten fyysinen kytkin. Se toimii kerroksessa 2 virtuaalisten kytkinporttien välikappaleena. Se ohjaa paketit MAC-osoitteisiin. Se käsittelee VLAN-koodausta. Se voi jopa suorittaa joitain Quality of Service (QoS) -tehtäviä. Se on myös vastuussa verkkoliikenteen eristämisestä virtuaaliselle sovittimelle, jonka oletetaan vastaanottavan sitä. Hyper-V-verkkokytkintä tulee visualisoida samalla tavalla kuin tavallista kytkintä:
Seuraava osa virtuaalikytkimen ymmärtämistä on, kuinka se on vuorovaikutuksessa isännän kanssa. Avataksesi tämän keskustelun sinun on ensin tutustuttava saatavilla oleviin virtuaalikytkintyyppeihin.
Hyper-V-kytkimessä on kolme mahdollista tilaa: yksityinen, sisäinen ja julkinen. Älä sekoita näitä IP-osoitteiden järjestelyihin tai muihin virtuaaliverkkokokoonpanoihin eri tekniikassa.
Hyper-V:n yksityinen kytkinYksityinen kytkin mahdollistaa viestinnän isäntänsä virtuaalikoneiden välillä eikä mitään muuta. Edes hallinnan käyttöjärjestelmä ei saa osallistua. Tämä kytkin on täysin looginen, eikä se käytä fyysistä sovitinta millään tavalla. Tässä mielessä "yksityinen" ei liity yksityiseen IP-osoitteeseen. Voit ajatella tätä kytkimenä, jolla ei ole kykyä linkittää muihin kytkimiin.
Hyper-V:n sisäinen kytkinSisäinen kytkin on samanlainen kuin yksityinen kytkin yhdellä poikkeuksella: hallintakäyttöjärjestelmässä voi olla virtuaalinen sovitin tämän tyyppisessä kytkimessä. Näin hallintakäyttöjärjestelmä voi kommunikoida suoraan kaikkien virtuaalikoneiden kanssa, joissa on myös virtuaalisia sovittimia samassa sisäisessä kytkimessä. Kuten yksityisellä kytkimellä, sisäisellä kytkimellä ei ole mitään yhteyttä fyysiseen sovittimeen, joten se ei myöskään voi linkittää mihinkään toiseen kytkimeen.
Hyper-V:n ulkoinen kytkinUlkoinen kytkintyyppi on liitettävä fyysiseen sovittimeen. Se mahdollistaa viestinnän fyysisen verkon ja hallintakäyttöjärjestelmän sekä virtuaalikoneiden virtuaalisten sovittimien välillä. Älä sekoita tätä kytkintyyppiä julkisiin IP-osoitteisiin tai anna sen nimen vihjata, että se on liitettävä Internetiin päin olevaan järjestelmään. Voit käyttää samaa yksityistä IP-osoitealuetta ulkoisen virtuaalikytkimen sovittimille, jota käytät fyysisessä verkossa, johon se on liitetty. Ulkoinen tässä käytössä tarkoittaa, että se voi muodostaa yhteyden Hyper-V-isännän ulkopuolisiin järjestelmiin.
Osa siitä, mikä tekee ulkoisen virtuaalikytkimen ymmärtämisestä keinotekoisen vaikeaa, on tapa, jolla siihen liittyvät asetukset on muotoiltu. Hyper-V Manager -käyttöliittymässä se on muotoiltu seuraavasti: Salli hallintakäyttöjärjestelmän jakaa tämä verkkosovitin. PowerShellin New-VMSwitch-cmdletissä on AllowManagementOS-parametri, joka ei ole sen parempi, ja sen kuvaus — Määrittää, onko pääosion (eli hallintakäyttöjärjestelmän) pääsy luotavaan virtuaalikytkimeen sidottuun fyysiseen verkkokorttiin. – pahentaa tilannetta. Se, mitä näyttää tapahtuvan aivan liian usein, on se, että ihmiset lukevat näitä ja ajattelevat virtuaalikytkintä ja virtuaalisia sovittimia näin:
Valitettavasti tämä ei ole ollenkaan tarkka esitys Hyper-V:n virtuaaliverkkopinosta. Kun virtuaalinen kytkin on sidottu fyysiseen sovittimeen, sovitinta ei enää käytetä mihinkään muuhun. TCP/IP ja useimmat muut kohteet poistetaan siitä. Hallintakäyttöjärjestelmä ei yksinkertaisesti pysty "jakamaan" sitä. Jos yrität sitoa jotain muuta sovittimeen, on melko todennäköistä, että rikot virtuaalikytkimen.
Itse asiassa hallintakäyttöjärjestelmä saa oman virtuaalisen verkkosovittimen. Se yhdistetään virtuaalikytkimeen. Tämä sovitin ei ole täsmälleen samanlainen kuin virtuaalikoneiden sovittimet; se ei ole aivan yhtä rikas. Se ei kuitenkaan ole ollenkaan samanlaista kuin fyysisen sovittimen jakaminen ohjainten tarkoittamalla tavalla. Parempi termi olisi "Yhdistä hallintakäyttöjärjestelmä virtuaalikytkimeen". Sitä asetukset todella tekevät. Seuraava kuva on paljon tarkempi kuvaus siitä, mitä tapahtuu:
Kuten näet, hallintakäyttöjärjestelmän virtuaalisovitinta käsitellään samalla tavalla kuin virtuaalikoneiden sovittimia. Tietenkin sinulla on aina mahdollisuus ottaa yksi tai useampi fyysinen sovitin pois virtuaalikytkimestä. Hallintakäyttöjärjestelmä käyttää niitä normaalisti. Jos teet niin, sinun ei välttämättä tarvitse "jakaa" virtuaalikytkimen sovitinta hallintakäyttöjärjestelmän kanssa:
Windows Server 2012:sta lähtien verkkosovittimen ryhmittely on nyt Windows Server -käyttöjärjestelmän alkuperäinen toiminto. Teaming mahdollistaa kahden tai useamman sovittimen yhdistämisen yhdeksi loogiseksi viestintäkanavaksi verkkoliikenteen jakamiseksi. Hyper-V Server voi myös yhdistää fyysisiä sovittimia.
Kun tiimisovitin luodaan, yksittäiset sovittimet näkyvät edelleen Windowsissa, mutta virtuaalisen kytkimen tapaan niitä ei voi enää sitoa mihinkään muuhun kuin ryhmitysprotokollaan. Kun ryhmä on luotu, käyttöjärjestelmälle esitetään uusi sovitin. Olisi oikein kutsua tätä sovitinta "virtuaaliksi", koska sitä ei ole fyysisesti olemassa, mutta se voi aiheuttaa sekaannusta Hyper-V-virtuaalikytkimen kanssa käytettyjen virtuaalisten sovittimien kanssa. Yleisempiä termejä ovat tiimisovitin tai looginen sovitin, ja joskus käytetään lyhennettä tNIC.
Koska tiimityö ei ole Hyper-V:n keskeinen ominaisuus tai vaatimus, sitä ei käsitellä tässä yksityiskohtaisesti. Hyper-V käyttää natiivia sovittimen ryhmittelyä tehokkaasti, ja siksi sitä tulisi käyttää aina kun mahdollista. Yleissääntönä on, että sinun tulee valita dynaaminen kuormituksen tasapainotusalgoritmi, ellei sinulla ole selkeästi määriteltyä pakottavaa tarvetta. se yhdistää Hyper-V Portin ja Transport Ports -algoritmien parhaat ominaisuudet. Mitä tulee siihen, käytetäänkö kytkimestä riippumatonta tiimityötilaa vai jotakin kytkimestä riippuvaista tilaa vai ei, tämä on syvempää keskustelua, joka sisältää tavoitteidesi tasapainottamisen käytettävissäsi olevan laitteiston ominaisuuksien kanssa. Jos haluat käsitellä Hyper-V:n kanssa yhdistämisen aihetta paljon syvemmin, lue seuraavat Altaron blogin artikkelit:
[thrive_leads id=’17165′]
Verkon konvergenssi tarkoittaa yksinkertaisesti sitä, että useita liikennetyyppejä yhdistetään yhdeksi viestintäkanavaksi. Tietyssä määrin Hyper-V tekee tämän aina, koska useat virtuaalikoneet käyttävät samaa virtuaalikytkintä, siis samaa verkkolaitteistoa. Tämä kaikki voitaisiin kuitenkin teknisesti luokitella yhteen otsikkoon "virtuaalikoneliikenne", joten se ei ole aivan konvergenssi.
Hyper-V-tilassa todellinen konvergenssi sisältää ainakin yhden muun roolin ja vähintään kaksi fyysistä verkkosovitinta. Yksinkertaisin tapa saavuttaa tämä on yhdistää kaksi tai useampi sovitinta edellisessä osiossa kerrotulla tavalla ja luoda sitten virtuaalinen kytkin tiimisovittimen päälle. Kun virtuaalinen kytkin on luotu, käytä "share"-vaihtoehtoa tai PowerShellia luodaksesi virtuaalisen sovittimen myös hallintakäyttöjärjestelmää varten. Jos tätä sovitinta käytetään mihin tahansa hallintakäyttöjärjestelmään, sitä pidetään konvergenssina. Muista mahdollisista rooleista keskustellaan myöhemmin.
Vaikka yleisin konvergenssi yleensä sitoo kaikki samalla nopeudella toimivat sovittimet yhdeksi kanavaksi, se ei ole vaatimus. Voit halutessasi käyttää yhtä tiimiä virtuaalikoneen liikenteeseen ja toista hallintakäyttöjärjestelmään.
Virkasiirtoklusterilla on omat erityiset verkkotarpeensa, ja Hyper-V laajentaa näitä vaatimuksia entisestään. Jokainen solmu alkaa samoilla vaatimuksilla kuin erillinen Hyper-V-järjestelmä: yksi hallintasovitin ja virtuaalinen kytkin. Klusteri lisää tarvetta klusteriin liittyvälle liikenteelle ja Live Migrationille.
Vuotta 2012 vanhemmissa versioissa ainoa tuettu kokoonpano edellytti kaikkien näiden roolien jakamista yksilöllisiksi gigabitin yhteyksiksi. Vuosina 2012 ja 2012 R2 esiteltyjen parannusten myötä nämä vaatimukset ovat paljon rennompia. Uusissa versioissa ei ole julkaistuja vaatimuksia (vaikka voitaisiin väittää, että vuoden 2008 R2:n vaatimuksia ei koskaan virallisesti korvattu, joten ne ovat teknisesti edelleen voimassa). Käytännössä on havaittu, että on ehdottoman välttämätöntä, että yksilöllisiä klusteripolkuja on vähintään kaksi, mutta loput voidaan säätää ylös tai alas työkuormien mukaan.
Seuraavassa kuvataan jokaista roolia ja annetaan lyhyt kuvaus sen liikenteestä:
Hallinta: Tämä rooli siirtää kaiken liikenteen isäntätason varmuuskopiointiin ja kaikkiin isäntiin liittyviin tiedostojen jakamistoimintoihin, kuten ISO-kuvien käyttöön tai kopioimiseen etäjärjestelmästä. Muina aikoina tähän rooliin ei yleensä kohdistu raskasta liikennekuormaa. Tyypillinen käyttö on etähallintaliikennettä, kuten RDP ja WS-Man (PowerShell), jotka ovat erittäin kevyitä.Klusteriviestintä: Kukin klusterin solmu kommunikoi jatkuvasti kaikkien muiden solmujen kanssa verkkokuviossa varmistaakseen, että klusteri on edelleen toiminnassa. Tämä operaatio tunnetaan yleisesti "sydänlyöntinä", vaikka myös verkon konfigurointitiedoilla käydään kauppaa. Sykeliikenne on tyypillisesti hyvin kevyttä, mutta se on erittäin herkkä latenssille. Jos sillä ei ole omaa verkkoa, se voi helposti hukkua muihin toimintoihin, kuten suuriin tiedostokopioihin, mikä aiheuttaa solmujen päätösvaltaisuuden ja epäonnistumisen virtuaalikoneiden yli, vaikka mikään ei olisi teknisesti vialla.
Klusterin jaetut volyymit: CSV-liikenne ei ole ainutlaatuinen rooli; se kulkee osana tavallista klusteriviestintää. Kun kaikki on hyvin, CSV-liikenne on melko vähäistä, ja se välittää vain CSV-metadatatietoja solmujen välillä. Jos CSV siirtyy uudelleenohjatun pääsyn tilaan, omistajasolmu hoitaa kaiken CSV-tiedoston ja sieltä lähtevän liikenteen. Jos jonkin muun solmun on käytettävä kyseistä CSV:tä, se tekee sen klusteriverkon kautta. Klusteri varmistaa, että normaalia klusterin tietoliikennettä, kuten sykettä, ei uhrata, mutta kaikki kaistanleveystaistelut saavat virtuaalikoneita toimimaan huonosti – ja mahdollisesti kaatumaan. Jos klusterisi ei käytä CSV-tiedostoja, tämä liikenne ei ole ongelma. Live Migration: Ilman rajoituksia Live Migration -toiminto käyttää niin paljon kaistanleveyttä kuin mahdollista. Tyypillinen kokoonpano tarjoaa tälle roolille erillisen sovittimen. Konvergoinnissa vaatimus ei ole niin tiukka.Virtuaalikoneliikenne: VM-liikenne on luultavasti klusterin tärkeintä, mutta se ei myöskään yleensä ole liian raskasta. Perinteinen lähestymistapa on varata vähintään yksi sovitin virtuaalikytkimelle.Vaikka vanhat koontiversiot erottivat ne ainutlaatuisiksi, omistetuiksi gigabittisiksi putkiksi, sinulla on nyt enemmän vaihtoehtoja käytettävissäsi.
Klusteriviestinnässä on aina käytetty SMB-protokollaa. SMB-protokollaa päivitettiin merkittävästi vuonna 2012, ja se on nyt monikanavainen. Tämä ominaisuus neuvottelee automaattisesti lähde- ja kohdeisännän välillä ja jakaa automaattisesti SMB-liikenteen kaikkien käytettävissä olevien sovittimien kesken.
Kun ennen oli tarpeen määrittää verkot klusteriviestintää varten ja sitten muokata metrimäärityksiä liikenteen ohjaamiseksi, 2012 R2:ssa suositeltu lähestymistapa on yksinkertaisesti määrittää kaksi tai useampi verkko klusteriverkoiksi. Isännät tasapainottavat automaattisesti liikennekuormia.
Jos klusterin solmut on asetettu käyttämään SMB:tä Live Migrationissa, se hyödyntää samoja SMB-parannuksia kuin tavallinen klusterin tietoliikenne. Tällä tavalla hallintaliikenne, klusteriviestintäliikenne ja Live Migration voitaisiin kaikki ajaa vain kahdessa erillisessä verkossa kahden sijaan. Tämä on mahdollisesti riskialtista, varsinkin jos uudelleenohjattu käyttötila laukeaa.
Käyttämällä konvergoituja verkkoja saat huomattavasti enemmän vaihtoehtoja vähemmällä laitteistolla. SMB-monikanava jakaa liikenteen eri verkkoihin eli yksilöllisiin aliverkkoihin. Konvergoituja verkkoja käyttämällä voit luoda enemmän aliverkkoja kuin sinulla on fyysisiä sovittimia.
Tämä on erityisen kätevä 10 GbE-sovittimille, koska harvoilla isännillä on enemmän kuin kaksi. Sillä on myös paikkansa 1GbE-verkoissa. Voit yksinkertaisesti yhdistää kaikki fyysiset sovittimet yhdeksi suureksi tiimiksi ja luoda saman määrän loogisia verkkoja, jotka sinulla olisi perinteisessä roolissa, mutta ottaa niistä jokainen käyttöön klusteriviestintään ja Live Migrationiin. Tällä tavalla SMB-monikanava pystyy automaattisesti tasapainottamaan tarpeitaan. Muista, että jopa konvergoidussa verkotuksessa on parasta olla yhdistämättä kaikkia rooleja yhdeksi virtuaaliseksi tai tiimisovittimeksi. SMB-monikanava vaatii erilliset aliverkot suorittaakseen tehtävänsä, ja tiimityö tasapainottaa osan liikenteestä virtuaalisen sovittimen mukaan.
Vaikka huolenaihe ilmenee harvoin, on teknisesti mahdollista, että yksi liikennetyyppi kuluttaa täysin konvergoituneen tiimin. Saatavilla on useita QoS (Quality of Service) -vaihtoehtoja tämän estämiseksi. Voit erityisesti rajoittaa SMB- ja/tai Live Migration -liikennettä ja asettaa maksimi- ja vähimmäisarvoja virtuaalisille sovittimille.
Ennen kuin vietät paljon aikaa näiden vaihtoehtojen tutkimiseen, ota huomioon, että useimmat käyttöönotot eivät vaadi tällaista hallintaa ja toimivat täydellisesti oletusarvoilla. Hyper-V toimii automaattisesti ylläpitääkseen liikenteen tasapainoa, joka ei täysin peitä mitään tiettyä virtuaalista verkkosovitinta. Koska QoS-määrityksen monimutkaisuus on suurempi kuin sen hyödyt tyypillisessä ympäristössä, tätä aihetta ei tutkita tässä sarjassa. Aiheen lopullisin työ on saatavilla TechNetissä.
Yksi kriittinen käsite on, että klusteriverkot määrittää TCP/IP-aliverkko. Klusteripalvelu havaitsee jokaisen solmun jokaisen IP-osoitteen ja aliverkon peitteen. Näistä se luo verkon kullekin ainutlaatuiselle aliverkolle, jonka se löytää. Jos jollakin solmulla on useampi kuin yksi IP-osoite aliverkossa, klusteripalvelu käyttää yhtä ja ohittaa loput, ellei ensimmäistä poisteta. Jos palvelu löytää verkkoja, joille vain joillakin solmuilla on IP-osoite, verkko merkitään osioiduksi. Verkko merkitään myös osioiduksi, jos klusteriviestintä on sallittu, mutta solmujen välisessä liikennevirrassa on ongelmia. Seuraava kaavio näyttää joitakin esimerkkiverkkoja ja kuinka klusterointi havaitsee ne.
Kuvassa ainoa kelvollinen verkko on klusteriverkko 2. Huonoin on klusteriverkko 4. Aliverkon määritystavasta johtuen se on päällekkäinen kaikkien muiden verkkojen kanssa. Klusteripalvelu lukitsee automaattisesti solmun 2 sovittimen, jonka IP-osoite on 192.168.5.11, pois klusteriviestinnästä ja merkitsee verkon arvoksi Ei mitään, mikä osoittaa, että se ei ole sallittu klusteriviestinnässä.
Määritä käyttämäsi IP-aliverkot ennen klusterin rakentamista. Täysin uusien verkkojen luominen tarvittaessa on täysin hyväksyttävää. Klusteriviestinnässä solmut eivät tarkoituksella kommunikoi minkään muun kuin saman klusterin solmujen kanssa. Yksilöllisten verkkojen vähimmäismäärä on kaksi. Yksi on merkittävä, jotta asiakas- ja klusteriviestintä sallitaan; tämä on hallintaverkosto. Yksi on merkittävä, jotta klusteriviestintä sallitaan (asiakasviestintä valinnainen, mutta ei suositeltavaa). Muut verkot ovat valinnaisia, mutta ne antavat klusterille mahdollisuuden luoda lisää TCP-virtoja, jotka voivat auttaa kuormituksen tasapainottamisessa tiimisovittimien välillä.
Ei ole yhtä "oikeaa" tapaa määrittää verkkotoiminta Hyper-V:ssä, kuten ei ole yhtä "oikeaa" tapaa määrittää. fyysinen verkko. Tässä osiossa käydään läpi useita parhaita käytäntöjä ja menettelytapoja, joiden avulla voit näyttää, miten asiat tehdään, ja antaa ohjeita mahdollisuuksien mukaan. Paras neuvo, jonka kuka tahansa voi sinulle antaa, on olla ajattelematta sitä liikaa. Hyvin harvat virtuaalikoneet vaativat paljon verkon kaistanleveyttä.
On olemassa muutamia parhaita käytäntöjä, jotka auttavat sinua tekemään joitain perusmäärityspäätöksiä:
Konvergoitu verkko tuottaa parhaan yleisen kaistanleveyden jakautumisen. On erittäin harvinaista, että yksittäinen verkkorooli käyttää jatkuvasti koko gigabitin yhteyttä. Kun omistat yhden tai useamman sovittimen yhdelle roolille, estät muita rooleja käyttämästä kyseistä sovitinta, vaikka sen omistava rooli olisi käyttämättömänä.Yksi TCP/IP-virta voi käyttää vain yhtä fyysistä linkkiä. Yksi hämmentävämmistä uusien tulokkaiden kohtaamista asioista tiimityössä on se, että useiden linkkien yhdistäminen yhdeksi tiimiksi ei automaattisesti tarkoita, että kaikki liikenne käyttää automaattisesti kaikkia saatavilla olevia linkkejä. Se tarkoittaa, että eri viestintävirrat ovat tasapainossa käytettävissä olevien välillä. Tai selventääksesi asiaa, tarvitset vähintään neljä erilaista viestintävirtaa, jotta voit hyödyntää täysin neljä sovitinta tiimissä. Vältä käyttämästä iSCSI:tä tai SMB 3:a suoraan ryhmittymisen kanssa. Se on tuettu molemmille, mutta se on vähemmän tehokas kuin MPIO (iSCSI:lle) tai SMB-monikanavan käyttäminen. On tuettu useita virtuaalisia verkkosovittimia, jotka on määritetty iSCSI- tai SMB-monikanavaa varten. Saat kuitenkin aina parhaan suorituskyvyn verkkotallennustilassa käyttämällä ryhmittämättömiä sovittimia, joita ei ole sidottu virtuaaliseen kytkimeen. Tässä artikkelissa kerrotaan, kuinka MPIO määritetään.Tiimin luomiseen tarvittavat vaiheet on linkitetty aiemmin, mutta tässä on linkki uudelleen: https://www.altaro.com/hyper-v/how-to-set-up- native-tiams-in-hyper-v-server-2012/.
Jos järjestelmässäsi on Windows Serverin GUI-versio, voit määrittää TCP/IP:n kaikille sovittimille perinteisten graafisten työkalujen avulla. Kaikissa versioissa voit myös käyttää tiedostoa sconfig.cmd ohjattua prosessia varten. Tämä osio näyttää, kuinka nämä tehtävät suoritetaan PowerShellin avulla. Jotta materiaali olisi mahdollisimman tiivis, kaikkia mahdollisia vaihtoehtoja ei näytetä. Katso johdattelevasta PowerShell-artikkelista apua cmdlet-komentojen ominaisuuksien löytämisessä Get-Help:n ja muiden työkalujen avulla.
Katso sovittimen tila (ja muissa komentotiedostoissa käytettävät nimet)
Get-NetAdapterNimeä fyysinen tai tiimisovitin uudelleen
Rename-NetAdapter Name CurrentName NewName NewNameAseta sovittimen IP-osoite
New-NetIPAddress InterfaceAlias AdapterName IPAddress 192.168.20.20 PrefixLength 24Aseta sovittimen oletusyhdyskäytävä
New-NetRoute InterfaceAlias AdapterName DestinationPrefix 0.0.0.0/0 NextHop 192.168.20.1Vinkki: käytä "Set-NetRoute" tehdäksesi muutoksia tai "Remove-NetRoute" päästäksesi eroon yhdyskäytävästä.
Aseta DNS-palvelinosoitteet
Set-DNSClientServerAddresses InterfaceAlias AdapterName – ServerAddresses 192.168.20.5, 192.168.20.6Estä sovitinta rekisteröitymästä DNS:ään
Set-DnsClient InterfaceAlias AdapterName RegisterThisConnectionsAddress $falseViimeinen vaihtoehto, jota kannattaa harkita, on Jumbo Frames -kehyksen asettaminen virtuaalisille sovittimille. Jumbo Frame on mikä tahansa TCP/IP-paketti, joka ylittää peruskoon 1514 tavua. Sitä käytetään yleisimmin iSCSI-yhteyksissä, mutta se voi myös auttaa hieman SMB 3- ja Live Migration -liikenteessä. Se ei ole ollenkaan hyödyllinen Internetin ylittävässä liikenteessä, eikä suurin osa tavallisista LAN-liikenteestä myöskään hyödy siitä paljon. Jos haluat käyttää sitä, seuraava viesti selittää sen yksityiskohtaisesti: https://www.altaro.com/hyper-v/how-to-adjust-mtu-jumbo-frames-on-hyper-v-and -windows-palvelin-2012/. Kyseinen artikkeli on kirjoitettu vuodelle 2012. Vuoden 2012 R2:n virtuaalikytkimessä Jumbo Frames on oletusarvoisesti käytössä, joten sinun tarvitsee vain seurata osia, jotka selittävät sen asettamisen fyysisille ja virtuaalisille sovittimillesi.
Kaikki graafiset työkalut virtuaalikytkimen luomiseen ja yksittäisen virtuaalisovittimen määrittämiseen hallintakäyttöjärjestelmää varten käsiteltiin tässä sarjan edellisessä artikkelissa. Graafisten työkalujen avulla ei voi luoda muita virtuaalisia sovittimia hallintakäyttöjärjestelmän käyttöön. Sinun on myös käytettävä PowerShellia virtuaalisen kytkimen luomiseen, jos haluat hallita sen QoS-käytäntöä. Seuraavat PowerShell-komennot käsittelevät virtuaalikytkintä ja sen sovittimia.
Luo ulkoinen virtuaalikytkin
Uusi-VMSwitch –InterfaceAlias AdapterName –Name vSwitch –AllowManagementOS $false –EnableIOV $false –MinimumBandwidthMode WeightTässä cmdletissä on useita huomioitavia asioita:
Yllä näkyvä "InterfaceAlias"-parametri on itse asiassa "NetAdapterName" -alias. Alias valittiin tähän, koska se on linjassa Get-NetAdapterin parametrin nimen ja lähdön kanssa. cmdletille kirjoitettiin virtuaalikytkimen nimeksi "vSwitch", mutta voit käyttää mitä tahansa. Jos valitsemasi nimessä on välilyönti, sinun on suljettava se kerta- tai lainausmerkeissä. Jos et määritä "AllowManagementOS"-parametria tai asetat sen arvoksi tosi, se luo automaattisesti virtuaalisen sovittimen hallintakäyttöjärjestelmää varten. samalla nimellä kuin virtuaalikytkin. Ohitamalla tämän automaattisen luomisen saat paremman hallinnan omien virtuaalisten sovittimiesi luomiseen ja asettamiseen. Jos et halua ottaa SR-IOV:ta käyttöön virtuaalikytkimessäsi, tätä parametria ei tarvitse määrittää ollenkaan. Se näkyy tässä muistutuksena siitä, että jos aiot asettaa sen, sinun on asetettava se, kun kytkin luodaan. Et voi muuttaa tätä myöhemmin. Get-VMSwitchin ohjedokumentaation mukaan "MinimumBandwidthMode" -asetuksen oletusarvo on "Weight". Tämä on väärin. Oletustila on "Absolute". Kuten SR-IOV-tuessa, et voi muokata tätä asetusta kytkimen luomisen jälkeen.Luo yksityinen virtuaalikytkin
New-VMSwitch Name Isolated SwitchType Yksityinen Minimikaistanleveystilan painoMonet ulkoisen kytkimen luomisesta saadut huomautukset koskevat myös tätä. EnableIOV-kytkin ei sovellu yksityiseen tai sisäiseen kytkimeen ollenkaan. "AllowManagementOS"-kytkin on redundantti: jos kytkimen tyyppi on "Private", virtuaalista sovitinta ei luoda; jos kytkimen tyyppi on "Sisäinen", sellainen luodaan. Yhden virtuaalisen sovittimen lisääminen hallintakäyttöjärjestelmään yksityisellä kytkimellä muuttaa sen sisäiseksi. Kaikkien hallintajärjestelmän virtuaalisten sovittimien poistaminen sisäisestä kytkimestä tekee siitä yksityisen.
Poista virtuaalinen kytkin pysyvästi
Remove-VMSwitch Name vSwitchTämä toiminto on pysyvä. Koko kytkin ja kaikki sen asetukset menetetään. Kaikki tämän kytkimen hallintakäyttöjärjestelmän virtuaaliset sovittimet menetetään pysyvästi. Tähän kytkimeen kytkettyjen virtuaalikoneiden virtuaaliset sovittimet on irrotettu.
Lisää virtuaalinen sovitin hallintakäyttöjärjestelmään
Add-VMNetworkAdapter ManagementOS SwitchName vSwitch Name 'New vAdapter'Ensimmäinen huomioitava asia on, että jostain syystä tämä cmdlet käyttää "Lisää" tavallisen "New"-verbin sijaan uuden objektin luomiseen. Huomaa, että tämä uusi sovitin näkyy Get-NetAdapter-merkinnöissä nimellä vEthernet (New vAdapter), ja tätä nimeä käytät kaikille sellaisille ei-Hyper-V-cmdleteille. Käytä määritysten tekemiseen samoja cmdlet-komentoa kuin edellisessä osassa
Hae luettelo hallintakäyttöjärjestelmän virtuaalisista sovittimista
Get-VMNetworkAdapter – ManagementOSNimeä virtuaalinen sovitin uudelleen hallintakäyttöjärjestelmässä
Rename-VMNetworkAdapter ManagementOS Name CurrentName NewName NewNameVLAN-verkkoihin voidaan määrittää hallintakäyttöjärjestelmän ja virtuaalikoneiden sovittimet. Kun näin tapahtuu, Hyper-V-virtuaalinen kytkin käsittelee 802.1q-koodausprosessia virtuaalikytkimien välistä viestintää ja paketteja varten fyysisille kytkimille. Kuten Virtuaalikoneen asetuksia koskevassa artikkelissa näkyy, voit käyttää Hyper-V Manageria minkä tahansa virtuaalikoneen liitetyn sovittimen VLAN:in vaihtamiseen. Voit käyttää PowerShellia vain virtuaalisten sovittimien VLAN:in vaihtamiseen hallintakäyttöjärjestelmässä.
Hae VLAN-määritykset kaikille isäntäkoneen virtuaalisovittimille
GetVMNetworkAdapterVlanVoit käyttää ManagementOS-parametria nähdäksesi vain sovittimet hallintakäyttöjärjestelmässä. Voit käyttää VMName-parametria tähdellä nähdäksesi vain virtuaalikoneen liitetyt sovittimet.
Aseta virtuaalisovittimen VLAN hallintakäyttöjärjestelmässä
Set-VMNetworkAdapterVlan ManagementOS VMNetworkAdapterName vAdapterName Access VlanId 10Aseta VLAN kaikille virtuaalikoneen sovittimille
Set-VMNetworkAdapterVlan -VMName svtest -Access -VlanId 7Poista VLAN-tunnisteet kaikista virtuaalikoneen sovittimista
Set-VMNetworkAdapterVlan -VMName svtest – UntaggedJos virtuaalikoneessa on useampi kuin yksi virtuaalinen sovitin ja haluat käyttää sitä erikseen, se saattaa vaatia hieman enemmän työtä. Kun GUI:ta käytetään virtuaalikoneen virtuaalisten sovittimien luomiseen, ne nimetään aina Verkkosovittimeksi, vaikka niitä olisi useita. Joten sinun on nimettävä ne uudelleen PowerShellin avulla, kun ne luodaan, tai et voi käyttää "VMNetworkAdapterName" -tunnusta niiden erottamiseen. Sen sijaan voit käyttää Get-VMNetworkAdapter-työkalua muiden erottavien ominaisuuksien etsimiseen ja tulosteen ohjaamiseen VMNetworkAdapter-objekteja hyväksyviin cmdleteihin. Haluat esimerkiksi muuttaa vain yhden sovittimen VLAN-verkkoa, joka on liitetty virtuaalikoneeseen nimeltä "svtest". Käyttämällä vieraskäyttöjärjestelmän työkaluja olet päättänyt, että muutettavan sovittimen MAC-osoite on "00-15-5D-19-0A-24". MAC-osoitteella voit muuttaa vain kyseisen sovittimen VLAN-verkkoa käyttämällä seuraavaa PowerShell-rakennetta:
GetVMNetworkAdapter VMName svtest | jossa { $_.MacAddress eq '00155D190A24' } | SetVMNetworkAdapterVlan –VMName Access VlanId 7Voit käyttää PowerShellia verkoston määrittämiseen vikasietoklusterillesi, mutta se on erittäin tyylikäs näiden cmdlet-komentojen nykyiseen tilaan nähden. Tällä hetkellä niitä ei ole määritetty hyvin, joten sinun on suoraan manipuloitava objektin ominaisuusarvoja ja rekisteriasetuksia tavalla, joka on riskialtista ja virhealtista. On paljon parempi, että käytät Failover Cluster Manageria näiden asetusten tekemiseen, kuten tässä artikkelissa on aiemmin selostettu.
Hyper-V-virtuaaliverkotuksessa on paljon sulateltavaa. Tähän mennessä näkemäsi on todellakin vain perusasiat. Suhteellisen yksinkertaisessa käyttöönotossa, jossa on enintään muutama tusina virtuaalikoneita, et ehkä koskaan tarvitse enempää tietoja. Kun tiheydet alkavat nousta, tarve tiivistää verkottumista kasvaa. Gigabit-sovittimilla paras vaihtoehto on skaalata. 10GbE-sovittimien avulla voit voittaa fyysiset suorittimen rajoitukset useilla purkutekniikoilla, joista tärkein on VMQ. Aloita tutkimuksesi aiheesta aloittamalla aihetta käsittelevästä lopullisesta artikkelisarjasta VMQ Deep Dive.
Muuten paras seuraava vaihe on harjoitella PowerShell-cmdlet-komentoja. Opi esimerkiksi käyttämään Set-VMNetworkAdapteria virtuaalisten sovittimien muokkaamiseen samalla tavalla kuin aiemmissa GUI-artikkeleissa. Pienellä vaivalla voit vaihtaa sovittimien ryhmiä kerralla. Hyper-V:n verkostoituminen voi olla monitahoista ja monimutkaista, mutta sinulle myönnetty hallinnan taso on yhtä laaja.
![[Ratkaistu] Ei voi muodostaa yhteyttä MySql-palvelimeen localhostilla (10061) (Näytä aihe) * Apache OpenOffice -yhteisöfoorumi](http://website-google-hk.oss-cn-hongkong.aliyuncs.com/drawing/26/2022-3-1/7051.jpeg "[Ratkaistu] Ei voi muodostaa yhteyttä MySql-palvelimeen localhostilla (10061) (Näytä aihe) * Apache OpenOffice -yhteisöfoorumi")
