Le service d'alarme est surchargé.

Lorsque l'événement est détecté : « En raison d'un volume important d'alarmes signalé, le service d'alarme est temporairement surchargé. L'interface utilisateur NSX et la NSX API GET /api/v1/alarms ont cessé de signaler de nouvelles alarmes ; cependant, les entrées Syslog et les interruptions SNMP (si elles sont activées) sont toujours émises en signalant les informations de l'événement sous-jacent. Lorsque les problèmes sous-jacents entraînant un volume d'alarmes important sont résolus, le service d'alarme recommence à signaler de nouvelles alarmes.  »

Lorsque l'événement est résolu : « Le volume important d'alarmes a diminué et les nouvelles alarmes sont de nouveau signalées.  »

Vérifiez toutes les alarmes actives sur la page Alarmes dans l'interface utilisateur de NSX ou à l'aide de la NSX API GET /api/v1/alarms?status=OPEN,ACKNOWLEDGED,SUPPRESSED. Pour chaque alarme active, recherchez la cause principale en suivant l'action recommandée pour l'alarme. Lorsqu'un nombre suffisant d'alarmes est résolu, le service d'alarme commencera à signaler de nouveau de nouvelles alarmes.

Volume important d'un type d'alarme spécifique détecté.

Lorsque l'événement est détecté : « En raison d'un volume important d'alarmes {event_id}, le service d'alarme a temporairement arrêté de signaler des alarmes de ce type. L'interface utilisateur NSX et la NSX API GET /api/v1/alarms ne signalent pas de nouvelles instances de ces alarmes ; cependant, les entrées Syslog et les interruptions SNMP (si elles sont activées) sont toujours émises en signalant les informations de l'événement sous-jacent. Lorsque les problèmes sous-jacents entraînant un volume important d'alarmes {event_id} sont résolus, le service d'alarme commence à signaler de nouvelles alarmes {event_id} lorsque de nouveaux problèmes sont détectés à nouveau.  »

Lorsque l'événement est résolu : « Le volume important d'alarmes {event_id} a diminué et de nouvelles alarmes de ce type sont de nouveau signalées.  »

Vérifiez toutes les alarmes actives de type {event_id} à l'aide de la page Alarmes dans l'interface utilisateur de NSX ou à l'aide de la NSX API GET /api/v1/alarms?status=OPEN,ACKNOWLEDGED,SUPPRESSED. Pour chaque alarme active, recherchez la cause principale en suivant l'action recommandée pour l'alarme. Lorsqu'un nombre suffisant d'alarmes est résolu, le service d'alarme commencera à signaler de nouveau de nouvelles alarmes {event_id}.

Au moins un des fichiers journaux surveillés n'est pas accessible en écriture.

Lorsque l'événement est détecté : « Au moins un des fichiers journaux surveillés dispose d'autorisations en lecture seule ou d'une propriété d'utilisateur/de groupe incorrecte sur les nœuds de gestionnaire, de gestionnaire global, de dispositif Edge, de passerelle de cloud public, de KVM ou de serveur physique Linux. Ou le dossier des journaux est manquant dans les nœuds de serveur physique Windows. Ou rsyslog.log est manquant sur les nœuds de gestionnaire, de gestionnaire global, de dispositif Edge ou de passerelle de cloud public.  »

Lorsque l'événement est résolu : « Tous les fichiers journaux surveillés disposent des autorisations de fichier et de la propriété correctes sur les nœuds de gestionnaire, de gestionnaire global, de dispositif Edge, de passerelle de cloud public, de KVM ou de serveur physique Linux. Et le dossier des journaux existe sur les nœuds de serveur physique Windows. Et rsyslog.log existe sur les nœuds de gestionnaire, de gestionnaire global, de dispositif Edge ou de passerelle de cloud public.  »

1. Sur les nœuds de gestionnaire et de gestionnaire global, les nœuds Edge et de passerelle de cloud public, les nœuds d'hôte Ubuntu KVM garantissent que les autorisations du répertoire /var/log sont 775 et que la propriété est root:syslog. Un nœud hôte Rhel KVM et BMS garantit que l'autorisation pour le répertoire /var/log est 755 et que la propriété est root:root.
2. Sur les nœuds de gestionnaire et de gestionnaire global, vérifiez que l'autorisation de fichier pour auth.log, nsx-audit.log, nsx-audit-write.log, rsyslog.log et Syslog sous /var/log est 640 et que la propriété est syslog:admin.
3. Sur les nœuds Edge et de passerelle de cloud public, assurez-vous que l'autorisation de fichier pour rsyslog.log et Syslog sous /var/log est 640 et que la propriété est syslog:admin.
4. Sur les nœuds d'hôte Ubuntu KVM et de serveur physique Ubuntu, assurez-vous que les autorisations de fichier pour d'auth.log et de vmware/nsx-syslog sous /var/log sont 640 et que la propriété est syslog:admin.
5. Sur les nœuds hôtes Rhel KVM et les nœuds de serveur physique Centos/Rhel/Sles, assurez-vous que l'autorisation de fichier de vmware/nsx-syslog sous /var/log est 640 et que la propriété est root:root.
6. Si l'un de ces fichiers dispose d'autorisations ou de propriété incorrectes, appelez les commandes chmod &ltmode&gt &ltpath&gt et chown &ltuser&gt:&ltgroup&gt &ltpath&gt.
7. Si rsyslog.log est manquant sur les nœuds de gestionnaire, de gestionnaire global, de dispositif Edge ou de passerelle de cloud public, appelez la commande de l'interface de ligne de commande NSX restart service syslog qui redémarre le service de journalisation et régénère /var/log/rsyslog.log.
8. Sur les nœuds de serveur physique Windows, assurez-vous que le dossier journal : C:\ProgramData\VMware\NSX\Logs existe. Si ce n'est pas le cas, réinstallez NSX sur les nœuds de serveur physique Windows.

Messages de journal non livrables en raison d'une configuration incorrecte du serveur de journalisation distant.

Lorsque l'événement est détecté : « Les messages de journal du serveur de connexion {hostname_or_ip_address_with_port} ({entity_id}) ne peuvent pas être distribués probablement en raison d'un nom de domaine complet non résolu, d'un certificat TLS non valide ou d'une règle iptables de dispositif NSX manquante.  »

Lorsque l'événement est résolu : « La configuration du serveur de journalisation {hostname_or_ip_address_with_port} ({entity_id}) s'affiche correctement.  »

1. Assurez-vous que {hostname_or_ip_address_with_port} est le nom d'hôte ou l'adresse IP et le port corrects.
2. Si le serveur de journalisation est spécifié à l'aide d'un nom de domaine complet, assurez-vous que le nom de domaine complet peut être résolu à partir du dispositif NSX à l'aide de la commande de l'interface de ligne de commande NSX nslookup &ltfqdn&gt. S'il ne peut pas être résolu, vérifiez que le nom de domaine complet correct est spécifié et que le serveur DNS du réseau dispose de l'entrée requise pour le nom de domaine complet.
3. Si le serveur de journalisation est configuré pour utiliser TLS, vérifiez que le certificat spécifié est valide. Par exemple, assurez-vous que le serveur de journalisation utilise réellement le certificat ou vérifiez que le certificat n'a pas expiré à l'aide de la commande openssl x509 -in &ltcert-file-path&gt -noout -dates.
4. Les dispositifs NSX utilisent des règles iptables pour autoriser explicitement le trafic sortant. Vérifiez que la règle iptables pour le serveur de journalisation est correctement configurée en appelant la commande verify logging-servers de l'interface de ligne de commande NSX qui reconfigure les règles iptables du serveur de journalisation si nécessaire.
5. Si pour une raison quelconque le serveur de journalisation est mal configuré, il doit être supprimé à l'aide de la commande CLI « del logging-server &lthostname-or-ip-address[:port]&gt proto &ltproto&gt level &ltlevel&gt » et ajouté de nouveau avec la bonne configuration.

Un seuil de capacité minimale a été dépassé.

Lorsque l'événement est détecté : Le nombre d'objets définis dans le système pour {capacity_display_name} a atteint {capacity_usage_count}, ce qui est supérieur au seuil de capacité minimal de {min_capacity_threshold} %.  »

Lorsque l'événement est résolu : « Le nombre d'objets définis dans le système pour {capacity_display_name} a atteint {capacity_usage_count}, et est inférieur ou au seuil de capacité minimal de {min_capacity_threshold} %.  »

Accédez à la page Capacité dans l'interface utilisateur NSX et vérifiez l'utilisation actuelle par rapport aux limites de seuil. Si l'utilisation actuelle est attendue, envisagez d'augmenter les valeurs de seuil minimales. Si l'utilisation actuelle est inattendue, vérifiez les stratégies réseau configurées pour diminuer l'utilisation au seuil ou en dessous du seuil minimal.

Un seuil de capacité maximale a été dépassé.

Lorsque l'événement est détecté : « Le nombre d'objets définis dans le système pour {capacity_display_name} a atteint {capacity_usage_count}, ce qui est supérieur au seuil de capacité maximal de {max_capacity_threshold} %.  »

Lorsque l'événement est résolu : « Le nombre d'objets définis dans le système pour {capacity_display_name} a atteint {capacity_usage_count}, ce qui est inférieur ou égal au seuil de capacité maximal de {max_capacity_threshold} %.  »

Accédez à la page Capacité dans l'interface utilisateur NSX et vérifiez l'utilisation actuelle par rapport aux limites de seuil. Si l'utilisation actuelle est attendue, envisagez d'augmenter les valeurs de seuil maximales. Si l'utilisation actuelle est inattendue, vérifiez les stratégies réseau configurées pour diminuer l'utilisation au seuil ou en dessous du seuil maximal.

Une capacité maximale a été dépassée.

Lorsque l'événement est détecté : Le nombre d'objets définis dans le système pour {capacity_display_name} a atteint {capacity_usage_count}, ce qui est supérieur au nombre maximal pris en charge de {max_supported_capacity_count}.  »

Lorsque l'événement est résolu : « Le nombre d'objets définis dans le système pour {capacity_display_name} a atteint {capacity_usage_count}, ce qui est égal ou inférieur au nombre maximal de {max_supported_capacity_count} pris en charge.  »

Assurez-vous que le nombre d'objets NSX créés est compris dans les limites prises en charge par NSX. S'il existe des objets inutilisés, supprimez-les à l'aide de l'interface utilisateur ou de la NSX API respective du système. Envisagez d'augmenter le facteur de forme de tous les nœuds de gestionnaire et/ou des nœuds Edge. Notez que le facteur de forme de chaque type de nœud doit être le même. Dans le cas contraire, les limites de capacité du facteur de forme le plus bas déployé sont utilisées.

Un certificat a expiré.

Lorsque l'événement est détecté : « Le certificat {entity_id} a expiré.  »

Lorsque l'événement est résolu : « Le certificat expiré {entity_id} a été supprimé ou n'a plus expiré.  »

Assurez-vous que les services qui utilisent actuellement le certificat sont mis à jour afin d'utiliser un nouveau certificat non expiré. Une fois que le certificat expiré n'est plus utilisé, il doit être supprimé en appelant la NSX API DELETE {api_collection_path}{entity_id}. Si le certificat expiré est utilisé par la plate-forme NAPP, la connexion est interrompue entre NSX et la plate-forme NAPP. Consultez le document de dépannage de la plate-forme NAPP pour utiliser un certificat d'autorité de certification NAPP auto-signé pour récupérer la connexion.

Un certificat est sur le point d'expirer

Lorsque l'événement est détecté : « Le certificat {entity_id} est sur le point d'expirer.  »

Lorsque l'événement est résolu : « Le certificat arrivant à expiration {entity_id} a été supprimé ou n'est plus sur le point d'expirer.  »

Assurez-vous que les services qui utilisent actuellement le certificat sont mis à jour pour utiliser un nouveau certificat non expiré. Une fois que le certificat arrivant à expiration n'est plus utilisé, il doit être supprimé en appelant la NSX API DELETE {api_collection_path}{entity_id}.

Un certificat approche de son expiration.

Lorsque l'événement est détecté : « Le certificat {entity_id} approche de son expiration.  »

Lorsque l'événement est résolu : « Le certificat arrivant à expiration {entity_id} a été supprimé ou n'approche plus de son expiration.  »

Assurez-vous que les services qui utilisent actuellement le certificat sont mis à jour pour utiliser un nouveau certificat non expiré. Une fois que le certificat arrivant à expiration n'est plus utilisé, il doit être supprimé en appelant la NSX API DELETE {api_collection_path}{entity_id}.

La mise à jour d'un bundle d'autorité de certification approuvée est recommandée.

Lorsque l'événement est détecté : « Le bundle d'autorité de certification approuvée {entity_id} a été mis à jour il y a plus de {ca_bundle_age_threshold} jours. La mise à jour du bundle d'autorité de certification approuvée est recommandée.  »

Lorsque l'événement est résolu : « Le bundle d'autorité de certification approuvée {entity_id} a été supprimé, mis à jour ou n'est plus utilisé.  »

Assurez-vous que les services qui utilisent actuellement le bundle d'autorité de certification approuvée sont mis à jour pour utiliser un bundle d'autorité de certification approuvée récemment mis à jour. À moins qu'il s'agisse d'un bundle fourni par le système, le bundle peut être mis à jour à l'aide de la NSX API PUT /policy/api/v1/infra/cabundles/{entity_id}. Une fois que le bundle expiré n'est plus utilisé, il doit être supprimé (s'il n'est pas fourni par le système) en appelant la NSX API DELETE /policy/api/v1/infra/cabundles/{entity_id}.

La mise à jour d'un bundle d'autorité de certification approuvée est suggérée.

Lorsque l'événement est détecté : « Le bundle d'autorité de certification approuvée {entity_id} a été mis à jour il y a plus de {ca_bundle_age_threshold} jours. La mise à jour du bundle d'autorité de certification approuvée est suggérée.  »

Lorsque l'événement est résolu : « Le bundle d'autorité de certification approuvée {entity_id} a été supprimé, mis à jour ou n'est plus utilisé.  »

Assurez-vous que les services qui utilisent actuellement le bundle d'autorité de certification approuvée sont mis à jour pour utiliser un bundle d'autorité de certification approuvée récemment mis à jour. À moins qu'il s'agisse d'un bundle fourni par le système, le bundle peut être mis à jour à l'aide de la NSX API PUT /policy/api/v1/infra/cabundles/{entity_id}. Une fois que le bundle expiré n'est plus utilisé, il doit être supprimé (s'il n'est pas fourni par le système) en appelant la NSX API DELETE /policy/api/v1/infra/cabundles/{entity_id}.

Un certificat a expiré.

Lorsque l'événement est détecté : « Le certificat a expiré pour le nœud de transport {entity_id}.  »

Lorsque l'événement est résolu : « Le certificat expiré pour le nœud de transport {entity_id} a été remplacé ou n'est plus expiré.  »

Remplacez le certificat du nœud de transport {entity_id} par un certificat non expiré. Le certificat expiré doit être remplacé en appelant la NSX API POST /api/v1/trust-management/certificates/action/replace-host-certificate/{entity_id}. Si le certificat expiré est utilisé par le nœud de transport, la connexion est interrompue entre le nœud de transport et le nœud de gestionnaire.

Un certificat est sur le point d'expirer

Lorsque l'événement est détecté : « Le certificat du nœud de transport {entity_id} est sur le point d'expirer.  »

Lorsque l'événement est résolu : « Le certificat arrivant à expiration pour le nœud de transport {entity_id} a été supprimé ou n'est plus sur le point d'expirer.  »

Remplacez le certificat du nœud de transport {entity_id} par un certificat non expiré. Le certificat expiré doit être remplacé en appelant la NSX API POST /api/v1/trust-management/certificates/action/replace-host-certificate/{entity_id}. Si le certificat n'est pas remplacé, la connexion entre le nœud de transport et le nœud de gestionnaire est interrompue lorsque le certificat expire.

Un certificat approche de son expiration.

Lorsque l'événement est détecté : « Le certificat du nœud de transport {entity_id} arrive à expiration.  »

Lorsque l'événement est résolu : « Le certificat arrivant à expiration pour le nœud de transport {entity_id} a été supprimé ou n'arrive plus à expiration.  »

Remplacez le certificat du nœud de transport {entity_id} par un certificat non expiré. Le certificat expiré doit être remplacé en appelant la NSX API POST /api/v1/trust-management/certificates/action/replace-host-certificate/{entity_id}. Si le certificat n'est pas remplacé, la connexion entre le nœud de transport et le nœud de gestionnaire est interrompue lorsque le certificat expire.

Le membre du groupe est inactif.

Lorsque l'événement est détecté : « Le membre du groupe {manager_node_id} du service {group_type} est inactif.  »

Lorsque l'événement est résolu : « Le membre du groupe {manager_node_id} de {group_type} est actif.  »

1. Appelez la commande « get cluster status » de l'interface de ligne de commande NSX pour afficher l'état des membres du groupe du cluster.
2. Assurez-vous que le service pour {group_type} est en cours d'exécution sur le nœud. Appelez la NSX API GET /api/v1/node/services/&ltservice_name&gt/status ou la commande CLI NSX get service &ltservice_name&gt pour déterminer si le service est en cours d'exécution. S'il n'est pas en cours d'exécution, appelez la NSX API POST /api/v1/node/services/&ltservice_name&gt?action=restart ou la CLI NSX restart service &ltservice_name&gt pour redémarrer le service.
3. Vérifiez si des erreurs sont signalées dans le fichier /var/log/ du service {group_type}.

Tous les membres du groupe du service sont inactifs.

Lorsque l'événement est détecté : « Tous les membres du groupe {manager_node_ids} du service {group_type} sont inactifs.  »

Lorsque l'événement est résolu : « Tous les membres du groupe {manager_node_ids} du service {group_type} sont actifs.  »

1. Assurez-vous que le service pour {group_type} est en cours d'exécution sur le nœud. Appelez la NSX API GET /api/v1/node/services/&ltservice_name&gt/status ou la commande CLI NSX get service &ltservice_name&gt pour déterminer si le service est en cours d'exécution. S'il n'est pas en cours d'exécution, appelez la NSX API POST /api/v1/node/services/&ltservice_name&gt?action=restart ou la CLI NSX restart service &ltservice_name&gt pour redémarrer le service.
2. Vérifiez si des erreurs sont signalées dans le fichier /var/log/ du service {group_type}.

Hyperbus sur DPU ne peut pas communiquer avec le nœud de gestionnaire.

Lorsque l'événement est détecté : « Hyperbus sur DPU {dpu_id} ne peut pas communiquer avec le nœud de gestionnaire.  »

Lorsque l'événement est résolu : « Hyperbus sur DPU {dpu_id} peut communiquer avec le nœud de gestionnaire.  »

L'interface hyperbus vmkernel (vmk50) sur DPU {dpu_id} peut être manquante. Reportez-vous à l'article de la base de connaissances https://kb.vmware.com/s/article/67432.

Hyperbus ne peut pas communiquer avec le nœud de gestionnaire.

Lorsque l'événement est détecté : « Hyperbus ne peut pas communiquer avec le nœud de gestionnaire.  »

Lorsque l'événement est résolu : « Hyperbus peut communiquer avec le nœud de gestionnaire.  »

L'interface Hyperbus vmkernel (vmk50) est peut-être manquante. Reportez-vous à l'article de la base de connaissances https://kb.vmware.com/s/article/67432.

Le collecteur indiqué est inaccessible via la ou les cartes vmknic sur le DVS indiqué sur DPU.

Lorsque l'événement est détecté : « Le collecteur {vertical_name} {collector_ip} est inaccessible via la ou les cartes vmknic (pile {stack_alias}) sur DVS {dvs_alias} sur DPU {dpu_id}, mais est accessible via la ou les cartes vmknic (pile {stack_alias}) sur d'autres DVS.  »

Lorsque l'événement est résolu : « Le collecteur {vertical_name} {collector_ip} est accessible via la ou les cartes vmknic (pile {stack_alias}) sur DVS {dvs_alias} sur DPU {dpu_id}, ou le collecteur {vertical_name} {collector_ip} est totalement inaccessible.  »

Si l'avertissement est activé, cela ne signifie pas que le collecteur est inaccessible. Les flux exportés générés par la verticale basée sur DVS {dvs_alias} peuvent toujours atteindre le collecteur {collector_ip} via la ou les cartes vmknic sur DVS en plus de DVS {dvs_alias}. Si cela n'est pas acceptable, l'utilisateur peut essayer de créer une ou plusieurs cartes vmknic avec la pile {stack_alias} sur DVS {dvs_alias} et la configurer avec l'adresse IPv4(6) appropriée, puis vérifier si le collecteur {vertical_name} {collector_ip} est accessible via la ou les cartes vmknic récemment créées sur DPU {dpu_id} en appelant vmkping {collector_ip} -S {stack_alias} -I vmkX avec SSH à DPU via ESXi activé.

Le collecteur indiqué est inaccessible via la ou les cartes vmknic existantes sur DPU.

Lorsque l'événement est détecté : « Le collecteur {vertical_name} {collector_ip} est inaccessible via la ou les cartes vmknic (pile {stack_alias}) sur n'importe quel DVS sur DPU {dpu_id}.  »

Lorsque l'événement est résolu : « Le collecteur {vertical_name} {collector_ip} est accessible avec la ou les cartes vmknic existantes (pile {stack_alias}) actuellement sur DPU {dpu_id}.  »

Pour rendre le collecteur accessible pour une verticale donnée sur le DVS, l'utilisateur doit s'assurer qu'il existe une ou plusieurs cartes vmknic avec la pile attendue {stack_alias} créées et configurées avec des adresses IPv4(6) appropriées, et que la connexion réseau au collecteur {vertical_name} {collector_ip} est également correcte. Par conséquent, l'utilisateur doit effectuer la vérification sur DPU {dpu_id} et effectuer la configuration requise pour s'assurer que la condition est remplie. Enfin, si vmkping {collector_ip} -S {stack_alias} avec SSH vers DPU via ESXi activé réussit, cela indique que le problème a disparu.

La latence réseau moyenne entre les nœuds de gestionnaire est élevée.

Lorsque l'événement est détecté : « La latence réseau moyenne entre les nœuds de gestionnaire {manager_node_id} ({appliance_address}) et {remote_manager_node_id} ({remote_appliance_address}) est supérieure à 10 ms au cours des 5 dernières minutes. »  »

Lorsque l'événement est résolu : « La latence réseau moyenne entre les nœuds de gestionnaire {manager_node_id} ({appliance_address}) et {remote_manager_node_id} ({remote_appliance_address}) est de 10 ms.  »

Assurez-vous qu'aucune règle de pare-feu ne bloque le trafic ping entre les nœuds de gestionnaire. S'il existe d'autres serveurs et applications à bande passante élevée partageant le réseau local, envisagez de les déplacer vers un autre réseau.

La connexion du plan de contrôle du nœud de transport au nœud de gestionnaire est inactive pendant un long moment.

Lorsque l'événement est détecté : « La connexion du plan de contrôle du nœud de transport {entity_id} au nœud de gestionnaire {appliance_address} est inactive pendant au moins {timeout_in_minutes} minutes du point de vue du nœud de transport.  »

Lorsque l'événement est résolu : « Le nœud de transport {entity_id} restaure la connexion du plan de contrôle vers le nœud de gestionnaire {appliance_address}.  »

1. Vérifiez la connectivité entre le nœud de transport {entity_id} et l'interface du nœud de gestionnaire {appliance_address} via un test ping. Si la commande ping n'est pas possible, vérifiez la fragilité de la connectivité réseau.
2. Vérifiez si les connexions TCP sont établies à l'aide de la sortie netstat pour déterminer si le service de contrôleur sur le nœud de gestionnaire {central_control_plane_id} écoute les connexions sur le port 1235. Si ce n'est pas le cas, vérifiez les règles de pare-feu (ou) iptables pour voir si le port 1235 bloque les demandes de connexion {entity_id} du nœud de transport. Assurez-vous qu'il n'y a pas de pare-feu d'hôte ou de pare-feu de réseau dans la sous-couche bloquant les ports IP requis entre les nœuds de gestionnaire et les nœuds de transport. Cela est documenté dans notre outil Ports et protocoles disponible ici : https://ports.vmware.com/.
3. Il est possible que le nœud de transport {entity_id} soit toujours en mode de maintenance. Vous pouvez vérifier si le nœud de transport est en mode de maintenance via l'API suivante : GET https://&ltnsx-mgr&gt/api/v1/transport-nodes/&lttn-uuid&gt. Lorsque le mode de maintenance est défini, le nœud de transport n'est pas connecté au service de contrôleur. Cela est généralement le cas lorsque la mise à niveau de l'hôte est en cours. Attendez quelques minutes et vérifiez de nouveau la connectivité.

La connexion du plan de contrôle du nœud de transport au nœud de gestionnaire est inactive.

Lorsque l'événement est détecté : « La connexion du plan de contrôle du nœud de transport {entity_id} au nœud de gestionnaire {appliance_address} est inactive pendant au moins {timeout_in_minutes} minutes du point de vue du nœud de transport. »

Lorsque l'événement est résolu : « Le nœud de transport {entity_id} restaure la connexion du plan de contrôle vers le nœud de gestionnaire {appliance_address}.  »

1. Vérifiez la connectivité entre le nœud de transport {entity_id} et l'interface du nœud de gestionnaire {appliance_address} via un test ping. Si la commande ping n'est pas possible, vérifiez la fragilité de la connectivité réseau.
2. Vérifiez si les connexions TCP sont établies à l'aide de la sortie netstat pour déterminer si le service de contrôleur sur le nœud de gestionnaire {central_control_plane_id} écoute les connexions sur le port 1235. Si ce n'est pas le cas, vérifiez les règles de pare-feu (ou) iptables pour voir si le port 1235 bloque les demandes de connexion {entity_id} du nœud de transport. Assurez-vous qu'il n'y a pas de pare-feu d'hôte ou de pare-feu de réseau dans la sous-couche bloquant les ports IP requis entre les nœuds de gestionnaire et les nœuds de transport. Cela est documenté dans notre outil ports et protocoles disponible ici : https://ports.vmware.com/.
3. Il est possible que le nœud de transport {entity_id} soit toujours en mode de maintenance. Vous pouvez vérifier si le nœud de transport est en mode de maintenance via l'API suivante : GET https://&ltnsx-mgr&gt/api/v1/transport-nodes/&lttn-uuid&gt. Lorsque le mode de maintenance est défini, le nœud de transport n'est pas connecté au service de contrôleur. Cela est généralement le cas lorsque la mise à niveau de l'hôte est en cours. Attendez quelques minutes et vérifiez de nouveau la connectivité. Remarque : cette alarme n'est pas critique et doit être résolue. GSS n'a pas besoin d'être contacté pour la notification de cette alarme, sauf si l'alarme reste non résolue pendant une période prolongée.

Le service de contrôleur pour la connexion du nœud de transport est inactif.

Lorsque l'événement est détecté : « Le service de contrôleur sur le nœud de gestionnaire {appliance_address} ({central_control_plane_id}) vers le nœud de transport {transport_node_name} ({entity_id}) est inactif pendant au moins trois minutes du point de vue du service de contrôleur.  »

Lorsque l'événement est résolu : « Le service de contrôleur sur le nœud de gestionnaire {appliance_address} ({central_control_plane_id}) rétablit la connexion au nœud de transport {entity_id}.  »

1. Vérifiez la connectivité à partir du service de contrôleur {central_control_plane_id} et de l'interface du nœud de transport {entity_id} à l'aide d'un test ping et de traceroute. Cela peut être effectué sur l'interface de ligne de commande d'admin du nœud NSX Manager. Le test ping ne doit pas voir d'abandons et doit avoir des valeurs de latence cohérentes. VMware recommande des valeurs de latence de 150 ms ou moins.
2. Accédez à Système | Infrastructure | Nœuds | Nœuds de transport {entity_id} sur l'interface utilisateur de NSX pour vérifier si la connexion TCP entre le service de contrôleur sur le nœud de gestionnaire {appliance_address} ({central_control_plane_id}) et le nœud de transport {entity_id} est établie. Si ce n'est pas le cas, vérifiez les règles de pare-feu sur le réseau et les hôtes pour voir si le port 1235 bloque les demandes de connexion {entity_id} du nœud de transport. Assurez-vous qu'il n'y a pas de pare-feu d'hôte ou de pare-feu de réseau dans la sous-couche bloquant les ports IP requis entre les nœuds de gestionnaire et les nœuds de transport. Cela est documenté dans notre outil ports et protocoles disponible ici : https://ports.vmware.com/.

Le service de contrôleur pour la connexion du nœud de transport est inactif pendant trop longtemps.

Lorsque l'événement est détecté : « Le service de contrôleur sur le nœud de gestionnaire {appliance_address} ({central_control_plane_id}) vers le nœud de transport {transport_node_name} ({entity_id}) est inactif pendant au moins 15 minutes du point de vue du service de contrôleur.  »

Lorsque l'événement est résolu : « Le service de contrôleur sur le nœud de gestionnaire {appliance_address} ({central_control_plane_id}) rétablit la connexion au nœud de transport {entity_id}.  »

1. Vérifiez la connectivité à partir du service de contrôleur {central_control_plane_id} et de l'interface du nœud de transport {entity_id} à l'aide d'un test ping et de traceroute. Cela peut être effectué sur l'interface de ligne de commande d'admin du nœud NSX Manager. Le test ping ne doit pas voir d'abandons et doit avoir des valeurs de latence cohérentes. VMware recommande des valeurs de latence de 150 ms ou moins.
2. Accédez à Système | Infrastructure | Nœuds | Nœuds de transport {entity_id} sur l'interface utilisateur de NSX pour vérifier si la connexion TCP entre le service de contrôleur sur le nœud de gestionnaire {appliance_address} ({central_control_plane_id}) et le nœud de transport {entity_id} est établie. Si ce n'est pas le cas, vérifiez les règles de pare-feu sur le réseau et les hôtes pour voir si le port 1235 bloque les demandes de connexion {entity_id} du nœud de transport. Assurez-vous qu'il n'y a pas de pare-feu d'hôte ou de pare-feu de réseau dans la sous-couche bloquant les ports IP requis entre les nœuds de gestionnaire et les nœuds de transport. Cela est documenté dans notre outil Ports et protocoles disponible ici : https://ports.vmware.com/.

Le canal entre le gestionnaire et le contrôleur est inactif.

Lorsque l'événement est détecté : « La communication entre la fonction de gestion et la fonction de contrôle a échoué sur le nœud de gestionnaire {manager_node_name} ({appliance_address}).  »

Lorsque l'événement est résolu : « La communication entre la fonction de gestion et la fonction de contrôle a été restaurée sur le nœud de gestionnaire {manager_node_name} ({appliance_address}).  »

1. Sur le nœud de gestionnaire {manager_node_name} ({appliance_address}), appelez la commande CLI NSX suivante : get service applianceproxy pour vérifier l'état du service périodiquement pendant 60 minutes.
2. Si le service n'est pas en cours d'exécution pendant plus de 60 minutes, appelez la commande d'interface de ligne de commande NSX suivante : restart service applianceproxy et revérifier l'état. Si le service est toujours en panne, contactez le support VMware.

Le canal de gestion vers le nœud de transport est inactif.

Lorsque l'événement est détecté : « Le canal de gestion vers le nœud de transport {transport_node_name} ({transport_node_address}) est inactif pendant 5 minutes.  »

Lorsque l'événement est résolu : « Le canal de gestion vers le nœud de transport {transport_node_name} ({transport_node_address}) est actif.  »

Assurez-vous qu'il existe une connectivité réseau entre les nœuds de gestionnaire et le nœud de transport {transport_node_name} ({transport_node_address}) et qu'aucun pare-feu ne bloque le trafic entre les nœuds. Sur les nœuds de transport Windows, assurez-vous que le service nsx-proxy est en cours d'exécution sur le nœud de transport en appelant la commande C:\NSX\nsx-proxy\nsx-proxy.ps1 status dans Windows PowerShell. S'il n'est pas en cours d'exécution, redémarrez-le en appelant la commande C:\NSX\nsx-proxy\nsx-proxy.ps1 restart. Sur tous les autres nœuds de transport, assurez-vous que le service nsx-proxy est en cours d'exécution sur le nœud de transport en appelant la commande /etc/init.d/nsx-proxy status. S'il n'est pas en cours d'exécution, redémarrez-le en appelant la commande /etc/init.d/nsx-proxy restart.

Le canal de gestion vers le nœud de transport est inactif pendant trop longtemps.

Lorsque l'événement est détecté : « Le canal de gestion vers le nœud de transport {transport_node_name} ({transport_node_address}) est inactif pendant 15 minutes. »

Lorsque l'événement est résolu : « Le canal de gestion vers le nœud de transport {transport_node_name} ({transport_node_address}) est actif.  »

Assurez-vous qu'il existe une connectivité réseau entre les nœuds de gestionnaire et le nœud de transport {transport_node_name} ({transport_node_address}) et qu'aucun pare-feu ne bloque le trafic entre les nœuds. Sur les nœuds de transport Windows, assurez-vous que le service nsx-proxy est en cours d'exécution sur le nœud de transport en appelant la commande C:\NSX\nsx-proxy\nsx-proxy.ps1 status dans Windows PowerShell. S'il n'est pas en cours d'exécution, redémarrez-le en appelant la commande C:\NSX\nsx-proxy\nsx-proxy.ps1 restart. Sur tous les autres nœuds de transport, assurez-vous que le service nsx-proxy est en cours d'exécution sur le nœud de transport en appelant la commande /etc/init.d/nsx-proxy status. S'il n'est pas en cours d'exécution, redémarrez-le en appelant la commande /etc/init.d/nsx-proxy restart.

Échec de la recherche DNS pour le nom de domaine complet du nœud de gestionnaire.

Lorsque l'événement est détecté : « Échec de la recherche DNS pour le nœud de gestionnaire {entity_id} avec le nom de domaine complet {appliance_fqdn} et l'indicateur publish_fqdns a été défini.  »

Lorsque l'événement est résolu : « Recherche FQDN réussie pour le nœud de gestionnaire {entity_id} avec le nom de domaine complet {appliance_fqdn} et l'indicateur publish_fqdns a été effacé.  »

1. Attribuez des noms de domaine complets corrects à tous les nœuds de gestionnaire et vérifiez que la configuration DNS est correcte pour la recherche réussie de tous les noms de domaine complets des nœuds de gestionnaire.
2. Vous pouvez également désactiver l'utilisation des noms de domaine complets en appelant la NSX API PUT /api/v1/configs/management avec publish_fqdns défini sur false dans le corps de la demande. Ensuite, les appels depuis les nœuds de transport et depuis Fédération vers les nœuds de gestionnaire dans ce cluster utiliseront uniquement des adresses IP.

Échec de la recherche DNS inversée pour l'adresse IP du nœud de gestionnaire.

Lorsque l'événement est détecté : « La recherche DNS inverse a échoué pour le nœud de gestionnaire {entity_id} avec l'adresse IP {appliance_address} et l'indicateur publish_fqdns a été défini.  »

Lorsque l'événement est résolu : « La recherche DNS inverse a échoué pour le nœud de gestionnaire {entity_id} avec l'adresse IP {appliance_address} ou l'indicateur publish_fqdns a été effacé.  »

1. Attribuez des noms de domaine complets corrects à tous les nœuds de gestionnaire et vérifiez que la configuration DNS est correcte pour une recherche inversée réussie de l'adresse IP du nœud de gestionnaire.
2. Vous pouvez également désactiver l'utilisation des noms de domaine complets en appelant la NSX API PUT /api/v1/configs/management avec publish_fqdns défini sur false dans le corps de la demande. Ensuite, les appels depuis les nœuds de transport et depuis Fédération vers les nœuds de gestionnaire dans ce cluster utiliseront uniquement des adresses IP.

Le canal de gestion vers le nœud de gestionnaire est inactif.

Lorsque l'événement est détecté : « Le canal de gestion vers le nœud de gestionnaire {manager_node_id} ({appliance_address}) est inactif pendant 5 minutes.  »

Lorsque l'événement est résolu : « Le canal de gestion vers le nœud de gestionnaire {manager_node_id} ({appliance_address}) est actif.  »

Assurez-vous qu'il existe une connectivité réseau entre le nœud de transport {transport_node_id} et le nœud de gestionnaire master. Assurez-vous également qu'aucun pare-feu ne bloque le trafic entre les nœuds. Assurez-vous que le service du gestionnaire de messagerie est en cours d'exécution sur les nœuds de gestionnaire en appelant la commande /etc/init.d/messaging-manager status. Si le gestionnaire de messagerie n'est pas en cours d'exécution, redémarrez-le en appelant la commande /etc/init.d/messaging-manager restart.

Le canal de gestion vers le nœud de gestionnaire est inactif pendant trop longtemps.

Lorsque l'événement est détecté : « Le canal de gestion vers le nœud de gestionnaire {manager_node_id} ({appliance_address}) est inactif pendant 15 minutes.  »

Lorsque l'événement est résolu : « Le canal de gestion vers le nœud de gestionnaire {manager_node_id} ({appliance_address}) est actif.  »

Assurez-vous qu'il existe une connectivité réseau entre le nœud de transport {transport_node_id} et les nœuds de gestionnaire master. Assurez-vous également qu'aucun pare-feu ne bloque le trafic entre les nœuds. Assurez-vous que le service du gestionnaire de messagerie est en cours d'exécution sur les nœuds de gestionnaire en appelant la commande /etc/init.d/messaging-manager status. Si le gestionnaire de messagerie n'est pas en cours d'exécution, redémarrez-le en appelant la commande /etc/init.d/messaging-manager restart.

La latence du réseau de gestion vers le nœud de transport est élevée.

Lorsque l'événement est détecté : « La latence réseau moyenne entre les nœuds de gestionnaire et l'hôte {transport_node_name} ({transport_node_address}) est supérieure à 150 ms pendant 5 minutes.  »

Lorsque l'événement est résolu : « La latence réseau moyenne entre les nœuds de gestionnaire et l'hôte {transport_node_name} ({transport_node_address}) est normale.  »

1. Attendez 5 minutes pour voir si l'alarme est résolue automatiquement.
2. Exécutez une commande ping sur le nœud de transport NSX à partir du nœud de gestionnaire. Le test ping ne doit pas voir d'abandons et doit avoir des valeurs de latence cohérentes. VMware recommande des valeurs de latence de 150 ms ou moins.
3. Recherchez d'autres problèmes de couche réseau physique. Si le problème persiste, contactez le support VMware.

Les adresses IP d'un pool d'adresses IP ont été épuisées.

Lorsque l'événement est détecté : Les adresses du pool d'adresses IP {entity_id} du serveur DHCP {dhcp_server_id} ont été épuisées. La dernière demande DHCP a échoué et les futures demandes échoueront.  »

Lorsque l'événement est résolu : « Le pool d'adresses IP {entity_id} du serveur DHCP {dhcp_server_id} n'est plus épuisé. Un bail a été alloué à la dernière demande DHCP.  »

Vérifiez la configuration du pool DHCP dans l'interface utilisateur de NSX ou sur le nœud Edge sur lequel le serveur DHCP s'exécute en appelant la commande get dhcp ip-pool de l'interface de ligne de commande NSX. Vérifiez également les baux actifs actuels sur le nœud Edge en appelant la commande get dhcp lease de l'interface de ligne de commande NSX. Comparez les baux au nombre de VM actives. Pensez à réduire la durée du bail sur la configuration du serveur DHCP si le nombre de VM est faible par rapport au nombre de baux actifs. Pensez également à développer la plage de pools pour le serveur DHCP en consultant la page Mise en réseau | Segments | Segment de l'interface utilisateur de NSX.

Un pool d'adresses IP est surchargé.

Lorsque l'événement est détecté : « L'utilisation du pool d'adresses IP {entity_id} du serveur DHCP {dhcp_server_id} approche de l'épuisement, avec {dhcp_pool_usage} % d'adresses IP allouées.  »

Lorsque l'événement est résolu : « Le pool d'adresses IP {entity_id} du serveur DHCP {dhcp_server_id} est tombé au-dessous du seuil d'utilisation élevé.  »

Vérifiez la configuration du pool DHCP dans l'interface utilisateur de NSX ou sur le nœud Edge sur lequel le serveur DHCP s'exécute en appelant la commande get dhcp ip-pool de l'interface de ligne de commande NSX. Vérifiez également les baux actifs actuels sur le nœud Edge en appelant la commande get dhcp lease de l'interface de ligne de commande NSX. Comparez les baux au nombre de VM actives. Pensez à réduire la durée du bail sur la configuration du serveur DHCP si le nombre de VM est faible par rapport au nombre de baux actifs. Pensez également à développer la plage de pools pour le serveur DHCP en consultant la page Mise en réseau | Segments | Segment de l'interface utilisateur de NSX.

L'utilisation du CPU de DFW est très élevée.

Lorsque l'événement est détecté : « L'utilisation du CPU de DFW sur le nœud de transport {entity_id} a atteint {system_resource_usage} %, ce qui est supérieur ou égal à la valeur de seuil très élevée de {system_usage_threshold} %.  »

Lorsque l'événement est résolu : « L'utilisation du CPU de DFW sur le nœud de transport {entity_id} a atteint {system_resource_usage} %, ce qui est inférieur à la valeur de seuil très élevée de {system_usage_threshold} %.  »

Pensez à rééquilibrer les charges de travail de VM sur cet hôte vers d'autres hôtes. Vérifiez la conception de la sécurité pour l’optimisation. Par exemple, utilisez la configuration applicable si les règles ne s'appliquent pas à l'ensemble du centre de données.

L'utilisation du CPU de DFW est très élevée sur DPU.

Lorsque l'événement est détecté : « L'utilisation du CPU de DFW sur le nœud de transport {entity_id} a atteint {system_resource_usage} % sur DPU {dpu_id}, ce qui est supérieur ou égal à la valeur de seuil très élevée de {system_usage_threshold} %.  »

Lorsque l'événement est résolu : « L'utilisation du CPU de DFW sur le nœud de transport {entity_id} a atteint {system_resource_usage} % sur DPU {dpu_id}, ce qui est inférieur à la valeur de seuil très élevée de {system_usage_threshold} %.  »

Pensez à rééquilibrer les charges de travail de VM sur cet hôte vers d'autres hôtes. Vérifiez la conception de la sécurité pour l’optimisation. Par exemple, utilisez la configuration applicable si les règles ne s'appliquent pas à l'ensemble du centre de données.

L'utilisation de la mémoire de DFW est très élevée.

Lorsque l'événement est détecté : « L'utilisation de la mémoire de DFW {heap_type} sur le nœud de transport {entity_id} a atteint {system_resource_usage} %, ce qui est supérieur ou égal à la valeur de seuil très élevée de {system_usage_threshold} %.  »

Lorsque l'événement est résolu : « L'utilisation de la mémoire de DFW {heap_type} sur le nœud de transport {entity_id} a atteint {system_resource_usage} %, ce qui est inférieur à la valeur de seuil très élevée de {system_usage_threshold} %.  »

Affichez l'utilisation actuelle de la mémoire DFW en appelant la commande get firewall thresholds de l'interface de ligne de commande NSX sur l'hôte. Pensez à rééquilibrer les charges de travail sur cet hôte vers d'autres hôtes.

L'utilisation de la mémoire de DFW est très élevée sur DPU.

Lorsque l'événement est détecté : « L'utilisation de la mémoire de DFW {heap_type} sur le nœud de transport {entity_id} a atteint {system_resource_usage} % sur DPU {dpu_id}, ce qui est supérieur ou égal à la valeur de seuil très élevée de {system_usage_threshold} %.  »

Lorsque l'événement est résolu : « L'utilisation de la mémoire de DFW {heap_type} sur le nœud de transport {entity_id} a atteint {system_resource_usage} % sur DPU {dpu_id}, ce qui est inférieur à la valeur de seuil très élevée de {system_usage_threshold} %.  »

Affichez l'utilisation actuelle de la mémoire DFW en appelant la commande get firewall thresholds de l'interface de ligne de commande NSX sur le DPU. Pensez à rééquilibrer les charges de travail sur cet hôte vers d'autres hôtes.

DFW vMotion a échoué, port déconnecté.

Lorsque l'événement est détecté : « Le filtre DFW vMotion pour DFW {entity_id} sur l'hôte {transport_node_name} de destination a échoué et le port de l'entité a été déconnecté.  »

Lorsque l'événement est résolu : « La configuration DFW pour le filtre DFW {entity_id} sur l'hôte de destination {transport_node_name} a réussi et une erreur causée par l'échec de DFW vMotion a été effacée.  »

Vérifiez les machines virtuelles sur l'hôte dans NSX Manager, renvoyez manuellement la configuration DFW via l'interface utilisateur de NSX Manager. La stratégie DFW à renvoyer peut être suivie par le filtre DFW {entity_id}. Pensez également à trouver la machine virtuelle à laquelle le filtre DFW est attaché et redémarrez-la.

La limite de propagation DFW a atteint le niveau d'avertissement.

Lorsque l'événement est détecté : « La limite de propagation DFW pour le filtre DFW {entity_id} sur l'hôte {transport_node_name} a atteint le niveau d'avertissement de 80 % de la limite configurée pour le protocole {protocol_name}.  »

Lorsque l'événement est résolu : « La condition de limite de propagation d'avertissement pour le filtre DFW {entity_id} sur l'hôte {transport_node_name} pour le protocole {protocol_name} est effacée.  »

Vérifiez les VM sur l'hôte dans NSX Manager, vérifiez le niveau d'avertissement de propagation configuré du filtre DFW {entity_id} pour le protocole {protocol_name}.

La limite de propagation DFW a atteint le niveau critique.

Lorsque l'événement est détecté : « La limite de propagation DFW pour le filtre DFW {entity_id} sur l'hôte {transport_node_name} a atteint le niveau critique de 98 % de la limite configurée pour le protocole {protocol_name}.  »

Lorsque l'événement est résolu : « La condition de limite de propagation critique pour le filtre DFW {entity_id} sur l'hôte {transport_node_name} pour le protocole {protocol_name} est effacée.  »

Vérifiez les VM sur l'hôte dans NSX Manager, vérifiez le niveau critique de propagation configuré du filtre DFW {entity_id} pour le protocole {protocol_name}.

Le nombre de sessions DFW est élevé.

Lorsque l'événement est détecté : « Le nombre de sessions DFW sur le nœud de transport {entity_id} a atteint {system_resource_usage} %, ce qui est supérieur ou égal à la valeur de seuil de {system_usage_threshold} %.  »

Lorsque l'événement est résolu : « Le nombre de sessions DFW sur le nœud de transport {entity_id} a atteint {system_resource_usage} %, ce qui est inférieur à la valeur de seuil très élevée de {system_usage_threshold} %.  »

Vérifiez le niveau de charge du trafic réseau des charges de travail sur l’hôte. Pensez à rééquilibrer les charges de travail sur cet hôte vers d'autres hôtes.

La limite de règles DFW par vNIC est sur le point de dépasser la limite maximale.

Lorsque l'événement est détecté : « La limite des règles DFW pour le VIF {entity_id} sur l'hôte de destination {transport_node_name} est sur le point de dépasser la limite maximale.  »

Lorsque l'événement est résolu : « La limite des règles DFW pour le VIF {entity_id} sur l'hôte de destination {transport_node_name} est passée sous la limite maximale.  »

Connectez-vous à l'hôte ESX {transport_node_name} et appelez la commande CLI NSX get firewall &ltVIF_UUID&gt ruleset rules pour obtenir les statistiques de règle pour les règles configurées sur le VIF correspondant. Réduisez le nombre de règles configurées pour le VIF {entity_id}.

La limite de règles DFW par vNIC approche de la limite maximale.

Lorsque l'événement est détecté : « La limite des règles DFW pour le VIF {entity_id} sur l'hôte de destination {transport_node_name} approche la limite maximale.  »

Lorsque l'événement est résolu : « La limite des règles DFW pour le VIF {entity_id} sur l'hôte de destination {transport_node_name} est passée sous le seuil.  »

Connectez-vous à l'hôte ESX {transport_node_name} et appelez la commande CLI NSX get firewall &ltVIF_UUID&gt ruleset rules pour obtenir les statistiques de règle pour les règles configurées sur le VIF correspondant. Réduisez le nombre de règles configurées pour le VIF {entity_id}.

La limite de règles DFW par hôte est sur le point de dépasser la limite maximale.

Lorsque l'événement est détecté : « La limite des règles DFW pour l'hôte {transport_node_name} est sur le point de dépasser la limite maximale.  »

Lorsque l'événement est résolu : « La limite des règles DFW pour l'hôte {transport_node_name} est passée sous la limite maximale.  »

Connectez-vous à l'hôte ESX {transport_node_name} et appelez la commande CLI NSX get firewall rule-stats total pour obtenir les statistiques de règle pour les règles configurées sur l'hôte ESX {transport_node_name}. Réduisez le nombre de règles configurées pour l'hôte {transport_node_name}. Vérifiez le nombre de règles configurées pour divers VIF à l'aide de la commande CLI NSX get firewall &ltVIF_UUID&gt ruleset rules. Réduisez le nombre de règles configurées pour divers VIF.

La limite de règles DFW par hôte approche de la limite maximale.

Lorsque l'événement est détecté : « La limite des règles DFW pour l'hôte {transport_node_name} approche de la limite maximale.  »

Lorsque l'événement est résolu : « La limite des règles DFW pour l'hôte {transport_node_name} est passée sous le seuil.  »

Connectez-vous à l'hôte ESX {transport_node_name} et appelez la commande CLI NSX get firewall rule-stats total pour obtenir les statistiques de règle pour les règles configurées sur l'hôte ESX {transport_node_name}. Réduisez le nombre de règles configurées pour l'hôte {transport_node_name}. Vérifiez le nombre de règles configurées pour divers VIF à l'aide de la commande CLI NSX get firewall &ltVIF_UUID&gt ruleset rules. Réduisez le nombre de règles configurées pour divers VIF.

Nombre maximal d'événements d'intrusion atteint.

Lorsque l'événement est détecté : « Le nombre d'événements d'intrusion dans le système est de {ids_events_count}, ce qui est supérieur à la valeur maximale autorisée de {max_ids_events_allowed}.  »

Lorsque l'événement est résolu : « Le nombre d'événements d'intrusion dans le système est de {ids_events_count}, ce qui est inférieur à la valeur maximale autorisée de {max_ids_events_allowed}.  »

Aucune intervention manuelle n’est requise. Une tâche de purge démarrera automatiquement toutes les 3 minutes et supprimera 10 % des anciens enregistrements pour ramener le nombre total d'événements d'intrusion dans le système à la valeur de seuil de 1,5 million d'événements.

L'utilisation de la mémoire du moteur NSX-IDPS atteint 75 % ou plus.

Lorsque l'événement est détecté : « L'utilisation de la mémoire du moteur NSX-IDPS a atteint {system_resource_usage} %, ce qui est supérieur ou égal à la valeur de seuil élevée de 75 %.  »

Lorsque l'événement est résolu : « L'utilisation de la mémoire du moteur NSX-IDPS a atteint {system_resource_usage} %, ce qui est inférieur à la valeur de seuil élevée de 75 %.  »

Pensez à rééquilibrer les charges de travail de VM sur cet hôte vers d'autres hôtes.

L'utilisation de la mémoire du moteur NSX-IDPS atteint 75 % ou plus sur DPU.

Lorsque l'événement est détecté : « L'utilisation de la mémoire du moteur NSX-IDPS a atteint {system_resource_usage} %, ce qui est supérieur ou égal à la valeur de seuil élevée de 75 % sur DPU {dpu_id}.  »

Lorsque l'événement est résolu : « L'utilisation de la mémoire du moteur NSX-IDPS a atteint sur DPU {dpu_id}, {system_resource_usage} %, ce qui est inférieur à la valeur de seuil élevée de 75 %.  »

Pensez à rééquilibrer les charges de travail de VM sur cet hôte vers d'autres hôtes.

L'utilisation de la mémoire du moteur NSX-IDPS atteint 85 % ou plus.

Lorsque l'événement est détecté : « L'utilisation de la mémoire du moteur NSX-IDPS a atteint {system_resource_usage} %, ce qui est supérieur ou égal à la valeur de seuil moyenne élevée de 85%.  »

Lorsque l'événement est résolu : « L'utilisation de la mémoire du moteur NSX-IDPS a atteint {system_resource_usage} %, ce qui est inférieur à la valeur de seuil moyenne élevée de 85 %.  »

Pensez à rééquilibrer les charges de travail de VM sur cet hôte vers d'autres hôtes.

L'utilisation de la mémoire du moteur NSX-IDPS atteint 85 % ou plus sur DPU.

Lorsque l'événement est détecté : « L'utilisation de la mémoire du moteur NSX-IDPS a atteint {system_resource_usage} %, ce qui est supérieur ou égal à la valeur de seuil moyenne élevée de 85 % sur DPU {dpu_id}.  »

Lorsque l'événement est résolu : « L'utilisation de la mémoire du moteur NSX-IDPS a atteint sur DPU {dpu_id}, {system_resource_usage} %, ce qui est inférieur à la valeur de seuil moyenne élevée de 85 %.  »

Pensez à rééquilibrer les charges de travail de VM sur cet hôte vers d'autres hôtes.

L'utilisation de la mémoire du moteur NSX-IDPS atteint 95% ou plus.

Lorsque l'événement est détecté : « L'utilisation de la mémoire du moteur NSX-IDPS a atteint {system_resource_usage} %, ce qui est supérieur ou égal à la valeur de seuil très élevée de 95 %.  »

Lorsque l'événement est résolu : « L'utilisation de la mémoire du moteur NSX-IDPS a atteint {system_resource_usage} %, ce qui est inférieur à la valeur de seuil très élevée de 95 %.  »

Pensez à rééquilibrer les charges de travail de VM sur cet hôte vers d'autres hôtes.

L'utilisation de la mémoire du moteur NSX-IDPS atteint 95 % ou plus sur DPU.

Lorsque l'événement est détecté : « L'utilisation de la mémoire du moteur NSX-IDPS a atteint {system_resource_usage} %, ce qui est supérieur ou égal à la valeur de seuil très élevée de 95 % sur DPU {dpu_id}.  »

Lorsque l'événement est résolu : « L'utilisation de la mémoire du moteur NSX-IDPS a atteint sur DPU {dpu_id}, {system_resource_usage} %, ce qui est inférieur à la valeur de seuil très élevée de 95 %.  »

Pensez à rééquilibrer les charges de travail de VM sur cet hôte vers d'autres hôtes.

L'utilisation du CPU du moteur NSX-IDPS atteint 75% ou plus.

Lorsque l'événement est détecté : « L'utilisation du CPU du moteur NSX-IDPS a atteint {system_resource_usage} %, ce qui est supérieur ou égal à la valeur de seuil élevée de 75 %.  »

Lorsque l'événement est résolu : « L'utilisation du CPU du moteur NSX-IDPS a atteint {system_resource_usage} %, ce qui est inférieur à la valeur de seuil élevée de 75 %.  »

Pensez à rééquilibrer les charges de travail de VM sur cet hôte vers d'autres hôtes.

L'utilisation du CPU du moteur NSX-IDPS atteint 85 % ou plus.

Lorsque l'événement est détecté : « L'utilisation du CPU du moteur NSX-IDPS a atteint {system_resource_usage} %, ce qui est supérieur ou égal à la valeur de seuil moyenne élevée de 85 %.  »

Lorsque l'événement est résolu : « L'utilisation du CPU du moteur NSX-IDPS a atteint {system_resource_usage} %, ce qui est inférieur à la valeur de seuil moyenne élevée de 85 %.  »

Pensez à rééquilibrer les charges de travail de VM sur cet hôte vers d'autres hôtes.

L'utilisation du CPU du moteur NSX-IDPS a dépassé 95 % ou plus.

Lorsque l'événement est détecté : « L'utilisation du CPU du moteur NSX-IDPS a atteint {system_resource_usage} %, ce qui est supérieur ou égal à la valeur de seuil très élevée de 95 %.  »

Lorsque l'événement est résolu : « L'utilisation du CPU du moteur NSX-IDPS a atteint {system_resource_usage} %, ce qui est inférieur à la valeur de seuil très élevée de 95 %.  »

Pensez à rééquilibrer les charges de travail de VM sur cet hôte vers d'autres hôtes.

NSX IDPS est activé via la stratégie NSX et les règles IDPS sont configurées, mais le moteur NSX-IDPS est inactif.

Lorsque l'événement est détecté : « NSX IDPS est activé via la stratégie NSX et les règles IDPS sont configurées, mais le moteur NSX-IDPS est inactif.  »

Lorsque l'événement est résolu : « NSX IDPS est dans l'un des cas ci-dessous. 1. NSX IDPS est désactivé via la stratégie NSX. 2. Le moteur NSX IDPS est activé, le moteur NSX IDPS et vdpi sont actifs, NSX IDPS a été activé et les règles IDPS sont configurées via la stratégie NSX.  »

1. Vérifiez /var/log/nsx-syslog.log pour voir si des erreurs sont signalées.
2. Appelez la commande NSX CLI get ids engine status pour vérifier si NSX IDPS distribué est dans un état désactivé. Si c'est le cas, appelez /etc/init.d/nsx-idps start pour démarrer le service.
3. Appelez /etc/init.d/nsx-vdpi status pour vérifier si nsx-vdpi est en cours d'exécution. Si ce n'est pas le cas, appelez /etc/init.d/nsx-vdpi start pour démarrer le service.

NSX IDPS est activé via la stratégie NSX et les règles IDPS sont configurées, mais le moteur NSX-IDPS est inactif sur DPU.

Lorsque l'événement est détecté : « NSX IDPS est activé via la stratégie NSX et les règles IDPS sont configurées, mais le moteur NSX-IDPS est inactif sur DPU {dpu_id}.  »

Lorsque l'événement est résolu : « NSX IDPS se trouve dans l'un des cas ci-dessous sur DPU {dpu_id}. 1. NSX IDPS est désactivé via la stratégie NSX. 2. Le moteur NSX IDPS est activé, le moteur NSX IDPS et vdpi sont actifs, NSX IDPS a été activé et les règles IDPS sont configurées via la stratégie NSX.  »

1. Vérifiez /var/log/nsx-idps/nsx-idps.log et /var/log/nsx-syslog.log pour voir si des erreurs sont signalées.
2. Appelez la commande NSX CLI get ids engine status pour vérifier si NSX IDPS distribué est dans un état désactivé. Si c'est le cas, appelez /etc/init.d/nsx-idps start pour démarrer le service.
3. Appelez /etc/init.d/nsx-vdpi status pour vérifier si nsx-vdpi est en cours d'exécution. Si ce n'est pas le cas, appelez /etc/init.d/nsx-vdpi start pour démarrer le service.

L'utilisation du CPU pour le moteur IDPS distribué est élevée.

Lorsque l'événement est détecté : « L'utilisation du CPU pour le moteur IDPS distribué est supérieure ou égale à la valeur de seuil élevée de {system_usage_threshold} %.  »

Lorsque l'événement est résolu : « L'utilisation du CPU pour le moteur IDPS distribué est inférieure à la valeur de seuil élevée de {system_usage_threshold} %.  »

Vérifiez la raison du surabonnement. Déplacez certaines applications vers un autre hôte.

L'utilisation du CPU pour le moteur IDPS distribué est très élevée.

Lorsque l'événement est détecté : « L'utilisation du CPU pour le moteur IDPS distribué est supérieure ou égale à la valeur de seuil très élevée de {system_usage_threshold} %.  »

Lorsque l'événement est résolu : « L'utilisation du CPU pour le moteur IDPS distribué est inférieure à la valeur de seuil très élevée de {system_usage_threshold} %.  »

Vérifiez la raison du surabonnement. Déplacez certaines applications vers un autre hôte.

L'utilisation du réseau pour le moteur IDPS distribué est élevée.

Lorsque l'événement est détecté : « L'utilisation du réseau pour le moteur IDPS distribué est supérieure ou égale à la valeur de seuil élevée de {system_usage_threshold} %.  »

Lorsque l'événement est résolu : « L'utilisation du réseau pour le moteur IDPS distribué est inférieure à la valeur de seuil élevée de {system_usage_threshold} %.  »

Vérifiez la raison du surabonnement. Vérifiez les règles IDPS pour réduire la quantité de trafic soumis au service IDPS.

L'utilisation du réseau pour le moteur IDPS distribué est très élevée.

Lorsque l'événement est détecté : « L'utilisation du réseau pour le moteur IDPS distribué est supérieure ou égale à la valeur de seuil très élevée de {system_usage_threshold} %.  »

Lorsque l'événement est résolu : « L'utilisation du réseau pour le moteur IDPS distribué est inférieure à la valeur de seuil très élevée de {system_usage_threshold} %.  »

Vérifiez la raison du surabonnement. Vérifiez les règles IDPS pour réduire la quantité de trafic soumis au service IDPS.

Le moteur IDPS distribué a abandonné le trafic en raison d'un surabonnement de CPU.

Lorsque l'événement est détecté : « Le moteur IDPS ne dispose pas de ressources de CPU suffisantes et ne peut pas suivre le rythme du trafic entrant, ce qui entraîne l'abandon du trafic en excès. Pour plus d'informations, connectez-vous à l'hôte ESX, exécutez la commande suivante : vsipioctl getdpiinfo -s et examinez les statistiques de surabonnement.  »

Lorsque l'événement est résolu : « Le moteur IDPS distribué dispose de ressources de CPU adéquates et n'annule aucun trafic.  »

Vérifiez la raison du surabonnement. Déplacez certaines applications vers un autre hôte.

Le moteur IDPS distribué a abandonné le trafic en raison d'un surabonnement réseau.

Lorsque l'événement est détecté : « Le moteur IDPS ne parvient pas à suivre le rythme du trafic entrant, ce qui entraîne l'abandon du trafic excessif. Pour plus d'informations, connectez-vous à l'hôte ESX, exécutez la commande suivante : vsipioctl getdpiinfo -s et examinez les statistiques de surabonnement.  »

Lorsque l'événement est résolu : « Le moteur IDPS distribué n'annule aucun trafic.  »

Vérifiez la raison du surabonnement. Vérifiez les règles IDPS pour réduire la quantité de trafic soumis au service IDPS.

Le moteur IDPS distribué a contourné le trafic en raison d'un surabonnement de CPU.

Lorsque l'événement est détecté : « Le moteur IDPS ne dispose pas de ressources de CPU suffisantes et ne peut pas suivre le rythme du trafic entrant, ce qui entraîne le contournement du trafic en excès. Pour plus d'informations, connectez-vous à l'hôte ESX, exécutez la commande suivante : vsipioctl getdpiinfo -s et examinez les statistiques de surabonnement.  »

Lorsque l'événement est résolu : « Le moteur IDPS distribué dispose de ressources de CPU adéquates et n'utilise aucun trafic.  »

Vérifiez la raison du surabonnement. Déplacez certaines applications vers un autre hôte.

Le moteur IDPS distribué a contourné le trafic en raison d'un surabonnement réseau.

Lorsque l'événement est détecté : « Le moteur IDPS ne peut pas suivre le rythme du trafic entrant, ce qui entraîne le contournement du trafic excessif. Pour plus d'informations, connectez-vous à l'hôte ESX, exécutez la commande suivante : vsipioctl getdpiinfo -s et examinez les statistiques de surabonnement.  »

Lorsque l'événement est résolu : « Le moteur IDPS distribué ne contourne aucun trafic.  »

Vérifiez la raison du surabonnement. Vérifiez les règles IDPS pour réduire la quantité de trafic soumis au service IDPS.

Un redirecteur DNS est inactif.

Lorsque l'événement est détecté : « Le redirecteur DNS {entity_id} n'est pas en cours d'exécution. Cela affecte le redirecteur DNS identifié actuellement activé.  »

Lorsque l'événement est résolu : « Le redirecteur DNS {entity_id} s'exécute de nouveau.  »

1. Appelez la commande get dns-forwarders status de l'interface de ligne de commande NSX pour vérifier si le redirecteur DNS se trouve dans un état inactif.
2. Vérifiez /var/log/syslog pour voir si des erreurs sont signalées.
3. Collectez un bundle de support et contactez l'équipe du support NSX.

Un redirecteur DNS est désactivé.

Lorsque l'événement est détecté : « Le redirecteur DNS {entity_id} est désactivé.  »

Lorsque l'événement est résolu : « Le redirecteur DNS {entity_id} est activé.  »

1. Appelez la commande get dns-forwarders status de l'interface de ligne de commande NSX pour vérifier si le redirecteur DNS se trouve dans un état désactivé.
2. Utilisez l'API de stratégie NSX ou l'API de gestionnaire pour activer le redirecteur DNS qui ne doit pas être dans l'état désactivé.

Un serveur en amont du redirecteur DNS a expiré.

Lorsque l'événement est détecté : « Le redirecteur DNS {intent_path}({dns_id}) n'a pas reçu de réponse en temps opportun du serveur en amont {dns_upstream_ip}. La connectivité de l'instance de calcul aux noms de domaine complets expirés peut être affectée.  »

Lorsque l'événement est résolu : « Le serveur en amont du redirecteur DNS {intent_path}({dns_id}) {dns_upstream_ip} est normal.  »

1. Appelez la NSX API GET /api/v1/dns/forwarders/{dns_id}/nslookup? address=&ltaddress&gt&server_ip={dns_upstream_ip}&source_ip=&ltsource_ip&gt. Cette demande d'API déclenche une recherche DNS sur le serveur en amont dans l'espace de noms réseau du redirecteur DNS. &ltaddress&gt est l'adresse IP ou le nom de domaine complet dans le même domaine que le serveur en amont. &Ltsource_ip&gt est une adresse IP dans la zone du serveur en amont. Si l'API renvoie une réponse de connexion expirée, il existe probablement une erreur réseau ou un problème de serveur en amont. Vérifiez pourquoi les recherches DSN n'atteignent pas le serveur en amont ou pourquoi le serveur en amont ne renvoie pas de réponse. Si la réponse de l'API indique que le serveur en amont répond, passez à l'étape 2.
2. Appelez la NSX API GET /api/v1/dns/forwarders/{dns_id}/nslookup? address=&ltaddress&gt. Cette demande d'API déclenche une recherche DNS vers le redirecteur DNS. Si l'API renvoie une réponse valide, le serveur en amont peut avoir récupéré et cette alarme devra être résolue en quelques minutes. Si l'API renvoie une réponse de connexion expirée, passez à l'étape 3.
3. Appelez la commande de l'interface de ligne de commande NSX « get dns-forwarder {dns_id} live-debug server-ip {dns_upstream_ip} ». Cette commande déclenche le débogage en direct sur le serveur en amont et journalise les détails et les statistiques indiquant pourquoi le redirecteur DNS n'obtient pas de réponse.

Incompatibilité des paramètres de nœud Edge.

Lorsque l'événement est détecté : « La configuration des paramètres du nœud Edge {entity_id} ne correspond pas à celle de l'intention de stratégie. La configuration du nœud Edge visible par l'utilisateur sur l'interface utilisateur ou l'API n'est pas la même que celle réalisée. Les modifications réalisées du nœud Edge apportées par l'utilisateur en dehors de NSX Manager sont affichées dans les détails de cette alarme et toutes les modifications apportées à l'interface utilisateur ou à l'API remplaceront la configuration réalisée. Les champs qui diffèrent pour le nœud Edge sont répertoriés dans les données d'exécution {edge_node_setting_mismatch_reason} « 

Lorsque l'événement est résolu : « Les paramètres de nœud {entity_id} du nœud Edge sont désormais cohérents avec l'intention de stratégie.  »

Vérifiez les paramètres de ce nœud de transport Edge {entity_id}. Exécutez l'une des actions suivantes pour résoudre l'alarme -
1. Mettez à jour manuellement l'intention de stratégie du paramètre du nœud de transport Edge à l'aide de l'API - PUT https://&ltmanager-ip&gt/api/v1/transport-nodes/&lttn-id&gt.
2. Acceptez les paramètres d'intention ou de nœud Edge réalisés pour ce nœud de transport Edge via le programme de résolution de nœud de transport Edge pour résoudre cette alarme.
3. Résolvez l'alarme en acceptant la configuration des paramètres du nœud Edge à l'aide de l'API POST d'actualisation - https://&ltmanager-ip&gt/api/v1/transport-nodes/&lttn-id&gt?action=refresh_node_configuration&resource_type=EdgeNode.

Incompatibilité des paramètres vSphere de la VM Edge.

Lorsque l'événement est détecté : « La configuration du nœud Edge {entity_id} sur vSphere ne correspond pas à la configuration de l'intention de stratégie. La configuration du nœud Edge visible par l'utilisateur sur l'interface utilisateur ou l'API n'est pas la même que celle réalisée. Les modifications réalisées du nœud Edge apportées par l'utilisateur en dehors de NSX Manager sont affichées dans les détails de cette alarme et toutes les modifications apportées à l'interface utilisateur ou à l'API remplaceront la configuration réalisée. Les champs qui diffèrent pour le nœud Edge sont répertoriés dans les données d'exécution {edge_vm_vsphere_settings_mismatch_reason} « 

Lorsque l'événement est résolu : « Les paramètres vSphere de la VM du nœud Edge {entity_id} sont désormais cohérents avec l'intention de la stratégie.  »

Vérifiez la configuration vSphere de ce nœud de transport Edge {entity_id}. Exécutez l'une des actions suivantes pour résoudre l'alarme -
1. Acceptez les paramètres d'intention ou de nœud Edge vSphere réalisés pour ce nœud de transport Edge via le programme de résolution de nœud de transport Edge pour résoudre cette alarme.
2. Résolvez l'alarme en acceptant la configuration réalisée vSphere du nœud Edge à l'aide de l'API POST d'actualisation - https://&ltmanager-ip&gt/api/v1/transport-nodes/&lttn-id&gt?action=refresh_node_configuration&resource_type=EdgeNode.

Les paramètres du nœud Edge et les paramètres vSphere sont modifiés.

Lorsque l'événement est détecté : « Les paramètres du nœud Edge {entity_id} et la configuration de vSphere sont modifiés et ne correspondent pas à la configuration de l'intention de stratégie. La configuration du nœud Edge visible par l'utilisateur sur l'interface utilisateur ou l'API n'est pas la même que celle réalisée. Les modifications réalisées du nœud Edge apportées par l'utilisateur en dehors de NSX Manager sont affichées dans les détails de cette alarme et toutes les modifications apportées à l'interface utilisateur ou à l'API remplaceront la configuration réalisée. Les champs qui diffèrent pour les paramètres du nœud Edge et la configuration de vSphere sont répertoriés dans les données d'exécution {edge_node_settings_and_vsphere_settings_mismatch_reason} « 

Lorsque l'événement est résolu : « Les paramètres de nœud {entity_id} du nœud Edge et les paramètres vSphere sont désormais cohérents avec l'intention de stratégie.  »

Vérifiez les paramètres du nœud et la configuration vSphere de ce nœud de transport Edge {entity_id}. Exécutez l'une des actions suivantes pour résoudre l'alarme -
1. Mettez à jour manuellement l'intention de stratégie du paramètre de nœud de transport Edge à l'aide de l'API : PUT https://&ltmanager-ip&gt/api/v1/transport-nodes/&lttn-id&gt.
2. Acceptez l'intention ou la configuration du nœud Edge réalisée par vSphere ou les paramètres du nœud Edge réalisé pour ce nœud de transport Edge via le programme de résolution de nœud de transport Edge pour résoudre cette alarme.
3. Résolvez l'alarme en acceptant la configuration réalisée par vSphere et les paramètres du nœud Edge à l'aide de l'API d'actualisation - POST https://&ltmanager-ip&gt/api/v1/transport-nodes/&lttn-id&gt?action=refresh_node_configuration&resource_type=EdgeNode.

Incompatibilité d'emplacement de vSphere Edge.

Lorsque l'événement est détecté : « Le nœud Edge {entity_id} a été déplacé à l'aide de vMotion. La configuration du nœud Edge {entity_id} sur vSphere ne correspond pas à la configuration de l'intention de stratégie. La configuration du nœud Edge visible par l'utilisateur sur l'interface utilisateur ou l'API n'est pas la même que celle réalisée. Les modifications réalisées du nœud Edge effectuées par l'utilisateur en dehors de NSX Manager sont affichées dans les détails de cette alarme. Les champs qui diffèrent pour le nœud Edge sont répertoriés dans les données d'exécution {edge_vsphere_location_mismatch_reason}. « 

Lorsque l'événement est résolu : « Les paramètres vSphere de nœud du nœud Edge {entity_id} sont désormais cohérents avec l'intention de la stratégie.  »

Vérifiez la configuration vSphere de ce nœud de transport Edge {entity_id}. Exécutez l'une des actions suivantes pour résoudre l'alarme -
1. Résolvez l'alarme en acceptant la configuration réalisée vSphere du nœud Edge à l'aide de l'API POST d'actualisation - https://&ltmanager-ip&gt/api/v1/transport-nodes/&lttn-id&gt?action=refresh_node_configuration&resource_type=EdgeNode.
2. Si vous souhaitez revenir à l'emplacement précédent, utilisez l'API de redéploiement NSX - POST https://&ltmanager-ip&gt/api/v1/transport-nodes/&lttn-id&gt?action=redeploy. Le déplacement vMotion vers l'hôte d'origine n'est pas pris en charge.

La machine virtuelle Edge automatique est présente dans l'inventaire NSX, mais pas dans vCenter.

Lorsque l'événement est détecté : « La machine virtuelle {policy_edge_vm_name} avec l'ID MoRef {vm_moref_id} correspondant aux paramètres de placement vSphere du nœud de transport Edge {entity_id} est trouvée dans l'inventaire NSX, mais n'est pas présente dans vCenter. Vérifiez si la machine virtuelle a été supprimée dans vCenter ou si elle est présente avec un ID MoRef de VM différent. »

Lorsque l'événement est résolu : « Le nœud Edge {entity_id} portant l'ID MoRef de machine virtuelle {vm_moref_id} est présent dans l'inventaire NSX et dans vCenter.  »

L'ID MoRef de référence d'objet géré d'une machine virtuelle a le format vm-number, qui est visible dans l'URL lors de la sélection de la machine virtuelle Edge dans l'interface utilisateur de vCenter. Exemple vm-12011 in https://&ltvc-url>/ui/app/vm;nav=h/urn:vmomi:VirtualMachine:vm-12011:164ff798-c4f1-495b-a0be-adfba337e5d2/summary Recherchez la machine virtuelle {policy_edge_vm_name} avec l'ID moref {vm_moref_id} dans vCenter pour ce nœud de transport Edge {entity_id}. Si la machine virtuelle Edge est présente dans vCenter avec un autre ID MoRef, suivez l'action ci-dessous. Utilisez l'API d'ajout ou de mise à jour du placement NSX avec des propriétés de charge utile de demande JSON vm_id et vm_deployment_config pour mettre à jour les nouveaux paramètres de déploiement d'ID MoRef de VM et vSphere. POST https://&ltmanager-ip&gt/api/v1/transport-nodes/&lttn-id&gt?action=addOrUpdatePlacementReferences. Si la machine virtuelle Edge portant le nom {policy_edge_vm_name} n'est pas présente dans vCenter, utilisez l'API de redéploiement de NSX pour déployer une nouvelle machine virtuelle pour le nœud Edge. POST https://&ltmanager-ip&gt/api/v1/transport-nodes/&lttn-id&gt?action=redeploy.

La machine virtuelle Edge automatique n'est pas présente à la fois dans l'inventaire NSX et dans vCenter.

Lorsque l'événement est détecté : « La machine virtuelle {policy_edge_vm_name} avec l'ID MoRef {vm_moref_id} correspondant aux paramètres de placement vSphere du nœud de transport Edge {entity_id} n'est trouvée ni dans l'inventaire NSX ni dans vCenter. Les paramètres de placement dans la configuration vSphere de ce nœud de transport Edge {entity_id} font référence à la machine virtuelle avec moref {vm_moref_id}.  »

Lorsque l'événement est résolu : « Le nœud Edge {entity_id} portant l'ID MoRef de machine virtuelle {vm_moref_id} est présent dans l'inventaire NSX et dans vCenter.  »

L'ID MoRef de référence d'objet géré d'une machine virtuelle a le format vm-number, qui est visible dans l'URL lors de la sélection de la machine virtuelle Edge dans l'interface utilisateur de vCenter. Exemple m-12011 in https://&ltvc-url>/ui/app/vm;nav=h/urn:vmomi:VirtualMachine:vm-12011:164ff798-c4f1-495b-a0be-adfba337e5d2/summary Recherchez la machine virtuelle {policy_edge_vm_name} avec l'ID moref {vm_moref_id} dans vCenter pour ce nœud de transport Edge {entity_id}. Suivez l'action ci-dessous pour résoudre l'alarme : vérifiez si la VM a été supprimée dans vSphere ou si elle est présente avec un id Moref différent.
1. Si la machine virtuelle est toujours présente dans vCenter, mettez le nœud de transport Edge en mode de maintenance, puis mettez la machine virtuelle Edge hors tension et supprimez-la dans vCenter. Utilisez l'API de redéploiement NSX pour déployer une nouvelle machine virtuelle pour le nœud Edge. Le trafic de données pour le nœud de transport Edge sera interrompu pendant la durée intermédiaire si la machine virtuelle Edge transfère le trafic.
2. Si la machine virtuelle n'est pas présente dans vCenter, utilisez l'API de redéploiement pour déployer une nouvelle machine virtuelle pour le nœud Edge. POST https://&ltmanager-ip&gt/api/v1/transport-nodes/&lttn-id&gt?action=redeploy.

L'opération de mise hors tension et de suppression a échoué pour l'ancienne machine virtuelle Edge dans vCenter lors du redéploiement.

Lorsque l'événement est détecté : « Échec de la mise hors tension et de la suppression de la VM du nœud Edge {entity_id} avec l'ID MoRef {vm_moref_id} dans vCenter lors de l'opération de redéploiement. Une nouvelle machine virtuelle Edge avec l'ID MoRef {new_vm_moref_id} a été déployée. Les anciennes et nouvelles machines virtuelles de ce dispositif Edge fonctionnent en même temps et peuvent entraîner des conflits d'adresses IP et des problèmes de mise en réseau.  »

Lorsque l'événement est résolu : « Le nœud Edge {entity_id} portant l'ID MoRef de machine virtuelle périmé {vm_moref_id} n'est plus présent dans l'inventaire NSX et dans vCenter. La machine virtuelle nouvellement déployée portant l'ID Moref {new_vm_moref_id} est présente dans l'inventaire NSX et dans vCenter.  »

L'ID MoRef de référence d'objet géré d'une machine virtuelle a le format vm-number, qui est visible dans l'URL lors de la sélection de la machine virtuelle Edge dans l'interface utilisateur de vCenter. Exemple m-12011 in https://&ltvc-url>/ui/app/vm;nav=h/urn:vmomi:VirtualMachine:vm-12011:164ff798-c4f1-495b-a0be-adfba337e5d2/summary Recherchez la machine virtuelle {policy_edge_vm_name} avec l'ID moref {vm_moref_id} dans vCenter pour ce nœud de transport Edge {entity_id}. Mettez hors tension et supprimez l'ancienne machine virtuelle Edge {policy_edge_vm_name} avec il'd moref {vm_moref_id} dans vCenter.

Le nœud Edge présente une incompatibilité de version matérielle.

Lorsque l'événement est détecté : « Le nœud Edge {transport_node_name} dans le cluster Edge {edge_cluster_name} dispose d'une version matérielle {edge_tn_hw_version} qui est inférieure à la version matérielle la plus élevée {edge_cluster_highest_hw_version} dans le cluster Edge.  »

Lorsque l'événement est résolu : « L'incompatibilité de version matérielle du nœud Edge {transport_node_name} est désormais résolue.  »

Suivez l'article de la base de connaissances pour résoudre l'alarme d'incompatibilité de version matérielle pour le nœud Edge {transport_node_name}.

Alarme de panne de déplacement du membre du cluster Edge

Lorsque l'événement est détecté : « L'opération sur le cluster Edge {edge_cluster_id} pour déplacer tout le contexte de service a échoué pour l'index de membre du cluster Edge {member_index_id} avec l'ID de nœud de transport {transport_node_id}

Lorsque l'événement est résolu : « L'échec du déplacement du nœud Edge avec {transport_node_id} a été résolu.  »

Vérifiez la capacité disponible pour le cluster Edge. Si une capacité supplémentaire est requise, mettez à l'échelle votre cluster Edge. Réessayez l'opération de déplacement d'un membre du cluster Edge.

L'utilisation du CPU du nœud Edge est très élevée.

Lorsque l'événement est détecté : « L'utilisation du CPU sur le nœud Edge {entity_id} a atteint {system_resource_usage} %, ce qui est supérieur ou égal à la valeur de seuil très élevée de {system_usage_threshold} %.  »

Lorsque l'événement est résolu : « L'utilisation du CPU de sur le nœud Edge {entity_id} a atteint {system_resource_usage} %, ce qui est inférieur à la valeur de seuil très élevée de {system_usage_threshold} %.  »

Vérifiez la configuration, les services en cours d'exécution et le dimensionnement de ce nœud Edge. Pensez à ajuster la taille du facteur de forme du dispositif Edge ou à rééquilibrer les services vers d'autres nœuds Edge pour la charge de travail applicable.

L'utilisation du CPU du nœud Edge est élevée.

Lorsque l'événement est détecté : « L'utilisation du CPU de sur le nœud Edge {entity_id} a atteint {system_resource_usage} %, ce qui est supérieur ou égal à la valeur de seuil élevée de {system_usage_threshold} %.  »

Lorsque l'événement est résolu : « L'utilisation du CPU sur le nœud Edge {entity_id} a atteint {system_resource_usage} %, ce qui est inférieur à la valeur de seuil élevée de {system_usage_threshold} %.  »

Vérifiez la configuration, les services en cours d'exécution et le dimensionnement de ce nœud Edge. Pensez à ajuster la taille du facteur de forme du dispositif Edge ou à rééquilibrer les services vers d'autres nœuds Edge pour la charge de travail applicable.

L'utilisation de la mémoire du nœud Edge est très élevée.

Lorsque l'événement est détecté : « L'utilisation de la mémoire sur le nœud Edge {entity_id} a atteint {system_resource_usage} %, ce qui est supérieur ou égal à la valeur de seuil très élevée de {system_usage_threshold} %.  »

Lorsque l'événement est résolu : « L'utilisation de la mémoire sur le nœud Edge {entity_id} a atteint {system_resource_usage} %, ce qui est inférieur à la valeur de seuil très élevée de {system_usage_threshold} %.  »

Vérifiez la configuration, les services en cours d'exécution et le dimensionnement de ce nœud Edge. Pensez à ajuster la taille du facteur de forme du dispositif Edge ou à rééquilibrer les services vers d'autres nœuds Edge pour la charge de travail applicable.

L'utilisation de la mémoire du nœud Edge est élevée.

Lorsque l'événement est détecté : « L'utilisation de la mémoire sur le nœud Edge {entity_id} a atteint {system_resource_usage} %, ce qui est supérieur ou égal à la valeur de seuil élevée de {system_usage_threshold} %.  »

Lorsque l'événement est résolu : « L'utilisation de la mémoire sur le nœud Edge {entity_id} a atteint {system_resource_usage} %, ce qui est inférieur à la valeur de seuil élevée de {system_usage_threshold} %.  »

Vérifiez la configuration, les services en cours d'exécution et le dimensionnement de ce nœud Edge. Pensez à ajuster la taille du facteur de forme du dispositif Edge ou à rééquilibrer les services vers d'autres nœuds Edge pour la charge de travail applicable.

L'utilisation du disque du nœud Edge est très élevée.

Lorsque l'événement est détecté : « L'utilisation du disque pour la partition de disque du nœud Edge {disk_partition_name} a atteint {system_resource_usage} %, ce qui est supérieur ou égal à la valeur de seuil très élevée de {system_usage_threshold} %.  »

Lorsque l'événement est résolu : « L'utilisation du disque pour la partition de disque du nœud Edge {disk_partition_name} a atteint {system_resource_usage} %, ce qui est inférieur à la valeur de seuil très élevée de {system_usage_threshold} %.  »

Examinez la partition ayant une utilisation élevée et vérifiez si des fichiers volumineux inattendus peuvent être supprimés.

L'utilisation du disque du nœud Edge est élevée.

Lorsque l'événement est détecté : « L'utilisation du disque pour la partition de disque du nœud Edge {disk_partition_name} a atteint {system_resource_usage} %, ce qui est supérieur ou égal à la valeur de seuil élevée de {system_usage_threshold} %.  »

Lorsque l'événement est résolu : « L'utilisation du disque pour la partition de disque du nœud Edge {disk_partition_name} a atteint {system_resource_usage} %, ce qui est inférieur à la valeur de seuil élevée de {system_usage_threshold} %.  »

Examinez la partition ayant une utilisation élevée et vérifiez si des fichiers volumineux inattendus peuvent être supprimés.

L'utilisation du CPU du chemin de données du nœud Edge est très élevée.

Lorsque l'événement est détecté : « L'utilisation du CPU du chemin de données sur le nœud Edge {entity_id} a atteint {datapath_resource_usage} %, ce qui est supérieur ou égal au seuil très élevé pendant au moins deux minutes.  »

Lorsque l'événement est résolu : « L'utilisation du CPU sur le nœud Edge {entity_id} est passée au-dessous du seuil très élevé.  »

Vérifiez les statistiques du CPU sur le nœud Edge en appelant la commande get dataplane cpu stats de l'interface de ligne de commande NSX pour afficher les taux de paquets par cœur de CPU. Une utilisation plus élevée du CPU est attendue avec des taux de paquets supérieurs. Pensez à augmenter la taille du facteur de forme du dispositif Edge et à rééquilibrer les services sur ce nœud Edge vers d'autres nœuds Edge dans le même cluster ou dans d'autres clusters Edge.

L'utilisation du CPU du chemin de données du nœud Edge est élevée.

Lorsque l'événement est détecté : « L'utilisation du CPU du chemin de données sur le nœud Edge {entity_id} a atteint {datapath_resource_usage} %, ce qui est supérieur ou égal au seuil élevé pendant au moins deux minutes.  »

Lorsque l'événement est résolu : « L'utilisation du CPU sur le nœud Edge {entity_id} est passée au-dessous du seuil élevé.  »

Vérifiez les statistiques du CPU sur le nœud Edge en appelant la commande get dataplane cpu stats de l'interface de ligne de commande NSX pour afficher les taux de paquets par cœur de CPU. Une utilisation plus élevée du CPU est attendue avec des taux de paquets supérieurs. Pensez à augmenter la taille du facteur de forme du dispositif Edge et à rééquilibrer les services sur ce nœud Edge vers d'autres nœuds Edge dans le même cluster ou dans d'autres clusters Edge.

Échec de la configuration du chemin de données du nœud Edge.

Lorsque l'événement est détecté : « Échec de l'activation du chemin de données sur le nœud Edge après trois tentatives.  »

Lorsque l'événement est résolu : « Le chemin de données sur le nœud Edge a été activé.  »

Vérifiez que la connectivité du nœud Edge au nœud de gestionnaire est saine. Dans l'interface de ligne de commande NSX du nœud Edge, appelez la commande get services pour vérifier la santé des services. Si le service du plan de données est arrêté, appelez la commande start service dataplane pour le redémarrer.

Le pilote de cryptographie du nœud Edge est inactif.

Lorsque l'événement est détecté : « Le pilote de cryptographie du nœud Edge {edge_crypto_drv_name} est inactif.  »

Lorsque l'événement est résolu : « Le pilote de cryptographie du nœud Edge {edge_crypto_drv_name} est actif.  »

Mettez à niveau le nœud Edge si nécessaire.

Le pool de mémoire du chemin de données du nœud Edge est élevé.

Lorsque l'événement est détecté : « L'utilisation du pool de mémoire du chemin de données pour {mempool_name} sur le nœud Edge {entity_id} a atteint {system_resource_usage} %, ce qui est supérieur ou égal à la valeur de seuil élevée de {system_usage_threshold} %.  »

Lorsque l'événement est résolu : « L'utilisation du pool de mémoire du chemin de données pour {mempool_name} sur le nœud Edge {entity_id} a atteint {system_resource_usage} %, ce qui est inférieur à la valeur de seuil élevée de {system_usage_threshold} %.  »

Connectez-vous en tant qu'utilisateur racine et appelez les commandes edge-appctl -t /var/run/vmware/edge/dpd.ctl mempool/show et edge-appctl -t /var/run/vmware/edge/dpd.ctl memory/show malloc_heap malloc_heap » pour vérifier l'utilisation de la mémoire DPDK.

L'utilisation de la table ARP globale du nœud est élevée.

Lorsque l'événement est détecté : « L'utilisation de la table ARP globale sur le nœud Edge {entity_id} a atteint {datapath_resource_usage}%, ce qui est supérieur au seuil maximal pendant plus de deux minutes.  »

Lorsque l'événement est résolu : « L'utilisation de la table ARP globale sur le nœud Edge {entity_id} est passée au-dessous du seuil élevé.  »

Connectez-vous en tant qu'utilisateur racine et appelez la commande edge-appctl -t /var/run/vmware/edge/dpd.ctl neigh/show puis vérifiez si l'utilisation du cache neigh est normale. Si elle est normale, appelez la commande edge-appctl -t /var/run/vmware/edge/dpd.ctl neigh/set_param max_entries pour augmenter la taille de la table ARP.

La carte réseau du nœud Edge n'a temporairement plus de tampons d'anneau de réception.

Lorsque l'événement est détecté : « La mémoire tampon d'anneau de réception de la carte réseau Edge {edge_nic_name} a été dépassée de {rx_ring_buffer_overflow_percentage} % sur le nœud Edge {entity_id}. Le nombre de paquets manqués est {rx_misses} et le nombre de paquets traités est {rx_processed}.  »

Lorsque l'événement est résolu : « L'utilisation de la mémoire tampon de l'anneau de réception de la carte réseau Edge {edge_nic_name} sur le nœud Edge {entity_id} ne dépasse plus.  »

Exécutez la commande get dataplane cpu stats de l'interface de ligne de commande NSX sur le nœud Edge et vérifiez :
1. Si l'utilisation du CPU est élevée, c'est-à-dire > 90 %, prenez une capture de paquets sur l'interface à l'aide de la commande « start capture interface &ltinterface-name&gt direction input ou start capture interface &ltinterface-name&gt direction input core &ltcore-id&gt » (pour capturer les paquets entrants sur un cœur spécifique dont l'utilisation est élevée). Analysez ensuite la capture pour voir si une majorité de paquets fragmentés ou de paquets ipsec est présente. Si c'est le cas, il s'agit du comportement attendu. Autrement, le chemin de données est probablement occupé avec d'autres opérations. Si cette alarme dure plus de 2 à 3 minutes, contactez le support VMware.
2. Si l'utilisation du CPU n'est pas élevée, c'est-à-dire < 90 %, vérifiez si le pps de réception est élevé à l'aide de la commande get dataplane cpu stats (pour vous assurer que le débit du trafic augmente). Augmentez ensuite la taille de l'anneau de 1 024 à l'aide de la commande set dataplane ring-size rx . REMARQUE : l'augmentation continue de la taille de l'anneau selon un facteur de 1 024 peut entraîner des problèmes de performances. Si, même après l'augmentation de la taille de l'anneau, le problème persiste, cela indique que le dispositif Edge a besoin d'un déploiement de facteur de forme plus important pour prendre en charge le trafic.
3. Si l'alarme continue de se bloquer, c'est-à-dire qu'elle se déclenche et se résout très vite, cela est dû à un trafic en rafale. Dans ce cas, vérifiez le pps de réception comme décrit ci-dessus, s'il n'est pas élevé pendant la période d'activité de l'alarme, contactez le support VMware. Si pps est élevé, cela confirme le trafic en rafale. Envisagez de supprimer l'alarme. REMARQUE : il n'existe pas de référence permettant de définir une valeur de réception élevée. Cela dépend de l'infrastructure et du type de trafic. La comparaison peut être effectuée en notant les moments où l'alarme est inactive et active.

La carte réseau du nœud Edge ne dispose temporairement plus de tampons d'anneau de transmission.

Lorsque l'événement est détecté : « La mémoire tampon d'anneau de transmission de la carte réseau Edge {edge_nic_name} a été dépassée de {tx_ring_buffer_overflow_percentage} % sur le nœud Edge {entity_id}. Le nombre de paquets manqués est {tx_misses} et le nombre de paquets traités est {tx_processed}.  »

Lorsque l'événement est résolu : « L'utilisation de la mémoire tampon de l'anneau de transmission de la carte réseau Edge {edge_nic_name} sur le nœud Edge {entity_id} ne dépasse plus.  »

1. Si un grand nombre de machines virtuelles sont prises en charge avec Edge par l'hyperviseur, il se peut que la VM Edge n'ait pas le temps de s'exécuter, les paquets ne pourront donc peut-être pas être récupérés par l'hyperviseur. Envisagez ensuite de migrer la machine virtuelle Edge vers un hôte avec moins de machines virtuelles.
2. Augmentez la taille de l'anneau de 1 024 à l'aide de la commande « set dataplane ring-size tx  ». Si, même après l'augmentation de la taille de l'anneau, le problème persiste, contactez le support VMware, car la mémoire tampon d'anneau de transmission côté ESX peut avoir une valeur inférieure. S'il n'y a aucun problème du côté ESX, cela indique que le dispositif Edge doit être mis à l'échelle pour un déploiement de facteur de forme plus important afin d'intégrer le trafic.
3. Si l'alarme continue de se bloquer, c'est-à-dire qu'elle se déclenche et se résout très vite, cela est dû à un trafic en rafale. Dans ce cas, vérifiez le pps de transmission à l'aide de la commande get dataplane cpu stats. S'il n'est pas élevé pendant la période d'activité de l'alarme, contactez le support VMware. Si pps est élevé, cela confirme le trafic en rafale. Envisagez de supprimer l'alarme. REMARQUE : il n'existe pas de référence permettant de définir une valeur de réception élevée. Cela dépend de l'infrastructure et du type de trafic. La comparaison peut être effectuée en notant les moments où l'alarme est inactive et active.

La liaison de la carte réseau du nœud Edge est inactive.

Lorsque l'événement est détecté : « La liaison de la carte réseau du nœud Edge {edge_nic_name} est inactive.  »

Lorsque l'événement est résolu : « La liaison de la carte réseau du nœud Edge {edge_nic_name} est active.  »

Sur le nœud Edge, confirmez que la liaison de la carte réseau est physiquement inactive en appelant la commande get interfaces de l'interface de ligne de commande NSX. Si elle est inactive, vérifiez la connexion du câble.

Le disque du nœud Edge est en lecture seule.

Lorsque l'événement est détecté : « Les partitions de disque suivantes sur le nœud Edge sont en lecture seule : {Disk_partition_name} »

Lorsque l'événement est résolu : « Les partitions de disque suivantes sur le nœud Edge ont été récupérées en lecture seule : {disk_partition_name} »

Examinez la partition en lecture seule pour savoir si le redémarrage résout le problème ou si vous devez remplacer le disque. Contactez GSS pour obtenir plus d'informations.

Le thread de chemin de données du nœud Edge est dans une condition de blocage.

Lorsque l'événement est détecté : « Le thread de chemin de données du nœud Edge {edge_thread_name} est dans une condition de blocage.  »

Lorsque l'événement est résolu : « Le thread {edge_thread_name} du chemin de données du nœud Edge n'est pas en condition de blocage.  »

Redémarrez le service de plan de données en appelant la commande CLI NSX restart service dataplane.

Le débit de la carte réseau du chemin de données du nœud Edge est très élevé.

Lorsque l'événement est détecté : « L'utilisation de la carte réseau du chemin de données pour {edge_nic_name} sur le nœud Edge {entity_id} a atteint {nic_throughput} %, ce qui est supérieur ou égal à la valeur de seuil très élevée de {nic_throughput_threshold} %.  »

Lorsque l'événement est résolu : « L'utilisation de la carte réseau du chemin de données pour {edge_nic_name} sur le nœud Edge {entity_id} a atteint {nic_throughput} %, ce qui est inférieur à la valeur de seuil très élevée de {nic_throughput_threshold} %.  »

Examinez les niveaux de débit du trafic sur la carte réseau et déterminez si des modifications de configuration sont nécessaires. La commande « get dataplane thoughput &ltseconds&gt » peut être utilisée pour surveiller le débit.

Le débit de la carte réseau du chemin de données du nœud Edge est élevé.

Lorsque l'événement est détecté : « L'utilisation de la carte réseau du chemin de données pour {edge_nic_name} sur le nœud Edge {entity_id} a atteint {nic_throughput} %, ce qui est supérieur ou égal à la valeur de seuil élevée de {nic_throughput_threshold} %.  »

Lorsque l'événement est résolu : « L'utilisation de la carte réseau du chemin de données pour {edge_nic_name} sur le nœud Edge {entity_id} a atteint {nic_throughput} %, ce qui est inférieur à la valeur de seuil élevée de {nic_throughput_threshold} %.  »

Examinez les niveaux de débit du trafic sur la carte réseau et déterminez si des modifications de configuration sont nécessaires. La commande « get dataplane thoughput &ltseconds&gt » peut être utilisée pour surveiller le débit.

Tous les membres du domaine de pannes sont inactifs.

Lorsque l'événement est détecté : « Tous les membres du domaine de pannes {transport_node_id} sont inactifs.  »

Lorsque l'événement est résolu : « Tous les membres du domaine de pannes {transport_node_id} sont accessibles.  »

1. Sur le nœud Edge identifié par {transport_node_id}, vérifiez la connectivité aux plans de gestion et de contrôle en appelant la commande CLI NSX get manager et les contrôleurs get.
2. Appelez la commande CLI NSX get interface eth0 pour vérifier l'état de l'interface de gestion.
3. Appelez l'interface de ligne de commande get services pour vérifier l'état des services de base, tels que dataplane/local-controller/nestdb/routeur, etc.
4. Inspectez le fichier /var/log/syslog pour localiser l'erreur suspecte.
5. Redémarrez le nœud Edge.

Le taux de réussite du cache de micro-flux diminue et le CPU du chemin de données est élevé.

Lorsque l'événement est détecté : « Le taux de réussite du cache de micro-flux sur le nœud Edge {entity_id} est passé sous le seuil spécifié de {flow_cache_threshold} % pour le cœur {core_id} et l'utilisation du CPU du chemin de données a augmenté durant les 30 dernières minutes.  »

Lorsque l'événement est résolu : « Le taux de réussite du cache de flux se trouve dans la plage normale.  »

Le taux de réussite du flux de cache a diminué au cours des 30 dernières minutes, ce qui indique qu'il peut y avoir une dégradation des performances du dispositif Edge. Le trafic continuera d'être transféré et vous ne rencontrerez peut-être aucun problème. Vérifiez l'utilisation du CPU du chemin de données du dispositif Edge {entity_id} principal {core_id} si elle est élevée au cours des 30 dernières minutes. Le dispositif Edge a un faible taux de réussite du cache de flux lorsque de nouveaux flux sont continuellement créés, car le premier paquet d'un nouveau flux sera utilisé pour configurer dans le cache de flux pour le traitement des chemins d'accès rapide. Vous pouvez augmenter la taille de votre dispositif Edge ou augmenter le nombre de nœuds Edge utilisés pour les passerelles actives/actives.

Le taux de réussite du cache de méga-flux diminue et le CPU du chemin de données est élevé.

Lorsque l'événement est détecté : « Le taux de réussite du cache de méga-flux sur le nœud Edge {entity_id} est passé sous le seuil spécifié de {flow_cache_threshold}% pour le cœur {core_id} et l'utilisation du CPU du chemin de données a augmenté durant les 30 dernières minutes.  »

Lorsque l'événement est résolu : « Le taux de réussite du cache de flux se trouve dans la plage normale.  »

Le taux de réussite du flux de cache a diminué au cours des 30 dernières minutes, ce qui indique qu'il peut y avoir une dégradation des performances du dispositif Edge. Le trafic continuera d'être transféré et vous ne rencontrerez peut-être aucun problème. Vérifiez l'utilisation du CPU du chemin de données du dispositif Edge {entity_id} principal {core_id} si elle est élevée au cours des 30 dernières minutes. Le dispositif Edge a un faible taux de réussite du cache de flux lorsque de nouveaux flux sont continuellement créés, car le premier paquet d'un nouveau flux sera utilisé pour configurer dans le cache de flux pour le traitement des chemins d'accès rapide. Vous pouvez augmenter la taille de votre dispositif Edge ou augmenter le nombre de nœuds Edge utilisés pour les passerelles actives/actives.

Le service ESX Agent Manager (EAM) sur un gestionnaire de calcul est inactif.

Lorsque l'événement est détecté : « Le service EAM (ESX Agent Manager) sur le gestionnaire de calcul {entity_id} est inactif.  »

Lorsque l'événement est résolu : « Le service ESX Agent Manager (EAM) dans le gestionnaire de calcul {entity_id} est actif ou le gestionnaire de calcul {entity_id} a été supprimé.  »

Démarrez le service ESX Agent Manager (EAM). Connectez-vous via SSH à vCenter et appelez la commande service vmware-eam start.

La connexion du module hôte et de la SVM du partenaire est inactive.

Lorsque l'événement est détecté : « La connexion entre le module hôte et la SVM partenaire {entity_id} est inactive.  »

Lorsque l'événement est résolu : « La connexion entre le module hôte et la SVM partenaire {entity_id} est active.  »

Reportez-vous à https://kb.vmware.com/s/article/85844 et vérifiez que la SVM partenaire {entity_id} est reconnectée au module hôte.

Le voisin RTEP BGP est inactif.

Lorsque l'événement est détecté : « La session BGP RTEP (point de terminaison du tunnel distant) de l'adresse IP source {bgp_source_ip} vers l'adresse IP du voisin {bgp_neighbor_ip} de l'emplacement distant {remote_site_name} est inactive. Motif : {failure_reason}.  »

Lorsque l'événement est résolu : « La session BGP RTEP (point de terminaison du tunnel distant) de l'adresse IP source {bgp_source_ip} vers l'adresse IP du voisin {bgp_neighbor_ip} de l'emplacement distant {remote_site_name} est établie.  »

1. Appelez la commande CLI NSX get logical-routers sur le nœud Edge concerné.
2. Basculez vers le contexte REMOTE_TUNNEL_VRF.
3. Appelez la commande d'interface de ligne de commande NSX get bgp neighbor summary pour vérifier l'état du voisin BGP.
4. Vous pouvez également appeler la NSX API GET /api/v1/transport-nodes/&lttransport-node-id&gt/inter-site/bgp/summary pour obtenir l'état du voisin BGP.
5. Appelez la commande de l'interface de ligne de commande NSX get interfaces et vérifiez si l'adresse IP de RTEP adéquate est attribuée à l'interface avec le nom remote-tunnel-endpoint.
6. Vérifiez si le test ping fonctionne correctement entre l'adresse IP RTEP attribuée ({bgp_source_ip}) et l'adresse IP du voisin {bgp_neighbor_ip} de l'emplacement distant {remote_site_name}.
7. Recherchez les erreurs liées à BGP dans /var/log/syslog.
8. Appelez la NSX API GET ou PUT /api/v1/transport-nodes/&lttransport-node-id&gt pour obtenir/mettre à jour la configuration remote_tunnel_endpoint sur le nœud Edge. Cette action mettra à jour l'adresse IP RTEP attribuée au nœud Edge concerné. Si la raison indique Edge n'est pas prêt, vérifiez pourquoi le nœud Edge n'est pas dans un état correct.
1. Appelez la commande de l'interface de ligne de commande NSX get edge-cluster status pour vérifier la raison pour laquelle le nœud Edge est inactif.
2. Appelez les commandes CLI NSX get bfd-config et get bfd-sessions pour vérifier si BFD fonctionne correctement.
3. Vérifiez les alarmes liées à la santé du dispositif Edge pour obtenir plus d'informations.

La synchronisation entre les emplacements distants a échoué pendant plus de 3 minutes.

Lorsque l'événement est détecté : La synchronisation entre {site_name}({site_id}) et {remote_site_name}({remote_site_id}) a échoué pendant plus de 3 minutes.  »

Lorsque l'événement est résolu : « Les emplacements distants {site_name}({site_id}) et {remote_site_name}({remote_site_id}) sont maintenant synchronisés.  »

1. Appelez la commande CLI NSX get site-replicator remote-sites pour obtenir l'état de connexion entre les emplacements distants. Si un emplacement distant est connecté mais pas synchronisé, il est possible qu'il soit toujours en cours de résolution principale. Dans ce cas, attendez environ 10 secondes et essayez à nouveau d'appeler l'interface de ligne de commande pour vérifier l'état de l'emplacement distant. Si un emplacement est déconnecté, essayez l'étape suivante.
2. À l'aide d'une commande ping, vérifiez la connectivité du gestionnaire local (LM) dans l'emplacement {site_name}({site_id}) aux LM dans l'emplacement {remote_site_name}({remote_site_id}). Si la commande ping n'est pas possible, vérifiez la fragilité de la connectivité WAN. S'il n'y a aucun problème de connectivité réseau physique, essayez l'étape suivante.
3. Consultez le fichier /var/log/cloudnet/nsx-ccp.log sur les nœuds de gestionnaire dans le cluster local à l'emplacement {site_name}({site_id}) qui a déclenché l'alarme, pour déterminer s'il existe des erreurs de communication entre sites. De plus, recherchez également les erreurs journalisées par le sous-composant nsx-appl-proxy dans /var/log/syslog.

La synchronisation entre les emplacements distants a échoué pendant plus de 15 minutes.

Lorsque l'événement est détecté : La synchronisation entre {site_name}({site_id}) et {remote_site_name}({remote_site_id}) a échoué pendant plus de 15 minutes.  »

Lorsque l'événement est résolu : « Les sites distants {site_name}({site_id}) et {remote_site_name}({remote_site_id}) sont maintenant synchronisés.  »

1. Appelez la commande CLI NSX get site-replicator remote-sites pour obtenir l'état de connexion entre les emplacements distants. Si un emplacement distant est connecté mais pas synchronisé, il est possible qu'il soit toujours en cours de résolution principale. Dans ce cas, attendez environ 10 secondes et essayez à nouveau d'appeler l'interface de ligne de commande pour vérifier l'état de l'emplacement distant. Si un emplacement est déconnecté, essayez l'étape suivante.
2. À l'aide d'une commande ping, vérifiez la connectivité du gestionnaire local (LM) dans l'emplacement {site_name}({site_id}) aux LM dans l'emplacement {remote_site_name}({remote_site_id}). Si la commande ping n'est pas possible, vérifiez la fragilité de la connectivité WAN. S'il n'y a aucun problème de connectivité réseau physique, essayez l'étape suivante.
3. Consultez le fichier /var/log/cloudnet/nsx-ccp.log sur les nœuds de gestionnaire dans le cluster local à l'emplacement {site_name}({site_id}) qui a déclenché l'alarme, pour déterminer s'il existe des erreurs de communication entre sites. De plus, recherchez également les erreurs journalisées par le sous-composant nsx-appl-proxy dans /var/log/syslog.

Connectivité d'emplacement RTEP perdue.

Lorsque l'événement est détecté : « Le nœud du dispositif Edge {transport_node_name} a perdu la connectivité RTEP (Remote Tunnel Endpoint) avec l'emplacement distant {remote_site_name}.  »

Lorsque l'événement est résolu : « Le nœud du dispositif Edge {transport_node_name} a récupéré la connectivité RTEP (Remote Tunnel Endpoint) avec l'emplacement distant {remote_site_name}.  »

1. Appelez la commande CLI NSX get logical-routers sur le nœud Edge {transport_node_name} concerné.
2. Basculez vers le contexte REMOTE_TUNNEL_VRF.
3. Appelez la commande d'interface de ligne de commande NSX get bgp neighbor summary pour vérifier l'état du voisin BGP.
4. Vous pouvez également appeler la NSX API GET /api/v1/transport-nodes/&lttransport-node-id&gt/inter-site/bgp/summary pour obtenir l'état du voisin BGP.
5. Appelez la commande de l'interface de ligne de commande NSX get interfaces et vérifiez si l'adresse IP de RTEP adéquate est attribuée à l'interface avec le nom remote-tunnel-endpoint.
6. Vérifiez si le ping fonctionne correctement entre l'adresse IP RTEP attribuée et les adresses IP RTEP sur l'emplacement distant {remote_site_name}.
7. Recherchez les erreurs liées à BGP dans /var/log/syslog.
8. Appelez la NSX API GET ou PUT /api/v1/transport-nodes/&lttransport-node-id&gt pour obtenir/mettre à jour la configuration remote_tunnel_endpoint sur le nœud Edge. Cette action mettra à jour l'adresse IP RTEP attribuée au nœud Edge concerné {transport_node_name}.

Plusieurs nœuds de gestionnaire global sont actifs en même temps.

Lorsque l'événement est détecté : « Plusieurs nœuds de gestionnaire global sont actifs : {active_global_managers}. Un seul nœud de gestionnaire global doit être actif à la fois.  »

Lorsque l'événement est résolu : « Le nœud de gestionnaire global {active_global_manager} est désormais le seul nœud de gestionnaire global actif.  »

Configurez un seul nœud de gestionnaire global comme actif et tous les autres nœuds de gestionnaire global en veille.

La latence entre les gestionnaires globaux est supérieure à celle attendue pendant plus de 2 minutes

Lorsque l'événement est détecté : « La latence est supérieure à celle attendue entre les gestionnaires globaux {from_gm_path} et {to_gm_path}.  »

Lorsque l'événement est résolu : « La latence est inférieure à celle attendue entre les gestionnaires globaux {from_gm_path} et {to_gm_path}.  »

Vérifiez la connectivité du gestionnaire global {from_gm_path}({site_id}) au gestionnaire global {to_gm_path}({remote_site_id}) via un test ping. Si la commande ping n'est pas possible, vérifiez la fragilité de la connectivité WAN.

Le gestionnaire global actif vers le gestionnaire global en veille ne peut pas se synchroniser

Lorsque l'événement est détecté : « Le gestionnaire global actif {from_gm_path} vers le gestionnaire global en veille {to_gm_path} ne peut pas se synchroniser.  »

Lorsque l'événement est résolu : « La synchronisation entre le gestionnaire global actif {from_gm_path} et le gestionnaire global en veille {to_gm_path} est saine.  »

Vérifiez la connectivité du gestionnaire global {from_gm_path}({site_id}) au gestionnaire global {to_gm_path}({remote_site_id}) via un test ping.

Le gestionnaire global actif vers le gestionnaire global en veille ne peut pas se synchroniser pendant plus de 5 minutes

Lorsque l'événement est détecté : « Le gestionnaire global actif {from_gm_path} vers le gestionnaire global en veille {to_gm_path} ne peut pas se synchroniser pendant plus de 5 minutes.  »

Lorsque l'événement est résolu : « La synchronisation entre le gestionnaire global actif {from_gm_path} et le gestionnaire global en veille {to_gm_path} est saine.  »

Vérifiez la connectivité du gestionnaire global {from_gm_path}({site_id}) au gestionnaire global {to_gm_path}({remote_site_id}) via un test ping.

La synchronisation des données entre le gestionnaire global (GM) et le gestionnaire local (LM) a échoué.

Lorsque l'événement est détecté : « La synchronisation entre les sites {site_name}({site_id}) et {remote_site_name}({remote_site_id}) a échoué pour {flow_identifier}. Motif : {Sync_issue_reason} »

Lorsque l'événement est résolu : « Les sites distants {site_name}({site_id}) et {remote_site_name}({remote_site_id}) sont maintenant synchronisés pour {flow_identifier}.  »

1. Vérifiez la connectivité réseau entre le site distant et le site local via un test ping.
2. Assurez-vous que le trafic TCP/1236 du port est autorisé entre les sites locaux et distants.
3. Assurez-vous que le service async-replicator est en cours d'exécution sur les sites locaux et distants. Appelez la NSX API GET /api/v1/node/services/async_replicator/status ou la commande CLI NSX get service async_replicator pour déterminer si le service est en cours d'exécution. S'il n'est pas en cours d'exécution, appelez la NSX API POST /api/v1/node/services/async_replicator?action=restart ou l'interface de ligne de commande NSX restart service async_replicator pour redémarrer le service.
4. Vérifiez si des erreurs sont signalées dans le fichier /var/log/async-replicator/ar.log.

La synchronisation des données entre le gestionnaire global (GM) et le gestionnaire local (LM) a échoué pendant une période prolongée.

Lorsque l'événement est détecté : « La synchronisation entre les sites {site_name}({site_id}) et {remote_site_name}({remote_site_id}) a échoué pour {flow_identifier} pendant une période prolongée. Motif : {sync_issue_reason}.  »

Lorsque l'événement est résolu : « Les sites distants {site_name}({site_id}) et {remote_site_name}({remote_site_id}) sont maintenant synchronisés pour {flow_identifier}.  »

1. Vérifiez la connectivité réseau entre le site distant et le site local via un test ping.
2. Assurez-vous que le trafic TCP/1236 du port est autorisé entre les sites locaux et distants.
3. Assurez-vous que le service async-replicator est en cours d'exécution sur les sites locaux et distants. Appelez la NSX API GET /api/v1/node/services/async_replicator/status ou la commande CLI NSX get service async_replicator pour déterminer si le service est en cours d'exécution. S'il n'est pas en cours d'exécution, appelez la NSX API POST /api/v1/node/services/async_replicator?action=restart ou l'interface de ligne de commande NSX restart service async_replicator pour redémarrer le service.
4. Vérifiez si des erreurs sont signalées dans le fichier /var/log/async-replicator/ar.log.
5. Collectez un bundle de support et contactez l'équipe du support NSX.

Le seuil de taille de l'occupation de la file d'attente a dépassé l'avertissement.

Lorsque l'événement est détecté : « La file d'attente ({queue_name}) utilisée pour la synchronisation entre les sites {site_name}({site_id}) et {remote_site_name}({remote_site_id}) a atteint la taille de {queue_size}, ce qui est supérieur ou égal au seuil maximal de {queue_size_threshold} %.  »

Lorsque l'événement est résolu : « La file d'attente ({queue_name}) utilisée pour la synchronisation entre les sites {site_name}({site_id}) et {remote_site_name}({remote_site_id}) a atteint la taille de {queue_size}, ce qui est inférieur au seuil maximal de {queue_size_threshold} %.  »

La taille de la file d'attente peut dépasser le seuil en raison d'un problème de communication avec le site distant ou un système surchargé. Vérifiez les performances du système et le fichier /var/log/async-replicator/ar.log pour voir si des erreurs sont signalées.

La latence entre le gestionnaire global et le gestionnaire local est supérieure à celle attendue pendant plus de 2 minutes.

Lorsque l'événement est détecté : « La latence entre les sites {site_name}({site_id}) et {remote_site_name}({remote_site_id}) a atteint {latency_value}, ce qui est supérieur à la valeur de seuil de {latency_threshold}.  »

Lorsque l'événement est résolu : « La latence entre les sites {site_name}({site_id}) et {remote_site_name}({remote_site_id}) a atteint {latency_value}, ce qui est inférieur à la valeur de seuil de {latency_threshold}.  »

1. Vérifiez la connectivité réseau entre le site distant et le site local via un test ping.
2. Assurez-vous que le trafic TCP/1236 du port est autorisé entre les sites locaux et distants.
3. Vérifiez si des erreurs sont signalées dans le fichier /var/log/async-replicator/ar.log.

Le gestionnaire local est restauré lorsque l'importation de la configuration est en cours sur le gestionnaire global.

Lorsque l'événement est détecté : « L'importation de la configuration depuis le site {site_name}({site_id}) est en cours. Toutefois, le site {site_name}({site_id}) est restauré à partir d'une sauvegarde par l'administrateur, ce qui le laisse dans un état incohérent.  »

Lorsque l'événement est résolu : « L'incohérence de configuration au site {site_name}({site_id}) est résolue.  »

1. Connectez-vous à la CLI NSX du dispositif du gestionnaire global.
2. Basculez vers la racine.
3. Appelez la NSX API DELETE http://localhost:64440 /gm/api/v1/infra/sites/&ltsite-name&gt/onboarding/status en mode local, ce qui supprimera l'état d'intégration du site pour le gestionnaire global.
4. Relancez l'intégration de la configuration.

L'utilisation de la table de flux du pare-feu de passerelle pour le trafic IP est élevée. Les nouveaux flux seront abandonnés par le pare-feu de passerelle lorsque l'utilisation atteint la limite maximale.

Lorsque l'événement est détecté : « L'utilisation de la table de flux du pare-feu de passerelle pour IP sur le routeur logique {entity_id} a atteint {firewall_ip_flow_usage} %, ce qui est supérieur ou égal à la valeur de seuil élevée de {system_usage_threshold} %. Les nouveaux flux seront abandonnés par le pare-feu de passerelle lorsque l'utilisation atteint la limite maximale.  »

Lorsque l'événement est résolu : « L'utilisation de la table de flux du pare-feu de passerelle pour les flux non IP sur le routeur logique {entity_id} est inférieure à la valeur de seuil élevée de {system_usage_threshold} %.  »

Connectez-vous en tant qu'utilisateur Admin sur le nœud Edge et appelez la commande CLI NSX get firewall &ltLR_INT_UUID&gt interface stats | json en utilisant l'UUID d'interface de droite et vérifiez l'utilisation de la table de flux pour les flux IP. Vérifiez que les flux de trafic passant par la passerelle ne sont pas une attaque DOS ou une rafale anormale. Si le trafic semble être dans la charge normale, mais que le seuil d'alarme est atteint, envisagez d'augmenter le seuil d'alarme ou d'acheminer le nouveau trafic vers un autre nœud Edge.

La table de flux du pare-feu de passerelle pour le trafic IP a dépassé le seuil défini. Les nouveaux flux seront abandonnés par le pare-feu de passerelle lorsque l'utilisation atteint la limite maximale.

Lorsque l'événement est détecté : « L'utilisation de la table de flux du pare-feu de passerelle pour le trafic IP sur le routeur logique {entity_id} a atteint {firewall_ip_flow_usage} %, ce qui est supérieur ou égal à la valeur de seuil élevée de {system_usage_threshold} %. Les nouveaux flux seront abandonnés par le pare-feu de passerelle lorsque l'utilisation atteint la limite maximale.  »

Lorsque l'événement est résolu : « L'utilisation de la table de flux du pare-feu de passerelle pour les flux sur le routeur logique {entity_id} est inférieure à la valeur de seuil élevée de {system_usage_threshold} %.  »

Connectez-vous en tant qu'utilisateur Admin sur le nœud Edge et appelez la commande CLI NSX get firewall &ltLR_INT_UUID&gt interface stats | json en utilisant l'UUID d'interface de droite et vérifiez l'utilisation de la table de flux pour les flux IP. Vérifiez que les flux de trafic passant par la passerelle ne sont pas une attaque DOS ou une rafale anormale. Si le trafic semble être dans la charge normale, mais que le seuil d'alarme est atteint, envisagez d'augmenter le seuil d'alarme ou d'acheminer le nouveau trafic vers un autre nœud Edge.

L'utilisation de la table de flux du pare-feu de passerelle pour le trafic UDP est élevée. Les nouveaux flux seront abandonnés par le pare-feu de passerelle lorsque l'utilisation atteint la limite maximale.

Lorsque l'événement est détecté : « L'utilisation de la table de flux du pare-feu de passerelle pour UDP sur le routeur logique {entity_id} a atteint {firewall_udp_flow_usage} %, ce qui est supérieur ou égal à la valeur de seuil élevée de {system_usage_threshold} %. Les nouveaux flux seront abandonnés par le pare-feu de passerelle lorsque l'utilisation atteint la limite maximale.  »

Lorsque l'événement est résolu : « L'utilisation de la table de flux du pare-feu de passerelle pour UDP sur le routeur logique {entity_id} est inférieure au seuil élevé.  »

Connectez-vous en tant qu'utilisateur Admin sur le nœud Edge et appelez la commande CLI NSX get firewall &ltLR_INT_UUID&gt interface stats | json en utilisant l'UUID d'interface de droite et vérifiez l'utilisation de la table de flux pour les flux UDP. Vérifiez que les flux de trafic passant par la passerelle ne sont pas une attaque DOS ou une rafale anormale. Si le trafic semble être dans la charge normale, mais que le seuil d'alarme est atteint, envisagez d'augmenter le seuil d'alarme ou d'acheminer le nouveau trafic vers un autre nœud Edge.

La table de flux du pare-feu de passerelle pour le trafic UDP a dépassé le seuil défini. Les nouveaux flux seront abandonnés par le pare-feu de passerelle lorsque l'utilisation atteint la limite maximale.

Lorsque l'événement est détecté : « L'utilisation de la table de flux du pare-feu de passerelle pour le trafic UDP sur le routeur logique {entity_id} a atteint {firewall_udp_flow_usage} %, ce qui est supérieur ou égal à la valeur de seuil élevée de {system_usage_threshold} %. Les nouveaux flux seront abandonnés par le pare-feu de passerelle lorsque l'utilisation atteint la limite maximale.  »

Lorsque l'événement est résolu : « L'utilisation de la table de flux du pare-feu de passerelle sur le routeur logique {entity_id} est inférieure au seuil élevé.  »

Connectez-vous en tant qu'utilisateur Admin sur le nœud Edge et appelez la commande CLI NSX get firewall &ltLR_INT_UUID&gt interface stats | json en utilisant l'UUID d'interface de droite et vérifiez l'utilisation de la table de flux pour les flux UDP. Vérifiez que les flux de trafic passant par la passerelle ne sont pas une attaque DOS ou une rafale anormale. Si le trafic semble être dans la charge normale, mais que le seuil d'alarme est atteint, envisagez d'augmenter le seuil d'alarme ou d'acheminer le nouveau trafic vers un autre nœud Edge.

L'utilisation de la table de flux du pare-feu de passerelle pour le trafic ICMP est élevée. Les nouveaux flux seront abandonnés par le pare-feu de passerelle lorsque l'utilisation atteint la limite maximale.

Lorsque l'événement est détecté : « L'utilisation de la table de flux du pare-feu de passerelle pour ICMP sur le routeur logique {entity_id} a atteint {firewall_icmp_flow_usage} %, ce qui est supérieur ou égal à la valeur de seuil élevée de {system_usage_threshold} %. Les nouveaux flux seront abandonnés par le pare-feu de passerelle lorsque l'utilisation atteint la limite maximale.  »

Lorsque l'événement est résolu : « L'utilisation de la table de flux du pare-feu de passerelle pour les flux ICMP sur le routeur logique {entity_id} est inférieure à la valeur de seuil élevée de {system_usage_threshold} %.  »

Connectez-vous en tant qu'utilisateur Admin sur le nœud Edge et appelez la commande CLI NSX get firewall &ltLR_INT_UUID&gt interface stats | json en utilisant l'UUID d'interface de droite et vérifiez l'utilisation de la table de flux pour les flux ICMP. Vérifiez que les flux de trafic passant par la passerelle ne sont pas une attaque DOS ou une rafale anormale. Si le trafic semble être dans la charge normale, mais que le seuil d'alarme est atteint, envisagez d'augmenter le seuil d'alarme ou d'acheminer le nouveau trafic vers un autre nœud Edge.

La table de flux du pare-feu de passerelle pour le trafic ICMP a dépassé le seuil défini. Les nouveaux flux seront abandonnés par le pare-feu de passerelle lorsque l'utilisation atteint la limite maximale.

Lorsque l'événement est détecté : « L'utilisation de la table de flux du pare-feu de passerelle pour le trafic ICMP sur le routeur logique {entity_id} a atteint {firewall_icmp_flow_usage} %, ce qui est supérieur ou égal à la valeur de seuil élevée de {system_usage_threshold} %. Les nouveaux flux seront abandonnés par le pare-feu de passerelle lorsque l'utilisation atteint la limite maximale.  »

Lorsque l'événement est résolu : « L'utilisation de la table de flux du pare-feu de passerelle pour les flux sur le routeur logique {entity_id} est inférieure à la valeur de seuil élevée de {system_usage_threshold} %.  »

Connectez-vous en tant qu'utilisateur Admin sur le nœud Edge et appelez la commande CLI NSX get firewall &ltLR_INT_UUID&gt interface stats | json en utilisant l'UUID d'interface de droite et vérifiez l'utilisation de la table de flux pour les flux ICMP. Vérifiez que les flux de trafic passant par la passerelle ne sont pas une attaque DOS ou une rafale anormale. Si le trafic semble être dans la charge normale, mais que le seuil d'alarme est atteint, envisagez d'augmenter le seuil d'alarme ou d'acheminer le nouveau trafic vers un autre nœud Edge.

L'utilisation de la table de flux du pare-feu de passerelle pour le trafic semi-ouvert TCP est élevée. Les nouveaux flux seront abandonnés par le pare-feu de passerelle lorsque l'utilisation atteint la limite maximale.

Lorsque l'événement est détecté : « L'utilisation de la table de flux du pare-feu de passerelle pour TCP sur le routeur logique {entity_id} a atteint {firewall_halfopen_flow_usage} %, ce qui est supérieur ou égal à la valeur de seuil élevée de {system_usage_threshold} %. Les nouveaux flux seront abandonnés par le pare-feu de passerelle lorsque l'utilisation atteint la limite maximale.  »

Lorsque l'événement est résolu : « L'utilisation de la table de flux du pare-feu de passerelle pour les flux TCP semi-ouverts sur le routeur logique {entity_id} est inférieure à la valeur de seuil élevée de {system_usage_threshold} %.  »

Connectez-vous en tant qu'utilisateur Admin sur le nœud Edge et appelez la commande CLI NSX get firewall &ltLR_INT_UUID&gt interface stats | json en utilisant l'UUID d'interface de droite et vérifiez l'utilisation de la table de flux pour les flux TCP semi-ouverts. Vérifiez que les flux de trafic passant par la passerelle ne sont pas une attaque DOS ou une rafale anormale. Si le trafic semble être dans la charge normale, mais que le seuil d'alarme est atteint, envisagez d'augmenter le seuil d'alarme ou d'acheminer le nouveau trafic vers un autre nœud Edge.

La table de flux du pare-feu de passerelle pour le trafic semi-ouvert TCP a dépassé le seuil défini. Les nouveaux flux seront abandonnés par le pare-feu de passerelle lorsque l'utilisation atteint la limite maximale.

Lorsque l'événement est détecté : « L'utilisation de la table de flux du pare-feu de passerelle pour le trafic semi-ouvert TCP sur le routeur logique {entity_id} a atteint {firewall_halfopen_flow_usage} %, ce qui est supérieur ou égal à la valeur de seuil élevée de {system_usage_threshold} %. Les nouveaux flux seront abandonnés par le pare-feu de passerelle lorsque l'utilisation atteint la limite maximale.  »

Lorsque l'événement est résolu : « L'utilisation de la table de flux du pare-feu de passerelle pour les flux sur le routeur logique {entity_id} est inférieure à la valeur de seuil élevée de {system_usage_threshold} %.  »

Connectez-vous en tant qu'utilisateur Admin sur le nœud Edge et appelez la commande CLI NSX get firewall &ltLR_INT_UUID&gt interface stats | json en utilisant l'UUID d'interface de droite et vérifiez l'utilisation de la table de flux pour les flux TCP semi-ouverts. Vérifiez que les flux de trafic passant par la passerelle ne sont pas une attaque DOS ou une rafale anormale. Si le trafic semble être dans la charge normale, mais que le seuil d'alarme est atteint, envisagez d'augmenter le seuil d'alarme ou d'acheminer le nouveau trafic vers un autre nœud Edge.

Le nombre total d'éléments de groupe traduits a dépassé la limite maximale.

Lorsque l'événement est détecté : « Le groupe {group_id} a au moins {group_size} éléments traduits, ce qui est supérieur ou égal à la limite maximale de {group_max_number_limit}. Cela peut entraîner de longs temps de traitement ainsi que des délais d'expiration et des interruptions. Le nombre actuel de chaque type d'élément est le suivant. Ensembles d'adresses IP : {ip_count}, ensembles d'adresses MAC : {mac_count}, VIF : {vif_count}, ports de commutateur logique : {lsp_count}, ports de routeur logique : {lrp_count}, groupes ad : {sid_count}.  »

Lorsque l'événement est résolu : « Le nombre total d'éléments dans le groupe {group_id} doit être inférieur à la limite maximale de {group_max_number_limit}.  »

1. Pensez à ajuster les éléments du groupe dans le groupe surdimensionné {group_id}.
2. Envisagez de fractionner un groupe surdimensionné {group_id} en plusieurs groupes plus petits et de distribuer les membres du groupe surdimensionné à ces groupes.

Une passerelle de niveau 0 a basculé.

Lorsque l'événement est détecté : « Le basculement de la passerelle de niveau 0 {entity_id} de {previous_gateway_state} vers {current_gateway_state}, service-router {service_router_id} « 

Lorsque l'événement est résolu : « La passerelle de niveau 0 {entity_id} est désormais active.  »

Appelez la commande get logical-router &ltservice_router_id&gt de l'interface de ligne de commande NSX pour obtenir l'ID VRF du routeur de service de niveau 0. Passez au contexte VRF en appelant vrf &ltvrf-id&gt puis appelez get high-availability status pour déterminer quel service est inactif.

Une passerelle de niveau 1 a basculé.

Lorsque l'événement est détecté : « Basculement de la passerelle de niveau 1 {entity_id} de {previous_gateway_state} vers {current_gateway_state}, service-router {service_router_id} « 

Lorsque l'événement est résolu : « La passerelle de niveau 1 {entity_id} est désormais active.  »

Appelez la commande get logical-router &ltservice_router_id&gt de l'interface de ligne de commande NSX pour obtenir l'ID VRF du routeur de service de niveau 1. Passez au contexte VRF en appelant vrf &ltvrf-id&gt puis appelez get high-availability status pour déterminer quel service est inactif.

Le groupe de services n'a pas d'instance active.

Lorsque l'événement est détecté : « Le cluster de groupes de services {entity_id} ne dispose actuellement pas d'une instance active. Il est dans l'état {ha_state} (où 0 est inactif, 1 est en veille et 2 est actif) sur le nœud Edge {transport_node_id} et dans l'état {ha_state2} sur le nœud Edge {transport_node_id2}.  »

Lorsque l'événement est résolu : « Le cluster de groupe de services de niveau 0 {entity_id} dispose désormais d'une instance active sur le nœud Edge {transport_node_id}.  »

Appelez la commande CLI NSX get logical-router &ltservice_router_id&gt service_group pour vérifier tous les groupes de services configurés sous un routeur de service donné. Examinez la sortie pour déterminer la raison pour laquelle un groupe de services quitte l'état actif.

Le groupe de services n'a pas d'instance active.

Lorsque l'événement est détecté : « Le cluster de groupes de services {entity_id} ne dispose actuellement pas d'une instance active. Il est dans l'état {ha_state} (où 0 est inactif, 1 est en veille et 2 est actif) sur le nœud Edge {transport_node_id} et dans l'état {ha_state2} sur le nœud Edge {transport_node_id2}.  »

Lorsque l'événement est résolu : « Le cluster de groupe de services de niveau 1 {entity_id} dispose désormais d'une instance active sur le nœud Edge {transport_node_id}.  »

Appelez la commande CLI NSX get logical-router &ltservice_router_id&gt service_group pour vérifier tous les groupes de services configurés sous un routeur de service donné. Examinez la sortie pour déterminer la raison pour laquelle un groupe de services quitte l'état actif.

Une instance en veille dans un groupe de services a échoué.

Lorsque l'événement est détecté : « Le cluster de groupes de services {entity_id} attaché au routeur de service de niveau 0 {service_router_id} sur le nœud Edge {transport_node_id} a échoué. Par conséquent, le cluster du groupe de services n'a actuellement pas d'instance en veille.  »

Lorsque l'événement est résolu : « Le cluster du groupe de services {entity_id} est dans l'état {ha_state} (où 0 est inactif, 1 est en veille et 2 est actif) sur le nœud Edge {transport_node_id} et dans l'état {ha_state2} sur le nœud Edge {transport_node_id2}.  »

Appelez la commande CLI NSX get logical-router &ltservice_router_id&gt service_group pour vérifier tous les groupes de services configurés sous un routeur de service donné. Examinez la sortie pour déterminer la raison de l'échec d'un groupe de services précédemment en veille.

Une instance en veille dans un groupe de services a échoué.

Lorsque l'événement est détecté : « Le cluster de groupes de services {entity_id} attaché au routeur de service de niveau 1 {service_router_id} sur le nœud Edge {transport_node_id} a échoué. Par conséquent, le cluster du groupe de services n'a actuellement pas d'instance en veille.  »

Lorsque l'événement est résolu : « Le cluster du groupe de services {entity_id} est dans l'état {ha_state} (où 0 est inactif, 1 est en veille et 2 est actif) sur le nœud Edge {transport_node_id} et dans l'état {ha_state2} sur le nœud Edge {transport_node_id2}.  »

Appelez la commande CLI NSX get logical-router &ltservice_router_id&gt service_group pour vérifier tous les groupes de services configurés sous un routeur de service donné. Examinez la sortie pour déterminer la raison de l'échec d'un groupe de services précédemment en veille.

La connectivité au serveur LDAP est perdue.

Lorsque l'événement est détecté : « La connectivité au serveur LDAP {ldap_server} est perdue.  »

Lorsque l'événement est résolu : « La connectivité au serveur LDAP {ldap_server} est restaurée.  »

Cochez
1. Le serveur LDAP est accessible à partir des nœuds NSX.
2. Les détails du serveur LDAP sont correctement configurés dans NSX.
3. Le serveur LDAP s'exécute correctement.
4. Aucun pare-feu ne bloque l'accès entre le serveur LDAP et les nœuds NSX. Une fois le problème résolu, utilisez TEST CONNECTION dans l'interface utilisateur NSX sous Annuaire AD de pare-feu d'identité pour tester la connexion.

Des erreurs se sont produites lors de l'exécution de la synchronisation Delta.

Lorsque l'événement est détecté : « Des erreurs se sont produites lors de l'exécution de la synchronisation Delta avec {directory_domain}.  »

Lorsque l'événement est résolu : « Aucune erreur ne s'est produite lors de l'exécution de la synchronisation Delta avec {directory_domain}.  »

1. Vérifiez s'il existe des alarmes de connectivité au serveur LDAP perdu.
2. Recherchez les détails de l'erreur dans /var/log/syslog. Autour de l'heure de déclenchement de l'alarme, recherchez le texte : une erreur s'est produite lors de la synchronisation avec des objets LDAP.
3. Vérifiez auprès de l'administrateur AD si des modifications récentes apportées à AD peuvent provoquer les erreurs.
4. Si les erreurs persistent, collectez le bundle de support technique et contactez le support technique VMware.

L'état du tunnel d'un nœud Edge est inactif.

Lorsque l'événement est détecté : « L'état du tunnel global du nœud Edge {entity_id} est inactif.  »

Lorsque l'événement est résolu : « Les tunnels du nœud Edge {entity_id} ont été restaurés.  »

Appelez la commande CLI NSX get tunnel-ports pour obtenir tous les ports de tunnel, puis vérifiez les statistiques de chaque tunnel en appelant la commande CLI NSX get tunnel-port &ltUUID&gt stats pour vérifier s'il existe des abandons. Recherchez également dans /var/log/syslog s'il existe des erreurs liées au tunnel.

L'état du service sur le DPU est anormal.

Lorsque l'événement est détecté : « Le service {service_name} sur DPU {dpu_id} ne répondait pas pendant 10 secondes.  »

Lorsque l'événement est résolu : « Le service {service_name} sur DPU {dpu_id} répond de nouveau.  »

Vérifiez que le service {service_name} sur DPU {dpu_id} est toujours en cours d'exécution en appelant /etc/init.d/{service_name} status. Si le service est signalé comme étant en cours d'exécution, il peut devoir être redémarré, ce qui peut être effectué avec /etc/init.d/{service_name} restart. Exécutez à nouveau la commande status pour vérifier que le service est en cours d'exécution. Si le redémarrage du service ne résout pas le problème ou si le problème se produit après un redémarrage réussi, contactez le support VMware.

L'état du service est anormal.

Lorsque l'événement est détecté : « Le service {service_name} ne répondait pas pendant 10 secondes.  »

Lorsque l'événement est résolu : « Le service {service_name} répond de nouveau.  »

Vérifiez si le service {service_name} est toujours en cours d'exécution en appelant /etc/init.d/{service_name} status. Si le service est signalé comme étant en cours d'exécution, il peut devoir être redémarré, ce qui peut être effectué avec /etc/init.d/{service_name} restart. Exécutez à nouveau la commande status pour vérifier que le service est en cours d'exécution. Si le script /etc/init.d/{service_name} n'est pas disponible, appelez systemctl {service_name} status et redémarrez via systemctl {service_name} restart avec des privilèges racine. Si le redémarrage du service ne résout pas le problème ou si le problème se produit après un redémarrage réussi, contactez le support VMware.

Échec de la livraison des mesures à la cible spécifiée.

Lorsque l'événement est détecté : « Échec de la livraison des mesures de SHA aux {metrics_target_alias}({metrics_target_address}:{metrics_target_port}) cibles.  »

Lorsque l'événement est résolu : « Livraison de mesures aux l'{metrics_target_alias}({metrics_target_address}:{metrics_target_port}) cibles récupérée.  »

L'utilisateur doit effectuer les vérifications suivantes afin d'exclure le problème à l'origine de l'échec : 1. Vérifiez si l'adresse cible {metrics_target_address} et le port {metrics_target_port} (la valeur par défaut est 443 si le port n'est pas spécifié) transmis pour la connexion est la cible attendue, 2. Vérifiez si le certificat est correct via /opt/vmware/nsx-nestdb/bin/nestdb-cli --cmd 'put vmware.nsx.nestdb.CommonAgentHostConfigMsg', 3. Vérifiez si la cible {metrics_target_address} est accessible, 4. Vérifiez si le gestionnaire de mesures sur la cible {metrics_target_address} est en cours d'exécution avec docker ps | grep metrics_manager, 5. Vérifiez si le port {metrics_target_port} est ouvert par netstat -a | grep {metrics_target_port} on target, 6. Vérifiez si la règle de pare-feu ALLOW est installée sur le nœud par iptables -S OUTPUT | grep {metrics_target_port}(EDGE/UA) or localcli network firewall ruleset list | grep nsx-sha-tsdb(ESX), 7. Redémarrez le démon SHA pour voir s'il peut être résolu par /etc/init.d/netopa restart(ESX) ou /etc/init.d/nsx-netopa restart (EDGE) ou /etc/init.d/nsx-sha restart(UA).

Le service Edge est inactif pendant au moins une minute.

Lorsque l'événement est détecté : « Le service {edge_service_name} est inactif pendant au moins une minute. {service_down_reason} »

Lorsque l'élément est résolu : « Le service {edge_service_name} est actif.  »

Sur le nœud Edge, vérifiez que le service n'est pas fermé en raison d'une erreur en examinant les fichiers noyaux dans le répertoire /var/log/core. En outre, appelez la commande de l'interface de ligne de commande NSX get services pour confirmer si le service est arrêté. Si c'est le cas, appelez start service &ltservice-name&gt pour redémarrer le service.

État du service Edge modifié.

Lorsque l'événement est détecté : « Le service {edge_service_name} a changé de {previous_service_state} à {current_service_state}. {service_down_reason} »

Lorsque l'élément est résolu : « Le service {edge_service_name} a changé de {previous_service_state} à {current_service_state}.  »

Sur le nœud Edge, vérifiez que le service n'est pas fermé en raison d'une erreur en examinant les fichiers noyaux dans le répertoire /var/log/core. En outre, appelez la commande de l'interface de ligne de commande NSX get services pour confirmer si le service est arrêté. Si c'est le cas, appelez start service &ltservice-name&gt pour redémarrer le service.

L'application s'est bloquée et a généré un vidage de mémoire.

Lorsque l'événement est détecté : « L'application sur le nœud NSX {node_display_or_host_name} s'est bloquée. Le nombre de fichiers noyaux trouvés est {core_dump_count}. Collectez le bundle de support, y compris les fichiers de vidage de mémoire, puis contactez l'équipe de support VMware.  »

Lorsque l'événement est résolu : « Tous les fichiers de vidage de mémoire sont retirés du système.  »

Collectez le bundle de support pour le nœud NSX {node_display_or_host_name} à l'aide de l'interface utilisateur ou de l'API de NSX Manager. Remarque : les vidages de mémoire peuvent être définis pour déplacer ou copier vers le bundle de support technique NSX afin de supprimer ou de conserver la copie locale sur le nœud. La copie du bundle de support avec les fichiers de vidage de mémoire est essentielle pour l'équipe de support VMware afin de résoudre le problème. Il est recommandé d'enregistrer la copie la plus récente du bundle de support technique incluant les fichiers de vidage de mémoire avant de les supprimer du système. Pour plus d'informations, reportez-vous à l'article de la base de connaissances.

Un nœud de transport est déconnecté de son broker de messagerie de nœud Intelligence. Cela affecte la collecte de données.

Lorsque l'événement est détecté : « L'exportateur de flux sur le nœud de transport {entity_id} est déconnecté du broker de messagerie du nœud Intelligence. Cela affecte la collecte de données.  »

Lorsque l'événement est résolu : « L'exportateur de flux sur le nœud de transport {entity_id} s'est reconnecté au broker de messagerie du nœud Intelligence.  »

Redémarrez le service de messagerie s'il n'est pas en cours d'exécution dans le nœud Intelligence. Résolvez l'échec de la connexion réseau entre l'exportateur de flux de nœud de transport et le nœud Intelligence.

L'utilisation du CPU du nœud Intelligence est très élevée.

Lorsque l'événement est détecté : « L'utilisation du CPU sur le nœud Intelligence {intelligence_node_id} est supérieure à la valeur de seuil très élevée de {system_usage_threshold} %.  »

Lorsque l'événement est résolu : « L'utilisation du CPU sur le nœud Intelligence {intelligence_node_id} est inférieure à la valeur de seuil très élevée de {system_usage_threshold} %.  »

Utilisez la commande top pour vérifier quels processus présentent le plus d'utilisations du CPU, puis vérifiez /var/log/syslog et les journaux locaux de ces processus pour voir si des erreurs en attente doivent être résolues.

L'utilisation du CPU du nœud Intelligence est élevée.

Lorsque l'événement est détecté : « L'utilisation du CPU sur le nœud Intelligence {intelligence_node_id} est supérieure à la valeur de seuil élevée de {system_usage_threshold} %.  »

Lorsque l'événement est résolu : « L'utilisation du CPU sur le nœud Intelligence {intelligence_node_id} est inférieure à la valeur de seuil élevée de {system_usage_threshold} %.  »

Utilisez la commande top pour vérifier quels processus présentent le plus d'utilisations du CPU, puis vérifiez /var/log/syslog et les journaux locaux de ces processus pour voir si des erreurs en attente doivent être résolues.

L'utilisation de la mémoire du nœud Intelligence est très élevée.

Lorsque l'événement est détecté : « L'utilisation de la mémoire sur le nœud Intelligence {intelligence_node_id} est supérieure à la valeur de seuil très élevée de {system_usage_threshold} %.  »

Lorsque l'événement est résolu : « L'utilisation de la mémoire sur le nœud Intelligence {intelligence_node_id} est inférieure à la valeur de seuil très élevée de {system_usage_threshold} %.  »

Utilisez la commande top pour vérifier quels processus présentent le plus d'utilisations de la mémoire, puis vérifiez /var/log/syslog et les journaux locaux de ces processus pour voir si des erreurs en attente doivent être résolues.

L'utilisation de la mémoire du nœud Intelligence est élevée.

Lorsque l'événement est détecté : « L'utilisation de la mémoire sur le nœud Intelligence {intelligence_node_id} est supérieure à la valeur de seuil élevée de {system_usage_threshold} %.  »

Lorsque l'événement est résolu : « L'utilisation de la mémoire sur le nœud Intelligence {intelligence_node_id} est inférieure à la valeur de seuil élevée de {system_usage_threshold} %.  »

Utilisez la commande top pour vérifier quels processus présentent le plus d'utilisations de la mémoire, puis vérifiez /var/log/syslog et les journaux locaux de ces processus pour voir si des erreurs en attente doivent être résolues.

L'utilisation du disque du nœud Intelligence est très élevée.

Lorsque l'événement est détecté : « L'utilisation du disque pour la partition de disque {disk_partition_name} sur le nœud Intelligence {intelligence_node_id} est supérieure à la valeur de seuil très élevée de {system_usage_threshold} %.  »

Lorsque l'événement est résolu : « L'utilisation du disque pour la partition de disque {disk_partition_name} sur le nœud Intelligence {intelligence_node_id} est inférieure à la valeur de seuil très élevée de {system_usage_threshold} %.  »

Examinez la partition de disque {disk_partition_name} et vérifiez si vous pouvez supprimer des fichiers volumineux inattendus.

L'utilisation du disque du nœud Intelligence est élevée.

Lorsque l'événement est détecté : « L'utilisation du disque pour la partition de disque {disk_partition_name} sur le nœud Intelligence {intelligence_node_id} est supérieure à la valeur de seuil élevée de {system_usage_threshold} %.  »

Lorsque l'événement est résolu : « L'utilisation du disque pour la partition de disque {disk_partition_name} sur le nœud Intelligence {intelligence_node_id} est inférieure à la valeur de seuil élevée de {system_usage_threshold} %.  »

Examinez la partition de disque {disk_partition_name} et vérifiez si vous pouvez supprimer des fichiers volumineux inattendus.

L'utilisation de la partition de disque de données du nœud Intelligence est très élevée.

Lorsque l'événement est détecté : « L'utilisation du disque pour la partition de disque/les données sur le nœud Intelligence {intelligence_node_id} est supérieure à la valeur de seuil très élevée de {system_usage_threshold} %.  »

Lorsque l'événement est résolu : « L'utilisation du disque pour la partition de disque/les données sur le nœud Intelligence {intelligence_node_id} est inférieure à la valeur de seuil très élevée de {system_usage_threshold} %.  »

Arrêtez la collecte de données NSX Intelligence jusqu'à ce que l'utilisation du disque soit inférieure au seuil. Dans l'interface utilisateur de NSX, accédez à Système | Dispositifs | Dispositif NSX Intelligence. Cliquez ensuite sur ACTIONS, Arrêter la collecte des données.

L'utilisation de la partition de disque de données du nœud Intelligence est élevée.

Lorsque l'événement est détecté : « L'utilisation du disque pour la partition de disque/les données sur le nœud Intelligence {intelligence_node_id} est supérieure à la valeur de seuil élevée de {system_usage_threshold} %.  »

Lorsque l'événement est résolu : « L'utilisation du disque pour la partition de disque/les données sur le nœud Intelligence {intelligence_node_id} est inférieure à la valeur de seuil élevée de {system_usage_threshold} %.  »

Arrêtez la collecte de données NSX Intelligence jusqu'à ce que l'utilisation du disque soit inférieure au seuil. Examinez la partition/les données de disque et vérifiez si vous pouvez supprimer des fichiers volumineux inattendus.

La latence de stockage du nœud Intelligence est élevée.

Lorsque l'événement est détecté : « La latence de stockage de la partition de disque {disk_partition_name} sur le nœud Intelligence {intelligence_node_id} est supérieure à la valeur de seuil élevée de {system_usage_threshold} millisecondes.  »

Lorsque l'événement est résolu : « La latence de stockage de la partition de disque {disk_partition_name} sur le nœud Intelligence {intelligence_node_id} est inférieure à la valeur de seuil élevée de {system_usage_threshold} millisecondes.  »

Une latence de stockage élevée transitoire peut se produire en raison d'un pic de demandes d'E/S. Si la latence de stockage reste élevée pendant plus de 30 minutes, envisagez de déployer le dispositif NSX Intelligence sur un disque à faible latence ou de partager le même périphérique de stockage avec d'autres machines virtuelles.

L'état du nœud Intelligence est dégradé.

Lorsque l'événement est détecté : « Le nœud Intelligence {intelligence_node_id} est dégradé.  »

Lorsque l'événement est résolu : « Le nœud Intelligence {intelligence_node_id} s'exécute correctement.  »

Appelez la NSX API GET /napp/api/v1/platform/monitor/category/health pour vérifier quel espace spécifique est inactif et la raison. Appelez la commande d'interface de ligne de commande suivante pour redémarrer le service dégradé : kubectl rollout restart &ltstatefulset/deployment&gt &ltservice_name&gt -n &ltnamespace&gt

L'utilisation du bloc d'adresses IP est très élevée.

Lorsque l'événement est détecté : « L'utilisation du bloc d'adresses IP {intent_path} est très élevée. Le bloc d'adresses IP approche de sa capacité totale, la création d'un sous-réseau à l'aide d'un bloc d'adresses IP peut échouer.  »

Lorsque l'événement est résolu : « L'utilisation du bloc d'adresses IP {intent_path} est inférieure au niveau de seuil.  »

Examinez l'utilisation du bloc d'adresses IP. Utilisez un nouveau bloc d'adresses IP pour la création de ressources ou supprimez le sous-réseau IP inutilisé du bloc d'adresses IP. Pour vérifier le sous-réseau utilisé pour un bloc d'adresses IP. Dans l'interface utilisateur de NSX, accédez à l'onglet Mise en réseau | Pools d'adresses IP | Pools d'adresses IP. Sélectionnez les pools d'adresses IP dans lesquels le bloc d'adresses IP est utilisé, cochez la colonne Sous-réseaux et Adresses IP alloués sur l'interface utilisateur. Si aucune allocation n'a été utilisée pour le pool d'adresses IP et qu'elle ne sera pas utilisée à l'avenir, supprimez le sous-réseau ou le pool d'adresses IP. Utilisez l'API suivante pour vérifier si le bloc d'adresses IP est utilisé par le pool d'adresses IP et si l'allocation d'adresses IP a été effectuée : Pour obtenir les sous-réseaux configurés d'un pool d'adresses IP, appelez la NSX API GET /policy/api/v1/infra/ip-pools/&ltip-pool&gt/ip-subnets pour obtenir des allocations d'adresses IP, appelez la NSX API GET /policy/api/v1/infra/ip-pools/&ltip-pool&gt/ip-allocations Remarque : la suppression du pool/sous-réseau d'adresses IP ne doit être effectuée que s'il ne dispose pas d'adresses IP allouées et s'il ne sera pas utilisé à l'avenir.

L'utilisation du pool d'adresses IP est très élevée.

Lorsque l'événement est détecté : « L'utilisation du pool d'adresses IP {intent_path} est très élevée. Pool d'adresses IP proche de sa capacité totale. La création d'une entité/d'un service qui dépend de l'adresse IP allouée à partir du pool d'adresses IP peut échouer.  »

Lorsque l'événement est résolu : « L'utilisation du pool d'adresses IP {intent_path} est maintenant normale.  »

Examinez l'utilisation du pool d'adresses IP. Libérez les allocations IP inutilisées du pool d'adresses IP ou créez un pool d'adresses IP et utilisez-le. Dans l'interface utilisateur de NSX accédez à l'onglet Mise en réseau | Pools d'adresses IP | Pools d'adresses IP. Sélectionnez des pools IP et cochez la colonne Adresses IP allouées pour afficher les adresses IP allouées à partir du pool IP. Si l'utilisateur constate que des adresses IP ne sont pas utilisées, elles peuvent être libérées. Pour libérer les allocations IP inutilisées, appelez la NSX API DELETE /policy/api/v1/infra/ip-pools/&ltip-pool&gt/ip-allocations/&ltip-allocation&gt

Une licence a expiré.

Lorsque l'événement est détecté : « La clé de licence {license_edition_type} se terminant par {displayed_license_key} a expiré.  »

Lorsque l'événement est résolu : « La clé de licence expirée {license_edition_type} se terminant par {displayed_license_key} a été supprimée, mise à jour ou n'est plus sur le point d'expirer.  »

Ajoutez une nouvelle licence non expirée à l'aide de l'interface utilisateur NSX en accédant à Système | Licences puis cliquez sur AJOUTER et spécifiez la clé de la nouvelle licence. La licence expirée doit être supprimée en cochant la case de la licence, puis cliquez sur SUPPRIMER.

Une licence est sur le point d'expirer.

Lorsque l'événement est détecté : « La clé de licence {license_edition_type} se terminant par {displayed_license_key} est sur le point d'expirer.  »

Lorsque l'événement est résolu : « La clé de licence expirant {license_edition_type} se terminant par {displayed_license_key} a été supprimée, mise à jour ou n'est plus sur le point d'expirer.  »

La licence est sur le point d'expirer dans plusieurs jours. Prévoyez d'ajouter une nouvelle licence sans expiration à l'aide de l'interface utilisateur NSX en accédant à Système | Licences, puis cliquez sur AJOUTER et spécifiez la clé de la nouvelle licence. La licence expirée doit être supprimée en cochant la case de la licence, puis cliquez sur SUPPRIMER.

L'utilisation du CPU de l'équilibreur de charge est très élevée.

Lorsque l'événement est détecté : « L'utilisation du CPU par l'équilibreur de charge {entity_id} est très élevée. Le seuil est {system_usage_threshold} %.  »

Lorsque l'événement est résolu : « L'utilisation du CPU par l'équilibreur de charge {entity_id} est assez basse. Le seuil est {system_usage_threshold} %.  »

Si l'utilisation du CPU par l'équilibrage de charge est supérieure au seuil d'utilisation du système, la charge de travail est trop élevée pour cet équilibrage de charge. Redimensionnez le service d'équilibreur de charge en passant la taille de l'équilibreur de charge de petite à moyenne ou de moyenne à grande. Si l'utilisation du CPU de cet équilibreur de charge est toujours élevée, pensez à ajuster la taille du facteur de forme du dispositif Edge ou à déplacer les services d'équilibreur de charge vers d'autres nœuds Edge pour la charge de travail applicable.

Le service d'équilibreur de charge est dégradé.

Lorsque l'événement est détecté : « Le service d'équilibreur de charge {entity_id} est dégradé.  »

Lorsque l'événement est résolu : « Le service d'équilibreur de charge {entity_id} n'est pas dégradé.  »

Pour l'équilibreur de charge centralisé : vérifiez l'état de l'équilibreur de charge sur le nœud Edge en veille, car l'état dégradé signifie que l'état de l'équilibreur de charge sur le nœud Edge en veille n'est pas prêt. Sur le nœud Edge en veille, appelez la commande CLI NSX get load-balancer &ltlb-uuid&gt status. Si l'état de l'équilibreur de charge du service d'équilibreur de charge est « not_ready » ou s'il n'existe aucune sortie, faites entrer le nœud Edge en mode de maintenance, puis quittez le mode de maintenance. Pour l'équilibreur de charge distribué :
1. Obtenez l'état détaillé en appelant la NSX API GET /policy/api/v1/infra/lb-services/&ltLBService&gt/detailed-status?source=realtime
2. Dans la sortie de l'API, recherchez l'hôte ESXi signalant une valeur non nulle instance_number avec l'état NOT_READY ou CONFLICT.
3. Sur le nœud hôte ESXi, appelez la commande CLI NSX « get load-balancer &ltlb-uuid&gt status ». Si le message « LSP en conflit » est signalé, vérifiez si ce LSP est associé à un autre service d'équilibreur de charge. Vérifiez si ce conflit est acceptable. Si « LSP non prêt » est signalé, vérifiez l'état de ce LSP en appelant la commande CLI NSX get logical-switch-port status. REMARQUE : vous devez ignorer l'alarme si elle peut être résolue automatiquement en 5 minutes, car l'état dégradé peut être un état temporaire.

Le service d'équilibreur de charge distribué est inactif.

Lorsque l'événement est détecté : « Le service d'équilibreur de charge distribué {entity_id} est inactif.  »

Lorsque l'événement est résolu : « Le service d'équilibreur de charge distribué {entity_id} est actif.  »

Sur le nœud hôte ESXi, appelez la commande CLI NSX « get load-balancer &ltlb-uuid&gt status ». Si le message « LSP en conflit » est signalé, vérifiez si ce LSP est associé à un autre service d'équilibreur de charge. Vérifiez si ce conflit est acceptable. Si « LSP non prêt » est signalé, vérifiez l'état de ce LSP en appelant la commande CLI NSX get logical-switch-port status.

Le service d'équilibreur de charge centralisé est inactif.

Lorsque l'événement est détecté : « Le service d'équilibreur de charge centralisé {entity_id} est inactif.  »

Lorsque l'événement est résolu : « Le service d'équilibreur de charge centralisé {entity_id} est actif.  »

Sur le nœud Edge actif, vérifiez l'état de l'équilibreur de charge en appelant la commande CLI NSX get load-balancer &ltlb-uuid&gt status. Si l'état de l'équilibreur de charge du service d'équilibreur de charge est « not_ready » ou s'il n'existe aucune sortie, faites entrer le nœud Edge en mode de maintenance, puis quittez le mode de maintenance.

Le service virtuel d'équilibreur de charge est inactif.

Lorsque l'événement est détecté : « Le serveur virtuel de l'équilibreur de charge {entity_id} est inactif.  »

Lorsque l'événement est résolu : « Le serveur virtuel de l'équilibreur de charge {entity_id} est actif.  »

Consultez le pool d'équilibreurs de charge pour déterminer son état et vérifier sa configuration. S'il est configuré de manière incorrecte, reconfigurez-le et supprimez le pool d'équilibreurs de charge du serveur virtuel, puis rajoutez-le à nouveau au serveur virtuel.

Le pool d'équilibreurs de charge est inactif.

Lorsque l'événement est détecté : L'état du pool d'équilibreurs de charge {entity_id} est inactif.  »

Lorsque l'événement est résolu : « L'état du pool d'équilibreurs de charge {entity_id} est actif. »

Consultez le pool d'équilibreur de charge pour déterminer les membres inactifs en appelant la commande CLI NSX get load-balancer &ltlb-uuid&gt pool &ltpool-uuid&gt status ou la NSX API /policy/api/v1/infra/lb-services/&ltlb-service-id&gt/lb-pools/&ltlb-pool-id&gt/detailed-status Si DOWN ou UNKNOWN est signalé, vérifiez le membre du pool. Vérifiez la connectivité réseau entre l'équilibreur de charge et les membres du pool concernés. Validez la santé de l'application de chaque membre du pool. Validez également la santé de chaque membre du pool à l'aide du moniteur configuré. Lorsque la santé du membre est établie, l'état du membre du pool est mis à jour sur Sain en fonction de la configuration « Nombre de reconnexions » dans le moniteur. Corrigez le problème en redémarrant le membre du pool ou faites passer le nœud Edge en mode de maintenance, puis quittez le mode de maintenance.

L'utilisation de l'équilibreur de charge est élevée.

Lorsque l'événement est détecté : « L'utilisation du service d'équilibreur de charge dans le nœud Edge {entity_id} est élevée. Le seuil est {system_usage_threshold} %.  »

Lorsque l'événement est résolu : « L'utilisation du service d'équilibreur de charge dans le nœud Edge {entity_id} est assez faible. Le seuil est {system_usage_threshold} %.  »

Si plusieurs instances d'équilibrage de charge ont été configurées dans ce nœud Edge, déployez un nouveau nœud Edge et déplacez certaines instances d'équilibrage de charge vers ce nouveau nœud Edge. Si une seule instance d'équilibrage de charge (petite/moyenne/etc.) a été configurée dans un nœud Edge de même taille (petit/moyen/etc), déployez un nouveau dispositif Edge de plus grande taille et déplacez l'instance d'équilibrage de charge vers ce nouveau nœud Edge.

L'utilisation du membre du pool d'équilibreur de charge est très élevée.

Lorsque l'événement est détecté : L'utilisation des membres du pool dans le nœud Edge {entity_id} est très élevée. Le seuil est {system_usage_threshold} %.  »

Lorsque l'événement est résolu : « L'utilisation des membres du pool dans le nœud Edge {entity_id} est assez faible. Le seuil est {system_usage_threshold} %.  »

Déployez un nouveau nœud Edge et déplacez le service d'équilibreur de charge des nœuds Edge existants vers le nœud Edge qui vient d'être déployé.

La configuration de l'équilibreur de charge n'est pas réalisée en raison d'une utilisation élevée de la mémoire sur le nœud Edge.

Lorsque l'événement est détecté : « La configuration de l'équilibreur de charge {entity_id} n'est pas réalisée, en raison d'une utilisation élevée de la mémoire sur le nœud Edge {transport_node_id}.  »

Lorsque l'événement est résolu : « La configuration de l'équilibreur de charge {entity_id} est réalisée sur {transport_node_id}.  »

Préférez définir des équilibreurs de charge de petite et moyenne taille sur des équilibreurs de charge de grande taille. Répartissez les services d'équilibreur de charge entre les nœuds Edge disponibles. Réduisez le nombre de serveurs virtuels définis.

L'état du service est inactif.

Lorsque l'événement est détecté : « Le service {mps_service_name} n'est pas en cours d'exécution sur {transport_node_name}.  »

Lorsque l'événement est résolu : « Le service {mps_service_name} s'exécute correctement sur {transport_node_name}.  »

1. Sur le nœud Edge identifié par {nsx_edge_tn_name}, appelez l'interface de ligne de commande NSX get services pour vérifier l'état de {mps_service_name}. Inspectez le fichier /var/log/syslog pour localiser toute erreur suspecte.
2. Sur le nœud hôte identifié par {nsx_esx_tn_name}, connectez-vous à la machine virtuelle du service de protection contre les programmes malveillants associée {entity_id} et vérifiez l'état de {mps_service_name}. Inspectez /var/log/syslog sur la machine virtuelle du service de protection contre les programmes malveillants associée {entity_id} pour trouver une ou plusieurs erreurs suspectes.

L'état du service est dégradé.

Lorsque l'événement est détecté : « Le service {mps_service_name} est dégradé sur {transport_node_name}. Impossible de communiquer avec la fonctionnalité d'extraction de fichier. Toutes les capacités d'extraction de fichiers sur le {transport_node_name} sont suspendues.  »

Lorsque l'événement est résolu : « Le service {mps_service_name} s'exécute correctement sur {transport_node_name}.  »

1. Sur le nœud Edge identifié par {nsx_edge_tn_name}, appelez la CLI NSX get ids engine status pour vérifier l'état du service file_extraction (IDS). Inspectez /var/log/syslog pour trouver une ou plusieurs erreurs suspectes avec le service d'extraction de fichiers (IDS) et/ou {mps_service_name}.
2. Sur le nœud hôte identifié par {nsx_esx_tn_name}, connectez-vous à la machine virtuelle du service de protection contre les programmes malveillants associée {entity_id} et vérifiez l'état du service d'extraction de fichiers (NXGI). Inspectez /var/log/syslog sur la machine virtuelle du service de protection contre les programmes malveillants associée {entity_id} pour trouver une ou plusieurs erreurs suspectes.

L'état du service est dégradé.

Lorsque l'événement est détecté : Le service {mps_service_name} est dégradé sur NSX Application Platform. Il ne peut pas communiquer avec la base de données de protection contre les programmes malveillants.  »

Lorsque l'événement est résolu : « Le service {mps_service_name} s'exécute correctement sur NSX Application Platform.  »

Dans l'interface utilisateur NSX, accédez à Système | NSX Application Platform | Services de base pour vérifier quel service est dégradé. Appelez la NSX API GET /napp/api/v1/platform/monitor/feature/health pour vérifier quel service spécifique est inactif et la raison. Appelez la commande d'interface de ligne de commande suivante pour redémarrer le service dégradé : kubectl rollout restart &ltstatefulset/deployment&gt &ltservice_name&gt -n &ltnamespace&gt Déterminez l'état du service de base de données de protection contre les programmes malveillants.

L'état du service est dégradé.

Lorsque l'événement est détecté : Le service {mps_service_name} est dégradé sur NSX Application Platform. Il ne peut pas communiquer avec le service analyst_api. Les verdicts des fichiers inspectés peuvent ne pas être à jour.  »

Lorsque l'événement est résolu : « Le service {mps_service_name} s'exécute correctement sur NSX Application Platform.  »

Dans l'interface utilisateur NSX, accédez à Système | NSX Application Platform | Services de base pour vérifier quel service est dégradé. Appelez la NSX API GET /napp/api/v1/platform/monitor/feature/health pour vérifier quel service spécifique est inactif et la raison. Appelez la commande d'interface de ligne de commande suivante pour redémarrer le service dégradé : kubectl rollout restart &ltstatefulset/deployment&gt &ltservice_name&gt -n &ltnamespace&gt Déterminez l'état du service Cloud Connector de protection contre les programmes malveillants.

L'état du service est dégradé.

Lorsque l'événement est détecté : Le service {mps_service_name} est dégradé sur NSX Application Platform. Il ne peut pas communiquer avec le service de réputation NTICS. Les réputations de fichiers inspectées peuvent ne pas être à jour.  »

Lorsque l'événement est résolu : « Le service {mps_service_name} s'exécute correctement sur NSX Application Platform.  »

Dans l'interface utilisateur NSX, accédez à Système | NSX Application Platform | Services de base pour vérifier quel service est dégradé. Appelez la NSX API GET /napp/api/v1/platform/monitor/feature/health pour vérifier quel service spécifique est inactif et la raison. Appelez la commande d'interface de ligne de commande suivante pour redémarrer le service dégradé : kubectl rollout restart &ltstatefulset/deployment&gt &ltservice_name&gt -n &ltnamespace&gt Déterminez si l'accès au service NTICS est inactif.

L'utilisation du CPU du nœud de gestionnaire est très élevée.

Lorsque l'événement est détecté : « L'utilisation du CPU de sur le nœud Gestionnaire {entity_id} a atteint {system_resource_usage} %, ce qui est supérieur ou égal à la valeur de seuil très élevée de {system_usage_threshold} %.  »

Lorsque l'événement est résolu : « L'utilisation du CPU de sur le nœud Gestionnaire {entity_id} a atteint {system_resource_usage} %, ce qui est inférieur à la valeur de seuil très élevée de {system_usage_threshold} %.  »

Vérifiez la configuration, les services en cours d'exécution et le dimensionnement de ce nœud de gestionnaire. Pensez à ajuster la taille du facteur de forme du dispositif de gestionnaire.

L'utilisation du CPU du nœud de gestionnaire est élevée.

Lorsque l'événement est détecté : « L'utilisation du CPU de sur le nœud Gestionnaire {entity_id} a atteint {system_resource_usage} %, ce qui est supérieur ou égal à la valeur de seuil élevée de {system_usage_threshold} %.  »

Lorsque l'événement est résolu : « L'utilisation du CPU de sur le nœud Gestionnaire {entity_id} a atteint {system_resource_usage} %, ce qui est inférieur à la valeur de seuil élevée de {system_usage_threshold} %.  »

Vérifiez la configuration, les services en cours d'exécution et le dimensionnement de ce nœud de gestionnaire. Pensez à ajuster la taille du facteur de forme du dispositif de gestionnaire.

L'utilisation de la mémoire du nœud de gestionnaire est très élevée.

Lorsque l'événement est détecté : « L'utilisation de la mémoire sur le nœud Gestionnaire {entity_id} a atteint {system_resource_usage} %, ce qui est supérieur ou égal à la valeur de seuil très élevée de {system_usage_threshold} %.  »

Lorsque l'événement est résolu : « L'utilisation de la mémoire sur le nœud Gestionnaire {entity_id} a atteint {system_resource_usage} %, ce qui est inférieur à la valeur de seuil très élevée de {system_usage_threshold} %.  »

Vérifiez la configuration, les services en cours d'exécution et le dimensionnement de ce nœud de gestionnaire. Pensez à ajuster la taille du facteur de forme du dispositif de gestionnaire.

L'utilisation de la mémoire du nœud de gestionnaire est élevée.

Lorsque l'événement est détecté : « L'utilisation de la mémoire sur le nœud Gestionnaire {entity_id} a atteint {system_resource_usage} %, ce qui est supérieur ou égal à la valeur de seuil élevée de {system_usage_threshold} %.  »

Lorsque l'événement est résolu : « L'utilisation de la mémoire sur le nœud Gestionnaire {entity_id} a atteint {system_resource_usage} %, ce qui est inférieur à la valeur de seuil élevée de {system_usage_threshold} %.  »

Vérifiez la configuration, les services en cours d'exécution et le dimensionnement de ce nœud de gestionnaire. Pensez à ajuster la taille du facteur de forme du dispositif de gestionnaire.

L'utilisation du disque du nœud de gestionnaire est très élevée.

Lorsque l'événement est détecté : « L'utilisation du disque pour la partition de disque du nœud Gestionnaire {disk_partition_name} a atteint {system_resource_usage} %, ce qui est supérieur ou égal à la valeur de seuil très élevée de {system_usage_threshold} %.  »

Lorsque l'événement est résolu : « L'utilisation du disque pour la partition de disque du nœud Gestionnaire {disk_partition_name} a atteint {system_resource_usage} %, ce qui est inférieur à la valeur de seuil très élevée de {system_usage_threshold} %.  »

Examinez la partition ayant une utilisation élevée et vérifiez si des fichiers volumineux inattendus peuvent être supprimés.

L'utilisation du disque du nœud de gestionnaire est élevée.

Lorsque l'événement est détecté : « L'utilisation du disque pour la partition de disque du nœud Gestionnaire {disk_partition_name} a atteint {system_resource_usage} %, ce qui est supérieur ou égal à la valeur de seuil élevée de {system_usage_threshold} %.  »

Lorsque l'événement est résolu : « L'utilisation du disque pour la partition de disque du nœud Gestionnaire {disk_partition_name} a atteint {system_resource_usage} %, ce qui est inférieur à la valeur de seuil élevée de {system_usage_threshold} %.  »

Examinez la partition ayant une utilisation élevée et vérifiez si des fichiers volumineux inattendus peuvent être supprimés.

L'utilisation du disque de configuration du nœud de gestionnaire est très élevée.

Lorsque l'événement est détecté : « L'utilisation du disque pour la partition/configuration de disque du nœud Gestionnaire a atteint {system_resource_usage} %, ce qui est supérieur ou égal à la valeur de seuil très élevée de {system_usage_threshold} %. Cela peut indiquer une utilisation élevée du disque par le service de banque de données NSX dans le répertoire /config/corfu.  »

Lorsque l'événement est résolu : « L'utilisation du disque pour la partition/configuration de disque du nœud Gestionnaire a atteint {system_resource_usage} %, ce qui est inférieur à la valeur de seuil très élevée de {system_usage_threshold} %.  »

Exécutez l'outil suivant et contactez GSS si des problèmes sont signalés : /opt/vmware/tools/support/inspect_checkpoint_issues.py

L'utilisation du disque de configuration du nœud de gestionnaire est élevée.

Lorsque l'événement est détecté : « L'utilisation du disque pour la partition/configuration de disque du nœud Gestionnaire a atteint {system_resource_usage} %, ce qui est supérieur ou égal à la valeur de seuil élevée de {system_usage_threshold} %. Cela peut indiquer une utilisation croissante du disque par le service de banque de données NSX dans le répertoire /config/corfu.  »

Lorsque l'événement est résolu : « L'utilisation du disque pour la partition de disque/config du nœud de gestionnaire a atteint {system_resource_usage} %, ce qui est inférieur à la valeur de seuil élevée de {system_usage_threshold} %.  »

Exécutez l'outil suivant et contactez GSS si des problèmes sont signalés : /opt/vmware/tools/support/inspect_checkpoint_issues.py

L'utilisation du disque de non-configuration du nœud de gestionnaire est très élevée.

Lorsque l'événement est détecté : « L'utilisation du disque pour la partition/non-config de disque du nœud de gestionnaire a atteint {system_resource_usage} %, ce qui est supérieur ou égal à la valeur de seuil très élevée de {system_usage_threshold} %. Cela peut indiquer une utilisation élevée du disque par le service de banque de données NSX dans le répertoire /nonconfig/corfu.  »

Lorsque l'événement est résolu : « L'utilisation du disque pour la partition/non-config de disque du nœud de gestionnaire a atteint {system_resource_usage} %, ce qui est inférieur à la valeur de seuil très élevée de {system_usage_threshold} %.  »

Exécutez l'outil suivant et contactez GSS si des problèmes sont signalés : /opt/vmware/tools/support/inspect_checkpoint_issues.py --nonconfig

L'utilisation du disque de non-configuration du nœud de gestionnaire est élevée.

Lorsque l'événement est détecté : « L'utilisation du disque pour la partition/non-config de disque du nœud de gestionnaire a atteint {system_resource_usage} %, ce qui est supérieur ou égal à la valeur de seuil élevée de {system_usage_threshold} %. Cela peut indiquer une utilisation croissante du disque par le service de banque de données NSX dans le répertoire /nonconfig/corfu.  »

Lorsque l'événement est résolu : « L'utilisation du disque pour la partition/non-config de disque du nœud de gestionnaire a atteint {system_resource_usage} %, ce qui est inférieur à la valeur de seuil élevée de {system_usage_threshold} %.  »

Exécutez l'outil suivant et contactez GSS si des problèmes sont signalés : /opt/vmware/tools/support/inspect_checkpoint_issues.py --nonconfig

L'adresse IP du nœud de gestionnaire est utilisée par un autre périphérique.

Lorsque l'événement est détecté : « L'adresse IP {duplicate_ip_address} du nœud de gestionnaire {entity_id} est actuellement utilisée par un autre périphérique du réseau.  »

Lorsque l'événement est résolu : « Le périphérique utilisant l'adresse IP attribuée au nœud de gestionnaire {entity_id} semble ne plus utiliser {duplicate_ip_address}.  »

1. Déterminez le périphérique qui utilise l'adresse IP du gestionnaire et attribuez-lui une nouvelle adresse IP. Remarque : la reconfiguration du gestionnaire pour utiliser une nouvelle adresse IP n'est pas prise en charge.
2. Assurez-vous que le pool d'adresses IP statiques/serveur DHCP est correctement configuré.
3. Corrigez l'adresse IP du périphérique si elle est attribuée manuellement.

Le disque du nœud de gestionnaire est en lecture seule.

Lorsque l'événement est détecté : « La partition de disque suivante sur le nœud de gestionnaire {entity_id} est en mode lecture seule : {Disk_partition_name} »

Lorsque l'événement est résolu : « La partition de disque suivante sur le nœud de gestionnaire {entity_id} a récupéré du mode lecture seule : {disk_partition_name} »

Examinez la partition en lecture seule pour savoir si le redémarrage résout le problème ou si vous devez remplacer le disque. Contactez GSS pour obtenir plus d'informations.

L'entrée DNS du nom de domaine complet du gestionnaire est manquante.

Lorsque l'événement est détecté : « La configuration DNS du nœud de gestionnaire {manager_node_name} ({entity_id}) est incorrecte. Le nœud de gestionnaire est à double pile et/ou un certificat d'API signé par une autorité de certification est utilisé, mais la ou les adresses IP du nœud de gestionnaire ne sont pas résolues en nom de domaine complet ou résolues en différents noms de domaine complets.  »

Lorsque l'événement est résolu : « La configuration DNS du nœud de gestionnaire {manager_node_name} ({entity_id}) est correcte. Soit le nœud de gestionnaire n'est pas à double pile et le certificat API signé par une autorité de certification n'est plus utilisé, soit la ou les adresses IP du nœud de gestionnaire sont résolues sur le même nom de domaine complet.  »

1. Assurez-vous que les serveurs DNS appropriés sont configurés dans le nœud de gestionnaire.
2. Assurez-vous que les enregistrements A et PTR appropriés sont configurés dans les serveurs DNS de sorte que la recherche inversée des adresses IP du nœud de gestionnaire renvoie le même nom de domaine complet et que la recherche directe du nom de domaine complet renvoie toutes les adresses IP du nœud de gestionnaire.
3. Si le nœud de gestionnaire n'est pas à double pile, remplacez le certificat signé par une autorité de certification pour le type de service API par un certificat auto-signé.

Entrée de nom de domaine complet manquante pour l'adresse IP virtuelle du gestionnaire.

Lorsque l'événement est détecté : « Dans le cas d'un certificat d'API à double pile ou signé par une autorité de certification pour une instance de NSX Manager, l'adresse IPv4 virtuelle {ipv4_address} et l'adresse IPv6 virtuelle {ipv6_address} pour le nœud de gestionnaire {entity_id} doivent être résolues sur le même nom de domaine complet.  »

Lorsque l'événement est résolu : « Les adresses IP virtuelles à double pile pour le nœud de gestionnaire {entity_id} doivent être résolues sur le même nom de domaine complet.  »

Examinez l'entrée DNS des adresses IP virtuelles pour voir si elles sont résolues sur le même nom de domaine complet.

Incohérence de configuration de MTU entre les nœuds de transport attachés à la même zone de transport.

Lorsque l'événement est détecté : « Incompatibilité de configuration MTU entre les nœuds de transport (ESXi, KVM et Edge) attachés à la même zone de transport. Les valeurs MTU sur tous les commutateurs attachés à la même zone de transport qui ne sont pas cohérentes entraînent des problèmes de connectivité.  »

Lorsque l'événement est résolu : « Toutes les valeurs MTU entre les nœuds de transport attachés à la même zone de transport sont maintenant cohérentes.  »

1. Accédez à Système | Infrastructure | Paramètres | Vérification de la configuration MTU | Incohérent sur l'interface utilisateur NSX pour vérifier d'autres détails de non-correspondance.
2. Définissez la même valeur MTU sur tous les commutateurs attachés à la même zone de transport en appelant la NSX API PUT /api/v1/host-switch-profiles/&lthost-switch-profile-id&gt avec mtu dans le corps de la demande, ou API PUT /api/v1/global-configs/SwitchingGlobalConfig avec physical_uplink_mtu dans le corps de la demande.

La configuration du MTU du routeur global est plus volumineuse que le MTU de la zone de transport de superposition.

Lorsque l'événement est détecté : « La configuration MTU du routeur global est plus volumineuse que le MTU des commutateurs dans la zone de transport de superposition qui se connecte au niveau 0 ou au niveau 1. La valeur MTU du routeur global doit être inférieure à la valeur MTU de tous les commutateurs d'au moins 100, car nous avons besoin d'un quota de 100 pour l'encapsulation Geneve.  »

Lorsque l'événement est résolu : « Le MTU du routeur global est maintenant inférieur au MTU de la zone de transport de superposition.  »

1. Accédez à Système | Infrastructure | Paramètres | Vérification de la configuration MTU | Incohérent sur l'interface utilisateur NSX pour vérifier d'autres détails de non-correspondance.
2. Définissez la valeur MTU supérieure sur les commutateurs en appelant la NSX API PUT /api/v1/host-switch-profiles/&lthost-switch-profile-id&gt avec mtu dans le corps de la demande, ou l'API PUT /api/v1/global-configs/SwitchingGlobalConfig avec physical_uplink_mtu dans le corps de la demande.
3. Vous pouvez également définir la valeur de MTU inférieure de la configuration du routeur global en appelant la NSX API PUT /api/v1/global-configs/RoutingGlobalConfig avec logical_uplink_mtu dans le corps de la demande.

L'utilisation du port SNAT sur la passerelle est élevée.

Lorsque l'événement est détecté : « L'utilisation des ports SNAT sur le routeur logique {entity_id} pour l'adresse IP SNAT {snat_ip_address} a atteint la valeur de seuil élevée de {system_usage_threshold} %. Les nouveaux flux ne seront pas pris en charge lorsque l'utilisation atteint la limite maximale.  »

Lorsque l'événement est résolu : « L'utilisation des ports SNAT sur le routeur logique {entity_id} pour l'adresse IP SNAT {snat_ip_address} est passée en dessous de la valeur de seuil élevée de {system_usage_threshold} %.  »

Connectez-vous en tant qu'utilisateur Admin sur le nœud Edge et appelez la commande CLI NSX get firewall &ltLR_INT_UUID&gt l'état de connexion en utilisant l'UUID d'interface de droite et vérifiez divers mappages SNAT pour l'adresse IP SNAT {snat_ip_address}. Vérifiez que les flux de trafic passant par la passerelle ne sont pas une attaque de déni de service ou une rafale anormale. Si le trafic semble être dans la charge normale, mais que le seuil d'alarme est atteint, envisagez d'ajouter d'autres adresses IP SNAT pour distribuer la charge ou acheminer le nouveau trafic vers un autre nœud Edge.

Le nœud de gestionnaire a détecté que NCP est inactif ou défectueux.

Lorsque l'événement est détecté : « Le nœud de gestionnaire a détecté que le NCP est inactif ou défectueux.  »

Lorsque l'événement est résolu : « Le nœud de gestionnaire a détecté que le NCP est de nouveau actif ou sain.  »

Pour rechercher les clusters qui rencontrent des problèmes, utilisez l'interface utilisateur NSX et accédez à la page Alarmes. La valeur du nom de l'entité pour cette instance d'alarme identifie le nom du cluster. Vous pouvez également appeler la NSX API GET /api/v1/systemhealth/container-cluster/ncp/status pour extraire tous les états des clusters et déterminer le nom des clusters qui signalent INACTIF ou INCONNU. Ensuite, sur la page Inventaire | Conteneur | Clusters de l'interface utilisateur NSX, recherchez le cluster par nom et cliquez sur l'onglet Nœuds qui répertorie tous les membres du cluster Kubernetes et PAS. Pour le cluster Kubernetes :
1. Vérifiez la réactivité de l'espace NCP en recherchant le nœud master K8s à partir de tous les membres du cluster et connectez-vous au nœud master. Appelez ensuite la commande kubectl kubectl get pods --all-namespaces. En cas de problème avec l'espace NCP, utilisez la commande kubectl logs pour vérifier le problème et corriger l'erreur.
2. Vérifiez la connexion entre NCP et Kubernetes API Server. La CLI NSX peut être utilisée à l'intérieur de l'espace NCP pour vérifier cet état de connexion en appelant les commandes suivantes à partir de la machine virtuelle maître. kubectl exec -it &ltNCP-Pod-Name&gt -n nsx-system bash nsxcli get ncp-k8s-api-server En cas de problème avec la connexion, vérifiez les configurations réseau et NCP.
3. Vérifiez la connexion entre NCP et NSX Manager. La CLI NSX peut être utilisée dans l'espace NCP pour vérifier cet état de connexion en appelant la commande suivante à partir de la machine virtuelle maître. kubectl exec -it &ltNCP-Pod-Name&gt -n nsx-system bash nsxcli get ncp-nsx status En cas de problème avec la connexion, vérifiez les configurations réseau et NCP. Pour le cluster PAS :
1. Vérifiez les connexions réseau entre les machines virtuelles et corrigez les problèmes réseau.
2. Vérifiez l'état des nœuds et des services et corrigez ceux qui sont bloqués. Appelez la commande bosh vms et bosh instances -p pour vérifier l'état des nœuds et des services.

Les agents exécutés à l'intérieur de la VM du nœud semblent être inactifs sur DPU.

Lorsque l'événement est détecté : « Les agents exécutés à l'intérieur de la VM du nœud semblent être inactifs sur DPU {dpu_id}.  »

Lorsque l'événement est résolu : « Les agents à l'intérieur de la VM de nœud sont en cours d'exécution sur DPU {dpu_id}.  »

1. Si Vmk50 sur DPU {dpu_id} est manquant, reportez-vous à cet article de la base de connaissances https://kb.vmware.com/s/article/67432.
2. Si Hyperbus 4094 sur DPU {dpu_id} est manquant, le redémarrage de nsx-cfgagent sur DPU {dpu_id} ou le redémarrage de la machine virtuelle de l'hôte de conteneur peut aider.
3. Si la VIF de l'hôte du conteneur est bloquée, vérifiez la connexion au contrôleur pour vous assurer que toutes les configurations sont envoyées.
4. Si nsx-cfg-agent sur DPU {dpu_id} s'est arrêté, redémarrez nsx-cfgagent sur DPU {dpu_id}.
5. Si le module node-agent est manquant, vérifiez s'il a été correctement installé sur la VM de l'hôte du conteneur.
6. Si l'interface du module node-agent sur la VM de l'hôte du conteneur est inactive, vérifiez l'état de l'interface eth1 sur la VM de l'hôte du conteneur.

Les agents exécutés à l'intérieur de la VM du nœud semblent être inactifs.

Lorsque l'événement est détecté : « Les agents exécutés à l'intérieur de la VM du nœud semblent être inactifs.  »

Lorsque l'événement est résolu : « Les agents à l'intérieur de la VM de nœud sont en cours d'exécution.  »

Pour ESX :
1. Si Vmk50 est manquant, reportez-vous à cet article de la base de connaissances https://kb.vmware.com/s/article/67432.
2. Si Hyperbus 4094 est manquant, le redémarrage de nsx-cfgagent ou de la VM de l'hôte du conteneur peut aider.
3. Si la VIF de l'hôte du conteneur est bloquée, vérifiez la connexion au contrôleur pour vous assurer que toutes les configurations sont envoyées.
4. Si nsx-cfg-agent s'est arrêté, redémarrez nsx-cfgagent. Pour KVM :
1. Si l'espace de noms Hyperbus est manquant, le redémarrage de nsx-opsagent peut aider à le recréer.
2. Si l'interface Hyperbus est manquante dans l'espace de noms Hyperbus, le redémarrage de nsx-opsagent peut aider.
3. Si nsx-agent s'est arrêté, redémarrez nsx-agent. Pour ESX et KVM :
1. Si le module node-agent est manquant, vérifiez s'il a été correctement installé sur la VM de l'hôte du conteneur.
2. Si l'interface du module node-agent sur la VM de l'hôte du conteneur est inactive, vérifiez l'état de l'interface eth1 sur la VM de l'hôte du conteneur.

Le cluster NSX Application Platform est déconnecté du cluster de gestion NSX.

Lorsque l'événement est détecté : « Le cluster NSX Application Platform {napp_cluster_id} est déconnecté du cluster de gestion NSX.  »

Lorsque l'événement est résolu : « Le cluster NSX Application Platform {napp_cluster_id} est reconnecté au cluster de gestion NSX.  »

Vérifiez si le certificat du cluster de gestionnaire, les certificats de nœud de gestionnaire, le certificat Kafka et le certificat d'entrée correspondent à la fois sur NSX Manager et sur le cluster NSX Application Platform. Vérifiez les dates d'expiration des certificats mentionnés ci-dessus pour vous assurer qu'ils sont valides. Vérifiez la connexion réseau entre NSX Manager et NSX cluster Application Platform et résolvez les éventuels échecs de connexion réseau.

Ralentissement du traitement des données détecté dans la rubrique de messagerie Flux brut.

Lorsque l'événement est détecté : « Le nombre de messages en attente dans la rubrique de messagerie Flux brut dépasse le seuil de messages en attente de {napp_messaging_lag_threshold}  »

Lorsque l'événement est résolu : « Le nombre de messages en attente dans la rubrique de messagerie Flux brut est inférieur au seuil de messages en attente de {napp_messaging_lag_threshold}.  »

Ajoutez des nœuds, puis faites monter en puissance le cluster NSX Application Platform. Si le goulot d'étranglement peut être attribué à un service spécifique, par exemple le service d'analyse, alors faites monter en puissance le service spécifique lors de l'ajout de nouveaux nœuds.

Ralentissement du traitement des données détecté dans la rubrique de messagerie de dépassement.

Lorsque l'événement est détecté : « Le nombre de messages en attente dans la rubrique de messagerie Flux de dépassement dépasse le seuil de messages en attente de {napp_messaging_lag_threshold}.  »

Lorsque l'événement est résolu : « Le nombre de messages en attente dans la rubrique de messagerie Flux de dépassement est inférieur au seuil de messages en attente de {napp_messaging_lag_threshold}.  »

Ajoutez des nœuds, puis faites monter en puissance le cluster NSX Application Platform. Si le goulot d'étranglement peut être attribué à un service spécifique, par exemple le service d'analyse, alors faites monter en puissance le service spécifique lors de l'ajout de nouveaux nœuds.

Un nœud de transport est déconnecté de son Broker de messagerie du cluster NSX Application Platform. Cela affecte la collecte de données.

Lorsque l'événement est détecté : « L'exportateur de flux sur le nœud de transport {entity_id} est déconnecté du Broker de messagerie du cluster NSX Application Platform. Cela affecte la collecte de données.  »

Lorsque l'événement est résolu : « L'exportateur de flux sur le nœud de transport {entity_id} s'est reconnecté au Broker de messagerie du cluster NSX Application Platform.  »

Redémarrez le service de messagerie s'il n'est pas en cours d'exécution dans le cluster NSX Application Platform. Résolvez l'échec de connexion réseau entre l'exportateur de flux du nœud de transport et le cluster NSX Application Platform.

Un nœud de transport est déconnecté de son broker de messagerie de nœud Intelligence. La collecte de données est affectée sur DPU.

Lorsque l'événement est détecté : « L'exportateur de flux sur le nœud de transport {entity_id} DPU {dpu_id} est déconnecté du Broker de messagerie du nœud Intelligence. Cela affecte la collecte de données.  »

Lorsque l'événement est résolu : « L'exportateur de flux sur le nœud de transport {entity_id} DPU {dpu_id} s'est reconnecté au Broker de messagerie du nœud Intelligence.  »

Redémarrez le service de messagerie s'il n'est pas en cours d'exécution dans le nœud Intelligence. Résolvez l'échec de la connexion réseau entre l'exportateur de flux de nœud de transport et le nœud Intelligence.

L'utilisation du CPU du cluster NSX Application Platform est très élevée.

Lorsque l'événement est détecté : « L'utilisation du CPU du cluster NSX Application Platform {napp_cluster_id} est supérieure à la valeur de seuil très élevée de {system_usage_threshold} %.  »

Lorsque l'événement est résolu : « L'utilisation du CPU du cluster NSX Application Platform {napp_cluster_id} est inférieure à la valeur de seuil très élevée de {system_usage_threshold} %.  »

Dans l'interface utilisateur NSX, accédez à Système | NSX Application Platform | Services de base et vérifiez le champ Charge du système des services individuels pour voir quel service est sous pression. Vérifiez si la charge peut être réduite. Si plus de puissance de calcul est requise, cliquez sur le bouton Monter en charge pour demander plus de ressources.

L'utilisation du CPU du cluster NSX Application Platform est élevée.

Lorsque l'événement est détecté : « L'utilisation du CPU du cluster NSX Application Platform {napp_cluster_id} est supérieure à la valeur de seuil élevée de {system_usage_threshold} %.  »

Lorsque l'événement est résolu : « L'utilisation du CPU du cluster NSX Application Platform {napp_cluster_id} est inférieure à la valeur de seuil élevée de {system_usage_threshold} %.  »

Dans l'interface utilisateur NSX, accédez à Système | NSX Application Platform | Services de base et vérifiez le champ Charge du système des services individuels pour voir quel service est sous pression. Vérifiez si la charge peut être réduite. Si plus de puissance de calcul est requise, cliquez sur le bouton Monter en charge pour demander plus de ressources.

L'utilisation de la mémoire du cluster NSX Application Platform est très élevée.

Lorsque l'événement est détecté : « L'utilisation de la mémoire du cluster NSX Application Platform {napp_cluster_id} est supérieure à la valeur de seuil très élevée de {system_usage_threshold} %.  »

Lorsque l'événement est résolu : « L'utilisation de la mémoire du cluster NSX Application Platform {napp_cluster_id} est inférieure à la valeur de seuil très élevée de {system_usage_threshold} %.  »

Dans l'interface utilisateur NSX, accédez à Système | NSX Application Platform | Services de base et vérifiez le champ Mémoire des services individuels pour voir quel service est sous pression. Vérifiez si la charge peut être réduite. Si davantage de mémoire est nécessaire, cliquez sur le bouton Monter en charge pour demander plus de ressources.

L'utilisation de la mémoire du cluster NSX Application Platform est élevée.

Lorsque l'événement est détecté : « L'utilisation de la mémoire du cluster NSX Application Platform {napp_cluster_id} est supérieure à la valeur de seuil élevée de {system_usage_threshold} %.  »

Lorsque l'événement est résolu : « L'utilisation de la mémoire du cluster NSX Application Platform {napp_cluster_id} est inférieure à la valeur de seuil élevée de {system_usage_threshold} %.  »

Dans l'interface utilisateur NSX, accédez à Système | NSX Application Platform | Services de base et vérifiez le champ Mémoire des services individuels pour voir quel service est sous pression. Vérifiez si la charge peut être réduite. Si davantage de mémoire est nécessaire, cliquez sur le bouton Monter en charge pour demander plus de ressources.

L'utilisation du disque du cluster NSX Application Platform est très élevée.

Lorsque l'événement est détecté : « L'utilisation du cluster NSX Application Platform {napp_cluster_id} est supérieure à la valeur de seuil très élevée de {system_usage_threshold} %.  »

Lorsque l'événement est résolu : « L'utilisation du cluster NSX Application Platform {napp_cluster_id} est inférieure à la valeur de seuil très élevée de {system_usage_threshold} %.  »

Dans l'interface utilisateur NSX, accédez à Système | NSX Application Platform | Services de base et vérifiez le champ Stockage des services individuels pour déterminer quel service est sous pression. Vérifiez si la charge peut être réduite. Si davantage de stockage sur disque est requis, cliquez sur le bouton Monter en charge pour demander plus de ressources. Si le service de stockage de données est sous contrainte, une autre manière consiste à cliquer sur le bouton Monter en puissance pour augmenter la taille du disque.

L'utilisation du disque du cluster NSX Application Platform est élevée.

Lorsque l'événement est détecté : « L'utilisation du disque du cluster NSX Application Platform {napp_cluster_id} est supérieure à la valeur de seuil élevée de {system_usage_threshold} %.  »

Lorsque l'événement est résolu : « L'utilisation du disque du cluster NSX Application Platform {napp_cluster_id} est inférieure à la valeur de seuil élevée de {system_usage_threshold} %.  »

Dans l'interface utilisateur NSX, accédez à Système | NSX Application Platform | Services de base et vérifiez le champ Stockage des services individuels pour déterminer quel service est sous pression. Vérifiez si la charge peut être réduite. Si davantage de stockage sur disque est requis, cliquez sur le bouton Monter en charge pour demander plus de ressources. Si le service de stockage de données est sous contrainte, une autre manière consiste à cliquer sur le bouton Monter en puissance pour augmenter la taille du disque.

L'état global du cluster NSX Application Platform est dégradé.

Lorsque l'événement est détecté : « L'état global du cluster NSX Application Platform {napp_cluster_id} est dégradé.  »

Lorsque l'événement est résolu : « Le cluster NSX Application Platform {napp_cluster_id} s'exécute correctement.  »

Obtenez plus d'informations des alarmes de nœuds et de services.

L'état global du cluster NSX Application Platform est inactif.

Lorsque l'événement est détecté : « L'état global du cluster NSX Application Platform {napp_cluster_id} est inactif.  »

Lorsque l'événement est résolu : « Le cluster NSX Application Platform {napp_cluster_id} s'exécute correctement.  »

Obtenez plus d'informations des alarmes de nœuds et de services.

L'utilisation du CPU du nœud NSX Application Platform est très élevée.

Lorsque l'événement est détecté : « L'utilisation du CPU du nœud NSX Application Platform {napp_node_name} est supérieure à la valeur de seuil très élevée de {system_usage_threshold} %.  »

Lorsque l'événement est résolu : « L'utilisation du CPU du nœud NSX Application Platform {napp_node_name} est inférieure à la valeur de seuil très élevée de {system_usage_threshold} %.  »

Dans l'interface utilisateur NSX, accédez à Système | NSX Application Platform | Services de base et vérifiez le champ Charge du système des services individuels pour voir quel service est sous pression. Vérifiez si la charge peut être réduite. Si seule une petite minorité des nœuds a une utilisation élevée du CPU, Kubernetes replanifie les services automatiquement par défaut. Si la plupart des nœuds ont une utilisation élevée du CPU et que la charge ne peut pas être réduite, cliquez sur le bouton Monter en charge pour demander plus de ressources.

L'utilisation du CPU du nœud NSX Application Platform est élevée.

Lorsque l'événement est détecté : « L'utilisation du CPU du nœud NSX Application Platform {napp_node_name} est supérieure à la valeur de seuil élevée de {system_usage_threshold} %.  »

Lorsque l'événement est résolu : « L'utilisation du CPU du nœud NSX Application Platform {napp_node_name} est inférieure à la valeur de seuil élevée de {system_usage_threshold} %.  »

Dans l'interface utilisateur NSX, accédez à Système | NSX Application Platform | Services de base et vérifiez le champ Charge du système des services individuels pour voir quel service est sous pression. Vérifiez si la charge peut être réduite. Si seule une petite minorité des nœuds a une utilisation élevée du CPU, Kubernetes replanifie les services automatiquement par défaut. Si la plupart des nœuds ont une utilisation élevée du CPU et que la charge ne peut pas être réduite, cliquez sur le bouton Monter en charge pour demander plus de ressources.

L'utilisation de la mémoire du nœud NSX Application Platform est très élevée.

Lorsque l'événement est détecté : « L'utilisation de la mémoire du nœud NSX Application Platform {napp_node_name} est supérieure à la valeur de seuil très élevée de {system_usage_threshold} %.  »

Lorsque l'événement est résolu : « L'utilisation de la mémoire du nœud NSX Application Platform {napp_node_name} est inférieure à la valeur de seuil très élevée de {system_usage_threshold} %.  »

Dans l'interface utilisateur NSX, accédez à Système | NSX Application Platform | Services de base et vérifiez le champ Mémoire des services individuels pour voir quel service est sous pression. Vérifiez si la charge peut être réduite. Si seule une petite minorité des nœuds a une utilisation élevée de la mémoire, Kubernetes replanifie les services automatiquement par défaut. Si la plupart des nœuds ont une utilisation élevée de la mémoire et que la charge ne peut pas être réduite, cliquez sur le bouton Monter en charge pour demander plus de ressources.

L'utilisation de la mémoire du nœud NSX Application Platform est élevée.

Lorsque l'événement est détecté : « L'utilisation du CPU de la mémoire NSX Application Platform {napp_node_name} est supérieure à la valeur de seuil élevée de {system_usage_threshold} %.  »

Lorsque l'événement est résolu : « L'utilisation du CPU de la mémoire NSX Application Platform {napp_node_name} est inférieure à la valeur de seuil élevée de {system_usage_threshold} %.  »

Dans l'interface utilisateur NSX, accédez à Système | NSX Application Platform | Services de base et vérifiez le champ Mémoire des services individuels pour voir quel service est sous pression. Vérifiez si la charge peut être réduite. Si seule une petite minorité des nœuds a une utilisation élevée de la mémoire, Kubernetes replanifie les services automatiquement par défaut. Si la plupart des nœuds ont une utilisation élevée de la mémoire et que la charge ne peut pas être réduite, cliquez sur le bouton Monter en charge pour demander plus de ressources.

L'utilisation du disque du nœud NSX Application Platform est très élevée.

Lorsque l'événement est détecté : « L'utilisation du disque du nœud NSX Application Platform {napp_node_name} est supérieure à la valeur de seuil très élevée de {system_usage_threshold} %.  »

Lorsque l'événement est résolu : « L'utilisation du disque du nœud NSX Application Platform {napp_node_name} est inférieure à la valeur de seuil très élevée de {system_usage_threshold} %.  »

Dans l'interface utilisateur NSX, accédez à Système | NSX Application Platform | Services de base et vérifiez le champ Stockage des services individuels pour déterminer quel service est sous pression. Nettoyez les données ou les journaux inutilisés pour libérer des ressources de disque et voir si la charge peut être réduite. Si davantage de stockage sur disque est requis, augmentez la charge du service sous pression. Si le service de stockage de données est sous contrainte, une autre manière consiste à cliquer sur le bouton Monter en puissance pour augmenter la taille du disque.

L'utilisation du disque du nœud NSX Application Platform est élevée.

Lorsque l'événement est détecté : « L'utilisation du CPU du disque NSX Application Platform {napp_node_name} est supérieure à la valeur de seuil élevée de {system_usage_threshold} %.  »

Lorsque l'événement est résolu : « L'utilisation du CPU du disque NSX Application Platform {napp_node_name} est inférieure à la valeur de seuil élevée de {system_usage_threshold} %.  »

Dans l'interface utilisateur NSX, accédez à Système | NSX Application Platform | Services de base et vérifiez le champ Stockage des services individuels pour déterminer quel service est sous pression. Nettoyez les données ou les journaux inutilisés pour libérer des ressources de disque et voir si la charge peut être réduite. Si davantage de stockage sur disque est requis, augmentez la charge du service sous pression. Si le service de stockage de données est sous contrainte, une autre manière consiste à cliquer sur le bouton Monter en puissance pour augmenter la taille du disque.

L'état du nœud NSX Application Platform est dégradé.

Lorsque l'événement est détecté : Le nœud NSX Application Platform {napp_node_name} est dégradé.  »

Lorsque l'événement est résolu : « Le nœud NSX Application Platform {napp_node_name} s'exécute correctement.  »

Dans l'interface utilisateur NSX, accédez à Système | NSX Application Platform | Ressources pour vérifier quel nœud est dégradé. Vérifiez l'utilisation du réseau, de la mémoire et du CPU du nœud. Redémarrez le nœud s'il s'agit d'un nœud worker.

L'état du nœud NSX Application Platform est inactif.

Lorsque l'événement est détecté : « Le nœud NSX Application Platform {napp_node_name} n'est pas en cours d'exécution.  »

Lorsque l'événement est résolu : « Le nœud NSX Application Platform {napp_node_name} s'exécute correctement.  »

Dans l'interface utilisateur NSX, accédez à Système | NSX Application Platform | Ressources pour vérifier quel nœud est inactif. Vérifiez l'utilisation du réseau, de la mémoire et du CPU du nœud. Redémarrez le nœud s'il s'agit d'un nœud worker.

L'utilisation du CPU du service de stockage de données est très élevée.

Lorsque l'événement est détecté : « L'utilisation du CPU du service de stockage de données est supérieure à la valeur de seuil très élevée de {system_usage_threshold} %.  »

Lorsque l'événement est résolu : « L'utilisation du CPU du service de stockage de données est inférieure à la valeur de seuil très élevée de {system_usage_threshold} %.  »

Montez en charge tous les services ou le service de stockage de données.

L'utilisation du CPU du service de stockage de données est élevée.

Lorsque l'événement est détecté : « L'utilisation du CPU du service de stockage de données est supérieure à la valeur de seuil élevée de {system_usage_threshold} %.  »

Lorsque l'événement est résolu : « L'utilisation du CPU du service de stockage de données est inférieure à la valeur de seuil élevée de {system_usage_threshold} %.  »

Montez en charge tous les services ou le service de stockage de données.

L'utilisation du CPU du service de messagerie est très élevée.

Lorsque l'événement est détecté : « L'utilisation du CPU du service de messagerie est supérieure à la valeur de seuil très élevée de {system_usage_threshold} %.  »

Lorsque l'événement est résolu : « L'utilisation du CPU du service de messagerie est inférieure à la valeur de seuil très élevée de {system_usage_threshold} %.  »

Montez en charge tous les services ou le service de messagerie.

L'utilisation du CPU du service de messagerie est élevée.

Lorsque l'événement est détecté : « L'utilisation du CPU du service de messagerie est supérieure à la valeur de seuil élevée de {system_usage_threshold} %.  »

Lorsque l'événement est résolu : « L'utilisation du CPU du service de messagerie est inférieure à la valeur de seuil élevée de {system_usage_threshold} %.  »

Montez en charge tous les services ou le service de messagerie.

L'utilisation du CPU du service de base de données de configuration est très élevée.

Lorsque l'événement est détecté : « L'utilisation du CPU du service de base de données de configuration est supérieure à la valeur de seuil très élevée de {system_usage_threshold} %.  »

Lorsque l'événement est résolu : « L'utilisation du CPU du service de base de données de configuration est inférieure à la valeur de seuil très élevée de {system_usage_threshold} %.  »

Montez en charge tous les services.

L'utilisation du CPU du service de base de données de configuration est élevée.

Lorsque l'événement est détecté : « L'utilisation du CPU du service de base de données de configuration est supérieure à la valeur de seuil élevée de {system_usage_threshold} %.  »

Lorsque l'événement est résolu : « L'utilisation du CPU du service de base de données de configuration est inférieure à la valeur de seuil élevée de {system_usage_threshold} %.  »

Montez en charge tous les services.

L'utilisation du CPU du service de mesures est très élevée.

Lorsque l'événement est détecté : « L'utilisation du CPU du service de mesures est supérieure à la valeur de seuil très élevée de {system_usage_threshold} %.  »

Lorsque l'événement est résolu : « L'utilisation du CPU du service de mesures est inférieure à la valeur de seuil très élevée de {system_usage_threshold} %.  »

Montez en charge tous les services.

L'utilisation du CPU du service de mesures est élevée.

Lorsque l'événement est détecté : « L'utilisation du CPU du service de mesures est supérieure à la valeur de seuil élevée de {system_usage_threshold} %.  »

Lorsque l'événement est résolu : « L'utilisation du CPU du service de mesures est inférieure à la valeur de seuil élevée de {system_usage_threshold} %.  »

Montez en charge tous les services.

L'utilisation du CPU du service d'analyse est très élevée.

Lorsque l'événement est détecté : « L'utilisation du CPU du service d'analyse est supérieure à la valeur de seuil très élevée de {system_usage_threshold} %.  »

Lorsque l'événement est résolu : « L'utilisation du CPU du service d'analyse est inférieure à la valeur de seuil très élevée de {system_usage_threshold} %.  »

Montez en charge tous les services ou le service d'analyse.

L'utilisation du CPU du service d'analyse est élevée.

Lorsque l'événement est détecté : « L'utilisation du CPU du service d'analyse est supérieure à la valeur de seuil élevée de {system_usage_threshold} %.  »

Lorsque l'événement est résolu : « L'utilisation du CPU du service d'analyse est inférieure à la valeur de seuil élevée de {system_usage_threshold} %.  »

Montez en charge tous les services ou le service d'analyse.

L'utilisation du CPU du service des services de plate-forme est très élevée.

Lorsque l'événement est détecté : « L'utilisation du CPU du service des services de plate-forme est supérieure à la valeur de seuil très élevée de {system_usage_threshold} %.  »

Lorsque l'événement est résolu : « L'utilisation du CPU du service des services de plate-forme est inférieure à la valeur de seuil très élevée de {system_usage_threshold} %.  »

Montez en charge tous les services.

L'utilisation du CPU du service des services de plate-forme est élevée.

Lorsque l'événement est détecté : « L'utilisation du CPU du service des services de plate-forme est supérieure à la valeur de seuil élevée de {system_usage_threshold} %.  »

Lorsque l'événement est résolu : « L'utilisation du CPU du service des services de plate-forme est inférieure à la valeur de seuil élevée de {system_usage_threshold} %.  »

Montez en charge tous les services.

L'utilisation de la mémoire du service de stockage de données est très élevée.

Lorsque l'événement est détecté : « L'utilisation de la mémoire de stockage de données est supérieure à la valeur de seuil très élevée de {system_usage_threshold} %.  »

Lorsque l'événement est résolu : « L'utilisation de la mémoire de stockage de données est inférieure à la valeur de seuil très élevée de {system_usage_threshold} %.  »

Montez en charge tous les services ou le service de stockage de données.

L'utilisation de la mémoire du service de stockage de données est élevée.

Lorsque l'événement est détecté : « L'utilisation de la mémoire de stockage de données est supérieure à la valeur de seuil élevée de {system_usage_threshold} %.  »

Lorsque l'événement est résolu : « L'utilisation de la mémoire de stockage de données est inférieure à la valeur de seuil élevée de {system_usage_threshold} %.  »

Montez en charge tous les services ou le service de stockage de données.

L'utilisation de la mémoire du service de messagerie est très élevée.

Lorsque l'événement est détecté : « L'utilisation de la mémoire du service de messagerie est supérieure à la valeur de seuil très élevée de {system_usage_threshold} %.  »

Lorsque l'événement est résolu : « L'utilisation de la mémoire du service de messagerie est inférieure à la valeur de seuil très élevée de {system_usage_threshold} %.  »

Montez en charge tous les services ou le service de messagerie.

L'utilisation de la mémoire du service de messagerie est élevée.

Lorsque l'événement est détecté : « L'utilisation de la mémoire du service de messagerie est supérieure à la valeur de seuil élevée de {system_usage_threshold} %.  »

Lorsque l'événement est résolu : « L'utilisation de la mémoire du service de messagerie est inférieure à la valeur de seuil élevée de {system_usage_threshold} %.  »

Montez en charge tous les services ou le service de messagerie.

L'utilisation de la mémoire du service de base de données de configuration est très élevée.

Lorsque l'événement est détecté : « L'utilisation de la mémoire du service de base de données de configuration est supérieure à la valeur de seuil très élevée de {system_usage_threshold} %.  »

Lorsque l'événement est résolu : « L'utilisation de la mémoire du service de base de données de configuration est inférieure à la valeur de seuil très élevée de {system_usage_threshold} %.  »

Montez en charge tous les services.

L'utilisation de la mémoire du service de base de données de configuration est élevée.

Lorsque l'événement est détecté : « L'utilisation de la mémoire du service de base de données de configuration est supérieure à la valeur de seuil élevée de {system_usage_threshold} %.  »

Lorsque l'événement est résolu : « L'utilisation de la mémoire du service de base de données de configuration est inférieure à la valeur de seuil élevée de {system_usage_threshold} %.  »

Montez en charge tous les services.

L'utilisation de la mémoire du service de mesures est très élevée.

Lorsque l'événement est détecté : « L'utilisation de la mémoire du service de mesures est supérieure à la valeur de seuil très élevée de {system_usage_threshold} %.  »

Lorsque l'événement est résolu : « L'utilisation de la mémoire du service de mesures est inférieure à la valeur de seuil très élevée de {system_usage_threshold} %.  »

Montez en charge tous les services.

L'utilisation de la mémoire du service de mesures est élevée.

Lorsque l'événement est détecté : « L'utilisation de la mémoire du service de mesures est supérieure à la valeur de seuil élevée de {system_usage_threshold} %.  »

Lorsque l'événement est résolu : « L'utilisation de la mémoire du service de mesures est inférieure à la valeur de seuil élevée de {system_usage_threshold} %.  »

Montez en charge tous les services.

L'utilisation de la mémoire du service d'analyse est très élevée.

Lorsque l'événement est détecté : « L'utilisation de la mémoire du service d'analyse est supérieure à la valeur de seuil très élevée de {system_usage_threshold} %.  »

Lorsque l'événement est résolu : « L'utilisation de la mémoire du service d'analyse est inférieure à la valeur de seuil très élevée de {system_usage_threshold} %.  »

Montez en charge tous les services ou le service d'analyse.

L'utilisation de la mémoire du service d'analyse est élevée.

Lorsque l'événement est détecté : « L'utilisation de la mémoire du service d'analyse est supérieure à la valeur de seuil élevée de {system_usage_threshold} %.  »

Lorsque l'événement est résolu : « L'utilisation de la mémoire du service d'analyse est inférieure à la valeur de seuil élevée de {system_usage_threshold} %.  »

Montez en charge tous les services ou le service d'analyse.

L'utilisation de la mémoire du service des services de plate-forme est très élevée.

Lorsque l'événement est détecté : « L'utilisation de la mémoire du service des services de plate-forme est supérieure à la valeur de seuil très élevée de {system_usage_threshold} %.  »

Lorsque l'événement est résolu : « L'utilisation de la mémoire du service des services de plate-forme est inférieure à la valeur de seuil très élevée de {system_usage_threshold} %.  »

Montez en charge tous les services.

L'utilisation de la mémoire du service des services de plate-forme est élevée.

Lorsque l'événement est détecté : « L'utilisation de la mémoire du service des services de plate-forme est supérieure à la valeur de seuil élevée de {system_usage_threshold} %.  »

Lorsque l'événement est résolu : « L'utilisation de la mémoire du service des services de plate-forme est inférieure à la valeur de seuil élevée de {system_usage_threshold} %.  »

Montez en charge tous les services.

L'utilisation du disque du service de stockage de données est très élevée.

Lorsque l'événement est détecté : « L'utilisation du disque de stockage de données est supérieure à la valeur de seuil très élevée de {system_usage_threshold} %.  »

Lorsque l'événement est résolu : « L'utilisation du disque de stockage de données est inférieure à la valeur de seuil très élevée de {system_usage_threshold} %.  »

Montez en charge ou en puissance le service de stockage de données.

L'utilisation du disque du service de stockage de données est élevée.

Lorsque l'événement est détecté : « L'utilisation du disque de stockage de données est supérieure à la valeur de seuil élevée de {system_usage_threshold} %.  »

Lorsque l'événement est résolu : « L'utilisation du disque de stockage de données est inférieure à la valeur de seuil élevée de {system_usage_threshold} %.  »

Montez en charge ou en puissance le service de stockage de données.

L'utilisation du disque du service de messagerie est très élevée.

Lorsque l'événement est détecté : « L'utilisation du disque du service de messagerie est supérieure à la valeur de seuil très élevée de {system_usage_threshold} %.  »

Lorsque l'événement est résolu : « L'utilisation du disque du service de messagerie est inférieure à la valeur de seuil très élevée de {system_usage_threshold} %.  »

Le nettoyage des fichiers n'est pas requis. Montez en charge tous les services ou le service de messagerie.

L'utilisation du disque du service de messagerie est élevée.

Lorsque l'événement est détecté : « L'utilisation du disque du service de messagerie est supérieure à la valeur de seuil élevée de {system_usage_threshold} %.  »

Lorsque l'événement est résolu : « L'utilisation du disque du service de messagerie est inférieure à la valeur de seuil élevée de {system_usage_threshold} %.  »

Le nettoyage des fichiers n'est pas requis. Montez en charge tous les services ou le service de messagerie.

L'utilisation du disque du service de base de données de configuration est très élevée.

Lorsque l'événement est détecté : « L'utilisation du disque du service de base de données de configuration est supérieure à la valeur de seuil très élevée de {system_usage_threshold} %.  »

Lorsque l'événement est résolu : « L'utilisation du disque du service de base de données de configuration est inférieure à la valeur de seuil très élevée de {system_usage_threshold} %.  »

Le nettoyage des fichiers n'est pas requis. Montez en charge tous les services.

L'utilisation du disque du service de base de données de configuration est élevée.

Lorsque l'événement est détecté : « L'utilisation du disque du service de base de données de configuration est supérieure à la valeur de seuil élevée de {system_usage_threshold} %.  »

Lorsque l'événement est résolu : « L'utilisation du disque du service de base de données de configuration est inférieure à la valeur de seuil élevée de {system_usage_threshold} %.  »

Le nettoyage des fichiers n'est pas requis. Montez en charge tous les services.

L'utilisation du disque du service de mesures est très élevée.

Lorsque l'événement est détecté : « L'utilisation du disque du service de mesures est supérieure à la valeur de seuil très élevée de {system_usage_threshold} %.  »

Lorsque l'événement est résolu : « L'utilisation du disque du service de mesures est inférieure à la valeur de seuil très élevée de {system_usage_threshold} %.  »

Le nettoyage des fichiers n'est pas requis. Montez en charge tous les services.

L'utilisation du disque du service de mesures est élevée.

Lorsque l'événement est détecté : « L'utilisation du disque du service de mesures est supérieure à la valeur de seuil élevée de {system_usage_threshold} %.  »

Lorsque l'événement est résolu : « L'utilisation du disque du service de mesures est inférieure à la valeur de seuil élevée de {system_usage_threshold} %.  »

Le nettoyage des fichiers n'est pas requis. Montez en charge tous les services.

L'utilisation du disque du service d'analyse est très élevée.

Lorsque l'événement est détecté : « L'utilisation du disque du service d'analyse est supérieure à la valeur de seuil très élevée de {system_usage_threshold} %.  »

Lorsque l'événement est résolu : « L'utilisation du disque du service d'analyse est inférieure à la valeur de seuil très élevée de {system_usage_threshold} %.  »

Le nettoyage des fichiers n'est pas requis. Montez en charge tous les services ou le service d'analyse.

L'utilisation du disque du service d'analyse est élevée.

Lorsque l'événement est détecté : « L'utilisation du disque du service d'analyse est supérieure à la valeur de seuil élevée de {system_usage_threshold} %.  »

Lorsque l'événement est résolu : « L'utilisation du disque du service d'analyse est inférieure à la valeur de seuil élevée de {system_usage_threshold} %.  »

Le nettoyage des fichiers n'est pas requis. Montez en charge tous les services ou le service d'analyse.

L'utilisation du disque du service des services de plate-forme est très élevée.

Lorsque l'événement est détecté : « L'utilisation du disque du service des services de plate-forme est supérieure à la valeur de seuil très élevée de {system_usage_threshold} %.  »

Lorsque l'événement est résolu : « L'utilisation du disque du service des services de plate-forme est inférieure à la valeur de seuil très élevée de {system_usage_threshold} %.  »

Le nettoyage des fichiers n'est pas requis. Montez en charge tous les services.

L'utilisation du disque du service des services de plate-forme est élevée.

Lorsque l'événement est détecté : « L'utilisation du disque du service des services de plate-forme est supérieure à la valeur de seuil élevée de {system_usage_threshold} %.  »

Lorsque l'événement est résolu : « L'utilisation du disque du service des services de plate-forme est inférieure à la valeur de seuil élevée de {system_usage_threshold} %.  »

Le nettoyage des fichiers n'est pas requis. Montez en charge tous les services.

L'état du service est dégradé.

Lorsque l'événement est détecté : Le service {napp_service_name} est dégradé. Le service peut toujours atteindre un quorum alors que les espaces associés à {napp_service_name} ne sont pas tous stables. Les ressources consommées par ces espaces instables peuvent être libérées.  »

Lorsque l'événement est résolu : « Le service {napp_service_name} s'exécute correctement.  »

Dans l'interface utilisateur NSX, accédez à Système | NSX Application Platform | Services de base pour vérifier quel service est dégradé. Appelez la NSX API GET /napp/api/v1/platform/monitor/feature/health pour vérifier quel service spécifique est dégradé et la raison. Appelez la commande d'interface de ligne de commande suivante pour redémarrer le service dégradé si nécessaire : kubectl rollout restart &ltstatefulset/deployment&gt &ltservice_name&gt -n &ltnamespace&gt. Les services dégradés peuvent fonctionner correctement, mais les performances ne sont pas optimales.

L'état du service est inactif.

Lorsque l'événement est détecté : « Le service {napp_service_name} n'est pas en cours d'exécution.  »

Lorsque l'événement est résolu : « Le service {napp_service_name} s'exécute correctement.  »

Dans l'interface utilisateur NSX, accédez à Système | NSX Application Platform | Services de base pour vérifier quel service est dégradé. Appelez la NSX API GET /napp/api/v1/platform/monitor/feature/health pour vérifier quel service spécifique est inactif et la raison. Appelez la commande d'interface de ligne de commande suivante pour redémarrer le service dégradé : kubectl rollout restart &ltstatefulset/deployment&gt &ltservice_name&gt -n &ltnamespace&gt

Service dégradé.

Lorsque l'événement est détecté : « Le service {nsxaas_service_name} est dégradé. Dans son état actuel, le service peut fonctionner avec une efficacité réduite, ce qui peut avoir un impact sur les charges de travail des clients. {service_down_reason} »

Lorsque l'élément est résolu : « Le service {nsxaas_service_name} n'est plus dans un état dégradé.  »

Vérifiez les données incluses dans la description de l'alarme en identifiant le service, l'emplacement de déploiement du service et les données supplémentaires capturées par le service de surveillance de la santé. Vérifiez également les données historiques enregistrées par le service Mesures ou Wavefront, le cas échéant.

Service inactif.

Lorsque l'événement est détecté : « Le service {nsxaas_service_name} est inactif. {service_down_reason} »

Lorsque l'élément est résolu : « Le service {nsxaas_service_name} est de nouveau disponible.  »

Vérifiez les données incluses dans la description de l'alarme en identifiant le service, l'emplacement de déploiement du service et les données supplémentaires capturées par le service de surveillance de la santé. Vérifiez également les données historiques enregistrées par le service Mesures ou Wavefront, le cas échéant.

Le mot de passe utilisateur a expiré.

Lorsque l'événement est détecté : « Le mot de passe de l'utilisateur {username} a expiré.  »

Lorsque l'événement est résolu : « Le mot de passe de l'utilisateur {username} a été modifié correctement, n'est plus expiré ou l'utilisateur n'est plus actif.  »

Le mot de passe de l'utilisateur {username} doit maintenant être modifié pour accéder au système. Par exemple, pour appliquer un nouveau mot de passe à un utilisateur, appelez la NSX API suivante avec un mot de passe valide dans le corps de la demande : PUT /api/v1/node/users/&ltuserid&gt où &ltuserid&gt est l'ID de l'utilisateur. Si le mot de passe de l'utilisateur Admin (avec &ltuserid&gt 10 000) a expiré, l'admin doit se connecter au système via SSH (si activé) ou à la console pour modifier le mot de passe. En entrant le mot de passe actuel expiré, l'admin est invité à entrer un nouveau mot de passe.

Le mot de passe utilisateur est sur le point d'expirer.

Lorsque l'événement est détecté : « Le mot de passe de l'utilisateur {username} est sur le point d'expirer dans {password_expiration_days} jours.  »

Lorsque l'événement est résolu : « Le mot de passe de l'utilisateur {username} a été modifié correctement, n'est plus expiré ou l'utilisateur n'est plus actif.  »

Assurez-vous que le mot de passe de l'utilisateur {username} est modifié immédiatement. Par exemple, pour appliquer un nouveau mot de passe à un utilisateur, appelez la NSX API suivante avec un mot de passe valide dans le corps de la demande : PUT /api/v1/node/users/&ltuserid&gt où &ltuserid&gt est l'ID de l'utilisateur.

Le mot de passe de l'utilisateur arrive à expiration.

Lorsque l'événement est détecté : « Le mot de passe de l'utilisateur {username} arrive à expiration dans {password_expiration_days} jours.  »

Lorsque l'événement est résolu : « Le mot de passe de l'utilisateur {username} a été modifié correctement, n'est plus expiré ou l'utilisateur n'est plus actif.  »

Le mot de passe de l'utilisateur {username} doit bientôt être modifié. Par exemple, pour appliquer un nouveau mot de passe à un utilisateur, appelez la NSX API suivante avec un mot de passe valide dans le corps de la demande : PUT /api/v1/node/users/&ltuserid&gt où &ltuserid&gt est l'ID de l'utilisateur.

Échec de l'installation du serveur physique (BMS).

Lorsque l'événement est détecté : « L'installation du serveur physique {transport_node_name} ({entity_id}) a échoué.  »

Lorsque l'événement est résolu : « Installation du serveur physique {transport_node_name} ({entity_id}) terminée.  »

Accédez à Système > Infrastructure > Nœuds > Nœuds de transport hôtes et résolvez l'erreur sur le nœud.

Échec de la mise à niveau du serveur physique (BMS).

Lorsque l'événement est détecté : « La mise à niveau du serveur physique {transport_node_name} ({entity_id}) a échoué.  »

Lorsque l'événement est résolu : « Mise à niveau du serveur physique {transport_node_name} ({entity_id}) terminée.  »

Accédez à Système > Mettre à niveau et résolvez l'erreur, puis redémarrez la mise à niveau.

Échec de la désinstallation du serveur physique (BMS).

Lorsque l'événement est détecté : « La désinstallation du serveur physique {transport_node_name} ({entity_id}) a échoué.  »

Lorsque l'événement est résolu : « Désinstallation du serveur physique {transport_node_name} ({entity_id}) terminée.  »

Accédez à Système > Infrastructure > Nœuds > Nœuds de transport hôtes et résolvez l'erreur sur le nœud.

Le nombre d'entités a atteint la limite de contrainte de la stratégie.

Lorsque l'événement est détecté : « Le nombre d'entités pour le type {constraint_type} dans {constraint_type_path} est actuellement à {current_count} qui a atteint la limite maximale de {constraint_limit}.  »

Lorsque l'événement est résolu : « Le nombre {constraint_type} est inférieur au seuil.  »

Vérifiez l'utilisation de {constraint_type}. Mettez à jour la contrainte pour augmenter la limite ou supprimer les {constraint_type} inutilisés.

La session BFD est inactive.

Lorsque l'événement est détecté : « Dans le routeur {lr_id}, la session BFD pour l'homologue {peer_address} est inactive.  »

Lorsque l'événement est résolu : « Dans le routeur {lr_id}, la session BFD pour l'homologue {peer_address} est active.  »

1. Appelez la commande de l'interface de ligne de commande NSX get logical-routers.
2. Basculez vers le routeur de service {sr_id}
3. Appelez la commande de l'interface de ligne de commande NSX ping {peer_address} pour vérifier la connectivité.

Itinéraire statique supprimé.

Lorsque l'événement est détecté : « Dans le routeur {lr_id}, la route statique {entity_id} ({static_address}) a été supprimée, car BFD était inactif.  »

Lorsque l'événement est résolu : « Dans le routeur {lr_id}, la route statique {entity_id} ({static_address}) a été rajoutée en tant que BFD récupéré.  »

L'entrée de routage statique a été supprimée, car la session BFD était inactive.
1. Appelez la commande de l'interface de ligne de commande NSX get logical-routers.
2. Basculez vers le routeur de service {sr_id}.
3. Appelez la commande CLI NSX ping &ltBFD peer IP address&gt pour vérifier la connectivité. Vérifiez également la configuration dans NSX et l'homologue BFD pour vous assurer que les temporisateurs n'ont pas été modifiés.

Le voisin BGP est inactif.

Lorsque l'événement est détecté : « Dans le routeur {lr_id}, le voisin BGP {entity_id} ({bgp_neighbor_ip}) est inactif. Motif : {failure_reason}.  »

Lorsque l'événement est résolu : « Dans le routeur {lr_id}, le voisin BGP {entity_id} ({bgp_neighbor_ip}) est actif.  »

1. Appelez la commande de l'interface de ligne de commande NSX get logical-routers.
2. Basculez vers le routeur de service {sr_id}. Si la raison indique une erreur de réseau ou de configuration -
3. Appelez la commande d'interface de ligne de commande NSX get bgp neighbor summary pour vérifier l'état du voisin BGP. Si la raison indique Edge n'est pas prêt, vérifiez pourquoi le nœud Edge n'est pas dans un état correct.
4. Appelez la commande de l'interface de ligne de commande NSX get edge-cluster status pour vérifier la raison pour laquelle le nœud Edge est inactif.
5. Appelez les commandes CLI NSX get bfd-config et get bfd-sessions pour vérifier si BFD fonctionne correctement.
6. Vérifiez les alarmes liées à la santé du dispositif Edge pour obtenir plus d'informations. Vérifiez /var/log/syslog pour voir s'il existe des erreurs liées à la connectivité de BGP.

L'ARP du proxy n'est pas configuré pour l'adresse IP du service.

Lorsque l'événement est détecté : L'ARP du proxy pour l'adresse IP {service_ip} et l'entité de service {entity_id} n'est pas configuré, car le nombre d'entrées de proxy ARP générées en raison du chevauchement de l'adresse IP de service avec le sous-réseau de lrport {lrport_id} sur le routeur {lr_id} a dépassé la limite de seuil autorisée de 16 384.  »

Lorsque l'événement est résolu : « L'ARP du proxy pour l'entité de service {entity_id} est généré correctement, car le chevauchement de l'adresse IP du service avec le sous-réseau de lrport {lrport_id} sur le routeur {lr_id} se trouve dans la limite autorisée de 16 384 entrées.  »

Reconfigurez l'adresse IP de service {service_ip} pour l'entité de service {entity_id} ou modifiez le sous-réseau de lrport {lrport_id} sur le routeur {lr_id} afin que les entrées ARP du proxy générées en raison du chevauchement entre l'adresse IP de service et le sous-réseau du port lrport soient inférieures à la limite de seuil autorisée de 16 384.

Toutes les sessions BGP/BFD sont inactives.

Lorsque l'événement est détecté : « Toutes les sessions BGP/BFD sont inactives.  »

Lorsque l'événement est résolu : « Au moins une session BGP/BFD est activée.  »

Appelez la commande CLI NSX get les routeurs logiques pour obtenir le routeur de service de niveau 0 et passer à ce VRF, puis appelez les commandes CLI NSX suivantes.
1. ping &ltBFD peer IP address&gt pour vérifier la connectivité.
2. get bfd-config et get bfd-sessions pour vérifier si BFD fonctionne correctement.
3. get bgp neighbor summary pour vérifier si BGP fonctionne correctement. Vérifiez également /var/log/syslog pour voir s'il existe des erreurs liées à la connectivité de BGP.

Le voisin OSPF est passé de Complet à un autre état.

Lorsque l'événement est détecté : « Le voisin OSPF {peer_address} est passé de Complet à un autre état.  »

Lorsque l'événement est résolu : « Le voisin OSPF {peer_address} est passé à l'état Complet.  »

1. Appelez la commande CLI NSX get logical-routers pour obtenir l'ID de VRF et basculer vers le routeur de service de niveau 0.
2. Exécutez get ospf neighbor pour vérifier l'état actuel de ce voisin. Si le voisin n'est pas répertorié dans la sortie, il est devenu hors service ou n'est plus dans le réseau.
3. Appelez la commande CLI NSX ping &ltOSPF neighbor IP address&gt pour vérifier la connectivité.
4. Vérifiez également la configuration du routeur NSX et du routeur homologue pour vous assurer que les temporisateurs et l'ID de zone correspondent.
5. Vérifiez /var/log/syslog pour voir s'il existe des erreurs liées à la connectivité.

La limite maximale de routes IPv4 approche sur le nœud Edge.

Lorsque l'événement est détecté : « La limite des routes IPv4 a atteint {route_limit_threshold} sur la passerelle de niveau 0 et tous les VRF de niveau 0 sur le nœud Edge {edge_node}.  »

Lorsque l'événement est résolu : « Les routes IPv4 se trouvent dans la limite de {route_limit_threshold} sur la passerelle de niveau 0 et de tous les VRF de niveau 0 sur le nœud Edge {edge_node}.  »

1. Vérifiez les stratégies de redistribution des routes et les routes reçues de tous les homologues externes.
2. Envisagez de réduire le nombre de routes en appliquant des stratégies de routage et des filtres en conséquence.

La limite maximale de routes IPv6 approche sur le nœud Edge.

Lorsque l'événement est détecté : « La limite des routes IPv6 a atteint {route_limit_threshold} sur la passerelle de niveau 0 et tous les VRF de niveau 0 sur le nœud Edge {edge_node}.  »

Lorsque l'événement est résolu : « Les routes IPv6 se trouvent dans la limite de {route_limit_threshold} sur la passerelle de niveau 0 et de tous les VRF de niveau 0 sur le nœud Edge {edge_node}.  »

1. Vérifiez les stratégies de redistribution des routes et les routes reçues de tous les homologues externes.
2. Envisagez de réduire le nombre de routes en appliquant des stratégies de routage et des filtres en conséquence.

La limite maximale de routes IPv4 a été dépassée sur le nœud Edge.

Lorsque l'événement est détecté : « Les routes IPv4 ont dépassé la limite de {route_limit_maximum} sur la passerelle de niveau 0 et tous les VRF de niveau 0 sur le nœud Edge {edge_node}.  »

Lorsque l'événement est résolu : « Les routes IPv4 se trouvent dans la limite de {route_limit_maximum} sur la passerelle de niveau 0 et de tous les VRF de niveau 0 sur le nœud Edge {edge_node}.  »

1. Vérifiez les stratégies de redistribution des routes et les routes reçues de tous les homologues externes.
2. Envisagez de réduire le nombre de routes en appliquant des stratégies de routage et des filtres en conséquence.

La limite maximale de routes IPv6 a été dépassée sur le nœud Edge.

Lorsque l'événement est détecté : « Les routes IPv6 ont dépassé la limite de {route_limit_maximum} sur la passerelle de niveau 0 et tous les VRF de niveau 0 sur le nœud Edge {edge_node}.  »

Lorsque l'événement est résolu : « Les routes IPv6 se trouvent dans la limite de {route_limit_maximum} sur la passerelle de niveau 0 et de tous les VRF de niveau 0 sur le nœud Edge {edge_node}.  »

1. Vérifiez les stratégies de redistribution des routes et les routes reçues de tous les homologues externes.
2. Envisagez de réduire le nombre de routes en appliquant des stratégies de routage et des filtres en conséquence.

Le nombre maximal de préfixes IPv4 reçus du voisin BGP approche.

Lorsque l'événement est détecté : « Le nombre de préfixes IPv4 {subsequent_address_family} reçus de {bgp_neighbor_ip} atteint {prefixes_count_threshold}. La limite définie pour cet homologue est {prefixes_count_max}.  »

Lorsque l'événement est résolu : « Le nombre de préfixes IPv4 {subsequent_address_family} reçus de {bgp_neighbor_ip} est compris dans la limite {prefixes_count_threshold}.  »

1. Vérifiez les stratégies de routage BGP dans le routeur externe.
2. Envisagez de réduire le nombre de routes annoncées par l'homologue BGP en appliquant des stratégies de routage et des filtres au routeur externe.
3. Si nécessaire, augmentez le nombre maximal de paramètres de préfixes sous la section de configuration du voisin BGP.

Le nombre maximal de préfixes IPv6 reçus du voisin BGP approche.

Lorsque l'événement est détecté : Le nombre de préfixes IPv6 {subsequent_address_family} reçus de {bgp_neighbor_ip} atteint {prefixes_count_threshold}. La limite définie pour cet homologue est {prefixes_count_max}.  »

Lorsque l'événement est résolu : « Le nombre de préfixes IPv6 {subsequent_address_family} reçus de {bgp_neighbor_ip} est compris dans la limite {prefixes_count_threshold}.  »

1. Vérifiez les stratégies de routage BGP dans le routeur externe.
2. Envisagez de réduire le nombre de routes annoncées par l'homologue BGP en appliquant des stratégies de routage et des filtres au routeur externe.
3. Si nécessaire, augmentez le nombre maximal de paramètres de préfixes sous la section de configuration du voisin BGP.

Le nombre maximal de préfixes IPv4 reçus du voisin BGP a été dépassé.

Lorsque l'événement est détecté : « Le nombre de préfixes IPv4 {subsequent_address_family} reçus de {bgp_neighbor_ip} a dépassé la limite définie pour cet homologue de {prefixes_count_max}.  »

Lorsque l'événement est résolu : « Le nombre de préfixes IPv4 {subsequent_address_family} reçus de {bgp_neighbor_ip} est compris dans la limite {prefixes_count_max}.  »

1. Vérifiez les stratégies de routage BGP dans le routeur externe.
2. Envisagez de réduire le nombre de routes annoncées par l'homologue BGP en appliquant des stratégies de routage et des filtres au routeur externe.
3. Si nécessaire, augmentez le nombre maximal de paramètres de préfixes sous la section de configuration du voisin BGP.

Le nombre maximal de préfixes IPv6 reçus du voisin BGP a été dépassé.

Lorsque l'événement est détecté : « Le nombre de préfixes IPv6 {subsequent_address_family} reçus de {bgp_neighbor_ip} a dépassé la limite définie pour cet homologue de {prefixes_count_max}.  »

Lorsque l'événement est résolu : « Le nombre de préfixes IPv6 {subsequent_address_family} reçus de {bgp_neighbor_ip} est compris dans la limite {prefixes_count_max}.  »

1. Vérifiez les stratégies de routage BGP dans le routeur externe.
2. Envisagez de réduire le nombre de routes annoncées par l'homologue BGP en appliquant des stratégies de routage et des filtres au routeur externe.
3. Si nécessaire, augmentez le nombre maximal de paramètres de préfixes sous la section de configuration du voisin BGP.

L'état de la sécurité NSX n'est pas conforme à NDcPP.

Lorsque l'événement est détecté : « L'une des exigences de conformité NDcPP est enfreinte. Cela signifie que l'état NSX est actuellement non conforme à NDcPP.  »

Lorsque l'événement est résolu : « Les problèmes de conformité à NDcPP ont tous été résolus.  »

Exécutez le rapport de conformité depuis le menu Accueil - Surveillance et tableau de bord - Rapport de conformité de l'interface utilisateur et résolvez tous les problèmes marqués du nom de conformité NDcPP.

L'état de la sécurité NSX n'est pas conforme à EAL4+.

Lorsque l'événement est détecté : « L'une des exigences de conformité EAL4+ est enfreinte. Cela signifie que l'état de NSX est actuellement non conforme en ce qui concerne EAL4+.  »

Lorsque l'événement est résolu : « Les problèmes de conformité à EAL4+ ont tous été résolus.  »

Exécutez le rapport de conformité depuis le menu Accueil - Surveillance et tableau de bord - Rapport de conformité de l'interface utilisateur et résolvez tous les problèmes marqués du nom de conformité EAL4+.

La configuration de la sécurité NSX n'est pas conforme à NDcPP.

Lorsque l'événement est détecté : « L'une des exigences de conformité NDcPP est enfreinte. Cela signifie que la configuration NSX n'est actuellement pas conforme à NDcPP.  »

Lorsque l'événement est résolu : « Les problèmes de conformité à NDcPP ont tous été résolus.  »

Exécutez le rapport de conformité depuis le menu Accueil - Surveillance et tableau de bord - Rapport de conformité de l'interface utilisateur et résolvez tous les problèmes marqués du nom de conformité NDcPP.

La configuration de la sécurité NSX n'est pas conforme à EAL4+.

Lorsque l'événement est détecté : « L'une des exigences de conformité EAL4+ est enfreinte. Cela signifie que la configuration NSX n'est actuellement pas conforme à EAL4+.  »

Lorsque l'événement est résolu : « Les problèmes de conformité à EAL4+ ont tous été résolus.  »

Exécutez le rapport de conformité depuis le menu Accueil - Surveillance et tableau de bord - Rapport de conformité de l'interface utilisateur et résolvez tous les problèmes marqués du nom de conformité EAL4+.

Le déploiement du service a réussi.

Lorsque l'événement est détecté : « Le déploiement du service {entity_id} pour le service {service_name} sur le cluster {vcenter_cluster_id} a réussi.  »

Lorsque l'événement est résolu : « Le déploiement du service {entity_id} sur le cluster {vcenter_cluster_id} a réussi. Aucune action n'est nécessaire.  »

Aucune action n'est nécessaire.

Échec du déploiement du service.

Lorsque l'événement est détecté : « Le déploiement du service {entity_id} pour le service {service_name} sur le cluster {vcenter_cluster_id} a échoué. Motif : {Failure_reason} « 

Lorsque l'élément est résolu : « Le déploiement de service ayant échoué {entity_id} a été supprimé.  »

Supprimez le déploiement de service à l'aide de l'interface utilisateur ou de l'API. Effectuez une action corrective à partir de l'article de la base de connaissances et recommencez le déploiement du service.

Suppression du déploiement du service réussie.

Lorsque l'événement est détecté : « La suppression du service {entity_id} pour le service {service_name} sur le cluster {vcenter_cluster_id} a réussi.  »

Lorsque l'événement est résolu : « La suppression du service {entity_id} sur le cluster {vcenter_cluster_id} a réussi. Aucune action n'est nécessaire.  »

Aucune action n'est nécessaire.

Échec de la suppression du déploiement de service.

Lorsque l'événement est détecté : « La suppression du déploiement de service {entity_id} pour le service {service_name} sur le cluster {vcenter_cluster_id} a échoué. Motif : {Failure_reason} « 

Lorsque l'élément est résolu : « Le nom du déploiement de service ayant échoué {entity_id} a été supprimé.  »

Supprimez le déploiement de service à l'aide de l'interface utilisateur ou de l'API. Effectuez une action corrective à partir de l'article de la base de connaissances et recommencez le déploiement de la suppression du service. Résolvez l'alarme manuellement après avoir vérifié que toutes les machines virtuelles et tous les objets sont supprimés.

SVM fonctionne dans le service.

Lorsque l'événement est détecté : « Le contrôle de santé de la SVM {entity_id} pour le service {service_name} fonctionne correctement sur {hostname_or_ip_address_with_port}.  »

Lorsque l'événement est résolu : « La SVM {entity_id} fonctionne correctement. Aucune action n'est nécessaire.  »

Aucune action n'est nécessaire.

SVM ne fonctionne pas dans le service.

Lorsque l'événement est détecté : « Le contrôle de santé de la SVM {entity_id} pour le service {service_name} ne fonctionne pas correctement sur {hostname_or_ip_address_with_port}. Motif : {failure_reason}.  »

Lorsque l'événement est résolu : « La SVM {entity_id} avec un état incorrect a été supprimée.  »

Supprimez le déploiement de service à l'aide de l'interface utilisateur ou de l'API. Effectuez une action corrective à partir de l'article de la base de connaissances et recommencez le déploiement du service si nécessaire.

L'état de l'infrastructure d'insertion de services est inactif et non activé sur l'hôte.

Lorsque l'événement est détecté : « SPF non activé au niveau du port sur l'hôte {transport_node_id} et l'état est inactif. Motif : {failure_reason}.  »

Lorsque l'événement est résolu : « L'état de l'infrastructure de l'insertion de services est actif et a été activé sur l'hôte.  »

Effectuez une action corrective à partir de l'article de la base de connaissances et vérifiez si l'état est actif. Résolvez l'alarme manuellement après avoir vérifié l'état.

État de réactivité de SVM inactif.

Lorsque l'événement est détecté : « L'état de réactivité de la SVM est inactif sur {entity_id} et le flux de trafic est affecté.  »

Lorsque l'événement est résolu : « L'état de réactivité de SVM est actif et configuré comme prévu.  »

Effectuez une action corrective à partir de l'article de la base de connaissances et vérifiez si l'état est actif.

Chemin d'accès à la chaîne de services inactif.

Lorsque l'événement est détecté : « Le chemin de la chaîne de services est inactif sur {entity_id} et le flux de trafic est affecté.  »

Lorsque l'événement est résolu : « Le chemin d'accès à la chaîne de services est actif et configuré comme prévu.  »

Effectuez une action corrective à partir de l'article de la base de connaissances et vérifiez si l'état est actif.

Nouvel hôte ajouté dans le cluster.

Lorsque l'événement est détecté : « Le nouvel hôte ajouté dans le cluster {vcenter_cluster_id} et SVM seront déployés.  »

Lorsque l'événement est résolu : « Nouvel hôte ajouté.  »

Vérifiez l'état de déploiement de la machine virtuelle et attendez qu'elle se mette sous tension.

TEP est défectueux.

Lorsque l'événement est détecté : « TEP: {vtep_name} de VDS : {dvs_name} dans nœud de transport : {transport_node_id}. Les charges de travail de superposition utilisant ce TEP seront confrontées à une panne du réseau. Motif : {vtep_fault_reason}.  »

Lorsque l'événement est résolu : « TEP : {vtep_name} de VDS : {dvs_name} dans nœud de transport : {transport_node_id} est sain.  »

1. Vérifiez si le TEP dispose d'une adresse IP valide ou d'autres problèmes de connectivité de sous-couche.
2. Activez TEP HA pour basculer les charges de travail vers d'autres TEP sains.

La haute disponibilité de TEP est activée.

Lorsque l'événement est détecté : « HA de TEP activée : {vtep_name} de VDS : {dvs_name} dans nœud de transport : {transport_node_id}.  »

Lorsque l'événement est résolu : « HA de TEP effacée : {vtep_name} de VDS : {dvs_name} dans nœud de transport : {transport_node_id}.  »

Activez la récupération automatique ou appelez la récupération manuelle pour le TEP : {vtep_name} sur le VDS : {dvs_name} dans le nœud de transport :{transport_node_id}.

La récupération automatique a réussi.

Lorsque l'événement est détecté : « Récupération automatique du TEP : {vtep_name} de VDS : {dvs_name} dans le nœud de transport : {transport_node_id} réussie.  »

Lorsque l'événement est résolu : « Récupération automatique du TEP : {vtep_name} de VDS : {dvs_name} dans nœud de transport : {transport_node_id} effacée.  »

aucune.

Échec de la récupération automatique.

Lorsque l'événement est détecté : « Échec de la récupération automatique pour le TEP : {vtep_name} de VDS : {dvs_name} sur le nœud de transport : {transport_node_id}. Les charges de travail de superposition utilisant ce TEP basculeront vers d'autres TEP sains. S'il n'y a pas d'autres TEP sains, les charges de travail de superposition seront confrontées à une panne du réseau.  »

Lorsque l'événement est résolu : « Récupération automatique du TEP : {vtep_name} de VDS : {dvs_name} dans nœud de transport : {transport_node_id} effacée.  »

Vérifiez si le TEP dispose d'une adresse IP valide ou d'autres problèmes de connectivité de sous-couche.

TEP est défectueux sur le DPU.

Lorsque l'événement est détecté : « TEP : {vtep_name} de VDS : {dvs_name} sur le nœud de transport : {transport_node_id} sur DPU : {dpu_id}. Les charges de travail de superposition utilisant ce TEP seront confrontées à une panne du réseau. Motif : {vtep_fault_reason}.  »

Lorsque l'événement est résolu : « TEP : {vtep_name} sur VDS : {dvs_name} sur le nœud de transport : {transport_node_id} sur DPU {dpu_id} est sain.  »

1. Vérifiez si le TEP dispose d'une adresse IP valide ou d'autres problèmes de connectivité de sous-couche.
2. Activez TEP HA pour basculer les charges de travail vers d'autres TEP sains.

La haute disponibilité de TEP est activée sur le DPU.

Lorsque l'événement est détecté : « TEP HA activé pour TEP : {vtep_name} de VDS : {dvs_name} sur le nœud de transport : {transport_node_id} sur DPU {dpu_id}.  »

Lorsque l'événement est résolu : « La haute disponibilité de TEP a été effacée pour TEP : {vtep_name} de VDS : {dvs_name} sur le nœud de transport : {transport_node_id} sur DPU {dpu_id}.  »

Activez la récupération automatique ou appelez la récupération manuelle pour le TEP : {vtep_name} sur le VDS : {dvs_name} dans le nœud de transport : {transport_node_id} sur DPU {dpu_id}.

La récupération automatique a réussi sur le DPU.

Lorsque l'événement est détecté : « Récupération automatique pour TEP : {vtep_name} de VDS : {dvs_name} dans le nœud de transport : {transport_node_id} sur DPU {dpu_id} a réussi.  »

Lorsque l'événement est résolu : « La récupération automatique pour TEP : {vtep_name} de VDS : {dvs_name} dans le nœud de transport : {transport_node_id}. sur le DPU {dpu_id} est effacée.  »

aucune.

Échec de la récupération automatique sur le DPU.

Lorsque l'événement est détecté : « La récupération automatique pour TEP : {vtep_name} de VDS : {dvs_name} sur le nœud de transport : {transport_node_id} sur le DPU {dpu_id} a échoué. Les charges de travail de superposition utilisant ce TEP basculeront vers d'autres TEP sains. S'il n'y a pas d'autres TEP sains, les charges de travail de superposition seront confrontées à une panne du réseau.  »

Lorsque l'événement est résolu : « La récupération automatique pour TEP : {vtep_name} de VDS : {dvs_name} sur le nœud de transport : {transport_node_id} sur DPU {dpu_id} est effacée.  »

Vérifiez si le TEP dispose d'une adresse IP valide ou d'autres problèmes de connectivité de sous-couche.

La liaison montante sur DPU est inactive.

Lorsque l'événement est détecté : « La liaison montante sur DPU {dpu_id} est inactive.  »

Lorsque l'événement est résolu : « La liaison montante sur DPU {dpu_id} est active.  »

Vérifiez l'état des liaisons montantes sur DPU {dpu_id} dans les cartes réseau physiques. Recherchez le nom mappé de cette carte réseau physique sur l'hôte, puis effectuez la vérification sur l'interface utilisateur.
1. Dans l'interface utilisateur de NSX accédez à Infrastructure | Nœuds | Nœuds de transport | Nœuds de transport hôtes.
2. Dans la liste Nœuds de transport hôtes, vérifiez la colonne État du nœud. Recherchez le nœud de transport dont l'état du nœud est dégradé ou inactif.
3. Sélectionnez &lttransport node&gt | Moniteur. Vérifiez les détails de l'état de la liaison (liaison montante) qui est signalée comme dégradée ou inactive. Pour éviter un état dégradé, assurez-vous que toutes les interfaces de liaison montante sont connectées et actives, qu'elles soient utilisées ou non.

LACP sur le membre de rapport DPU inactif.

Lorsque l'événement est détecté : « LACP sur le membre de rapport DPU {dpu_id} inactif.  »

Lorsque l'événement est résolu : « LACP sur le membre de rapport DPU {dpu_id} actif.  »

Vérifiez l'état de la connexion des membres LAG sur DPU {dpu_id}. Recherchez le nom mappé de la carte réseau physique associée sur l'hôte, puis effectuez la vérification sur l'interface utilisateur.
1. Dans l'interface utilisateur de NSX accédez à Infrastructure | Nœuds | Nœuds de transport | Nœuds de transport hôtes.
2. Dans la liste Nœuds de transport hôtes, vérifiez la colonne État du nœud. Recherchez le nœud de transport dont l'état du nœud est dégradé ou inactif.
3. Sélectionnez &lttransport node&gt | Moniteur. Recherchez la liaison (liaison montante) signalée comme dégradée ou inactive.
4. Vérifiez les détails de l'état du membre LACP en vous connectant au DPU en échec {dpu_id} et en appelant esxcli network vswitch dvs vmware lacp status get.

La liaison montante est inactive.

Lorsque l'événement est détecté : « La liaison montante est inactive.  »

Lorsque l'événement est résolu : « La liaison montante est active.  »

Vérifiez l'état des liaisons montantes sur les hôtes dans les cartes réseau physiques.
1. Dans l'interface utilisateur de NSX accédez à Infrastructure | Nœuds | Nœuds de transport | Nœuds de transport hôtes.
2. Dans la liste Nœuds de transport hôtes, vérifiez la colonne État du nœud. Recherchez le nœud de transport dont l'état du nœud est dégradé ou inactif.
3. Sélectionnez &lttransport node&gt | Moniteur. Vérifiez les détails de l'état de la liaison (liaison montante) qui est signalée comme dégradée ou inactive. Pour éviter un état dégradé, assurez-vous que toutes les interfaces de liaison montante sont connectées et actives, qu'elles soient utilisées ou non.

La liaison montante est inactive.

Lorsque l'événement est détecté : « La liaison montante est inactive.  »

Lorsque l'événement est résolu : « La liaison montante est active.  »

Vérifiez l''état des liaisons montantes sur les hôtes dans les cartes réseau physiques.
1. Dans l'interface utilisateur de NSX accédez à Infrastructure | Nœuds | Nœuds de transport | Nœuds de transport hôtes.
2. Dans la liste Nœuds de transport hôtes, vérifiez la colonne État du nœud. Recherchez le nœud de transport dont l'état du nœud est dégradé ou inactif.
3. Sélectionnez &lttransport node&gt | Moniteur. Vérifiez les détails de l'état de la liaison (liaison montante) qui est signalée comme dégradée ou inactive. Pour éviter un état dégradé, assurez-vous que toutes les interfaces de liaison montante sont connectées et actives, qu'elles soient utilisées ou non.

Le membre de rapports LACP est inactif.

Lorsque l'événement est détecté : « Le membre de rapports LACP est inactif.  »

Lorsque l'événement est résolu : « Le membre de rapports LACP est actif.  »

Vérifiez l'état de la connexion des membres LAG sur les hôtes.
1. Dans l'interface utilisateur de NSX accédez à Infrastructure | Nœuds | Nœuds de transport | Nœuds de transport hôtes.
2. Dans la liste Nœuds de transport hôtes, vérifiez la colonne État du nœud. Recherchez le nœud de transport dont l'état du nœud est dégradé ou inactif.
3. Sélectionnez &lttransport node&gt | Moniteur. Recherchez la liaison (liaison montante) signalée comme dégradée ou inactive.
4. Vérifiez les détails de l'état du membre LACP en vous connectant à l'hôte ayant échoué et en appelant esxcli network vswitch dvs vmware lacp status get sur un hôte ESXi ou ovs-appctl bond/show et ovs-appctl lacp/show sur un hôte KVM.

Transit Connect ne parvient pas à être entièrement réalisé.

Lorsque l'événement est détecté : « La configuration liée à Transit Connect n'est pas entièrement réalisée correctement. Les problèmes potentiels peuvent être l'échec de la récupération des informations du fournisseur ou une erreur temporaire de communication du fournisseur.  »

Lorsque l'événement est résolu : « L'échec de Transit Connect est corrigé.  »

Si cette alarme n'est pas résolue automatiquement dans les 10 minutes, réessayez la ou les demandes liées à la connexion de transit les plus récentes. Par exemple, si une demande d'API d'attachement TGW a déclenché cette alarme, réessayez la demande d'API d'attachement TGW. Si l'alarme ne se résout pas même après une nouvelle tentative, procédez comme suit :
1. Vérifiez si la tâche continue d'échouer ou si elle est récupérée. a) Identifier le nœud de gestionnaire leader. Après vous être connecté à l'un des nœuds, exécutez la commande : - su admin - get cluster status verbose Cela affichera le nœud de gestionnaire leader b) Connectez-vous au nœud de gestionnaire leader NSX. Vérifiez vmc-app.log sur le nœud de gestionnaire leader NSX : - tail -f /var/log/policy/vmc-app.log c) Vérifiez les impressions suivantes dans les journaux - Si l'un de ces messages d'erreur continue de s'afficher toutes les deux minutes, cela signifie que la tâche continue d'échouer. - Échec de l'obtention de la table de routage de la TGW pour []. Erreur : [] - Impossible d'obtenir des routes TGW pour attachement [] dans la table de route []. Erreur - Échec de l'obtention de l'ID VPC d'attachement de TGW pour []. Erreur : [] - Échec de l'obtention de l'ID de ressource d'attachement TGW pour []. Erreur : Type de ressource inconnu : échec de l'obtention des pièces jointes de la TGW pour la TGW []. Erreur : []- Échec de l'obtention de l'attachement de la TGW locale []. Erreur : [] - Impossible de trouver l'état TgwAttachment correct dans AWS, état : [], ignorer la tâche de mise à jour de la route de la TGW - L'attachement de la TGW [] n'est associé à aucune table de route - Aucune association de SDDC TGW locale trouvée pour []
2. Vérifiez si tous les appels AWS depuis NSX Manager ont échoué, sur le nœud de gestionnaire leader. Exécutez la commande suivante : - export HTTP_PROXY=http://&ltpop ip&gt:3128 - export HTTPS_PROXY=http://&ltpop ip&gt:3128 - export NO_PROXY=169.254.169.254 - aws ec2 describe-instances --region Si la commande aws a échoué avec une erreur, il peut y avoir un problème système dans la configuration du proxy inverse HTTP sur pop, ou il y a un problème côté service AWS.
3. Vérifiez si l'attachement de la TGW existe toujours dans AWS. a) L'ID d'attachement TGW est disponible avec GET cloud-service/api/v1/infra/associated-groups - aws ec2 describe-transit-gateway-attachments --region --transit-gateway-attachment-id &ltTGW attachment ID&gt Si l'attachement de la TGW a été supprimé, contactez le support VMware, partagez l'ID de SDDC et l'ID d'attachement de la TGW. Une fois que l'équipe de support VMware a identifié le problème, supprimez manuellement l'objet laissé derrière, si nécessaire. b) Vérifiez si cette pièce jointe TGW existe sur la console AWS. c) Une autre option se connecte à NSX Manager, à l'aide de la commande aws pour vérifier l'état de l'attachement de la TGW : - aws ec2 describe-transit-gateway-attachments --region --transit-gateway-attachment-id &ltTGW attachment ID&gt

Le service IPsec est inactif.

Lorsque l'événement est détecté : « Le service IPsec {entity_id} est inactif. Motif : {service_down_reason}.  »

Lorsque l'événement est résolu : « Le service IPsec {entity_id} est actif.  »

1. Désactivez et activez le service IPsec à partir de l'interface utilisateur NSX Manager.
2. Si le problème persiste, consultez Syslog pour les journaux d'erreurs et contactez le support VMware.

La session VPN IPsec basée sur une stratégie est inactive.

Lorsque l'événement est détecté : « La session VPN IPsec {entity_id} basée sur une stratégie est inactive. Motif : {session_down_reason}.  »

Lorsque l'événement est résolu : « La session VPN IPsec {entity_id} basée sur une stratégie est active.  »

Vérifiez la configuration de la session VPN IPsec et résolvez les erreurs en fonction du motif de l'inactivité de la session.

La session VPN IPsec basée sur une route est inactive.

Lorsque l'événement est détecté : « La session VPN IPsec {entity_id} basée sur une route est inactive. Motif : {session_down_reason}.  »

Lorsque l'événement est résolu : « La session VPN IPsec {entity_id} basée sur une route est active.  »

Vérifiez la configuration de la session VPN IPsec et résolvez les erreurs en fonction du motif de l'inactivité de la session.

Les tunnels VPN IPsec basés sur une stratégie sont inactifs.

Lorsque l'événement est détecté : « Un ou plusieurs tunnels VPN IPsec basés sur une stratégie dans la session {entity_id} sont inactifs.  »

Lorsque l'événement est résolu : « Tous les tunnels VPN IPsec basés sur une stratégie dans la session {entity_id} sont actifs.  »

Vérifiez la configuration de la session VPN IPsec et résolvez les erreurs en fonction du motif de l'inactivité du tunnel.

Le tunnel VPN IPsec basé sur une route est inactif.

Lorsque l'événement est détecté : « Le tunnel VPN IPsec basé sur une route dans la session {entity_id} est inactif. Motif : {tunnel_down_reason}.  »

Lorsque l'événement est résolu : « Le tunnel VPN IPsec basé sur une route dans la session {entity_id} est actif.  »

Vérifiez la configuration de la session VPN IPsec et résolvez les erreurs en fonction du motif de l'inactivité du tunnel.

La session L2VPN est inactive.

Lorsque l'événement est détecté : « La session L2VPN {entity_id} est inactive.  »

Lorsque l'événement est résolu : « La session L2VPN {entity_id} est active.  »

Vérifiez l'état de la session L2VPN pour trouver le motif de l'inactivité de la session et résolvez les erreurs en fonction du motif.