Miten kytkin virtualisoidaan
Palvelinten virtualisointitekniikoihin etsitään yhteistä säveltä. Seuraavaksi on vuorossa virtuaalikytkimien standardointi.
Kun samassa fyysisessä palvelinlaitteessa ajetaan useita virtuaalikoneita, myös niiden oheislaiteliitännät virtualisoidaan, jotta fyysisiä liitäntöjä voitaisiin käyttää rinnakkain. Hypervisor-kerros limittää esimerkiksi virtuaalisten verkkosovitinten liikenteen fyysisille verkkosovittimille.
Hypervisor voi hoitaa muitakin verkkoliikenteen toimintoja. Kun samassa fyysisessä laitteessa ajettavat virtuaalikoneet kommunikoivat keskenään, liikennettä on turha kuljettaa verkon kautta.
Virtualisointiohjelmistot sisältävätkin usein virtuaalikytkimen, joka ohjaa liikennettä sekä fyysisten verkkosovitinten kautta verkkoon että virtuaalipalvelinten välillä palvelinlaitteen sisällä. Tällainen kytkin on niin Vmwaren ESX:ssä, Microsoftin Hyper-V:ssä, Citrixin XENissä kuin Linuxin KVM:ssäkin. Verkkotopologian kannalta kytkin on silta, joten virtuaalikytkimestä käytetään myös nimitystä veb (virtual ethernet bridge).
Veb ei kuitenkaan aina ole tehokkain tapa hoitaa verkkoliikennettä. Virtuaalikoneiden määrän kasvaessa kymmeniin ja verkkoliitäntöjen nopeuksien noustessa yli gigabitin alkavat hypervisorit olla kovilla. Tehokkaampi tapa virtualisoida verkkoliikennettä onkin ajaa yhdellä fyysisellä verkkosovittimella useita virtuaalisia verkkosovittimia, jotka jaetaan virtuaalikoneiden käyttöön.
Yhdessä nykyaikaisessa verkkosovittimessa voi olla useita fyysisiä portteja, joista kuhunkin liittyy kymmeniä virtuaalisia verkkosovittimia omine puskurialueineen. Fyysiset portit ovat hypervisor-kerroksen hallinnassa, ja jokainen virtuaalikone hallitsee omia virtuaalisia verkkosovittimiaan. Verkkosovittimessa voidaan ajaa myös omaa veb-virtuaalikytkintä, joka hoitaa virtuaalikoneiden välistä liikennettä yhdessä hypervisorin kanssa.
Kääntöpuolena hallinnan vaikeus
Veb on toteutustavastaan riippumatta luonteeltaan reunakytkin. Siihen kytketään vain virtuaalikoneita, eikä sen tarvitse välittää muiden kytkinten välistä liikennettä.
Enintään voi olla tarpeen ketjuttaa verkkosovittimen ja hypervisorin virtuaalikytkimiä toisiinsa. Kaikenlaiset runko- ja keräilykytkinten toiminnot ovat joka tapauksessa turhia, koska reunakytkin ei voi osallistua esimerkiksi virityspuun muodostamiseen.
Siirtoyhteyskerroksen vlan-toiminnot ovat sen sijaan usein tarpeellisia. Myös palvelimen fyysisten porttien niputus voi olla tarpeen kuormanjako- tai vikasietoisuussyistä.
Vebin ei tarvitse edes oppia verkon mac-osoitteita. Hypervisor jakaa virtuaalisille verkkosovittimelle näiden mac-osoitteet, jotka ovat palvelinlaitteiston puitteissa automaattisesti tiedossa. Vebin ei liioin tarvitse toteuttaa pääsylistojen, lähdeporttisuodatusten tai 802.1x:n kaltaisia tietoturvatoimintoja.
Yksinkertaisuudesta on joskus myös haittaa. Käytettävissä ei esimerkiksi ole standardia tapaa selvittää virtuaalipalvelimen suorituskyky- tai toimivuusongelmia verkkoliikennettä tarkkailemalla. Jos virtuaalikoneiden välinen liikenne pysyy palvelinlaitteen sisäisenä, missään ei myöskään ole diagnostiikkaporttia, johon epäilyttävän virtuaaliportin liikenteen voisi peilata.
Yksi ratkaisu näihin ongelmiin on tietysti virtuaalikytkimen toiminnallisuuden lisääminen. Tähän päätyivät Vmware ja Cisco kehittäessään jo vuonna 2008 hajautetun virtuaalikytkimen, joka toimii yhteistyössä Ciscon verkonhallinnan kanssa.
Cisco Nexus 1000V -ratkaisussa Vmwaren hypervisorin virtuaalikytkin korvataan erityisversiolla, joka kommunikoi erillisen hallinta-aseman kanssa. Luonnollisesti myös hallintayhteys Vmwaren Vcenteriin on edelleen käytettävissä.
Cisco käyttää hallintaan itse kehittämäänsä vn-link-käytäntöä. Se pohjautuu vntag-replikointitunnisteeseen, jolla merkitään virtuaaliportin lähettämät paketit ja jota käytetään ohjaamaan sille tai usean virtuaaliportin muodostamalle joukolle kuuluvat paketit perille. Virtuaalipalvelinten liikennettä voidaan hallita Ciscon verkonhallinnan tavallisilla toiminnoilla.
Ciscon ratkaisu ei kelpaa kaikille
Ciscon ja Vmwaren toteutus yllätti markkinat, eikä muita vastaavia ratkaisuja ole juuri esitelty. Kaikki verkkolaitteiden ja virtualisointiohjelmistojen valmistajat eivät tietenkään kehitä omia hallintaratkaisujaan, joten Cisco ja Vmware tarjosivat vntag-tekniikkaansa IEEE:lle yleisen standardin pohjaksi.
Kilpailijat eivät ottaneet ehdotusta avosylin vastaan, vaan halusivat kehittää itselleen paremmin sopivia yleisiä standardeja. Halu vain kasvoi, kun Cisco lähti mukaan palvelinmarkkinoille ucs-arkkitehtuurinsa (unified computing system) myötä.
Perusidea on useimmissa lähestymistavoissa sama. Moni verkonhallinnan ongelma saataisiin ratkaistua helposti, jos virtuaalipalvelinten liikenne kulkisi aina jonkin fyysisen kytkimen kautta. Liikennettä voitaisiin tällöin monitoroida, analysoida ja tilastoida tavanomaisin keinoin. Myös erilaisia tietoturvakäytäntöjä voitaisiin suoraan soveltaa myös virtuaalikoneisiin.
Vebejä tarvittaisiin tämän jälkeen enää fyysisten ja loogisten verkkosovitinten yhdistämiseen. Verkkoliikenne tosin lisääntyisi jonkin verran, kun myös samassa fyysisessä palvelimessa toimivat virtuaalikoneet kommunikoisivat keskenään fyysisen verkon välityksellä. Käytännössä tämä tuskin olisi iso ongelma.
HP luottaa reunakytkimiin
Runkoverkoissa vahva Cisco nojaa keskitettyyn hallintaan. Työasemaverkoissa ja blade-palvelimissa menestynyt HP sen sijaan katsoo, että yksinkertaisin ratkaisu olisi lähettää paketti lähimmälle fyysiselle kytkimelle ja antaa sen palauttaa paketti kohdeosoitteen perusteella samaan fyysiseen porttiin. Tästä toiminnosta käytetään nimitystä vepa (virtual ethernet port aggregator), koska se yhdistää monta virtuaalista porttia samaan fyysiseen ethernet-porttiin.
Kytkin ei kuitenkaan osaa erottaa saman palvelinportin takana olevia virtuaalikoneiden verkkoliitäntöjä toisistaan. Nykyiset reunakytkimet eivät välttämättä salli niin sanottua hiuspinniliikennettä eli paketin lähettämistä takaisin tuloporttiin saman vlanin sisällä. Tarvittava muutos kytkinten ohjelmistoon on onneksi pieni.
Käytännössä törmätään myös niin sanottuun monikanavaongelmaan eli tarpeeseen yhdistää palvelimella erityyppisiä virtuaalisia verkkoliitäntöjä. Yksi virtuaalikone voi käyttää omaa erillistä virtuaaliporttiaan, muutama muu turvaa hypervisorin vebiin ja loput verkkosovittimelle integroituun vepaan.
HP löysi ratkaisun monissa toimistohotellien tai kaupunkialueiden palveluverkoissa käytettävästä standardoidusta Provider Bridge -tekniikasta. Sen avulla palveluntarjoaja voi hallita verkkoaan vlaneina, jotka ovat riippumattomia asiakkaiden omiin verkkoihinsa määrittelemistä vlaneista.
Virtuaaliportit tunnistetaan merkitsemällä paketit svid-tunnisteilla, jotka standardin tunteva reunakytkin osaa käsitellä oikein. Samalla ratkeaa myös joukko teknisiin yksityiskohtiin liittyviä ongelmia.
HP ja Cisco tukijoukkoineen kiistelivät omien ratkaisujensa puolesta pitkään ja näyttävästi. Lopulta IEEE:lle lähti viime vuoden päättyessä kaksi standardointiehdotusta.
HP:n kirjoittama perus-vepa multikanavalaajennuksineen (edge virtual bridging) käsitellään 802.1Qbg-työryhmässä. Sen avoimeksi tukijaksi on jo ilmoittautunut Extreme Networks, ja monet palvelinten, verkkolaitteiden ja virtualisointiohjelmistojen valmistajat suhtautuvat ehdotukseen myötämielisesti.
Ciscon ehdotus (bridge port expansion) taas käsitellään 802.1Qbh-ryhmässä. Siinä mielessä kilpakumppanit pääsivät sopuun, että Cisco on kirjoittanut oman määrityksensä HP:n standardin laajennuksena. HP:n mielestä kun Ciscon vntag-menettely vaatisi aivan liian suuria muutoksia olemassa oleviin kytkimiin.
Lopullisten luonnosten odotetaan valmistuvan vasta ensi vuoden joulukuussa, ja standardien lopulliseksi valmistumisajaksi on merkitty kesäkuu 2012.
