Vous êtes sur la page 1sur 13

Configuration réseau par défaut

Après avoir terminé ce module, vous serez en mesure de:


 Expliquez les réseaux Acropolis gérés et non gérés.
 Décrivez l'utilisation d'Open vSwitch (OVS) dans Acropolis.
 Déterminez les paramètres de configuration du réseau Acropolis.
 Affichez les détails du réseau à l'aide de Prism.
 Différencier les modes de liaison OVS pris en charge.
 Discutez de la configuration réseau par défaut.
Le diagramme suivant illustre la configuration réseau d'un seul hôte. La meilleure pratique
consiste à n'utiliser que les NIC de 10 Go et à déconnecter les NIC de 1 Go si vous n'en avez
pas besoin ou de les mettre dans une liaison distincte pour être utilisées dans des réseaux non
critiques.
 

 
Les connexions du serveur au commutateur physique utilisent des interfaces 10 GbE
ou plus. Vous pouvez établir des connexions entre les commutateurs avec des liaisons
directes de 40 GbE ou plus rapides, ou via une topologie de réseau en forme de feuille
(non illustrée). L'interface de gestion IPMI du nœud Nutanix se connecte également au
réseau de gestion hors bande, qui peut se connecter au réseau de production, mais ce
n'est pas obligatoire. Chaque nœud a toujours une seule connexion au réseau de
gestion, mais nous avons omis cet élément des autres images de ce document pour plus
de clarté et de simplicité.
Consultez le Guide de mise en réseau physique sur le portail de support Nutanix pour
plus d'informations sur la topologie des feuilles.  
 
Éléments du réseau
Open vSwitch OVS est un commutateur logiciel open source implémenté dans le noyau
Linux et conçu pour fonctionner dans un environnement de virtualisation multiserveur. Par
défaut, OVS se comporte comme un commutateur de couche 2 qui maintient une table
d'adresses MAC. L'hôte de l'hyperviseur et les machines virtuelles se connectent aux ports
virtuels sur le commutateur. OVS prend en charge de nombreuses fonctionnalités de
commutateurs populaires, telles que le marquage VLAN, l'équilibrage de charge et le
protocole LACP (Link Aggregation Control Protocol).
Chaque serveur AHV gère une instance OVS et toutes les instances OVS se combinent pour
former un seul commutateur logique. Les constructions appelées ponts gèrent les instances de
commutateur résidant sur les hôtes AHV. Utilisez les commandes suivantes pour configurer
OVS avec des ponts, des liaisons et des balises VLAN. Par exemple:
 ovs-vsctl (sur les hôtes AHV)
 ovs-appctl (sur les hôtes AHV)
 manage-ovs (sur CVM)
Consultez le site Web d' Open vSwitch pour plus d'informations  
 
Des ponts
 
Les ponts agissent comme des commutateurs virtuels pour gérer le trafic entre les
interfaces réseau physiques et virtuelles. La configuration AHV par défaut comprend
un pont OVS appelé br0 et un pont Linux natif appelé virbr0 . Les noms peuvent
varier entre les versions AHV / AOS et en fonction des changements de configuration
effectués sur les nœuds, mais dans cette formation, nous utiliserons br0 et virbr0 par
défaut.     
Le pont Linux virbr0 assure la gestion et la communication de stockage entre le CVM
et l'hôte AHV. Tout autre trafic réseau de stockage, d'hôte et de VM passe par
le pont br0 OVS. L'hôte AHV, les machines virtuelles et les interfaces physiques
utilisent des «ports» pour la connectivité au pont.    
 
Les ports
 
Les ports sont des constructions logiques créées dans un pont qui représentent la
connectivité au commutateur virtuel. Nutanix utilise plusieurs types de ports,
notamment internes, tap, VXLAN et bond.
 Un port interne portant le même nom que le pont par défaut ( br0 ) permet
d'accéder à l'hôte AHV.
 Les ports Tap connectent les cartes réseau virtuelles présentées aux machines
virtuelles.
 Utilisez les ports VXLAN pour la fonctionnalité de gestion des adresses IP
fournie par Acropolis.
 Les ports liés fournissent une association de NIC pour les interfaces physiques
de l'hôte AHV.
Obligations
Les ports liés regroupent les interfaces physiques sur l'hôte AHV. Par défaut, le
système crée une liaison nommée br0-up dans le pont br0 contenant toutes les
interfaces physiques. Les modifications apportées au lien par défaut br0-up à l'aide
des commandes manage_ovs peuvent le renommer en bond0 . N'oubliez pas que les
noms d'obligations sur votre système peuvent différer du diagramme ci-
dessous. Nutanix recommande d'utiliser le nom br0-up pour identifier rapidement
cette interface comme liaison montante du pont br0 . En utilisant ce schéma de
dénomination, vous pouvez également distinguer facilement les liaisons montantes des
ponts supplémentaires les unes des autres.           
N'utilisez que des cartes réseau de la même vitesse au sein de la même liaison. 
 
Modes de liaison
Il existe trois modes d'équilibrage de charge / basculement qui peuvent être appliqués
aux liaisons:
 

 
 
Active-Backup (par défaut)
  

 
 
Avec le mode de liaison de sauvegarde active, une interface de la liaison transporte le trafic et
les autres interfaces de la liaison ne sont utilisées que lorsque la liaison active échoue. La
sauvegarde active est le mode de liaison le plus simple, permettant facilement des connexions
à plusieurs commutateurs en amont sans aucune configuration de commutateur
supplémentaire. Le mode de liaison de sauvegarde active ne nécessite aucun matériel spécial
et vous pouvez utiliser différents commutateurs physiques pour la redondance.
Le compromis est que le trafic de toutes les machines virtuelles n'utilise qu'un seul lien actif
au sein de la liaison à la fois. Tous les liens de sauvegarde restent inutilisés jusqu'à ce que le
lien actif échoue. Dans un système avec deux adaptateurs de 10 Go, le débit maximal de
toutes les machines virtuelles s'exécutant sur un nœud Nutanix avec cette configuration est de
10 Gbit / s ou la vitesse d'une liaison unique.
Ce mode offre uniquement une capacité de basculement (pas d'équilibrage de la charge du
trafic). Si la liaison active tombe en panne, une liaison de secours ou passive s'active pour
fournir une connectivité continue. AHV transmet tout le trafic, y compris ceux du CVM et des
VM sur la liaison active. Tout le trafic partage 10 Gbit / s de bande passante réseau

Balance-slb
 
 
 
 
Pour tirer parti de la bande passante fournie par plusieurs liaisons de commutation en amont,
vous pouvez utiliser le mode de liaison balance-slb. Le mode de liaison balance-slb dans OVS
tire parti de toutes les liaisons dans une liaison et utilise la charge de trafic mesurée pour
rééquilibrer le trafic VM des interfaces les plus utilisées vers les moins utilisées. Lorsque
l'intervalle de rééquilibrage de liaison configurable expire, OVS utilise la charge mesurée
pour chaque interface et la charge pour chaque hachage MAC source pour répartir
uniformément le trafic entre les liaisons de la liaison. Le trafic provenant de certains hachages
MAC source peut passer à un lien moins actif pour équilibrer plus uniformément l'utilisation
des membres obligataires.
Un équilibrage parfaitement uniforme peut ne pas toujours être possible, en fonction du
nombre de hachages MAC source et de la taille de leurs flux. Chaque NIC de VM individuel
n'utilise qu'une seule interface de membre de liaison à la fois, mais un algorithme de hachage
distribue plusieurs adresses MAC sources de plusieurs NIC de VM sur les interfaces de
membre de liaison. En conséquence, il est possible pour un nœud Nutanix AHV avec deux
interfaces de 10 Go d'utiliser jusqu'à 20 Gbps de débit réseau. Les NIC de
VM individuelles ont un débit maximal de 10 Gbit / s, la vitesse d'une seule interface
physique. Une machine virtuelle avec plusieurs cartes réseau pourrait toujours avoir plus de
bande passante que la vitesse d'une seule interface physique, mais il n'y a aucune garantie que
les différentes cartes réseau de machine virtuelle atterriront sur des interfaces physiques
différentes.
L'intervalle de rééquilibrage par défaut est de 10 secondes, mais Nutanix recommande
de définir cet intervalle sur 30 secondes pour éviter un mouvement excessif des
hachages d'adresses MAC source entre les commutateurs en amont. Nutanix a testé
cette configuration en utilisant deux commutateurs en amont séparés avec AHV. Si les
commutateurs en amont sont interconnectés physiquement ou virtuellement et que les
deux liaisons montantes autorisent les mêmes VLAN, aucune configuration
supplémentaire, telle que l'agrégation de liens, n'est nécessaire.
 
N'utilisez pas de technologies d'agrégation de liens telles que LACP avec balance-
slb. L'algorithme balance-slb suppose que les liaisons de commutation en amont sont des
interfaces L2 indépendantes. Il gère le trafic de diffusion, de monodiffusion et de multidiffusion
(BUM), écoutant sélectivement ce trafic sur un seul adaptateur actif dans la liaison.
 
N'utilisez pas la surveillance IGMP sur les commutateurs physiques connectés aux serveurs
Nutanix à l'aide de balance-slb. Balance-slb transfère le trafic de multidiffusion entrant sur un seul
adaptateur actif et rejette le trafic de multidiffusion d'autres adaptateurs. Les commutateurs avec
surveillance IGMP peuvent ignorer le trafic vers l' adaptateur actif et l'envoyer uniquement aux
adaptateurs de sauvegarde. Cette discordance conduit à un comportement de trafic multicast
imprévisible. Désactivez la surveillance IGMP ou configurez des groupes IGMP statiques pour
tous les ports de commutateur connectés aux serveurs Nutanix à l'aide de balance-slb. La
surveillance IGMP est souvent activée par défaut sur les commutateurs physiques.
 
Active-backup et balance-slb ne nécessitent pas de configuration du côté du commutateur.
 
LACP avec Balance-TCP
 
 
Tirer pleinement parti de la bande passante fournie par plusieurs liens vers des
commutateurs en amont, à partir d'une seule machine virtuelle, nécessite une
agrégation de liens et un équilibrage de charge négociés dynamiquement à l'aide de
balance-tcp. Nutanix recommande l'agrégation de liens dynamiques avec LACP au
lieu de l'agrégation de liens statiques en raison de l'amélioration de la détection et de la
récupération des pannes.
 
Assurez-vous que vous avez correctement configuré les commutateurs en amont avant d'activer
LACP. Sur le commutateur, l'agrégation de liens est communément appelée canal de port ou
LAG, selon le fournisseur du commutateur. L'utilisation de plusieurs commutateurs en amont peut
nécessiter une configuration supplémentaire telle que MLAG ou vPC. Configurez les
commutateurs pour revenir en mode de sauvegarde active en cas d'échec de la négociation LACP,
parfois appelée repli ou pas de suspension individuelle. Ce paramètre aide à l'imagerie des nœuds
et à la configuration initiale lorsque LACP n'est peut-être pas encore disponible.
Consultez les documents suivants pour plus d'informations sur les meilleures
pratiques MLAG et vPC .    
Avec l'agrégation de liens négociée par LACP, plusieurs liens vers des commutateurs
physiques distincts apparaissent comme un lien de couche 2 (L2) unique. Un
algorithme de hachage du trafic tel que balance-tcp peut diviser le trafic entre plusieurs
liens de manière active-active. Étant donné que les liaisons montantes apparaissent
comme une liaison L2 unique, l'algorithme peut équilibrer le trafic entre les membres
de la liaison sans tenir compte des tables d'adresses MAC des commutateurs. Nutanix
recommande d'utiliser balance-tcp lors de l'utilisation de LACP et de l'agrégation de
liens, car chaque flux TCP d' une seule VM peut potentiellement utiliser une liaison
montante différente dans cette configuration.
Avec l'agrégation de liens, LACP et balance-tcp, une seule VM invitée avec plusieurs
flux TCP pourrait utiliser jusqu'à 20 Gbit / s de bande passante dans un nœud AHV
avec deux adaptateurs de 10 Go.
 
Configuration de l'agrégation de liens
Configurez l'agrégation de liens avec LACP et balance-tcp à l'aide des commandes ci-
dessous sur tous les CVM Nutanix du cluster.
Vous devez configurer des commutateurs en amont pour l'agrégation de liens avec LACP avant de
configurer l'hôte AHV à partir du CVM. Les paramètres LACP en amont, tels que les minuteries,
doivent correspondre aux paramètres de l'hôte AHV pour la cohérence de la
configuration. Voir KB 3263 pour plus d'informations sur la configuration LCAP.  
Si la négociation LACP en amont échoue, la configuration d'hôte AHV par défaut
désactive la liaison, bloquant ainsi tout le trafic. La commande suivante permet le
retour en mode de liaison de sauvegarde active dans l'hôte AHV en cas d'échec de la
négociation LACP:
 
nutanix @ CVM $ ssh root@192.168.5.1 "ovs-vsctl définit le port br0-up
other_config: lacp-fallback- ab = true
 
Dans l'hôte AHV et sur la plupart des commutateurs, la configuration par défaut du
minuteur OVS LACP est lente, soit 30 secondes. Cette valeur - qui est indépendante
du réglage de la minuterie du commutateur - détermine la fréquence à laquelle l'hôte
AHV demande des LACPDU au commutateur physique connecté. Le réglage rapide (1
seconde) demande des LACPDU au commutateur physique connecté toutes les
secondes, ce qui permet de détecter plus rapidement les pannes d'interface. Le fait de
ne pas recevoir trois LACPDU - en d'autres termes, après 3 secondes avec le réglage
rapide - ferme la liaison au sein de la liaison. Nutanix recommande de régler lacp-time
pour réduire le temps nécessaire pour détecter une défaillance de liaison de 90
secondes à 3 secondes. N'utilisez le paramètre de temps lacp plus lent que si le
commutateur physique l'exige pour l'interopérabilité.
nutanix @ CVM $ ssh root@192.168.5.1 "ovs-vsctl définit le port br0-up
other_config: lacp-time = fast"
 
Ensuite, activez la négociation LACP et définissez l'algorithme de hachage sur
balance-tcp:
nutanix @ CVM $ ssh root@192.168.5.1 "ovs-vsctl définit le port br0-up lacp
= active"
nutanix @ CVM $ ssh root@192.168.5.1 "ovs-vsctl définit le port br0-up
bond_mode = balance-tcp"
 
Confirmez la négociation LACP avec le ou les commutateurs en amont à l'aide de ovs-
appctl, en recherchant le mot «négocié» dans les lignes d'état:
 
nutanix @ CVM $ ssh root@192.168.5.1 "ovs-appctl bond / show br0-up"
nutanix @ CVM $ ssh root@192.168.5.1 "ovs-appctl lacp / show br0-up"
 
Réseaux locaux virtuels (VLAN)
AHV prend en charge deux façons différentes de fournir une connectivité VM:
les réseaux gérés et non gérés .    
 

            
 

Avec les réseaux non gérés , les VM obtiennent une connexion directe à leur VLAN de

choix. Chaque réseau virtuel dans AHV est mappé à un seul VLAN et pont. Tous les VLAN
autorisés sur le port de commutateur physique vers l'hôte AHV sont disponibles pour le CVM

et les machines virtuelles invitées. Vous pouvez créer et gérer des réseaux virtuels, sans

configuration d'hôte AHV supplémentaire, en utilisant:  


 Élément prisme
 CLI Acropole (aCLI)
 API REST
Acropolis lie chaque réseau virtuel qu'il crée à un seul VLAN. Lors de la création de la
VM, vous pouvez créer une carte réseau virtuelle et l'associer à un réseau et un
VLAN. Vous pouvez également provisionner plusieurs cartes réseau virtuelles avec
chacune un seul VLAN ou réseau.
 
Gestion des adresses IP (IPAM)
 
  
 

              Les administrateurs peuvent configurer chaque réseau virtuel avec un sous-réseau

IP spécifique, des paramètres de domaine associés et un groupe de pools d'adresses IP

disponibles pour l'attribution.


 L'Acropolis Master agit comme un serveur DHCP interne pour tous les réseaux gérés.
 L'OVS est chargé d'encapsuler les requêtes DHCP des VM dans VXLAN et de les
transmettre à Acropolis Master.
 Les VM reçoivent leurs adresses IP à partir des réponses de l'Acropolis Master.
 L'adresse IP attribuée à une machine virtuelle est persistante jusqu'à ce que vous
supprimiez le VNIC ou que vous détruisez la machine virtuelle.
Acropolis Master exécute le processus administratif CVM pour suivre les adresses IP
des appareils. Cela crée des associations entre les adresses MAC de l'interface, les
adresses IP et le pool défini d'adresses IP pour le serveur DHCP AOS.
 
Mise en réseau hôte AHV
La gestion du réseau dans un cluster Acropolis comprend les tâches suivantes:
 Configuration de la commutation L2 (configuration des ponts, des liaisons et
des VLAN.)
 Modification facultative de l'adresse IP, du masque de réseau et de la passerelle
par défaut spécifiés par AHV pour les hôtes pendant le processus de création
d'image.
Cette vidéo Tech TopX présente les concepts de mise en réseau AHV, y compris des
exemples CLI et Prism.  
 
Configuration réseau recommandée
Vous devez remplacer la configuration réseau par défaut par la configuration
recommandée ci-dessous.
 

 
 
Bonnes pratiques de mise en réseau AVS
OVS
Ne modifiez pas les tables OpenFlow associées au pont OVS par défaut br0 . 
 
VLAN
Ajoutez le contrôleur VM et l'hôte AHV au même VLAN. Par défaut, AHV attribue le
contrôleur VM et l'hyperviseur au VLAN 0 , ce qui les place effectivement sur le VLAN natif
configuré sur le commutateur physique en amont. 
N'ajoutez pas d'autres périphériques, tels que des machines virtuelles invitées, au même
VLAN que le CVM et l'hyperviseur. Isolez les VM invitées sur un ou plusieurs VLAN
distincts.
 
 
Ponts virtuels
Ne supprimez ni ne renommez le pont OVS br0 . 
Ne modifiez pas le pont Linux natif virbr0. 
 
Port lié OVS (bond0)
Agrégez les interfaces 10 GbE de l'hôte en une liaison OVS sur br0. Trunk ces interfaces sur
le commutateur physique.
 
Par défaut, les interfaces 10 GbE de la liaison OVS fonctionnent dans le mode de sauvegarde
active recommandé. 
 
Remarque : Nutanix ne recommande ni ne prend en charge le mélange de modes de liaison
entre les hôtes AHV dans le même cluster. Les configurations LACP peuvent fonctionner
mais peuvent avoir une prise en charge limitée.
 
Interfaces 1 GbE et 10 GbE (hôte physique)
Si vous souhaitez utiliser les interfaces 10 GbE pour le trafic de VM invité, assurez-vous que
les VM invitées n'utilisent pas le VLAN sur lequel la VM du contrôleur et l'hyperviseur
communiquent.
Si vous souhaitez utiliser les interfaces 1 GbE pour la connectivité des machines virtuelles
invitées, suivez les directives de configuration de réseau et de port de commutateur du
fabricant de l'hyperviseur. 
Remarque : n'incluez pas les interfaces 1 GbE dans la même liaison que les interfaces 10
GbE. Aussi, pour éviter les boucles, n'ajoutez pas les interfaces 1 GbE au pont br0 , que ce
soit individuellement ou dans une deuxième liaison. Utilisez-les sur d'autres ponts. 
 
Port IPMI sur l'hôte de l'hyperviseur
Ne pas relier les ports de commutateur qui se connectent à l'interface IPMI.
Configurez les ports du commutateur en tant que ports d'accès pour une gestion simplifiée.
 
Commutateur physique en amont
Nutanix ne recommande pas l'utilisation de Fabric Extenders (FEX) ou de technologies
similaires pour les cas d'utilisation en production. Bien que les implémentations initiales à
faible charge puissent fonctionner correctement avec ces technologies, des performances
médiocres, des blocages de VM et d'autres problèmes peuvent survenir à mesure que les
implémentations évoluent vers le haut.
Nutanix recommande l'utilisation de commutateurs non bloquants à débit de ligne de 10
Gbit / s avec des tampons plus grands pour les charges de travail de production.  
Utilisez un commutateur conforme aux normes 802.3-2012 qui a une faible latence, une
conception de coupure et fournit une latence de trafic prévisible et cohérente indépendamment
de la taille des paquets, du modèle de trafic ou des fonctionnalités activées sur les interfaces
10 GbE.  
La latence de port à port ne doit pas dépasser 2 microsecondes.
Utilisez des technologies de convergence rapide (telles que Cisco PortFast) sur les ports de
commutateur connectés à l'hôte de l'hyperviseur.
Évitez d'utiliser des tampons partagés pour les ports 10 GbE. Utilisez un tampon dédié pour
chaque port.
 
Disposition physique du réseau
Utilisez des commutateurs redondants de haut de rack dans une architecture traditionnelle en
forme de feuille. La conception de réseau plat est bien adaptée à une architecture de calcul et
de stockage hautement distribuée et sans partage.
Ajoutez tous les nœuds appartenant à un cluster donné au même segment de réseau de couche
2.
Nutanix prend en charge d'autres configurations de réseau tant que vous suivez toutes les
autres recommandations de Nutanix.
 
Contrôleur VM
 
Ne supprimez pas la machine virtuelle du contrôleur du pont OVS br0 ou du pont Linux
natif virbr0 .   
 
Comparaison de la terminologie des réseaux AHV
 
 
 
 
 
 
  
 
 
 
Aperçu
La segmentation du réseau est conçue pour gérer le trafic provenant du trafic du fond
de panier (stockage et CVM). Il sépare le trafic de stockage du trafic de gestion
routable à des fins de sécurité et crée des réseaux virtuels distincts pour chaque type de
trafic.
 
 
 
 

 
Vous pouvez segmenter le réseau sur un cluster Nutanix des manières suivantes:
 Sur un cluster existant à l'aide de la console Web Prism
 Lors de la création d'un cluster à l'aide de Nutanix Foundation 3.11.2 ou de
versions supérieures.
Regardez cette vidéo Tech TopX pour en savoir plus sur la segmentation du
réseau. Vous pouvez également lire le Guide de sécurité Nutanix pour plus
d'informations sur la sécurisation du trafic via la segmentation du réseau.    
 
Scénarios
Configuration de la segmentation du réseau sur un cluster existant
Pour plus d'informations sur la segmentation du réseau lors de la création d'un cluster,
consultez le Guide d'installation sur le terrain . 
Vous pouvez segmenter le réseau sur un cluster existant à l'aide de la console Web
Prism. Le processus de segmentation du réseau:
 Crée un réseau distinct pour les communications de fond de panier sur le
commutateur virtuel par défaut existant.
 Configure les interfaces eth2 créées par AHV sur les CVM pendant la mise à
niveau.  
 Place les interfaces hôte sur le réseau nouvellement créé.
A partir du sous-réseau spécifié, AHV attribue des adresses IP à chaque nouvelle
interface. Chaque nœud nécessite deux adresses IP. Pour les nouveaux réseaux de fond
de panier, vous devez spécifier un sous-réseau non routable. Les interfaces du réseau
de fond de panier reçoivent automatiquement des adresses IP à partir de ce sous-
réseau, alors réservez le sous-réseau entier pour le réseau de fond de panier
uniquement.
Si vous prévoyez de spécifier un VLAN pour le réseau de fond de panier, configurez le
VLAN sur les ports de commutateur physique auxquels les nœuds se connectent. Si
vous spécifiez l'ID VLAN facultatif, AHV place les interfaces nouvellement créées sur
le VLAN. Nutanix recommande vivement un VLAN distinct pour le réseau de fond de
panier afin d'obtenir une véritable segmentation.
 
Configuration de la segmentation du réseau pour un cluster RDMA existant
Segmentez le réseau sur un cluster RDMA existant à l'aide de la console Web
Prism. Le processus de segmentation du réseau:
 Crée un réseau distinct pour les communications RDMA sur le commutateur
virtuel par défaut existant.
 Place l' interface rdma0 créée sur les CVM lors de la mise à niveau.  
 Place les interfaces hôte sur le réseau nouvellement créé.
A partir du sous-réseau spécifié, AHV attribue des adresses IP (deux par nœud) à
chaque nouvelle interface. Pour les nouveaux réseaux RDMA, vous devez spécifier un
sous-réseau non routable. AHV attribue automatiquement les interfaces sur les
adresses IP du réseau de fond de panier à partir de ce sous-réseau, alors réservez
l'intégralité du sous-réseau pour le réseau de fond de panier uniquement.
Si vous prévoyez de spécifier un VLAN pour le réseau RDMA, configurez le VLAN
sur les ports de commutateur physique auxquels les nœuds se connectent. Si vous
spécifiez l'ID VLAN facultatif, AHV place les interfaces nouvellement créées sur le
VLAN. Nutanix recommande vivement un VLAN séparé pour le réseau RDMA afin
d'obtenir une véritable segmentation.
 
Segmentation du réseau pendant l'expansion du cluster
 
Lorsque vous développez un cluster, AHV étend la segmentation du réseau aux nœuds
ajoutés. Pour chaque nœud que vous ajoutez au cluster, AHV alloue deux adresses IP à
partir de l'espace d'adressage réseau non routable spécifié. Si les adresses IP ne sont
pas disponibles dans le réseau spécifié, Prism affiche un message sur la page des
tâches. Dans ce cas, vous devez reconfigurer le réseau avant de réessayer l'extension
du cluster.
Lorsque vous modifiez le sous-réseau, toutes les adresses IP affectées aux interfaces
sur le réseau du fond de panier changent et la procédure implique donc l'arrêt du
cluster. Pour plus d'informations sur la reconfiguration du réseau, voir Reconfiguration
du réseau de fond de panier . 
 
Segmentation du réseau lors d'une mise à niveau AOS
 
Si la nouvelle version d'AOS prend en charge la segmentation du réseau, AHV crée
automatiquement l' interface eth2 sur chaque CVM. Cependant, le réseau reste non
segmenté et les services de cluster sur le CVM continuent à utiliser eth0 jusqu'à ce que
vous configuriez la segmentation du réseau.    
 
Ne supprimez pas l' interface eth2 créée par AHV sur les CVM, même si vous n'utilisez pas la
fonction de segmentation du réseau.  
 

Reconfiguration du réseau de
fond de panier
La reconfiguration du réseau de fond de panier est une procédure pilotée par CLI que
vous exécutez sur l'un des CVM du cluster. AHV propage la modification aux CVM
restants.
 
À la fin de cette procédure, le cluster s'arrête et redémarre, même s'il ne modifie que l'ID de
VLAN, et implique donc un temps d'arrêt du cluster. Arrêtez toutes les machines virtuelles et
CVM utilisateur avant de reconfigurer le fond de panier réseau.
 
Désactivation de la segmentation du réseau
 
La désactivation de la segmentation du réseau est une procédure pilotée par CLI que
vous exécutez sur l'un des CVM du cluster. AHV propage la modification aux CVM
restants. 
À la fin de cette procédure, le cluster s'arrête et redémarre et implique donc un temps
d'arrêt du cluster. Arrêtez toutes les machines virtuelles et CVM utilisateur avant de
reconfigurer la segmentation réseau désactivée.
 
Configurations de segmentation de réseau non prises en charge
 
La segmentation du réseau n'est pas prise en charge dans les configurations suivantes:
 Clusters sur lesquels les CVM ont une interface eth2 créée manuellement.
 Clusters sur lesquels l'interface eth2 sur un ou plusieurs CVM ont des adresses
IP attribuées manuellement.
 Dans les clusters ESXi où le CVM se connecte à un commutateur virtuel
distribué VMware.
 Clusters qui ont deux (ou plus) vSwitches ou ponts pour l'isolation du trafic
CVM. Le réseau de gestion CVM (eth0) et le réseau de fond de panier CVM
(eth2) doivent résider sur un seul vSwitch ou pont. Ne créez pas ces réseaux
CVM sur des vSwitches ou des ponts séparés.