Détails techniques sur la virtualisation de réseau Hyper-V dans Windows Server

La virtualisation de serveur permet à plusieurs instances de serveur de s’exécuter simultanément sur un seul hôte physique. Pourtant, les instances de serveur sont isolées les unes par rapport aux autres. En substance, chaque ordinateur virtuel fonctionne comme s’il s’agissait du seul serveur à s’exécuter sur l’ordinateur physique.

La virtualisation de réseau offre des possibilités similaires, le principe étant que plusieurs réseau virtuels (avec éventuellement des chevauchements d’adresses IP) s’exécutent sur une même infrastructure de réseau physique et chaque réseau virtuel fonctionne comme s’il s’agissait du seul réseau virtuel à s’exécuter sur l’infrastructure réseau partagée. La figure 1 illustre cette relation.

Figure 1: virtualisation de serveur comparée à la virtualisation de réseau

Principes de la virtualisation de réseau Hyper-V

Dans la virtualisation de réseau Hyper-V (HNV), un client ou un locataire est défini comme le « propriétaire » d’un ensemble de sous-réseaux IP déployés dans une entreprise ou un centre de données. Un client peut être une société ou une entreprise avec plusieurs services ou unités commerciales dans un centre de données privé qui nécessitent une isolation réseau, ou un locataire dans un centre de données public hébergé par un fournisseur de services. Chaque client peut disposer d’un ou de plusieurs Réseaux virtuels dans le centre de données et chaque réseau virtuels se compose d’un ou de plusieurs Sous-réseaux virtuels.

Il existe deux implémentations HNV qui seront disponibles dans Windows Server 2016 : HNVv1 et HNVv2.

• HNVv1

  HNVv1 est compatible avec Windows Server 2012 R2 et System Center 2012 R2 Virtual Machine Manager (VMM). La configuration de HNVv1 s’appuie sur la gestion WMI et les applets de commande Windows PowerShell (facilitées par System Center VMM) pour définir les paramètres d’isolation et les mappages et routage de l’adresse client (CA) - réseau virtuel - vers les adresses physiques (PA). Aucune fonctionnalité supplémentaire n’a été ajoutée à HNVv1 dans Windows Server 2016 et aucune nouvelle fonctionnalité n’est planifiée.

  • SET Teaming et HNV V1 ne sont pas compatibles par plateforme.

  o Pour utiliser des passerelles NVGRE HA, les utilisateurs doivent utiliser l’équipe LBFO ou Aucune équipe. ou

  o Utilisez les passerelles déployées par le contrôleur de réseau avec le commutateur SET associé.

• HNVv2

  Un nombre important de nouvelles fonctionnalités sont incluses dans HNVv2, qui est implémenté à l’aide de l’extension de transfert VFP (Azure Virtual Filtering Platform) dans le commutateur Hyper-V. HNVv2 est entièrement intégré à Microsoft Azure Stack, qui inclut le nouveau Contrôleur de réseau dans la pile SDN (Software Defined Networking). La stratégie de réseau virtuel est définie via le Contrôleur de réseau Microsoft à l’aide d’une API RESTful NorthBound (NB) et transférée à un agent hôte via plusieurs interfaces SouthBound (SBI), y compris OVSDB. L’agent hôte programme la stratégie dans l’extension VFP du commutateur Hyper-V où elle est appliquée.

  Important

  Cette rubrique traite de HNVv2.

Réseau virtuel

• Chaque réseau virtuel se compose d’un ou plusieurs sous-réseaux virtuels. Un réseau virtuel forme une limite d’isolation où les machines virtuelles au sein d’un réseau virtuel ne peuvent communiquer qu’entre elles. Traditionnellement, cette isolation était appliquée à l’aide de réseaux locaux virtuels avec une plage d’adresses IP séparée et une balise 802.1q ou un ID de réseau local virtuel. Toutefois, avec HNV, l’isolation est appliquée à l’aide de l’encapsulation NVGRE ou VXLAN pour créer des réseaux de superposition avec la possibilité de chevaucher des sous-réseaux IP entre des clients ou des locataires.

• Chaque réseau virtuel a un ID de domaine de routage (RDID) unique sur l’hôte. Ce RDID correspond approximativement à un ID de ressource pour identifier la ressource REST de réseau virtuel dans le contrôleur de réseau. La ressource REST de réseau virtuel est référencée à l’aide d’un espace de noms URI (Uniform Resource Identifier) avec l’ID de ressource ajouté.

Sous-réseaux virtuels

• Un sous-réseau virtuel implémente la sémantique de sous-réseau IP de couche 3 pour les ordinateurs virtuels qui font partie d’un même sous-réseau virtuel. Le sous-réseau virtuel forme un domaine de diffusion (similaire à un VLAN) et l’isolation est appliquée à l’aide du champ TNI (ID réseau de locataire NVGRE) ou VNI (VXLAN Network Identifier).

• Chaque sous-réseau virtuel appartient à un seul réseau virtuel (RDID) et un ID de sous-réseau virtuel (VSID) unique est attribué à l’aide de la clé TNI ou VNI dans l’en-tête de paquet encapsulé. Le VSID doit être unique au sein du centre de données et est compris dans une plage allant de 4096 à 2^24-2.

L’un des principaux avantages du réseau virtuel et du domaine de routage est qu’il permet aux clients d’apporter leurs propres topologies de réseau (par exemple, des sous-réseaux IP) dans le cloud. La figure 2 montre un exemple dans lequel Contoso Corp possède deux réseaux distincts : le réseau Recherche et développement (« R&D Net ») et le réseau commercial (« Sales Net »). Comme ces réseaux ont des ID de domaine de routage différents, ils ne peuvent pas interagir ensemble. Autrement dit, le réseau R&D Net Contoso est isolé du réseau Sales Net Contoso, alors même que les deux appartiennent à Contoso Corp. Le réseau R&D Net Contoso contient trois sous-réseaux virtuels. Notez que les RDID et VSID sont uniques au sein d’un centre de données.

Figure 2 : réseaux client et sous-réseaux virtuels

Transfert de couche 2

Dans la figure 2, les paquets des machines virtuelles dans VSID 5001 peuvent être transférés aux machines virtuelles qui se trouvent également dans VSID 5001 via le commutateur Hyper-V. Les paquets entrants d’une machine virtuelle dans VSID 5001 sont envoyés à un VPort spécifique sur le commutateur Hyper-V. Les règles d’entrée (par exemple, encaps) et les mappages (par exemple, l’en-tête d’encapsulation) sont appliqués par le commutateur Hyper-V pour ces paquets. Les paquets sont ensuite transférés vers un autre VPort sur le commutateur Hyper-V (si la machine virtuelle de destination est attachée au même hôte) ou vers un commutateur Hyper-V différent sur un autre hôte (si la machine virtuelle de destination se trouve sur un autre hôte).

Routage de couche 3

De même, les paquets des machines virtuelles dans VSID 5001 peuvent être acheminés vers des machines virtuelles dans VSID 5002 ou VSID 5003 par le routeur distribué HNV qui est présent dans le commutateur virtuel de chaque hôte Hyper-V. Lors de la remise du paquet au commutateur Hyper-V, HNV met à jour le VSID du paquet entrant par rapport au VSID de l’ordinateur virtuel de destination. Cela ne se produit que si les deux VSID se trouvent dans le même RDID. Par conséquent, les cartes réseau virtuelles associés à RDID1 ne peuvent pas envoyer de paquets aux cartes réseau virtuelles associées à RDID2 sans traverser une passerelle.

Chaque sous-réseau virtuel définit un sous-réseau IP de couche 3 et une limite de domaine de diffusion de couche 2 similaire à un VLAN. Lorsqu’une machine virtuelle diffuse un paquet, HNV utilise la réplication de monodiffusion (UR) pour effectuer une copie du paquet d’origine et remplacer l’adresse IP et le MAC de destination par les adresses de chaque machine virtuelle qui se trouvent dans le même VSID.

En plus d’être un domaine de diffusion, le VSID assure une isolation. Une carte réseau virtuelle dans HNV est connectée à un port de commutateur Hyper-V dont les règles de liste de contrôle d’accès sont appliquées directement au port (ressource REST virtualNetworkInterface) ou au sous-réseau virtuel (VSID) dont elle fait partie.

Une règle ACL doit être appliquée au port du commutateur Hyper-V. Cette liste de contrôle d’accès peut être ALLOW ALL, DENY ALL ou être plus spécifique pour autoriser uniquement certains types de trafic en fonction de la correspondance à 5 tuples (Adresse IP source, Adresse IP de destination, port source, port de destination, protocole).

Passage et routage dans la virtualisation de réseau Hyper-V

HNVv2 implémente la commutation de couche 2 (L2) et la sémantique de routage de couche 3 correctes (L3) pour fonctionner comme un commutateur physique ou un routeur fonctionne. Lorsqu’une machine virtuelle connectée à un réseau virtuel HNV tente d’établir une connexion avec une autre machine virtuelle dans le même sous-réseau virtuel (VSID), elle doit d’abord connaître l’adresse MAC de l’autorité de certification de la machine virtuelle distante. S’il existe une entrée ARP pour l’adresse IP de la machine virtuelle de destination dans la table ARP de la machine virtuelle source, l’adresse MAC de cette entrée est utilisée. Si aucune entrée n’existe, la machine virtuelle source envoie une diffusion ARP avec une demande de retour de l’adresse MAC correspondant à l’adresse IP de la machine virtuelle de destination. Le commutateur Hyper-V intercepte cette requête et l’envoie à l’agent hôte. L’agent hôte recherche dans sa base de données locale une adresse MAC correspondante pour l’adresse IP de la machine virtuelle de destination demandée.

Si une adresse MAC est disponible, l’agent hôte injecte une réponse ARP et la renvoie à la machine virtuelle. Une fois que la pile réseau de la machine virtuelle contient toutes les informations d’en-tête L2 requises, la trame est envoyée au port Hyper-V correspondant sur le commutateur virtuel. En interne, le commutateur Hyper-V teste cette trame par rapport aux règles de correspondance de N-tuple affectées au V-Port et applique certaines transformations au frame en fonction de ces règles. Plus important encore, un ensemble de transformations d’encapsulation est appliqué pour construire l’en-tête d’encapsulation à l’aide de NVGRE ou VXLAN, en fonction de la stratégie définie sur le contrôleur de réseau. En fonction de la stratégie programmée par l’agent hôte, un mappage AC-AF est utilisé pour déterminer l’adresse IP de l’hôte Hyper-V où réside la machine virtuelle de destination. Le commutateur Hyper-V garantit que les règles d’acheminement et les balises de réseau local virtuel correctes sont appliquées au paquet externe afin qu’il atteigne l’adresse AF distante.

Si une machine virtuelle connectée à un réseau virtuel HNV souhaite créer une connexion avec une machine virtuelle dans un autre sous-réseau virtuel (VSID), le paquet doit être routé en conséquence. HNV suppose une topologie en étoile où il n’y a qu’une seule adresse IP dans l’espace d’autorité de certification utilisée comme tronçon suivant pour atteindre tous les préfixes IP (c’est-à-dire un itinéraire/passerelle par défaut). Actuellement, cela applique une limitation à un itinéraire par défaut unique, et les itinéraires autres que les routes par défaut ne sont pas pris en charge.

Routage entre des sous-réseaux virtuels

Dans un réseau physique, un sous-réseau IP est un domaine de couche 2 (L2) où les ordinateurs (virtuels et physiques) peuvent communiquer directement entre eux. Le domaine L2 est un domaine de diffusion où les entrées ARP (carte d’adresses IP:MAC) sont apprises via les requêtes ARP qui sont diffusées sur toutes les interfaces et les réponses ARP sont renvoyées à l’hôte demandeur. L’ordinateur utilise les informations MAC apprises à partir de la réponse ARP pour construire complètement la trame L2, y compris les en-têtes Ethernet. Toutefois, si une adresse IP se trouve dans un autre sous-réseau L3, la requête ARP ne franchit pas cette limite L3. Au lieu de cela, une interface de routeur L3 (tronçon suivant ou passerelle par défaut) avec une adresse IP dans le sous-réseau source doit répondre à ces requêtes ARP avec sa propre adresse MAC.

Dans la mise en réseau Windows standard, un administrateur peut créer des itinéraires statiques et les affecter à une interface réseau. En outre, une « passerelle par défaut » est généralement configurée pour être l’adresse IP du tronçon suivant sur une interface où les paquets destinés à l’itinéraire par défaut (0.0.0.0/0) sont envoyés. Les paquets sont envoyés à cette passerelle par défaut si aucun itinéraire spécifique n’existe. Il s’agit en général du routeur pour votre réseau physique. HNV utilise un routeur intégré qui fait partie de chaque hôte et a une interface dans chaque VSID pour créer un routeur distribué pour les réseaux virtuels.

Étant donné que HNV suppose une topologie en étoile, le routeur distribué HNV agit comme une passerelle par défaut unique pour tout le trafic qui transite entre les sous-réseaux virtuels qui font partie du même réseau VSID. L’adresse utilisée comme passerelle par défaut est l’adresse IP la plus basse dans le VSID et est affectée au routeur distribué HNV. Ce routeur distribué représente un moyen très efficace de router correctement tout le trafic à l’intérieur d’un réseau VSID, car chaque hôte peut acheminer directement le trafic vers l’hôte approprié sans intermédiaire. Cela est particulièrement vrai lorsque deux ordinateurs virtuels du même réseau d’ordinateurs virtuels, mais de différents sous-réseaux virtuels, se trouvent sur le même hôte physique. Comme vous le verrez plus loin dans cette section, le paquet ne doit jamais quitter l’hôte physique.

Routage entre les sous-réseaux PA

Contrairement à HNVv1 qui a alloué une adresse IP PA pour chaque sous-réseau virtuel (VSID), HNVv2 utilise désormais une adresse IP PA par Switch-Embedded membre de l’équipe de cartes réseau SET (Teaming). Le déploiement par défaut suppose une équipe à deux cartes réseau et affecte deux adresses IP PA par hôte. Un seul hôte a des adresses IP PA attribuées à partir du même sous-réseau logique fournisseur (PA) sur le même VLAN. Deux machines virtuelles locataires dans le même sous-réseau virtuel peuvent en effet se trouver sur deux hôtes différents qui sont connectés à deux sous-réseaux logiques de fournisseur différents. HNV construit les en-têtes IP externes pour le paquet encapsulé en fonction du mappage CA-PA. Toutefois, il s’appuie sur la pile TCP/IP hôte vers ARP pour la passerelle PA par défaut, puis génère les en-têtes Ethernet externes en fonction de la réponse ARP. En règle générale, cette réponse ARP provient de l’interface SVI sur le commutateur physique ou le routeur L3 où l’hôte est connecté. HNV s’appuie donc sur le routeur L3 pour acheminer les paquets encapsulés entre les sous-réseaux logiques/VLAN du fournisseur.

Routage hors d’un réseau virtuel

La plupart des déploiements clients nécessitent une communication entre l’environnement HNV et les ressources qui ne font pas partie de ce même environnement. Les passerelles de virtualisation de réseau sont nécessaires pour permettre la communication entre les deux environnements. Les infrastructures nécessitant une passerelle HNV comprennent le Cloud privé et le Cloud hybride. Fondamentalement, les passerelles HNV sont requises pour le routage de couche 3 entre des réseaux internes et externes (physiques) (y compris NAT) ou entre différents sites et/ou clouds (privés ou publics) qui utilisent un tunnel IPSec VPN ou GRE.

Les passerelles peuvent présenter différents facteurs de forme physique. Elles peuvent être basées sur Windows Server 2016, incorporées dans un commutateur Top of Rack (TOR) agissant comme une passerelle VXLAN, accessibles via une adresse IP virtuelle (VIP) annoncée par un équilibreur de charge, placées dans d’autres appliances réseau existantes, ou peuvent être une nouvelle appliance réseau autonome.

Pour plus d’informations sur les options de passerelle RAS Windows, consultez Passerelle RAS.

Encapsulation de paquet

Dans HNV, chaque carte réseau virtuelle est associée à deux adresses IP :

• Adresse client (AC) Adresse IP assignée par le client, en fonction de son infrastructure intranet. Cette adresse permet au client d’échanger du trafic réseau avec l’ordinateur virtuel comme s’il n’avait pas été transféré sur un cloud public ou privé. L’adresse client est visible de l’ordinateur virtuel et accessible au client.

• Adresse fournisseur (AF) Adresse IP assignée par l’hébergeur ou les administrateurs du centre de données, en fonction de l’infrastructure de leur réseau physique. L’adresse fournisseur figure dans les paquets du réseau qui sont échangés avec le serveur exécutant Hyper-V qui héberge l’ordinateur virtuel. Cette adresse est visible sur le réseau physique, mais pas sur l’ordinateur virtuel.

Les adresses client préservent la topologie réseau du client, qui est virtualisée et dissociée des adresses et de la topologie du réseau physique sous-jacent, conformément à l’implémentation des adresses fournisseur. Le diagramme suivant illustre la relation conceptuelle entre les adresses client des ordinateurs virtuels et les adresses fournisseur d’une infrastructure réseau à la suite d’une virtualisation de réseau.

Figure 6 : diagramme conceptuel d’une virtualisation de réseau sur une infrastructure physique

Dans le diagramme, les ordinateurs virtuels client envoient des paquets de données dans l’espace d’adressage client, qui transitent par l’infrastructure réseau physique en empruntant leurs propres réseaux virtuels ou « tunnels ». Dans l’exemple ci-dessus, les tunnels peuvent être considérés comme des « enveloppes » pour les paquets de données Contoso et Fabrikam disposant d’étiquettes d’expédition (adresses fournisseur) vertes, qui doivent être remises par l’hôte source de gauche à l’hôte de destination de droite. La question essentielle est de savoir comment les hôtes déterminent les « adresses d’expédition » (fournisseur) correspondant aux adresses client Contoso et Fabrikam, comment l’« enveloppe » englobe les paquets et comment les hôtes de destination peuvent déballer les paquets et les remettre correctement aux ordinateurs virtuels de destination Contoso et Fabrikam.

Cette analogie simple a mis en évidence les principaux aspects de la virtualisation de réseau :

• Chaque adresse client d’ordinateur virtuel est mappée à une adresse fournisseur d’hôte physique. Plusieurs adresses client peuvent être associées à la même adresse fournisseur.

• Les ordinateurs virtuels envoient des paquets de données dans les espaces d’adressage client, qui sont mis dans une « enveloppe » avec une paire d’adresses fournisseur source et de destination en fonction du mappage.

• Les mappages entre adresses client et fournisseur doivent permettre aux hôtes de distinguer les paquets à destination des différents ordinateurs virtuels client.

Par conséquent, la virtualisation d’un réseau consiste à virtualiser les adresses réseau utilisées par les ordinateurs virtuels. Le contrôleur de réseau est responsable du mappage d’adresses et l’agent hôte gère la base de données de mappage à l’aide du schéma MS_VTEP. La section suivante décrit les mécanismes réels de la virtualisation d’adresses.

La virtualisation de réseau via la virtualisation d’adresses

HNV implémente des réseaux de locataires de superposition à l’aide de l’encapsulation de routage générique de virtualisation de réseau (NVGRE) ou du réseau local virtuel eXtensible (VXLAN). VXLAN est la valeur par défaut.

Réseau local virtuel eXtensible (VXLAN)

Le protocole VXLAN (Virtual eXtensible Local Area Network) (RFC 7348) a été largement adopté sur le marché, avec le support de fournisseurs tels que Cisco, Brocade, Arista, Dell, HP et d’autres. Le protocole VXLAN utilise UDP comme transport. Le port de destination UDP attribué par IANA pour VXLAN est 4789 et le port source UDP doit être un hachage d’informations du paquet interne à utiliser pour la propagation ECMP. Après l’en-tête UDP, un en-tête VXLAN est ajouté au paquet qui comprend un champ réservé de 4 octets suivi d’un champ de 3 octets pour l’identificateur réseau VXLAN (VNI) - VSID - suivi d’un autre champ réservé de 1 octet. Après l’en-tête VXLAN, l’image d’autorité de certification L2 d’origine (sans le cadre Ethernet de l’autorité de certification FCS) est ajoutée.

Encapsulation de routage générique (NVGRE)

Ce mécanisme de virtualisation de réseau utilise l’encapsulation générique de routage (NVGRE) dans l’en-tête de tunnel. Avec NVGRE, le paquet de l’ordinateur virtuel est encapsulé dans un autre paquet. L’en-tête de ce nouveau paquet contient les adresses IP fournisseur sources et de destination appropriées, outre l’ID de sous-réseau virtuel, qui est stocké dans le champ de clé de l’en-tête GRE, comme le montre la figure 7.

Figure 7 : virtualisation de réseau - encapsulation NVGRE

L’ID de sous-réseau virtuel permet aux hôtes d’identifier l’ordinateur virtuel client pour un paquet donné, même si les adresses fournisseur et client des paquets peuvent se chevaucher. De ce fait, tous les ordinateurs virtuels d’un même hôte peuvent partager une adresse fournisseur unique, comme l’illustre la figure 7.

La partage de l’adresse fournisseur a des conséquences importantes sur l’extensibilité réseau. Le nombre d’adresses IP et MAC que l’infrastructure réseau doit mémoriser s’en trouve considérablement réduit. Par exemple, si chaque hôte final compte en moyenne 30 ordinateurs virtuels, le nombre d’adresses IP et MAC que doit mémoriser l’infrastructure réseau est réduit selon un facteur de 30. Les ID de sous-réseau virtuel incorporés dans les paquets permettent en outre une corrélation facile entre les paquets et les clients effectifs.

Le schéma de partage AF pour Windows Server 2012 R2 est d’un AF par VSID et par hôte. Par Windows Server 2016 le schéma est d’un AF par membre de l’équipe de carte réseau.

Avec Windows Server 2016 et versions ultérieures, HNV prend entièrement en charge NVGRE et VXLAN en mode natif. Celle-ci ne nécessite AUCUNE mise à niveau ni acquisition de nouveau matériel réseau, tel qu'une carte réseau, un commutateur ou un routeur. Cela est dû au fait que les paquets transitant par le câble sont un paquet IP normal dans l’espace d’adressage fournisseur, qui est compatible avec l’infrastructure réseau d’aujourd’hui. Toutefois, pour obtenir les meilleures performances, utilisez des cartes réseau prises en charge avec les derniers pilotes qui prennent en charge les déchargements de tâches.

exemple de déploiement mutualisé

Le diagramme suivant montre un exemple de déploiement où deux clients optent pour un centre de données cloud et où la relation entre les adresses client et fournisseur est définie par les stratégies HNV.

Figure 8 : exemple de déploiement mutualisé

Examinez l’exemple illustré dans la figure 8. Avant d’utiliser le service IaaS partagé du fournisseur d’hébergement :

• Contoso Corp a exécuté un serveur SQL Server (nommé SQL) à l’adresse IP 10.1.1.11 et un serveur Web (nommé Web) à l’adresse IP 10.1.1.12, qui utilise son serveur SQL Server pour les transactions de base de données.

• Fabrikam Corp a exécuté un serveur SQL Server, également nommé SQL et a assigné l’adresse IP 10.1.1.11, ainsi qu’un serveur Web, également nommé Web avec la même adresse IP 10.1.1.12, qui utilise son serveur SQL Server pour les transactions de base de données.

Nous partons du principe que le fournisseur de services d’hébergement a déjà créé le réseau logique du fournisseur (AF) via le contrôleur de réseau pour qu’il corresponde à sa topologie de réseau physique. Le contrôleur de réseau alloue deux adresses IP AF à partir du préfixe IP du sous-réseau logique où les hôtes sont connectés. Le contrôleur réseau indique également la balise VLAN appropriée pour appliquer les adresses IP.

À l’aide du contrôleur de réseau, Contoso Corp et Fabrikam Corp, créez ensuite leur réseau virtuel et leurs sous-réseaux qui sont soutenus par le réseau logique du fournisseur (AF) spécifié par le fournisseur de services d’hébergement. Contoso Corp et Fabrikam Corp transfèrent leurs serveurs SQL Server et Web respectifs sur le service IaaS partagé du même fournisseur d’hébergement où, par coïncidence, elles exécutent les ordinateurs virtuels SQL sur l’hôte 1 Hyper-V et les ordinateurs virtuels Web (IIS7) sur l’hôte 2 Hyper-V. Tous les ordinateurs virtuels conservent leurs adresses IP (client) intranet d’origine.

Le contrôleur de réseau attribue aux deux sociétés l’ID de sous-réseau virtuel (VSID) suivant, comme indiqué ci-dessous. L’agent hôte sur chacun des hôtes Hyper-V reçoit les adresses IP AF allouées du contrôleur de réseau et crée deux cartes réseau virtuelles hôtes pa dans un compartiment réseau non par défaut. Une interface réseau est affectée à chacune de ces cartes réseau virtuelles hôtes où l’adresse IP AF est affectée, comme indiqué ci-dessous :

• VSID et PAs des machines virtuelles de Contoso Corp : VSID est 5001, SQL PA est 192.168.1.10, l’AF web est 192.168.2.20

• VSID et AFs des machines virtuelles de Contoso Corp : VSID est 6001, SQL AF est 192.168.1.10, l’AF web est 192.168.2.20

Le contrôleur de réseau connecte toutes les stratégies réseau (y compris le mappage AC-AF) à l’agent hôte SDN qui maintient la stratégie dans un magasin persistant (dans les tables de base de données OVSDB).

Lorsque l’ordinateur virtuel Web de Contoso Corp (10.1.1.12) sur l’hôte Hyper-V 2 crée une connexion TCP sur son serveur SQL Server à l’adresse 10.1.1.11, voici ce qui se produit :

• ARP de machine virtuelle pour l’adresse MAC de destination 10.1.1.11

• L’extension VFP dans le vSwitch intercepte ce paquet et l’envoie à l’agent hôte SDN

• L’agent hôte SDN recherche dans son magasin de stratégies l’adresse MAC pour 10.1.1.11

• Si un MAC est trouvé, l’agent hôte injecte une réponse ARP à la machine virtuelle

• Si un MAC est introuvable, aucune réponse n’est envoyée et l’entrée ARP dans la machine virtuelle pour 10.1.1.11 est marquée comme inaccessible.

• La machine virtuelle construit maintenant un paquet TCP avec les en-têtes Ethernet et IP de l’autorité de certification appropriés et l’envoie au commutateur virtuel

• L’extension de transfert VFP dans le vSwitch traite ce paquet via les couches VFP (décrites ci-dessous) affectées au port vSwitch source sur lequel le paquet a été reçu et crée une entrée de flux dans la table de flux unifiée VFP

• Le moteur VFP effectue la correspondance de règles ou la recherche de table de flux pour chaque couche (par exemple, la couche réseau virtuelle) en fonction des en-têtes IP et Ethernet.

• La règle correspondante dans la couche de réseau virtuel fait référence à un espace de mappage AC-AF et effectue l’encapsulation.

• Le type d’encapsulation (VXLAN ou NVGRE) est spécifié dans la couche de réseau virtuel avec le VSID.

• Dans le cas de l’encapsulation VXLAN, un en-tête UDP externe est construit avec le VSID de 5001 dans l’en-tête VXLAN. Un en-tête d’adresse IP externe est construit avec l’adresse PA source et de destination affectée respectivement à l’hôte Hyper-V 2 (192.168.2.20) et à l’hôte Hyper-V 1 (192.168.1.10) en fonction du magasin de stratégies de l’agent hôte SDN.

• Ce paquet est ensuite acheminé vers la couche de routage AF dans VFP.

• La couche de routage AF dans VFP référence le compartiment réseau utilisé pour le trafic d’espace AF et un ID de VLAN, et utilise la pile TCP/IP de l’hôte pour transférer correctement le paquet AF à l’hôte Hyper-V 1.

• À la réception du paquet encapsulé, l’hôte Hyper-V 1 reçoit le paquet dans le compartiment réseau AF et le transfère au commutateur virtuel.

• Le VFP traite le paquet via ses couches VFP et crée une entrée de flux dans la table de flux unifiée VFP.

• Le moteur VFP correspond aux règles d’entrée dans la couche réseau virtuelle et supprime les en-têtes Ethernet, IP et VXLAN du paquet encapsulé externe.

• Le moteur VFP transfère ensuite le paquet au port vSwitch auquel la machine virtuelle de destination est connectée.

Il existe un processus similaire pour le trafic échangé entre les ordinateurs virtuels Web et SQL de Fabrikam Corp qui utilise les paramètres de stratégie HNV pour Fabrikam Corp. Ainsi, grâce à la virtualisation HNV, les ordinateurs virtuels de Fabrikam Corp et Contoso Corp interagissent comme s’ils se trouvaient sur leur intranet d’origine. Ils ne peuvent jamais interagir entre eux, même s’ils utilisent les mêmes adresses IP.

Les adresses distinctes (client et fournisseur), les paramètres de stratégie des hôtes Hyper-V et la traduction d’adresses entre adresses client et fournisseur pour le trafic entrant et sortant des ordinateurs virtuels ont pour effet d’isoler ces ensembles de serveurs en utilisant soit la Clé NVGRE ou VLXAN VNID. De plus, les mappages et la transformation de la virtualisation dissocient l’architecture de réseau virtuel de l’infrastructure de réseau physique. Bien que les serveurs SQL et Web Contoso et les serveurs SQL et Web Fabrikam résident dans leurs propres sous-réseaux IP d’adresses client (10.1.1/24), leur déploiement physique se produit sur deux hôtes situés dans des sous-réseaux d’adresses fournisseur différents, 192.168.1/24 et 192.168.2/24, respectivement. Cela implique que l’approvisionnement et la migration dynamique des ordinateurs virtuels entre sous-réseaux devient possible avec HNV.

Architecture de la virtualisation de réseau Hyper-V

Dans Windows Server 2016, HNVv2 est implémenté à l’aide de la plateforme de filtrage virtuel Azure (VFP), qui est une extension de filtrage NDIS dans le commutateur Hyper-V. Le concept clé de VFP est celui d’un moteur de flux Match-Action avec une API interne exposée à l’agent hôte SDN pour la programmation de la stratégie réseau. L’agent hôte SDN reçoit lui-même la stratégie réseau du contrôleur de réseau sur les canaux de communication OVSDB et WCF SouthBound. Non seulement la stratégie de réseau virtuel (par exemple le mappage AC-AF) est programmée à l’aide de VFP, mais une stratégie supplémentaire telle que les listes de contrôle d’accès, la qualité de service, etc.

La hiérarchie d’objets pour l’extension de transfert vSwitch et VFP est la suivante :

• vSwitch

  • Gestion des cartes réseau externes

  • Déchargements matériels de carte réseau

  • Règles de transfert globales

  • Port

    • Couche de transfert de sortie pour l’épinglage à cheveux

    • Listes d’espaces pour les mappages et les pools NAT

    • Table de flux unifiée

    • Couche VFP

      • Table de flux

      • Groupe

      • Règle

        • Les règles peuvent référencer des espaces

Dans le VFP, une couche est créée par type de stratégie (par exemple, Réseau virtuel) et est un ensemble générique de tables de règles/flux. Il n’a pas de fonctionnalités intrinsèques tant que des règles spécifiques n’ont pas été affectées à cette couche pour implémenter ces fonctionnalités. Chaque couche se voit attribuer une priorité et les couches sont affectées à un port par priorité croissante. Les règles sont organisées en groupes principalement en fonction de la direction et de la famille d’adresses IP. Une priorité est également attribuée aux groupes et, au maximum, une règle d’un groupe peut correspondre à un flux donné.

La logique de transfert pour le commutateur virtuel avec l’extension VFP est la suivante :

• Traitement d’entrée (entrée du point de vue du paquet entrant dans un port)

• Transfert

• Traitement de sortie (sortie du point de vue du paquet sortant d’un port)

Le VFP prend en charge le transfert MAC interne pour les types d’encapsulation NVGRE et VXLAN, ainsi que le transfert basé sur un réseau local virtuel MAC externe.

L’extension VFP a un chemin d’accès lent et un chemin d’accès rapide pour la traversée de paquets. Le premier paquet d’un flux doit parcourir tous les groupes de règles de chaque couche et effectuer une recherche de règle, ce qui est une opération coûteuse. Toutefois, une fois qu’un flux est inscrit dans la table de flux unifiée avec une liste d’actions (en fonction des règles correspondantes), tous les paquets suivants sont traités en fonction des entrées de la table de flux unifiée.

La stratégie HNV est programmée par l’agent hôte. Chaque carte réseau d’ordinateur virtuel est configurée avec une adresse IPv4. Il s’agit des adresses client dont se serviront les ordinateurs virtuels pour communiquer entre eux et qui sont transportées dans les paquets IP en provenance des ordinateurs virtuels. HNV encapsule la trame d’autorité de certification dans une trame pa basée sur les stratégies de virtualisation de réseau stockées dans la base de données de l’agent hôte.

Figure 9 : architecture HNV

Résumé

Les centres de données en nuage peuvent apporter de nombreux avantages, notamment une extensibilité améliorée et une meilleure utilisation des ressources. Pour profiter de ces avantages potentiels, il est nécessite de faire appel à une technologie à même de résoudre fondamentalement les problèmes de l’extensibilité mutualisée dans un environnement dynamique. La virtualisation HNV a été conçue pour traiter ces problèmes et également pour améliorer l’efficacité des opérations du centre de données en dissociant la topologie du réseau virtuel de la topologie du réseau physique. S’appuyant sur une norme existante, HNV s’exécute dans le centre de données d’aujourd’hui et fonctionne avec votre infrastructure VXLAN existante. Avec HNV, les clients peuvent désormais consolider leurs centres de données dans un cloud privé ou les étendre en toute transparence dans l’environnement d’un fournisseur de serveurs d’hébergement avec un cloud hybride.

Voir aussi

Pour en savoir plus sur HNVv2, voir les liens suivants :