Serveur d'impression

Configuration du réseau virtuel Hyper-V et meilleures pratiques – Bien choisir son serveur d impression

Le 4 mai 2019 - 29 minutes de lecture

Si vous débutez dans le monde de la virtualisation, la configuration réseau peut être l’un des concepts les plus difficiles à comprendre. La mise en réseau est également différente dans Hyper-V par rapport aux autres hyperviseurs. Ainsi, même ceux qui ont des années d'expérience peuvent trébucher un peu lorsqu'ils rencontrent Hyper-V pour la première fois. Cet article commence par examiner la conception du réseau virtuel dans Hyper-V, sa configuration, puis les meilleures pratiques d'implémentation.

Bases de la mise en réseau

Avant de commencer, il peut être utile de vous assurer de bien comprendre les principes fondamentaux des réseaux Ethernet et TCP / IP en général. Plusieurs articles expliquant les aspects communs commencent par cette explication du modèle OSI.

Le commutateur virtuel Hyper-V

Le composant le plus important de la mise en réseau dans Hyper-V est le commutateur virtuel. Ce blog contient un article approfondi sur le commutateur virtuel Hyper-V, mais dans l’intérêt de cet article, je vais vous donner une introduction de base au concept, dans son ensemble.

La clé de la compréhension est de réaliser que c'est vraiment un commutateur, tout comme un commutateur physique. Il fonctionne dans la couche 2 en tant qu'intermédiaire pour les ports de commutateurs virtuels. Il dirige les paquets vers les adresses MAC. Il gère le marquage VLAN. Il peut même effectuer certaines tâches de qualité de service (QoS). Il est également responsable de l’isolation du trafic réseau vers l’adaptateur virtuel censé le recevoir. Lorsqu’il est visualisé, le commutateur réseau Hyper-V doit être conçu de la même manière qu’un commutateur standard:

La prochaine partie de la compréhension du commutateur virtuel concerne son interaction avec l'hôte. Pour ouvrir cette discussion, vous devez d'abord vous familiariser avec les types de commutateurs virtuels disponibles.

Modes de commutation virtuels

Il existe trois modes possibles pour le commutateur Hyper-V: privé, interne et public. Ne les confondez pas avec les schémas d'adressage IP ou toute autre configuration de réseau virtuel utilisant une technologie différente.

Switch privé Hyper-V

Le commutateur privé autorise les communications entre les machines virtuelles sur son hôte et rien d'autre. Même le système d'exploitation de gestion n'est pas autorisé à participer. Ce commutateur est purement logique et n’utilise aucun adaptateur physique. «Privé» dans ce sens n'est pas lié à l'adressage IP privé. Vous pouvez penser mentalement à cela comme à un commutateur qui ne permet pas la liaison montante avec d'autres commutateurs.

Commutateur interne Hyper-V

Le commutateur interne est similaire au commutateur privé, à une exception près: le système d'exploitation de gestion peut disposer d'un adaptateur virtuel sur ce type de commutateur. Cela permet au système d'exploitation de gestion de communiquer directement avec toutes les machines virtuelles disposant également d'adaptateurs virtuels sur le même commutateur interne. A l'instar du commutateur privé, le commutateur interne n'a aucun lien avec une carte physique et ne peut donc pas également se connecter à un autre commutateur.

Commutateur externe Hyper-V

Le type de commutateur externe doit être connecté à une carte physique. Il permet la communication entre le réseau physique et le système d'exploitation de gestion et les adaptateurs virtuels sur des machines virtuelles. Ne confondez pas ce type de commutateur avec les schémas d'adressage IP publics ou laissez son nom suggérer qu'il doit être connecté à un système connecté à Internet. Vous pouvez utiliser la même plage d'adresses IP privées pour les adaptateurs d'un commutateur virtuel externe que vous utilisez sur le réseau physique auquel il est connecté. Externe dans cette utilisation, cela signifie qu'il peut se connecter à des systèmes externes à l'hôte Hyper-V.

Comment conceptualiser le commutateur virtuel externe

Une partie de ce qui rend la compréhension artificielle du commutateur virtuel externe artificielle est la formulation des paramètres associés. Dans l’interface graphique du gestionnaire Hyper-V, il est libellé comme suit: Autoriser le système d'exploitation de gestion à partager cette carte réseau. Dans PowerShell New-VMSwitch cmdlet, il y a un AllowManagementOS paramètre qui ne vaut pas mieux, et sa description – Indique si la partition parent (c'est-à-dire le système d'exploitation de gestion) doit avoir accès à la carte réseau physique liée au commutateur virtuel à créer. – ça fait pire. Ce qui semble se produire beaucoup trop souvent, c’est que les gens les lisent et pensent au commutateur virtuel et aux adaptateurs virtuels comme ceci:

Malheureusement, ce n’est pas du tout une représentation précise de la pile réseau virtuelle d’Hyper-V. Une fois que le commutateur virtuel est lié à une carte physique, cette carte n'est plus utilisée. TCP / IP et la plupart des autres éléments en sont supprimés. Le système d'exploitation de gestion est tout simplement incapable de le «partager». Si vous essayez de lier autre chose à l’adaptateur, il est fort probable que vous casseriez le commutateur virtuel.

En réalité, le système d'exploitation de gestion obtient sa propre carte réseau virtuelle. C’est ce qui se connecte au commutateur virtuel. Cet adaptateur ne correspond pas exactement aux adaptateurs connectés aux machines virtuelles; ce n’est pas aussi riche en fonctionnalités. Cependant, rien n’est comparable au partage de l’adaptateur physique comme le supposent les contrôles. Un meilleur terme serait «Connecter le système d'exploitation de gestion au commutateur virtuel». C’est ce que les réglages font vraiment. L'image suivante est une description beaucoup plus précise de ce qui se passe:

Comme vous pouvez le constater, l’adaptateur virtuel du système d’exploitation de gestion est traité de la même manière que celui des adaptateurs de machines virtuelles. Bien entendu, vous avez toujours la possibilité de retirer un ou plusieurs adaptateurs physiques du commutateur virtuel. Celles-ci seront utilisées normalement par le système d'exploitation de gestion. Si vous faites cela, vous n’avez pas nécessairement besoin de «partager» l’adaptateur du commutateur virtuel avec le système d’exploitation:

Utilisation de l'association de cartes réseau physiques avec le commutateur virtuel Hyper-V

À partir de Windows Server 2012, l'association de cartes réseau est désormais une fonction native du système d'exploitation Windows Server. Teaming vous permet de combiner deux adaptateurs ou plus dans un seul canal de communication logique pour répartir le trafic réseau. Hyper-V Server peut également associer des adaptateurs physiques.

Lorsqu'un adaptateur groupé est créé, les adaptateurs individuels apparaissent toujours dans Windows mais, d'une manière très similaire au commutateur virtuel, ne peuvent plus être liés à rien à l'exception du protocole Teaming. Lors de la création de l'équipe, un nouvel adaptateur est présenté au système d'exploitation. Il serait correct d’appeler cet adaptateur «virtuel», car il n’existe pas physiquement, mais cela peut créer une confusion avec les adaptateurs virtuels utilisés avec le commutateur virtuel Hyper-V. Des termes plus courants sont adaptateur d'équipe ou adaptateur logique, et parfois l'abréviation tNIC est utilisé.

Étant donné que l’association n’est pas une fonctionnalité ni une exigence centrale d’Hyper-V, elle ne sera pas traitée en détail ici. Hyper-V utilise efficacement les associations d'adaptateurs natifs et doit donc être utilisé dans la mesure du possible. En règle générale, vous devriez choisir le Dynamique algorithme d'équilibrage de charge, sauf si vous avez un besoin impératif clairement défini; il combine les meilleures fonctionnalités des algorithmes de port Hyper-V et de ports de transport. Pour ce qui est d'utiliser ou non le mode de regroupement indépendant du commutateur ou l'un des modes qui en dépendent, il s'agit d'une discussion plus approfondie impliquant l'équilibrage de vos objectifs par rapport aux capacités du matériel disponible. Pour approfondir le sujet du partenariat avec Hyper-V, consultez les articles suivants du blog Altaro:

Forums Altaro Dojo

Vous avez des questions brûlantes sur Hyper-V?

logo des forums

Posez des questions, lisez les réponses, laissez des commentaires et maîtrisez Hyper-V

Modéré par les MVP Microsoft et les principaux experts du secteur informatique

Convergence Hyper-V et réseau

Convergence réseau signifie simplement que plusieurs types de trafic sont combinés dans un seul canal de communication. Dans une certaine mesure, Hyper-V le fait toujours, car plusieurs machines virtuelles utilisent le même commutateur virtuel, donc le même matériel réseau. Cependant, tout cela pourrait techniquement être classé dans une seule rubrique du "trafic de machine virtuelle", de sorte que ce n’est pas tout à fait la convergence.

Dans l’espace Hyper-V, la convergence réelle inclurait au moins un autre rôle et au moins deux cartes réseau physiques. Le moyen le plus simple d'y parvenir consiste à associer deux ou plusieurs adaptateurs comme indiqué dans la section précédente, puis à créer un commutateur virtuel au-dessus de l'adaptateur d'équipe. Une fois le commutateur virtuel créé, utilisez l'option "partager" ou PowerShell pour créer également un adaptateur virtuel pour le système d'exploitation de gestion. Si cet adaptateur est utilisé pour quoi que ce soit dans le système d'exploitation de gestion, cela est considéré comme une convergence. D'autres rôles possibles seront discutés plus tard.

Alors que la convergence la plus courante lie généralement tous les adaptateurs de la même vitesse dans un seul canal, ce n’est pas une obligation. Vous pouvez utiliser une équipe pour le trafic de la machine virtuelle et une autre pour le système d'exploitation de gestion si vous le souhaitez.

Hyper-V et mise en réseau au sein d'un cluster

Le clustering avec basculement a ses propres besoins de mise en réseau, et Hyper-V étend encore ces exigences. Chaque nœud commence par les mêmes exigences qu'un système Hyper-V autonome: un adaptateur de gestion et un commutateur virtuel. Un cluster ajoute le besoin de trafic lié au cluster et de Live Migration.

Dans les versions antérieures à 2012, la seule configuration prise en charge nécessitait que tous ces rôles soient séparés en connexions gigabit uniques. Avec les améliorations introduites en 2012 et 2012 R2, ces exigences sont beaucoup plus souples. Il n’existe aucune exigence publiée avec les nouvelles versions (bien que l’on puisse affirmer que les exigences pour 2008 R2 n’ont jamais été remplacées officiellement, elles sont donc techniquement toujours appliquées). En pratique, il a été observé qu’il est absolument nécessaire d’avoir au moins deux chemins de cluster uniques, mais le reste peut être ajusté à la hausse ou à la baisse en fonction de la charge de travail.

Ce qui suit décrit chaque rôle et donne une brève description de son trafic:

  • La gestion: Ce rôle transportera tout le trafic pour les sauvegardes au niveau de l'hôte et toutes les activités de partage de fichiers liées à l'hôte, telles que l'accès ou la copie d'images ISO à partir d'un système distant. Pendant les autres périodes, ce rôle ne rencontre généralement pas une charge de trafic importante. L'utilisation typique est pour le trafic de gestion à distance, tel que RDP et WS-Man (PowerShell), qui sont très légers.
  • Communications de clusterRemarque: chaque nœud du cluster communique en permanence avec tous les autres nœuds d’un modèle de maillage afin de s’assurer que le cluster est toujours opérationnel. Cette opération est communément appelée «pulsation», bien que les informations de configuration du réseau soient également échangées. Le trafic cardiaque est généralement très léger, mais il est extrêmement sensible à la latence. S'il ne dispose pas d'un réseau dédié, il peut facilement être noyé par d'autres opérations, telles que les copies de fichiers volumineuses, ce qui entraînera la perte de quorum et le basculement des machines virtuelles sur les ordinateurs virtuels, même si rien n'est techniquement faux.

    • Volumes partagés du cluster: Le trafic CSV n’est pas un rôle unique; il voyage dans le cadre des communications de cluster standard. Lorsque tout va bien, le trafic CSV est assez minime, ne transmettant que les informations de métadonnées CSV entre les nœuds. Si un fichier CSV passe en mode d'accès redirigé, tout le trafic en provenance et à destination de ce fichier CSV sera traité par le nœud propriétaire. Si un autre nœud doit accéder à ce fichier CSV, il le fera via un réseau de cluster. Le cluster veillera à ce que les communications de cluster normales, telles que les pulsations, ne soient pas sacrifiées, mais toute lutte pour la bande passante entraînera un dysfonctionnement des machines virtuelles, voire un crash. Si votre cluster n'utilise pas de fichiers CSV, ce trafic n'est pas un problème.
  • Migration en direct: Sans contraintes, une opération Live Migration utilisera autant de bande passante que possible. La configuration typique fournit un adaptateur dédié pour ce rôle. Avec la mise en réseau convergée, l'exigence n'est pas aussi stricte.
  • Trafic de la machine virtuelle: Le trafic des ordinateurs virtuels est sans doute le plus important du cluster, mais il a également tendance à ne pas être excessivement lourd. L'approche traditionnelle consiste à dédier au moins un adaptateur au commutateur virtuel.

Tandis que les versions existantes les séparaient simplement en tuyaux gigabit uniques et dédiés, vous disposez désormais de plus d'options.

Améliorations SMB pour les communications de cluster

Les communications de cluster ont toujours utilisé le protocole SMB. Le protocole SMB a été considérablement mis à niveau en 2012 et a maintenant la capacité de à canaux multiples. Cette fonctionnalité négociera automatiquement entre les hôtes source et de destination et répartira automatiquement le trafic SMB sur tous les adaptateurs disponibles.

Auparavant, il était nécessaire de configurer les réseaux pour les communications de cluster, puis de modifier les attributions de métriques afin de guider le trafic. En 2012, R2 a donc été privilégié: il suffit de désigner deux réseaux ou plus comme réseaux de cluster. Les hôtes équilibreront automatiquement les charges de trafic.

Améliorations SMB pour la migration en direct

Si les nœuds du cluster sont tous configurés pour utiliser SMB pour la migration en direct, il tire parti des mêmes améliorations SMB que celles utilisées par les communications de cluster standard. De cette façon, le trafic de gestion, le trafic de communication de cluster et Live Migration ne peuvent être exécutés que sur deux réseaux distincts au lieu de deux. Cela peut être risqué, surtout si le mode d'accès redirigé est activé.

Avantages de la mise en réseau convergée pour le clustering

En utilisant des réseaux convergés, vous gagnez beaucoup plus d'options avec moins de matériel. Le multicanal SMB divise le trafic sur des réseaux distincts, c’est-à-dire des sous-réseaux uniques. En utilisant des réseaux convergés, vous pouvez créer plus de sous-réseaux que d'adaptateurs physiques.

Ceci est particulièrement utile pour les adaptateurs 10GbE car peu d’hôtes en auront plus de deux. Il a également sa place sur les réseaux 1GbE. Vous pouvez simplement combiner tous les adaptateurs physiques en une seule et grande équipe et créer le même nombre de réseaux logiques que vous auriez pour un rôle traditionnel, mais activer chacun d'eux pour les communications de cluster et la migration Live. De cette façon, le multicanal SMB sera capable d'équilibrer automatiquement la charge de ses besoins. N'oubliez pas que même avec un réseau convergé, il est préférable de ne pas combiner tous les rôles sur un seul adaptateur virtuel ou associé. Le multicanal SMB nécessite des sous-réseaux distincts pour jouer son rôle et le regroupement équilibre le trafic en fonction de l'adaptateur virtuel.

Avantages de la qualité de service pour le clustering

Bien que l'inquiétude se manifeste rarement, il est techniquement possible qu'un type de trafic consomme pleinement une équipe convergée. Un certain nombre d'options de qualité de service (QoS) sont disponibles pour empêcher cela. Vous pouvez spécifiquement limiter le trafic SMB et / ou Live Migration et définir des valeurs maximales et minimales sur les cartes virtuelles.

Avant de passer beaucoup de temps à explorer ces options, sachez que la plupart des déploiements n'exigent pas ce degré de contrôle et fonctionnent parfaitement avec les valeurs par défaut. Hyper-V travaillera automatiquement à maintenir un équilibre de trafic qui ne noie pas complètement une carte réseau virtuelle particulière. Étant donné que la complexité de la configuration de la qualité de service l'emporte sur ses avantages dans l'environnement typique, cette rubrique ne sera pas abordée dans cette série. Le travail le plus complet sur le sujet est disponible sur TechNet.

Comment concevoir des réseaux de clusters pour Hyper-V

Le concept essentiel est que les réseaux de cluster sont définis par le sous-réseau TCP / IP. Le service de cluster détectera chaque adresse IP et masque de sous-réseau sur chaque nœud. À partir de ceux-ci, il créera un réseau pour chaque sous-réseau unique trouvé. Si un nœud a plus d'une adresse IP dans un sous-réseau, le service de cluster en utilisera une et ignorera le reste à moins que le premier ne soit supprimé. Si le service trouve des réseaux pour lesquels seuls certains nœuds ont des adresses IP, le réseau sera marqué comme cloisonné. Un réseau sera également marqué en tant que partitionné si les communications de cluster sont autorisées, mais que le flux de trafic entre nœuds pose problème. Le diagramme suivant montre quelques exemples de réseaux et explique comment leur mise en cluster les détectera.

Dans l’illustration, le seul réseau valide est Réseau de cluster 2. Le pire est Réseau de cluster 4. En raison de la manière dont le sous-réseau est configuré, il se superpose à tous les autres réseaux. Le service de cluster verrouille automatiquement l'adaptateur de noeud 2 avec l'adresse IP 192.168.5.11 en dehors des communications de cluster et marque le réseau comme Aucun pour indiquer qu'il n'est pas autorisé pour les communications de cluster.

Avant de créer votre cluster, déterminez les sous-réseaux IP que vous utiliserez. Il est parfaitement acceptable de créer de nouveaux réseaux si nécessaire. Pour les communications de cluster, les nœuds ne communiqueront pas intentionnellement avec autre chose que les nœuds du même cluster. Le nombre minimum de réseaux uniques est de deux. L'un doit être marqué pour permettre les communications client et cluster; c'est le réseau de gestion. L'un d'entre eux doit être marqué pour permettre les communications en cluster (les communications client sont facultatives mais non recommandées). D'autres réseaux sont facultatifs, mais donneront au cluster la possibilité de créer des flux TCP supplémentaires pouvant faciliter l'équilibrage de la charge entre des adaptateurs associés.

Meilleures pratiques de mise en réseau Hyper-V – Configuration en pratique

Il n’existe pas non plus de méthode «correcte» pour configurer la mise en réseau dans Hyper-V qu’il existe une méthode «correcte» pour configurer un réseau physique. Cette section abordera un certain nombre de pratiques et procédures optimales pour vous montrer comment les choses se passent et vous guider dans la mesure du possible. Le meilleur conseil que quiconque puisse vous donner est de ne pas trop y penser. Très peu de machines virtuelles exigeront beaucoup de bande passante réseau.

Il existe quelques meilleures pratiques pour vous aider à prendre des décisions de base en matière de configuration:

  • Un réseau convergé permet d'obtenir la meilleure répartition globale de la bande passante. Il est extrêmement rare d’avoir une situation dans laquelle un seul rôle de réseau utilise constamment une connexion gigabit complète. En dédiant un ou plusieurs adaptateurs à un seul rôle, vous empêchez tout autre rôle d'utiliser cet adaptateur, même lorsque son rôle propriétaire est inactif.

  • Un seul flux TCP / IP ne peut utiliser qu'un seul lien physique. L’un des aspects les plus déroutants en matière d’équipe que rencontrent les nouveaux arrivants est que la combinaison de plusieurs liens au sein d’une même équipe ne signifie pas automatiquement que tout le trafic utilisera automatiquement tous les liens disponibles. Cela signifie que différents flux de communication seront équilibrés parmi ceux disponibles. Ou bien, pour que cela soit plus clair, vous avez besoin d'au moins quatre flux de communication différents pour utiliser pleinement quatre adaptateurs dans une équipe.
  • Évitez d'utiliser iSCSI ou SMB 3 directement avec le regroupement. Il est pris en charge pour les deux, mais il est moins efficace que d'utiliser MPIO (pour iSCSI) ou SMB multicanal. Il est pris en charge de disposer de plusieurs cartes réseau virtuelles sur une équipe configurées pour le multicanal iSCSI ou SMB. Cependant, vous obtiendrez toujours les meilleures performances pour le stockage réseau en utilisant des adaptateurs non associés qui ne sont pas liés à un commutateur virtuel. Cet article explique comment configurer MPIO.

Les étapes nécessaires à la création d'une équipe étaient déjà liées, mais vous trouverez à nouveau le lien: https://www.altaro.com/hyper-v/how-to-set-up-native-teams-in-hyper-v-server -2012 /.

Configuration de l'adaptateur et du TCP / IP

Si votre système exécute une édition graphique de Windows Server, vous pouvez configurer TCP / IP pour tous les adaptateurs à l'aide des outils graphiques traditionnels. Pour toutes les versions, vous pouvez également utiliser sconfig.cmd pour un processus guidé. Cette section explique comment effectuer ces tâches à l'aide de PowerShell. Pour que le matériel soit aussi concis que possible, toutes les options possibles ne seront pas affichées. Reportez-vous à l'article d'introduction à PowerShell pour obtenir de l'aide sur la découverte des fonctionnalités des applets de commande à l'aide de Get-Help et d'autres outils.

Voir Statut de l'adaptateur (et noms à utiliser dans d'autres applets de commande).

Renommer un adaptateur physique ou d'équipe

Définir l'adresse IP d'un adaptateur

Définir la passerelle par défaut d’une carte

Conseil: utilisez «Set-NetRoute» pour apporter des modifications ou «Remove-NetRoute» pour supprimer une passerelle.

Définir les adresses du serveur DNS

Empêcher un adaptateur de s'inscrire dans le DNS

Une dernière option que vous voudrez peut-être envisager est de définir des cadres jumbo sur vos cartes virtuelles. Une trame jumbo est un paquet TCP / IP dépassant la taille de base de 1514 octets. Il est le plus souvent utilisé pour les connexions iSCSI, mais peut également aider un peu avec le trafic SMB 3 et Live Migration. Ce n'est pas du tout utile pour le trafic qui traverse Internet et la plupart des trafics de réseau local n'en bénéficient pas non plus. Si vous souhaitez l'utiliser, le post suivant l'explique en détail: https://www.altaro.com/hyper-v/how-to-adjust-mtu-jumbo-frames-on-hyper-v-and -windows-server-2012 /. Cet article a été écrit pour 2012. Le commutateur virtuel de 2012 R2 dispose de la fonction Jumbo Frames activée par défaut. Il vous suffit donc de suivre les parties qui expliquent comment le définir sur vos adaptateurs physiques et virtuels.

Configuration de commutateurs virtuels et d'adaptateurs virtuels

Tous les outils graphiques permettant de créer un commutateur virtuel et de configurer un seul adaptateur virtuel pour le système d'exploitation de gestion étaient décrits dans cet article précédent de la série. Vous ne pouvez pas utiliser les outils graphiques pour créer d'autres adaptateurs virtuels à utiliser par le système d'exploitation de gestion. Vous devez également utiliser PowerShell pour créer votre commutateur virtuel si vous souhaitez contrôler sa stratégie QoS. Les commandes PowerShell suivantes traitent du commutateur virtuel et de ses adaptateurs.

Créer un commutateur virtuel externe

Il y a plusieurs choses à noter à propos de cette cmdlet particulière:

  • Le paramètre «InterfaceAlias» présenté ci-dessus est en réalité un alias de «NetAdapterName». L'alias a été choisi ici car il s'aligne sur le nom du paramètre et la sortie de Get-NetAdapter.
  • La cmdlet a été saisie avec «vSwitch» comme nom du commutateur virtuel, mais vous pouvez utiliser ce que vous voulez. Si votre nom choisi comporte un espace, vous devez le mettre entre guillemets simples ou doubles.
  • Si vous ne spécifiez pas le paramètre «AllowManagementOS» ou si vous le définissez sur true, un adaptateur virtuel sera automatiquement créé pour le système d'exploitation de gestion avec le même nom que le commutateur virtuel. Ignorer cette création automatique vous donne un plus grand contrôle sur la création et la configuration de vos propres adaptateurs virtuels.
  • Si vous ne souhaitez pas activer SR-IOV sur votre commutateur virtuel, il n'est pas nécessaire de spécifier ce paramètre. Il apparaît ici pour vous rappeler que si vous souhaitez le définir, vous devez le définir lors de la création du commutateur. Vous ne pouvez pas changer cela plus tard.
  • La documentation d'aide pour Get-VMSwitch indique que le paramètre par défaut de «MinimumBandwidthMode» est «Weight». Ceci est une erreur. Le mode par défaut est “Absolute”. Comme avec le support SR-IOV, vous ne pouvez pas modifier ce paramètre après la création du commutateur.

Créer un commutateur virtuel privé

De nombreuses notes de la création du commutateur externe s'appliquent également ici. Le commutateur «EnableIOV» ne s'applique pas du tout à un commutateur privé ou interne. Le commutateur «AllowManagementOS» est redondant: si le type de commutateur est «Privé», aucun adaptateur virtuel n'est créé. si le type de commutateur est “Internal”, il en est créé un. L'ajout d'un adaptateur virtuel au système d'exploitation de gestion sur un commutateur privé le convertira en interne; le retrait de tous les adaptateurs virtuels de système d'exploitation de gestion d'un commutateur interne le rendra privé.

Supprimer définitivement un commutateur virtuel

Cette opération est permanente. L'ensemble du commutateur et tous ses paramètres sont perdus. Tous les adaptateurs virtuels du système d'exploitation de gestion sur ce commutateur sont définitivement perdus. Les adaptateurs virtuels des machines virtuelles connectées à ce commutateur sont déconnectés.

Ajouter un adaptateur virtuel au système d'exploitation de gestion

La première chose à noter est que, pour une raison quelconque, cette applet de commande utilise «Ajouter» au lieu du verbe «Nouveau» normal pour créer un nouvel objet. Sachez que ce nouvel adaptateur apparaîtra dans les entrées Get-NetAdapter en tant que vEthernet (New vAdapter) et c’est le nom que vous utiliserez pour toutes ces applets de commande autres que Hyper-V. Utilisez les mêmes applets de commande de la section précédente pour configurer

Récupérer une liste d'adaptateurs virtuels dans le système d'exploitation de gestion

Renommer un adaptateur virtuel dans le système d'exploitation de gestion

Comment définir les informations de VLAN pour les adaptateurs virtuels Hyper-V

Des adaptateurs pour le système d'exploitation de gestion et les machines virtuelles peuvent être attribués à des VLAN. Lorsque cela se produit, le commutateur virtuel Hyper-V gère le processus de marquage 802.1q pour les communications sur les commutateurs virtuels et pour les paquets en provenance et à destination des commutateurs physiques. Comme indiqué dans l'article sur les paramètres de la machine virtuelle, vous pouvez utiliser le gestionnaire Hyper-V pour modifier le VLAN de l'un des adaptateurs connectés aux machines virtuelles. Vous pouvez uniquement utiliser PowerShell pour modifier le VLAN des adaptateurs virtuels dans le système d'exploitation de gestion.

Récupérer les assignations de VLAN pour tous les adaptateurs virtuels sur l'hôte

Vous pouvez utiliser le paramètre «ManagementOS» pour afficher uniquement les adaptateurs dans le système d'exploitation de gestion. Vous pouvez utiliser le paramètre "VMName" avec un astérisque pour afficher uniquement les adaptateurs connectés aux machines virtuelles.

Définir le VLAN pour une carte virtuelle dans le système d'exploitation de gestion

Définir le VLAN pour tous les adaptateurs d’une machine virtuelle

Supprimer le marquage VLAN de tous les adaptateurs d’une machine virtuelle

Si une machine virtuelle dispose de plusieurs adaptateurs virtuels et que vous souhaitez opérer séparément, cela peut nécessiter un peu plus de travail. Lorsque l'interface graphique est utilisée pour créer des adaptateurs virtuels pour une machine virtuelle, ils sont toujours nommés. Adaptateur de réseau, même s'il y en a plusieurs. Par conséquent, vous devrez utiliser PowerShell pour les renommer au fur et à mesure de leur création ou vous ne pourrez pas utiliser «VMNetworkAdapterName» pour les distinguer. Au lieu de cela, vous pouvez utiliser Get-VMNetworkAdapter pour localiser d'autres fonctionnalités distinctives et diriger la sortie vers des applets de commande qui acceptent des objets VMNetworkAdapter. Par exemple, vous souhaitez modifier le VLAN d'un seul adaptateur connecté à la machine virtuelle nommé «svtest». En utilisant les outils du système d'exploitation invité, vous avez déterminé que l'adresse MAC de l'adaptateur que vous souhaitez modifier est «00-15-5D-19-0A-24». Avec l'adresse MAC, vous pouvez modifier le VLAN de cette carte uniquement à l'aide de la construction PowerShell suivante:

Configuration de la mise en réseau du cluster

Il est possible d’utiliser PowerShell pour configurer la mise en réseau de votre cluster de basculement, mais il n’est pas très élégant avec l’état actuel de ces cmdlets. Pour le moment, ils ne sont pas bien configurés. Vous devez donc manipuler directement les valeurs de propriété d'objet et les paramètres de registre de manière risquée et source d'erreurs. Il est préférable d'utiliser le gestionnaire de cluster de basculement pour définir ces paramètres, comme expliqué dans cet article, plus haut dans la série.

Continuer à explorer la mise en réseau

Il y a beaucoup à digérer dans la mise en réseau virtuelle Hyper-V. Ce que vous avez vu jusqu’à présent n’est vraiment que les fondamentaux. Pour un déploiement relativement simpliste ne comprenant que quelques dizaines de machines virtuelles, vous n'aurez peut-être jamais besoin de plus d'informations. À mesure que les densités commencent à augmenter, il devient de plus en plus nécessaire d'optimiser la mise en réseau. Avec les adaptateurs gigabits, votre meilleure option est de faire évoluer votre système. Les adaptateurs 10 GbE vous permettent de surmonter les limitations physiques du processeur avec un certain nombre de techniques de déchargement, notamment VMQ. Commencez votre recherche sur ce sujet en commençant par la série d'articles définitive sur le sujet, VMQ Deep Dive.

Sinon, la meilleure chose à faire est de vous familiariser avec les applets de commande PowerShell. Par exemple, découvrez comment utiliser Set-VMNetworkAdapter pour modifier les adaptateurs virtuels de la même manière que les procédures décrites dans les articles précédents de l'interface graphique. Avec un peu d’effort, vous pourrez changer de groupe d’adaptateurs à la fois. La mise en réseau d’Hyper-V peut être complexe et avoir de multiples facettes, mais le niveau de contrôle qui vous est accordé est également vaste.

Commentaires

Laisser un commentaire

Votre commentaire sera révisé par les administrateurs si besoin.