Hyper-V verkot. Käyttöönotossa huomioitavat asiat ja parhaat käytännöt.

Yleensä Hyper-V:n testaaminen vaikka omalla kannettavalla on niinkin helppoa että otetaan Hyper-V rooli käyttöön ja jaetaan käytettävä verkkoliittymä isäntäkäyttöjärjestelmän kanssa. Edellä mainitulla konfiguraatiolla päästään helposti testaamaan Hyper-V:n yleistoiminnallisuutta, mutta jos sitä tulisi testata myös oikeassa palvelinympäristössä, jossa myös korkea käytettävyys on suunnittelun lähtökohta, niin käyttöönotossa tulee huomioida laajemmin eri asioita. Aluksi kannattaa tarkastaa muutama alustan optimointiin ja käyttöönottoon liittyvä asia.

• Käyttöliittymä, tarvitaanko alustapalvelimissa täyttä Windows käyttöliittymää. Windows Server 2012 tuo kolme eri käyttöliittymävaihtoehtoa: Täysi Windows GUI, MinShell tai Server Core. Tämän lisäksi valintaa voi muuttaa eli vaikka asentaisit alustapalvelimen valmiiksi täyden Windows GUI:n kanssa voit lopuksi ottaa sen pois ja jättää koneeseen pelkän Server Core käyttöliittymän.
• Tietoturvapäivitykset
• Hyper-V ja Cluster palveluun liittyvät toiminnalliset päivitykset
  • Windows Server 2012 Hyper-V: https://social.technet.microsoft.com/wiki/contents/articles/15576.hyper-v-update-list-for-windows-server-2012.aspx
  • Windows Server 2012 Failover Clustering: https://support.microsoft.com/kb/2784261
• Palvelinraudan ja muiden laitteistoon liittyvien komponenttien firmware päivitykset
• Älä käytä alustapalvelimissa muita palveluita kuin palvelinvirtualisointiin tarvittavat palvelut (Hyper-V sekä VDI käyttöskenaariossa tarvittavat RDS palvelut)

Perusasioiden jälkeen ensimmäisiä asioita onkin suunnitella verkkoliittymät vastaamaan alustan vaatimuksia siirrettävyyden, hallinnan ja korkean käytettävyyden näkökulmasta.

Miten Windows yleisesti käsittelee eri verkkoadaptereita ja aliverkkoja

Ennen kuin lähdemme tarkemmin käymään läpi eri verkkoja ja niihin liittyviä vaatimuksia on hyvä kerrata miten Windows käyttöjärjestelmä toimii eri verkkojen suhteen. Mikäli käyttöjärjestelmällä on käytettävissään useita verkkoliittymiä, fyysisiä sekä mahdollisesti myös virtuaalisia, monella tulee kysymys siitä että milloin Windows käyttää mitä liittymää ja millaisia tapoja on määritellä käyttöjärjestelmä hyödyntämään niitä. Järjestys menee yleistettynä seuraavasti:

1. Pyytääkö sovellus käytettäväksi jotain tiettyä verkkoadapteria?
   1. Kyllä – ajetaan sovelluksen liikenne tämän adapterin kautta
   2. Ei – Jatketaan kohtaan 2
2. Onko käyttöjärjestelmällä adapteria jolla olisi IP osoite samasta aliverkosta kuin mikä kohde osoite on?
   1. Kyllä – Onko niitä enemmän kuin yksi
      1. On – Käytä sitä adapteria joka on korkeammalla Binding order järjestyksessä (Binding order järjestys on käsin määriteltävissä verkkoliittymät kohdasta ohjauspaneelissa)
   2. Ei – Jatketaan kohtaan 3
3. Onko jollain paikallisella verkkoadapterilla oletusyhdyskäytävää määriteltynä?
   1. Kyllä – Jatketaan kohtaan 4
   2. Ei – Liikenne pysähtyy ilmoitukseen ”Destination unreachable”
4. Onko yhdyskäytävällä määriteltyjä verkkoadaptereita enemmän kuin yksi?
   1. Ei – Käytä liikenteeseen sitä adapteria jolla on yhdyskäytävä
   2. Kyllä – Jatketaan kohtaan 5
5. Onko jollekin yhdyskäytävällä määritellylle verkkoadapterille annettu alempi metric arvo kuin toiselle?
   1. Kyllä – Käytetään liikenteeseen sitä adapteria jolla on pienin metric arvo
   2. Ei – Käytetään liikenteeseen sitä yhdyskäytävällä varustettua adapteria joka on korkeimmalla Binding Order järjestyksessä.

Edellisessä on siis käyttöjärjestelmän toiminnallisuus eri verkkojen kanssa ja seuraavassa katsotaan asiaa Hyper-V:n, tallennuksen ja klusteroinnin näkökulmasta.

Aliverkot yleisesti korkeasti käytettävässä virtualisointialustassa voisi yleistää seuraaviin adaptereihin / aliverkkoihin:

1. Virtuaalipalvelinten liikenne – liittymä jonka kautta ajettavat virtuaalipalvelimet liikennöivät omiin asiakasverkkoihin. Liikenteen määrä riippuu täysin ajettavasta kuormasta.
2. Hallinta – liittymä jolla isäntäkäyttöjärjestelmää hallinnoidaan. Windows palvelimen ollessa kyseessä, yleisin liikenne joka tästä kulkee on RDP Protokolla etähallintaan. Liikenteen määrä on pieni ja latenssivaatimus ei ole suuri.
3. Klusterin heartbeat sekä CSV levyalueen liikenne – liittymä jonka kautta klusteri varmistaa toisten noodien terveyden sekä tietyissä tilanteissa tämän kautta ajetaan myös CSV levyalueelle tarkoitettua kirjoitusta ns. isäntänoodin kautta. Liikenteen määrä pientä normaalitilanteessa mutta ongelmatilanteessa tarve voi kasvaa merkittävästi
4. Live Migration liikenne – liittymä jonka kautta klusteri siirtää käynnissä olevan virtuaalipalvelimen tilan sekä mahdollisesti myös virtuaalilevyt. Liikenne vaihtelee ja riippuu onko dynaamista klusterin tasaamista otettu käyttöön (SCVMM DynamicOptimization) tai siirrelläänkö kuormia jostain muusta syystä klusterissa. Liikenteessä voi varautua suureen kaistantarpeeseen sekä pieneen viiveeseen.
5. iSCSI liikenne – mikäli tallennusratkaisuna käytetään iSCSI tallennusjärjestelmää, tarvitaan sille myös oma liittymä. Liikenteen määrä on suuri ja viive on pieni.

 

Seuraavaksi käsitellään näiden eri verkkojen määritystä ja huomioita niissä:

Virtuaalipalvelinten liikenne

Virtuaalipalvelinten liikenteelle käytettävä adapteri voidaan määritellä Hyper-V konsolista. Ensimmäinen siinä huomioitava asia on kohta ”Allow management operating system to share this network adapter”.  Tässä siis voidaan valitun verkkoadapterin liikenne jakaa isäntäkäyttöjärjestelmän hallinnan ja virtuaalipalvelinten kesken. Tässä tapauksessa isäntäkäyttöjärjestelmälle luodaan uusi virtuaalinen verkkokortti jonka kautta kaikki isäntäkäyttöjärjestelmän liikenne ajetaan fyysiseen adapteriin joka aiemmin oli dedikoitu isännälle. Liikennettä on mahdollista erotella käyttäen esimerkiksi VLAN verkkoja määrittelemällä isäntäkoneen adapterille hallintaverkon VLAN ID ja vastaavasti virtuaalipalvelimille niiden omat VLAN ID:t.

Yleisesti kuitenkin palvelimissa joissa on riittävä määrä verkkoadaptereita, on kuitenkin dedikoitu hallintaan oma fyysinen adapteri jolloin jätetään ruksi pois kohdasta ”Allow management operating system to share this network adapter”. Tässä tapauksessa virtuaalipalvelimille valittu verkkoadapteri on dedikoitu vain sille liikenteelle. Tässä liikenteessä voidaan siis tuoda asiakasverkot virtuaalipalvelimille käyttäen VLAN Trunking toimintoa ja määritellä virtuaalipalvelimen asetuksissa virtuaalikoneen käyttämä VLAN ID.

Monessa keskustelussa on tullut vastaan tilanteita joissa tämä ruksi on unohtunut päälle vaikka isäntäkoneen hallintaan onkin dedikoitu oma fyysinen adapteri. Pahimmassa tapauksessa mikäli ruksi on jäänyt paikalleen isäntä käyttää useaa eri adapteria sekä useaa eri yhdyskäytävää omaan liikenteeseensä jolloin myös vianselvitys voi koitua varsin hankalaksi.

Virtuaalipalvelinten liikenteeseen voidaan, ja myös Windows Server 2012 alustassa useasti käytetäänkin Network Teaming toiminnallisuutta jolloin sidotaan useampi verkkoadapteri tiimiksi ja sen käyttämä liikenne ajetaan virtuaalisen multiplex adapterin kautta. Mikäli näin halutaan konfiguroida virtuaalipalvelinten liikenne, niin tulee muistaa valita Multiplex adapteri luotaessa virtuaaliverkkoa Hyper-V konsolissa.

Tämän jälkeen kun joku adapteri on valittu virtuaalipalvelinten käyttöön Windows poistaa sen käytöstä eri IP protokollat ja muut sidokset. Ainoa voimaan jäävä sidos kyseiselle adapterille on Hyper-V Extensible Switch.

Tässä tehdyt määritykset toimivat siis ”Miten Windows yleensä käsittelee eri aliverkkoja” kappaleessa mainitun kohdan 1 mukaisesti jolloin sovellustasolla valitaan käytettävä verkkoadapteri.

Hallinta

Isäntäkoneen hallintaan käytetty verkkoadapteri. Käytännössä eristetty verkkosegmentti johon vain ylläpidolla on pääsy. Isäntäkäyttöjärjestelmä käyttää tätä liittymä myös omiin päivityksiinsä. Tämä on yleisesti ainut jolle määritellään yhdyskäytävä. Adapteri voidaan myös tiimata ja käyttää myös tässä Multiplex virtuaaliadapteria mikäli hallintaliikenne halutaan esimerkiksi kahdentaa korkean käytettävyyden vuoksi. Manuaalisesti on myös mahdollista asettaa metric arvo hallinta adapterille niin että liikenne menee aina sen kautta, tämä voidaan asettaa seuraavalla komennolla: NETSH INTERFACE IP SET INTERFACE “Hallinta LAN Liittymän nimi tähän" METRIC=1

Tässä tehdyt määritykset toimivat siis ”Miten Windows yleensä käsittelee eri aliverkkoja” kappaleessa mainitun kohdan 4a mukaisesti jolloin hallintaliikenne ajetaan yhdyskäytävän omaavan adapterin kautta ja kohdan 5a mukaisesti kun määrittelemme metric arvon käytettävälle adapterille..

Klusterin heartbeat sekä CSV levyalueen liikenne

Tämän verkon avulla Windows Cluster palvelu pitää yhteyttä eri noodien välillä ja päättelee niiden terveydentilan. Lisäksi jos ja kun Hyper-V klusterille on määritelty yhteinen CSV (Cluster Shared Volumes) levyalue käytetään sen tarvitsemaan liikenteeseen tätä adapteria. CSV tarvitsee liittymää pitääkseen tiedot levyalueesta synkronissa sekä mikäli sattuisi sellainen tilanne että jollain klusterin noodilla katkeaisi yhteys levyalueelle kuidun tai iSCSI:in kautta siinä tapauksessa kyseinen noodi yrittäisi tehdä kirjoituksia toisen klusterinoodin kautta käyttäen tätä verkkoliittymää. Tässä tilanteessa myös kaistan tarve voi olla yllättävän suuri. Kyseessä on kuitenkin poikkeustilanne ja normaalitilassa liikenne ei ole suurta.

Tälle liikenteelle tulisi dedikoida oma adapterinsa sekä oma aliverkkonsa jossa kaikki noodit ovat kytkettynä. Käytettävä adapteri määritellään Failover Cluster Manager konsolista sekä määrittelemällä metric arvo komentoriviltä.

Mikäli käytettävästä adapterista on omassa ympäristössä epävarmuutta tai se halutaan määritellä käsin niin seuraavassa ohjeet siihen:

• Aluksi otetaan käyttöön klusterin PowerShell komennot: DISM /ONLINE /ENABLE-FEATURE /FEATURENAME:FailoverCluster-PowerShell
• “Get-ClusterNetwork | ft Name,AutoMetric,Metric,Role” Komento palauttaa klusterin tuntemien verkkojen nimet (Name)
  • Esimerkiksi Cluster Network 1, nämä voi tarkistaa Failover Cluster konsolista

• Kyseisen verkkoliittymän roolin (0,1 tai 3)
  • Rooli 0 tarkoittaa että kyseiselle verkkoliittymälle on valittu Failover Cluster managementista ”Do not allow cluster network communication on this network”
  •  Rooli 1 tarkoittaa että kyseiselle verkkoliittymälle on valittu Failover Cluster managementista ”Allow cluster network communication on this network” mutta poistettu valinta ”Allow clients to connect throught this network”
  • Rooli 3 tarkoittaa että kyseiselle verkkoliittymälle on valittu Failover Cluster managementista ”Allow cluster network communication on this network” sekä valittuna kohta ”Allow clients to connect throught this network”

• Onko automaattinen priorisointi käytössä (AutoMetric)
  • True tai False

• Prioriteetti arvon (Metric)
  • Ensimmäinen Autometric arvo 2012 palvelimessa roolin 1 adapterille on 30384
  • Ensimmäinen Autometric arvo 2012 palvelimessa roolin 3 adapterille on 70384
  • Roolin 1 verkkoliittymän alimman metric arvon saavaa adapteria käytetään klusterin heartbeat liikenteeseen sekä CSV liikenteeseen.
  • Seuraavaksi suuremman metric arvon omaava roolin 1 tai 3 adapteria käytetään Live Migration liikenteeseen.
    • Live Migration liikenteeseen käytettävät adapterit voidaan myös käsin valita Failover Cluster management konsolista
  • Mikäli klusterissa on enemmän roolin 1 adaptereita, niitä käytetään varmuusreittinä kummalle vain liikenteelle

Tässä tehdyt määritykset toimivat siis ”Miten Windows yleensä käsittelee eri aliverkkoja” kappaleessa mainitun kohdan 1 mukaisesti kun määritellään asetuksia Failover Cluster Manager konsolista ja kohdan 5a mukaisesti kun määrittelemme metric arvon käytettävälle adapterille.

Live Migration liikenne

Live migration liikenteelle tarkoitetut verkkoadapterit voidaan valita Failover Cluster Manager konsolista, Networks, Live Migration Settings kohdasta. Tuolta voidaan siis valita käytettävät adapterit sekä järjestys jolla niitä käytetään, mikäli jokin niistä ei olisi saatavilla. Tämän lisäksi Hyper-V Manager konsolista voidaan erikseen listata verkot mistä sallitaan sisääntuleva Live Migration liikenne. Tämän rajoituksen käyttämistä kannattaa kuitenkin harkita, mikäli ei ole tarkoitusta rajata tiukasti sisään tulevaa Live Migration liikennettä. Yleensä käytettävä aliverkko on privaattiverkko ilman yhdyskäytävää, poikkeuksen tähän voi kuitenkin muodostaa Share Nothing Live Migration. Yhdyskäytävällä varustettu Live Migration verkko tarvitaan, mikäli Share Nothing Live Migrationin avulla halutaan siirtää virtuaalipalvelimia johonkin toisessa aliverkossa olevaan isäntäkoneeseen.

Tässä tehdyt määritykset toimivat siis ”Miten Windows yleensä käsittelee eri aliverkkoja” kappaleessa mainitun kohdan 2a mukaisesti mikäli käytetään Live Migration toiminnallisuutta vain samassa aliverkossa olevien isäntäkoneiden kanssa ja kohdan 4a mukaisesti mikäli käytössä on Share Nothing Live Migration ja virtuaalipalvelimia halutaan siirtää toisissa aliverkoissa oleville palvelimille.

iSCSI verkko

iSCSI liikenteen osalta suositeltavaa olisi että Initiator ja Target ovat samassa aliverkossa jolloin sille dedikoitu adapteri valitaan automaattisesti saman aliverkon osoitteen perusteella. iSCSI liikenne on myös mahdollista reitittää mutta tämä voi rasittaa kohtuuttomasti verkkolaitteita ja tätä kannattaa harkita tarkkaan suunnitteluvaiheessa. Mikäli liikenne reititetään ja halutaan valita manuaalisesti käytettävä adapteri, voidaan se tehdä PowerShell komennoilla tai iscsicli.exe:n avulla.

iSCSI liikenne suositellaan yleensä kahdennettavaksi. Kahdennusta tässä verkossa ei toteuteta normaali verkkotiimauksella vaan MPIO:n avulla. Tämän vuoksi palvelimeen tulee asentaa toiminnallisuus nimeltä Multipath IO, mikäli käytetään Windowsin omaa MPIO toiminnallisuutta tai mahdollisesti levyjärjestelmätoimittajan oma MPIO toteutus.

iSCSI verkko ei ole Failover Cluster palvelun kontrolloima resurssi mutta klusteri haluaa kuitenkin ottaa sen hallintaansa. iSCSI verkot tulee käsin määritellä pois klusterin käytöstä. Tämä tehdään Failover Cluster konsolista valitsemalla kyseiselle verkkoliittymälle: “Do not allow cluster network communication on this network.”

Tässä tehdyt määritykset toimivat siis ”Miten Windows yleensä käsittelee eri aliverkkoja” kappaleessa mainitun kohdan 2a mukaisesti mikäli käytetään iSCSI toiminnallisuutta vain samassa aliverkossa olevien targetin sekä initiatorin kesken ja kohdan 1a mukaisesti mikäli jokin tietty adapteri valitaan manuaalisesti PowerShellin tai iscsicli.exe:n avulla.

Tässä blogikirjoituksessa olemme siis käsitelleet Windows Server tasolla miten määritellään eri verkkoadapterit korkean käytettävyyden Hyper-V ympäristössä. Seuraavassa Technet TV lähetyksessä ja siihen liittyvässä blogikirjoituksessa käsittelemme laajemmin korkean käytettävyyden ratkaisuja Hyper-V:ssä. Toivottavasti tästä oli apua oman ympäristön testaamiseen ja mikäli sinulla on kommentoitavaa tai lisättävää niin minulle voi laittaa sähköpostia asiasta.

Technet TV tallenne Hyper-V verkoista löytyy seuraavasta osoitteesta:

https://youtu.be/LuK4ZEdudKg

Terveisin,

Antti Alila

Tuotepäällikkö

Server & Cloud, Microsoft Oy