Ce chapitre décrit les scénarios d'échec classiques pouvant affecter les composants du sous-système de routage NSX et les effets de ces échecs.

NSX Manager

Tableau 1. Modes d'échec de NSX Manager et effets
Mode d'échec Effets de l'échec
Perte de connectivité réseau avec la VM NSX Manager
  • Indisponibilité totale de toutes les fonctions de NSX Manager, notamment les opérations CLMS pour le routage/pontage NSX
  • Aucune perte de données de configuration
  • Aucune indisponibilité des données ou du plan de contrôle
Perte de connectivité réseau entre NSX Manager et les hôtes ESXi ou échec du serveur RabbitMQ
  • Si la VM de contrôle du DLR ou la passerelle ESG est exécutée sur des hôtes affectés, les opérations CLMS sur elles échouent
  • La création et la suppression d'instances du DLR sur des hôtes affectés échouent
  • Aucune perte de données de configuration
  • Aucune indisponibilité des données ou du plan de contrôle
  • Les mises à jour du routage dynamique continuent de fonctionner
Perte de connectivité réseau entre NSX Manager et les contrôleurs
  • Les opérations de création, de mise à jour et de suppression pour le routage distribué et le pontage de NSX échouent
  • Aucune perte de données de configuration
  • Aucune indisponibilité des données ou du plan de contrôle
La VM NSX Manager est détruite (échec de la banque de données)
  • Indisponibilité totale de toutes les fonctions de NSX Manager, notamment les opérations CLMS pour le routage/pontage NSX
  • Risque qu'un sous-ensemble d'instances de routage/pontage devienne orphelin si NSX Manager est restauré vers une ancienne configuration, ce qui requiert un nettoyage et un rapprochement manuels
  • Aucune indisponibilité des données ou du plan de contrôle, sauf si un rapprochement est nécessaire

Cluster de contrôleurs

Tableau 2. Modes d'échec de NSX Controller et effets
Mode d'échec Effets de l'échec
Le cluster de contrôleurs perd la connectivité réseau avec les hôtes ESXi
  • Indisponibilité totale de toutes les fonctions du plan de contrôle du DLR (création, mise à jour et suppression des itinéraires, y compris dynamiques)
  • Indisponibilité des fonctions du plan de gestion du DLR (création, mise à jour et suppression de LIF sur des hôtes)
  • Le transfert de VXLAN est affecté, ce qui peut également entraîner l'échec du processus de transfert de bout en bout (L2+L3)
  • Le plan de données continue de fonctionner selon le dernier état connu
Un ou deux contrôleurs perdent la connectivité avec les hôtes ESXi
  • Si un contrôleur affecté peut toujours atteindre d'autres contrôleurs dans le cluster, les instances du DLR contrôlées par ce contrôleur rencontrent les mêmes effets que ceux décrits ci-dessus. D'autres contrôleurs ne prennent pas le contrôle automatiquement
Un contrôleur perd la connectivité réseau avec les autres contrôleurs (ou complètement)
  • Deux contrôleurs restants prennent le contrôle de VXLAN et de DLR gérés par le contrôleur isolé
  • Le contrôleur affecté passe en mode lecture seule, annule ses sessions sur des hôtes et refuse les nouvelles
Les contrôleurs perdent la connectivité entre eux
  • Tous les contrôleurs passent en mode lecture seule, ferment les connexions aux hôtes et refusent les nouvelles
  • Les opérations de création, de mise à jour et de suppression des LIF et des itinéraires de tous les DLR (y compris dynamiques) échouent
  • La configuration du routage NSX (LIF) peut être désynchronisée entre NSX Manager et le cluster de contrôleurs, ce qui nécessite une intervention manuelle pour la resynchronisation
  • Les hôtes continueront à fonctionner avec le dernier état connu du plan de contrôle
Une VM de contrôleur est perdue
  • Le cluster de contrôleurs perd la redondance
  • Le plan de gestion/contrôle continue à fonctionner normalement
Deux VM de contrôleur sont perdues
  • Le contrôleur restant passera en mode lecture seule ; l'effet est le même que lorsque des contrôleurs perdent la connectivité entre eux (au-dessus). Récupération manuelle du cluster probablement nécessaire

Modules hôtes

netcpa repose sur la clé et le certificat SSL d'hôte, en plus des empreintes numériques SSL, pour établir des communications sécurisées avec les contrôleurs. Ces éléments sont obtenus auprès de NSX Manager via le bus de messages (fourni par vsfwd).

Si le processus d'échange de certificats échoue, netcpa ne pourra pas se connecter correctement aux contrôleurs.

Remarque : cette section n'aborde pas l'échec des modules de noyau, car son effet est grave (PSOD) et cela se produit rarement.

Tableau 3. Modes d'échec du module hôte et effets
Mode d'échec Effets de l'échec
vsfwd utilise l'authentification par nom d'utilisateur/mot de passe pour accéder au serveur de bus de messages, qui peut expirer
  • Si vsfwd sur un hôte ESXi récemment préparé ne peut pas atteindre NSX Manager dans les deux heures, le nom de connexion et le mot de passe temporaires fournis pendant l'installation expirent et le bus de messages sur cet hôte devient inopérable
Les effets de l'échec du client de bus de messages (vsfwd) dépendent du timing.
S'il échoue avant que d'autres éléments du plan de contrôle de NSX aient pu atteindre un état d'exécution stable
  • Le routage distribué sur l'hôte cesse de fonctionner, car l'hôte ne peut pas communiquer avec les contrôleurs
  • L'hôte n'apprend pas les instances du DLR de NSX Manager
S'il échoue une fois que l'hôte a atteint un état stable
  • Des passerelles ESG et des VM de contrôle du DLR exécutées sur l'hôte ne pourront pas recevoir des mises à jour de configuration
  • L'hôte n'apprend pas les nouveaux DLR et ne peut pas supprimer des DLR existants
  • Le chemin de données de l'hôte continuera de fonctionner selon la configuration de l'hôte au moment de l'échec
Tableau 4. Modes d'échec de netcpa et effets
Mode d'échec Effets de l'échec
Les effets de l'échec de l'agent de plan de contrôle (netcpa) dépendent du timing
S'il échoue avant que les modules de noyau du chemin de données de NSX aient pu atteindre un état d'exécution stable
  • Le routage distribué sur l'hôte cesse de fonctionner
S'il échoue une fois que l'hôte a atteint un état stable
  • Une ou des VM de contrôle du DLR exécutées sur l'hôte ne pourront pas envoyer les mises à jour de leur table de transfert aux contrôleurs
  • Le chemin de données du routage distribué ne recevra aucune mise à jour de LIF ou d'itinéraire de la part des contrôleurs, mais il continuera à fonctionner selon son état avant l'échec

VM de contrôle du DLR

Tableau 5. Modes d'échec de la VM de contrôle du DLR et effets
Mode d'échec Effets de l'échec
La VM de contrôle du DLR est perdue ou désactivée
  • Les opérations de création, de mise à jour et de suppression des LIF et des itinéraires de ce DLR échouent
  • Aucune mise à jour d'itinéraire dynamique ne sera envoyée aux hôtes (notamment retrait de préfixes reçus via des contiguïtés maintenant rompues)
La VM de contrôle du DLR perd la connectivité avec NSX Manager et les contrôleurs
  • Même effets que ci-dessus, sauf si la VM de contrôle du DLR et ses contiguïtés de routage sont toujours actives, le trafic vers et depuis des préfixes appris précédemment ne sera pas affecté
La VM de contrôle du DLR perd la connexion avec NSX Manager
  • Les opérations de création, de mise à jour et de suppression de NSX Manager pour les LIF et les itinéraires de ce DLR échoueront et ne seront pas retentées
  • Les mises à jour du routage dynamique continuent de se propager
La VM de contrôle du DLR perd la connexion avec les contrôleurs
  • Les modifications apportées au routage (statique ou dynamique) pour ce DLR ne se propagent pas sur les hôtes