Hyper-V Teknisk information om nätverksvirtualisering i Windows Server

Med servervirtualisering kan flera serverinstanser köras samtidigt på en enda fysisk värd. men serverinstanser är isolerade från varandra. Varje virtuell dator fungerar i princip som om det är den enda servern som körs på den fysiska datorn.

Nätverksvirtualisering ger en liknande funktion, där flera virtuella nätverk (eventuellt med överlappande IP-adresser) körs på samma fysiska nätverksinfrastruktur och varje virtuellt nätverk fungerar som om det är det enda virtuella nätverket som körs på den delade nätverksinfrastrukturen. Bild 1 visar den här relationen.

Bild 1: Servervirtualisering jämfört med nätverksvirtualisering

Hyper-V begrepp för nätverksvirtualisering

I Hyper-V Nätverksvirtualisering (HNV) definieras en kund eller klientorganisation som "ägare" av en uppsättning IP-undernät som distribueras i ett företag eller datacenter. En kund kan vara ett företag eller ett företag med flera avdelningar eller affärsenheter i ett privat datacenter som kräver nätverksisolering eller en klientorganisation i ett offentligt datacenter som hanteras av en tjänstleverantör. Varje kund kan ha ett eller flera virtuella nätverk i datacentret och varje virtuellt nätverk består av ett eller flera virtuella undernät.

Det finns två HNV-implementeringar som kommer att vara tillgängliga i Windows Server 2016: HNVv1 och HNVv2.

• HNVv1

  HNVv1 är kompatibelt med Windows Server 2012 R2 och System Center 2012 R2 Virtual Machine Manager (VMM). Konfigurationen för HNVv1 förlitar sig på hantering via WMI och Windows PowerShell-cmdletar (underlättas genom System Center VMM) för att definiera isoleringsinställningar samt mappningar från kundadress (CA) i virtuella nätverk till fysisk adress (PA) och routning. Inga ytterligare funktioner har lagts till i HNVv1 i Windows Server 2016 och inga nya funktioner planeras.

  • SET Teaming och HNV V1 är inte kompatibla med plattformen.

  o För att använda HA NVGRE-gatewayer måste användarna antingen använda LBFO-teamet eller ingen grupp. Or

  o Använd distribuerade nätverksstyrenhetsgatewayer med teamindelade SET-switchar.

• HNVv2

  Ett stort antal nya funktioner ingår i HNVv2 som implementeras med hjälp av tillägget för vidarebefordran av Azure Virtual Filtering Platform (VFP) i Hyper-V Switch. HNVv2 är helt integrerat med Microsoft Azure Stack som innehåller den nya nätverksstyrenheten i SDN-stacken (Software Defined Networking). Principen för virtuellt nätverk definieras via Microsofts nätverksstyrenhet med hjälp av ett RESTful NorthBound-API (NB) och skickas till en värdagent via flera SouthBound Interfaces (SBI) inklusive OVSDB. Den värdagent som programmerar policyn i VFP-förlängningen för Hyper-V Switch där den verkställs.

  Important

  Det här avsnittet fokuserar på HNVv2.

Virtuellt nätverk

• Varje virtuellt nätverk består av ett eller flera virtuella undernät. Ett virtuellt nätverk utgör en isoleringsgräns där de virtuella datorerna i ett virtuellt nätverk bara kan kommunicera med varandra. Traditionellt tillämpades den här isoleringen med hjälp av VLAN med ett separat IP-adressintervall och 802.1q-tagg eller VLAN-ID. Men med HNV framtvingas isolering med NVGRE- eller VXLAN-inkapsling för att skapa överläggsnätverk där IP-undernät kan överlappa mellan kunder eller hyresgäster.

• Varje virtuellt nätverk har ett unikt routningsdomän-ID (RDID) på värden. Detta RDID mappar ungefär till ett resurs-ID för att identifiera rest-resursen för det virtuella nätverket i nätverksstyrenheten. REST-resursen för det virtuella nätverket refereras till med hjälp av ett URI-namnområde (Uniform Resource Identifier) med det bifogade resurs-ID:t.

Virtuella undernät

• Ett virtuellt undernät implementerar Ip-undernätets semantik för Layer 3 för de virtuella datorerna i samma virtuella undernät. Det virtuella undernätet utgör en sändningsdomän (liknar ett VLAN) och isoleringen framtvingas med hjälp av antingen NVGRE-klientnätverks-ID (TNI) eller VXLAN-nätverksidentifierare (VNI).

• Varje virtuellt undernät tillhör ett enda virtuellt nätverk (RDID) och tilldelas ett unikt virtuellt undernäts-ID (VSID) med antingen TNI- eller VNI-nyckeln i det inkapslade pakethuvudet. VSID måste vara unikt i datacentret och ligger i intervallet 4096 till 2^24-2.

En viktig fördel med det virtuella nätverket och routningsdomänen är att det gör att kunderna kan ta med sina egna nätverkstopologier (till exempel IP-undernät) till molnet. Bild 2 visar ett exempel där Contoso Corp har två separata nätverk, R&D Net och Sales Net. Eftersom dessa nätverk har olika routningsdomän-ID:er kan de inte interagera med varandra. Contoso R&D Net är isolerat från Contoso Sales Net trots att båda ägs av Contoso Corp. Contoso R&D Net innehåller tre virtuella undernät. Observera att både RDID och VSID är unika i ett datacenter.

Bild 2: Kundnätverk och virtuella undernät

Lager 2 överföring

I bild 2 kan de virtuella datorerna i VSID 5001 få sina paket vidarebefordrade till virtuella datorer som också finns i VSID 5001 via Hyper-V Switch. Inkommande paket från en virtuell dator i VSID 5001 skickas till en specifik VPort på Hyper-V Switch. Ingressregler (till exempel inkapsling) och mappningar (till exempel inkapslingshuvud) tillämpas av Hyper-V-switchen för dessa paket. Paketen vidarebefordras sedan antingen till en annan VPort på Hyper-V Switch (om den virtuella måldatorn är ansluten till samma värd) eller till en annan Hyper-V växla på en annan värd (om den virtuella måldatorn finns på en annan värd).

Layer 3-routning

På samma sätt kan de virtuella datorerna i VSID 5001 få sina paket routade till virtuella datorer i VSID 5002 eller VSID 5003 av den HNV-distribuerade routern som finns på varje Hyper-V värds VSwitch. När paketet levereras till växeln Hyper-V uppdaterar HNV VSID för det inkommande paketet till VSID för den virtuella måldatorn. Detta inträffar bara om båda VSID:erna finns i samma RDID. Därför kan virtuella nätverkskort med RDID1 inte skicka paket till virtuella nätverkskort med RDID2 utan att passera en gateway.

Note

I beskrivningen av paketflödet ovan betyder termen "virtuell dator" faktiskt det virtuella nätverkskortet på den virtuella datorn. Det vanliga är att en virtuell dator bara har ett enda virtuellt nätverkskort. I det här fallet kan orden "virtuell dator" och "virtuellt nätverkskort" konceptuellt betyda samma sak.

Varje virtuellt undernät definierar ett Layer 3 IP-undernät och en layer 2-sändningsdomängräns (L2) som liknar en VLAN. När en virtuell dator sänder ett paket använder HNV Unicast Replication (UR) för att göra en kopia av det ursprungliga paketet och ersätta mål-IP och MAC med adresserna för varje virtuell dator som finns i samma VSID.

Note

När Windows Server 2016 levereras kommer multicasts för broadcast och subnät att implementeras med hjälp av unicast-replikering. Multicast-routning mellan undernät och IGMP stöds inte.

Förutom att vara en sändningsdomän tillhandahåller VSID isolering. Ett virtuellt nätverkskort i HNV är anslutet till en Hyper-V växelport som har ACL-regler som tillämpas antingen direkt på porten (virtualNetworkInterface REST-resursen) eller på det virtuella undernät (VSID) som det är en del av.

Växelporten för Hyper-V måste ha en ACL-regel tillämpad. Den här ACL:en kan vara ALLOW ALL, DENY ALL eller vara mer specifik för att endast tillåta vissa typer av trafik baserat på matchning med 5 tuppler (käll-IP, mål-IP, källport, målport, protokoll).

Note

Hyper-V Switch Extensions fungerar inte med HNVv2 i den nya SDN-stacken (Software Defined Networking). HNVv2 implementeras med växeltillägget Azure Virtual Filtering Platform (VFP) som inte kan användas tillsammans med andra växeltillägg från tredje part.

Växla och routning i Hyper-V nätverksvirtualisering

HNVv2 implementerar korrekt Layer 2-växling (L2) och Layer 3-routningssemantik (L3) för att fungera precis som en fysisk växel eller router skulle fungera. När en virtuell dator som är ansluten till ett virtuellt HNV-nätverk försöker upprätta en anslutning till en annan virtuell dator i samma virtuella undernät (VSID) måste den först lära sig CA MAC-adressen för den virtuella fjärrdatorn. Om det finns en ARP-post för den virtuella måldatorns IP-adress i den virtuella källdatorns ARP-tabell används MAC-adressen från den här posten. Om det inte finns någon post skickar den virtuella källdatorn en ARP-sändning med en begäran om att få tillbaka MAC-adressen som motsvarar IP-adressen för den virtuella måldatorn. Hyper-V Switch avlyssnar den här begäran och skickar den till värdagent. Värdagenten söker i sin lokala databas efter en motsvarande MAC-adress för den begärda virtuella måldatorns IP-adress.

Note

Värdagenten, som fungerar som OVSDB-server, använder en variant av VTEP-schemat för att lagra CA-PA mappningar, MAC-tabell och så vidare.

Om en MAC-adress är tillgänglig matar värdagenten in ett ARP-svar och skickar tillbaka det till den virtuella datorn. När den virtuella datorns nätverksstack har all nödvändig L2-rubrikinformation skickas ramen till motsvarande Hyper-V port på V-Växeln. Internt testar Hyper-V Switch den här ramen mot matchningsregler för N-tuppel som tilldelats V-porten och tillämpar vissa transformeringar på ramen baserat på dessa regler. Viktigast av allt är att en uppsättning inkapslingsomvandlingar tillämpas för att konstruera inkapslingshuvudet med antingen NVGRE eller VXLAN, beroende på den princip som definierats på nätverksstyrenheten. Baserat på den princip som programmeras av värdagenten används en CA-PA mappning för att fastställa IP-adressen för den Hyper-V värd där den virtuella måldatorn finns. Hyper-V Switch säkerställer att rätt routningsregler och VLAN-taggar tillämpas på det yttre paketet så att det når den fjärranslutna PA-adressen.

Om en virtuell dator som är ansluten till ett virtuellt HNV-nätverk vill skapa en anslutning med en virtuell dator i ett annat virtuellt undernät (VSID) måste paketet dirigeras i enlighet med detta. HNV förutsätter en stjärntopologi där det bara finns en IP-adress i ca-utrymmet som används som nästa hopp för att nå alla IP-prefix (vilket innebär en standardväg/gateway). För närvarande framtvingar detta en begränsning för en enda standardväg och icke-standardvägar stöds inte.

Routning mellan virtuella undernät

I ett fysiskt nätverk är ett IP-undernät en Layer 2-domän (L2) där datorer (virtuella och fysiska) kan kommunicera direkt med varandra. L2-domänen är en sändningsdomän där ARP-poster (IP:MAC-adresskarta) hämtas via ARP-begäranden som sänds i alla gränssnitt och ARP-svar skickas tillbaka till den begärande värden. Datorn använder MAC-informationen som lärts från ARP-svaret för att helt konstruera L2-ramen, inklusive Ethernet-huvuden. Men om en IP-adress finns i ett annat L3-undernät går ARP-begäran inte över den här L3-gränsen. I stället måste ett L3-routergränssnitt (nästa hopp eller standardgateway) med en IP-adress i källundernätet svara på dessa ARP-begäranden med en egen MAC-adress.

I standardnätverk i Windows kan en administratör skapa statiska vägar och tilldela dem till ett nätverksgränssnitt. Dessutom är en "standardgateway" vanligtvis konfigurerad för att vara nästa hopps IP-adress i ett gränssnitt där paket som är avsedda för standardvägen (0.0.0.0/0) skickas. Paket skickas till den här standardgatewayen om det inte finns några specifika vägar. Detta är vanligtvis routern för ditt fysiska nätverk. HNV använder en inbyggd router som ingår i varje värd och har ett gränssnitt i varje VSID för att skapa en distribuerad router för de virtuella nätverken.

Eftersom HNV förutsätter en stjärntopologi fungerar den HNV-distribuerade routern som en enda standardgateway för all trafik som går mellan virtuella undernät som ingår i samma VSID-nätverk. Den adress som används som standardgateway är som standard den lägsta IP-adressen i VSID och tilldelas till den distribuerade HNV-routern. Den här distribuerade routern möjliggör ett mycket effektivt sätt för all trafik i ett VSID-nätverk att dirigeras korrekt eftersom varje värd direkt kan dirigera trafiken till rätt värd utan att behöva en mellanhand. Detta gäller särskilt när två virtuella datorer i samma virtuella datornätverk men olika virtuella undernät finns på samma fysiska värd. Som du ser senare i det här avsnittet behöver paketet aldrig lämna värddatorn.

Routning mellan PA-undernät

Till skillnad från HNVv1 som allokerade en PA IP-adress för varje virtuellt undernät (VSID) använder HNVv2 nu en PA IP-adress per Switch-Embedded Teaming (SET) NIC-teammedlem. Standarddistributionen förutsätter ett två-NIC-team och tilldelar två PA IP-adresser per värd. En enskild värd har PA-IP-adresser tilldelade från samma logiska undernät för Provider (PA) på samma VLAN. Två virtuella klientdatorer i samma virtuella undernät kan faktiskt finnas på två olika värdar som är anslutna till två olika logiska providerundernät. HNV konstruerar de yttre IP-huvudena för det inkapslade paketet baserat på CA-PA mappning. Den förlitar sig dock på värdens TCP/IP-stack till ARP för standard-PA-gatewayen och skapar sedan de yttre Ethernet-huvudena baserat på ARP-svaret. Vanligtvis kommer det här ARP-svaret från SVI-gränssnittet där värd är ansluten, på den fysiska växeln eller L3-routern. HNV förlitar sig därför på L3-routern för att dirigera de inkapslade paketen mellan providerns logiska undernät/VLAN.

Routning utanför ett virtuellt nätverk

De flesta kunddistributioner kräver kommunikation från HNV-miljön till resurser som inte ingår i HNV-miljön. Nätverksvirtualiseringsgatewayer krävs för att tillåta kommunikation mellan de två miljöerna. Infrastrukturer som kräver en HNV-gateway är privata moln och hybridmoln. I grund och botten krävs HNV-gatewayer för Layer 3-routning mellan interna och externa (fysiska) nätverk (inklusive NAT) eller mellan olika platser och/eller moln (privata eller offentliga) som använder en IPSec VPN- eller GRE-tunnel.

Gatewayer kan komma i olika fysiska formfaktorer. De kan byggas på Windows Server 2016, införlivas i en TOR-växel (Top of Rack) som fungerar som en VXLAN-gateway, nås via en virtuell IP-adress (VIP) som annonseras av en lastbalanserare, placeras i andra befintliga nätverksinstallationer eller kan vara en ny fristående nätverksinstallation.

Mer information om alternativ för Windows RAS Gateway finns i RAS Gateway.

Paketsammankapsling

Varje virtuellt nätverkskort i HNV är associerat med två IP-adresser:

• Kundadress (CA) DEN IP-adress som tilldelats av kunden, baserat på deras intranätinfrastruktur. Med den här adressen kan kunden utbyta nätverkstrafik med den virtuella datorn som om den inte hade flyttats till ett offentligt eller privat moln. Ca:en är synlig för den virtuella datorn och kan nås av kunden.

• Provideradress (PA) IP-adressen som tilldelats av värdleverantören eller datacenteradministratörerna baserat på deras fysiska nätverksinfrastruktur. PA visas i nätverkspaketen som utbyts med den server som kör Hyper-V och är värd för den virtuella datorn. PA är synligt i det fysiska nätverket, men inte för den virtuella datorn.

CA:erna underhåller kundens nätverkstopologi, som virtualiseras och frikopplas från den faktiska underliggande fysiska nätverkstopologin och adresserna, som implementeras av PA:erna. Följande diagram visar den konceptuella relationen mellan certifikatutfärdare för virtuella datorer och nätverksinfrastruktur-PA:er som ett resultat av nätverksvirtualisering.

Bild 6: Konceptuellt diagram över nätverksvirtualisering över fysisk infrastruktur

I diagrammet skickar virtuella kunddatorer datapaket i CA-utrymmet, som passerar den fysiska nätverksinfrastrukturen via sina egna virtuella nätverk eller "tunnlar". I exemplet ovan kan tunnlarna betraktas som "kuvert" runt Contoso- och Fabrikam-datapaketen med gröna leveransetiketter (PA-adresser) som ska levereras från källvärden till vänster till målvärden till höger. Nyckeln är hur värdarna fastställer de "leveransadresserna" (PA:er) som motsvarar Contoso och Fabrikams CA:er, hur "kuvertet" placeras runt paketen och hur målvärdarna kan packa upp paketen och leverera dem korrekt till Contosos och Fabrikams virtuella måldatorer.

Den här enkla analogi markerade de viktigaste aspekterna av nätverksvirtualisering:

• Varje CA för virtuella maskiner mappas till en fysisk värd PA. Det kan finnas flera certifikatutfärdare som är associerade med samma pa.

• Virtuella datorer skickar datapaket i CA-utrymmen, som placeras i ett "kuvert" med en PA-källa och ett destinationspar baserat på mappningen.

• CA-PA-mappningarna måste göra det möjligt för värdarna att särskilja paket för olika virtuella kunddatorer.

Därför är mekanismen för att virtualisera nätverket att virtualisera de nätverksadresser som används av de virtuella datorerna. Nätverksstyrenheten ansvarar för adressmappningen och värdagenten underhåller mappningsdatabasen med hjälp av MS_VTEP schema. I nästa avsnitt beskrivs den faktiska mekanismen för adressvirtualisering.

Nätverksvirtualisering via adressvirtualisering

HNV implementerar överläggsklientnätverk med hjälp av antingen NVGRE (Network Virtualization Generic Routing Encapsulation) eller VXTensible Local Area Network (VXLAN). VXLAN är standardvärdet.

VXLAN (Virtual eXtensible Local Area Network)

Protokollet Virtual eXtensible Local Area Network (VXLAN) (RFC 7348) har antagits i stor utsträckning på marknaden, med stöd från leverantörer som Cisco, Brocade, Arista, Dell, HP och andra. VXLAN-protokollet använder UDP som transport. Den IANA-tilldelade UDP-målporten för VXLAN är 4789 och UDP-källporten bör vara en hash av information från det inre paketet som ska användas för ECMP-spridning. Efter UDP-huvudet läggs ett VXLAN-huvud till i paketet som innehåller ett reserverat fält med 4 byte följt av ett fält med 3 byte för VXLAN Network Identifier (VNI) – VSID – följt av ett annat reserverat fält med 1 byte. Efter VXLAN-huvudet läggs den ursprungliga CA L2-ramen (utan CA Ethernet-ramen FCS) till.

Generic Routing Encapsulation (Allmän inkapsling av routning) (NVGRE)

Den här nätverksvirtualiseringsmekanismen använder NVGRE (Generic Routing Encapsulation) som en del av tunnelhuvudet. I NVGRE kapslas den virtuella datorns paket in i ett annat paket. Huvudet för det nya paketet har lämpliga IP-adresser för käll- och destination-PA utöver det virtuella undernätets ID, som lagras i Nyckelfältet i GRE-huvudet, enligt bild 7.

Bild 7: Nätverksvirtualisering – NVGRE-inkapsling

Med det virtuella undernäts-ID:t kan värdar identifiera kundens virtuella dator för ett visst paket, även om PA:erna och CA:erna på paketen kan överlappa varandra. Detta gör att alla virtuella datorer på samma värd kan dela en enda PA, som visas i bild 7.

Delning av PA har stor inverkan på nätverkets skalbarhet. Antalet IP- och MAC-adresser som behöver läras av nätverksinfrastrukturen kan minskas avsevärt. Om varje slutvärd till exempel har i genomsnitt 30 virtuella datorer minskas antalet IP- och MAC-adresser som behöver läras av nätverksinfrastrukturen med en faktor på 30.De inbäddade virtuella undernäts-ID:n i paketen möjliggör också enkel korrelation av paket till de faktiska kunderna.

PA-delningsschemat för Windows Server 2012 R2 är en PA per VSID per värd. För Windows Server 2016 är schemat en PA per NIC-gruppmedlem.

Med Windows Server 2016 och senare har HNV fullt stöd för NVGRE och VXLAN. Det kräver INTE uppgradering eller inköp av ny nätverksmaskinvara, till exempel nätverkskort, växlar eller routrar. Detta beror på att dessa paket på kabeln är vanliga IP-paket i PA-utrymmet, vilket är kompatibelt med dagens nätverksinfrastruktur. Men för att få bästa prestanda kan du använda nätverkskort som stöds med de senaste drivrutinerna som stöder avlastningar av uppgifter.

Exempel på flertenant-distribution

Följande diagram visar ett exempel på distribution av två kunder som finns i ett molndatacenter med den CA-PA relation som definieras av nätverksprinciperna.

Bild 8: Exempel på installation av multiklientmiljö

Tänk på exemplet i bild 8. Innan du flyttar till värdleverantörens delade IaaS-tjänst:

• Contoso Corp körde en SQL Server (med namnet SQL) på IP-adressen 10.1.1.11 och en webbserver (med namnet Web) på IP-adressen 10.1.1.12, som använder sin SQL Server för databastransaktioner.

• Fabrikam Corp körde en SQL Server med namnet SQL och tilldelade IP-adressen 10.1.1.11 och en webbserver med namnet Web och även på IP-adressen 10.1.1.12 som använder sin SQL Server för databastransaktioner.

Vi förutsätter att värdtjänstleverantören tidigare har skapat det logiska providernätverket (PA) via nätverksstyrenheten för att motsvara deras fysiska nätverkstopologi. Nätverksstyrenheten allokerar två PA IP-adresser från det logiska undernätets IP-prefix där värdarna är anslutna. Nätverksstyrenheten anger också lämplig VLAN-tagg för att tillämpa IP-adresserna.

Med hjälp av nätverksstyrenheten skapar Contoso Corp och Fabrikam Corp sedan sina virtuella nätverk och undernät som backas upp av det logiska providernätverket (PA) som anges av värdtjänstleverantören. Contoso Corp och Fabrikam Corp flyttar sina respektive SQL-servrar och webbservrar till samma värdleverantörs delade IaaS-tjänst där de av en tillfällighet kör de virtuella SQL-datorerna på Hyper-V värd 1 och webben (IIS7) på Hyper-V Värd 2. Alla virtuella datorer har sina ursprungliga IP-adresser för intranätet (deras certifikatutfärdare).

Båda företagen tilldelas följande virtuella undernäts-ID (VSID) av nätverksstyrenheten enligt nedan. Värdagenten på var och en av de Hyper-V värdarna tar emot de tilldelade PA IP-adresserna från Nätverkskontrollanten och skapar två PA-host vNICs i en nätverksavdelning som inte är standard. Ett nätverksgränssnitt tilldelas var och en av dessa värd-VNICs där PA IP-adressen tilldelas enligt nedan:

• Contoso Corps virtuella datorer VSID och PA: VSID är 5001, SQL PA är 192.168.1.10, Web PA är 192.168.2.20

• Fabrikam Corps virtuella datorer VSID och PA: VSID är 6001, SQL PA är 192.168.1.10, Webb-PA är 192.168.2.20

Nätverksstyrenheten distribuerar alla nätverkspolicyer (inklusive CA-PA-mappning) till SDN-värdagenten som ansvarar för att lagra policyn i ett beständigt lagringsutrymme (i OVSDB-databastabeller).

När den virtuella Contoso Corp Web-datorn (10.1.1.12) på Hyper-V Värd 2 skapar en TCP-anslutning till SQL Server på 10.1.1.11 händer följande:

• VM-ARP:er för mac-måladressen 10.1.1.11

• VFP-tillägget i vSwitch fångar upp det här paketet och skickar det till SDN-värdagenten

• SDN Host Agent letar i sitt policy-lager efter MAC-adressen för 10.1.1.11

• Om en MAC hittas matar värdagenten in ett ARP-svar tillbaka till den virtuella datorn

• Om en MAC inte hittas skickas inget svar och ARP-posten i den virtuella datorn för 10.1.1.11 har markerats som oåtkomlig.

• Den virtuella datorn skapar nu ett TCP-paket med rätt CA Ethernet- och IP-huvuden och skickar det till vSwitch

• VFP-vidarebefordran i vSwitch bearbetar det här paketet via VFP-lagren (beskrivs nedan) som tilldelats den vSwitch-källport där paketet togs emot och skapar en ny flödespost i VFP-tabellen för enhetligt flöde

• VFP-motorn utför regelmatchning eller flödestabellsökning för varje lager (till exempel virtuellt nätverkslager) baserat på IP- och Ethernet-huvudena.

• Den matchade regeln i det virtuella nätverksskiktet refererar till ett CA-PA mappningsutrymme och utför inkapsling.

• Inkapslingstypen (antingen VXLAN eller NVGRE) anges i VNet-lagret tillsammans med VSID.

• När det gäller VXLAN-inkapsling skapas en yttre UDP-rubrik med VSID 5001 i VXLAN-huvudet. Ett yttre IP-huvud konstrueras med hjälp av den käll-PA-adressen och mål-PA-adressen som tilldelats Hyper-V Värd 2 (192.168.2.20) och Hyper-V Värd 1 (192.168.1.10) baserat på SDN-värdagentens policyarkiv.

• Det här paketet flödar sedan till PA-routningsskiktet i VFP.

• PA-routningslagret i VFP refererar till nätverksfacket som används för PA-space-trafik och ett VLAN-ID, och använder värdens TCP/IP-stack för att korrekt vidarebefordra PA-paketet till Hyper-V Värd 1.

• När det inkapslade paketet tas emot tar Hyper-V värd 1 emot paketet i PA-nätverksfacket och vidarebefordrar det till vSwitch.

• VFP bearbetar paketet genom sina VFP-lager och skapar en ny flödespost i den enhetliga VFP-flödestabellen.

• VFP-motorn matchar ingångsreglerna i det virtuella nätverksskiktet och tar bort det yttre inkapslade paketets Ethernet-, IP- och VXLAN-huvuden.

• VFP-motorn vidarebefordrar sedan paketet till den vSwitch-port som den virtuella måldatorn är ansluten till.

En liknande process för trafik mellan fabrikam Corp Web och virtuella SQL-datorer använder HNV-principinställningarna för Fabrikam Corp. Därför interagerar virtuella datorer med HNV, Fabrikam Corp och Contoso Corp som om de vore på sina ursprungliga intranät. De kan aldrig interagera med varandra, även om de använder samma IP-adresser.

De separata adresserna (CA och PA), policyinställningarna för Hyper-V-värdarna och adressöversättningen mellan CA och PA för inkommande och utgående trafik på virtuella maskiner isolerar dessa servrar med hjälp av antingen NVGRE-nyckeln eller VXLAN VNID. Dessutom frikopplar virtualiseringsmappningar och transformering den virtuella nätverksarkitekturen från den fysiska nätverksinfrastrukturen. Även om Contoso SQL och Web och Fabrikam SQL och Web finns i sina egna CA IP-undernät (10.1.1/24), sker deras fysiska distribution på två värdar i olika PA-undernät, 192.168.1/24 respektive 192.168.2/24. Implikationen är att etablering av virtuella datorer mellan undernät och direktmigrering blir möjliga med HNV.

Hyper-V Arkitektur för nätverksvirtualisering

I Windows Server 2016 implementeras HNVv2 med hjälp av Azure Virtual Filtering Platform (VFP) som är ett NDIS-filtreringstillägg i Hyper-V Switch. Huvudkonceptet med VFP är en Match-Action flödeshanteringsmotor med ett internt API som exponeras för SDN-värdagenten för att programmera nätverkspolicy. Själva SDN-värdagenten tar emot en nätverksprincip från nätverksstyrenheten via kommunikationskanalerna OVSDB och WCF SouthBound. Den virtuella nätverksprincipen (till exempel CA-PA mappning) programmeras inte bara med hjälp av VFP utan även ytterligare principer som ACL:er, QoS och så vidare.

Objekthierarkin för vSwitch- och VFP-vidarebefordran är följande:

• vSwitch

  • Extern NIC-hantering

  • NIC-maskinvarulaster

  • Regler för global vidarebefordran

  • Port

    • Utgående vidarebefordrande lager för hårfästning

    • Utrymmeslistor för mappningar och NAT-pooler

    • Enhetlig flödestabell

    • VFP-skikt

      • Flödestabell

      • Group

      • Rule

        • Regler kan referera till områden

I VFP skapas ett lager per principtyp (till exempel virtuellt nätverk) och är en allmän uppsättning regel-/flödestabeller. Den har inga inbyggda funktioner förrän specifika regler har tilldelats det lagret för att implementera sådana funktioner. Varje lager tilldelas en prioritet, och lager fördelas till en port i stigande prioritetsordning. Regler är ordnade i grupper baserat främst på riktning och IP-adressfamilj. Grupper tilldelas också en prioritet och som mest kan en regel från en grupp matcha ett visst flöde.

Vidarebefordringslogik för vSwitch med VFP-tillägget är följande:

• Inkommande bearbetning (ingress från perspektivet för paket som kommer till en port)

• Forwarding

• Utgående bearbetning (utgående från perspektivet för paket som lämnar en port)

VFP stöder inre MAC-vidarebefordran för NVGRE- och VXLAN-inkapslingstyper samt yttre MAC VLAN-baserad vidarebefordran.

VFP-tillägget har en långsam sökväg och snabb sökväg för paketbläddering. Det första paketet i ett flöde måste passera alla regelgrupper i varje lager och göra en regelsökning som är en dyr åtgärd. Men när ett flöde har registrerats i den enhetliga flödestabellen med en lista över åtgärder (baserat på de regler som matchas) bearbetas alla efterföljande paket baserat på poster i tabellen för enhetligt flöde.

HNV-principen programmeras av värdagenten. Varje virtuell dators nätverkskort konfigureras med en IPv4-adress. Det här är de certifikatutfärdare som används av de virtuella maskinerna för att kommunicera med varandra, och de transporteras i IP-paketen från de virtuella maskinerna. HNV kapslar in CA-ramen i en PA-ram baserat på nätverksvirtualiseringsprinciperna som lagras i värdagentens databas.

Bild 9: HNV-arkitektur

Summary

Molnbaserade datacenter kan ge många fördelar, till exempel förbättrad skalbarhet och bättre resursanvändning. För att kunna utnyttja dessa potentiella fördelar krävs en teknik som i grunden löser problemen med skalbarhet för flera klientorganisationer i en dynamisk miljö. HNV har utformats för att åtgärda dessa problem och även förbättra datacentrets driftseffektivitet genom att ta bort den virtuella nätverkstopologin för den fysiska nätverkstopologin. HNV bygger på en befintlig standard och körs i dagens datacenter och fungerar med din befintliga VXLAN-infrastruktur. Kunder med HNV kan nu konsolidera sina datacenter till ett privat moln eller sömlöst utöka sina datacenter till en värdserverleverantörs miljö med ett hybridmoln.

Se även

Mer information om HNVv2 finns i följande länkar:

Innehållstyp	References
Community-resurser	- Blogg om arkitektur för privat moln – Ställ frågor: cloudnetfb@microsoft.com
RFC	- NVGRE RFC-utkast - VXLAN – RFC 7348
Relaterade tekniker	– Teknisk information om Hyper-V nätverksvirtualisering i Windows Server 2012 R2 finns i teknisk information omHyper-V nätverksvirtualisering - Nätverksstyrenhet