Dettagli tecnici sulla virtualizzazione di rete Hyper-V in Windows Server

La virtualizzazione dei server consente l'esecuzione contemporanea di più istanze di server, comunque isolate tra di loro, su un unico host fisico. Ogni macchina virtuale, in pratica, opera come se fosse l'unico server in esecuzione sul computer fisico.

Virtualizzazione di rete offre una funzionalità simile, in cui più reti virtuali (potenzialmente con indirizzi IP sovrapposti) eseguite sulla stessa infrastruttura di rete fisica e ogni rete virtuale funziona come se fosse l'unica rete virtuale in esecuzione sull'infrastruttura di rete condivisa. Nella Figura 1 viene mostrata questa relazione.

Figura 1: confronto tra virtualizzazione di server e virtualizzazione di rete

Concetti di Virtualizzazione rete Hyper-V

Nella virtualizzazione di rete Hyper-V (HNV), un cliente o un tenant è definito come il "proprietario" di un insieme di subnet IP distribuite in un'azienda o in un data center. Un cliente può essere una società o organizzazione con più reparti o business unit in un Data Center privato che richiedono l'isolamento della rete o un tenant in un centro dati pubblico che è ospitato da un provider di servizi. Ogni cliente può avere una o più reti virtuali nel data center e ogni rete virtuale è costituita da una o più subnet virtuali.

Esistono due implementazioni di Virtualizzazione che saranno disponibile in Windows Server 2016: HNVv1 e HNVv2.

• HNVv1

  HNVv1 è compatibile con Windows Server 2012 R2 e System Center 2012 R2 Virtual Machine Manager (VMM). La configurazione per HNVv1 si basa sulla gestione WMI e sui cmdlet di Windows PowerShell (resi disponibili tramite System Center VMM) per definire le impostazioni di isolamento e il mapping e l'instradamento tra indirizzo cliente (CA), rete virtuale e indirizzo fisico (PA). Non sono state aggiunte funzionalità aggiuntive a HNVv1 in Windows Server 2016 e non sono previste nuove funzionalità.

  • SET Teaming e HNV V1 non sono compatibili con la piattaforma.

  o Per usare i gateway NVGRE ad alta disponibilità, gli utenti devono usare un team LBFO oppure non usare alcun team. Or

  o Usare i gateway distribuiti del controller di rete con il commutatore con gruppo SET.

• HNVv2

  HNVv2 include un numero significativo di nuove funzionalità ed è implementato usando l'estensione di inoltro della piattaforma di filtro virtuale di Azure (VFP) nello switch Hyper-V. HNVv2 è completamente integrato con Microsoft Azure Stack che include il nuovo Controller di rete nello Stack di rete SDN (Software Defined). I criteri della rete virtuale vengono definiti tramite Microsoft Network Controller usando un'API RESTful NorthBound (NB) e distribuiti a un Host Agent tramite più interfacce SouthBound (SBI), tra cui OVSDB. L'agente host programma il criterio nell'estensione VFP dello switch Hyper-V, dove viene applicato.

  Important

  Questo argomento è incentrato su HNVv2.

Rete virtuale

• Ogni rete virtuale è costituito da uno o più subnet virtuali. Una rete virtuale costituisce un limite di isolamento in cui le macchine virtuali all'interno di una rete virtuale possono comunicare solo tra loro. Tradizionalmente, questo isolamento veniva implementato tramite VLAN con un intervallo di indirizzi IP segregato e tag 802.1q o ID VLAN. Ma con HNV, l’isolamento viene applicato utilizzando l’incapsulamento NVGRE o VXLAN per creare reti di overlay, con la possibilità di sovrapporre sottoreti IP tra clienti o tenant.

• Ogni rete virtuale ha un ID del dominio di instradamento (RDID) univoco sull'host. Questo RDID corrisponde approssimativamente a un ID di risorsa per identificare la rete virtuale risorse REST nel Controller di rete. La risorsa REST della rete virtuale è referenziata utilizzando uno spazio dei nomi Uniform Resource Identifier (URI) con l'ID risorsa aggiunto in appendice.

Subnet virtuali

• Una subnet virtuale implementa la semantica di una subnet IP di livello 3 per le macchine virtuali nella stessa subnet virtuale. La sottorete virtuale costituisce un dominio di broadcast (simile a una VLAN) e l'isolamento viene applicato utilizzando il campo NVGRE Tenant Network ID (TNI) o l'identificatore di rete VXLAN (VNI).

• Ogni subnet virtuale appartiene a una singola rete virtuale (RDID) e a essa viene assegnato un ID di subnet virtuale univoco (VSID) utilizzando la chiave TNI o VNI nell'intestazione del pacchetto incapsulato. Il VSID deve essere univoco all'interno del centro dati ed è compreso nell'intervallo tra 4096 e 2 ^ 24-2.

Un vantaggio fondamentale della rete virtuale e del dominio di routing è che consente ai clienti di portare le proprie topologie di rete (ad esempio, le subnet IP) per il cloud. Nella Figura 2 viene mostrato un esempio in cui la società Contoso dispone di due reti separate: quella per la ricerca e lo sviluppo (R&D) e quella per le vendite. Poiché dispongono di ID di dominio di routing diversi, queste due reti non possono interagire. In altre parole, la rete per la ricerca e lo sviluppo della società Contoso è isolata da quella per le vendite, anche se entrambe sono di proprietà della stessa società. La rete Contoso per la ricerca e lo sviluppo include tre subnet virtuali. Si noti come l'RDID e il VSID siano entrambi univoci all'interno di un centro dati.

Figura 2: reti clienti e subnet virtuali

Inoltro di livello 2

Nella figura 2, le macchine virtuali in VSID 5001 possono avere i propri pacchetti inoltrati a macchine virtuali anch’esse in VSID 5001 tramite lo switch Hyper-V. I pacchetti in ingresso provenienti da una macchina virtuale in VSID 5001 vengono inviati a un VPort specifico del commutatore Hyper-V. Per questi pacchetti, le regole di ingresso (ad esempio incap) e i mapping (ad esempio l'intestazione di incapsulamento) vengono applicati dal commutatore Hyper-V. I pacchetti vengono quindi inoltrati a un diverso VPort nel commutatore Hyper-V (se la macchina virtuale di destinazione è collegata allo stesso host) o a un altro commutatore Hyper-V in un host diverso (se la macchina virtuale di destinazione si trova in un host diverso).

Instradamento di livello 3

Analogamente, le macchine virtuali in VSID 5001 possono avere i propri pacchetti instradati alle macchine virtuali in VSID 5002 o VSID 5003 dal router distribuito HNV presente nel VSwitch di ogni host Hyper-V. Quando il pacchetto viene recapitato allo switch Hyper-V, HNV aggiorna il VSID del pacchetto in ingresso al VSID della macchina virtuale di destinazione. Questo si verifica solo se entrambi i VSID si trovano nello stesso RDID. Di conseguenza, le schede di rete virtuali con RDID1 non possono inviare pacchetti alle schede di rete virtuali con RDID2 senza attraversamento di un gateway.

Ogni subnet virtuale definisce una subnet IP livello 3 e un limite di dominio di trasmissione livello 2 (L2) simile a una VLAN. Quando una macchina virtuale trasmette un pacchetto, HNV utilizza la replicazione unicast (UR) per creare una copia del pacchetto originale e sostituire gli indirizzi IP e MAC di destinazione con quelli di ogni VM che si trova nello stesso VSID.

Oltre a funzionare come dominio broadcast, il VSID garantisce l'isolamento. Una scheda di rete virtuale in HNV è connessa a una porta di uno switch Hyper-V a cui verranno applicate regole ACL direttamente alla porta (risorsa REST virtualNetworkInterface) oppure alla subnet virtuale (VSID) di cui fa parte.

La porta del commutatore Hyper-V deve disporre di una regola ACL applicata. Questa ACL può essere di tipo ALLOW ALL, DENY ALL oppure essere più specifica e consentire solo determinati tipi di traffico in base alla corrispondenza della 5-tupla (IP di origine, IP di destinazione, porta di origine, porta di destinazione, protocollo).

Commutazione e instradamento nella virtualizzazione di rete Hyper-V

HNVv2 implementa le corrette semantiche di commutazione di livello 2 (L2) e di routing di livello 3 (L3), in modo da funzionare esattamente come farebbe uno switch o un router fisico. Quando una macchina virtuale connessa a una rete virtuale HNV tenta di stabilire una connessione con un'altra macchina virtuale nella stessa sottorete virtuale (VSID), dovrà prima apprendere l'indirizzo MAC CA della macchina virtuale remota. Se è presente una voce ARP per l'indirizzo IP della macchina virtuale di destinazione nella tabella ARP della macchina virtuale di origine, viene utilizzato l'indirizzo MAC da questa voce. Se una voce non esiste, la macchina virtuale di origine invierà una richiesta broadcast ARP per ottenere l'indirizzo MAC corrispondente all'indirizzo IP della macchina virtuale di destinazione. Il commutatore Hyper-V intercetterà la richiesta e inviarlo per l'agente Host. L'Host Agent cercherà nel proprio database locale l'indirizzo MAC corrispondente all'indirizzo IP della macchina virtuale di destinazione richiesta.

Se un indirizzo MAC è disponibile, l'agente Host inserisce una risposta ARP e invia nuovamente alla macchina virtuale. Dopo che lo stack di rete della macchina virtuale dispone di tutte le informazioni necessarie sull'intestazione L2, il frame viene inviato alla corrispondente porta Hyper-V sullo switch virtuale. All'interno, lo switch Hyper-V confronta questo frame con le regole di corrispondenza N-tuple assegnate alla V-Port e applica al frame determinate trasformazioni in base a tali regole. Soprattutto, una serie di trasformazioni di incapsulamento viene applicata per costruire l'intestazione di incapsulamento utilizzando NVGRE o VXLAN, a seconda della policy definita nel Controller di rete. In base ai criteri programmato dall'agente Host, un mapping di CA-PA viene utilizzato per determinare l'indirizzo IP dell'host Hyper-V in cui risiede la macchina virtuale di destinazione. Il commutatore Hyper-V assicura le regole di routing corrette e tag VLAN vengono applicate al pacchetto esterno in modo da raggiungere l'indirizzo PA remoto.

Se una macchina virtuale connessa a una rete virtuale HNV vuole stabilire una connessione con una macchina virtuale in una subnet virtuale diversa (VSID), il pacchetto deve essere instradato di conseguenza. HNV presuppone una topologia a stella in cui è presente un unico indirizzo IP nello spazio CA utilizzato come next hop per raggiungere tutti i prefissi IP (ossia un’unica route predefinita o un unico gateway predefinito). Attualmente, ciò impone una limitazione a una sola route predefinita e le route non predefinite non sono supportate.

Routing tra le subnet virtuali

In una rete fisica, una subnet IP è un dominio di livello 2 (L2) in cui i computer (virtuali e fisici) possono comunicare direttamente tra loro. Il dominio L2 è un dominio di broadcast in cui le voci ARP (mappatura tra indirizzo IP e indirizzo MAC) vengono apprese tramite richieste ARP trasmesse su tutte le interfacce, mentre le risposte ARP vengono rimandate all'host richiedente. Il computer utilizza le informazioni di MAC apprese dalla risposta ARP per costruire completamente il frame L2, incluse le intestazioni Ethernet. Tuttavia, se un indirizzo IP si trova in una subnet L3 diversa, la richiesta ARP non attraversa questo confine L3. Al contrario, un'interfaccia di router L3 (hop successivo o il gateway predefinito) con un indirizzo IP della subnet di origine deve rispondere a queste richieste ARP con il proprio indirizzo MAC.

Nella configurazione di rete standard di Windows, un amministratore può creare route statiche e assegnarle a un'interfaccia di rete. Inoltre, un "gateway predefinito" è in genere configurato per essere l'indirizzo IP dell'hop successivo in un'interfaccia in cui vengono inviati i pacchetti destinati per la route predefinita (0.0.0.0/0). I pacchetti vengono inviati a questo gateway predefinito se non esistono alcuna route specifiche. Questo in genere è il router della rete fisica. HNV utilizza un router integrato, presente in ogni host e con un'interfaccia in ogni VSID, per creare un router distribuito per le reti virtuali.

Poiché virtualizzazione RETE prevede una topologia a stella, il router di virtualizzazione RETE distribuito funge da gateway predefinito solo per tutto il traffico tra subnet virtuali che fanno parte della stessa rete VSID. L'indirizzo utilizzato come gateway predefinito corrisponde per impostazione predefinita all'indirizzo IP più basso nel VSID e viene assegnato al router distribuito HNV. Il router distribuito consente un modo molto efficiente per tutto il traffico all'interno di una rete VSID da indirizzare in modo appropriato, poiché ogni host può instradare direttamente il traffico all'host appropriato senza intermediari. Questo è valido soprattutto quando due macchine virtuali della stessa rete VM ma di subnet virtuali diverse si trovano nello stesso host fisico. Come è possibile osservare più avanti in questa sezione, il pacchetto non deve mai uscire dall'host fisico.

Routing tra le sottoreti PA

A differenza di HNVv1, che allocava un indirizzo IP PA per ogni subnet virtuale (VSID), HNVv2 ora utilizza un indirizzo IP PA per ogni membro del team NIC Switch-Embedded Teaming (SET). La distribuzione predefinita prevede un team con due NIC e assegna due indirizzi IP PA per host. Un singolo host ha indirizzi IP PA assegnati dalla stessa subnet logica del Provider (PA) sulla stessa VLAN. Due VM tenant nella stessa subnet virtuale possono effettivamente trovarsi su due host diversi collegati a due subnet logiche del provider diverse. HNV costruirà le intestazioni IP esterne per il pacchetto incapsulato in base alla mappatura CA-PA. Tuttavia, si affida allo stack TCP/IP dell'host per eseguire l'ARP per il gateway PA predefinito e quindi costruisce le intestazioni Ethernet esterne in base alla risposta ARP. In genere, questa risposta ARP proviene dall'interfaccia SVI sul commutatore fisico o L3 router in cui l'host è connesso. HNV si basa quindi sul router L3 per instradare i pacchetti incapsulati tra le subnet logiche del provider / VLAN.

Routing all'esterno di una rete virtuale

La maggior parte delle distribuzioni dei clienti richiede la comunicazione tra l'ambiente di Virtualizzazione rete Hyper-V e risorse che non fanno parte di tale ambiente. Per consentire la comunicazione tra questi due ambienti sono dunque necessari gateway di virtualizzazione rete. Infrastrutture che richiedono un Gateway di virtualizzazione RETE includono Cloud privato e Cloud ibrido. In pratica, i gateway HNV sono necessari per il routing di livello 3 tra reti interne ed esterne (fisiche), incluso il NAT, oppure tra siti diversi e/o cloud privati o pubblici che utilizzano una VPN IPSec o un tunnel GRE.

I gateway sono disponibili in diversi fattori di forma fisici. Possono essere basati su Windows Server 2016, incorporati in uno switch Top of Rack (TOR) che funge da gateway VXLAN, accessibili tramite un IP virtuale (VIP) pubblicizzato da un servizio di bilanciamento del carico, inseriti in altri dispositivi di rete esistenti oppure costituire un nuovo dispositivo di rete autonomo.

Per altre informazioni sulle opzioni del gateway RAS di Windows, vedere Gateway RAS.

Incapsulamento dei pacchetti

Ogni scheda di rete virtuale in HNV è associata a due indirizzi IP:

• Indirizzo cliente (CA) L'indirizzo IP assegnato dal cliente, in base all'infrastruttura Intranet. Questo indirizzo consente agli utenti di scambiare il traffico di rete con la macchina virtuale come se non è stato spostato in un cloud pubblico o privato. L'indirizzo CA è visibile alla macchina virtuale e raggiungibile dal cliente.

• Indirizzo provider (PA) L'indirizzo IP assegnato dal provider di hosting o dagli amministratori del data center in base all'infrastruttura di rete fisica. L'indirizzo PA compare nei pacchetti sulla rete che vengono scambiati con il server che esegue Hyper-V e che ospita la macchina virtuale. La PA è visibile sulla rete fisica, ma non per la macchina virtuale.

I CAs mantengono la topologia di rete del cliente, che è virtualizzata e disaccoppiata dalla topologia e dagli indirizzi della rete fisica sottostante effettiva, come implementato dai PAs. Nel diagramma seguente viene mostrata la relazione concettuale esistente tra gli indirizzi CA della macchina virtuale e gli indirizzi PA dell'infrastruttura di rete in conseguenza della virtualizzazione di rete.

Figura 6: Diagramma concettuale della virtualizzazione di rete su infrastruttura fisica

Nel diagramma, le macchine virtuali dei clienti inviano pacchetti di dati nello spazio CA, che attraversano l'infrastruttura di rete fisica tramite le proprie reti virtuali, o "tunnel". Nell'esempio precedente, i tunnel possono essere considerati come "buste" che avvolgono i pacchetti di dati Contoso e Fabrikam con etichette di spedizione verdi (gli indirizzi PA) per essere recapitati all'host di destinazione a destra dall'host di origine a sinistra. La chiave è capire come gli host determinano gli "indirizzi di spedizione" (PA) corrispondenti ai CA di Contoso e Fabrikam, come i pacchetti vengono inseriti nella "busta" e come gli host di destinazione possono rimuovere l'incapsulamento dei pacchetti e recapitarli correttamente alle macchine virtuali di destinazione di Contoso e Fabrikam.

Questa semplice analogia sottolinea gli aspetti essenziali della virtualizzazione di rete:

• L'indirizzo CA di ciascuna macchina virtuale è mappato all'indirizzo PA di un host fisico. Possono esserci più CA associate alla stessa PA.

• Le macchine virtuali inviano pacchetti di dati negli spazi di indirizzi CA, che vengono inseriti in una "busta" con una coppia di indirizzi PA di origine e destinazione in base alla mappatura.

• Le mappature degli indirizzi CA-PA devono consentire agli host di distinguere tra i pacchetti per diverse macchine virtuali dei clienti.

Di conseguenza, il meccanismo per virtualizzare la rete consiste nella virtualizzazione degli indirizzi di rete utilizzati dalle macchine virtuali. Il controller di rete è responsabile per il mapping degli indirizzi e l'agente host mantiene il database di mapping utilizzando lo schema MS_VTEP. Nella sezione successiva vengono descritti i meccanismi effettivi di virtualizzazione degli indirizzi.

Virtualizzazione di rete attraverso la virtualizzazione degli indirizzi

HNV implementa reti overlay tenant utilizzando Network Virtualization Generic Routing Encapsulation (NVGRE) o Virtual eXtensible Local Area Network (VXLAN). VXLAN è il valore predefinito.

Rete locale virtuale estensibile (VXLAN)

Il protocollo Virtual eXtensible Local Area Network (VXLAN) (RFC 7348) è stato ampiamente adottato nel mercato, con il supporto di fornitori come Cisco, Brocade, Arista, Dell, HP e altri. Il protocollo VXLAN utilizza il protocollo UDP come trasporto. La porta di destinazione UDP assegnata da IANA per VXLAN è 4789 e la porta di origine UDP deve essere un hash di informazioni del pacchetto interno da usare per la distribuzione ECMP. Dopo l'intestazione UDP, al pacchetto viene aggiunta un'intestazione VXLAN che include un campo riservato di 4 byte, seguito da un campo di 3 byte per il VXLAN Network Identifier (VNI) - VSID -, seguito da un altro campo riservato di 1 byte. Dopo l'intestazione VXLAN, viene aggiunto il frame L2 CA originale (senza frame Ethernet CA FCS).

Incapsulamento di Routing Generico (NVGRE)

Questo meccanismo di virtualizzazione di rete utilizza Generic Routing Encapsulation (NVGRE) come parte dell'intestazione del tunnel. In NVGRE, pacchetto della macchina virtuale viene incapsulato all'interno di un altro pacchetto. L'intestazione del nuovo pacchetto così ottenuto contiene gli indirizzi IP PA di origine e di destinazione appropriati, oltre all'ID subnet virtuale memorizzato nel campo chiave dell'intestazione GRE, come illustrato nella Figura 7.

Figura 7: virtualizzazione di rete - Incapsulamento NVGRE

L'ID della subnet virtuale consente agli host di identificare la macchina virtuale del cliente per ogni dato pacchetto, anche se i PA e i CA nei pacchetti possono sovrapporsi. In questo modo, tutte le macchine virtuali presenti nello stesso host possono condividere un unico indirizzo PA, come illustrato nella Figura 7.

La condivisione del PA ha un forte impatto sulla scalabilità della rete. perché consente di ridurre drasticamente il numero di indirizzi IP e MAC che l'infrastruttura di rete deve apprendere. Ad esempio, se gli host presenti a ciascuna estremità della rete hanno in media 30 macchine virtuali, il numero degli indirizzi IP e MAC che l'infrastruttura di rete deve apprendere si riduce di un fattore 30. Anche gli ID subnet virtuale incorporati semplificano l'associazione dei pacchetti ai clienti effettivi.

Lo schema di condivisione PA per Windows Server 2012 R2 prevede un PA per VSID per host. In Windows Server 2016 lo schema prevede un indirizzo PA per ciascun membro del team NIC.

Con Windows Server 2016 e versioni successive, HNV supporta completamente NVGRE e VXLAN in modo nativo; NON richiede l'aggiornamento né l'acquisto di nuovo hardware di rete, ad esempio NIC (schede di rete), switch o router. Questo perché i pacchetti che transitano sulla rete sono normali pacchetti IP nello spazio degli indirizzi PA, compatibili con le attuali infrastrutture di rete. Tuttavia, per ottenere le migliori prestazioni, utilizzare NIC supportate con i driver più recenti che supportano le funzionalità di offload.

esempio di distribuzione multi-tenant

Il diagramma seguente mostra un esempio di distribuzione di due clienti situati in un data center cloud con la relazione CA-PA definita dai criteri di rete.

Figura 8: esempio di distribuzione multi-tenant

Osservare l'esempio della Figura 8. Prima dello spostamento nel servizio IaaS condiviso del provider di servizi di hosting:

• Contoso Corp ha eseguito un'istanza di SQL Server (denominata SQL) nell'indirizzo IP 10.1.1.11 e un server Web (denominato Web) all'indirizzo IP 10.1.1.12, che usa sql Server per le transazioni di database.

• Fabrikam Corp disponeva di un server SQL Server, denominato anch'esso SQL e con indirizzo IP 10.1.1.11, e di un server Web, denominato anch'esso Web e con indirizzo IP 10.1.1.12, che usa il relativo server SQL Server per le transazioni del database.

Si presuppone che il provider di servizi di hosting ha creato in precedenza la rete logica provider (PA) tramite il Controller di rete in modo che corrispondano alla loro topologia di rete fisica. Il controller di rete alloca due indirizzi IP PA dal prefisso IP della subnet logica a cui sono connessi gli host. Il controller di rete indica inoltre il tag VLAN appropriato per applicare gli indirizzi IP.

Utilizzando il controller di rete, Contoso Corp e Fabrikam Corp creano quindi la propria rete virtuale e le subnet, supportate dalla rete logica del provider (PA) specificata dal provider di servizi di hosting. Contoso Corp e Fabrikam Corp spostano i rispettivi server SQL e server Web nello stesso servizio IaaS condiviso del provider di hosting in cui, per coincidenza, eseguono le macchine virtuali SQL in Hyper-V Host 1 e le macchine virtuali Web (IIS7) in Hyper-V Host 2. Tutte le macchine virtuali mantengono gli indirizzi IP Intranet originali (i propri indirizzi CA).

Entrambe le società vengono assegnate il seguente ID Subnet virtuale (VSID) dal Controller di rete come indicato di seguito. L'agente host in ciascun host Hyper-V riceve dal Controller di rete gli indirizzi IP PA allocati e crea due vNIC host PA in un comparto di rete non predefinito. Un'interfaccia di rete viene assegnata a ciascuno di questi vNICs host in cui l'indirizzo IP PA viene assegnato come illustrato di seguito:

• Macchine virtuali di Contoso VSID e PA: VSID è 5001, SQL PA è 192.168.1.10, PA Web è 192.168.2.20

• Le macchine virtuali di Fabrikam Corp VSID e PA: VSID è 6001, SQL PA è 192.168.1.10, Web PA è 192.168.2.20

Il controller di rete propaga tutte le policy di rete (inclusa la mappatura CA-PA) all'SDN Host Agent, che manterrà la policy in un archivio persistente (nelle tabelle del database OVSDB).

Quando la macchina virtuale Web di Contoso (10.1.1.12) su Hyper-V Host 2 crea una connessione TCP a SQL Server all'indirizzo 10.1.1.11, si verifica quanto segue:

• La VM effettua una richiesta ARP per l'indirizzo MAC di destinazione 10.1.1.11

• L'estensione VFP di vSwitch intercetta il pacchetto e lo invia all'agente Host SDN

• L'agente host SDN cerca nell'archivio dei criteri l'indirizzo MAC di 10.1.1.11

• Se viene rilevato un MAC, l'Host Agent invia una risposta ARP alla macchina virtuale

• Se non viene trovato un MAC, non viene inviata alcuna risposta e la voce ARP nella VM relativa a 10.1.1.11 viene contrassegnata come non raggiungibile.

• La macchina Virtuale ora costruisce un pacchetto TCP con le intestazioni di CA Ethernet e indirizzo IP corrette e lo invia il vSwitch

• L’estensione di inoltro VFP nello vSwitch elabora questo pacchetto attraverso i livelli VFP (descritti di seguito) assegnati alla porta di origine dello vSwitch sulla quale il pacchetto è stato ricevuto e crea una nuova voce di flusso nella tabella di flusso unificata di VFP

• Il motore VFP esegue la corrispondenza delle regole o la ricerca nella tabella di flusso per ciascun livello (ad esempio il livello di rete virtuale) in base alle intestazioni IP ed Ethernet.

• La regola corrispondente nel livello di rete virtuale fa riferimento a uno spazio di mapping CA-PA ed esegue l'incapsulamento.

• Il tipo di incapsulamento (VXLAN o NVGRE) è specificato nel livello di rete virtuale con il VSID.

• Nel caso dell'incapsulamento VXLAN, viene creata un'intestazione UDP esterna con il VSID 5001 nell'intestazione VXLAN. Viene creata un'intestazione IP esterna con gli indirizzi PA di origine e di destinazione assegnati rispettivamente a Hyper-V Host 2 (192.168.2.20) e Hyper-V Host 1 (192.168.1.10), in base all'archivio dei criteri dell'agente host SDN.

• Questo pacchetto viene quindi trasmesso al livello di routing PA in VFP.

• Il livello di routing PA in VFP farà riferimento al compartimento di rete utilizzato per il traffico dello spazio PA e a un ID VLAN, e utilizzerà lo stack TCP/IP dell'host per inoltrare correttamente il pacchetto PA a Hyper-V Host 1.

• Alla ricezione del pacchetto incapsulato, Hyper-V Host 1 riceve il pacchetto nel compartimento di rete PA e lo inoltra al vSwitch.

• VFP elabora il pacchetto attraverso i propri livelli VFP e crea una nuova voce nella tabella di flusso unificata VFP.

• Il motore VFP trova corrispondenza con le regole di ingresso a livello di rete virtuale e rimuove le intestazioni Ethernet, IP e VXLAN del pacchetto esterno incapsulato.

• Il motore VFP inoltra quindi il pacchetto alla porta vSwitch a cui è connessa la macchina Virtuale di destinazione.

Un processo simile per il traffico tra le macchine virtuali Web e SQL di Fabrikam Corp utilizza le impostazioni dei criteri HNV di Fabrikam Corp. Di conseguenza, con HNV, le macchine virtuali di Fabrikam Corp e Contoso Corp interagiscono come se fossero sulle rispettive intranet originali. Non possono mai interagire tra di loro, anche se utilizzano gli stessi indirizzi IP.

Gli indirizzi separati (CA e PA), le impostazioni dei criteri degli host Hyper-V e la conversione degli indirizzi tra la CA e PA per il traffico di macchina virtuale in ingresso e in uscita isolano questi insiemi di server con la chiave NVGRE o il VNID VLXAN. Inoltre, le mappature e la trasformazione della virtualizzazione disaccoppiano l'architettura di rete virtuale dall'infrastruttura di rete fisica. Sebbene Contoso SQL e Web e Fabrikam SQL e Web si trovino nelle proprie subnet IP DELLA CA (10.1.1/24), la distribuzione fisica avviene in due host in subnet PA diverse, rispettivamente 192.168.1/24 e 192.168.2/24. L’implicazione è che con la virtualizzazione di rete Hyper-V il provisioning delle macchine virtuali tra subnet e la migrazione live diventano possibili.

Architettura di Virtualizzazione rete Hyper-V

In Windows Server 2016, HNVv2 è implementato tramite la piattaforma di filtro virtuale di Azure (VFP), che è un'estensione di filtro NDIS all'interno dello switch Hyper-V. Il concetto chiave di VFP è quello di un motore di flusso Match-Action con un'API interna esposta a SDN Host Agent per programmare i criteri di rete. L'agente Host SDN stesso riceve i criteri di rete dal Controller di rete attraverso i canali di comunicazione WCF SouthBound e OVSDB. Non solo i criteri di rete virtuale (ad esempio la mappatura CA-PA) vengono programmati tramite VFP, ma anche criteri aggiuntivi come ACL, QoS e così via.

La gerarchia degli oggetti per il vSwitch e l'estensione di inoltro VFP è la seguente:

• vSwitch

  • Gestione NIC esterna

  • Offload hardware della scheda di rete

  • Regole di inoltro globale

  • Port

    • Livello di inoltro in uscita per hairpinning

    • Elenchi di spazio per i mapping e i pool di NAT

    • Tabella di flusso unificato

    • Livello VFP

      • Tabella di flusso

      • Group

      • Rule

        • Le regole possono fare riferimento a spazi

Nel VFP, viene creato un livello per ogni tipo di criterio, ad esempio Rete virtuale, e costituisce un insieme generico di tabelle di regole/flussi. Non presenta alcuna funzionalità intrinseche fino a quando le regole specifiche vengono assegnate a tale livello per implementare tali funzionalità. Ogni livello viene assegnata una priorità e i livelli vengono assegnati a una porta dall'ordine crescente di priorità. Le regole sono organizzate in gruppi basati principalmente su direzione e famiglia di indirizzi IP. I gruppi sono inoltre assegnati una priorità e al massimo una regola da un gruppo può corrispondere a un determinato flusso.

La logica di inoltro per vSwitch con estensione VFP è come segue:

• Elaborazione in ingresso (dal punto di vista del pacchetto che entra in una porta)

• Forwarding

• Elaborazione di uscita (uscita dal punto di vista di un pacchetto che lascia una porta)

Il VFP supporta l'inoltro MAC interno per i tipi di incapsulamento NVGRE e VXLAN, nonché l'inoltro basato su VLAN MAC esterne.

L'estensione VFP dispone di un percorso lento e di uno rapido per l'inoltro dei pacchetti. Il primo pacchetto in un flusso deve attraversare tutti i gruppi di regole in ogni livello ed eseguire una regola di ricerca che è un'operazione dispendiosa. Tuttavia, dopo aver registrato un flusso della tabella di flusso unificata con un elenco di azioni (in base alle regole di corrispondenza) tutti i pacchetti successivi verranno elaborati in base alle voci della tabella di flusso unificato.

La policy HNV è programmata dall'agente host. Ogni scheda di rete della macchina virtuale è configurata con un indirizzo IPv4. Si tratta degli indirizzi CA che verranno utilizzati dalle macchine virtuali per comunicare tra di loro e sono trasportati nei pacchetti IP provenienti dalle macchine virtuali. HNV incapsula il frame CA in un frame PA in base ai criteri di virtualizzazione della rete archiviati nel database dell'agente host.

Figura 9: Architettura HNV

Summary

I centri dati basati su cloud possono offrire diversi vantaggi, come una migliore scalabilità e un utilizzo ottimale delle risorse. Lo sfruttamento di questi potenziali vantaggi richiede una tecnologia in grado soprattutto di affrontare i problemi posti dalla scalabilità multi-tenant in un ambiente dinamico. La funzionalità Virtualizzazione rete Hyper-V è stata progettata per ovviare a questi problemi e per migliorare inoltre l'efficienza operativa del centro dati disaccoppiando la topologia della rete virtuale da quella della rete fisica. Basandosi su uno standard esistente, HNV viene eseguito negli attuali data center e funziona con l'infrastruttura VXLAN esistente. I clienti con HNV possono ora consolidare i propri data center in un cloud privato oppure estenderli senza soluzione di continuità all'ambiente di un provider di hosting con un cloud ibrido.

Vedere anche

Per ulteriori informazioni su HNVv2 vedere i collegamenti seguenti: