Hyper-V Technische details van netwerkvirtualisatie in Windows Server

Servervirtualisatie maakt het mogelijk om meerdere serverinstanties gelijktijdig op één fysieke host uit te voeren; Toch zijn serverinstanties van elkaar geïsoleerd. Elke virtuele machine werkt in wezen alsof het de enige server is die op de fysieke computer draait.

Netwerkvirtualisatie biedt een vergelijkbare mogelijkheid, waarbij meerdere virtuele netwerken (mogelijk met overlappende IP-adressen) op dezelfde fysieke netwerkinfrastructuur worden uitgevoerd en elk virtueel netwerk werkt alsof het het enige virtuele netwerk is dat op de gedeelde netwerkinfrastructuur wordt uitgevoerd. Figuur 1 laat deze relatie zien.

Figuur 1: Servervirtualisatie versus netwerkvirtualisatie

Hyper-V concepten voor netwerkvirtualisatie

In Hyper-V netwerkvirtualisatie (HNV) wordt een klant of tenant gedefinieerd als de 'eigenaar' van een set IP-subnetten die worden geïmplementeerd in een onderneming of datacenter. Een klant kan een bedrijf of onderneming zijn met meerdere afdelingen of bedrijfseenheden in een privédatacenter die netwerkisolatie vereisen, of een huurder in een openbaar datacenter dat wordt gehost door een serviceprovider. Elke klant kan een of meer virtuele netwerken in het datacenter hebben en elk virtueel netwerk bestaat uit een of meer virtuele subnetten.

Er zijn twee HNV-implementaties die beschikbaar zullen zijn in Windows Server 2016: HNVv1 en HNVv2.

• HNVv1

  HNVv1 is compatibel met Windows Server 2012 R2 en System Center 2012 R2 Virtual Machine Manager (VMM). De configuratie voor HNVv1 is gebaseerd op WMI-beheer en Windows PowerShell-cmdlets (gefaciliteerd via System Center VMM) om isolatie-instellingen en routering te definiëren en toewijzingen en routering van klantadres (CA) - virtueel netwerk - naar fysiek adres (PA). Er zijn geen extra functies toegevoegd aan HNVv1 in Windows Server 2016 en er zijn geen nieuwe functies gepland.

  • SET Teaming en HNV V1 zijn niet compatibel per platform.

  o Om HA NVGRE-gateways te gebruiken, moeten gebruikers LBFO-team of Geen team gebruiken. Or

  o Gebruik Network Controller Deployed gateways met SET teamed switch.

• HNVv2

  Een aanzienlijk aantal nieuwe functies is opgenomen in HNVv2, dat wordt geïmplementeerd met behulp van de Azure Virtual Filtering Platform (VFP) forwarding-extensie in de Hyper-V Switch. HNVv2 is volledig geïntegreerd met Microsoft Azure Stack, die de nieuwe Network Controller in de Software Defined Networking (SDN) Stack bevat. Het beleid voor virtuele netwerken wordt gedefinieerd via de Microsoft-netwerkcontroller met behulp van een RESTful NorthBound (NB) API en is verpruimd naar een hostagent via meerdere SouthBound Interfaces (SBI), waaronder OVSDB. Het beleid van de Host Agent programmeert in de VFP-extensie van de Hyper-V Switch waar het wordt afgedwongen.

  Important

  Dit onderwerp richt zich op HNVv2.

Virtueel netwerk

• Elk virtueel netwerk bestaat uit een of meer virtuele subnetten. Een virtueel netwerk vormt een isolatiegrens waarbij de virtuele machines binnen een virtueel netwerk alleen met elkaar kunnen communiceren. Traditioneel werd deze isolatie afgedwongen met behulp van VLAN's met een gescheiden IP-adresbereik en 802.1q-tag of VLAN-ID. Maar met HNV wordt isolatie afgedwongen met behulp van NVGRE- of VXLAN-inkapseling om overlay-netwerken te creëren met de mogelijkheid van overlappende IP-subnetten tussen klanten of tenants.

• Elk virtueel netwerk heeft een unieke Routing Domain ID (RDID) op de host. Deze RDID wordt ruwweg toegewezen aan een resource-ID om de REST-bron van het virtuele netwerk in de netwerkcontroller te identificeren. Er wordt verwezen naar de REST-resource van het virtuele netwerk met behulp van een URI-naamruimte (Uniform Resource Identifier) met de toegevoegde resource-ID.

Virtuele subnetten

• Een virtueel subnet implementeert de semantiek van het Layer 3 IP-subnet voor de virtuele machines in hetzelfde virtuele subnet. Het virtuele subnet vormt een broadcast-domein (vergelijkbaar met een VLAN) en isolatie wordt afgedwongen met behulp van het veld NVGRE Tenant Network ID (TNI) of VXLAN Network Identifier (VNI).

• Elk virtueel subnet maakt deel uit van één virtueel netwerk (RDID) en krijgt een unieke Virtual Subnet-ID (VSID) toegewezen met behulp van de TNI- of VNI-sleutel in de ingekapselde pakketheader. De VSID moet uniek zijn binnen het datacenter en ligt in het bereik van 4096 tot 2^24-2.

Een belangrijk voordeel van het virtuele netwerk en routeringsdomein is dat het klanten in staat stelt hun eigen netwerktopologieën (bijvoorbeeld IP-subnetten) naar de cloud te brengen. Afbeelding 2 toont een voorbeeld waarbij Contoso Corp twee afzonderlijke netwerken heeft, het R&D-net en het verkoopnet. Omdat deze netwerken verschillende routeringsdomein-id's hebben, kunnen ze niet met elkaar communiceren. Dat wil zeggen dat Contoso R&D Net is geïsoleerd van Contoso Sales Net, ook al zijn beide eigendom van Contoso Corp. Contoso R&D Net bevat drie virtuele subnetten. Houd er rekening mee dat zowel de RDID als de VSID uniek zijn binnen een datacenter.

Figuur 2: Klantennetwerken en virtuele subnetten

Laag 2 doorsturen

In afbeelding 2 kunnen de pakketten van de virtuele machines in VSID 5001 worden doorgestuurd naar virtuele machines die zich ook in VSID 5001 bevinden via de Hyper-V Switch. De binnenkomende pakketten van een virtuele machine in VSID 5001 worden verzonden naar een specifieke VPort op de Hyper-V Switch. Ingress rules (bijvoorbeeld encap) en mappings (bijvoorbeeld encapsulation header) worden toegepast door de Hyper-V Switch voor deze pakketten. De pakketten worden vervolgens doorgestuurd naar een andere VPort op de Hyper-V Switch (als de virtuele doelmachine aan dezelfde host is gekoppeld) of naar een andere Hyper-V switch op een andere host (als de virtuele doelmachine zich op een andere host bevindt).

Laag 3 Routing

Op dezelfde manier kunnen de pakketten van de virtuele machines in VSID 5001 worden gerouteerd naar virtuele machines in VSID 5002 of VSID 5003 door de gedistribueerde HNV-router die aanwezig is in de VSwitch van elke Hyper-V host. Bij het afleveren van het pakket aan de Hyper-V switch, werkt HNV de VSID van het inkomende pakket bij aan de VSID van de virtuele doelmachine. Dit gebeurt alleen als beide VSID's zich in dezelfde RDID bevinden. Daarom kunnen virtuele netwerkadapters met RDID1 geen pakketten verzenden naar virtuele netwerkadapters met RDID2 zonder een gateway te passeren.

Elk virtueel subnet definieert een Layer 3 IP-subnet en een Layer 2 (L2) broadcast-domeingrens die vergelijkbaar is met een VLAN. Wanneer een virtuele machine een pakket uitzendt, gebruikt HNV Unicast-replicatie (UR) om een kopie van het oorspronkelijke pakket te maken en het doel-IP-adres en de MAC te vervangen door de adressen van elke VM die zich in dezelfde VSID bevinden.

De VSID is niet alleen een broadcast-domein, maar zorgt ook voor isolatie. Een virtuele netwerkadapter in HNV is aangesloten op een Hyper-V switchpoort waarop ACL-regels worden toegepast die rechtstreeks op de poort (virtualNetworkInterface REST-bron) of op het virtuele subnet (VSID) worden toegepast waarvan deze deel uitmaakt.

Op de Hyper-V switchpoort moet een ACL-regel zijn toegepast. Deze ACL kan ALLES TOESTAAN, ALLES ONTKENNEN zijn, of specifieker zijn om alleen bepaalde soorten verkeer toe te staan op basis van 5-tuple (Bron-IP, Bestemmings-IP, Bronpoort, Bestemmingspoort, Protocol) matching.

Switching en routering in Hyper-V netwerkvirtualisatie

HNVv2 implementeert de juiste Layer 2 (L2) switching en Layer 3 (L3) routingsemantiek om net zo te werken als een fysieke switch of router zou werken. Wanneer een virtuele machine die is verbonden met een virtueel HNV-netwerk probeert een verbinding tot stand te brengen met een andere virtuele machine in hetzelfde virtuele subnet (VSID), moet deze eerst het CA MAC-adres van de externe virtuele machine leren. Als er een ARP-vermelding voor het IP-adres van de virtuele doelmachine in de ARP-tabel van de virtuele bronmachine staat, wordt het MAC-adres van deze vermelding gebruikt. Als een vermelding niet bestaat, verzendt de virtuele bronmachine een ARP-uitzending met een verzoek om het MAC-adres dat overeenkomt met het IP-adres van de virtuele doelmachine terug te sturen. De Hyper-V Switch onderschept dit verzoek en stuurt het naar de Host Agent. De hostagent zoekt in de lokale database naar een bijbehorend MAC-adres voor het IP-adres van de aangevraagde virtuele doelmachine.

Als er een MAC-adres beschikbaar is, injecteert de hostagent een ARP-respons en stuurt deze terug naar de virtuele machine. Nadat de netwerkstack van de virtuele machine alle vereiste L2-headerinformatie bevat, wordt het frame naar de bijbehorende Hyper-V-poort op de V-Switch gestuurd. Intern test de Hyper-V Switch dit frame aan de hand van N-tuple matching-regels die zijn toegewezen aan de V-Port en past bepaalde transformaties toe op het frame op basis van deze regels. Het belangrijkste is dat een set inkapselingstransformaties wordt toegepast om de inkapselingsheader te construeren met behulp van NVGRE of VXLAN, afhankelijk van het beleid dat is gedefinieerd op de netwerkcontroller. Op basis van het beleid dat door de hostagent is geprogrammeerd, wordt een CA-PA-toewijzing gebruikt om het IP-adres te bepalen van de Hyper-V host waar de virtuele doelmachine zich bevindt. De Hyper-V Switch zorgt ervoor dat de juiste routeringsregels en VLAN-tags worden toegepast op het buitenste pakket, zodat het het externe PA-adres bereikt.

Als een virtuele machine die is verbonden met een virtueel HNV-netwerk een verbinding wil maken met een virtuele machine in een ander virtueel subnet (VSID), moet het pakket dienovereenkomstig worden gerouteerd. HNV gaat uit van een ster-topologie waarbij er slechts één IP-adres in de CA-ruimte is dat wordt gebruikt als de volgende hop om alle IP-voorvoegsels te bereiken (wat betekent dat er één standaardroute/gateway is). Momenteel dwingt dit een beperking af tot één standaardroute en worden niet-standaardroutes niet ondersteund.

Routering tussen virtuele subnetten

In een fysiek netwerk is een IP-subnet een Layer 2 (L2) domein waar computers (virtueel en fysiek) rechtstreeks met elkaar kunnen communiceren. Het L2-domein is een broadcast-domein waar ARP-ingangen (IP:MAC-adrestoewijzing) worden geleerd via ARP-verzoeken die op alle interfaces worden uitgezonden en ARP-antwoorden worden teruggestuurd naar de aanvragende host. De computer gebruikt de MAC-informatie die is geleerd van de ARP-respons om het L2-frame volledig te construeren, inclusief Ethernet-headers. Als een IP-adres zich echter in een ander L3-subnet bevindt, overschrijdt het ARP-verzoek deze L3-grens niet. In plaats daarvan moet een L3-routerinterface (next-hop of standaardgateway) met een IP-adres in het bronsubnet op deze ARP-verzoeken reageren met een eigen MAC-adres.

In standaard Windows-netwerken kan een beheerder statische routes maken en deze toewijzen aan een netwerkinterface. Bovendien wordt een "standaardgateway" meestal geconfigureerd als het IP-adres van de volgende hop op een interface waar pakketten die bestemd zijn voor de standaardroute (0.0.0.0/0) worden verzonden. Pakketten worden naar deze standaardgateway verzonden als er geen specifieke routes bestaan. Dit is meestal de router voor uw fysieke netwerk. HNV maakt gebruik van een ingebouwde router die deel uitmaakt van elke host en een interface heeft in elke VSID om een gedistribueerde router voor het virtuele netwerk of de virtuele netwerken te maken.

Aangezien HNV uitgaat van een stertopologie, fungeert de gedistribueerde HNV-router als één standaardgateway voor al het verkeer dat plaatsvindt tussen virtuele subnetten die deel uitmaken van hetzelfde VSID-netwerk. Het adres dat als standaardgateway wordt gebruikt, is standaard ingesteld op het laagste IP-adres in de VSID en wordt toegewezen aan de gedistribueerde HNV-router. Deze gedistribueerde router zorgt voor een zeer efficiënte manier om al het verkeer binnen een VSID-netwerk op de juiste manier te routeren, omdat elke host het verkeer rechtstreeks naar de juiste host kan routeren zonder dat er een tussenpersoon nodig is. Dit is met name het geval wanneer twee virtuele machines in hetzelfde VM-netwerk, maar verschillende virtuele subnetten, zich op dezelfde fysieke host bevinden. Zoals je verderop in dit gedeelte zult zien, hoeft het pakket nooit de fysieke host te verlaten.

Routering tussen PA-subnetten

In tegenstelling tot HNVv1, dat één PA IP-adres toewees aan elk Virtual Subnet (VSID), gebruikt HNVv2 nu één PA IP-adres per Switch-Embedded Teaming (SET) NIC-teamlid. De standaardimplementatie gaat uit van een team met twee NIC's en wijst twee PA-IP-adressen per host toe. Aan één host zijn PA-IP's toegewezen vanuit hetzelfde logische subnet van de provider (PA) op hetzelfde VLAN. Twee tenant-VM's in hetzelfde virtuele subnet kunnen zich inderdaad op twee verschillende hosts bevinden die zijn verbonden met twee verschillende logische subnetten van de provider. HNV zal de buitenste IP-headers voor het ingekapselde pakket construeren op basis van de CA-PA mapping. Het vertrouwt echter op de host TCP/IP-stack naar ARP voor de standaard PA-gateway en bouwt vervolgens de buitenste Ethernet-headers op basis van de ARP-respons. Meestal komt deze ARP-respons van de SVI-interface op de fysieke switch of L3-router waarop de host is aangesloten. HNV vertrouwt daarom op de L3-router voor het routeren van de ingekapselde pakketten tussen logische subnetten / VLAN's van providers.

Routering buiten een virtueel netwerk

De meeste implementaties bij klanten vereisen communicatie van de HNV-omgeving naar resources die geen deel uitmaken van de HNV-omgeving. Netwerkvirtualisatiegateways zijn vereist om communicatie tussen de twee omgevingen mogelijk te maken. Infrastructuren die een HNV Gateway vereisen, zijn onder meer Private Cloud en Hybrid Cloud. In principe zijn HNV-gateways vereist voor Layer 3-routering tussen interne en externe (fysieke) netwerken (inclusief NAT) of tussen verschillende sites en/of clouds (privé of openbaar) die gebruikmaken van een IPSec VPN- of GRE-tunnel.

Gateways kunnen in verschillende fysieke vormfactoren voorkomen. Ze kunnen worden gebouwd op Windows Server 2016, worden opgenomen in een Top of Rack (TOR)-switch die fungeert als een VXLAN-gateway, toegankelijk zijn via een Virtual IP (VIP) die wordt geadverteerd door een load balancer, in andere bestaande netwerkapparaten worden geplaatst of een nieuw stand-alone netwerkapparaat zijn.

Zie RAS-gateway voor meer informatie over opties voor Windows RAS-gateway.

Pakket inkapseling

Elke virtuele netwerkadapter in HNV is gekoppeld aan twee IP-adressen:

• Klantadres (CA) Het IP-adres dat door de klant is toegewezen, op basis van hun intranetinfrastructuur. Met dit adres kan de klant netwerkverkeer uitwisselen met de virtuele machine alsof het niet naar een publieke of private cloud is verplaatst. De CA is zichtbaar voor de virtuele machine en bereikbaar voor de klant.

• Pa (provideradres ) Het IP-adres dat is toegewezen door de hostingprovider of de datacenterbeheerders op basis van hun fysieke netwerkinfrastructuur. De PA verschijnt in de pakketten op het netwerk die worden uitgewisseld met de server die wordt uitgevoerd Hyper-V die als host fungeert voor de virtuele machine. De PA is zichtbaar op het fysieke netwerk, maar niet op de virtuele machine.

De CA's onderhouden de netwerktopologie van de klant, die wordt gevirtualiseerd en losgekoppeld van de werkelijke onderliggende fysieke netwerktopologie en adressen, zoals geïmplementeerd door de PA's. In het volgende diagram ziet u de conceptuele relatie tussen CA's van virtuele machines en PA's van de netwerkinfrastructuur als gevolg van netwerkvirtualisatie.

Figuur 6: Conceptueel diagram van netwerkvirtualisatie over fysieke infrastructuur

In het diagram verzenden virtuele machines van de klant gegevenspakketten in de CA-ruimte, die de fysieke netwerkinfrastructuur doorkruisen via hun eigen virtuele netwerken of 'tunnels'. In het bovenstaande voorbeeld kunnen de tunnels worden gezien als 'enveloppen' rond de Contoso- en Fabrikam-gegevenspakketten met groene verzendlabels (PA-adressen) die moeten worden bezorgd van de bronhost aan de linkerkant aan de doelhost aan de rechterkant. De sleutel is hoe de hosts de 'verzendadressen' (PA's) bepalen die overeenkomen met de Contoso- en de Fabrikam-CA's, hoe de 'envelop' rond de pakketten wordt geplaatst en hoe de doelhosts de pakketten kunnen uitpakken en correct kunnen leveren aan de virtuele machines van Contoso en Fabrikam.

Deze eenvoudige analogie benadrukte de belangrijkste aspecten van netwerkvirtualisatie:

• Elke CA van een virtuele machine wordt toegewezen aan een fysieke host-PA. Er kunnen meerdere CA's aan dezelfde PA zijn gekoppeld.

• Virtuele machines verzenden gegevenspakketten in de CA-ruimten, die in een "envelop" worden geplaatst met een PA-bron- en doelpaar op basis van de toewijzing.

• De CA-PA toewijzingen moeten de hosts in staat stellen om pakketten te differentiëren voor verschillende virtuele machines van de klant.

Als gevolg hiervan is het mechanisme om het netwerk te virtualiseren het virtualiseren van de netwerkadressen die door de virtuele machines worden gebruikt. De netwerkcontroller is verantwoordelijk voor de adrestoewijzing en de hostagent onderhoudt de toewijzingsdatabase met behulp van het MS_VTEP schema. In de volgende sectie wordt het feitelijke mechanisme van adresvirtualisatie beschreven.

Netwerkvirtualisatie door adresvirtualisatie

HNV implementeert overlay-tenantnetwerken met behulp van Network Virtualization Generic Routing Encapsulation (NVGRE) of het Virtual eXtensible Local Area Network (VXLAN). VXLAN is de standaard.

Virtueel eXtensible Local Area Network (VXLAN)

Het VIRTUAL eXtensible Local Area Network (VXLAN) (RFC 7348)-protocol is op grote schaal gebruikt op de markt, met ondersteuning van leveranciers zoals Cisco, Brocade, Arista, Dell, HP en andere. Het VXLAN-protocol gebruikt UDP als transport. De door IANA toegewezen UDP-bestemmingspoort voor VXLAN is 4789 en de UDP-bronpoort moet een hash zijn van informatie uit het binnenste pakket dat moet worden gebruikt voor ECMP-verspreiding. Na de UDP-header wordt een VXLAN-header aan het pakket toegevoegd met een gereserveerd veld van 4 bytes, gevolgd door een veld van 3 bytes voor de VXLAN Network Identifier (VNI) - VSID - gevolgd door een ander gereserveerd veld van 1 byte. Na de VXLAN-header wordt het originele CA L2-frame (zonder het CA Ethernet-frame FCS) toegevoegd.

Generieke routeringsinkapseling (NVGRE)

Dit netwerkvirtualisatiemechanisme maakt gebruik van de Generic Routing Encapsulation (NVGRE) als onderdeel van de tunnelheader. In NVGRE wordt het pakket van de virtuele machine ingekapseld in een ander pakket. De header van dit nieuwe pakket heeft de juiste bron- en bestemmings-PA-IP-adressen naast de virtuele subnet-ID, die is opgeslagen in het sleutelveld van de GRE-header, zoals weergegeven in afbeelding 7.

Figuur 7: Netwerkvirtualisatie - NVGRE-inkapseling

Met de virtuele subnet-id kunnen hosts de virtuele machine van de klant voor een bepaald pakket identificeren, ook al kunnen de PA's en CA's op de pakketten elkaar overlappen. Hierdoor kunnen alle virtuele machines op dezelfde host één PA delen, zoals weergegeven in afbeelding 7.

Het delen van de PA heeft een grote impact op de schaalbaarheid van het netwerk. Het aantal IP- en MAC-adressen dat door de netwerkinfrastructuur moet worden geleerd, kan aanzienlijk worden verminderd. Als elke eindhost bijvoorbeeld gemiddeld 30 virtuele machines heeft, wordt het aantal IP- en MAC-adressen dat door de netwerkinfrastructuur moet worden geleerd, met een factor 30 verminderd.

Het PA-deelschema voor Windows Server 2012 R2 is één PA per VSID per host. Voor Windows Server 2016 is het schema één PA per NIC-teamlid.

Met Windows Server 2016 en hoger biedt HNV volledige ondersteuning voor NVGRE en VXLAN uit de doos; het vereist GEEN upgrade of aanschaf van nieuwe netwerkhardware zoals NIC's (netwerkadapters), switches of routers. Dit komt omdat deze pakketten op de draad een regulier IP-pakket zijn in de PA-ruimte, dat compatibel is met de huidige netwerkinfrastructuur. Om de beste prestaties te krijgen, gebruikt u echter ondersteunde NIC's met de nieuwste stuurprogramma's die taakoffloads ondersteunen.

Voorbeeld van implementatie met meerdere tenants

In het volgende diagram ziet u een voorbeeldimplementatie van twee klanten in een clouddatacenter met de CA-PA relatie die is gedefinieerd door het netwerkbeleid.

Afbeelding 8: Voorbeeld van multi-tenant implementatie

Beschouw het voorbeeld in Figuur 8. Voordat u overstapt op de gedeelde IaaS-service van de hostingprovider:

• Contoso Corp heeft een SQL Server (met de naam SQL) uitgevoerd op het IP-adres 10.1.1.11 en een webserver (met de naam Web) op het IP-adres 10.1.1.12, dat gebruikmaakt van de SQL Server voor databasetransacties.

• Fabrikam Corp heeft een SQL Server uitgevoerd, ook SQL genoemd en het IP-adres 10.1.1.11, en een webserver, ook web genoemd en ook op het IP-adres 10.1.1.12, dat gebruikmaakt van de SQL Server voor databasetransacties.

We gaan ervan uit dat de hostingserviceprovider eerder het logische netwerk van de provider (PA) heeft gemaakt via de netwerkcontroller om overeen te komen met hun fysieke netwerktopologie. De netwerkcontroller wijst twee PA-IP-adressen toe uit het IP-voorvoegsel van het logische subnet waarop de hosts zijn verbonden. De netwerkcontroller geeft ook de juiste VLAN-tag aan om de IP-adressen toe te passen.

Met behulp van de netwerkcontroller maken Contoso Corp en Fabrikam Corp vervolgens hun virtuele netwerk en subnetten die worden ondersteund door het logische netwerk van de provider (PA) dat is opgegeven door de hostingserviceprovider. Contoso Corp en Fabrikam Corp verplaatsen hun respectieve SQL-servers en webservers naar de gedeelde IaaS-service van dezelfde hostingprovider, waarbij ze toevallig de virtuele SQL-machines uitvoeren op Hyper-V Host 1 en de virtuele MACHINES (IIS7) op Hyper-V Host 2. Alle virtuele machines behouden hun oorspronkelijke intranet-IP-adressen (hun CA's).

Aan beide bedrijven wordt de volgende Virtual Subnet ID (VSID) toegewezen door de netwerkcontroller, zoals hieronder aangegeven. De hostagent op elk van de Hyper-V hosts ontvangt de toegewezen PA-IP-adressen van de netwerkcontroller en maakt twee PA-host-vNIC's in een niet-standaard netwerkcompartiment. Aan elk van deze host vNIC's wordt een netwerkinterface toegewezen waaraan het PA IP-adres wordt toegewezen, zoals hieronder weergegeven:

• Virtuele machines van Contoso Corp VSID en PA's: VSID is 5001, SQL PA is 192.168.1.10, Web PA is 192.168.2.20

• Virtuele machines van Fabrikam Corp VSID en PAs: VSID is 6001, SQL PA is 192.168.1.10, Web PA is 192.168.2.20

De netwerkcontroller loodst al het netwerkbeleid (inclusief CA-PA mapping) naar de SDN-hostagent, die het beleid in een persistente opslag (in OVSDB-databasetabellen) zal onderhouden.

Wanneer de virtuele machine van Contoso Corp Web (10.1.1.12) op Hyper-V host 2 een TCP-verbinding maakt met de SQL Server op 10.1.1.11, gebeurt het volgende:

• VM ARP's voor het MAC-adres van de bestemming 10.1.1.11

• De VFP-extensie in de vSwitch onderschept dit pakket en stuurt het naar de SDN-hostagent

• De SDN-hostagent zoekt in het beleidsarchief naar het MAC-adres voor 10.1.1.11

• Als er een MAC wordt gevonden, injecteert de Host Agent een ARP-respons terug naar de VM

• Als er geen MAC wordt gevonden, wordt er geen antwoord verzonden en wordt de ARP-vermelding in de VM voor 10.1.1.11 gemarkeerd als onbereikbaar.

• De VM bouwt nu een TCP-pakket met de juiste CA Ethernet- en IP-headers en verzendt dit naar de vSwitch

• De VFP-doorstuurextensie in de vSwitch verwerkt dit pakket via de VFP-lagen (hieronder beschreven) die zijn toegewezen aan de bron vSwitch-poort waarop het pakket is ontvangen en creëert een nieuwe flow-entry in de VFP unified flow-tabel

• De VFP-engine voert regelvergelijking of het opzoeken van stroomtabellen uit voor elke laag (bijvoorbeeld virtuele netwerklaag) op basis van de IP- en Ethernet-headers.

• De overeenkomende regel in de virtuele netwerklaag verwijst naar een CA-PA toewijzingsruimte en voert inkapseling uit.

• Het inkapselingstype (VXLAN of NVGRE) wordt gespecificeerd in de VNet-laag, samen met de VSID.

• In het geval van VXLAN-inkapseling wordt een buitenste UDP-header geconstrueerd met de VSID van 5001 in de VXLAN-header. Er wordt een buitenste IP-header geconstrueerd met het bron- en doel-PA-adres dat is toegewezen aan respectievelijk de Hyper-V Host 2 (192.168.2.20) en Hyper-V Host 1 (192.168.1.10) op basis van het beleidsarchief van de SDN-hostagent.

• Dit pakket stroomt vervolgens naar de PA-routeringslaag in VFP.

• De PA-routeringslaag in VFP verwijst naar het netwerkcompartiment dat wordt gebruikt voor PA-ruimteverkeer en een VLAN-ID en gebruikt de TCP/IP-stack van de host om het PA-pakket correct door te sturen naar Hyper-V host 1.

• Na ontvangst van het ingekapselde pakket ontvangt Hyper-V Host 1 het pakket in het PA-netwerkcompartiment en stuurt het door naar de vSwitch.

• De VFP verwerkt het pakket via zijn VFP-lagen en maakt een nieuwe flow-entry in de VFP unified flow-tabel.

• De VFP-engine komt overeen met de ingangsregels in de virtuele netwerklaag en verwijdert de Ethernet-, IP- en VXLAN-headers van het buitenste ingekapselde pakket.

• De VFP-engine stuurt het pakket vervolgens door naar de vSwitch-poort waarop de doel-VM is aangesloten.

Een vergelijkbaar proces voor verkeer tussen de virtuele machines Fabrikam Corp enSQL maakt gebruik van de HNV-beleidsinstellingen voor fabrikam Corp. Als gevolg hiervan communiceren virtuele machines van Fabrikam Corp en Contoso Corp met HNV alsof ze zich op hun oorspronkelijke intranet bevinden. Ze kunnen nooit met elkaar communiceren, ook al gebruiken ze dezelfde IP-adressen.

De afzonderlijke adressen (CA's en PA's), de beleidsinstellingen van de Hyper-V hosts en de adresomzetting tussen de CA en de PA voor binnenkomend en uitgaand verkeer van virtuele machines isoleren deze sets servers met behulp van de NVGRE-sleutel of de VLXAN VNID. Bovendien ontkoppelt de virtualisatietoewijzing en -transformatie de virtuele netwerkarchitectuur van de fysieke netwerkinfrastructuur. Hoewel Contoso SQL en Web en Fabrikam SQL en Web zich bevinden in hun eigen CA IP-subnetten (10.1.1/24), vindt hun fysieke implementatie plaats op twee hosts in verschillende PA-subnetten, respectievelijk 192.168.1/24 en 192.168.2/24. De implicatie is dat cross-subnet virtuele machine provisioning en live migratie mogelijk worden met HNV.

Hyper-V Architectuur voor netwerkvirtualisatie

In Windows Server 2016 wordt HNVv2 geïmplementeerd met behulp van het Azure Virtual Filtering Platform (VFP), een NDIS-filterextensie binnen de Hyper-V Switch. Het belangrijkste concept van VFP is dat van een Match-Action flow-engine met een interne API die wordt blootgesteld aan de SDN-hostagent voor het programmeren van netwerkbeleid. De SDN-hostagent ontvangt zelf netwerkbeleid van de netwerkcontroller via de OVSDB- en WCF SouthBound-communicatiekanalen. Niet alleen wordt virtueel netwerkbeleid (bijvoorbeeld CA-PA mapping) geprogrammeerd met behulp van VFP, maar ook aanvullend beleid zoals ACL's, QoS, enzovoort.

De objecthiërarchie voor de doorstuurextensie vSwitch en VFP is als volgt:

• vSwitch

  • Extern NIC-beheer

  • NIC Hardware Offloads

  • Regels voor wereldwijde expeditie

  • Port

    • Uittredende doorstuurlaag voor haarspelden

    • Ruimtelijsten voor toewijzingen en NAT-pools

    • Uniforme stroomtabel

    • VFP-laag

      • Stroomtabel

      • Group

      • Rule

        • Regels kunnen verwijzen naar spaties

In de VFP wordt een laag gemaakt per beleidstype (bijvoorbeeld Virtual Network) en is een algemene set regel-/stroomtabellen. Het heeft geen intrinsieke functionaliteit totdat specifieke regels aan die laag zijn toegewezen om dergelijke functionaliteit te implementeren. Aan elke laag wordt een prioriteit toegewezen en lagen worden toegewezen aan een poort door middel van oplopende prioriteit. Regels zijn ingedeeld in groepen, voornamelijk op basis van richting en IP-adresfamilie. Groepen krijgen ook een prioriteit toegewezen en maximaal één regel van een groep kan overeenkomen met een bepaalde stroom.

De doorstuurlogica voor de vSwitch met VFP-extensie is als volgt:

• Ingress processing (binnenkomen vanuit het oogpunt van een pakket dat een poort binnenkomt)

• Forwarding

• Verwerking van uitgaand verkeer (uitgaand verkeer vanuit het oogpunt van een pakket dat een poort verlaat)

De VFP ondersteunt interne MAC-forwarding voor NVGRE- en VXLAN-inkapselingstypen, evenals externe MAC VLAN-gebaseerde forwarding.

De VFP-extensie heeft een langzaam pad en een snel pad voor packet traversal. Het eerste pakket in een stroom moet alle regelgroepen in elke laag doorkruisen en een regel opzoeken, wat een dure bewerking is. Zodra een stroom echter is geregistreerd in de uniforme stroomtabel met een lijst met acties (op basis van de overeenkomende regels), worden alle volgende pakketten verwerkt op basis van de vermeldingen in de uniforme stroomtabel.

Het HNV-beleid wordt geprogrammeerd door de hostagent. Elke netwerkadapter van virtuele machines is geconfigureerd met een IPv4-adres. Dit zijn de CA's die door de virtuele machines worden gebruikt om met elkaar te communiceren, en ze worden vervoerd in de IP-pakketten van de virtuele machines. HNV kapselt het CA-frame in een PA-frame op basis van het netwerkvirtualisatiebeleid dat is opgeslagen in de database van de hostagent.

Figuur 9: HNV-architectuur

Summary

Cloudgebaseerde datacenters kunnen veel voordelen bieden, zoals verbeterde schaalbaarheid en een beter gebruik van resources. Om deze potentiële voordelen te realiseren, is een technologie nodig die de problemen van multi-tenant schaalbaarheid in een dynamische omgeving fundamenteel aanpakt. HNV is ontworpen om deze problemen aan te pakken en ook de operationele efficiëntie van het datacenter te verbeteren door de virtuele netwerktopologie los te koppelen van de fysieke netwerktopologie. Voortbouwend op een bestaande standaard, draait HNV in het datacenter van vandaag en werkt het met uw bestaande VXLAN-infrastructuur. Klanten met HNV kunnen nu hun datacenters consolideren in een private cloud of hun datacenters naadloos uitbreiden naar de omgeving van een hostingserverprovider met een hybride cloud.

Zie ook

Voor meer informatie over HNVv2 zie de volgende links: