Les trois sites d'un cluster étendu communiquent via le réseau de gestion et le réseau Virtual SAN. Les VM des deux sites de données communiquent via un réseau de machines virtuelles commun.

Un cluster étendu Virtual SAN doit répondre à certaines exigences réseau de base.

  • Un réseau de gestion a besoin de la connectivité avec les trois sites, à l'aide d'un réseau étendu à 2 ou 3 couches.

  • Le réseau Virtual SAN doit disposer d'une connectivité sur les trois sites. VMware recommande d'utiliser un réseau étendu à 2 ou 3 couches entre les sites de données et l'hôte témoin.

  • Le réseau VM a besoin de la connectivité avec les sites de données, mais pas avec l'hôte témoin. VMware recommande d'utiliser un réseau étendu à 2 couches entre les sites de données. En cas de panne, les VM n'ont pas besoin d'une nouvelle adresse IP pour fonctionner sur le site distant.

  • Le réseau vMotion a besoin de la connectivité avec les sites de données, mais pas avec l'hôte témoin. VMware prend en charge l'utilisation d'un réseau étendu à 2 ou 3 couches entre les sites de données.

Utilisation de routes statiques sur des hôtes ESXi

Si vous utilisez une seule passerelle par défaut sur les hôtes ESXi, souvenez-vous que chaque hôte ESXi contient une pile TCP/IP par défaut qui possède une seule passerelle par défaut. La route par défaut est habituellement associée à la pile TCP/IP du réseau de gestion.

Le réseau de gestion et le réseau Virtual SAN peuvent être isolés l'un de l'autre. Par exemple, le réseau de gestion doit utiliser vmk0 sur la NIC 0 physique, tandis que le réseau Virtual SAN utilise vmk2 sur la NIC 1 physique (adaptateurs réseau séparés pour deux piles TCP/IP distinctes). Cette configuration impose un réseau Virtual SAN sans passerelle par défaut.

Prenons le cas d'un réseau Virtual SAN étendu sur deux sites de données avec un domaine de diffusion à 2 couches (par exemple, 172.10.0.0) et l'hôte témoin sur un autre domaine de diffusion (par exemple, 172.30.0.0). Si les adaptateurs VMkernel d'un site de données essayent de se connecter au réseau Virtual SAN de l'hôte témoin, la connexion échouera parce que la passerelle par défaut de l'hôte ESXi est associée au réseau de gestion et qu'il n'existe aucune route entre le réseau de gestion et le réseau Virtual SAN.

Vous pouvez utiliser des routes statiques pour résoudre ce problème. Définissez une nouvelle entrée de route qui indique le chemin à suivre pour atteindre un réseau donné. Pour un réseau Virtual SAN sur un cluster étendu, vous pouvez ajouter des routes statiques qui permettront une communication adaptée entre tous les hôtes.

Par exemple, vous pouvez ajouter une route statique aux hôtes de chaque site de données afin que les demandes d'accès au réseau témoin 172.30.0.0 soient routées via l'interface 172.10.0.0. Ajoutez également une route statique vers l'hôte témoin afin que les demandes d'accès au réseau 172.10.0.0 pour les sites de données soient routées via l'interface 172.30.0.0.

Remarque :

Si vous utilisez des routes statiques, vous devez ajouter manuellement les routes statiques pour les nouveaux hôtes ESXi ajoutés à l'un des sites avant que ces hôtes ne puissent communiquer dans le cluster. Si vous remplacez l'hôte témoin, vous devez mettre à jour la configuration de la route statique.

Utilisez la commande esxcli network ip route pour ajouter des routes statiques.