Vous pouvez utiliser deux réseaux VLAN non routables logiquement et physiquement séparés afin de produire une topologie isolée.

Cet exemple fournit les étapes de configuration pour un vSphere Distributed Switch. Cependant, vous pouvez également utiliser des commutateurs vSphere Standard. Cela nécessite deux cartes réseau physiques de 10 Go et les sépare logiquement sur la couche de mise en réseau vSphere.

Créez deux groupes de ports distribués pour chaque vmknic VMkernel vSAN. Chaque groupe de ports dispose d'une balise VLAN distincte. Pour la configuration du VMkernel vSAN, deux adresses IP sur les deux réseaux VLAN sont nécessaires pour le trafic vSAN.

Note :

Les implémentations pratiques utilisent généralement quatre liaisons montantes physiques pour une redondance complète.

Pour chaque groupe de ports, la stratégie d'association et de basculement utilise les paramètres par défaut.

  • Équilibrage de charge défini sur Route basée sur l'ID de port d'origine

  • Détection de panne réseau définie sur État de lien seulement

  • Avertir les commutateurs défini sur la valeur par défaut Oui

  • Le retour arrière est défini sur la valeur par défaut Oui

  • La configuration de liaison montante présente une liaison montante dans la position Actif et une liaison montante dans la position Inutilisé.

Un réseau est complètement isolé de l'autre réseau.

Groupe de ports 1 vSAN

Cet exemple utilise un groupe de ports distribués appelé vSAN-DPortGroup-1. VLAN 3266 est marqué pour ce groupe de ports avec la stratégie d'association et de basculement suivante :

  • Trafic sur le groupe de ports marqué avec VLAN 3266

  • Équilibrage de charge défini sur Route basée sur l'ID de port d'origine

  • Détection de panne réseau définie sur État de lien seulement

  • Avertir les commutateurs défini sur la valeur par défaut Oui

  • Retour arrière défini sur la valeur par défaut Oui

  • La configuration de liaison montante indique le paramètre liaison montante 1 défini dans la position Actif et le paramètre liaison montante 2 défini dans la position Inutilisé.

Multiples vmnic, route basée sur le port d'origine

Groupe de ports 2 vSAN

Pour compléter le groupe de ports 1 vSAN, configurez un deuxième groupe de ports distribués appelé vSAN-portgroup-2 avec les différences suivantes :

  • Trafic sur le groupe de ports marqué avec VLAN 3265

  • La configuration de liaison montante indique le paramètre Liaison montante 2 défini dans la position Actif et le paramètre Liaison montante 1 défini dans la position Inutilisé .

Configuration du port VMkernel vSAN

Créez deux interfaces VMkernel vSAN et sur les deux groupes de ports. Dans cet exemple, les groupes de ports sont nommés vmk1 et vmk2.

  • vmk1 est associé à VLAN 3266 (172.40.0.xx) et par conséquent, au groupe de ports vSAN-DPortGroup-1.

  • vmk2 est associé à VLAN 3265 (192.60.0.xx) et, par conséquent, au groupe de ports vSAN-DPortGroup-2.

Configurer les ports VMkernel

Équilibrage de charge

vSAN ne dispose pas d'un mécanisme d'équilibrage de charge pour différencier plusieurs vmknic. Le chemin des E/S vSAN choisi n'est donc pas déterministe sur l'ensemble des cartes réseau physiques. Les graphiques de performances de vSphere montrent qu'une carte réseau physique est souvent plus utilisée que l'autre. Un test d'E/S simple effectué dans nos laboratoires, utilisant 120 machines virtuelles avec un taux de lecture/écriture de 70:30 avec une taille de bloc de 64 000 sur un cluster vSAN100 % Flash à quatre hôtes, a révélé un déséquilibrage de la charge sur les cartes réseau.

Les graphiques de performances de vSphere affichent une charge non équilibrée entre les cartes réseau.

Perte de redondance de la liaison montante du réseau

Supposez une panne de réseau introduite dans cette configuration. vmnic1 n'est pas activé sur un hôte vSAN spécifique. Par conséquent, le port vmk2 est affecté. Une carte réseau défaillante déclenche les alarmes de connectivité réseau et les alarmes de redondance.

Pour vSAN, ce processus de basculement se déclenche approximativement 10 secondes après que CMMDS (services de surveillance, d'appartenance et d'annuaire de cluster) a détecté une panne. Lors du basculement et de la récupération, vSAN arrête toutes les connexions actives sur le réseau défaillant et tente de rétablir les connexions sur le réseau fonctionnel restant.

Étant donné que deux ports VMkernel vSAN distincts communiquent sur des réseaux VLAN isolés, des pannes de contrôle de santé vSAN peuvent être déclenchées. Cela est normal, car vmk2 ne peut plus communiquer avec ses homologues sur VLAN 3265.

Les graphiques de performances montrent que la charge de travail affectée a été redémarrée sur vmnic0, car vmnic1 présente une panne. Ce test illustre une distinction importante entre l'association de cartes réseau vSphere et cette topologie. vSAN tente de rétablir ou de redémarrer les connexions sur le réseau restant.

Cependant, dans certains scénarios de panne, la récupération des connexions affectées peut nécessiter jusqu'à 90 secondes pour être exécutée en raison de l'expiration du délai de connexion à TCP ESXi. Les tentatives de connexion ultérieures peuvent échouer, mais les tentatives de connexion expirent à 5 secondes et les tentatives passent en revue toutes les adresses IP possibles. Ce comportement peut affecter les E/S invitées de la machine virtuelle. Par conséquent, les E/S d'application et de machine virtuelle devront éventuellement être réessayées.

Par exemple, sur les machines virtuelles Windows Server 2012, les ID d'événement 153 (réinitialisation de périphérique) et 129 (événements de nouvelle tentative) peuvent être consignés pendant le processus de basculement et de récupération. Dans l'exemple, l'ID d'événement 129 a été consigné pendant environ 90 secondes jusqu'à ce que les E/S aient été récupérées.

Vous devrez peut-être modifier les paramètres de délai d'expiration de disque de certains systèmes d'inactivité invités pour vous assurer qu'ils ne sont pas sérieusement affectés. Les valeurs de délai d'expiration de disque peuvent varier en fonction de la présence de VMware Tools, ainsi que du type et de la version spécifiques du système d'exploitation invité. Pour de plus amples informations sur la modification des valeurs de délai d'expiration du disque du système d'exploitation invité, accédez à l'article 1009465 de la base de connaissances VMware.

Récupération et retour arrière

Lorsque le réseau est réparé, les charges de travail ne sont pas automatiquement rééquilibrées, sauf si une autre erreur d'imposition de la charge de travail se produit, en raison d'une autre panne. Dès que le réseau affecté est récupéré, il devient disponible pour les nouvelles connexions TCP.