Der Alarmdienst ist überlastet.

Bei Erkennung des Ereignisses: „Aufgrund einer hohen Anzahl an gemeldeten Alarmen ist der Alarmdienst vorübergehend überlastet. Die NSX-Benutzeroberfläche und GET /api/v1/alarms-NSX API melden keine neuen Alarme mehr. Syslog-Einträge und SNMP-Traps (sofern aktiviert) werden jedoch weiterhin ausgegeben und melden die zugrunde liegenden Ereignisdetails. Wenn die Ursachen für die hohe Anzahl an Alarmen behoben sind, meldet der Alarmdienst wieder neue Alarme. “

Bei Auflösung des Ereignisses: „Die hohe Anzahl von Alarmen hat sich verringert und es werden wieder neue Alarme gemeldet. “

Überprüfen Sie alle aktiven Alarme auf der Seite „Alarme“ auf der NSX-Benutzeroberfläche oder mit der GET /api/v1/alarms?status=OPEN,ACKNOWLEDGED,SUPPRESSED-NSX API. Untersuchen Sie für jeden aktiven Alarm die Hauptursache, indem Sie die empfohlene Aktion für den Alarm befolgen. Wenn ausreichend Alarme behoben sind, beginnt der Alarmdienst erneut, neue Alarme zu melden.

Eine hohe Anzahl von Alarmen eines bestimmten Typs wurde erkannt.

Bei Erkennung des Ereignisses: „Aufgrund einer hohen Anzahl an {event_id}-Alarmen zeigt der Alarmdienst vorübergehend keine Alarme dieses Typs mehr an. Die NSX-Benutzeroberfläche und GET /api/v1/alarms-NSX API melden keine neuen Instanzen dieser Alarme. Syslog-Einträge und SNMP-Traps (sofern aktiviert) werden jedoch weiterhin ausgegeben und melden die zugrunde liegenden Ereignisdetails. Wenn die Ursachen für die hohe Anzahl von {event_id}-Alarmen behoben sind, meldet der Alarmdienst bei Problemen wieder neue {event_id}-Alarme. “

Bei Auflösung des Ereignisses: „Die hohe Anzahl an {event_id}-Alarmen hat sich verringert und es werden wieder neue Alarme dieses Typs gemeldet. “

Überprüfen Sie alle aktiven Alarme des Typs {event_id} auf der Seite „Alarme“ auf der NSX-Benutzeroberfläche oder mit der GET /api/v1/alarms?status=OPEN,ACKNOWLEDGED,SUPPRESSED-NSX API. Untersuchen Sie für jeden aktiven Alarm die Hauptursache, indem Sie die empfohlene Aktion für den Alarm befolgen. Wenn ausreichend Alarme behoben sind, beginnt der Alarmdienst erneut, neue {event_id}-Alarme zu melden.

In mindestens eine der überwachten Protokolldateien kann nicht geschrieben werden.

Bei Erkennung des Ereignisses: „Mindestens eine der überwachten Protokolldateien verfügt über schreibgeschützte Berechtigungen oder hat eine falsche Benutzer-/Gruppenzuständigkeit auf Manager-, globalen Manager-, Edge-, Public Cloud-Gateway-, KVM- oder physischen Linux-Serverknoten. Oder der Protokollordner fehlt in physischen Windows-Serverknoten. Oder rsyslog.log fehlt auf Manager-, globalen Manager-, Edge- oder Public Cloud-Gateway-Knoten. “

Bei Auflösung des Ereignisses: „Alle überwachten Protokolldateien verfügen über die korrekten Dateiberechtigungen und die richtige Zuständigkeit auf Manager-, globalen Manager-, Edge-, Public Cloud Gateway-, KVM- oder physischen Linux-Serverknoten. Und der Protokollordner ist auf physischen Windows-Serverknoten vorhanden. Und rsyslog.log ist auf Manager-, globalen Manager-, Edge- oder Public Cloud-Gateway-Knoten vorhanden. “

1. Auf Manager- und globalen Manager-Knoten, Edge- und Public Cloud-Gateway-Knoten stellen Ubuntu-KVM-Hostknoten sicher, dass die Berechtigung für das Verzeichnis /var/log 775 ist und der Besitz root:syslog lautet. Ein Rhel-KVM- und ein BMS-Hostknoten stellen sicher, dass die Berechtigung für das Verzeichnis /var/log 755 ist und der Besitz root:root lautet.
2. Auf Manager- und globalen Manager-Knoten: Stellen Sie sicher, dass die Dateiberechtigungen für auth.log, nsx-audit.log, nsx-audit-write.log, rsyslog.log und syslog unter /var/log 640 lauten und dass der Besitz syslog:admin lautet.
3. Auf Edge- und Public Cloud-Gateway-Knoten: Stellen Sie sicher, dass die Dateiberechtigungen für rsyslog.log und syslog unter /var/log 640 lauten und dass der Besitz syslog:admin lautet.
4. Auf Ubuntu-KVM-Host- und physischen Ubuntu-Serverknoten: Stellen Sie sicher, dass die Dateiberechtigungen für auth.log und vmware/nsx-syslog unter /var/log 640 lauten und dass der Besitz syslog:admin lautet.
5. Auf Rhel-KVM-Hostknoten und physischen Centos/Rhel/Sles-Serverknoten: Stellen Sie sicher, dass die Dateiberechtigungen für vmware/nsx-syslog unter /var/log 640 lauten und dass der Besitz root:root lautet.
6. Wenn eine dieser Dateien falsche Berechtigungen oder Besitzer hat, führen Sie die Befehle chmod &ltmode> &ltpath&gt und chown &ltuser>:&ltgroup> &ltpath&gt aus.
7. Wenn rsyslog.log auf Manager-, globalen Manager-, Edge- oder Public Cloud-Gateway-Knoten fehlt, führen Sie in der NSX-CLI den Befehl restart service syslog aus. Dieser Befehl startet den Protokollierungsdienst neu und generiert /var/log/rsyslog.log neu.
8. Stellen Sie auf physischen Windows-Serverknoten sicher, dass der folgende Protokollordner existiert: C:\ProgramData\VMware\NSX\Logs. Falls nicht, installieren Sie NSX erneut auf dem physischen Windows-Serverknoten.

Protokollmeldungen können aufgrund einer fehlerhaften Konfiguration des Remote-Protokollservers nicht zugestellt werden.

Bei Erkennung des Ereignisses: „Protokollmeldungen an Protokollserver {hostname_or_ip_address_with_port} ({entity_id}) können aufgrund eines nicht auflösbaren FQDN, eines ungültigen TLS-Zertifikats oder einer fehlenden iptables-Regel der NSX-Appliance nicht zugestellt werden. “

Bei Auflösung des Ereignisses: „Die Konfiguration für Protokollserver {hostname_or_ip_address_with_port} ({entity_id}) ist scheinbar korrekt. “

1. Stellen Sie sicher, dass {hostname_or_ip_address_with_port} der richtige Hostname bzw. die richtige IP-Adresse und der richtige Port ist.
2. Wenn der Protokollserver mithilfe eines FQDN angegeben wird, stellen Sie sicher, dass der FQDN mithilfe des NSX-CLI-Befehls nslookup &ltfqdn&gt über die NSX-Appliance aufgelöst werden kann. Wenn er nicht aufgelöst werden kann, überprüfen Sie, ob der richtige FQDN angegeben ist und ob der Netzwerk-DNS-Server über den erforderlichen Eintrag für den FQDN verfügt.
3. Wenn der Protokollserver für die Verwendung von TLS konfiguriert ist, achten Sie darauf, dass das angegebene Zertifikat gültig ist. Achten Sie beispielsweise darauf, dass der Protokollserver tatsächlich das Zertifikat verwendet, oder überprüfen Sie mit dem OpenSSL-Befehl openssl x509 -in &ltcert-file-path&gt -noout -dates, dass das Zertifikat nicht abgelaufen ist.
4. NSX-Appliances verwenden iptables-Regeln, um ausgehenden Datenverkehr explizit zuzulassen. Stellen Sie sicher, dass die iptables-Regel für den Protokollserver ordnungsgemäß konfiguriert ist. Rufen Sie dazu den NSX-CLI-Befehl verify logging-servers auf, der die Iptables-Regeln des Protokollierungsservers nach Bedarf neu konfiguriert.
5. Wenn der Protokollserver aus irgendeinem Grund falsch konfiguriert ist, löschen Sie ihn mit dem NSX-CLI-Befehl „del logging-server &lthostname-or-ip-address[:port]&gt proto &ltproto&gt level &ltlevel&gt“ und fügen Sie ihn mit der korrekten Konfiguration erneut hinzu.

Ein Grenzwert für die minimale Kapazität wurde unterschritten.

Bei Erkennung des Ereignisses: „Die Anzahl der im System für {capacity_display_name} definierten Objekte hat {capacity_usage_count} erreicht, was über dem Schwellenwert für die Mindestkapazität von {min_capacity_threshold} % liegt. “

Bei Auflösung des Ereignisses: „Die Anzahl der im System für {capacity_display_name} definierten Objekte hat {capacity_usage_count} erreicht, und ist damit kleiner als oder gleich dem Schwellenwert für die Mindestkapazität von {min_capacity_threshold} %. “

Navigieren Sie auf der NSX-Benutzeroberfläche zur Seite „Kapazität“ und überprüfen Sie die aktuelle Nutzung im Vergleich zu den Schwellenwerten. Wenn die aktuelle Nutzung im erwarteten Bereich liegt, sollten Sie gegebenenfalls die unteren Schwellenwerte erhöhen. Wenn die aktuelle Nutzung im unerwarteten Bereich liegt, prüfen Sie, ob die Netzwerkrichtlinien so konfiguriert sind, dass die Nutzung kleiner als der oder gleich dem minimalen Schwellenwert ist.

Ein Grenzwert für die maximale Kapazität wurde überschritten.

Bei Erkennung des Ereignisses: „Die Anzahl der im System für {capacity_display_name} definierten Objekte hat {capacity_usage_count} erreicht, was über dem Schwellenwert für die Maximalkapazität von {max_capacity_threshold} % liegt. “

Bei Auflösung des Ereignisses: „Die Anzahl der im System für {capacity_display_name} definierten Objekte hat {capacity_usage_count} erreicht, und ist damit kleiner als oder gleich dem Schwellenwert für die Maximalkapazität von {max_capacity_threshold} %. “

Navigieren Sie auf der NSX-Benutzeroberfläche zur Seite „Kapazität“ und überprüfen Sie die aktuelle Nutzung im Vergleich zu den Schwellenwerten. Wenn die aktuelle Nutzung im erwarteten Bereich liegt, sollten Sie gegebenenfalls die maximalen Schwellenwerte erhöhen. Wenn die aktuelle Nutzung im unerwarteten Bereich liegt, prüfen Sie, ob die Netzwerkrichtlinien so konfiguriert sind, dass die Nutzung kleiner als der oder gleich dem maximalen Schwellenwert ist.

Eine maximale Kapazität wurde überschritten.

Bei Erkennung des Ereignisses: „Die Anzahl der im System für {capacity_display_name} definierten Objekte hat {capacity_usage_count} erreicht, was über der maximal unterstützten Anzahl von {max_supported_capacity_count} liegt. “

Bei Auflösung des Ereignisses: „Die Anzahl der im System für {capacity_display_name} definierten Objekte hat {capacity_usage_count} erreicht, und ist damit kleiner als oder gleich der maximal unterstützten Anzahl von {max_supported_capacity_count}. “

Stellen Sie sicher, dass die Anzahl der erstellten NSX-Objekte innerhalb der von NSX unterstützten Grenzwerte liegt. Wenn nicht verwendete Objekte vorhanden sind, löschen Sie diese über die entsprechende NSX-Benutzeroberfläche oder -API aus dem System. Ziehen Sie eine Erhöhung des Formfaktors aller Manager-Knoten und/oder Edge-Knoten in Betracht. Beachten Sie, dass der Formfaktor der einzelnen Knotentypen identisch sein muss. Andernfalls werden die Kapazitätsgrenzwerte für den kleinsten bereitgestellten Formfaktor verwendet.

Ein Zertifikat ist abgelaufen.

Bei Erkennung des Ereignisses: „Zertifikat {entity_id} ist abgelaufen. “

Bei Auflösung des Ereignisses: „Das abgelaufene Zertifikat {entity_id} wurde entfernt oder ist nicht mehr abgelaufen. “

Stellen Sie sicher, dass Dienste, die das Zertifikat aktuell verwenden, aktualisiert werden, um ein neues, nicht abgelaufenes Zertifikat zu verwenden. Sobald das abgelaufene Zertifikat nicht mehr verwendet wird, sollte es gelöscht werden, indem Sie die NSX API „DELETE {api_collection_path}{entity_id}“ aufrufen. Wenn das abgelaufene Zertifikat von der NAPP-Plattform verwendet wird, wird die Verbindung zwischen NSX und der NAPP-Plattform unterbrochen. Überprüfen Sie das Dokument zur Fehlerbehebung der NAPP-Plattform, um ein selbstsigniertes NAPP-CA-Zertifikat für die Wiederherstellung der Verbindung zu verwenden.

Zertifikat läuft in Kürze ab.

Bei Erkennung des Ereignisses: „Das Zertifikat {entity_id} läuft in Kürze ab. “

Bei Auflösung des Ereignisses: „Das ablaufende Zertifikat {entity_id} wurde entfernt oder läuft nicht mehr in Kürze ab. “

Stellen Sie sicher, dass Dienste, die das Zertifikat aktuell verwenden, aktualisiert werden, um ein neues, nicht ablaufendes Zertifikat zu verwenden. Sobald das ablaufende Zertifikat nicht mehr verwendet wird, sollte es gelöscht werden, indem Sie die NSX API „DELETE {api_collection_path}{entity_id}“ aufrufen.

Ein Zertifikat läuft in Kürze ab.

Bei Erkennung des Ereignisses: „Zertifikat {entity_id} läuft in Kürze ab. “

Bei Auflösung des Ereignisses: „Das ablaufende Zertifikat {entity_id} wurde entfernt oder läuft nicht mehr in Kürze ab. “

Stellen Sie sicher, dass Dienste, die das Zertifikat aktuell verwenden, aktualisiert werden, um ein neues, nicht ablaufendes Zertifikat zu verwenden. Sobald das ablaufende Zertifikat nicht mehr verwendet wird, sollte es gelöscht werden, indem Sie die NSX API „DELETE {api_collection_path}{entity_id}“ aufrufen.

Es wird empfohlen, ein vertrauenswürdiges CA-Paket zu aktualisieren.

Bei Erkennung des Ereignisses: „Das vertrauenswürdige CA-Paket {entity_id} wurde vor mehr als {ca_bundle_age_threshold} Tagen aktualisiert. Es wird empfohlen, das vertrauenswürdige CA-Paket zu aktualisieren. “

Bei Auflösung des Ereignisses: „Das vertrauenswürdige CA-Paket {entity_id} wurde entfernt oder aktualisiert bzw. wird nicht mehr verwendet. “

Stellen Sie sicher, dass Dienste, die derzeit das vertrauenswürdige CA-Paket verwenden, aktualisiert werden, um ein kürzlich aktualisiertes vertrauenswürdiges CA-Paket zu verwenden. Sofern es sich nicht um ein vom System bereitgestelltes Paket handelt, kann das Paket mithilfe der NSX API „PUT /policy/api/v1/infra/cabundles/{entity_id}“ aktualisiert werden. Sobald das abgelaufene Paket nicht mehr verwendet wird, sollten Sie es löschen (sofern es nicht vom System bereitgestellt wird), indem Sie die NSX API „DELETE /policy/api/v1/infra/cabundles/{entity_id}“ aufrufen.

Es wird vorgeschlagen, ein vertrauenswürdiges CA-Paket zu aktualisieren.

Bei Erkennung des Ereignisses: „Das vertrauenswürdige CA-Paket {entity_id} wurde vor mehr als {ca_bundle_age_threshold} Tagen aktualisiert. Wir schlagen vor, das vertrauenswürdige CA-Paket zu aktualisieren. “

Bei Auflösung des Ereignisses: „Das vertrauenswürdige CA-Paket {entity_id} wurde entfernt oder aktualisiert bzw. wird nicht mehr verwendet. “

Stellen Sie sicher, dass Dienste, die derzeit das vertrauenswürdige CA-Paket verwenden, aktualisiert werden, um ein kürzlich aktualisiertes vertrauenswürdiges CA-Paket zu verwenden. Sofern es sich nicht um ein vom System bereitgestelltes Paket handelt, kann das Paket mithilfe der NSX API „PUT /policy/api/v1/infra/cabundles/{entity_id}“ aktualisiert werden. Sobald das abgelaufene Paket nicht mehr verwendet wird, sollte es gelöscht werden (sofern es nicht vom System bereitgestellt wird), indem Sie die NSX API „DELETE /policy/api/v1/infra/cabundles/{entity_id}“ aufrufen.

Ein Zertifikat ist abgelaufen.

Bei Erkennung des Ereignisses: „Zertifikat für Transportknoten {entity_id} ist abgelaufen. “

Bei Auflösung des Ereignisses: „Das abgelaufene Zertifikat für den Transportknoten {entity_id} wurde ersetzt oder ist nicht mehr abgelaufen. “

Ersetzen Sie das Transportknoten-{entity_id}-Zertifikat durch ein nicht abgelaufenes Zertifikat. Das abgelaufene Zertifikat sollte durch den Aufruf der NSX API „POST /api/v1/trust-management/certificates/action/replace-host-certificate/{entity_id}“ ersetzt werden. Wenn das abgelaufene Zertifikat vom Transportknoten verwendet wird, wird die Verbindung zwischen Transportknoten und Manager-Knoten unterbrochen.

Zertifikat läuft in Kürze ab.

Bei Erkennung des Ereignisses: „Zertifikat für Transportknoten {entity_id} läuft bald ab. “

Bei Auflösung des Ereignisses: „Das identifizierte ablaufende Zertifikat für Transportknoten {entity_id} wurde entfernt oder läuft nicht mehr bald ab. “

Ersetzen Sie das Transportknoten-{entity_id}-Zertifikat durch ein nicht abgelaufenes Zertifikat. Das abgelaufene Zertifikat sollte durch den Aufruf der NSX API „POST /api/v1/trust-management/certificates/action/replace-host-certificate/{entity_id}“ ersetzt werden. Wenn das Zertifikat nicht ersetzt wird, wird die Verbindung zwischen dem Transportknoten und dem Manager-Knoten unterbrochen, wenn das Zertifikat abläuft.

Ein Zertifikat läuft in Kürze ab.

Bei Erkennung des Ereignisses: „Zertifikat für Transportknoten {entity_id} läuft in Kürze ab. “

Bei Auflösung des Ereignisses: „Das identifizierte ablaufende Zertifikat für Transportknoten {entity_id} wurde entfernt oder läuft nicht mehr in Kürze ab. “

Ersetzen Sie das Transportknoten-{entity_id}-Zertifikat durch ein nicht abgelaufenes Zertifikat. Das abgelaufene Zertifikat sollte durch den Aufruf der NSX API „POST /api/v1/trust-management/certificates/action/replace-host-certificate/{entity_id}“ ersetzt werden. Wenn das Zertifikat nicht ersetzt wird, wird die Verbindung zwischen dem Transportknoten und dem Manager-Knoten unterbrochen, wenn das Zertifikat abläuft.

Gruppenmitglied ist nicht verfügbar.

Bei Erkennung des Ereignisses: „Gruppenmitglied {manager_node_id} des Diensts {group_type} ist nicht verfügbar. “

Bei Auflösung des Ereignisses: „Gruppenmitglied {manager_node_id} von {group_type} ist verfügbar. “

1. Rufen Sie den NSX-CLI-Befehl „get cluster status“ auf, um den Status der Gruppenmitglieder des Clusters anzuzeigen.
2. Stellen Sie sicher, dass der Dienst für {group_type} auf dem Knoten ausgeführt wird. Rufen Sie die NSX API „GET /api/v1/node/services/&ltservice_name&gt/status“ oder den NSX-CLI-Befehl get service &ltservice_name&gt auf, um festzustellen, ob der Dienst ausgeführt wird. Wenn er nicht ausgeführt wird, rufen Sie die NSX API POST /api/v1/node/services/&ltservice_name&gt?action=restart oder die NSX-CLI restart service &ltservice_name&gt auf, um den Dienst neu zu starten.
3. Überprüfen Sie anhand von /var/log/ für den Dienst {group_type}, ob Fehler gemeldet wurden.

Alle Gruppenmitglieder des Dienstes sind nicht verfügbar.

Bei Erkennung des Ereignisses: „Alle Gruppenmitglieder {manager_node_ids} des Diensts {group_type} sind nicht verfügbar. “

Bei Auflösung des Ereignisses: „Alle Gruppenmitglieder {manager_node_ids} des Diensts {group_type} sind verfügbar. “

1. Stellen Sie sicher, dass der Dienst für {group_type} auf dem Knoten ausgeführt wird. Rufen Sie die NSX API „GET /api/v1/node/services/&ltservice_name&gt/status“ oder den NSX-CLI-Befehl get service &ltservice_name&gt auf, um festzustellen, ob der Dienst ausgeführt wird. Wenn er nicht ausgeführt wird, rufen Sie die NSX API POST /api/v1/node/services/&ltservice_name&gt?action=restart oder die NSX-CLI restart service &ltservice_name&gt auf, um den Dienst neu zu starten.
2. Überprüfen Sie anhand von /var/log/ für den Dienst {group_type}, ob Fehler gemeldet wurden.

Hyperbus auf DPU kann nicht mit dem Manager-Knoten kommunizieren.

Bei Erkennung des Ereignisses: „Hyperbus auf DPU {dpu_id} kann nicht mit dem Manager-Knoten kommunizieren. “

Bei Auflösung des Ereignisses: „Hyperbus kann auf DPU {dpu_id} nicht mit dem Manager-Knoten kommunizieren. “

Möglicherweise fehlt die Hyperbus-VMkernel-Schnittstelle (vmk50) auf DPU {dpu_id}. Weitere Informationen hierzu finden Sie in diesem Knowledgebase-Artikel: https://kb.vmware.com/s/article/67432.

Hyperbus kann nicht mit dem Manager-Knoten kommunizieren.

Bei Erkennung des Ereignisses: „Hyperbus kann nicht mit dem Manager-Knoten kommunizieren. “

Bei Auflösung des Ereignisses: „Hyperbus kann mit dem Manager-Knoten kommunizieren. “

Möglicherweise fehlt die Hyperbus-VMkernel-Schnittstelle (vmk50). Weitere Informationen hierzu finden Sie in diesem Knowledgebase-Artikel: https://kb.vmware.com/s/article/67432.

Der angegebene Collector kann nicht über vmknic(s) auf dem angegebenen DVS auf DPU erreicht werden.

Bei Erkennung des Ereignisses: „Der {vertical_name}-Collector {collector_ip} kann nicht über vmknic(s)(stack {stack_alias}) auf DVS {dvs_alias} auf DPU {dpu_id} erreicht werden, ist aber über vmknic(s)(stack {stack_alias}) auf anderen DVS erreichbar. “

Bei Auflösung des Ereignisses: „Der {vertical_name}-Collector {collector_ip} kann über vmknic(s) (Stack {stack_alias}) auf DVS {dvs_alias} auf DPU {dpu_id} erreicht werden, oder der {vertical_name}-Collector {collector_ip} ist überhaupt nicht erreichbar. “

Wenn die Warnung aktiviert ist, bedeutet dies nicht, dass der Collector nicht erreichbar ist. Die exportierten Flows, die durch die Kategorie auf der Grundlage von DVS {dvs_alias} generiert werden, können den Collector {collector_ip} weiterhin über vmknic(s) auf DVS außer auf DVS {dvs_alias} erreichen. Wenn dies nicht akzeptabel ist, kann der Benutzer versuchen, vmknic(s) mit Stack {stack_alias} auf DVS {dvs_alias} zu erstellen und mit einer entsprechenden IPv4(6)-Adresse zu konfigurieren, und anschließend überprüfen, ob {vertical_name}-Collector {collector_ip} über die neu erstellten vmknic(s) auf DPU {dpu_id} erreicht werden kann, indem er vmkping {collector_ip} -S {stack_alias} -I vmkX bei aktiviertem SSH zu DPU über ESXi aufruft.

Der angegebene Collector kann über vorhandene vmknic(s) auf DPU überhaupt nicht erreicht werden.

Bei Erkennung des Ereignisses: „Der {vertical_name}-Collector {collector_ip} kann nicht über vorhandene vmknic(s)(Stack {stack_alias}) auf einem DVS auf DPU {dpu_id} erreicht werden. “

Bei Auflösung des Ereignisses: „Der {vertical_name}-Collector {collector_ip} kann über vorhandene vmknic(s)(Stack {stack_alias}) jetzt auf DPU {dpu_id} erreicht werden. “

Damit der Collector für ein bestimmtes Vertical auf dem DVS erreichbar ist, muss der Benutzer sicherstellen, dass vmknic(s) mit dem erwarteten Stack-{stack_alias} erstellt und mit entsprechenden IPv4(6)-Adressen konfiguriert wurde(n) und die Netzwerkverbindung mit {vertical_name}-Collector {collector_ip} ebenfalls ordnungsgemäß ist. Der Benutzer muss also die DPU {dpu_id} überprüfen und die erforderliche Konfiguration durchführen, um sicherzustellen, dass die Bedingung erfüllt ist. Wenn schließlich vmkping {collector_ip} -S {stack_alias} mit aktiviertem SSH zu DPU über ESXi erfolgreich ist, bedeutet dies, dass das Problem behoben ist.

Die durchschnittliche Netzwerklatenz zwischen Manager-Knoten ist hoch.

Bei Erkennung des Ereignisses: „Die durchschnittliche Netzwerklatenz zwischen den Manager-Knoten {manager_node_id} ({appliance_address}) und {remote_manager_node_id} ({remote_appliance_address}) betrug in den letzten 5 Minuten mehr als 10 ms. “

Bei Auflösung des Ereignisses: „Die durchschnittliche Netzwerklatenz zwischen den Manager-Knoten {manager_node_id} ({appliance_address}) und {remote_manager_node_id} ({remote_appliance_address}) liegt innerhalb von 10 ms. “

Stellen Sie sicher, dass keine Firewallregeln den Ping-Datenverkehr zwischen den Manager-Knoten blockieren. Wenn andere Server mit hoher Bandbreite und Anwendungen, die das lokale Netzwerk nutzen, vorhanden sind, verschieben Sie diese gegebenenfalls in ein anderes Netzwerk.

Die Control Plane-Verbindung des Transportknotens mit dem Manager-Knoten ist bereits lange inaktiv.

Bei Erkennung des Ereignisses: „Die Control Plane-Verbindung des Transportknotens {entity_id} mit dem Manager-Knoten {appliance_address} ist aus der Sicht des Transportknotens seit mindestens {timeout_in_minutes} Minuten inaktiv. “

Bei Auflösung des Ereignisses: „Der Transportknoten {entity_id} stellt die Control Plane-Verbindung mit dem Manager-Knoten {appliance_address} wieder her. “

1. Überprüfen Sie die Konnektivität des Transportknotens {entity_id} mit der Schnittstelle des Manager-Knotens {appliance_address} über Ping. Wenn sie über einen Ping-Befehl nicht erreichbar sind, überprüfen Sie, ob die Konnektivität im Netzwerk beeinträchtigt ist.
2. Überprüfen Sie, ob die TCP-Verbindungen mithilfe der netstat-Ausgabe eingerichtet wurden, um festzustellen, ob der Controller-Dienst auf dem Manager-Knoten {appliance_address} Port 1235 auf Verbindungen überwacht. Falls nicht, überprüfen Sie die Firewall- (oder) iptables-Regeln, um festzustellen, ob Port 1235 Verbindungsanfragen von Transportknoten {entity_id} blockiert. Stellen Sie sicher, dass keine Host- oder Netzwerk-Firewalls im Underlay vorhanden sind, die die erforderlichen IP-Ports zwischen Manager-Knoten und Transportknoten blockieren. Dies ist in unserem Tool für Ports und Protokolle beschrieben: https://ports.vmware.com/.
3. Es ist möglich, dass sich der Transportknoten {entity_id} noch im Wartungsmodus befindet. Sie können über die folgende API überprüfen, ob sich der Transportknoten im Wartungsmodus befindet: GET https://&ltnsx-mgr&gt/api/v1/transport-nodes/&lttn-uuid&gt. Wenn der Wartungsmodus festgelegt ist, wird der Transportknoten nicht mit dem Controller-Dienst verbunden. Dies ist in der Regel der Fall, wenn ein Upgrade des Hosts ausgeführt wird. Warten Sie einige Minuten und prüfen Sie die Konnektivität erneut.

Die Control Plane-Verbindung des Transportknotens mit dem Manager-Knoten ist inaktiv.

Bei Erkennung des Ereignisses: „Die Control Plane-Verbindung des Transportknotens {entity_id} mit dem Manager-Knoten {appliance_address} ist aus der Sicht des Transportknotens seit mindestens {timeout_in_minutes} Minuten inaktiv. “

Bei Auflösung des Ereignisses: „Der Transportknoten {entity_id} stellt die Control Plane-Verbindung mit dem Manager-Knoten {appliance_address} wieder her. “

1. Überprüfen Sie die Konnektivität des Transportknotens {entity_id} mit der Schnittstelle des Manager-Knotens {appliance_address} über Ping. Wenn sie über einen Ping-Befehl nicht erreichbar sind, überprüfen Sie, ob die Konnektivität im Netzwerk beeinträchtigt ist.
2. Überprüfen Sie, ob die TCP-Verbindungen mithilfe der netstat-Ausgabe eingerichtet wurden, um festzustellen, ob der Controller-Dienst auf dem Manager-Knoten {appliance_address} Port 1235 auf Verbindungen überwacht. Falls nicht, überprüfen Sie die Firewall- (oder) iptables-Regeln, um festzustellen, ob Port 1235 Verbindungsanfragen von Transportknoten {entity_id} blockiert. Stellen Sie sicher, dass keine Host- oder Netzwerk-Firewalls im Underlay vorhanden sind, die die erforderlichen IP-Ports zwischen Manager-Knoten und Transportknoten blockieren. Dies ist in unserem Tool für Ports und Protokolle beschrieben: https://ports.vmware.com/.
3. Es ist möglich, dass sich der Transportknoten {entity_id} noch im Wartungsmodus befindet. Sie können über die folgende API überprüfen, ob sich der Transportknoten im Wartungsmodus befindet: GET https://&ltnsx-mgr&gt/api/v1/transport-nodes/&lttn-uuid&gt Wenn der Wartungsmodus festgelegt ist, wird der Transportknoten nicht mit dem Controller-Dienst verbunden. Dies ist in der Regel der Fall, wenn ein Upgrade des Hosts ausgeführt wird. Warten Sie einige Minuten und prüfen Sie die Konnektivität erneut. Hinweis: Bitte beachten Sie, dass dieser Alarm nicht kritisch ist und aufgelöst werden sollte. GSS muss über diesen Alarm nicht benachrichtigt werden, es sei denn, er bleibt über einen längeren Zeitraum ungelöst.

Die Verbindung des Controller-Diensts mit dem Transportknoten ist getrennt.

Bei Erkennung des Ereignisses: „Der Controller-Dienst auf Manager-Knoten {appliance_address} ({central_control_plane_id}) zum Transportknoten {transport_node_name} ({entity_id}) ist aus Sicht des Controller-Diensts seit mindestens drei Minuten inaktiv. “

Bei Auflösung des Ereignisses: „Der Controller-Dienst auf dem Manager-Knoten {appliance_address} ({central_control_plane_id}) stellt die Verbindung zum Transportknoten {entity_id} wieder her. “

1. Überprüfen Sie die Konnektivität zwischen dem Controller-Dienst {central_control_plane_id} und der Schnittstelle des Transportknotens {entity_id} über Ping und Traceroute. Dies kann über die Admin-CLI des NSX Manager-Knotens durchgeführt werden. Der Ping-Test sollte keine Abbrüche und konsistente Latenzwerte aufweisen. VMware empfiehlt Latenzwerte von 150 ms oder weniger.
2. Navigieren Sie in der NSX-Benutzeroberfläche zu „System“ | „Fabric“ | „Knoten“ | „Transportknoten“ {entity_id}, um zu überprüfen, ob die TCP-Verbindungen zwischen dem Controller-Dienst auf dem Manager-Knoten {appliance_address} ({central_control_plane_id}) und dem Transportknoten {entity_id} hergestellt wurden. Falls nicht, überprüfen Sie die Firewallregeln im Netzwerk und auf den Hosts, um festzustellen, ob Port 1235 die Verbindungsanfragen des Transportknotens {entity_id} blockiert. Stellen Sie sicher, dass keine Host- oder Netzwerk-Firewalls im Underlay vorhanden sind, die die erforderlichen IP-Ports zwischen Manager-Knoten und Transportknoten blockieren. Dies ist in unserem Tool für Ports und Protokolle beschrieben: https://ports.vmware.com/.

Die Verbindung des Controllers mit dem Transportknoten ist bereits zu lange getrennt.

Bei Erkennung des Ereignisses: „Der Controller-Dienst auf Manager-Knoten {appliance_address} ({central_control_plane_id}) zum Transportknoten {transport_node_name} ({entity_id}) ist aus Sicht des Controller-Dienstes seit mindestens 15 Minuten inaktiv. “

Bei Auflösung des Ereignisses: „Der Controller-Dienst auf dem Manager-Knoten {appliance_address} ({central_control_plane_id}) stellt die Verbindung zum Transportknoten {entity_id} wieder her. “

1. Überprüfen Sie die Konnektivität zwischen dem Controller-Dienst {central_control_plane_id} und der Schnittstelle des Transportknotens {entity_id} über Ping und Traceroute. Dies kann über die Admin-CLI des NSX Manager-Knotens durchgeführt werden. Der Ping-Test sollte keine Abbrüche und konsistente Latenzwerte aufweisen. VMware empfiehlt Latenzwerte von 150 ms oder weniger.
2. Navigieren Sie in der NSX-Benutzeroberfläche zu „System“ | „Fabric“ | „Knoten“ | „Transportknoten“ {entity_id}, um zu überprüfen, ob die TCP-Verbindungen zwischen dem Controller-Dienst auf dem Manager-Knoten {appliance_address} ({central_control_plane_id}) und dem Transportknoten {entity_id} hergestellt wurden. Falls nicht, überprüfen Sie die Firewallregeln im Netzwerk und auf den Hosts, um festzustellen, ob Port 1235 die Verbindungsanfragen des Transportknotens {entity_id} blockiert. Stellen Sie sicher, dass keine Host- oder Netzwerk-Firewalls im Underlay vorhanden sind, die die erforderlichen IP-Ports zwischen Manager-Knoten und Transportknoten blockieren. Dies ist in unserem Tool für Ports und Protokolle beschrieben: https://ports.vmware.com/.

Der Kanal zwischen Manager und Controller ist nicht verfügbar.

Bei Erkennung des Ereignisses: „Die Kommunikation zwischen der Verwaltungsfunktion und der Steuerungsfunktion ist auf dem Manager-Knoten {manager_node_name} ({appliance_address}) fehlgeschlagen. “

Bei Auflösung des Ereignisses: „Die Kommunikation zwischen der Verwaltungsfunktion und der Steuerungsfunktion wurde auf dem Manager-Knoten {manager_node_name} ({appliance_address}) wiederhergestellt. “

1. Rufen Sie auf dem Manager-Knoten {manager_node_name} ({appliance_address}) den folgenden NSX-CLI-Befehl auf: get service applianceproxy, um den Status des Diensts regelmäßig 60 Minuten lang zu überprüfen.
2. Wenn der Dienst länger als 60 Minuten nicht ausgeführt wird, rufen Sie den folgenden NSX-CLI-Befehl auf: restart service applianceproxy und überprüfen Sie den Status erneut. Wenn der Dienst weiterhin nicht verfügbar ist, wenden Sie sich an den VMware Support.

Der Verwaltungskanal für den Transportknoten ist nicht verfügbar.

Bei Erkennung des Ereignisses: „Der Verwaltungskanal zum Transportknoten {transport_node_name} ({transport_node_address}) ist seit 5 Minuten inaktiv. “

Bei Auflösung des Ereignisses: „Der Verwaltungskanal zum Transportknoten {transport_node_name} ({transport_node_address}) ist aktiv. “

Stellen Sie sicher, dass Netzwerkkonnektivität zwischen den Manager-Knoten und dem Transportknoten {transport_node_name} ({transport_node_address}) besteht und keine Firewalls den Datenverkehr zwischen den Knoten blockieren. Stellen Sie auf Windows Transportknoten sicher, dass der nsx-proxy-Dienst auf dem Transportknoten ausgeführt wird, indem Sie den Befehl C:\NSX\nsx-proxy\nsx-proxy.ps1 status im Windows PowerShell aufrufen. Wenn er nicht ausgeführt wird, starten Sie ihn neu, indem Sie den Befehl aufrufen: C:\NSX\nsx-proxy\nsx-proxy.ps1 restart. Stellen Sie auf allen anderen Transportknoten sicher, dass der NSX-Proxydienst auf dem Transportknoten ausgeführt wird, indem Sie den Befehl aufrufen: /etc/init.d/nsx-proxy status. Wenn er nicht ausgeführt wird, starten Sie ihn neu, indem Sie den Befehl aufrufen: /etc/init.d/nsx-proxy restart.

Verwaltungskanal zum Transportknoten ist zu lang inaktiv.

Bei Erkennung des Ereignisses: „Der Verwaltungskanal zum Transportknoten {transport_node_name} ({transport_node_address}) ist seit 15 Minuten inaktiv. “

Bei Auflösung des Ereignisses: „Der Verwaltungskanal zum Transportknoten {transport_node_name} ({transport_node_address}) ist aktiv. “

Stellen Sie sicher, dass Netzwerkkonnektivität zwischen den Manager-Knoten und dem Transportknoten {transport_node_name} ({transport_node_address}) besteht und keine Firewalls den Datenverkehr zwischen den Knoten blockieren. Stellen Sie auf Windows Transportknoten sicher, dass der nsx-proxy-Dienst auf dem Transportknoten ausgeführt wird, indem Sie den Befehl C:\NSX\nsx-proxy\nsx-proxy.ps1 status im Windows PowerShell aufrufen. Wenn er nicht ausgeführt wird, starten Sie ihn neu, indem Sie den Befehl aufrufen: C:\NSX\nsx-proxy\nsx-proxy.ps1 restart. Stellen Sie auf allen anderen Transportknoten sicher, dass der NSX-Proxydienst auf dem Transportknoten ausgeführt wird, indem Sie den Befehl aufrufen: /etc/init.d/nsx-proxy status. Wenn er nicht ausgeführt wird, starten Sie ihn neu, indem Sie den Befehl aufrufen: /etc/init.d/nsx-proxy restart.

DNS-Lookup für den FQDN des Manager-Knotens fehlgeschlagen.

Bei Erkennung des Ereignisses: „DNS-Lookup ist für den Manager-Knoten {entity_id} mit FQDN {appliance_fqdn} fehlgeschlagen und das Flag ‚publish_fqdns‘ wurde gesetzt. “

Bei Auflösung des Ereignisses: „FQDN-Lookup für den Manager-Knoten {entity_id} mit FQDN {appliance_fqdn} war erfolgreich oder das Flag ‚publish_fqdns‘ wurde gelöscht. “

1. Weisen Sie allen Manager-Knoten korrekte FQDNs zu und überprüfen Sie, ob die DNS-Konfiguration für einen erfolgreichen Lookup der FQDNs aller Manager-Knoten korrekt ist.
2. Alternativ können Sie die Verwendung von FQDNs deaktivieren, indem Sie die NSX API PUT /api/v1/configs/management aufrufen, wobei „publish_fqdns“ im Anforderungstext auf „false“ gesetzt ist. Danach nutzen Aufrufe von Transportknoten und vom Verbund an Manager-Knoten in diesem Cluster nur IP-Adressen.

Umgekehrter DNS-Lookup für die IP-Adresse des-Manager-Knotens fehlgeschlagen.

Bei Erkennung des Ereignisses: „Umgekehrter DNS-Lookup für den Manager-Knoten {entity_id} mit der IP-Adresse {appliance_address} ist fehlgeschlagen und Flag ‚publish_fqdns‘ wurde gesetzt. “

Bei Auflösung des Ereignisses: „Umgekehrter DNS-Lookup für den Manager-Knoten {entity_id} mit der IP-Adresse {appliance_address} war erfolgreich oder Flag ‚publish_fqdns‘ wurde gelöscht. “

1. Weisen Sie allen Manager-Knoten die korrekten FQDNs zu und stellen Sie sicher, dass die DNS-Konfiguration für einen erfolgreichen umgekehrten Lookup der IP-Adresse des Manager-Knotens korrekt ist.
2. Alternativ können Sie die Verwendung von FQDNs deaktivieren, indem Sie die NSX API PUT /api/v1/configs/management aufrufen, wobei „publish_fqdns“ im Anforderungstext auf „false“ gesetzt ist. Danach nutzen Aufrufe von Transportknoten und vom Verbund an Manager-Knoten in diesem Cluster nur IP-Adressen.

Verwaltungskanal zum Manager-Knoten ist inaktiv.

Bei Erkennung des Ereignisses: „Der Verwaltungskanal zum Manager-Knoten {manager_node_id} ({appliance_address}) ist seit 5 Minuten inaktiv. “

Bei Auflösung des Ereignisses: „Der Verwaltungskanal zum Manager-Knoten {manager_node_id} ({appliance_address}) ist aktiv. “

Stellen Sie sicher, dass die Netzwerkkonnektivität zwischen dem Transportknoten {transport_node_id} und dem Master-Manager-Knoten besteht. und keine Firewalls den Datenverkehr zwischen den Knoten blockieren. Stellen Sie sicher, dass der Messaging-Manager-Dienst auf Manager-Knoten ausgeführt wird, indem Sie den Befehl aufrufen: /etc/init.d/messaging-manager status. Wenn der Messaging-Manager nicht ausgeführt wird, starten Sie ihn neu, indem Sie den Befehl aufrufen: /etc/init.d/messaging-manager restart.

Verwaltungskanal zum Manager-Knoten ist zu lang inaktiv.

Bei Erkennung des Ereignisses: „Der Verwaltungskanal zum Manager-Knoten {manager_node_id} ({appliance_address}) ist seit 15 Minuten inaktiv. “

Bei Auflösung des Ereignisses: „Der Verwaltungskanal zum Manager-Knoten {manager_node_id} ({appliance_address}) ist aktiv. “

Stellen Sie sicher, dass die Netzwerkkonnektivität zwischen dem Transportknoten {transport_node_id} und den Master-Manager-Knoten besteht. und keine Firewalls den Datenverkehr zwischen den Knoten blockieren. Stellen Sie sicher, dass der Messaging-Manager-Dienst auf Manager-Knoten ausgeführt wird, indem Sie den Befehl aufrufen: /etc/init.d/messaging-manager status. Wenn der Messaging-Manager nicht ausgeführt wird, starten Sie ihn neu, indem Sie den Befehl aufrufen: /etc/init.d/messaging-manager restart.

Die Netzwerklatenz der Transportknotenverwaltung ist hoch.

Bei Erkennung des Ereignisses: „Die durchschnittliche Netzwerklatenz zwischen Manager-Knoten und Host {transport_node_name} ({transport_node_address}) beträgt 5 Minuten lang mehr als 150 ms. “

Bei Auflösung des Ereignisses: „Die durchschnittliche Netzwerklatenz zwischen Manager-Knoten und Host {transport_node_name} ({transport_node_address}) ist normal. “

1. Warten Sie 5 Minuten, um zu sehen, ob der Alarm automatisch behoben wird.
2. Pingen Sie den Transportknoten vom Manager-Knoten aus an. Der Ping-Test sollte keine Abbrüche und konsistente Latenzwerte aufweisen. VMware empfiehlt Latenzwerte von 150 ms oder weniger.
3. Prüfen Sie auf weitere Probleme der physischen Netzwerkschicht. Wenn das Problem weiterhin besteht, wenden Sie sich bitte an den VMware-Support.

Die IP-Adressen in einem IP-Pool wurden ausgeschöpft.

Bei Erkennung des Ereignisses: „Die IP-Adressen im IP-Pool {entity_id} des DHCP-Servers {dhcp_server_id} sind verbraucht. Die letzte DHCP-Anforderung schlug fehl, zukünftige Anforderungen schlagen ebenfalls fehl. “

Bei Auflösung des Ereignisses: „IP-Pool {entity_id} des DHCP-Servers {dhcp_server_id} ist nicht mehr verbraucht. Ein Lease wird erfolgreich der letzten DHCP-Anforderung zugeteilt. “

Überprüfen Sie die Konfiguration des DHCP-Pools in der NSX-Benutzeroberfläche oder auf dem Edge-Knoten, auf dem der DHCP-Server ausgeführt wird, indem Sie den NSX-CLI-Befehl get dhcp ip-pool ausführen. Überprüfen Sie auch die aktuellen aktiven Leases auf dem Edge-Knoten, indem Sie den NSX-CLI-Befehl get dhcp lease aufrufen. Vergleichen Sie die Leases mit der Anzahl aktiver VMs. Sie sollten die Leasedauer in der DHCP-Serverkonfiguration verringern, wenn die Anzahl von VMs im Vergleich zur Anzahl aktiver Leases niedrig ist. Sie sollten auch den Poolbereich für den DHCP-Server erweitern, indem Sie die Seite Netzwerk | Segmente | Segment auf der NSX-Benutzeroberfläche aufrufen.

Ein IP-Pool ist überladen.

Bei Erkennung des Ereignisses: „Die Nutzung des IP-Pools {entity_id} des DHCP-Servers {dhcp_server_id} ist in Kürze ausgeschöpft. Es sind {dhcp_pool_usage} % IPs zugeteilt. “

Bei Auflösung des Ereignisses: „Der IP-Pool {entity_id} des DHCP-Servers {dhcp_server_id} ist unter den hohen Nutzungsschwellenwert gefallen. “

Überprüfen Sie die Konfiguration des DHCP-Pools in der NSX-Benutzeroberfläche oder auf dem Edge-Knoten, auf dem der DHCP-Server ausgeführt wird, indem Sie den NSX-CLI-Befehl get dhcp ip-pool ausführen. Überprüfen Sie auch die aktuellen aktiven Leases auf dem Edge-Knoten, indem Sie den NSX-CLI-Befehl get dhcp lease aufrufen. Vergleichen Sie die Leases mit der Anzahl aktiver VMs. Sie sollten die Leasedauer in der DHCP-Serverkonfiguration verringern, wenn die Anzahl von VMs im Vergleich zur Anzahl aktiver Leases niedrig ist. Sie sollten auch den Poolbereich für den DHCP-Server erweitern, indem Sie die Seite Netzwerk | Segmente | Segment auf der NSX-Benutzeroberfläche aufrufen.

Die DFW-CPU-Nutzung ist sehr hoch.

Bei Erkennung des Ereignisses: „Die DFW-CPU-Auslastung auf dem Transportknoten {entity_id} hat {system_resource_usage} % erreicht und ist damit größer als der oder gleich dem Schwellenwert für eine sehr hohe Nutzung von {system_usage_threshold} %. “

Bei Auflösung des Ereignisses: „Die DFW-CPU-Nutzung auf dem Transportknoten {entity_id} hat {system_resource_usage} % erreicht und ist damit kleiner als der Schwellenwert für eine sehr hohe Nutzung von {system_usage_threshold} %. “

Erwägen Sie, die Arbeitslasten der VM auf diesem Host erneut auf andere Hosts auszugleichen. Überprüfen Sie das Sicherheitsdesign für die Optimierung. Verwenden Sie beispielsweise die Konfiguration „Anwenden auf“, wenn die Regeln nicht auf das gesamte Datencenter zutreffen.

Die DFW-CPU-Auslastung auf DPU ist sehr hoch.

Bei Erkennung des Ereignisses: „Die DFW-CPU-Auslastung auf dem Transportknoten {entity_id} hat auf DPU {dpu_id} {system_resource_usage} % erreicht und ist damit größer als der oder gleich dem Schwellenwert für eine sehr hohe Nutzung von {system_usage_threshold} %. “

Bei Auflösung des Ereignisses: „Die DFW-CPU-Nutzung auf dem Transportknoten {entity_id} hat auf DPU {dpu_id} {system_resource_usage} % erreicht und ist damit kleiner als der Schwellenwert für eine sehr hohe Nutzung von {system_usage_threshold} %. “

Erwägen Sie, die Arbeitslasten der VM auf diesem Host erneut auf andere Hosts auszugleichen. Überprüfen Sie das Sicherheitsdesign für die Optimierung. Verwenden Sie beispielsweise die Konfiguration „Anwenden auf“, wenn die Regeln nicht auf das gesamte Datencenter zutreffen.

Die DFW-Arbeitsspeichernutzung ist sehr hoch.

Bei Erkennung des Ereignisses: „Die DFW-Arbeitsspeicherauslastung {heap_type} auf dem Transportknoten {entity_id} hat {system_resource_usage} % erreicht und ist damit größer als der oder gleich dem Schwellenwert für eine sehr hohe Nutzung von {system_usage_threshold} %. “

Bei Auflösung des Ereignisses: „Die DFW-Arbeitsspeicherauslastung {heap_type} auf dem Transportknoten {entity_id} hat {system_resource_usage} % erreicht und ist damit kleiner als der Schwellenwert für eine sehr hohe Nutzung von {system_usage_threshold} %. “

Zeigen Sie die aktuelle DFW-Arbeitsspeicherauslastung an, indem Sie den NSX-CLI-Befehl get firewall thresholds auf dem Host aufrufen. Erwägen Sie, die Arbeitslasten auf diesem Host erneut auf andere Hosts auszugleichen.

Die DFW-Arbeitsspeichernutzung auf DPU ist sehr hoch.

Bei Erkennung des Ereignisses: „Die DFW-Arbeitsspeicherauslastung {heap_type} auf dem Transportknoten {entity_id} hat {system_resource_usage} % auf DPU {dpu_id} erreicht und ist damit größer als der oder gleich dem Schwellenwert für eine sehr hohe Nutzung von {system_usage_threshold} %. “

Bei Auflösung des Ereignisses: „Die DFW-Arbeitsspeicherauslastung {heap_type} auf dem Transportknoten {entity_id} hat {system_resource_usage} % auf DPU {dpu_id} erreicht und ist damit kleiner als der Schwellenwert für eine sehr hohe Nutzung von {system_usage_threshold} %. “

Zeigen Sie die aktuelle DFW-Arbeitsspeicherauslastung an, indem Sie den NSX-CLI-Befehl get firewall thresholds auf der DPU aufrufen. Erwägen Sie, die Arbeitslasten auf diesem Host erneut auf andere Hosts auszugleichen.

Fehler bei DFW vMotion, Port getrennt.

Bei Erkennung des Ereignisses: „Der ‚DFW vMotion für DFW‘-Filter {entity_id} auf dem Zielhost {transport_node_name} ist fehlgeschlagen, und der Port für das Element wurde getrennt. “

Bei Auflösung des Ereignisses: „Der ‚DFW-Konfiguration für DFW‘-Filter {entity_id} auf dem Zielhost {transport_node_name} wurde erfolgreich angewendet, und der durch den DFW vMotion-Ausfall verursachte Fehler wurde behoben. “

Überprüfen Sie VMs auf dem Host in NSX Manager und übertragen Sie die DFW-Konfiguration manuell über die NSX Manager-Benutzeroberfläche erneut. Die neu zu übertragende DFW-Richtlinie kann durch den DFW-Filter {entity_id} nachverfolgt werden. Suchen Sie auch die VM, an die der DFW-Filter angehängt ist, und starten Sie sie neu.

Der DFW-Flood-Grenzwert hat die Warnstufe erreicht.

Bei Erkennung des Ereignisses: „Der DFW-Flood-Grenzwert für den DFW-Filter {entity_id} auf dem Host {transport_node_name} hat die Warnstufe von 80 % des konfigurierten Grenzwerts für das Protokoll {protocol_name} erreicht. “

Bei Auflösung des Ereignisses: „Die Bedingung für die Flood-Grenzwertwarnung für den DFW-Filter {entity_id} auf dem Host {transport_node_name} für das Protokoll {protocol_name} wurde gelöscht. “

Überprüfen Sie die VMs auf dem Host in NSX Manager und überprüfen Sie die konfigurierte Flood-Warnungsstufe des DFW-Filters {entity_id} für das Protokoll {protocol_name}.

Der DFW-Flood-Grenzwert hat eine kritische Stufe erreicht.

Bei Erkennung des Ereignisses: „Der DFW-Flood-Grenzwert für den DFW-Filter {entity_id} auf dem Host {transport_node_name} hat eine kritische Stufe von 98 % des konfigurierten Grenzwerts für das Protokoll {protocol_name} erreicht. “

Bei Auflösung des Ereignisses: „Die Bedingung für den kritischen Flood-Grenzwert für den DFW-Filter {entity_id} auf dem Host {transport_node_name} für das Protokoll {protocol_name} wurde gelöscht. “

Überprüfen Sie die VMs auf dem Host in NSX Manager und überprüfen Sie die konfigurierte kritische Flood-Stufe des DFW-Filters {entity_id} für das Protokoll {protocol_name}.

Die Anzahl der DFW-Sitzungen ist hoch.

Bei Erkennung des Ereignisses: „Die Anzahl der DFW-Sitzungen auf dem Transportknoten {entity_id} ist hoch, hat {system_resource_usage} % erreicht und ist damit größer als der oder gleich dem Schwellenwert von {system_usage_threshold} %. “

Bei Auflösung des Ereignisses: „Die Anzahl der DFW-Sitzungen auf dem Transportknoten {entity_id} hat {system_resource_usage} % erreicht und ist damit kleiner als der Schwellenwert von {system_usage_threshold} %. “

Überprüfen Sie die Lastebene des Netzwerkdatenverkehrs der Arbeitslasten auf dem Host. Erwägen Sie, die Arbeitslasten auf diesem Host erneut auf andere Hosts auszugleichen.

Der Grenzwert für DFW-Regeln pro vNIC überschreitet in Kürze den maximalen Grenzwert.

Bei Erkennung des Ereignisses: „Der Grenzwert für DFW-Regeln für VIF {entity_id} auf dem Zielhost {transport_node_name} ist im Begriff, den maximalen Grenzwert zu überschreiten. “

Bei Auflösung des Ereignisses: „Der Grenzwert für DFW-Regeln für VIF {entity_id} auf dem Zielhost {transport_node_name} ist unter den maximalen Grenzwert gefallen. “

Melden Sie sich beim ESX-Host {transport_node_name} an und rufen Sie den NSX-CLI-Befehl get firewall &ltVIF_UUID&gt ruleset rules auf, um die Regelstatistik für Regeln anzuzeigen, die auf der entsprechenden VIF konfiguriert sind. Reduzieren Sie die Anzahl der für VIF-{entity_id} konfigurierten Regeln.

Der Grenzwert für DFW-Regeln pro vNIC nähert sich dem maximalen Grenzwert.

Bei Erkennung des Ereignisses: „Der Grenzwert für DFW-Regeln für VIF {entity_id} auf dem Zielhost {transport_node_name} nähert sich dem maximalen Grenzwert. “

Bei Auflösung des Ereignisses: „Der Grenzwert für DFW-Regeln für VIF {entity_id} auf dem Zielhost {transport_node_name} ist unter den Schwellenwert gefallen. “

Melden Sie sich beim ESX-Host {transport_node_name} an und rufen Sie den NSX-CLI-Befehl get firewall &ltVIF_UUID&gt ruleset rules auf, um die Regelstatistik für Regeln anzuzeigen, die auf der entsprechenden VIF konfiguriert sind. Reduzieren Sie die Anzahl der für VIF-{entity_id} konfigurierten Regeln.

Der Grenzwert für DFW-Regeln pro Host überschreitet in Kürze den maximalen Grenzwert.

Bei Erkennung des Ereignisses: „Der Grenzwert für DFW-Regeln für Host {transport_node_name} ist im Begriff, den maximalen Grenzwert zu überschreiten. “

Bei Auflösung des Ereignisses: „Der Grenzwert für DFW-Regeln für den Host {transport_node_name} ist unter den maximalen Grenzwert gefallen. “

Melden Sie sich beim ESX-Host {transport_node_name} an und rufen Sie den NSX-CLI-Befehl get firewall rule-stats total auf, um die Regelstatistik für Regeln anzuzeigen, die auf dem ESX-Host {transport_node_name} konfiguriert sind. Reduzieren Sie die Anzahl der für Host-{entity_id} konfigurierten Regeln. Überprüfen Sie die Anzahl der für verschiedene VIFs konfigurierten Regeln mithilfe des NSX-CLI-Befehls get firewall &ltVIF_UUID&gt ruleset rules. Reduzieren Sie die Anzahl der für verschiedene VIFs konfigurierten Regeln.

Der Grenzwert für DFW-Regeln pro Host nähert sich dem maximalen Grenzwert.

Bei Erkennung des Ereignisses: „Der Grenzwert für DFW-Regeln für Host {transport_node_name} nähert sich dem maximalen Grenzwert. “

Bei Auflösung des Ereignisses: „Der Grenzwert für DFW-Regeln für Host {transport_node_name} ist unter den Schwellenwert gefallen. “

Melden Sie sich beim ESX-Host {transport_node_name} an und rufen Sie den NSX-CLI-Befehl get firewall rule-stats total auf, um die Regelstatistik für Regeln anzuzeigen, die auf dem ESX-Host {transport_node_name} konfiguriert sind. Reduzieren Sie die Anzahl der für Host-{entity_id} konfigurierten Regeln. Überprüfen Sie die Anzahl der für verschiedene VIFs konfigurierten Regeln mithilfe des NSX-CLI-Befehls get firewall &ltVIF_UUID&gt ruleset rules. Reduzieren Sie die Anzahl der für verschiedene VIFs konfigurierten Regeln.

Die maximale Anzahl der Eindringereignisse wurde erreicht.

Bei Erkennung des Ereignisses: „Die Anzahl der Eindringereignisse im System beläuft sich auf {ids_events_count} und liegt somit über dem maximal zulässigen Wert von {max_ids_events_allowed}. “

Bei Auflösung des Ereignisses: „Die Anzahl der Eindringereignisse im System hat {ids_events_count} erreicht, und ist damit kleiner als der maximal zulässige Wert von {max_ids_events_allowed}. “

Hierzu ist kein manueller Eingriff erforderlich. Ein Löschauftrag wird automatisch alle 3 Minuten gestartet und löscht 10 % der älteren Datensätze, um die Gesamtzahl der Eindringereignisse im System unter den Schwellenwert von 1,5 Millionen Ereignissen zu bringen.

Die Arbeitsspeichernutzung der NSX-IDPS-Engine hat 75% oder höher erreicht.

Bei Erkennung des Ereignisses: „Die Arbeitsspeichernutzung der NSX-IDPS-Engine hat {system_resource_usage} % erreicht und ist damit größer als der oder gleich dem Schwellenwert für die hohe Nutzung von 75 %. “

Bei Auflösung des Ereignisses: „Die Arbeitsspeichernutzung der NSX-IDPS-Engine hat {system_resource_usage} % erreicht, und ist damit kleiner als der Schwellenwert für die hohe Nutzung von 75 %. “

Erwägen Sie, die Arbeitslasten der VM auf diesem Host erneut auf andere Hosts auszugleichen.

Die Arbeitsspeichernutzung der NSX-IDPS-Engine auf DPU hat 75 % oder mehr erreicht.

Bei Erkennung des Ereignisses: „Die Arbeitsspeichernutzung der NSX-IDPS-Engine hat {system_resource_usage} % erreicht und ist damit größer als der oder gleich dem Schwellenwert für die hohe Nutzung von 75 % auf DPU{dpu_id}. “

Bei Auflösung des Ereignisses: „Die Arbeitsspeichernutzung der NSX-IDPS-Engine hat auf der DPU {dpu_id} {system_resource_usage} % erreicht, und ist damit kleiner als der Schwellenwert für die hohe Nutzung von 75 %. “

Erwägen Sie, die Arbeitslasten der VM auf diesem Host erneut auf andere Hosts auszugleichen.

Die Arbeitsspeichernutzung der NSX-IDPS-Engine hat 85 % oder höher erreicht.

Bei Erkennung des Ereignisses: „Die Arbeitsspeichernutzung der NSX-IDPS-Engine hat {system_resource_usage} % erreicht und ist damit größer als der oder gleich dem Schwellenwert für die mittelhohe Nutzung von 85 %. “

Bei Auflösung des Ereignisses: „Die Arbeitsspeichernutzung der NSX-IDPS-Engine hat {system_resource_usage} % erreicht, und ist damit kleiner als der Schwellenwert für die mittelhohe Nutzung von 85 %. “

Erwägen Sie, die Arbeitslasten der VM auf diesem Host erneut auf andere Hosts auszugleichen.

Die Arbeitsspeichernutzung der NSX-IDPS-Engine auf DPU hat 85 % oder mehr erreicht.

Bei Erkennung des Ereignisses: „Die Arbeitsspeichernutzung der NSX-IDPS-Engine hat {system_resource_usage} % erreicht und ist damit größer als der oder gleich dem Schwellenwert für die mittelhohe Nutzung von 85 % auf DPU {dpu_id}. “

Bei Auflösung des Ereignisses: „Die Arbeitsspeichernutzung der NSX-IDPS-Engine hat auf der DPU {dpu_id} {system_resource_usage} % erreicht, und ist damit kleiner als der Schwellenwert für die mittelhohe Nutzung von 85 %. “

Erwägen Sie, die Arbeitslasten der VM auf diesem Host erneut auf andere Hosts auszugleichen.

Die Arbeitsspeichernutzung der NSX-IDPS-Engine hat 95 % oder höher erreicht.

Bei Erkennung des Ereignisses: „Die Arbeitsspeichernutzung der NSX-IDPS-Engine hat {system_resource_usage} % erreicht und ist damit größer als der oder gleich dem Schwellenwert für die sehr hohe Nutzung von 95 %. “

Bei Auflösung des Ereignisses: „Die Arbeitsspeichernutzung der NSX-IDPS-Engine hat {system_resource_usage} % erreicht, und ist damit kleiner als der Schwellenwert für die sehr hohe Nutzung von 95 %. “

Erwägen Sie, die Arbeitslasten der VM auf diesem Host erneut auf andere Hosts auszugleichen.

Die Arbeitsspeichernutzung der NSX-IDPS-Engine auf DPU hat 95 % oder mehr erreicht.

Bei Erkennung des Ereignisses: „Die Arbeitsspeichernutzung der NSX-IDPS-Engine hat {system_resource_usage} % erreicht und ist damit größer als der oder gleich dem Schwellenwert für die sehr hohe Nutzung von 95 % auf DPU {dpu_id}. “

Bei Auflösung des Ereignisses: „Die Arbeitsspeichernutzung der NSX-IDPS-Engine hat auf der DPU {dpu_id} {system_resource_usage} % erreicht, und ist damit kleiner als der Schwellenwert für die sehr hohe Nutzung von 95 %. “

Erwägen Sie, die Arbeitslasten der VM auf diesem Host erneut auf andere Hosts auszugleichen.

Die CPU-Auslastung der NSX-IDPS-Engine hat 75 % oder höher erreicht.

Bei Erkennung des Ereignisses: „Die CPU-Auslastung der NSX-IDPS-Engine hat {system_resource_usage} % erreicht und ist damit größer als der oder gleich dem Schwellenwert für die hohe Nutzung von 75 %. “

Bei Auflösung des Ereignisses: „Die CPU-Auslastung der NSX-IDPS-Engine hat {system_resource_usage} % erreicht, und ist damit kleiner als der Schwellenwert für die hohe Nutzung von 75 %. “

Erwägen Sie, die Arbeitslasten der VM auf diesem Host erneut auf andere Hosts auszugleichen.

Die CPU-Auslastung der NSX-IDPS-Engine hat 85 % oder höher erreicht.

Bei Erkennung des Ereignisses: „Die CPU-Auslastung der NSX-IDPS-Engine hat {system_resource_usage} % erreicht und ist damit größer als der oder gleich dem Schwellenwert für die mittelhohe Nutzung von 85 %. “

Bei Auflösung des Ereignisses: „Die CPU-Auslastung der NSX-IDPS-Engine hat {system_resource_usage} % erreicht, und ist damit kleiner als der Schwellenwert für die mittelhohe Nutzung von 85 %. “

Erwägen Sie, die Arbeitslasten der VM auf diesem Host erneut auf andere Hosts auszugleichen.

Die CPU-Nutzung der NSX-IDPS-Engine hat 95 % oder höher überschritten.

Bei Erkennung des Ereignisses: „Die CPU-Auslastung der NSX-IDPS-Engine hat {system_resource_usage} % erreicht und ist damit größer als der oder gleich dem Schwellenwert für die mittelhohe Nutzung von 95 %. “

Bei Auflösung des Ereignisses: „Die CPU-Auslastung der NSX-IDPS-Engine hat {system_resource_usage} % erreicht, und ist damit kleiner als der Schwellenwert für die sehr hohe Nutzung von 95 %. “

Erwägen Sie, die Arbeitslasten der VM auf diesem Host erneut auf andere Hosts auszugleichen.

NSX-IDPS wurde über eine NSX-Richtlinie aktiviert und IDPS-Regeln sind konfiguriert, die NSX-IDPS-Engine ist aber inaktiv.

Bei Erkennung des Ereignisses: „NSX-IDPS wurde über eine NSX-Richtlinie aktiviert und IDPS-Regeln sind konfiguriert, die NSX-IDPS-Engine ist aber inaktiv. “

Bei Auflösung des Ereignisses: „Auf NSX-IDPS trifft einer der folgenden Fälle zu: 1. NSX-IDPS ist über NSX-Richtlinie deaktiviert. 2. Die NSX-IDPS-Engine ist aktiviert, die NSX-IDPS-Engine und vdpi sind aktiv und NSX-IDPS wurde aktiviert, und IDPS-Regeln wurden über die NSX-Richtlinie konfiguriert. “

1. Überprüfen Sie /var/log/nsx-syslog.log, um festzustellen, ob Fehler gemeldet wurden.
2. Führen Sie den NSX-CLI-Befehl get ids engine status aus, um zu prüfen, ob sich NSX Distributed IDPS im Zustand „Deaktiviert“ befindet. Falls ja, führen Sie /etc/init.d/nsx-idps start aus, um den Dienst zu starten.
3. Führen Sie /etc/init.d/nsx-vdpi status aus, um zu prüfen, ob NSX-VDPI ausgeführt wird. Falls nein, führen Sie /etc/init.d/nsx-vdpi start aus, um den Dienst zu starten.

NSX-IDPS wurde über eine NSX-Richtlinie aktiviert und IDPS-Regeln sind konfiguriert, die NSX-IDPS-Engine auf DPU ist aber inaktiv.

Bei Erkennung des Ereignisses: „NSX-IDPS wurde über eine NSX-Richtlinie aktiviert und IDPS-Regeln sind konfiguriert, die NSX-IDPS-Engine auf DPU {dpu_id} ist aber inaktiv. “

Bei Auflösung des Ereignisses: „Auf NSX-IDPS trifft auf DPU {dpu_id} einer der folgenden Fälle zu. 1. NSX-IDPS ist über NSX-Richtlinie deaktiviert. 2. Die NSX-IDPS-Engine ist aktiviert, die NSX-IDPS-Engine und vdpi sind aktiv und NSX-IDPS wurde aktiviert, und IDPS-Regeln wurden über die NSX-Richtlinie konfiguriert. “

1. Überprüfen Sie in /var/log/nsx-idps/nsx-idps.log und /var/log/nsx-syslog.log, ob Fehler gemeldet wurden.
2. Führen Sie den NSX-CLI-Befehl get ids engine status aus, um zu prüfen, ob sich NSX Distributed IDPS im Zustand „Deaktiviert“ befindet. Falls ja, führen Sie /etc/init.d/nsx-idps start aus, um den Dienst zu starten.
3. Führen Sie /etc/init.d/nsx-vdpi status aus, um zu prüfen, ob NSX-VDPI ausgeführt wird. Falls nein, führen Sie /etc/init.d/nsx-vdpi start aus, um den Dienst zu starten.

Die CPU-Auslastung für die verteilte IDPS-Engine ist hoch.

Bei Erkennung des Ereignisses: „Die CPU-Auslastung für die verteilte IDPS-Engine ist damit größer als der oder gleich dem Schwellenwert für eine hohe Nutzung von {system_usage_threshold} %. “

Bei Auflösung des Ereignisses: „Die CPU-Auslastung für die verteilte IDPS-Engine ist kleiner als der Schwellenwert für eine hohe Nutzung von {system_usage_threshold} %. “

Überprüfen Sie den Grund für die Abonnementüberschreitung. Verschieben Sie bestimmte Anwendungen auf einen anderen Host.

Die CPU-Auslastung für die verteilte IDPS-Engine ist sehr hoch.

Bei Erkennung des Ereignisses: „Die CPU-Auslastung für die verteilte IDPS-Engine ist damit größer als der oder gleich dem Schwellenwert für eine sehr hohe Nutzung von {system_usage_threshold} %. “

Bei Auflösung des Ereignisses: „Die CPU-Auslastung für die verteilte IDPS-Engine ist kleiner als der Schwellenwert für eine sehr hohe Nutzung von {system_usage_threshold} %. “

Überprüfen Sie den Grund für die Abonnementüberschreitung. Verschieben Sie bestimmte Anwendungen auf einen anderen Host.

Die Netzwerknutzung für die verteilte IDPS-Engine ist hoch.

Bei Erkennung des Ereignisses: „Die Netzwerknutzung für die verteilte IDPS-Engine ist damit größer als der oder gleich dem Schwellenwert für eine hohe Nutzung von {system_usage_threshold} %. “

Bei Auflösung des Ereignisses: „Die Netzwerknutzung für die verteilte IDPS-Engine ist kleiner als der Schwellenwert für eine hohe Nutzung von {system_usage_threshold} %. “

Überprüfen Sie den Grund für die Abonnementüberschreitung. Überprüfen Sie die IDPS-Regeln, um die Menge des Datenverkehrs zu reduzieren, der dem IDPS-Dienst unterliegt.

Die Netzwerknutzung für die verteilte IDPS-Engine ist sehr hoch.

Bei Erkennung des Ereignisses: „Die Netzwerknutzung für die verteilte IDPS-Engine ist damit größer als der oder gleich dem Schwellenwert für eine sehr hohe Nutzung von {system_usage_threshold} %. “

Bei Auflösung des Ereignisses: „Die Netzwerknutzung für die verteilte IDPS-Engine ist kleiner als der Schwellenwert für eine sehr hohe Nutzung von{system_usage_threshold} %. “

Überprüfen Sie den Grund für die Abonnementüberschreitung. Überprüfen Sie die IDPS-Regeln, um die Menge des Datenverkehrs zu reduzieren, der dem IDPS-Dienst unterliegt.

Die verteilte IDPS-Engine hat den Datenverkehr aufgrund einer CPU-Abonnementüberschreitung verworfen.

Bei Erkennung des Ereignisses: „Die IDPS-Engine verfügt über unzureichende CPU-Ressourcen und kann nicht mit dem eingehenden Datenverkehr Schritt halten, was dazu führt, dass übermäßiger Datenverkehr verworfen wird. Melden Sie sich für weitere Details beim ESX-Host an, führen Sie den Befehl vsipioctl getdpiinfo -s aus und sehen Sie sich die Statistik für die Abonnementüberschreitung an. “

Bei Auflösung des Ereignisses: „Die verteilte IDPS-Engine verfügt über ausreichende CPU-Ressourcen und verwirft keinen Datenverkehr. “

Überprüfen Sie den Grund für die Abonnementüberschreitung. Verschieben Sie bestimmte Anwendungen auf einen anderen Host.

Die verteilte IDPS-Engine hat den Datenverkehr aufgrund einer Netzwerkabonnementüberschreibung verworfen.

Bei Erkennung des Ereignisses: „Die IDPS-Engine kann nicht mit dem eingehenden Datenverkehr Schritt halten, was dazu führt, dass übermäßiger Datenverkehr verworfen wird. Melden Sie sich für weitere Details beim ESX-Host an und führen Sie den folgenden Befehl aus: vsipioctl getdpiinfo -s und sehen Sie sich die Statistik für die Abonnementüberschreitung an. “

Bei Auflösung des Ereignisses: „Die verteilte IDPS-Engine verwirft keinen Datenverkehr. “

Überprüfen Sie den Grund für die Abonnementüberschreitung. Überprüfen Sie die IDPS-Regeln, um die Menge des Datenverkehrs zu reduzieren, der dem IDPS-Dienst unterliegt.

Die verteilte IDPS-Engine hat den Datenverkehr aufgrund einer CPU-Abonnementüberschreitung umgangen.

Bei Erkennung des Ereignisses: „Die IDPS-Engine verfügt über unzureichende CPU-Ressourcen und kann nicht mit dem eingehenden Datenverkehr Schritt halten, was dazu führt, dass übermäßiger Datenverkehr umgangen wird. Melden Sie sich für weitere Details beim ESX-Host an und führen Sie den folgenden Befehl aus: vsipioctl getdpiinfo -s und sehen Sie sich die Statistik für die Abonnementüberschreitung an. “

Bei Auflösung des Ereignisses: „Die verteilte IDPS-Engine verfügt über ausreichende CPU-Ressourcen und umgeht keinen Datenverkehr. “

Überprüfen Sie den Grund für die Abonnementüberschreitung. Verschieben Sie bestimmte Anwendungen auf einen anderen Host.

Die verteilte IDPS-Engine hat den Datenverkehr aufgrund einer Netzwerkabonnementüberschreitung umgangen.

Bei Erkennung des Ereignisses: „Die IDPS-Engine kann nicht mit dem eingehenden Datenverkehr Schritt halten, was dazu führt, dass übermäßiger Datenverkehr umgangen wird. Melden Sie sich für weitere Details beim ESX-Host an, führen Sie den Befehl vsipioctl getdpiinfo -s aus und sehen Sie sich die Statistik für die Abonnementüberschreitung an. “

Bei Auflösung des Ereignisses: „Die verteilte IDPS-Engine umgeht keinen Datenverkehr. “

Überprüfen Sie den Grund für die Abonnementüberschreitung. Überprüfen Sie die IDPS-Regeln, um die Menge des Datenverkehrs zu reduzieren, der dem IDPS-Dienst unterliegt.

Eine DNS-Weiterleitung ist ausgefallen.

Bei Erkennung des Ereignisses: „DNS-Weiterleitung {entity_id} wird nicht ausgeführt. Dies wirkt sich auf die angegebene DNS-Weiterleitung aus, die derzeit aktiviert ist. “

Bei Auflösung des Ereignisses: „DNS Weiterleitung {entity_id} wird erneut ausgeführt. “

1. Rufen Sie den NSX-CLI-Befehl get dns-forwarders status auf, um zu überprüfen, ob die DNS-Weiterleitung den Status „inaktiv“ aufweist.
2. Überprüfen Sie /var/log/syslog, um festzustellen, ob Fehler gemeldet wurden.
3. Erfassen Sie ein Support-Paket und wenden Sie sich an das NSX-Supportteam.

Eine DNS-Weiterleitung ist deaktiviert.

Bei Erkennung des Ereignisses: „DNS-Weiterleitung {entity_id} ist deaktiviert. “

Bei Auflösung des Ereignisses: „DNS-Weiterleitung {entity_id} ist aktiviert. “

1. Rufen Sie den NSX-CLI-Befehl get dns-forwarders status auf, um zu überprüfen, ob die DNS-Weiterleitung den Status „deaktiviert“ aufweist.
2. Verwenden Sie NSX-Richtlinien-API oder Manager-API, um die DNS-Weiterleitung zu aktivieren, die sich nicht im deaktivierten Zustand befinden sollte.

Bei einem DNS-Weiterleitungs-Upstream-Server ist eine Zeitüberschreitung aufgetreten.

Bei Erkennung des Ereignisses: „DNS-Weiterleitung {intent_path}({dns_id}) erhielt keine rechtzeitige Antwort vom Upstream-Server {dns_upstream_ip}. Die Konnektivität der Computing-Instanz zu FQDNs mit Zeitüberschreitung kann beeinträchtigt werden. “

Bei Auflösung des Ereignisses: „Upstream-Server {dns_upstream_ip} der Weiterleitung {intent_path}({dns_id}) ist normal. “

1. Rufen Sie die NSX API GET /api/v1/dns/forwarders/{dns_id}/nslookup? Address=&ltaddress&gt&server_ip={dns_upstream_ip}&source_ip=&ltsource_ip&gt.{dns_upstream_ip}&source_ip=&ltsource_ip&gt auf. Diese API-Anfrage löst ein DNS-Lookup zum Upstream-Server im Netzwerk-Namespace der DNS-Weiterleitung aus. &ltaddress&gt ist die IP-Adresse oder der FQDN in derselben Domäne wie der Upstream-Server. &ltsource_ip&gt ist eine IP-Adresse in der Upstream-Serverzone. Wenn die API eine Zeitüberschreitungsantwort für die Verbindung zurückgibt, liegt wahrscheinlich ein Netzwerkfehler oder ein Upstream-Serverproblem vor. Überprüfen Sie, warum DSN-Lookups den Upstream-Server nicht erreichen können oder warum der Upstream-Server keine Antwort zurückgibt. Wenn die API-Antwort anzeigt, dass der Upstream-Server antwortet, fahren Sie mit Schritt 2 fort.
2. Rufen Sie die NSX API GET /api/v1/dns/forwarders/{dns_id}/nslookup? address=&ltaddress&gt auf. Diese API-Anfrage löst ein DNS-Lookup für die DNS-Weiterleitung aus. Wenn die API eine gültige Antwort zurückgibt, wurde der Upstream-Server möglicherweise wiederhergestellt und dieser Alarm sollte innerhalb weniger Minuten behoben sein. Wenn die API eine Antwort über eine Zeitüberschreitung der Verbindung zurückgibt, fahren Sie mit Schritt 3 fort.
3. Rufen Sie den NSX-CLI-Befehl „get dns-forwarder {dns_id} live-debug server-ip {dns_upstream_ip}“ auf. Dieser Befehl löst Live-Debugging auf dem Upstream-Server aus und protokolliert Details und Statistiken, die anzeigen, warum die DNS-Weiterleitung keine Antwort erhält.

Edge-Knoten-Einstellungen stimmen nicht überein.

Bei Erkennung des Ereignisses: „Die Konfiguration der Einstellungen für den Edge-Knoten {entity_id} stimmt nicht mit der Konfiguration der Richtlinienabsicht überein. Die Edge-Knotenkonfiguration, die dem Benutzer in der Benutzeroberfläche oder der API angezeigt wird, ist nicht mit der realisierten Konfiguration identisch. Die realisierten Edge-Knotenänderungen, die vom Benutzer außerhalb von NSX Manager vorgenommen wurden, werden in den Details dieses Alarms angezeigt, und alle Bearbeitungen in der Benutzeroberfläche oder API überschreiben die realisierte Konfiguration. Felder, die sich für den Edge-Knoten unterscheiden, werden in den Laufzeitdaten aufgelistet {edge_node_setting_mismatch_reason}“

Bei Auflösung des Ereignisses: „Die Knoteneinstellungen von Edge-Knoten {entity_id} stimmen jetzt mit der Richtlinienabsicht überein. “

Überprüfen Sie die Knoteneinstellungen dieses Edge-Transportknotens {entity_id}. Führen Sie eine der folgenden Aktionen aus, um Alarm -
1 zu beheben. Aktualisieren Sie die Richtlinienabsicht für die Edge-Transportknoteneinstellung manuell mithilfe der API PUT https://&ltmanager-ip&gt/api/v1/transport-nodes/&lttn-id&gt.
2. Akzeptieren Sie Intent-basierte oder realisierte Edge-Knoteneinstellungen für diesen Edge-Transportknoten über den Edge-Transportknoten-Resolver, um diesen Alarm zu beheben.
3. Lösen Sie den Alarm auf, indem Sie die Konfiguration des Edge-Knotens mithilfe von refresh API POST https://&ltmanager-ip&gt/api/v1/transport-nodes/&lttn-id&gt?action=refresh_node_configuration&resource_type=EdgeNode akzeptieren.

vSphere-Einstellungen der Edge-VM stimmen nicht überein.

Bei Erkennung des Ereignisses: „Die Konfiguration des Edge-Knotens {entity_id} auf vSphere stimmt nicht mit der Konfiguration der Richtlinienabsicht überein. Die Edge-Knotenkonfiguration, die dem Benutzer in der Benutzeroberfläche oder der API angezeigt wird, ist nicht mit der realisierten Konfiguration identisch. Die realisierten Edge-Knotenänderungen, die vom Benutzer außerhalb von NSX Manager vorgenommen wurden, werden in den Details dieses Alarms angezeigt, und alle Bearbeitungen in der Benutzeroberfläche oder API überschreiben die realisierte Konfiguration. Felder, die sich für den Edge-Knoten unterscheiden, werden in den Laufzeitdaten aufgelistet {edge_vm_vsphere_settings_mismatch_reason}“

Bei Auflösung des Ereignisses: „Die VM-vSphere-Einstellungen für Edge-Knoten {entity_id} stimmen jetzt mit der Richtlinienabsicht überein. “

Überprüfen Sie die vSphere-Konfiguration dieses Edge-Transportknotens {entity_id}. Führen Sie eine der folgenden Aktionen aus, um Alarm -
1 zu beheben. Akzeptieren Sie Intent-basierte oder vSphere-realisierte Edge-Knotenkonfiguration für diesen Edge-Transportknoten über den Edge-Transportknoten-Resolver, um diesen Alarm zu beheben.
2. Lösen Sie den Alarm auf, indem Sie die Edge-Knoten-vSphere-realisierte Konfiguration mithilfe von refresh API POST https://&ltmanager-ip&gt/api/v1/transport-nodes/&lttn-id&gt?action=refresh_node_configuration&resource_type=EdgeNode akzeptieren.

Edge-Knoten- und vSphere-Einstellungen werden geändert.

Bei Erkennung des Ereignisses: „Die Einstellungen und die vSphere-Konfiguration für den Edge-Knoten {entity_id} werden geändert und stimmen nicht mit der Konfiguration der Richtlinienabsicht überein. Die Edge-Knotenkonfiguration, die dem Benutzer in der Benutzeroberfläche oder der API angezeigt wird, ist nicht mit der realisierten Konfiguration identisch. Die realisierten Edge-Knotenänderungen, die vom Benutzer außerhalb von NSX Manager vorgenommen wurden, werden in den Details dieses Alarms angezeigt, und alle Bearbeitungen in der Benutzeroberfläche oder API überschreiben die realisierte Konfiguration. Felder, die sich für Edge-Knoteneinstellungen und vSphere-Konfiguration unterscheiden, werden in den Laufzeitdaten aufgeführt {Edge_node_settings_and_vsphere_settings_mismatch_reason}“

Bei Auflösung des Ereignisses: „Die Knoteneinstellungen für Edge-Knoten {entity_id} und die vSphere-Einstellungen stimmen jetzt mit der Richtlinienabsicht überein. “

Überprüfen Sie die Knoteneinstellungen und die vSphere-Konfiguration dieses Edge-Transportknotens {entity_id}. Führen Sie eine der folgenden Aktionen aus, um Alarm -
1 zu beheben. Aktualisieren Sie die Richtlinienabsicht für die Edge-Transportknoteneinstellung manuell mithilfe der API: PUT https://&ltmanager-ip&gt/api/v1/transport-nodes/&lttn-id&gt.
2. Akzeptieren Sie die Intent- oder vSphere-realisierte Edge-Knotenkonfiguration oder realisierten Edge-Knoteneinstellungen für diesen Edge-Transportknoten über den Edge-Transportknoten-Resolver, um diesen Alarm aufzulösen.
3. Lösen Sie den Alarm auf, indem Sie die Edge-Knoteneinstellungen und vSphere-realisierte Konfiguration mithilfe von refresh API POST https://&ltmanager-ip&gt/api/v1/transport-nodes/&lttn-id&gt?action=refresh_node_configuration&resource_type=EdgeNode akzeptieren.

Nichtübereinstimmung bei Edge-vSphere-Speicherort.

Bei Erkennung des Ereignisses: „Der Edge-Knoten {entity_id} wurde mithilfe von vMotion verschoben. Die Konfiguration des Edge-Knotens {entity_id} auf vSphere stimmt nicht mit der Konfiguration der Richtlinienabsicht überein. Die Edge-Knotenkonfiguration, die dem Benutzer in der Benutzeroberfläche oder der API angezeigt wird, ist nicht mit der realisierten Konfiguration identisch. Die realisierten Änderungen am Edge-Knoten, die vom Benutzer außerhalb von NSX Manager vorgenommen wurden, werden in den Details dieses Alarms angezeigt. Felder, die sich für den Edge-Knoten unterscheiden, werden in den Laufzeitdaten aufgelistet {edge_vsphere_location_mismatch_reason}“

Bei Auflösung des Ereignisses: „Die Knoten-vSphere-Einstellungen für Edge-Knoten {entity_id} stimmen jetzt mit der Richtlinienabsicht überein. “

Überprüfen Sie die vSphere-Konfiguration dieses Edge-Transportknotens {entity_id}. Führen Sie eine der folgenden Aktionen aus, um Alarm -
1 zu beheben. Lösen Sie den Alarm auf, indem Sie die Edge-Knoten-vSphere-realisierte Konfiguration mithilfe von refresh API POST https://&ltmanager-ip&gt/api/v1/transport-nodes/&lttn-id&gt?action=refresh_node_configuration&resource_type=EdgeNode akzeptieren.
2. Wenn Sie zum vorherigen Speicherort zurückkehren möchten, verwenden Sie NSX Redeploy API POST https://&ltmanager-ip&gt/api/v1/transport-nodes/&lttn-id&gt?action=redeploy. vMotion zurück zum ursprünglichen Host wird nicht unterstützt.

Die automatische Edge-VM ist in der NSX-Bestandsliste, aber nicht in vCenter vorhanden.

Bei Erkennung des Ereignisses: „Für die VM {policy_edge_vm_name} mit der MoRef-ID {vm_moref_id}, die dem Edge-Transportknoten {entity_id} entspricht, wurden die vSphere-Platzierungsparameter in der NSX-Bestandsliste, aber nicht in vCenter gefunden. Überprüfen Sie, ob die VM in vCenter entfernt wurde oder mit einer anderen MoRef-ID vorhanden ist.“

Bei Auflösung des Ereignisses: „Der Edge-Knoten {entity_id} mit der VM-MoRef-ID {vm_moref_id} ist sowohl in der NSX-Bestandsliste als auch in vCenter vorhanden. “

Die MoRef-ID der Referenz auf ein verwaltetes Objekt einer VM liegt im Format „vm-number“ vor, das beim Auswählen der Edge-VM auf der vCenter-Benutzeroberfläche in der URL angezeigt wird. Beispiel: vm-12011 in https://&ltvc-url>/ui/app/vm;nav=h/urn:vmomi:VirtualMachine:vm-12011:164ff798-c4f1-495b-a0be-adfba337e5d2/summary. Suchen Sie die VM {policy_edge_vm_name} mit der MoRef-ID {vm_moref_id} für den Edge-Transportknoten {entity_id} in vCenter. Wenn die Edge-VM in vCenter mit einer anderen MoRef-ID vorhanden ist, führen Sie die folgende Aktion aus. Verwenden Sie die NSX API für das Hinzufügen oder Aktualisieren der Platzierung mit JSON Request Payload mit den Propertys vm_id und vm_deployment_config, um die neue MoRef-ID und die vSphere-Bereitstellungsparameter zu aktualisieren. POST https://&ltmanager-ip&gt/api/v1/transport-nodes/&lttn-id&gt?action=addOrUpdatePlacementReferences. Wenn die Edge-VM {policy_edge_vm_name} nicht in vCenter vorhanden ist, verwenden Sie die NSX API für das erneute Bereitstellen einer neuen VM für den Edge-Knoten. POST https://&ltmanager-ip&gt/api/v1/transport-nodes/&lttn-id&gt?action=redeploy.

Die automatische Edge-VM ist weder in der NSX-Bestandsliste noch in vCenter vorhanden.

Bei Erkennung des Ereignisses: „Für die VM {policy_edge_vm_name} mit der MoRef-ID {vm_moref_id}, die dem Edge-Transportknoten {entity_id} entspricht, wurden die vSphere-Platzierungsparameter weder in der NSX-Bestandsliste noch in vCenter gefunden. Die Platzierungsparameter in der vSphere-Konfiguration des Edge-Transportknotens {entity_id} beziehen sich auf die VM mit der MoRef-ID {vm_moref_id}. “

Bei Auflösung des Ereignisses: „Der Edge-Knoten {entity_id} mit der VM-MoRef-ID {vm_moref_id} ist sowohl in der NSX-Bestandsliste als auch in vCenter vorhanden. “

Die MoRef-ID der Referenz auf ein verwaltetes Objekt einer VM liegt im Format „vm-number“ vor, das beim Auswählen der Edge-VM auf der vCenter-Benutzeroberfläche in der URL angezeigt wird. Beispiel: vm-12011 in https://&ltvc-url>/ui/app/vm;nav=h/urn:vmomi:VirtualMachine:vm-12011:164ff798-c4f1-495b-a0be-adfba337e5d2/summary. Suchen Sie die VM {policy_edge_vm_name} mit der MoRef-ID {vm_moref_id} für den Edge-Transportknoten {entity_id} in vCenter. Führen Sie die folgende Aktion aus, um den Alarm aufzulösen. Prüfen Sie, ob die VM in vSphere gelöscht wurde oder mit einer anderen MoRef-ID vorhanden ist.
1. Wenn die VM weiterhin in vCenter vorhanden ist, versetzen Sie den Edge-Transportknoten in den Wartungsmodus und schalten Sie dann die Edge-VM in vCenter aus und löschen Sie sie. Verwenden Sie die NSX API für das erneute Bereitstellen, um eine neue VM für den Edge-Knoten bereitzustellen. Der Datenverkehr für den Edge-Transportknoten wird in der Zwischenzeit unterbrochen, wenn die Edge-VM Datenverkehr weiterleitet.
2. Wenn die VM nicht in vCenter vorhanden ist, verwenden Sie die API für das erneute Bereitstellen, um eine neue VM für den Edge-Knoten bereitzustellen. POST https://&ltmanager-ip&gt/api/v1/transport-nodes/&lttn-id&gt?action=redeploy.

Der Ausschalt- und Löschvorgang für die alte Edge-VM in vCenter ist während der erneuten Bereitstellung fehlgeschlagen.

Bei Erkennung des Ereignisses: „Fehler beim Ausschalten und Löschen der VM des Edge-Knotens {entity_id} mit der MoRef-ID {vm_moref_id} in vCenter während der erneuten Bereitstellung. Eine neue Edge-VM mit der MoRef-ID {new_vm_moref_id} wurde bereitgestellt. Es sind gleichzeitig sowohl alte als auch neue VMs für diesen Edge funktionsfähig, was zu IP-Konflikten und Netzwerkproblemen führen kann. “

Bei Auflösung des Ereignisses: „Der Edge-Knoten {entity_id} mit der veralteten VM-MoRef-ID {vm_moref_id} wurde sowohl in der NSX-Bestandsliste als auch in vCenter nicht mehr gefunden. Eine neu bereitgestellte VM mit der MoRef-ID {new_vm_moref_id} ist sowohl in der NSX-Bestandsliste als auch in vCenter vorhanden. “

Die MoRef-ID der Referenz auf ein verwaltetes Objekt einer VM liegt im Format „vm-number“ vor, das beim Auswählen der Edge-VM auf der vCenter-Benutzeroberfläche in der URL angezeigt wird. Beispiel: vm-12011 in https://&ltvc-url>/ui/app/vm;nav=h/urn:vmomi:VirtualMachine:vm-12011:164ff798-c4f1-495b-a0be-adfba337e5d2/summary. Suchen Sie die VM {policy_edge_vm_name} mit der MoRef-ID {vm_moref_id} für den Edge-Transportknoten {entity_id} in vCenter. Schalten Sie die alte Edge-VM {policy_edge_vm_name} mit der MoRef-ID {vm_moref_id} in vCenter aus und löschen Sie sie.

Der Edge-Knoten stimmt nicht mit der Hardwareversion überein.

Bei Erkennung des Ereignisses: „Der Edge-Knoten {transport_node_name} im Edge-Cluster {edge_cluster_name} verfügt über eine Hardwareversion {edge_tn_hw_version}, die kleiner ist als die höchste Hardwareversion {edge_cluster_highest_hw_version} im Edge-Cluster. “

Bei Auflösung des Ereignisses: „Das Problem der nicht übereinstimmenden Hardwareversion des Edge-Knotens {transport_node_name} wurde jetzt behoben. “

Bitte befolgen Sie den KB-Artikel, um den Alarm für eine nicht übereinstimmende Hardwareversion des Edge-Knotens {transport_node_name} zu beheben.

Alarm für Fehler bei Verlagerung des Edge-Clustermitglieds

Bei Erkennung des Ereignisses: „Der Vorgang auf dem Edge-Cluster {edge_cluster_id} zum Verlagern des gesamten Dienstkontexts ist für Edge-Cluster-Mitgliederindex {member_index_id} mit der Transportknoten-ID {transport_node_id} fehlgeschlagen“

Bei Auflösung des Ereignisses: „Edge-Knoten mit {transport_node_id}-Verlagerungsfehler wurde jetzt behoben. “

Überprüfen Sie die verfügbare Kapazität für den Edge-Cluster. Wenn mehr Kapazität erforderlich ist, skalieren Sie den Edge-Cluster. Wiederholen Sie den Vorgang zum Verlagern des Edge-Clustermitglieds.

Die CPU-Auslastung durch den Edge-Knoten ist sehr hoch.

Bei Erkennung des Ereignisses: „Die CPU-Auslastung auf dem Edge-Knoten {entity_id} hat {system_resource_usage} % erreicht und ist damit größer als der oder gleich dem Schwellenwert für eine sehr hohe Nutzung von {system_usage_threshold} %. “

Bei Auflösung des Ereignisses: „Die CPU-Auslastung auf dem Edge-Knoten {entity_id} hat {system_resource_usage} % erreicht, und ist damit kleiner als der Schwellenwert für eine sehr hohe Nutzung von {system_usage_threshold} %. “

Überprüfen Sie die Konfiguration, die Dienstausführung und die Dimensionierung dieses Edge-Knotens. Sie sollten für die jeweilige Arbeitslast eine Anpassung der Formfaktorgröße der Edge-Appliance oder die Neuverteilung von Diensten auf andere Edge-Knoten in Erwägung ziehen.

Die CPU-Auslastung durch den Edge-Knoten ist hoch.

Bei Erkennung des Ereignisses: „Die CPU-Auslastung auf dem Edge-Knoten {entity_id} hat {system_resource_usage} % erreicht und ist damit größer als der oder gleich dem Schwellenwert für eine hohe Nutzung von {system_usage_threshold} %. “

Bei Auflösung des Ereignisses: „Die CPU-Auslastung auf dem Edge-Knoten {entity_id} hat {system_resource_usage} % erreicht und ist damit kleiner als der Schwellenwert für eine hohe Nutzung von {system_usage_threshold} %. “

Überprüfen Sie die Konfiguration, die Dienstausführung und die Dimensionierung dieses Edge-Knotens. Sie sollten für die jeweilige Arbeitslast eine Anpassung der Formfaktorgröße der Edge-Appliance oder die Neuverteilung von Diensten auf andere Edge-Knoten in Erwägung ziehen.

Die Arbeitsspeichernutzung des Edge-Knotens ist sehr hoch.

Bei Erkennung des Ereignisses: „Die Arbeitsspeichernutzung auf dem Edge-Knoten {entity_id} hat {system_resource_usage} % erreicht und ist damit größer als der oder gleich dem Schwellenwert für eine sehr hohe Nutzung von {system_usage_threshold} %. “

Bei Auflösung des Ereignisses: „Die Arbeitsspeichernutzung auf dem Edge-Knoten {entity_id} hat {system_resource_usage} % erreicht, und ist damit kleiner als der Schwellenwert für eine sehr hohe Nutzung von {system_usage_threshold} %. “

Überprüfen Sie die Konfiguration, die Dienstausführung und die Dimensionierung dieses Edge-Knotens. Sie sollten für die jeweilige Arbeitslast eine Anpassung der Formfaktorgröße der Edge-Appliance oder die Neuverteilung von Diensten auf andere Edge-Knoten in Erwägung ziehen.

Die Arbeitsspeichernutzung des Edge-Knotens ist hoch.

Bei Erkennung des Ereignisses: „Die Arbeitsspeichernutzung auf dem Edge-Knoten {entity_id} hat {system_resource_usage} % erreicht und ist damit größer als der oder gleich dem Schwellenwert für eine hohe Nutzung von {system_usage_threshold} %. “

Bei Auflösung des Ereignisses: „Die Arbeitsspeichernutzung auf dem Edge-Knoten {entity_id} hat {system_resource_usage} % erreicht, und ist damit kleiner als der Schwellenwert für eine hohe Nutzung von {system_usage_threshold} %. “

Überprüfen Sie die Konfiguration, die Dienstausführung und die Dimensionierung dieses Edge-Knotens. Sie sollten für die jeweilige Arbeitslast eine Anpassung der Formfaktorgröße der Edge-Appliance oder die Neuverteilung von Diensten auf andere Edge-Knoten in Erwägung ziehen.

Die Festplattennutzung des Edge-Knotens ist sehr hoch.

Bei Erkennung des Ereignisses: „Die Festplattennutzung für die Edge-Knoten-Festplattenpartition {disk_partition_name} hat {system_resource_usage} % erreicht und ist damit größer als der oder gleich dem Schwellenwert für eine sehr hohe Nutzung von {system_usage_threshold} %. “

Bei Auflösung des Ereignisses: „Die Festplattennutzung für die Edge-Knoten-Festplattenpartition {disk_partition_name} hat {system_resource_usage} % erreicht, und ist damit kleiner als der Schwellenwert für eine sehr hohe Nutzung von {system_usage_threshold} %. “

Untersuchen Sie die Partition mit hoher Auslastung und prüfen Sie, ob unerwartete große Dateien vorhanden sind, die entfernt werden können.

Die Festplattennutzung des Edge-Knotens ist hoch.

Bei Erkennung des Ereignisses: „Die Festplattennutzung für die Edge-Knoten-Festplattenpartition {disk_partition_name} hat {system_resource_usage} % erreicht und ist damit größer als der oder gleich dem Schwellenwert für eine hohe Nutzung von {system_usage_threshold} %. “

Bei Auflösung des Ereignisses: „Die Festplattennutzung für die Edge-Knoten-Festplattenpartition {disk_partition_name} hat {system_resource_usage} % erreicht, und ist damit kleiner als der Schwellenwert für eine hohe Nutzung von {system_usage_threshold} %. “

Untersuchen Sie die Partition mit hoher Auslastung und prüfen Sie, ob unerwartete große Dateien vorhanden sind, die entfernt werden können.

Die CPU-Auslastung durch den Edge-Knoten-Datenpfad ist sehr hoch.

Bei Erkennung des Ereignisses: „Die CPU-Auslastung des Datenpfads auf dem Edge-Knoten {entity_id} hat {datapath_resource_usage} % erreicht und ist damit größer als der oder gleich dem Schwellenwert für eine sehr hohe Nutzung für mindestens zwei Minuten. “

Bei Auflösung des Ereignisses: „Die CPU-Auslastung auf dem Edge-Knoten {entity_id} ist unter den Schwellenwert für eine sehr hohe Nutzung gesunken. “

Überprüfen Sie die CPU-Statistik auf dem Edge-Knoten, indem Sie den NSX-CLI-Befehl get dataplane cpu stats aufrufen, um die Paketraten pro CPU-Kern zu sehen. Bei höheren Paketraten wird eine höhere CPU-Auslastung erwartet. Ziehen Sie eine Erhöhung der Formfaktorgröße der Edge-Appliance und eine Neuverteilung der Dienste auf diesem Edge-Knoten auf andere Edge-Knoten im selben Cluster oder auf andere Edge-Cluster in Erwägung.

Die CPU-Auslastung durch den Edge-Knoten-Datenpfad ist hoch.

Bei Erkennung des Ereignisses: „Die CPU-Auslastung des Datenpfads auf dem Edge-Knoten {entity_id} hat {datapath_resource_usage} % erreicht und ist damit mindestens zwei Minuten lang größer als der oder gleich dem Schwellenwert für eine hohe Nutzung. “

Bei Auflösung des Ereignisses: „Die CPU-Auslastung auf dem Edge-Knoten {entity_id} ist unter den Schwellenwert für eine hohe Nutzung gesunken. “

Überprüfen Sie die CPU-Statistik auf dem Edge-Knoten, indem Sie den NSX-CLI-Befehl get dataplane cpu stats aufrufen, um die Paketraten pro CPU-Kern zu sehen. Bei höheren Paketraten wird eine höhere CPU-Auslastung erwartet. Ziehen Sie eine Erhöhung der Formfaktorgröße der Edge-Appliance und eine Neuverteilung der Dienste auf diesem Edge-Knoten auf andere Edge-Knoten im selben Cluster oder auf andere Edge-Cluster in Erwägung.

Die Konfiguration des Edge-Knoten-Datenpfads ist fehlgeschlagen.

Bei Erkennung des Ereignisses: „Fehler beim Aktivieren des Datenpfads auf dem Edge-Knoten nach drei Versuchen. “

Bei Auflösung des Ereignisses: „Datenpfad auf dem Edge-Knoten wurde erfolgreich aktiviert. “

Stellen Sie sicher, dass die Konnektivität zwischen dem Edge-Knoten und dem Manager-Knoten fehlerfrei ist. Rufen Sie in der NSX-CLI des Edge-Knotens den Befehl get services auf, um den Zustand der Dienste zu überprüfen. Wenn der dataplane-Dienst angehalten ist, rufen Sie den Befehl start service dataplane auf, um ihn zu starten.

Der Crypto-Treiber des Edge-Knotens ist inaktiv.

Bei Erkennung des Ereignisses: „Der Crypto-Treiber des Edge-Knotens {edge_crypto_drv_name} ist inaktiv. “

Bei Auflösung des Ereignisses: Der Crypto-Treiber {edge_crypto_drv_name} des Edge-Knotens ist aktiv. “

Aktualisieren Sie den Edge-Knoten nach Bedarf.

Der Mempool des Edge-Knoten-Datenpfads ist hoch.

Bei Erkennung des Ereignisses: „Die Datenpfad-Mempool-Nutzung für {mempool_name} auf dem Edge-Knoten {entity_id} hat {system_resource_usage} % erreicht und ist damit größer als der oder gleich dem Schwellenwert für eine hohe Nutzung von {system_usage_threshold} %. “

Bei Auflösung des Ereignisses: Die Datenpfad-Mempool-Nutzung für {mempool_name} auf dem Edge-Knoten {entity_id} hat {system_resource_usage} % erreicht, und ist damit kleiner als der Schwellenwert für eine hohe Nutzung von {system_usage_threshold} %. “

Melden Sie sich als Root-Benutzer an und rufen Sie die Befehle edge-appctl -t /var/run/vmware/edge/dpd.ctl mempool/show und edge-appctl -t /var/run/vmware/edge/dpd.ctl memory/show malloc_heap auf, um die DPDK-Arbeitsspeicherauslastung zu überprüfen.

Die globale ARP-Tabellennutzung des Edge-Knotens ist hoch.

Bei Erkennung des Ereignisses: „Die globale ARP-Tabellennutzung auf dem Edge-Knoten {entity_id} hat {datapath_resource_usage} % erreicht und liegt damit über dem hohen Schwellenwert für eine hohe Nutzung für über zwei Minuten. “

Bei Auflösung des Ereignisses: „Die globale ARP-Tabellennutzung auf dem Edge-Knoten {entity_id} ist unter den Schwellenwert für eine hohe Nutzung gesunken. “

Melden Sie sich als Root-Benutzer an und rufen Sie den Befehl edge-appctl -t /var/run/vmware/edge/dpd.ctl neigh/show auf. Überprüfen Sie, ob die Neigh-Cache-Nutzung normal ist. Rufen Sie, sofern sie normal ist, edge-appctl -t /var/run/vmware/edge/dpd.ctl neigh/set_param max_entries auf, um die ARP-Tabellengröße zu erhöhen.

Die Netzwerkkarte des Edge-Knotens hat vorübergehend keine RX-Ringpuffer mehr.

Bei Erkennung des Ereignisses: „Empfangs-Ringpuffer der Edge-Netzwerkkarte {edge_nic_name} wurde um {rx_ring_buffer_overflow_percentage} % auf dem Edge-Knoten {entity_id} überschritten. Es wurden {rx_misses} Pakete verpasst und {rx_processed} verarbeitet. “

Bei Auflösung des Ereignisses: „Die Nutzung des Empfangs-Ringpuffers der Edge-Netzwerkkarte {edge_nic_name} auf dem Edge-Knoten {entity_id} weist keine Überschreitung mehr auf. “

Führen Sie den NSX-CLI-Befehl get dataplane cpu stats auf dem Edge-Knoten aus und überprüfen Sie Folgendes:
1. Wenn die CPU-Nutzung hoch (> 90 %) ist, führen Sie eine Paketerfassung auf der Schnittstelle mithilfe des Befehls „start capture interface &ltinterface-name&gt direction input or start capture interface &ltinterface-name&gt direction input core &ltcore-id&gt“ durch (um Pakete zu erfassen, die auf einem bestimmten Kern eingehen, dessen Nutzung hoch ist). Analysieren Sie dann die Erfassung, um zu überprüfen, ob die meisten fragmentierten Pakete oder IPSec-Pakete vorhanden sind. Wenn ja, handelt es sich um das erwartete Verhalten. Andernfalls ist der Datenpfad wahrscheinlich mit anderen Vorgängen beschäftigt. Wenn dieser Alarm länger als 2–3 Minuten dauert, wenden Sie sich an VMware Support.
2. Wenn die CPU-Auslastung nicht hoch ist, d. h. < 90 %, dann prüfen Sie mit dem Befehl get dataplane cpu stats, ob RX PPS hoch ist (nur um sicherzustellen, dass die Datenverkehrsrate ansteigt). Erhöhen Sie dann die Ringgröße um 1024 mit dem Befehl set dataplane ring-size rx . HINWEIS: Die kontinuierliche Erhöhung der Ringgröße um den Faktor 1024 kann zu Problemen mit der Leistung führen. Wenn das Problem auch nach der Erhöhung der Ringgröße weiterhin besteht, ist dies ein Hinweis darauf, dass Edge für den Datenverkehr eine größere Formfaktorbereitstellung benötigt.
3. Wenn der Alarm weiterhin schwankt, d. h. ausgelöst und schnell wieder gelöst wird, dann liegt dies an stoßartigem Datenverkehr. Überprüfen Sie in diesem Fall wie oben beschrieben, ob RX PPS während des aktiven Alarms nicht hoch ist, und wenden Sie sich an den VMware-Support. Wenn PPS hoch ist, bestätigt dies den stoßartigen Datenverkehr. Ziehen Sie in Betracht, den Alarm zu unterdrücken. HINWEIS: Es gibt keinen spezifischen Vergleichsindex, um zu entscheiden, was als hoher PPS-Wert angesehen wird. Dies hängt von der Infrastruktur und der Art des Datenverkehrs ab. Der Vergleich kann anhand von Notizen bei inaktivem und aktivem Alarm erfolgen.

Die Netzwerkkarte des Edge-Knotens hat vorübergehend keine TX-Ringpuffer mehr.

Bei Erkennung des Ereignisses: „Übertragungs-Ringpuffer der Edge-Netzwerkkarte {edge_nic_name} wurde um {tx_ring_buffer_overflow_percentage} % auf dem Edge-Knoten {entity_id} überschritten. Es wurden {tx_misses} Pakete verpasst und {tx_processed} verarbeitet. “

Bei Auflösung des Ereignisses: „Die Nutzung des Übertragungs-Ringpuffers der Edge-Netzwerkkarte {edge_nic_name} auf dem Edge-Knoten {entity_id} weist keine Überschreitung mehr auf. “

1. Wenn viele VMs zusammen mit Edge vom Hypervisor aufgenommen werden, hat die Edge-VM möglicherweise nicht genügend Zeit für die Ausführung, weshalb die Pakete möglicherweise nicht vom Hypervisor abgerufen werden. Dann wird die Edge-VM wahrscheinlich zu einem Host mit weniger VMs migriert.
2. Erhöhen Sie die Ringgröße um 1024 mit dem Befehl „set dataplane ring-size tx“ “. Wenn das Problem auch nach dem Erhöhen der Ringgröße weiterhin besteht, wenden Sie sich an den VMware Support, da der Übertragungs-Ringpuffer für die ESX-Seite möglicherweise einen niedrigeren Wert aufweist. Wenn es kein Problem auf ESX-Seite gibt, deutet dies darauf hin, dass der Edge auf eine Bereitstellung mit einem größeren Formfaktor skaliert werden muss, um dem Datenverkehr gerecht zu werden.
3. Wenn der Alarm weiterhin schwankt, d. h. ausgelöst und schnell wieder gelöst wird, dann liegt dies an stoßartigem Datenverkehr. Überprüfen Sie TX-PPS in diesem Fall mit dem Befehl get dataplane cpu stats. Wenn RX PPS während des aktiven Alarms nicht hoch ist, wenden Sie sich an den VMware Support. Wenn PPS hoch ist, bestätigt dies den stoßartigen Datenverkehr. Ziehen Sie in Betracht, den Alarm zu unterdrücken. HINWEIS: Es gibt keinen spezifischen Vergleichsindex, um zu entscheiden, was als hoher PPS-Wert angesehen wird. Dies hängt von der Infrastruktur und der Art des Datenverkehrs ab. Der Vergleich kann anhand von Notizen bei inaktivem und aktivem Alarm erfolgen.

Verbindung der Netzwerkkarte des Edge-Knotens ist ausgefallen.

Bei Erkennung des Ereignisses: „Die Verbindung der Edge-Knoten-Netzwerkkarte {edge_nic_name} ist inaktiv. “

Bei Auflösung des Ereignisses: „Die Verbindung für die Edge-Knoten-Netzwerkkarte {edge_nic_name} ist verfügbar. “

Bestätigen Sie auf dem Edge-Knoten, dass die Verbindung der Netzwerkkarte physisch inaktiv ist, indem Sie den NSX-CLI-Befehl get interfaces aufrufen. Wenn Sie inaktiv ist, überprüfen Sie die Kabelverbindung.

Die Festplatte des Edge-Knotens ist schreibgeschützt.

Bei Erkennung des Ereignisses: „Die folgenden Festplattenpartitionen auf dem Edge-Knoten befinden sich im schreibgeschützten Modus: {disk_partition_name}“

Bei Auflösung des Ereignisses: „Die folgenden Festplattenpartitionen auf dem Edge-Knoten befinden sich nicht mehr im schreibgeschützten Modus: {disk_partition_name}“

Untersuchen Sie die schreibgeschützte Partition, um festzustellen, ob ein Neustart das Problem behebt oder die Festplatte ersetzt werden muss. Wenden Sie sich an GSS, um weitere Informationen zu erhalten.

Der Datenpfad-Thread des Edge-Knotens weist eine Deadlock-Bedingung auf.

Bei Erkennung des Ereignisses: „Der Datenpfad-Thread {edge_thread_name} des Edge-Knotens weist einen Deadlock auf. “

Bei Auflösung des Ereignisses: „Der Datenpfad-Thread {edge_thread_name} des Edge-Knotens weist keinen Deadlock auf. “

Starten Sie den Datenebenendienst neu, indem Sie den NSX-CLI-Befehl restart service dataplane aufrufen.

Der NIC-Durchsatz durch den Edge-Knoten-Datenpfad ist sehr hoch.

Bei Erkennung des Ereignisses: „Der Datenpfad-NIC-Durchsatz für {edge_nic_name} auf dem Edge-Knoten {entity_id} hat {nic_throughput} % erreicht und ist damit größer als der oder gleich dem Schwellenwert für sehr hohen Durchsatz von {nic_throughput_threshold} %. “

Bei Auflösung des Ereignisses: „Der Datenpfad-NIC-Durchsatz für {edge_nic_name} auf dem Edge-Knoten {entity_id} hat {nic_throughput} % erreicht und ist damit kleiner als der Schwellenwert für sehr hohen Durchsatz von {nic_throughput_threshold} %. “

Untersuchen Sie die Durchsatzwerte des Datenverkehrs auf der Netzwerkkarte und ermitteln Sie, ob Konfigurationsänderungen erforderlich sind. Der Befehl "get dataplane thoughput &ltseconds&gt" kann zur Überwachung des Durchsatzes verwendet werden.

Der NIC-Durchsatz durch den Edge-Knoten-Datenpfad ist hoch.

Bei Erkennung des Ereignisses: „Der Datenpfad-Netzwerkkarten-Durchsatz für {edge_nic_name} auf dem Edge-Knoten {entity_id} hat {nic_throughput} % erreicht und ist damit größer als der oder gleich dem Schwellenwert für hohen Durchsatz von {nic_throughput_threshold} %. “

Bei Auflösung des Ereignisses: „Der Datenpfad-NIC-Durchsatz für {edge_nic_name} auf dem Edge-Knoten {entity_id} hat {nic_throughput} % erreicht, und ist damit kleiner als der Schwellenwert für hohen Durchsatz von {nic_throughput_threshold} %. “

Untersuchen Sie die Durchsatzwerte des Datenverkehrs auf der Netzwerkkarte und ermitteln Sie, ob Konfigurationsänderungen erforderlich sind. Der Befehl "get dataplane thoughput &ltseconds&gt" kann zur Überwachung des Durchsatzes verwendet werden.

Alle Mitglieder der Fehlerdomäne sind nicht verfügbar.

Bei Erkennung des Ereignisses: „Alle Mitglieder der Fehlerdomäne {transport_node_id} sind nicht verfügbar. “

Bei Auflösung des Ereignisses: „Alle Mitglieder der Fehlerdomäne {transport_node_id} sind erreichbar. “

1. Überprüfen Sie auf dem Edge-Knoten, der durch {transport_node_id} identifiziert wird, die Konnektivität zur Management Plane und zur Control Plane, indem Sie den NSX CLI-Befehl get managers und get controllers aufrufen.
2. Rufen Sie den NSX-CLI-Befehl get interface eth0 auf, um den Status der Verwaltungsschnittstelle zu prüfen.
3. Rufen Sie den CLI-Befehl get services auf, um den Status der Kerndienste wie dataplane/local-controller/nestdb/router usw. zu überprüfen.
4. Überprüfen Sie das /var/log/syslog, um den vermuteten Fehler zu finden.
5. Starten Sie den Edge-Knoten neu.

Micro-Flow-Cache-Trefferrate nimmt ab und Datenpfad-CPU ist hoch.

Bei Erkennung des Ereignisses: Micro-Flow-Cache-Trefferrate auf dem Edge-Knoten {entity_id} hat sich unter den angegebenen Schwellenwert von {flow_cache_threshold} % für Kern {core_id} verringert und die CPU-Auslastung des Datenpfads hat sich in den letzten 30 Minuten erhöht. “

Bei Auflösung des Ereignisses: „Flow-Cache-Trefferrate liegt im normalen Bereich. “

Cache-Flow-Trefferrate hat sich in den letzten 30 Minuten verringert. Dies ist ein Hinweis darauf, dass die Edge-Leistung beeinträchtigt werden kann. Der Datenverkehr wird weiterhin weitergeleitet und möglicherweise treten keine Probleme auf. Überprüfen Sie die CPU-Auslastung des Datenpfads für Edge {entity_id}-Kern {core_id}, wenn sie in den letzten 30 Minuten hoch ist. Der Edge hat eine niedrige Flow-Cache-Trefferrate, wenn kontinuierlich neue Flows erstellt werden, da das erste Paket eines neuen Flows verwendet wird, um Flow-Cache für die schnelle Pfadverarbeitung einzurichten. Sie können die Größe Ihrer Edge-Appliance oder die Anzahl der Edge-Knoten erhöhen, die für Aktiv/Aktiv-Gateways verwendet werden.

Mega-Flow-Cache-Trefferrate nimmt ab und Datenpfad-CPU ist hoch.

Bei Erkennung des Ereignisses: „Mega-Flow-Cache-Trefferrate auf dem Edge-Knoten {entity_id} hat sich unter den angegebenen Schwellenwert von {flow_cache_threshold} % für Kern {core_id} verringert und die CPU-Auslastung des Datenpfads hat sich in den letzten 30 Minuten erhöht. “

Bei Auflösung des Ereignisses: „Flow-Cache-Trefferrate liegt im normalen Bereich. “

Cache-Flow-Trefferrate hat sich in den letzten 30 Minuten verringert. Dies ist ein Hinweis darauf, dass die Edge-Leistung beeinträchtigt werden kann. Der Datenverkehr wird weiterhin weitergeleitet und möglicherweise treten keine Probleme auf. Überprüfen Sie die CPU-Auslastung des Datenpfads für Edge {entity_id}-Kern {core_id}, wenn sie in den letzten 30 Minuten hoch ist. Der Edge hat eine niedrige Flow-Cache-Trefferrate, wenn kontinuierlich neue Flows erstellt werden, da das erste Paket eines neuen Flows verwendet wird, um Flow-Cache für die schnelle Pfadverarbeitung einzurichten. Sie können die Größe Ihrer Edge-Appliance oder die Anzahl der Edge-Knoten erhöhen, die für Aktiv/Aktiv-Gateways verwendet werden.

Der ESX Agent Manager (EAM)-Dienst auf einem Compute Manager ist nicht verfügbar.

Bei Erkennung des Ereignisses: „Der ESX Agent Manager (EAM)-Dienst auf Compute Manager {entity_id} ist nicht verfügbar. “

Bei Auflösung des Ereignisses: „Der ESX Agent Manager(EAM)-Dienst auf Compute Manager {entity_id} ist entweder aktiviert oder Compute Manager {entity_id} wurde entfernt. “

Starten Sie den ESX Agent Manager(EAM)-Dienst. Geben Sie SSH in vCenter ein und rufen Sie den Befehl service vmware-eam start auf.

Die Verbindung zwischen Host-Modul und Partner-SVM ist ausgefallen.

Bei Erkennung des Ereignisses: „Die Verbindung zwischen dem Host-Modul und der Partner-SVM {entity_id} ist inaktiv. “

Bei Auflösung des Ereignisses: „Die Verbindung zwischen dem Host-Modul und der Partner-SVM {entity_id} ist aktiv. “

Weitere Informationen finden Sie unter https://kb.vmware.com/s/article/85844. Stellen Sie sicher, dass die Partner-SVM {entity_id} erneut mit dem Host-Modul verbunden wird.

RTEP-BGP-Nachbar ist inaktiv.

Bei Erkennung des Ereignisses: „Die RTEP(Remote Tunnel Endpoint)-BGP-Sitzung von der Quell-IP {bgp_source_ip} zum Remotespeicherort {remote_site_name} mit der Nachbar-IP {bgp_neighbor_ip} ist inaktiv. Grund: {failure_reason}. “

Bei Auflösung des Ereignisses: „Die RTEP(Remote Tunnel Endpoint)-BGP-Sitzung von der Quell-IP {bgp_source_ip} zum Remotespeicherort {remote_site_name} mit der Nachbar-IP {bgp_neighbor_ip} wurde eingerichtet. “

1. Führen Sie auf dem betroffenen Edge-Knoten den NSX-CLI-Befehl get logical-routers aus.
2. Wechseln Sie zum REMOTE_TUNNEL_VRF-Kontext.
3. Rufen Sie den NSX-CLI-Befehl get bgp neighbor summary auf, um den BGP-Nachbarstatus zu prüfen.
4. Rufen Sie alternativ die NSX API GET /api/v1/transport-nodes/&lttransport-node-id&gt/inter-site/bgp/summary auf, um den BGP-Nachbarstatus abzurufen.
5. Führen Sie den NSX-CLI-Befehl get interfaces aus und prüfen Sie, ob der Schnittstelle mit dem Namen remote-tunnel-endpoint die korrekte RTEP-IP-Adresse zugewiesen ist.
6. Überprüfen Sie, ob der Ping-Befehl zwischen der zugewiesenen RTEP-IP-Adresse ({bgp_source_ip}) und dem Remotespeicherort {remote_site_name} Nachbar-IP {bgp_neighbor_ip} erfolgreich ausgeführt wird.
7. Überprüfen Sie in /var/log/syslog, ob Fehler im Zusammenhang mit BGP vorliegen.
8. Rufen Sie die NSX API GET oder PUT /api/v1/transport-nodes/&lttransport-node-id&gt auf, um die Konfiguration remote_tunnel_endpoint auf dem Edge-Knoten abzurufen/zu aktualisieren. Dadurch wird die dem betroffenen Edge-Knoten zugewiesene RTEP-IP-Adresse aktualisiert. Wenn als Grund Edge ist nicht bereit angezeigt wird, überprüfen Sie, warum sich der Edge-Knoten nicht in einem guten Zustand befindet.
1. Rufen Sie den NSX-CLI-Befehl get edge-cluster status auf, um zu überprüfen, warum der Edge-Knoten möglicherweise ausgefallen ist.
2. Rufen Sie die NSX-CLI-Befehle get bfd-config und get bfd-sessions auf, um zu überprüfen, ob BFD ordnungsgemäß ausgeführt wird.
3. Überprüfen Sie alle Alarme im Zusammenhang mit dem Edge-Systemzustand, um weitere Informationen zu erhalten.

Synchronisation zwischen Remotespeicherorten seit mehr als 3 Minuten fehlgeschlagen.

Bei Erkennung des Ereignisses: „Die Synchronisierung zwischen {site_name}({site_id}) und {remote_site_name}({remote_site_id}) ist für mehr als 3 Minuten fehlgeschlagen. “

Bei Auflösung des Ereignisses: „Die Remote-Speicherorte {site_name}({site_id}) und {remote_site_name}({remote_site_id}) werden jetzt synchronisiert. “

1. Rufen Sie den NSX-CLI-Befehl get site-replicator remote-sites auf, um den Verbindungsstatus zwischen den Remotespeicherorten abzurufen. Wenn ein Remotespeicherort verbunden, aber nicht synchronisiert ist, kann es sein, dass sich der Speicherort noch im Prozess der Masterauflösung befindet. Warten Sie in diesem Fall etwa 10 Sekunden und versuchen Sie dann erneut, den CLI-Befehl auszuführen, um den Zustand des Remotespeicherorts zu überprüfen. Wenn ein Speicherort getrennt ist, versuchen Sie es mit dem nächsten Schritt.
2. Überprüfen Sie die Konnektivität zwischen dem lokalen Manager (LM) am Speicherort {site_name}({site_id}) mit den LMs am Speicherort {remote_site_name}({remote_site_id}) mittels Ping. Wenn sie über einen Ping-Befehl nicht erreichbar sind, überprüfen Sie, ob die Konnektivität im WAN beeinträchtigt ist. Wenn keine Probleme mit der physischen Netzwerkkonnektivität vorliegen, versuchen Sie den nächsten Schritt.
3. Überprüfen Sie die Datei /var/log/cloudnet/nsx-ccp.log auf den Manager-Knoten im lokalen Cluster am Speicherort {site_name}({site_id}), der den Alarm ausgelöst hat, um festzustellen, ob es sich um Site-übergreifende Kommunikationsfehler handelt. Suchen Sie außerdem nach Fehlermeldungen, die von der Teilkomponente nsx-appl-proxy in /var/log/syslog protokolliert wurden.

Synchronisation zwischen Remotespeicherorten seit mehr als 15 Minuten fehlgeschlagen.

Bei Erkennung des Ereignisses: „Die Synchronisierung zwischen {site_name}({site_id}) und {remote_site_name}({remote_site_id}) ist für mehr als 15 Minuten fehlgeschlagen. “

Bei Auflösung des Ereignisses: „Die Remote-Sites {site_name}({site_id}) und {remote_site_name}({remote_site_id}) werden jetzt synchronisiert. “

1. Rufen Sie den NSX-CLI-Befehl get site-replicator remote-sites auf, um den Verbindungsstatus zwischen den Remotespeicherorten abzurufen. Wenn ein Remotespeicherort verbunden, aber nicht synchronisiert ist, kann es sein, dass sich der Speicherort noch im Prozess der Masterauflösung befindet. Warten Sie in diesem Fall etwa 10 Sekunden und versuchen Sie dann erneut, den CLI-Befehl auszuführen, um den Zustand des Remotespeicherorts zu überprüfen. Wenn ein Speicherort getrennt ist, versuchen Sie es mit dem nächsten Schritt.
2. Überprüfen Sie die Konnektivität zwischen dem lokalen Manager (LM) am Speicherort {site_name}({site_id}) mit den LMs am Speicherort {remote_site_name}({remote_site_id}) mittels Ping. Wenn sie über einen Ping-Befehl nicht erreichbar sind, überprüfen Sie, ob die Konnektivität im WAN beeinträchtigt ist. Wenn keine Probleme mit der physischen Netzwerkkonnektivität vorliegen, versuchen Sie den nächsten Schritt.
3. Überprüfen Sie die Datei /var/log/cloudnet/nsx-ccp.log auf den Manager-Knoten im lokalen Cluster am Speicherort {site_name}({site_id}), der den Alarm ausgelöst hat, um festzustellen, ob es sich um Site-übergreifende Kommunikationsfehler handelt. Suchen Sie außerdem nach Fehlermeldungen, die von der Teilkomponente nsx-appl-proxy in /var/log/syslog protokolliert wurden.

Die Verbindung zum RTEP-Speicherort wurde unterbrochen.

Bei Erkennung des Ereignisses: „Der Edge-Knoten {transport_node_name} hat die RTEP(Remote Tunnel Endpoint)-Konnektivität mit dem Remote-Speicherplatz {remote_site_name} verloren. “

Bei Auflösung des Ereignisses: „Der Edge-Knoten {transport_node_name} hat die RTEP(Remote Tunnel Endpoint)-Konnektivität mit dem Remote-Speicherplatz {remote_site_name} wiederhergestellt. “

1. Führen Sie auf dem betroffenen Edge-Knoten {transport_node_name} den NSX-CLI-Befehl get logical-routers aus.
2. Wechseln Sie zum REMOTE_TUNNEL_VRF-Kontext.
3. Rufen Sie den NSX-CLI-Befehl get bgp neighbor summary auf, um den BGP-Nachbarstatus zu prüfen.
4. Rufen Sie alternativ die NSX API GET /api/v1/transport-nodes/&lttransport-node-id&gt/inter-site/bgp/summary auf, um den BGP-Nachbarstatus abzurufen.
5. Führen Sie den NSX-CLI-Befehl get interfaces aus und prüfen Sie, ob der Schnittstelle mit dem Namen remote-tunnel-endpoint die korrekte RTEP-IP-Adresse zugewiesen ist.
6. Überprüfen Sie, ob der Ping-Befehl zwischen der zugewiesenen RTEP-IP-Adresse und den RTEP-IP-Adressen am Remotespeicherort {remote_site_name} erfolgreich funktioniert.
7. Überprüfen Sie in /var/log/syslog, ob Fehler im Zusammenhang mit BGP vorliegen.
8. Rufen Sie die NSX API GET oder PUT /api/v1/transport-nodes/&lttransport-node-id&gt auf, um die Konfiguration remote_tunnel_endpoint auf dem Edge-Knoten abzurufen/zu aktualisieren. Dadurch wird die dem betroffenen Edge-Knoten zugewiesene RTEP-IP-Adresse {transport_node_name} aktualisiert.

Mehrere Globaler Manager-Knoten sind gleichzeitig aktiv.

Bei Erkennung des Ereignisses: „Mehrere globale Manager-Knoten sind aktiv: {active_global_managers}. Es darf immer nur ein globaler Manager-Knoten aktiv sein. “

Bei Auflösung des Ereignisses: „Der Globaler Manager-Knoten {active_global_manager} ist jetzt der einzige aktive Globaler Manager-Knoten. “

Konfigurieren Sie nur einen Globaler Manager-Knoten als aktiv und alle anderen Globaler Manager-Knoten als Standby.

Die Latenz zwischen globalen Manager-Instanzen ist länger als erwartet und beträgt mehr als 2 Minuten

Bei Erkennung des Ereignisses: „Die Latenz zwischen den globalen Managern {from_gm_path} und {to_gm_path} ist höher als erwartet. “

Bei Auflösung des Ereignisses: „Die Latenz zwischen den globalen Managern {from_gm_path} und {to_gm_path} ist kleiner als das erwartete Niveau. “

Überprüfen Sie die Konnektivität zwischen dem globalen Manager {from_gm_path}({site_id}) und dem globalen Manager {to_gm_path}({remote_site_id}) per Ping. Wenn sie über einen Ping-Befehl nicht erreichbar sind, überprüfen Sie, ob die Konnektivität im WAN beeinträchtigt ist.

Der aktive globale Manager kann nicht mit dem globalen Standby-Manager synchronisiert werden

Bei Erkennung des Ereignisses: „Der aktive globale Manager {from_gm_path} kann nicht mit dem globalen Standby-Manager {to_gm_path} synchronisiert werden. “

Bei Auflösung des Ereignisses: „Die Synchronisierung vom aktiven globalen Manager {from_gm_path} zum globalen Standby-Manager {to_gm_path} ist fehlerfrei. “

Überprüfen Sie die Konnektivität zwischen dem globalen Manager {from_gm_path}({site_id}) und dem globalen Manager {to_gm_path}({remote_site_id}) per Ping.

Aktiver globaler Manager kann mehr als 5 Minuten lang nicht mit dem globalen Standby-Manager synchronisiert werden

Bei Erkennung des Ereignisses: „Aktiver globaler Manager {from_gm_path} kann mehr als 5 Minuten lang nicht mit dem globalen Standby-Manager {to_gm_path} synchronisiert werden. “

Bei Auflösung des Ereignisses: „Die Synchronisierung vom aktiven globalen Manager {from_gm_path} zum globalen Standby-Manager {to_gm_path} ist fehlerfrei. “

Überprüfen Sie die Konnektivität zwischen dem globalen Manager {from_gm_path}({site_id}) und dem globalen Manager {to_gm_path}({remote_site_id}) per Ping.

Die Datensynchronisierung zwischen dem globalen Manager (GM) und dem lokalen Manager (LM) ist fehlgeschlagen.

Bei Erkennung des Ereignisses: „Die Datensynchronisierung zwischen den Sites {site_name}({site_id}) und {remote_site_name}({remote_site_id}) ist für den {flow_identifier} fehlgeschlagen. Grund: {Sync_issue_reason}“

Bei Auflösung des Ereignisses: „Die Sites {site_name}({site_id}) und {remote_site_name}({remote_site_id}) werden jetzt für {flow_identifier} synchronisiert. “

1. Prüfen Sie die Netzwerkkonnektivität zwischen der Remote-Site und der lokalen Site per Ping.
2. Stellen Sie sicher, dass der Datenverkehr an Port TCP/1236 zwischen der lokalen Site und der Remote-Site zulässig ist.
3. Stellen Sie sicher, dass der async-replicator-Dienst sowohl auf lokalen als auch auf Remote-Sites ausgeführt wird. Rufen Sie die NSX API GET /api/v1/node/services/async_replicator/status oder den NSX-CLI-Befehl get service async_replicator auf, um festzustellen, ob der Dienst ausgeführt wird. Wenn er nicht ausgeführt wird, rufen Sie die NSX API POST /api/v1/node/services/async_replicator?action=restart oder die NSX-CLI restart service async_replicator auf, um den Dienst neu zu starten.
4. Überprüfen Sie in /var/log/async-replicator/ar.log, ob Fehler gemeldet wurden.

Die Datensynchronisierung zwischen dem globalen Manager (GM) und dem lokalen Manager (LM) ist für einen längeren Zeitraum fehlgeschlagen.

Bei Erkennung des Ereignisses: „Die Datensynchronisierung zwischen den Sites {site_name}({site_id}) und {remote_site_name}({remote_site_id}) ist für den {flow_identifier} über einen längeren Zeitraum fehlgeschlagen. Grund: {sync_issue_reason}. “

Bei Auflösung des Ereignisses: „Die Sites {site_name}({site_id}) und {remote_site_name}({remote_site_id}) werden jetzt für {flow_identifier} synchronisiert. “

1. Prüfen Sie die Netzwerkkonnektivität zwischen der Remote-Site und der lokalen Site per Ping.
2. Stellen Sie sicher, dass der Datenverkehr an Port TCP/1236 zwischen der lokalen Site und der Remote-Site zulässig ist.
3. Stellen Sie sicher, dass der async-replicator-Dienst sowohl auf lokalen als auch auf Remote-Sites ausgeführt wird. Rufen Sie die NSX API GET /api/v1/node/services/async_replicator/status oder den NSX-CLI-Befehl get service async_replicator auf, um festzustellen, ob der Dienst ausgeführt wird. Wenn er nicht ausgeführt wird, rufen Sie die NSX API POST /api/v1/node/services/async_replicator?action=restart oder die NSX-CLI restart service async_replicator auf, um den Dienst neu zu starten.
4. Überprüfen Sie in /var/log/async-replicator/ar.log, ob Fehler gemeldet wurden.
5. Erfassen Sie ein Support-Paket und wenden Sie sich an das NSX-Supportteam.

Warnung, dass der Schwellenwert für die Belegung der Warteschlange überschritten wurde.

Bei Erkennung des Ereignisses: „Die Warteschlange ({queue_name}), die für die Synchronisierung von Daten zwischen den Sites {site_name}({site_id}) und {remote_site_name}({remote_site_id}) verwendet wird, hat eine Größe von {queue_size} erreicht und ist damit größer als der oder gleich dem maximalen Schwellenwert von {queue_size_threshold} %. “

Bei Auflösung des Ereignisses: „Die Warteschlange ({queue_name}), die für die Synchronisierung von Daten zwischen den Sites {site_name}({site_id}) und {remote_site_name}({remote_site_id}) verwendet wird, hat eine Größe von {queue_size} erreicht, und ist damit kleiner als der maximale Schwellenwert von {queue_size_threshold} %. “

Die Warteschlangengröße kann den Schwellenwert aufgrund eines Kommunikationsproblems mit der Remote-Site oder eines überlasteten Systems überschreiten. Überprüfen Sie die Systemleistung und stellen Sie anhand von /var/log/async-replicator/ar.log fest, ob Fehler gemeldet wurden.

Die Latenz zwischen dem globalen Manager und dem lokalen Manager ist länger als erwartet und beträgt mehr als 2 Minuten.

Bei Erkennung des Ereignisses: „Die Latenz zwischen den Sites {site_name}({site_id}) und {remote_site_name}({remote_site_id}) hat {latency_value} erreicht. Dieser Wert ist damit größer als der Schwellenwert von {latency_threshold}. “

Bei Auflösung des Ereignisses: „Die Latenz zwischen den Sites {site_name}({site_id}) und {remote_site_name}({remote_site_id}) hat {latency_value} erreicht, und ist damit kleiner als der Schwellenwert von {latency_threshold}. “

1. Prüfen Sie die Netzwerkkonnektivität zwischen der Remote-Site und der lokalen Site per Ping.
2. Stellen Sie sicher, dass der Datenverkehr an Port TCP/1236 zwischen der lokalen Site und der Remote-Site zulässig ist.
3. Überprüfen Sie in /var/log/async-replicator/ar.log, ob Fehler gemeldet wurden.

Der lokale Manager wird wiederhergestellt, während der Konfigurationsimport auf dem globalen Manager ausgeführt wird.

Bei Erkennung des Ereignisses: „Konfigurationsimport von Site {site_name}({site_id}) wird durchgeführt. Site {site_name}({site_id}) wird jedoch vom Administrator aus der Sicherung wiederhergestellt, sodass sie sich in einem inkonsistenten Zustand befindet. “

Bei Auflösung des Ereignisses: „Inkonsistente Konfiguration auf Site {site_name}({site_id}) wurde behoben. “

1. Melden Sie sich bei der CLI der globalen NSX Manager-Appliance an.
2. Wechseln Sie zu Root.
3. Rufen Sie die NSX API DELETE http://localhost:64440 /gm/api/v1/infra/sites/&ltsite-name&gt/onboarding/status im lokalen Modus auf. Dadurch wird der Onboarding-Status der Site für den globalen Manager gelöscht.
4. Starten Sie das Onboarding der Konfiguration erneut.

Die Auslastung der Flow-Tabelle der Gateway-Firewall für IP-Datenverkehr ist hoch. Neue Flows werden von der Gateway-Firewall verworfen, wenn die Nutzung den maximalen Grenzwert erreicht.

Bei Erkennung des Ereignisses: „Die Auslastung der Flow-Tabelle der Gateway-Firewall für IP auf logischem Router {entity_id} hat {firewall_ip_flow_usage} % erreicht und ist damit größer als der oder gleich dem Schwellenwert für eine hohe Nutzung von {system_usage_threshold} %. Neue Flows werden von der Gateway-Firewall verworfen, wenn die Nutzung den maximalen Grenzwert erreicht. “

Bei Auflösung des Ereignisses: „Die Auslastung der Flow-Tabelle der Gateway-Firewall für Nicht-IP-Flows auf logischem Router {entity_id} ist damit kleiner als der hohe Schwellenwert von {system_usage_threshold} %. “

Melden Sie sich als Admin-Benutzer beim Edge-Knoten an und rufen Sie den NSX CLI-Befehl get firewall &ltLR_INT_UUID&gt interface stats | json auf, indem Sie die richtige Schnittstellen-UUID verwenden und die Auslastung der Flow-Tabelle für IP-Flows überprüfen. Stellen Sie sicher, dass es sich bei den das Gateway durchlaufenden Datenverkehrsströmen nicht um einen DOS-Angriff oder anormalen Burst handelt. Wenn jedoch bei scheinbar normaler Last des Datenverkehrs der Alarmschwellenwert erreicht wird, sollten Sie den Alarmschwellenwert erhöhen oder neuen Datenverkehr an einen anderen Edge-Knoten weiterleiten.

Die Flow-Tabelle der Gateway-Firewall für IP-Datenverkehr hat den festgelegten Schwellenwert überschritten. Neue Flows werden von der Gateway-Firewall verworfen, wenn die Nutzung den maximalen Grenzwert erreicht.

Bei Erkennung des Ereignisses: „Die Auslastung der Flow-Tabelle der Gateway-Firewall für IP-Datenverkehr auf logischem Router {entity_id} hat {firewall_ip_flow_usage} % erreicht und ist damit größer als der oder gleich dem Schwellenwert für eine hohe Nutzung von {system_usage_threshold} %. Neue Flows werden von der Gateway-Firewall verworfen, wenn die Nutzung den maximalen Grenzwert erreicht. “

Bei Auflösung des Ereignisses: „Die Auslastung der Flow-Tabelle der Gateway-Firewall auf logischem Router {entity_id} ist damit kleiner als der hohe Schwellenwert von {system_usage_threshold} %. “

Melden Sie sich als Admin-Benutzer beim Edge-Knoten an und rufen Sie den NSX CLI-Befehl get firewall &ltLR_INT_UUID&gt interface stats | json auf, indem Sie die richtige Schnittstellen-UUID verwenden und die Auslastung der Flow-Tabelle für IP-Flows überprüfen. Stellen Sie sicher, dass es sich bei den das Gateway durchlaufenden Datenverkehrsströmen nicht um einen DOS-Angriff oder anormalen Burst handelt. Wenn jedoch bei scheinbar normaler Last des Datenverkehrs der Alarmschwellenwert erreicht wird, sollten Sie den Alarmschwellenwert erhöhen oder neuen Datenverkehr an einen anderen Edge-Knoten weiterleiten.

Die Auslastung der Flow-Tabelle der Gateway-Firewall für UDP-Datenverkehr ist hoch. Neue Flows werden von der Gateway-Firewall verworfen, wenn die Nutzung den maximalen Grenzwert erreicht.

Bei Erkennung des Ereignisses: „Die Auslastung der Flow-Tabelle der Gateway-Firewall für UDP auf logischem Router {entity_id} hat {firewall_udp_flow_usage} % erreicht und ist damit größer als der oder gleich dem hohen Schwellenwert von  {system_usage_threshold}% %. Neue Flows werden von der Gateway-Firewall verworfen, wenn die Nutzung den maximalen Grenzwert erreicht. “

Bei Auflösung des Ereignisses: „Die Auslastung der Flow-Tabelle der Gateway-Firewall für UDP auf logischem Router {entity_id} ist damit kleiner als der hohe Schwellenwert. “

Melden Sie sich als Admin-Benutzer beim Edge-Knoten an und rufen Sie den NSX CLI-Befehl get firewall &ltLR_INT_UUID&gt interface stats | json auf, indem Sie die richtige Schnittstellen-UUID verwenden und die Auslastung der Flow-Tabelle für UDP-Flows überprüfen. Stellen Sie sicher, dass es sich bei den das Gateway durchlaufenden Datenverkehrsströmen nicht um einen DOS-Angriff oder anormalen Burst handelt. Wenn jedoch bei scheinbar normaler Last des Datenverkehrs der Alarmschwellenwert erreicht wird, sollten Sie den Alarmschwellenwert erhöhen oder neuen Datenverkehr an einen anderen Edge-Knoten weiterleiten.

Die Flow-Tabelle der Gateway-Firewall für UDP-Datenverkehr hat den festgelegten Schwellenwert überschritten. Neue Flows werden von der Gateway-Firewall verworfen, wenn die Nutzung den maximalen Grenzwert erreicht.

Bei Erkennung des Ereignisses: „Die Auslastung der Flow-Tabelle der Gateway-Firewall für UDP-Datenverkehr auf logischem Router {entity_id} hat {firewall_udp_flow_usage} % erreicht und ist damit größer als der oder gleich dem hohen Schwellenwert von {system_usage_threshold} %. Neue Flows werden von der Gateway-Firewall verworfen, wenn die Nutzung den maximalen Grenzwert erreicht. “

Bei Auflösung des Ereignisses: „Die Auslastung der Flow-Tabelle der Gateway-Firewall auf logischem Router {entity_id} ist damit kleiner als der hohe Schwellenwert. “

Melden Sie sich als Admin-Benutzer beim Edge-Knoten an und rufen Sie den NSX CLI-Befehl get firewall &ltLR_INT_UUID&gt interface stats | json auf, indem Sie die richtige Schnittstellen-UUID verwenden und die Auslastung der Flow-Tabelle für UDP-Flows überprüfen. Stellen Sie sicher, dass es sich bei den das Gateway durchlaufenden Datenverkehrsströmen nicht um einen DOS-Angriff oder anormalen Burst handelt. Wenn jedoch bei scheinbar normaler Last des Datenverkehrs der Alarmschwellenwert erreicht wird, sollten Sie den Alarmschwellenwert erhöhen oder neuen Datenverkehr an einen anderen Edge-Knoten weiterleiten.

Die Auslastung der Flow-Tabelle der Gateway-Firewall für ICMP-Datenverkehr ist hoch. Neue Flows werden von der Gateway-Firewall verworfen, wenn die Nutzung den maximalen Grenzwert erreicht.

Bei Erkennung des Ereignisses: „Die Auslastung der Flow-Tabelle der Gateway-Firewall für ICMP auf logischem Router {entity_id} hat {firewall_icmp_flow_usage} % erreicht und ist damit größer als der oder gleich dem hohen Schwellenwert von {system_usage_threshold} %. Neue Flows werden von der Gateway-Firewall verworfen, wenn die Nutzung den maximalen Grenzwert erreicht. “

Bei Auflösung des Ereignisses: „Die Auslastung der Flow-Tabelle der Gateway-Firewall für ICMP auf logischem Router {entity_id} ist damit kleiner als der hohe Schwellenwert von {system_usage_threshold} %. “

Melden Sie sich als Admin-Benutzer beim Edge-Knoten an und rufen Sie den NSX CLI-Befehl get firewall &ltLR_INT_UUID&gt interface stats | json auf, indem Sie die richtige Schnittstellen-UUID verwenden und die Auslastung der Flow-Tabelle für ICMP-Flows überprüfen. Stellen Sie sicher, dass es sich bei den das Gateway durchlaufenden Datenverkehrsströmen nicht um einen DOS-Angriff oder anormalen Burst handelt. Wenn jedoch bei scheinbar normaler Last des Datenverkehrs der Alarmschwellenwert erreicht wird, sollten Sie den Alarmschwellenwert erhöhen oder neuen Datenverkehr an einen anderen Edge-Knoten weiterleiten.

Die Flow-Tabelle der Gateway-Firewall für ICMP-Datenverkehr hat den festgelegten Schwellenwert überschritten. Neue Flows werden von der Gateway-Firewall verworfen, wenn die Nutzung den maximalen Grenzwert erreicht.

Bei Erkennung des Ereignisses: „Die Auslastung der Flow-Tabelle der Gateway-Firewall für ICMP-Datenverkehr auf logischem Router {entity_id} hat {firewall_icmp_flow_usage} % erreicht und ist damit größer als der oder gleich dem hohen Schwellenwert von {system_usage_threshold} %. Neue Flows werden von der Gateway-Firewall verworfen, wenn die Nutzung den maximalen Grenzwert erreicht. “

Bei Auflösung des Ereignisses: „Die Auslastung der Flow-Tabelle der Gateway-Firewall auf logischem Router {entity_id} ist damit kleiner als der hohe Schwellenwert von {system_usage_threshold} %. “

Melden Sie sich als Admin-Benutzer beim Edge-Knoten an und rufen Sie den NSX CLI-Befehl get firewall &ltLR_INT_UUID&gt interface stats | json auf, indem Sie die richtige Schnittstellen-UUID verwenden und die Auslastung der Flow-Tabelle für ICMP-Flows überprüfen. Stellen Sie sicher, dass es sich bei den das Gateway durchlaufenden Datenverkehrsströmen nicht um einen DOS-Angriff oder anormalen Burst handelt. Wenn jedoch bei scheinbar normaler Last des Datenverkehrs der Alarmschwellenwert erreicht wird, sollten Sie den Alarmschwellenwert erhöhen oder neuen Datenverkehr an einen anderen Edge-Knoten weiterleiten.

Die Auslastung der Flow-Tabelle der Gateway-Firewall für halb offenen TCP-Datenverkehr ist hoch. Neue Flows werden von der Gateway-Firewall verworfen, wenn die Nutzung den maximalen Grenzwert erreicht.

Bei Erkennung des Ereignisses: „Die Auslastung der Flow-Tabelle der Gateway-Firewall für TCP auf logischem Router {entity_id} hat {firewall_halfopen_flow_usage} % erreicht und ist damit größer als der oder gleich dem hohen Schwellenwert von {system_usage_threshold} %. Neue Flows werden von der Gateway-Firewall verworfen, wenn die Nutzung den maximalen Grenzwert erreicht. “

Bei Auflösung des Ereignisses: „Die Auslastung der Flow-Tabelle der Gateway-Firewall für halb offenes TCP auf logischem Router {entity_id} ist damit kleiner als der hohe Schwellenwert von {system_usage_threshold} %. “

Melden Sie sich als Admin-Benutzer beim Edge-Knoten an und rufen Sie den NSX CLI-Befehl get firewall &ltLR_INT_UUID&gt interface stats | json auf, indem Sie die richtige Schnittstellen-UUID verwenden und die Auslastung der Flow-Tabelle für halb offene TCP-Flows überprüfen. Stellen Sie sicher, dass es sich bei den das Gateway durchlaufenden Datenverkehrsströmen nicht um einen DOS-Angriff oder anormalen Burst handelt. Wenn jedoch bei scheinbar normaler Last des Datenverkehrs der Alarmschwellenwert erreicht wird, sollten Sie den Alarmschwellenwert erhöhen oder neuen Datenverkehr an einen anderen Edge-Knoten weiterleiten.

Die Flow-Tabelle der Gateway-Firewall für halb offenen TCP-Datenverkehr hat den festgelegten Schwellenwert überschritten. Neue Flows werden von der Gateway-Firewall verworfen, wenn die Nutzung den maximalen Grenzwert erreicht.

Bei Erkennung des Ereignisses: „Die Auslastung der Flow-Tabelle der Gateway-Firewall für halb offenen TCP-Datenverkehr auf logischem Router {entity_id} hat {firewall_icmp_flow_usage} % erreicht und ist damit größer als der oder gleich dem hohen Schwellenwert von {system_usage_threshold} %. Neue Flows werden von der Gateway-Firewall verworfen, wenn die Nutzung den maximalen Grenzwert erreicht. “

Bei Auflösung des Ereignisses: „Die Auslastung der Flow-Tabelle der Gateway-Firewall auf logischem Router {entity_id} ist damit kleiner als der hohe Schwellenwert von {system_usage_threshold} %. “

Melden Sie sich als Admin-Benutzer beim Edge-Knoten an und rufen Sie den NSX-CLI-Befehl get firewall &ltLR_INT_UUID&gt interface stats | json auf, indem Sie die richtige Schnittstellen-UUID verwenden und die Auslastung der Flow-Tabelle für halb offene TCP-Flows überprüfen. Stellen Sie sicher, dass es sich bei den das Gateway durchlaufenden Datenverkehrsströmen nicht um einen DOS-Angriff oder anormalen Burst handelt. Wenn jedoch bei scheinbar normaler Last des Datenverkehrs der Alarmschwellenwert erreicht wird, sollten Sie den Alarmschwellenwert erhöhen oder neuen Datenverkehr an einen anderen Edge-Knoten weiterleiten.

Gesamtanzahl der übersetzten Gruppenelemente hat den maximalen Grenzwert überschritten.

Bei Erkennung des Ereignisses: „Gruppe {group_id} weist mindestens {group_size} übersetzte Elemente auf und ist damit größer als der oder gleich dem Grenzwert für die maximale Anzahl von {group_max_number_limit}. Dies kann zu langen Verarbeitungszeiten sowie zu Zeitüberschreitungen und Ausfällen führen. Die aktuelle Anzahl für jeden Elementtyp lautet wie folgt. IP-Sets: {ip_count}, MAC-Sets: {mac_count}, VIFS: {vif_count}, Ports für logische Switches: {lsp_count}, Ports für logische Router: {lrp_count}, AdGroups: {sid_count}. “

Bei Auflösung des Ereignisses: „Die Gesamtanzahl der Elemente in Gruppe {group_id} ist damit kleiner als der maximale Grenzwert von {group_max_number_limit}. “

1. Erwägen Sie die Anpassung von Gruppenelementen in überdimensionierten Gruppen {group_id}.
2. Erwägen Sie, überdimensionierte Gruppen {group_id} in mehrere kleinere Gruppen aufzuteilen und Mitglieder einer überdimensionierten Gruppe auf diese Gruppen zu verteilen.

Ein Tier0-Gateway hat ein Failover durchgeführt.

Bei Erkennung des Ereignisses: „Für das Tier-0-Gateway {entity_id} wurde ein Failover von {previous_gateway_state} auf {current_gateway_state} vorgenommen, Dienstrouter {service_router_id}“

Bei Auflösung des Ereignisses: „Das Tier-0-Gateway {entity_id} ist jetzt aktiv. “

Rufen Sie den NSX-CLI-Befehl get logical-router &ltservice_router_id&gt auf, um die VRF-ID des Tier-0-Dienstrouters abzurufen. Wechseln Sie zum VRF-Kontext, indem Sie erst vrf &ltvrf-id&gt und dann get high-availability status aufrufen, um den inaktiven Dienst zu ermitteln.

Ein Tier-1-Gateway hat ein Failover durchgeführt.

Bei Erkennung des Ereignisses: „Für das Tier-1-Gateway {entity_id} wurde ein Failover von {previous_gateway_state} auf {current_gateway_state} vorgenommen, Dienstrouter {service_router_id}“

Bei Auflösung des Ereignisses: „Das Tier-1-Gateway {entity_id} ist jetzt aktiv. “

Rufen Sie den NSX-CLI-Befehl get logical-router &ltservice_router_id&gt auf, um die VRF-ID des Tier-1-Dienstrouters abzurufen. Wechseln Sie zum VRF-Kontext, indem Sie erst vrf &ltvrf-id&gt und dann get high-availability status aufrufen, um den inaktiven Dienst zu ermitteln.

Dienstgruppe hat keine aktive Instanz.

Bei Erkennung des Ereignisses: „Dienstgruppen-Cluster {entity_id} verfügt derzeit nicht über eine aktive Instanz. Er befindet sich auf Edge-Knoten {transport_node_id} im Status {ha_state} (0 ist inaktiv, 1 ist Standby und 2 ist aktiv) und auf Edge-Knoten {transport_node_id2} im Status {ha_state2}. “

Bei Auflösung des Ereignisses: „Tier-0-Dienstgruppen-Cluster {entity_id} verfügt jetzt über eine aktive Instanz auf {transport_node_id}. “

Untersuchen Sie den NSX-CLI-Befehl get logical-router &ltservice_router_id&gt service_group, um alle unter einem bestimmten Dienstrouter konfigurierten Dienstgruppen zu überprüfen. Untersuchen Sie die Ausgabe auf die Fehlerursache für eine zuvor im Standby-Status befindliche Dienstgruppe.

Dienstgruppe hat keine aktive Instanz.

Bei Erkennung des Ereignisses: „Dienstgruppen-Cluster {entity_id} verfügt derzeit nicht über eine aktive Instanz. Er befindet sich auf Edge-Knoten {transport_node_id} im Status {ha_state} (0 ist inaktiv, 1 ist Standby und 2 ist aktiv) und auf Edge-Knoten {transport_node_id2} im Status {ha_state2}. “

Bei Auflösung des Ereignisses: „Tier-1-Dienstgruppen-Cluster {entity_id} verfügt jetzt über eine aktive Instanz auf {transport_node_id}. “

Untersuchen Sie den NSX-CLI-Befehl get logical-router &ltservice_router_id&gt service_group, um alle unter einem bestimmten Dienstrouter konfigurierten Dienstgruppen zu überprüfen. Untersuchen Sie die Ausgabe auf die Fehlerursache für eine zuvor im Standby-Status befindliche Dienstgruppe.

Eine Standby-Instanz in einer Dienstgruppe ist fehlgeschlagen.

Bei Erkennung des Ereignisses: „Dienstgruppen-Cluster {entity_id}, der mit Tier-0-Dienstrouter {service_router_id} auf Edge-Knoten {transport_node_id} verknüpft ist, ist fehlgeschlagen. Dies führt dazu, dass der Dienstgruppen-Cluster derzeit keine Standby-Instanz aufweist. “

Bei Auflösung des Ereignisses: „Dienstgruppen-Cluster {entity_id} befindet sich im Status {ha_state} (0 ist inaktiv, 1 ist Standby und 2 ist aktiv) auf Edge-Knoten {transport_node_id} und Status {ha_state2} auf Edge-Knoten {transport_node_id2}. “

Untersuchen Sie den NSX-CLI-Befehl get logical-router &ltservice_router_id&gt service_group, um alle unter einem bestimmten Dienstrouter konfigurierten Dienstgruppen zu überprüfen. Untersuchen Sie die Ausgabe auf die Fehlerursache für eine zuvor im Standby-Status befindliche Dienstgruppe.

Eine Standby-Instanz in einer Dienstgruppe ist fehlgeschlagen.

Bei Erkennung des Ereignisses: „Dienstgruppen-Cluster {entity_id}, der mit Tier-1-Dienstrouter {service_router_id} auf Edge-Knoten {transport_node_id} verknüpft ist, ist fehlgeschlagen. Dies führt dazu, dass der Dienstgruppen-Cluster derzeit keine Standby-Instanz aufweist. “

Bei Auflösung des Ereignisses: „Dienstgruppen-Cluster {entity_id} befindet sich im Status {ha_state} (0 ist inaktiv, 1 ist Standby und 2 ist aktiv) auf Edge-Knoten {transport_node_id} und Status {ha_state2} auf Edge-Knoten {transport_node_id2}. “

Untersuchen Sie den NSX-CLI-Befehl get logical-router &ltservice_router_id&gt service_group, um alle unter einem bestimmten Dienstrouter konfigurierten Dienstgruppen zu überprüfen. Untersuchen Sie die Ausgabe auf die Fehlerursache für eine zuvor im Standby-Status befindliche Dienstgruppe.

Die Verbindung zum LDAP-Server ist unterbrochen.

Bei Erkennung des Ereignisses: „Die Verbindung zum LDAP-Server {ldap_server} ist unterbrochen. “

Bei Auflösung des Ereignisses: „Die Verbindung zum LDAP-Server {ldap_server} wird wiederhergestellt. “

Überprüfen Sie:
1. Der LDAP-Server ist von NSX-Knoten aus erreichbar.
2. Die LDAP-Serverdetails sind korrekt in NSX konfiguriert.
3. Der LDAP-Server wird ordnungsgemäß ausgeführt.
4. Der Zugriff zwischen dem LDAP-Server und NSX-Knoten wird nicht durch Firewalls blockiert. Nachdem das Problem behoben wurde, verwenden Sie in der NSX-Benutzeroberfläche unter „Identitäts-Firewall-AD“ VERBINDUNG TESTEN, um die Verbindung zu testen.

Beim Ausführen der Deltasynchronisierung sind Fehler aufgetreten.

Bei Erkennung des Ereignisses: „Beim Ausführen der Deltasynchronisierung mit {directory_domain} sind Fehler aufgetreten. “

Bei Auflösung des Ereignisses: „Beim Ausführen der Deltasynchronisierung mit {directory_domain} sind keine Fehler aufgetreten. “

1. Überprüfen Sie, ob Alarme vorliegen, die sich auf die Unterbrechung der Verbindung zum LDAP-Server beziehen.
2. Suchen Sie die Fehlerdetails in /var/log/syslog. Suchen Sie im Bereich des Alarmzeitpunkts nach dem Text: Fehler beim Synchronisieren von LDAP-Objekten.
3. Prüfen Sie mit dem AD-Administrator, ob kürzlich vorgenommene AD-Änderungen gegebenenfalls die Fehler verursachen können.
4. Falls die Fehler weiterhin auftreten, speichern Sie das Paket für den technischen Support und wenden Sie sich an den technischen Support von VMware.

Der Tunnelstatus eines Edge-Knotens ist inaktiv.

Bei Erkennung des Ereignisses: „Der Gesamttunnelstatus des Edge-Knotens {entity_id} ist inaktiv. “

Bei Auflösung des Ereignisses: „Die Tunnel des Edge-Knotens {entity_id} wurden wiederhergestellt. “

Rufen Sie den NSX-CLI-Befehl get tunnel-ports auf, um alle Tunnel-Ports abzurufen, und überprüfen Sie dann die Statistiken der einzelnen Tunnel, indem Sie den NSX-CLI-Befehl get tunnel-port &ltUUID&gt stats aufrufen, um zu überprüfen, ob es Abbrüche gibt. Überprüfen Sie anschließend in /var/log/syslog, ob auf Tunnel bezogene Fehler vorhanden sind.

Der Dienststatus auf DPU ist abnormal.

Bei Erkennung des Ereignisses: „Der Dienst {service_name} auf DPU {dpu_id} hat seit 10 Sekunden nicht reagiert. “

Bei Auflösung des Ereignisses: „Der Dienst {service_name} auf DPU {dpu_id} reagiert wieder. “

Stellen Sie sicher, dass der {service_name}-Dienst weiterhin auf DPU {dpu_id} ausgeführt wird, indem Sie /etc/init.d/{service_name} status ausführen. Wenn gemeldet wird, dass der Dienst ausgeführt wird, muss er möglicherweise neu gestartet werden. Dies kann durch /etc/init.d/{service_name} restart ausgeführt werden. Führen Sie den Statusbefehl erneut aus, um zu prüfen, ob der Dienst jetzt ausgeführt wird. Wenn das Problem durch einen Neustart des Dienstes nicht behoben wird oder wenn das Problem nach einem erfolgreichen Neustart erneut auftritt, wenden Sie sich an VMware Support.

Der Dienststatus ist abnormal.

Bei Erkennung des Ereignisses: „Der Dienst {service_name} hat seit 10 Sekunden nicht reagiert. “

Bei Auflösung des Ereignisses: „Der Dienst {service_name} reagiert wieder. “

Stellen Sie sicher, dass der {service_name}-Dienst weiterhin ausgeführt wird, indem Sie /etc/init.d/{service_name} status ausführen. Wenn gemeldet wird, dass der Dienst ausgeführt wird, muss er möglicherweise neu gestartet werden. Dies kann durch /etc/init.d/{service_name} restart ausgeführt werden. Führen Sie den Statusbefehl erneut aus, um zu prüfen, ob der Dienst jetzt ausgeführt wird. Wenn das Skript /etc/init.d/{service_name} nicht verfügbar ist, führen Sie systemctl {service_name} status aus, und starten Sie neu, indem Sie systemctl {service_name} restart mit Root-Berechtigungen ausführen. Wenn das Problem durch einen Neustart des Dienstes nicht behoben wird oder wenn das Problem nach einem erfolgreichen Neustart erneut auftritt, wenden Sie sich an VMware Support.

Fehler beim Bereitstellen von Metriken an das angegebene Ziel.

Bei Erkennung des Ereignisses: „Fehler beim Bereitstellen von Metriken von SHA an Ziel {metrics_target_alias}({metrics_target_address}:{metrics_target_port}). “

Bei Auflösung des Ereignisses: „Metrikbereitstellung an Ziel {metrics_target_alias}({metrics_target_address}:{metrics_target_port}) wiederhergestellt. “

Der Benutzer sollte die folgenden Prüfungen durchführen, um das Problem, das den Fehler verursacht, auszuschließen: 1. Überprüfen Sie, ob die für die Verbindung übergebene Zieladresse {metrics_target_address} und Port {metrics_target_port} (Standardwert ist 443, wenn der Port nicht angegeben ist) das erwartete Ziel ist. 2. Überprüfen Sie, ob das Zertifikat korrekt ist, indem Sie /opt/vmware/nsx-nestdb/bin/nestdb-cli --cmd 'put vmware.nsx.nestdb.CommonAgentHostConfigMsg' aufrufen. 3. Überprüfen Sie, ob Ziel {metrics_target_address} erreichbar ist. 4. Überprüfen Sie, ob der Metrikmanager auf Ziel {metrics_target_address} von docker ps | grep metrics_manager ausgeführt wird. 5. Überprüfen Sie, ob Port {metrics_target_port} durch netstat -a | grep {metrics_target_port} auf dem Ziel geöffnet ist. 6. Überprüfen Sie, ob die ALLOW-Firewallregel auf dem Knoten durchiptables -S OUTPUT | grep {metrics_target_port} (EDGE/UA) oder „localcli network firewall ruleset list | grep nsx-sha-tsdb (ESX) installiert ist. 7. Starten Sie den SHA-Daemon neu, um zu prüfen, ob er durch /etc/init.d/netopa restart (ESX) oder /etc/init.d/nsx-netopa restart (EDGE) oder /etc/init.d/nsx-sha restart (UA) repariert werden kann.

Der Edge-Dienst ist mindestens eine Minute lang inaktiv.

Bei Erkennung des Ereignisses: „Der Dienst {edge_service_name} ist mindestens eine Minute lang inaktiv. {Service_down_reason}“

Bei Auflösung des Ereignisses: „Der Dienst {edge_service_name} ist aktiv. “

Stellen Sie auf dem Edge-Knoten sicher, dass der Dienst nicht aufgrund eines Fehlers beendet wurde, indem Sie im Verzeichnis /var/log/core nach Core-Dateien suchen. Rufen Sie darüber hinaus den NSX-CLI-Befehl get services auf, um festzustellen, ob der Dienst angehalten wurde. Falls ja, rufen Sie start service &ltservice-name&gt auf, um den Dienst neu zu starten.

Der Status des Edge-Diensts hat sich geändert.

Bei Erkennung des Ereignisses: „Der Dienst {edge_service_name} wurde von {previous_service_state} in {current_service_state} geändert. {Service_down_reason}“

Bei Auflösung des Ereignisses: „Der Dienst {edge_service_name} wurde von {previous_service_state} in {current_service_state} geändert. “

Stellen Sie auf dem Edge-Knoten sicher, dass der Dienst nicht aufgrund eines Fehlers beendet wurde, indem Sie im Verzeichnis /var/log/core nach Core-Dateien suchen. Rufen Sie darüber hinaus den NSX-CLI-Befehl get services auf, um festzustellen, ob der Dienst angehalten wurde. Falls ja, rufen Sie start service &ltservice-name&gt auf, um den Dienst neu zu starten.

Die Anwendung ist abgestürzt und hat einen Core-Dump generiert.

Bei Erkennung des Ereignisses: „Die Anwendung auf NSX-Knoten {node_display_or_host_name} ist abgestürzt. Die Anzahl der gefundenen Kerndateien ist {core_dump_count}. Erfassen Sie das Support-Paket einschließlich Core-Dump-Dateien und wenden Sie sich an das VMware Supportteam. “

Bei Auflösung des Ereignisses: „Alle Core-Dump-Dateien werden aus dem System entfernt. “

Erfassen Sie ein Support-Paket für den NSX-Knoten {node_display_or_host_name} mithilfe der NSX Manager-Benutzeroberfläche oder der API. Hinweis: Core-Dumps können so festgelegt werden, dass sie in ein NSX Tech-Support-Paket verschoben oder kopiert werden, um die lokale Kopie auf dem Knoten zu entfernen oder beizubehalten. Die Kopie des Support-Pakets mit Core-Dump-Dateien ist für das VMware Supportteam wichtig, um das Problem zu beheben. Es wird empfohlen, eine aktuelle Kopie des Tech-Support-Pakets einschließlich Core-Dump-Dateien zu speichern, bevor Core-Dump-Dateien aus dem System entfernt werden. Weitere Einzelheiten finden Sie im KB-Artikel.

Ein Transportknoten ist vom Messaging-Broker des Intelligence-Knotens getrennt. Die Datenerfassung ist davon betroffen.

Bei Erkennung des Ereignisses: „Der Flow-Exporter auf dem Transportknoten{entity_id} ist vom Messaging-Broker des Intelligence-Knotens getrennt. Die Datenerfassung ist davon betroffen. “

Bei Auflösung des Ereignisses: „Der Flow-Exporter auf dem Transportknoten {entity_id} hat die Verbindung zum Messaging-Broker des Intelligence-Knotens wiederhergestellt. “

Starten Sie den Nachrichtendienst neu, wenn er nicht im Intelligence-Knoten ausgeführt wird. Beheben Sie den Netzwerkverbindungsfehler zwischen dem Flow-Exporter des Transportknotens und dem Intelligence-Knoten.

Die CPU-Auslastung durch den Intelligence-Knoten ist sehr hoch.

Bei Erkennung des Ereignisses: „Die CPU-Auslastung des Intelligence-Knotens {intelligence_node_id} liegt über dem Schwellenwert für eine sehr hohe Nutzung von {system_usage_threshold} %. “

Bei Auflösung des Ereignisses: „Die CPU-Auslastung des Intelligence-Knotens {intelligence_node_id} ist damit kleiner als der Schwellenwert für eine sehr hohe Nutzung von {system_usage_threshold} %. “

Verwenden Sie den obersten Befehl, um zu überprüfen, welche Prozesse die meiste CPU-Nutzung aufweisen, und überprüfen Sie dann /var/log/syslog und die lokalen Protokolle dieser Prozesse, um festzustellen, ob ausstehende Fehler behoben werden müssen.

Die CPU-Auslastung durch den Intelligence-Knoten ist hoch.

Bei Erkennung des Ereignisses: „Die CPU-Auslastung des Intelligence-Knotens {intelligence_node_id} liegt über dem Schwellenwert für eine hohe Nutzung von {system_usage_threshold} %. “

Bei Auflösung des Ereignisses: „Die CPU-Auslastung des Intelligence-Knotens {intelligence_node_id} ist damit kleiner als der Schwellenwert für eine hohe Nutzung von {system_usage_threshold} %. “

Verwenden Sie den obersten Befehl, um zu überprüfen, welche Prozesse die meiste CPU-Nutzung aufweisen, und überprüfen Sie dann /var/log/syslog und die lokalen Protokolle dieser Prozesse, um festzustellen, ob ausstehende Fehler behoben werden müssen.

Die Arbeitsspeichernutzung durch den Intelligence-Knoten ist sehr hoch.

Bei Erkennung des Ereignisses: „Die Arbeitsspeichernutzung des Intelligence-Knotens {intelligence_node_id} liegt über dem Schwellenwert für eine sehr hohe Nutzung von {system_usage_threshold} %. “

Bei Auflösung des Ereignisses: „Die Arbeitsspeichernutzung des Intelligence-Knotens {intelligence_node_id} ist damit kleiner als der Schwellenwert für eine sehr hohe Nutzung von {system_usage_threshold} %. “

Verwenden Sie den obersten Befehl, um zu überprüfen, welche Prozesse die meiste Arbeitsspeichernutzung aufweisen und überprüfen Sie dann /var/log/syslog und die lokalen Protokolle dieser Prozesse, um festzustellen, ob ausstehende Fehler behoben werden müssen.

Die Arbeitsspeichernutzung durch den Intelligence-Knoten ist hoch.

Bei Erkennung des Ereignisses: „Die Arbeitsspeichernutzung des Intelligence-Knotens {intelligence_node_id} liegt über dem Schwellenwert für eine hohe Nutzung von {system_usage_threshold} %. “

Bei Auflösung des Ereignisses: „Die Arbeitsspeichernutzung des Intelligence-Knotens {intelligence_node_id} ist damit kleiner als der Schwellenwert für eine hohe Nutzung von {system_usage_threshold} %. “

Verwenden Sie den obersten Befehl, um zu überprüfen, welche Prozesse die meiste Arbeitsspeichernutzung aufweisen und überprüfen Sie dann /var/log/syslog und die lokalen Protokolle dieser Prozesse, um festzustellen, ob ausstehende Fehler behoben werden müssen.

Die Festplattennutzung durch den Intelligence-Knoten ist sehr hoch.

Bei Erkennung des Ereignisses: „Die Festplattennutzung der Festplattenpartition {disk_partition_name} auf dem Intelligence-Knoten {intelligence_node_id} liegt über dem Schwellenwert für eine sehr hohe Nutzung von {system_usage_threshold} %. “

Bei Auflösung des Ereignisses: „Die Festplattennutzung der Festplattenpartition {disk_partition_name} auf dem Intelligence-Knoten {intelligence_node_id} ist damit kleiner als der Schwellenwert für eine sehr hohe Nutzung von {system_usage_threshold} %. “

Untersuchen Sie die Festplattenpartition {disk_partition_name} und überprüfen Sie, ob unerwartete große Dateien vorhanden sind, die entfernt werden können.

Die Festplattennutzung durch den Intelligence-Knoten ist hoch.

Bei Erkennung des Ereignisses: „Die Festplattennutzung der Festplattenpartition {disk_partition_name} auf dem Intelligence-Knoten {intelligence_node_id} liegt über dem Schwellenwert für eine hohe Nutzung von {system_usage_threshold} %. “

Bei Auflösung des Ereignisses: „Die Festplattennutzung der Festplattenpartition {disk_partition_name} auf dem Intelligence-Knoten {intelligence_node_id} ist damit kleiner als der Schwellenwert für eine hohe Nutzung von {system_usage_threshold} %. “

Untersuchen Sie die Festplattenpartition {disk_partition_name} und überprüfen Sie, ob unerwartete große Dateien vorhanden sind, die entfernt werden können.

Die Nutzung der Datenträgerpartition durch den Intelligence-Knoten ist sehr hoch.

Bei Erkennung des Ereignisses: „Die Festplattennutzung der Festplattenpartition /data auf dem Intelligence-Knoten {intelligence_node_id} liegt über dem Schwellenwert für eine sehr hohe Nutzung von {system_usage_threshold} %. “

Bei Auflösung des Ereignisses: „Die Festplattennutzung der Festplattenpartition /data auf dem Intelligence-Knoten {intelligence_node_id} ist damit kleiner als der Schwellenwert für eine sehr hohe Nutzung von {system_usage_threshold} %. “

Beenden Sie die NSX Intelligence-Datenerfassung, bis die Festplattennutzung unter dem Schwellenwert liegt. Navigieren Sie in der NSX-Benutzeroberfläche zu „System“ | „Appliances“ | „NSX Intelligence-Appliance“. Klicken Sie dann auf „AKTIONEN“ und dann auf „Datenerfassung stoppen“.

Die Nutzung der Datenträgerpartition durch den Intelligence-Knoten ist hoch.

Bei Erkennung des Ereignisses: „Die Festplattennutzung der Festplattenpartition /data auf dem Intelligence-Knoten {intelligence_node_id} liegt über dem Schwellenwert für eine hohe Nutzung von {system_usage_threshold} %. “

Bei Auflösung des Ereignisses: „Die Festplattennutzung der Festplattenpartition /data auf dem Intelligence-Knoten {intelligence_node_id} ist damit kleiner als der Schwellenwert für eine hohe Nutzung von {system_usage_threshold} %. “

Beenden Sie die NSX Intelligence-Datenerfassung, bis die Festplattennutzung unter dem Schwellenwert liegt. Untersuchen Sie die Festplattenpartition /data und überprüfen Sie, ob unerwartete große Dateien vorhanden sind, die entfernt werden können.

Die Latenz des Intelligence-Knotenspeichers ist hoch.

Bei Erkennung des Ereignisses: „Die Speicherlatenz der Festplattenpartition {disk_partition_name} auf dem Intelligence-Knoten {intelligence_node_id} liegt über dem Schwellenwert für eine hohe Nutzung von {system_usage_threshold} Millisekunden. “

Bei Auflösung des Ereignisses: „Die Speicherlatenz der Festplattenpartition {disk_partition_name} auf dem Intelligence-Knoten {intelligence_node_id} ist damit kleiner als der Schwellenwert für eine hohe Nutzung von {system_usage_threshold} Millisekunden. “

Wegen einer sehr großen Anzahl von E/A-Anforderungen kommt es möglicherweise vorübergehend zu einer hohen Speicherlatenz. Falls die Speicherlatenz länger als 30 Minuten hoch bleibt, sollten Sie die NSX Intelligence-Appliance eventuell auf einer Festplatte mit geringer Latenz bereitstellen oder das Speichergerät nicht für andere VMs freigeben.

Der Status des Intelligence-Knotens ist „Herabgestuft“.

Bei Erkennung des Ereignisses: „Intelligence-Knoten {intelligence_node_id} ist herabgestuft. “

Bei Auflösung des Ereignisses: „Intelligence-Knoten {intelligence_node_id} wird ordnungsgemäß ausgeführt. “

Rufen Sie die NSX API „GET /napp/api/v1/platform/monitor/category/health“ auf, um zu prüfen, welcher bestimmte Pod ausgefallen ist und welcher Grund dafür vorliegt. Rufen Sie den folgenden CLI-Befehl auf, um den herabgestuften Dienst kubectl rollout restart &ltstatefulset/deployment&gt &ltservice_name&gt -n &ltnamespace&gt neu zu starten.

Die IP-Blocknutzung ist sehr hoch.

Bei Erkennung des Ereignisses: „Die IP-Blocknutzung von {intent_path} ist sehr hoch. IP-Block nähert sich seiner Gesamtkapazität, die Erstellung eines Subnetzes mit IP-Block könnte fehlschlagen. “

Bei Auflösung des Ereignisses: „Die IP-Blocknutzung von {intent_path} ist damit kleiner als der Schwellenwert. “

Überprüfen Sie die IP-Blocknutzung. Verwenden Sie einen neuen IP-Block für die Ressourcenerstellung oder löschen Sie das nicht verwendete IP-Subnetz aus dem IP-Block. So überprüfen Sie das Subnetz, das für den IP-Block verwendet wird: Navigieren Sie von der NSX-Benutzeroberfläche zu „Netzwerk“ | „IP-Adresspools“ | Registerkarte „IP-Adresspools“. Wählen Sie IP-Pools aus, in denen der IP-Block verwendet wird, und überprüfen Sie die Spalte „Subnetze und zugeteilte IPs“ auf der Benutzeroberfläche. Wenn für den IP-Pool keine Zuteilung verwendet wurde und dieser zukünftig nicht mehr verwendet wird, löschen Sie das Subnetz oder den IP-Pool. Verwenden Sie die folgende API, um zu überprüfen, ob der IP-Block vom IP-Pool verwendet wird und ob eine IP-Zuteilung durchgeführt wurde: Um konfigurierte Subnetze eines IP-Pools abzurufen, rufen Sie die NSX API „GET /policy/api/v1/infra/ip-pools/&ltip-pool&gt/ip-subnets“ auf. Um IP-Zuweisungen zu erhalten, rufen Sie die NSX API „GET /policy/api/v1/infra/ip-pools/&ltip-pool&gt/ip-allocations“ auf. Hinweis: Der IP-Pool oder das Subnetz sollte nur gelöscht werden, wenn keine IP-Adressen zugewiesen sind oder Pool bzw. Subnetz zukünftig nicht verwendet wird.

Die IP-Pool-Nutzung ist sehr hoch.

Bei Erkennung des Ereignisses: „Die IP-Pool-Nutzung von {intent_path} ist sehr hoch. Der IP-Pool nähert sich seiner Gesamtkapazität. IP-Pool nähert sich seiner Gesamtkapazität. Die Entitäts-/Dienst-Erstellung hängt davon ab, ob die Zuteilung der IP aus dem IP-Pool fehlschlägt. “

Bei Auflösung des Ereignisses: „Die IP-Pool-Nutzung von {intent_path} ist jetzt normal. “

Überprüfen Sie die IP-Pool-Nutzung. Geben Sie nicht verwendete IP-Zuweisungen aus dem IP-Pool frei oder erstellen Sie einen neuen IP-Pool und verwenden Sie diesen. Navigieren Sie von der NSX-Benutzeroberfläche zu „Netzwerk“ | „IP-Adresspools“ | Registerkarte „IP-Adresspools“. Wählen Sie IP-Pools aus und überprüfen Sie die Spalte „Zugewiesene IPs“. Hier werden die aus dem IP-Pool zugewiesenen IPs angezeigt. Wenn der Benutzer sieht, dass IPs nicht verwendet werden, können diese IPs freigegeben werden. Um nicht verwendete IP-Zuweisungen freizugeben, rufen Sie die NSX API „DELETE /policy/api/v1/infra/ip-pools/&ltip-pool&gt/ip-allocations/&ltip-allocation&gt“ auf.

Eine Lizenz ist abgelaufen.

Bei Erkennung des Ereignisses: „Der Lizenzschlüssel {license_edition_type}, der mit {displayed_license_key} endet, ist abgelaufen. “

Bei Auflösung des Ereignisses: „Der abgelaufene Lizenzschlüssel {license_edition_type}, der mit {displayed_license_key} endet, wurde entfernt, aktualisiert oder läuft nicht mehr in Kürze ab. “

Fügen Sie eine neue, nicht abgelaufene Lizenz mithilfe der NSX-Benutzeroberfläche hinzu. Navigieren Sie dazu zu „System“ | „Lizenzen“, klicken Sie dann auf „HINZUFÜGEN“ und geben Sie den Schlüssel der neuen Lizenz an. Sie sollten die abgelaufene Lizenz löschen, indem Sie das Kontrollkästchen der Lizenz aktivieren und auf „LÖSCHEN“ klicken.

Eine Lizenz wird in Kürze ablaufen.

Bei Erkennung des Ereignisses: „Der Lizenzschlüssel {license_edition_type}, der mit {displayed_license_key} endet, läuft in Kürze ab. “

Bei Auflösung des Ereignisses: „Der ablaufende Lizenzschlüssel {license_edition_type}, der mit {displayed_license_key} endet, wurde entfernt, aktualisiert oder läuft nicht mehr in Kürze ab. “

In einigen Tagen läuft die Lizenz ab. Planen Sie eine neue, nicht abgelaufene Lizenz mithilfe der NSX-Benutzeroberfläche. Navigieren Sie dazu zu „System“ | „Lizenzen“, klicken Sie dann auf „HINZUFÜGEN“ und geben Sie den Schlüssel der neuen Lizenz an. Die abgelaufene Lizenz muss gelöscht werden, indem Sie das Kontrollkästchen der Lizenz aktivieren und auf „LÖSCHEN“ klicken.

Die CPU-Auslastung durch den Load Balancer ist sehr hoch.

Bei Erkennung des Ereignisses: „Die CPU-Auslastung von Load Balancer {entity_id} ist sehr hoch. Der Schwellenwert ist {system_usage_threshold} %. “

Bei Auflösung des Ereignisses: „Die CPU-Auslastung durch Load Balancer {entity_id} ist niedrig genug. Der Schwellenwert ist {system_usage_threshold} %. “

Wenn die CPU-Auslastung des Load Balancers höher als der Schwellenwert für die Systemauslastung ist, ist die Arbeitslast für diesen Load Balancer zu hoch. Skalieren Sie den Load Balancer-Dienst neu, indem Sie die Load Balancer-Größe von klein zu mittel oder von mittel zu groß ändern. Wenn die CPU-Nutzung dieses Load Balancers immer noch hoch ist, sollten Sie die Formfaktorgröße der Edge-Appliance anpassen oder die Load Balancer-Dienste für die jeweilige Arbeitslast auf andere Edge-Knoten verschieben.

Der Load Balancer-Dienst ist herabgestuft.

Bei Erkennung des Ereignisses: „Der Load Balancer-Dienst {entity_id} ist herabgestuft. “

Bei Auflösung des Ereignisses: „Der Load Balancer-Dienst {entity_id} ist nicht herabgestuft. “

Für zentralisierten Load Balancer: Prüfen Sie auf dem Standby-Edge-Knoten den Load Balancer-Status, da ein herabgestufter Status bedeutet, dass der Load Balancer-Status auf dem Standby-Edge-Knoten nicht bereit ist. Rufen Sie im Standby-Edge-Knoten den NSX-CLI-Befehl get load-balancer &ltlb-uuid&gt status auf. Wenn der LB-Status des Load Balancer-Dienstes „not_ready“ ist oder keine Ausgabe erfolgt, veranlassen Sie den Edge-Knoten, in den Wartungsmodus zu wechseln, und beenden Sie dann den Wartungsmodus. Für verteilte Load Balancer:
1. Holen Sie sich den detaillierten Status durch Aufrufen der NSX API „GET /policy/api/v1/infra/lb-services/&ltLBService&gt/detailed-status?source=realtime“.
2. Suchen Sie in der API-Ausgabe nach ESXi-Hosts, die eine Instanznummer ungleich null mit dem Status NOT_READY oder CONFLICT melden.
3. Rufen Sie auf dem ESXi-Hostknoten den NSX CLI-Befehl „get load-balancer &ltlb-uuid&gt status“ auf. Wenn „Conflict LSP“ gemeldet wird, prüfen Sie, ob dieser LSP mit einem anderen Load-Balancer-Dienst verbunden ist. Prüfen Sie, ob dieser Konflikt akzeptabel ist. Wenn „Not Ready LSP“ gemeldet wird, prüfen Sie den Status dieses LSP, indem Sie den NSX CLI-Befehl get logical-switch-port status aufrufen. HINWEIS: Ignorieren Sie den Alarm, wenn eine automatische Lösung in 5 Minuten möglich ist, da ein herabgestufter Status ein vorübergehender Status sein kann.

Der Distributed Load Balancer-Dienst ist inaktiv.

Bei Erkennung des Ereignisses: „Der verteilte Load Balancer-Dienst {entity_id} ist inaktiv. “

Bei Auflösung des Ereignisses: „Der verteilte Load Balancer-Dienst {entity_id} ist aktiv. “

Rufen Sie auf dem ESXi-Hostknoten den NSX CLI-Befehl „get load-balancer &ltlb-uuid&gt status“ auf. Wenn „Conflict LSP“ gemeldet wird, prüfen Sie, ob dieser LSP mit einem anderen Load-Balancer-Dienst verbunden ist. Prüfen Sie, ob dieser Konflikt akzeptabel ist. Wenn „Not Ready LSP“ gemeldet wird, prüfen Sie den Status dieses LSP, indem Sie den NSX CLI-Befehl get logical-switch-port status aufrufen.

Der zentralisierte Load Balancer-Dienst ist inaktiv.

Bei Erkennung des Ereignisses: „Der zentralisierte Load Balancer-Dienst {entity_id} ist inaktiv. “

Bei Auflösung des Ereignisses: „Der zentralisierte Load Balancer-Dienst {entity_id} ist aktiv. “

Prüfen Sie auf dem aktiven Edge-Knoten den Load Balancer-Status, indem Sie den NSX-CLI-Befehl get load-balancer &ltlb-uuid&gt status aufrufen. Wenn der LB-Status des Load Balancer-Dienstes „not_ready“ ist oder keine Ausgabe erfolgt, veranlassen Sie den Edge-Knoten, in den Wartungsmodus zu wechseln, und beenden Sie dann den Wartungsmodus.

Der virtuelle Load Balancer-Dienst ist inaktiv.

Bei Erkennung des Ereignisses: „Der virtuelle Load Balancer-Server {entity_id}ist inaktiv. “

Bei Auflösung des Ereignisses: „Der virtuelle Load Balancer-Server {entity_id} ist aktiv. “

Bestimmen Sie den Status des Load Balancer-Pools und überprüfen Sie dessen Konfiguration. Wenn er falsch konfiguriert ist, konfigurieren Sie ihn neu und entfernen Sie den Load Balancer-Pool vom virtuellen Server und fügen Sie ihn dann erneut dem virtuellen Server hinzu.

Der Load Balancer-Pool ist inaktiv.

Bei Erkennung des Ereignisses: „Der Status des Load Balancer-Pools {entity_id} ist inaktiv. “

Bei Auflösung des Ereignisses: „Der Status des Load Balancer-Pools {entity_id} ist aktiv.“

Konsultieren Sie den Load Balancer-Pool, um zu ermitteln, welche Mitglieder ausgefallen sind, indem Sie den NSX-CLI-Befehl get load-balancer &ltlb-uuid&gt pool &ltpool-uuid&gt status oder „NSX API GET /policy/api/v1/infra/lb-services/&ltlb-service-id&gt/lb-pools/&ltlb-pool-id&gt/detailed-status“ ausführen. Überprüfen Sie die Netzwerkkonnektivität des Load Balancer mit den betroffenen Poolmitgliedern. Überprüfen Sie die Netzwerkkonnektivität zwischen dem Load Balancer und den betroffenen Poolmitgliedern. Validieren Sie die Anwendungsintegrität der einzelnen Poolmitglieder. Validieren Sie auch mit dem konfigurierten Monitor die Integrität der einzelnen Poolmitglieder. Wenn der Integritätszustand des Mitglieds ermittelt wurde, wird der Status des Poolmitglieds basierend auf der Konfiguration „Anzahl bis zum erneuten Versuch“ in der Überwachung auf „fehlerfrei“ aktualisiert. Beheben Sie das Problem, indem Sie das Poolmitglied neu starten oder den Edge-Knoten in den Wartungsmodus versetzen und diesen dann wieder verlassen.

Die Auslastung des Load Balancers ist hoch.

Bei Erkennung des Ereignisses: „Die Auslastung des Load Balancer-Dienstes im Edge-Knoten {entity_id} ist hoch. Der Schwellenwert ist {system_usage_threshold} %. “

Bei Auflösung des Ereignisses: „Die Auslastung des Load Balancer-Dienstes im Edge-Knoten {entity_id} ist niedrig genug. Der Schwellenwert ist {system_usage_threshold} %. “

Wenn für diesen Edge-Knoten mehrere LB-Instanzen konfiguriert wurden, stellen Sie einen neuen Edge-Knoten bereit und verschieben Sie einige LB-Instanzen auf diesen neuen Edge-Knoten. Wenn nur eine einzelne LB-Instanz (klein/mittel/usw.) für einen Edge-Knoten derselben Größe (klein/mittel/usw.) konfiguriert wurde, stellen Sie einen neuen größeren Edge bereit und verschieben Sie die LB-Instanz auf den neuen Edge-Knoten.

Die Auslastung des Load Balancer-Poolmitglieds ist sehr hoch.

Bei Erkennung des Ereignisses: „Die Auslastung der Poolmitglieder im Edge-Knoten {entity_id} ist sehr hoch. Der Schwellenwert ist {system_usage_threshold} %. “

Bei Auflösung des Ereignisses: „Die Auslastung der Poolmitglieder im Edge-Knoten {entity_id} ist niedrig genug. Der Schwellenwert ist {system_usage_threshold} %. “

Stellen Sie einen neuen Edge-Knoten bereit und verschieben Sie den Load Balancer-Dienst von den vorhandenen Edge-Knoten auf den neu bereitgestellten Edge-Knoten.

Die Load Balancer-Konfiguration wurde wegen einer hohen Arbeitsspeichernutzung auf dem Edge-Knoten nicht realisiert.

Bei Erkennung des Ereignisses: „Die Load Balancer-Konfiguration {entity_id} wurde wegen einer hohen Arbeitsspeichernutzung auf dem Edge-Knoten nicht {transport_node_id} nicht realisiert. “

Bei Auflösung des Ereignisses: „Die Load Balancer-Konfiguration {entity_id} wird auf {transport_node_id} realisiert. “

Definieren Sie anstelle von großen Load Balancern bevorzugt kleine und mittlere Load Balancer. Verteilen Sie Load Balancer-Dienste auf die verfügbaren Edge-Knoten. Reduzieren Sie die Anzahl der definierten virtuellen Server.

Der Dienststatus ist „Inaktiv“.

Bei Erkennung des Ereignisses: „Der Dienst {mps_service_name} wird auf {transport_node_name} nicht ausgeführt. “

Bei Auflösung des Ereignisses: „Der Dienst {mps_service_name} wird auf {transport_node_name} ordnungsgemäß ausgeführt. “

1. Rufen Sie auf dem Edge-Knoten, der durch {nsx_edge_tn_name} identifiziert wird, den NSX CLI-Befehl get services auf, um den Status von {mps_service_name} zu überprüfen. Überprüfen Sie das /var/log/syslog, um den/die vermuteten Fehler zu finden.
2. Melden Sie sich auf dem durch {nsx_esx_tn_name} identifizierten Hostknoten bei der zugeordneten Malware-Prevention-Dienst-VM {entity_id} an und überprüfen Sie den Status von {mps_service_name}. Überprüfen Sie /var/log/syslog auf der zugeordneten Malware-Prevention-Dienst-VM {entity_id}, um den/die vermuteten Fehler zu finden.

Der Dienststatus ist „Herabgestuft“.

Bei Erkennung des Ereignisses: „Dienst {mps_service_name} ist auf {transport_node_name} herabgestuft. Die Kommunikation mit der Funktion „Dateiextraktion“ ist nicht möglich. Alle Funktionen zur Dateiextraktion auf {transport_node_name} werden angehalten. “

Bei Auflösung des Ereignisses: „Der Dienst {mps_service_name} wird auf {transport_node_name} ordnungsgemäß ausgeführt. “

1. Rufen Sie auf dem Edge-Knoten, der durch {nsx_edge_tn_name} identifiziert wird, den NSX CLI-Befehl get ids engine status auf, um den Status des Diensts file_extraction (IDS) zu überprüfen. Überprüfen Sie /var/log/syslog, um den/die vermuteten Fehler mit dem Dateiextraktionsdienst (IDS) und/oder {mps_service_name} zu finden.
2. Melden Sie sich auf dem durch {nsx_esx_tn_name} identifizierten Hostknoten bei der zugeordneten Malware-Prevention-Dienst-VM {entity_id} an und überprüfen Sie den Status des Diensts für Dateiextraktion (NXGI). Überprüfen Sie /var/log/syslog auf der zugeordneten Malware-Prevention-Dienst-VM {entity_id}, um den/die vermuteten Fehler zu finden.

Der Dienststatus ist „Herabgestuft“.

Bei Erkennung des Ereignisses: „Dienst {mps_service_name} ist auf NSX Application Platform herabgestuft. Die Kommunikation mit der Malware-Prevention-Datenbank ist nicht möglich. “

Bei Auflösung des Ereignisses: „Der Dienst {mps_service_name} wird auf der NSX Application Platform ordnungsgemäß ausgeführt. “

Navigieren Sie in der NSX-Benutzeroberfläche zu „System“ | „NSX Application Platform“ | „Kerndienste“, um zu überprüfen, welcher Dienst herabgestuft ist. Rufen Sie die NSX API „GET /napp/api/v1/platform/monitor/feature/health“ auf, um zu prüfen, welcher bestimmte Dienst ausgefallen ist und welcher Grund dafür vorliegt. Rufen Sie den folgenden CLI-Befehl auf, um den herabgestuften Dienst kubectl rollout restart &ltstatefulset/deployment&gt &ltservice_name&gt -n &ltnamespace&gt neu zu starten. Ermitteln Sie den Status des Dienstes „Malware-Prevention-Datenbank“.

Der Dienststatus ist „Herabgestuft“.

Bei Erkennung des Ereignisses: „Dienst {mps_service_name} ist auf NSX Application Platform herabgestuft. Die Kommunikation mit dem Dienst „analyst_api“ ist nicht möglich. Geprüfte Dateibewertungen sind möglicherweise nicht auf dem neuesten Stand. “

Bei Auflösung des Ereignisses: „Der Dienst {mps_service_name} wird auf der NSX Application Platform ordnungsgemäß ausgeführt. “

Navigieren Sie in der NSX-Benutzeroberfläche zu „System“ | „NSX Application Platform“ | „Kerndienste“, um zu überprüfen, welcher Dienst herabgestuft ist. Rufen Sie die NSX API „GET /napp/api/v1/platform/monitor/feature/health“ auf, um zu prüfen, welcher bestimmte Dienst ausgefallen ist und welcher Grund dafür vorliegt. Rufen Sie den folgenden CLI-Befehl auf, um den herabgestuften Dienst kubectl rollout restart &ltstatefulset/deployment&gt &ltservice_name&gt -n &ltnamespace&gt neu zu starten. Ermitteln Sie den Status des Dienstes „Malware-Prevention-Cloud-Connector“.

Der Dienststatus ist „Herabgestuft“.

Bei Erkennung des Ereignisses: „Dienst {mps_service_name} ist auf NSX Application Platform herabgestuft. Die Kommunikation mit dem NTICS-Reputationsdienst ist nicht möglich. Geprüfte Dateireputationen sind möglicherweise nicht auf dem neuesten Stand. “

Bei Auflösung des Ereignisses: „Der Dienst {mps_service_name} wird auf der NSX Application Platform ordnungsgemäß ausgeführt. “

Navigieren Sie in der NSX-Benutzeroberfläche zu „System“ | „NSX Application Platform“ | „Kerndienste“, um zu überprüfen, welcher Dienst herabgestuft ist. Rufen Sie die NSX API „GET /napp/api/v1/platform/monitor/feature/health“ auf, um zu prüfen, welcher bestimmte Dienst ausgefallen ist und welcher Grund dafür vorliegt. Rufen Sie den folgenden CLI-Befehl auf, um den herabgestuften Dienst kubectl rollout restart &ltstatefulset/deployment&gt &ltservice_name&gt -n &ltnamespace&gt neu zu starten. Ermitteln Sie, ob der Zugang zum NTICS-Dienst ausgefallen ist.

Die CPU-Auslastung durch den Manager-Knoten ist sehr hoch.

Bei Erkennung des Ereignisses: „Die CPU-Auslastung auf dem Manager-Knoten {entity_id} hat {system_resource_usage} % erreicht und ist damit größer als der oder gleich dem Schwellenwert für eine sehr hohe Nutzung von {system_usage_threshold} %. “

Bei Auflösung des Ereignisses: „Die CPU-Auslastung auf dem Manager-Knoten {entity_id} hat {system_resource_usage} % erreicht, und ist damit kleiner als der Schwellenwert für eine sehr hohe Nutzung von {system_usage_threshold} %. “

Überprüfen Sie die Konfiguration, die Dienstausführung und die Dimensionierung dieses Manager-Knotens. Ziehen Sie eine Anpassung der Formfaktorgröße der Manager-Appliance in Erwägung.

Die CPU-Auslastung durch den Manager-Knoten ist hoch.

Bei Erkennung des Ereignisses: „Die CPU-Auslastung auf dem Manager-Knoten {entity_id} hat {system_resource_usage} % erreicht und ist damit größer als der oder gleich dem Schwellenwert für eine hohe Nutzung von {system_usage_threshold} %. “

Bei Auflösung des Ereignisses: „Die CPU-Auslastung auf dem Manager-Knoten {entity_id} hat {system_resource_usage} % erreicht und ist damit kleiner als der Schwellenwert für eine hohe Nutzung von {system_usage_threshold} %. “

Überprüfen Sie die Konfiguration, die Dienstausführung und die Dimensionierung dieses Manager-Knotens. Ziehen Sie eine Anpassung der Formfaktorgröße der Manager-Appliance in Erwägung.

Die Arbeitsspeichernutzung des Manager-Knotens ist sehr hoch.

Bei Erkennung des Ereignisses: „Die Arbeitsspeichernutzung auf dem Manager-Knoten {entity_id} hat {system_resource_usage} % erreicht und ist damit größer als der oder gleich dem Schwellenwert für eine sehr hohe Nutzung von {system_usage_threshold} %. “

Bei Auflösung des Ereignisses: „Die Arbeitsspeichernutzung auf dem Manager-Knoten {entity_id} hat {system_resource_usage} % erreicht und ist damit kleiner als der Schwellenwert für eine sehr hohe Nutzung von {system_usage_threshold} %. “

Überprüfen Sie die Konfiguration, die Dienstausführung und die Dimensionierung dieses Manager-Knotens. Ziehen Sie eine Anpassung der Formfaktorgröße der Manager-Appliance in Erwägung.

Die Arbeitsspeichernutzung des Manager-Knotens ist hoch.

Bei Erkennung des Ereignisses: „Die Arbeitsspeichernutzung auf dem Manager-Knoten {entity_id} hat {system_resource_usage} % erreicht und ist damit größer als der oder gleich dem Schwellenwert für eine hohe Nutzung von {system_usage_threshold} %. “

Bei Auflösung des Ereignisses: „Die Arbeitsspeichernutzung auf dem Manager-Knoten {entity_id} hat {system_resource_usage} % erreicht, und ist damit kleiner als der Schwellenwert für eine hohe Nutzung von {system_usage_threshold} %. “

Überprüfen Sie die Konfiguration, die Dienstausführung und die Dimensionierung dieses Manager-Knotens. Ziehen Sie eine Anpassung der Formfaktorgröße der Manager-Appliance in Erwägung.

Die Festplattennutzung des Manager-Knotens ist sehr hoch.

Bei Erkennung des Ereignisses: „Die Festplattennutzung für die Manager-Knoten-Festplattenpartition {disk_partition_name} hat {system_resource_usage} % erreicht und ist damit größer als der oder gleich dem Schwellenwert für eine sehr hohe Nutzung von {system_usage_threshold} %. “

Bei Auflösung des Ereignisses: „Die Festplattennutzung für die Manager-Knoten-Festplattenpartition {disk_partition_name} hat {system_resource_usage} % erreicht und ist damit kleiner als der Schwellenwert für eine sehr hohe Nutzung von {system_usage_threshold} %. “

Untersuchen Sie die Partition mit hoher Auslastung und prüfen Sie, ob unerwartete große Dateien vorhanden sind, die entfernt werden können.

Die Festplattennutzung des Manager-Knotens ist hoch.

Bei Erkennung des Ereignisses: „Die Festplattennutzung für die Manager-Knoten-Festplattenpartition {disk_partition_name} hat {system_resource_usage} % erreicht und ist damit größer als der oder gleich dem Schwellenwert für eine hohe Nutzung von {system_usage_threshold} %. “

Bei Auflösung des Ereignisses: „Die Festplattennutzung für die Manager-Knoten-Festplattenpartition {disk_partition_name} hat {system_resource_usage} % erreicht, und ist damit kleiner als der Schwellenwert für eine hohe Nutzung von {system_usage_threshold} %. “

Untersuchen Sie die Partition mit hoher Auslastung und prüfen Sie, ob unerwartete große Dateien vorhanden sind, die entfernt werden können.

Die Festplattennutzung der Manager-Knotenkonfiguration ist sehr hoch.

Bei Erkennung des Ereignisses: „Die Festplattennutzung für die Manager-Knoten-Festplattenpartition „/config“ hat {system_resource_usage} % erreicht und ist damit größer als der oder gleich dem Schwellenwert für eine sehr hohe Nutzung von {system_usage_threshold} %. Dies kann ein Hinweis auf eine hohe Festplattennutzung durch den NSX-Datenspeicherdienst im Verzeichnis „/config/corfu“ sein. “

Bei Auflösung des Ereignisses: „Die Festplattennutzung für die Manager-Knoten-Festplattenpartition „/config“ hat {system_resource_usage} % erreicht, und ist damit kleiner als der Schwellenwert für eine sehr hohe Nutzung von {system_usage_threshold} %. “

Führen Sie das folgende Tool aus, und wenden Sie sich an GSS, wenn Probleme auftreten: /opt/vmware/tools/support/inspect_checkpoint_issues.py

Die Festplattennutzung der Manager-Knotenkonfiguration ist hoch.

Bei Erkennung des Ereignisses: „Die Festplattennutzung für die Manager-Knoten-Festplattenpartition „/config“ hat {system_resource_usage} % erreicht und ist damit größer als der oder gleich dem Schwellenwert für eine hohe Nutzung von {system_usage_threshold} %. Dies kann ein Hinweis auf eine steigende Festplattennutzung durch den NSX-Datenspeicherdienst im Verzeichnis „/config/corfu“ sein. “

Bei Auflösung des Ereignisses: „Die Festplattennutzung für die Manager-Knoten-Festplattenpartition „/config“ hat {system_resource_usage} % erreicht, und ist damit kleiner als der Schwellenwert für eine hohe Nutzung von {system_usage_threshold} %. “

Führen Sie das folgende Tool aus, und wenden Sie sich an GSS, wenn Probleme auftreten: /opt/vmware/tools/support/inspect_checkpoint_issues.py

Die Festplattennutzung der nonconfig-Instanz des Manager-Knotens ist sehr hoch.

Bei Erkennung des Ereignisses: „Die Festplattennutzung für die Manager-Knoten-Festplattenpartition „/nonconfig“ hat {system_resource_usage} % erreicht und ist damit größer als der oder gleich dem Schwellenwert für eine sehr hohe Nutzung von {system_usage_threshold} %. Dies kann ein Hinweis auf eine hohe Festplattennutzung durch den NSX-Datenspeicherdienst im Verzeichnis /nonconfig/corfu sein. “

Bei Auflösung des Ereignisses: „Die Festplattennutzung für die Manager-Knoten-Festplattenpartition „/nonconfig“ hat {system_resource_usage} % erreicht, und ist damit kleiner als der Schwellenwert für eine sehr hohe Nutzung von {system_usage_threshold} %. “

Führen Sie das folgende Tool aus und wenden Sie sich an GSS, wenn Probleme auftreten: /opt/vmware/tools/support/inspect_checkpoint_issues.py --nonconfig

Die Festplattennutzung der nonconfig-Instanz des Manager-Knotens ist hoch.

Bei Erkennung des Ereignisses: „Die Festplattennutzung für die Manager-Knoten-Festplattenpartition {disk_partition_name} hat {system_resource_usage} % erreicht und ist damit größer als der oder gleich dem Schwellenwert für eine hohe Nutzung von {system_usage_threshold} %. Dies kann ein Hinweis auf eine steigende Festplattennutzung durch den NSX-Datenspeicherdienst im Verzeichnis /nonconfig/corfu sein. “

Bei Auflösung des Ereignisses: „Die Festplattennutzung für die Manager-Knoten-Festplattenpartition „/nonconfig“ hat {system_resource_usage} % erreicht und ist damit kleiner als der Schwellenwert für eine hohe Nutzung von {system_usage_threshold} %. “

Führen Sie das folgende Tool aus, und wenden Sie sich an GSS, wenn Probleme auftreten: /opt/vmware/tools/support/inspect_checkpoint_issues.py --nonconfig

Die IP-Adresse des Manager-Knotens wird von einem anderen Gerät verwendet.

Bei Erkennung des Ereignisses: „Der Manager-Knoten {entity_id} mit IP-Adresse {duplicate_ip_address} wird derzeit von einem anderen Gerät im Netzwerk verwendet. “

Bei Auflösung des Ereignisses: „Das Gerät, das die dem Manager-Knoten {entity_id} zugewiesene IP-Adresse verwendet, scheint {duplicate_ip_address} nicht mehr zu verwenden. “

1. Legen Sie fest, welches Gerät die IP-Adresse des Managers verwendet, und weisen Sie dem Gerät eine neue IP-Adresse zu. Hinweis: Das Neukonfigurieren des Managers für die Verwendung einer neuen IP-Adresse wird nicht unterstützt.
2. Überprüfen Sie, ob der Pool/DHCP-Server für die statische IP-Adresse ordnungsgemäß konfiguriert ist.
3. Korrigieren Sie die IP-Adresse des Geräts, wenn sie manuell zugewiesen wird.

Die Festplatte des Verwaltungsknotens ist schreibgeschützt.

Bei Erkennung des Ereignisses: „Die folgende Festplattenpartition auf dem Manager-Knoten {entity_id} befindet sich im schreibgeschützten Modus: {disk_partition_name}“

Bei Auflösung des Ereignisses: „Die folgende Festplattenpartition auf dem Verwaltungsknoten {entity_id} wurde aus dem schreibgeschützten Modus wiederhergestellt: {disk_partition_name}“

Untersuchen Sie die schreibgeschützte Partition, um festzustellen, ob ein Neustart das Problem behebt oder die Festplatte ersetzt werden muss. Wenden Sie sich an GSS, um weitere Informationen zu erhalten.

Der DNS-Eintrag für den Manager-FQDN fehlt.

Bei Erkennung des Ereignisses: „Die DNS-Konfiguration für den Manager-Knoten {manager_node_name} ({entity_id}) ist falsch. Der Manager-Knoten ist ein Dual-Stack, und/oder es wird ein CA-signiertes API-Zertifikat verwendet, aber die IP-Adressen des Manager-Knotens werden nicht in einen FQDN oder unterschiedliche FQDNs aufgelöst. “

Bei Auflösung des Ereignisses: „Die DNS-Konfiguration für den Manager-Knoten {manager_node_name} ({entity_id}) ist richtig. Entweder ist der Manager-Knoten kein Dual-Stack, und das von einer Zertifizierungsstelle signierte API-Zertifikat wird nicht mehr verwendet, oder die IP-Adressen des Manager-Knotens werden in denselben FQDN aufgelöst. “

1. Stellen Sie sicher, dass die richtigen DNS-Server im Manager-Knoten konfiguriert sind.
2. Stellen Sie sicher, dass die richtigen A-Datensätze und PTR-Datensätze in den DNS-Servern so konfiguriert sind, dass der umgekehrte Lookup der IP-Adressen des Manager-Knotens denselben FQDN zurückgibt und der Forward-Lookup des FQDN alle IP-Adressen des Manager-Knotens zurückgibt.
3. Wenn der Manager-Knoten kein Dual-Stack ist, ersetzen Sie alternativ das von der Zertifizierungsstelle signierte Zertifikat für den API-Diensttyp durch ein selbstsigniertes Zertifikat.

Fehlender FQDN-Eintrag für die Manager-VIP.

Bei Erkennung des Ereignisses: „Im Falle eines Dual-Stack- oder CA-signierten API-Zertifikats für einen NSX Manager sollten die virtuelle IPv4-Adresse {ipv4_address} und die virtuelle IPv6-Adresse {ipv6_address} für den Manager-Knoten {entity_id} in denselben FQDN aufgelöst werden. “

Bei Auflösung des Ereignisses: „Dual-Stack-VIP-Adressen für Manager-Knoten {entity_id} wurden in denselben FQDN aufgelöst. “

Überprüfen Sie den DNS-Eintrag für die VIP-Adressen, um festzustellen, ob sie in denselben FQDN aufgelöst werden.

Nicht übereinstimmende MTU-Konfiguration zwischen Transportknoten, die an dieselbe Transportzone angeschlossen sind.

Bei Erkennung des Ereignisses: „Nicht übereinstimmende MTU-Konfiguration zwischen Transportknoten (ESXi, KVM und Edge), die an dieselbe Transportzone angeschlossen sind. Wenn die MTU-Werte für alle Switches, die mit derselben Transportzone verbunden sind, nicht konsistent sind, verursacht das Verbindungsprobleme. “

Bei Auflösung des Ereignisses: „Alle MTU-Werte zwischen Transportknoten, die an dieselbe Transportzone angeschlossen sind, sind jetzt konsistent. “

1. Navigieren Sie zu „System“ | „Fabric“ | „Einstellungen“ | „Prüfung der MTU-Konfiguration“ | „Inkonsistent“ auf der NSX-Benutzeroberfläche, um weitere Details zu Nichtübereinstimmungen zu überprüfen.
2. Legen Sie auf allen Switches, die an dieselbe Transportzone angeschlossen sind, denselben MTU-Wert fest, indem Sie die NSX API PUT /api/v1/host-switch-profiles/&lthost-switch-profile-id&gt mit „mtu“ im Anforderungstext oder API PUT /api/v1/global-configs/SwitchingGlobalConfig mit „physical_uplink_mtu“ im Anforderungstext aufrufen.

Die Konfiguration der MTU des globalen Routers ist größer als die MTU der Overlay-Transportzone.

Bei Erkennung des Ereignisses: „Die MTU-Konfiguration des globalen Routers ist größer als die MTU der Switches in der Overlay-Transportzone, die mit Tier0 oder Tier1 verbunden ist. Der MTU-Wert des globalen Routers sollte kleiner sein als der MTU-Wert aller Switches und mindestens 100 betragen, da wir für die Geneve-Kapselung ein Kontingent von 100 benötigen. “

Bei Auflösung des Ereignisses: „Die MTU des globalen Routers ist jetzt kleiner als die MTU der Overlay-Transportzone. “

1. Navigieren Sie zu „System“ | „Fabric“ | „Einstellungen“ | „Prüfung der MTU-Konfiguration“ | „Inkonsistent“ auf der NSX-Benutzeroberfläche, um weitere Details zu Nichtübereinstimmungen zu überprüfen.
2. Legen Sie den größeren MTU-Wert auf Switches fest, indem Sie die NSX API PUT /api/v1/host-switch-profiles/&lthost-switch-profile-id&gt mit „mtu“ im Anforderungstext oder API PUT /api/v1/global-configs/SwitchingGlobalConfig mit „physical_uplink_mtu“ im Anforderungstext aufrufen.
3. Oder legen Sie den kleineren MTU-Wert der globalen Routerkonfiguration fest, indem Sie die NSX API PUT /api/v1/global-configs/RoutingGlobalConfig mit logical_uplink_mtu im Anforderungstext aufrufen.

Die SNAT-Portnutzung auf dem Gateway ist hoch.

Bei Erkennung des Ereignisses: „Die SNAT-Portnutzung auf dem logischen Router {entity_id} für die SNAT-IP {snat_ip_address} hat den Schwellenwert für hohe Nutzung von {system_usage_threshold} % erreicht. Neue Flows werden nicht mit SNAT übersetzt, wenn die Nutzung den maximalen Grenzwert erreicht. “

Bei Auflösung des Ereignisses: „Die SNAT-Portnutzung auf dem logischen Router {entity_id} für die SNAT-IP {snat_ip_address} ist damit kleiner als der Schwellenwert für hohe Nutzung von {system_usage_threshold} %. “

Melden Sie sich als Admin-Benutzer beim Edge-Knoten an und rufen Sie den NSX CLI-Befehl get firewall &ltLR_INT_UUID&gt connection state auf, indem Sie die richtige Schnittstellen-UUID verwenden und verschiedene SNAT-Zuordnungen für die SNAT-IP {snat_ip_address} überprüfen. Stellen Sie sicher, dass es sich bei den das Gateway durchlaufenden Datenverkehrsströmen nicht um einen Denial-of-Service-Angriff oder anormalen Burst handelt. Wenn jedoch bei scheinbar normaler Last des Datenverkehrs der Alarmschwellenwert erreicht wird, sollten Sie weitere SNAT-IP-Adressen hinzufügen, um die Last zu verteilen, oder neuen Datenverkehr an einen anderen Edge-Knoten weiterleiten.

Manager-Knoten hat erkannt, dass NCP ausgefallen oder fehlerhaft ist.

Bei Erkennung des Ereignisses: „Manager-Knoten hat erkannt, dass NCP ausgefallen oder fehlerhaft ist. “

Bei Auflösung des Ereignisses: „Der Manager-Knoten hat erkannt, dass der NCP wieder betriebsbereit oder fehlerfrei ist. “

Um nach den Clustern zu suchen, die Probleme aufweisen, navigieren Sie auf der NSX-Benutzeroberfläche zur Seite „Alarme“. Der Wert „Entitätsname“ für diese Alarminstanz identifiziert den Clusternamen. Oder rufen Sie die NSX API GET /api/v1/systemhealth/container-cluster/ncp/status auf, um alle Clusterstatus abzurufen und den Namen aller Cluster zu ermitteln, die den Status INAKTIV oder UNBEKANNT zurückgeben. Suchen Sie dann in der NSX-Benutzeroberfläche auf der Seite „Bestand“ | „Container“ | „Cluster“ nach dem Namen des Clusters, und klicken Sie auf die Registerkarte „Knoten“, in der alle Kubernetes- und PAS-Clustermitglieder aufgeführt sind. Für Kubernetes-Cluster:
1. Überprüfen Sie die NCP-Pod-Aktivität, indem Sie den K8s-Master-Knoten unter sämtlichen Cluster-Mitgliedern finden, und melden Sich sich beim Master-Knoten an. Rufen Sie dann den Befehl kubectl get pods --all-namespaces auf. Wenn ein Problem mit dem NCP-Pod vorliegt, verwenden Sie den Befehl „kubectl logs“, um das Problem zu überprüfen und den Fehler zu beheben.
2. Überprüfen Sie die Verbindung zwischen NCP und dem Kubernetes-API-Server. Sie können die NSX-CLI innerhalb des NCP-Pods verwenden, um diesen Verbindungsstatus zu überprüfen, indem Sie folgende Befehle auf der Master-VM ausführen. kubectl exec -it &ltNCP-Pod-Name&gt -n nsx-system bash nsxcli get ncp-k8s-api-server status. Wenn ein Problem mit der Verbindung besteht, überprüfen Sie die Netzwerkkonfigurationen und NCP-Konfigurationen.
3. Überprüfen Sie die Verbindung zwischen NCP und NSX Manager. Sie können die NSX-CLI innerhalb des NCP-Pods verwenden, um diesen Verbindungsstatus zu überprüfen, indem Sie folgende Befehle auf der Master-VM ausführen. kubectl exec -it &ltNCP-Pod-Name&gt -n nsx-system bash nsxcli get ncp-nsx status. Wenn ein Problem mit der Verbindung besteht, überprüfen Sie die Netzwerkkonfigurationen und NCP-Konfigurationen. Für PAS-Cluster:
1. Überprüfen Sie die Netzwerkverbindungen zwischen den virtuellen Maschinen und beheben Sie Netzwerkprobleme.
2. Überprüfen Sie den Status von Knoten und Diensten und korrigieren Sie abgestürzte Knoten oder Dienste. Verwenden Sie die Befehle bosh vms und bosh instances -p, um den Status von Knoten und Diensten zu überprüfen.

Die Agents, die innerhalb der Knoten-VM ausgeführt werden, scheinen auf DPU ausgefallen zu sein.

Bei Erkennung des Ereignisses: „Die Agents, die innerhalb der Knoten-VM ausgeführt werden, scheinen auf DPU {dpu_id} ausgefallen zu sein. “

Bei Auflösung des Ereignisses: „Die Agents innerhalb der Knoten-VM werden auf DPU {dpu_id} ausgeführt. “

1. Wenn Vmk50 auf DPU {dpu_id} fehlt, finden Sie weitere Einzelheiten in diesem Knowledgebase-Artikel: https://kb.vmware.com/s/article/67432.
2. Wenn Hyperbus 4094 auf DPU {dpu_id} fehlt, kann ein Neustart von nsx-cfgagent auf DPU {dpu_id} oder ein Neustart der Container-Host-VM helfen.
3. Wenn Container-Host-VIF blockiert ist: Überprüfen Sie die Verbindung zum Controller, um sicherzustellen, dass alle Konfigurationen nach unten gesendet werden.
4. Wenn nsx-cfg-agent auf DPU {dpu_id} angehalten wurde, starten Sie nsx-cfgagent auf DPU {dpu_id} neu.
5. Wenn das node-agent-Paket fehlt, überprüfen Sie, ob das node-agent-Paket erfolgreich in der Container-Host-VM installiert wurde.
6. Wenn die Schnittstelle für node-agent auf der Container-Host-VM ausgefallen ist: Überprüfen Sie den Status der eth1-Schnittstelle innerhalb der Container-Host-VM.

Die Agents, die innerhalb der Knoten-VM ausgeführt werden, scheinen ausgefallen zu sein.

Bei Erkennung des Ereignisses: „Die Agents, die innerhalb der Knoten-VM ausgeführt werden, scheinen ausgefallen zu sein. “

Bei Auflösung des Ereignisses: „Die Agents innerhalb der Knoten-VM werden ausgeführt. “

Für ESX:
1. Wenn Vmk50 fehlt, finden Sie weitere Einzelheiten in diesem Knowledgebase-Artikel: https://kb.vmware.com/s/article/67432.
2. Wenn Hyperbus 4094 fehlt: Der Neustart von nsx-cfgagent bzw. der Container-Host-VM kann hilfreich sein.
3. Wenn Container-Host-VIF blockiert ist: Überprüfen Sie die Verbindung zum Controller, um sicherzustellen, dass alle Konfigurationen nach unten gesendet werden.
4. Wenn nsx-cfg-Agent angehalten wurde: Starten Sie nsx-cfgagent neu. Für KVM:
1. Wenn der Hyperbus-Namespace fehlt: Der Neustart von nsx-opsagent kann dazu beitragen, den Namespace neu zu erstellen.
2. Wenn die Hyperbus-Schnittstelle innerhalb des Hyperbus-Namespaces fehlt: Der Neustart von nsx-opsagent kann hilfreich sein.
3. Wenn nsx-agent angehalten wurde: Starten Sie nsx-agent neu. Für ESX und KVM:
1. Wenn das node-agent-Paket fehlt, überprüfen Sie, ob das node-agent-Paket erfolgreich in der Container-Host-VM installiert wurde.
2. Wenn die Schnittstelle für node-agent auf der Container-Host-VM ausgefallen ist: Überprüfen Sie den Status der eth1-Schnittstelle innerhalb der Container-Host-VM.

Der NSX Application Platform-Cluster wird vom NSX-Verwaltungscluster getrennt.

Bei Erkennung des Ereignisses: „Der NSX Application Platform-Cluster {napp_cluster_id} wird vom NSX-Verwaltungscluster getrennt. “

Bei Auflösung des Ereignisses: „Der NSX Application Platform-Cluster {napp_cluster_id} wird erneut mit dem NSX-Verwaltungscluster verbunden. “

Überprüfen Sie, ob das Manager-Clusterzertifikat, die Manager-Knotenzertifikate, das kafka-Zertifikat und das Ingress-Zertifikat sowohl auf NSX Manager als auch auf dem NSX Application Platform-Cluster übereinstimmen. Überprüfen Sie das Ablaufdatum der oben genannten Zertifikate, um sicherzustellen, dass sie gültig sind. Überprüfen Sie die Netzwerkverbindung zwischen NSX Manager und dem NSX Application Platform-Cluster und beheben Sie etwaige Netzwerkverbindungsfehler.

Langsame Datenverarbeitung im Messaging-Thema „Raw Flow“ erkannt.

Bei Erkennung des Ereignisses: „Die Anzahl der ausstehenden Meldungen im Messaging-Thema ‚Raw Flow‘ liegt über dem Schwellenwert für ausstehende Meldungen von {napp_messaging_lag_threshold}. “

Bei Auflösung des Ereignisses: „Die Anzahl der ausstehenden Meldungen im Messaging-Thema ‚Raw Flow‘ ist damit kleiner als der Schwellenwert für ausstehende Meldungen von {napp_messaging_lag_threshold}. “

Fügen Sie Knoten hinzu und führen Sie dann eine vertikale Hochskalierung des NSX Application Platform-Clusters durch. Wenn Engpässe einem bestimmten Dienst zugeschrieben werden können, wie z. B. dem Analysedienst, skalieren Sie den entsprechenden Dienst beim Hinzufügen der neuen Knoten vertikal hoch.

Langsame Datenverarbeitung im Messaging-Thema „Over Flow“ erkannt.

Bei Erkennung des Ereignisses: „Die Anzahl der ausstehenden Meldungen im Messaging-Thema ‚Over Flow‘ liegt über dem Schwellenwert für ausstehende Meldungen von {napp_messaging_lag_threshold}. “

Bei Auflösung des Ereignisses: „Die Anzahl der ausstehenden Meldungen im Messaging-Thema ‚Over Flow‘ ist damit kleiner als der Schwellenwert für ausstehende Meldungen von {napp_messaging_lag_threshold}. “

Fügen Sie Knoten hinzu und führen Sie dann eine vertikale Hochskalierung des NSX Application Platform-Clusters durch. Wenn Engpässe einem bestimmten Dienst zugeschrieben werden können, wie z. B. dem Analysedienst, skalieren Sie den entsprechenden Dienst beim Hinzufügen der neuen Knoten vertikal hoch.

Ein Transportknoten ist vom Messaging-Broker seines NSX Application Platform-Clusters getrennt. Die Datenerfassung ist davon betroffen.

Bei Erkennung des Ereignisses: „Der Flow-Exporter auf dem Transportknoten {entity_id} ist vom Messaging-Broker des NSX Application Platform-Clusters getrennt. Die Datenerfassung ist davon betroffen. “

Bei Auflösung des Ereignisses: „Der Flow-Exporter auf dem Transportknoten {entity_id} hat die Verbindung zum Messaging-Broker des NSX Application Platform-Clusters wiederhergestellt. “

Starten Sie den Messaging-Dienst neu, wenn er nicht im NSX Application Platform-Cluster ausgeführt wird. Beheben Sie den Netzwerkverbindungsfehler zwischen dem Flow-Exporter des Transportknotens und dem NSX Application Platform-Cluster.

Ein Transportknoten ist vom Messaging-Broker des Intelligence-Knotens getrennt. Die Datenerfassung auf DPU ist davon betroffen.

Bei Erkennung des Ereignisses: „Der Flow-Exporter auf dem Transportknoten {entity_id} DPU {dpu_id} ist vom Messaging-Broker des Intelligence-Knotens getrennt. Die Datenerfassung ist davon betroffen. “

Bei Auflösung des Ereignisses: „Der Flow-Exporter auf dem Transportknoten {entity_id} DPU {dpu_id} hat die Verbindung zum Messaging-Broker des Intelligence-Knotens wiederhergestellt. “

Starten Sie den Nachrichtendienst neu, wenn er nicht im Intelligence-Knoten ausgeführt wird. Beheben Sie den Netzwerkverbindungsfehler zwischen dem Flow-Exporter des Transportknotens und dem Intelligence-Knoten.

CPU-Auslastung für NSX Application Platform-Cluster ist sehr hoch.

Bei Erkennung des Ereignisses: „Die CPU-Auslastung des NSX Application Platform-Clusters {napp_cluster_id} liegt über dem Schwellenwert für eine sehr hohe Nutzung von {system_usage_threshold} %. “

Bei Auflösung des Ereignisses: „Die CPU-Auslastung des NSX Application Platform-Clusters {napp_cluster_id} ist damit kleiner als der Schwellenwert für eine sehr hohe Nutzung von {system_usage_threshold} %. “

Navigieren Sie auf der NSX-Benutzeroberfläche zu „System“ | „NSX Application Platform“ | „Kerndienste“ und überprüfen Sie das Feld „Systemlast“ der einzelnen Dienste, um zu sehen, welcher Dienst unter Druck steht. Prüfen Sie, ob die Last reduziert werden kann. Wenn mehr Rechenleistung erforderlich ist, klicken Sie auf die Schaltfläche „Horizontal skalieren“, um mehr Ressourcen anzufordern.

CPU-Auslastung für NSX Application Platform-Cluster ist hoch.

Bei Erkennung des Ereignisses: „Die CPU-Auslastung des NSX Application Platform-Clusters {napp_cluster_id} liegt über dem Schwellenwert für eine hohe Nutzung von {system_usage_threshold} %. “

Bei Auflösung des Ereignisses: „Die CPU-Auslastung des NSX Application Platform-Clusters {napp_cluster_id} ist damit kleiner als der Schwellenwert für eine hohe Nutzung von {system_usage_threshold} %. “

Navigieren Sie auf der NSX-Benutzeroberfläche zu „System“ | „NSX Application Platform“ | „Kerndienste“ und überprüfen Sie das Feld „Systemlast“ der einzelnen Dienste, um zu sehen, welcher Dienst unter Druck steht. Prüfen Sie, ob die Last reduziert werden kann. Wenn mehr Rechenleistung erforderlich ist, klicken Sie auf die Schaltfläche „Horizontal skalieren“, um mehr Ressourcen anzufordern.

Arbeitsspeichernutzung für NSX Application Platform-Cluster ist sehr hoch.

Bei Erkennung des Ereignisses: „Die Arbeitsspeichernutzung des NSX Application Platform-Clusters {napp_cluster_id} liegt über dem Schwellenwert für eine sehr hohe Nutzung von {system_usage_threshold} %. “

Bei Auflösung des Ereignisses: „Die Arbeitsspeichernutzung des NSX Application Platform-Clusters {napp_cluster_id} ist damit kleiner als der Schwellenwert für eine sehr hohe Nutzung von {system_usage_threshold} %. “

Navigieren Sie auf der NSX-Benutzeroberfläche zu „System“ | „NSX Application Platform“ | „Kerndienste“ und überprüfen Sie das Feld „Arbeitsspeicher“ der einzelnen Dienste, um zu sehen, welcher Dienst unter Druck steht. Prüfen Sie, ob die Last reduziert werden kann. Wenn mehr Arbeitsspeicher erforderlich ist, klicken Sie auf die Schaltfläche „Horizontal skalieren“, um mehr Ressourcen anzufordern.

Arbeitsspeichernutzung für NSX Application Platform-Cluster ist hoch.

Bei Erkennung des Ereignisses: „Die Arbeitsspeichernutzung des NSX Application Platform-Clusters {napp_cluster_id} liegt über dem Schwellenwert für eine hohe Nutzung von {system_usage_threshold} %. “

Bei Auflösung des Ereignisses: „Die Arbeitsspeichernutzung des NSX Application Platform-Clusters {napp_cluster_id} ist damit kleiner als der Schwellenwert für eine hohe Nutzung von {system_usage_threshold} %. “

Navigieren Sie auf der NSX-Benutzeroberfläche zu „System“ | „NSX Application Platform“ | „Kerndienste“ und überprüfen Sie das Feld „Arbeitsspeicher“ der einzelnen Dienste, um zu sehen, welcher Dienst unter Druck steht. Prüfen Sie, ob die Last reduziert werden kann. Wenn mehr Arbeitsspeicher erforderlich ist, klicken Sie auf die Schaltfläche „Horizontal skalieren“, um mehr Ressourcen anzufordern.

Festplattennutzung für NSX Application Platform-Cluster ist sehr hoch.

Bei Erkennung des Ereignisses: „Die Festplattennutzung des NSX Application Platform-Clusters {napp_cluster_id} liegt über dem Schwellenwert für eine sehr hohe Nutzung von {system_usage_threshold} %. “

Bei Auflösung des Ereignisses: „Die Festplattennutzung des NSX Application Platform-Clusters {napp_cluster_id} ist damit kleiner als der Schwellenwert für eine sehr hohe Nutzung von {system_usage_threshold} %. “

Navigieren Sie auf der NSX-Benutzeroberfläche zu „System“ | „NSX Application Platform“ | „Kerndienste“ und überprüfen Sie das Feld „Speicher“ der einzelnen Dienste, um zu sehen, welcher Dienst unter Druck steht. Prüfen Sie, ob die Last reduziert werden kann. Wenn mehr Festplattenspeicher erforderlich ist, klicken Sie auf die Schaltfläche „Horizontal skalieren“, um mehr Ressourcen anzufordern. Wenn der Datenspeicherdienst unter Druck steht, besteht eine weitere Möglichkeit darin, auf die Schaltfläche „Vertikal hochskalieren“ zu klicken, um die Festplattengröße zu erhöhen.

Festplattennutzung für NSX Application Platform-Cluster ist hoch.

Bei Erkennung des Ereignisses: „Die Festplattennutzung des NSX Application Platform-Clusters {napp_cluster_id} liegt über dem Schwellenwert für eine hohe Nutzung von {system_usage_threshold} %. “

Bei Auflösung des Ereignisses: „Die Festplattennutzung des NSX Application Platform-Clusters {napp_cluster_id} ist damit kleiner als der Schwellenwert für eine hohe Nutzung von {system_usage_threshold} %. “

Navigieren Sie auf der NSX-Benutzeroberfläche zu „System“ | „NSX Application Platform“ | „Kerndienste“ und überprüfen Sie das Feld „Speicher“ der einzelnen Dienste, um zu sehen, welcher Dienst unter Druck steht. Prüfen Sie, ob die Last reduziert werden kann. Wenn mehr Festplattenspeicher erforderlich ist, klicken Sie auf die Schaltfläche „Horizontal skalieren“, um mehr Ressourcen anzufordern. Wenn der Datenspeicherdienst unter Druck steht, besteht eine weitere Möglichkeit darin, auf die Schaltfläche „Vertikal hochskalieren“ zu klicken, um die Festplattengröße zu erhöhen.

Der Gesamtstatus des NSX Application Platform-Clusters ist „Herabgestuft“.

Bei Erkennung des Ereignisses: „Der Gesamtstatus des NSX Application Platform-Clusters {napp_cluster_id} ist ‚Herabgestuft‘. “

Bei Auflösung des Ereignisses: „Der NSX Application Platform-Cluster {napp_cluster_id} wird ordnungsgemäß ausgeführt. “

Erhalten Sie weitere Informationen aus den Alarmen der Knoten und Dienste.

Der Gesamtstatus des NSX Application Platform-Clusters ist „Inaktiv“.

Bei Erkennung des Ereignisses: „Der Gesamtstatus des NSX Application Platform-Clusters {napp_cluster_id} ist ‚Inaktiv‘. “

Bei Auflösung des Ereignisses: „Der NSX Application Platform-Cluster {napp_cluster_id} wird ordnungsgemäß ausgeführt. “

Erhalten Sie weitere Informationen aus den Alarmen der Knoten und Dienste.

CPU-Auslastung für NSX Application Platform-Knoten ist sehr hoch.

Bei Erkennung des Ereignisses: „Die CPU-Auslastung des NSX Application Platform-Knotens {napp_node_name} liegt über dem Schwellenwert für eine sehr hohe Nutzung von {system_usage_threshold} %. “

Bei Auflösung des Ereignisses: „Die CPU-Auslastung des NSX Application Platform-Knotens {napp_node_name} ist damit kleiner als der Schwellenwert für eine sehr hohe Nutzung von {system_usage_threshold} %. “

Navigieren Sie auf der NSX-Benutzeroberfläche zu „System“ | „NSX Application Platform“ | „Kerndienste“ und überprüfen Sie das Feld „Systemlast“ der einzelnen Dienste, um zu sehen, welcher Dienst unter Druck steht. Prüfen Sie, ob die Last reduziert werden kann. Wenn nur eine kleine Minderheit der Knoten eine hohe CPU-Auslastung hat, verschiebt Kubernetes standardmäßig die Dienste automatisch. Wenn die meisten Knoten eine hohe CPU-Auslastung haben und die Last nicht reduziert werden kann, klicken Sie auf die Schaltfläche „Horizontal skalieren“ um mehr Ressourcen anzufordern.

CPU-Auslastung für NSX Application Platform-Knoten ist hoch.

Bei Erkennung des Ereignisses: „Die CPU-Auslastung des NSX Application Platform-Knotens {napp_node_name} liegt über dem Schwellenwert für eine hohe Nutzung von {system_usage_threshold} %. “

Bei Auflösung des Ereignisses: „Die CPU-Auslastung des NSX Application Platform-Knotens {napp_node_name} ist damit kleiner als der Schwellenwert für eine hohe Nutzung von {system_usage_threshold} %. “

Navigieren Sie auf der NSX-Benutzeroberfläche zu „System“ | „NSX Application Platform“ | „Kerndienste“ und überprüfen Sie das Feld „Systemlast“ der einzelnen Dienste, um zu sehen, welcher Dienst unter Druck steht. Prüfen Sie, ob die Last reduziert werden kann. Wenn nur eine kleine Minderheit der Knoten eine hohe CPU-Auslastung hat, verschiebt Kubernetes standardmäßig die Dienste automatisch. Wenn die meisten Knoten eine hohe CPU-Auslastung haben und die Last nicht reduziert werden kann, klicken Sie auf die Schaltfläche „Horizontal skalieren“ um mehr Ressourcen anzufordern.

Arbeitsspeichernutzung für NSX Application Platform-Knoten ist sehr hoch.

Bei Erkennung des Ereignisses: „Die Arbeitsspeichernutzung des NSX Application Platform-Knotens {napp_node_name} liegt über dem Schwellenwert für eine sehr hohe Nutzung von {system_usage_threshold} %. “

Bei Auflösung des Ereignisses: „Die Arbeitsspeichernutzung des NSX Application Platform-Knotens {napp_node_name} ist damit kleiner als der Schwellenwert für eine sehr hohe Nutzung von {system_usage_threshold} %. “

Navigieren Sie auf der NSX-Benutzeroberfläche zu „System“ | „NSX Application Platform“ | „Kerndienste“ und überprüfen Sie das Feld „Arbeitsspeicher“ der einzelnen Dienste, um zu sehen, welcher Dienst unter Druck steht. Prüfen Sie, ob die Last reduziert werden kann. Wenn nur eine kleine Minderheit der Knoten eine hohe Arbeitsspeichernutzung hat, verschiebt Kubernetes standardmäßig die Dienste automatisch. Wenn die meisten Knoten eine hohe Arbeitsspeichernutzung haben und die Last nicht reduziert werden kann, klicken Sie auf die Schaltfläche „Horizontal skalieren“ um mehr Ressourcen anzufordern.

Arbeitsspeichernutzung für NSX Application Platform-Knoten ist hoch.

Bei Erkennung des Ereignisses: „Die Arbeitsspeichernutzung des NSX Application Platform-Knotens {napp_node_name} liegt über dem Schwellenwert für eine hohe Nutzung von {system_usage_threshold} %. “

Bei Auflösung des Ereignisses: „Die Arbeitsspeichernutzung des NSX Application Platform-Knotens {napp_node_name} ist damit kleiner als der Schwellenwert für eine hohe Nutzung von {system_usage_threshold} %. “

Navigieren Sie auf der NSX-Benutzeroberfläche zu „System“ | „NSX Application Platform“ | „Kerndienste“ und überprüfen Sie das Feld „Arbeitsspeicher“ der einzelnen Dienste, um zu sehen, welcher Dienst unter Druck steht. Prüfen Sie, ob die Last reduziert werden kann. Wenn nur eine kleine Minderheit der Knoten eine hohe Arbeitsspeichernutzung hat, verschiebt Kubernetes standardmäßig die Dienste automatisch. Wenn die meisten Knoten eine hohe Arbeitsspeichernutzung haben und die Last nicht reduziert werden kann, klicken Sie auf die Schaltfläche „Horizontal skalieren“ um mehr Ressourcen anzufordern.

Festplattennutzung für NSX Application Platform-Knoten ist sehr hoch.

Bei Erkennung des Ereignisses: „Die Festplattennutzung des NSX Application Platform-Knotens {napp_node_name} liegt über dem Schwellenwert für eine sehr hohe Nutzung von {system_usage_threshold} %. “

Bei Auflösung des Ereignisses: „Die Festplattennutzung des NSX Application Platform-Knotens {napp_node_name} ist damit kleiner als der Schwellenwert für eine sehr hohe Nutzung von {system_usage_threshold} %. “

Navigieren Sie auf der NSX-Benutzeroberfläche zu „System“ | „NSX Application Platform“ | „Kerndienste“ und überprüfen Sie das Feld „Speicher“ der einzelnen Dienste, um zu sehen, welcher Dienst unter Druck steht. Bereinigen Sie nicht verwendete Daten oder Protokolle, um Festplattenressourcen freizugeben und zu sehen, ob die Last reduziert werden kann. Wenn mehr Festplattenspeicher benötigt wird, skalieren Sie den belasteten Dienst aus. Wenn der Datenspeicherdienst unter Druck steht, besteht eine weitere Möglichkeit darin, auf die Schaltfläche „Vertikal hochskalieren“ zu klicken, um die Festplattengröße zu erhöhen.

Festplattennutzung für NSX Application Platform-Knoten ist hoch.

Bei Erkennung des Ereignisses: „Die Festplattennutzung des NSX Application Platform-Knotens {napp_node_name} liegt über dem Schwellenwert für eine hohe Nutzung von {system_usage_threshold} %. “

Bei Auflösung des Ereignisses: „Die Festplattennutzung des NSX Application Platform-Knotens {napp_node_name} ist damit kleiner als der Schwellenwert für eine hohe Nutzung von {system_usage_threshold} %. “

Navigieren Sie auf der NSX-Benutzeroberfläche zu „System“ | „NSX Application Platform“ | „Kerndienste“ und überprüfen Sie das Feld „Speicher“ der einzelnen Dienste, um zu sehen, welcher Dienst unter Druck steht. Bereinigen Sie nicht verwendete Daten oder Protokolle, um Festplattenressourcen freizugeben und zu sehen, ob die Last reduziert werden kann. Wenn mehr Festplattenspeicher benötigt wird, skalieren Sie den belasteten Dienst aus. Wenn der Datenspeicherdienst unter Druck steht, besteht eine weitere Möglichkeit darin, auf die Schaltfläche „Vertikal hochskalieren“ zu klicken, um die Festplattengröße zu erhöhen.

Der Status des NSX Application Platform-Knotens ist „Herabgestuft“.

Bei Erkennung des Ereignisses: Der NSX Application Platform-Knoten {napp_node_name} ist herabgestuft. “

Bei Auflösung des Ereignisses: „Der NSX Application Platform-Knoten {napp_node_name} wird ordnungsgemäß ausgeführt. “

Navigieren Sie auf der NSX-Benutzeroberfläche zu „System“ | „NSX Application Platform“ | „Ressourcen“, um zu überprüfen, welcher Knoten herabgestuft wurde. Überprüfen Sie die Netzwerk-, Arbeitsspeicher- und CPU-Auslastung des Knotens. Starten Sie den Knoten neu, wenn es sich um einen Worker-Knoten handelt.

Der Status des NSX Application Platform-Knotens ist „Nicht verfügbar“.

Bei Erkennung des Ereignisses: „Der NSX Application Platform-Knoten {napp_node_name} wird nicht ausgeführt. “

Bei Auflösung des Ereignisses: „Der NSX Application Platform-Knoten {napp_node_name} wird ordnungsgemäß ausgeführt. “

Navigieren Sie auf der NSX-Benutzeroberfläche zu „System“ | „NSX Application Platform“ | „Ressourcen“, um zu überprüfen, welcher Knoten nicht verfügbar ist. Überprüfen Sie die Netzwerk-, Arbeitsspeicher- und CPU-Auslastung des Knotens. Starten Sie den Knoten neu, wenn es sich um einen Worker-Knoten handelt.

CPU-Auslastung für Datenspeicherdienst ist sehr hoch.

Bei Erkennung des Ereignisses: „Die CPU-Auslastung des Datenspeicherdiensts liegt über dem Schwellenwert für eine sehr hohe Nutzung von {system_usage_threshold} %. “

Bei Auflösung des Ereignisses: „Die CPU-Auslastung des Datenspeicherdiensts ist damit kleiner als der Schwellenwert für eine sehr hohe Nutzung von {system_usage_threshold} %. “

Skalieren Sie alle Dienste oder den Datenspeicherdienst horizontal.

CPU-Auslastung für Datenspeicherdienst ist hoch.

Bei Erkennung des Ereignisses: „Die CPU-Auslastung des Datenspeicherdiensts liegt über dem Schwellenwert für eine hohe Nutzung von {system_usage_threshold} %. “

Bei Auflösung des Ereignisses: „Die CPU-Auslastung des Datenspeicherdiensts ist damit kleiner als der Schwellenwert für eine hohe Nutzung von {system_usage_threshold} %. “

Skalieren Sie alle Dienste oder den Datenspeicherdienst horizontal.

CPU-Auslastung für Messaging-Dienst ist sehr hoch.

Bei Erkennung des Ereignisses: „Die CPU-Auslastung des Messaging-Diensts liegt über dem Schwellenwert für eine sehr hohe Nutzung von {system_usage_threshold} %. “

Bei Auflösung des Ereignisses: „Die CPU-Auslastung des Messaging-Diensts ist damit kleiner als der Schwellenwert für eine sehr hohe Nutzung von {system_usage_threshold} %. “

Skalieren Sie alle Dienste oder den Messaging-Dienst horizontal.

CPU-Auslastung für Messaging-Dienst ist hoch.

Bei Erkennung des Ereignisses: „Die CPU-Auslastung des Messaging-Diensts liegt über dem Schwellenwert für eine hohe Nutzung von {system_usage_threshold} %. “

Bei Auflösung des Ereignisses: „Die CPU-Auslastung des Messaging-Diensts ist damit kleiner als der Schwellenwert für eine hohe Nutzung von {system_usage_threshold} %. “

Skalieren Sie alle Dienste oder den Messaging-Dienst horizontal.

CPU-Auslastung für Konfigurationsdatenbankdienst ist sehr hoch.

Bei Erkennung des Ereignisses: „Die CPU-Auslastung des Konfigurationsdatenbankdiensts liegt über dem Schwellenwert für eine sehr hohe Nutzung von {system_usage_threshold} %. “

Bei Auflösung des Ereignisses: „Die CPU-Auslastung des Konfigurationsdatenbankdiensts ist damit kleiner als der Schwellenwert für eine sehr hohe Nutzung von {system_usage_threshold} %. “

Skalieren Sie alle Dienste horizontal.

CPU-Auslastung für Konfigurationsdatenbankdienst ist hoch.

Bei Erkennung des Ereignisses: „Die CPU-Auslastung des Konfigurationsdatenbankdiensts liegt über dem Schwellenwert für eine hohe Nutzung von {system_usage_threshold} %. “

Bei Auflösung des Ereignisses: „Die CPU-Auslastung des Konfigurationsdatenbankdiensts ist damit kleiner als der Schwellenwert für eine hohe Nutzung von {system_usage_threshold} %. “

Skalieren Sie alle Dienste horizontal.

CPU-Auslastung für Metrikdienst ist sehr hoch.

Bei Erkennung des Ereignisses: „Die CPU-Auslastung des Metrikdiensts liegt über dem Schwellenwert für eine sehr hohe Nutzung von {system_usage_threshold} %. “

Bei Auflösung des Ereignisses: „Die CPU-Auslastung des Metrikdiensts ist damit kleiner als der Schwellenwert für eine sehr hohe Nutzung von {system_usage_threshold} %. “

Skalieren Sie alle Dienste horizontal.

CPU-Auslastung für Metrikdienst ist hoch.

Bei Erkennung des Ereignisses: „Die CPU-Auslastung des Metrikdiensts liegt über dem Schwellenwert für eine hohe Nutzung von {system_usage_threshold} %. “

Bei Auflösung des Ereignisses: „Die CPU-Auslastung des Metrikdiensts ist damit kleiner als der Schwellenwert für eine hohe Nutzung von {system_usage_threshold} %. “

Skalieren Sie alle Dienste horizontal.

CPU-Auslastung für Analysedienst ist sehr hoch.

Bei Erkennung des Ereignisses: „Die CPU-Auslastung des Analysediensts liegt über dem Schwellenwert für eine sehr hohe Nutzung von {system_usage_threshold} %. “

Bei Auflösung des Ereignisses: „Die CPU-Auslastung des Analysediensts ist damit kleiner als der Schwellenwert für eine sehr hohe Nutzung von {system_usage_threshold} %. “

Skalieren Sie alle Dienste oder den Analysedienst horizontal.

CPU-Auslastung für Analysedienst ist hoch.

Bei Erkennung des Ereignisses: „Die CPU-Auslastung des Analysediensts liegt über dem Schwellenwert für eine hohe Nutzung von {system_usage_threshold} %. “

Bei Auflösung des Ereignisses: „Die CPU-Auslastung des Analysediensts ist damit kleiner als der Schwellenwert für eine hohe Nutzung von {system_usage_threshold} %. “

Skalieren Sie alle Dienste oder den Analysedienst horizontal.

CPU-Auslastung für Platform Services-Dienst ist sehr hoch.

Bei Erkennung des Ereignisses: „Die CPU-Auslastung des Platform Services-Diensts liegt über dem Schwellenwert für eine sehr hohe Nutzung von {system_usage_threshold} %. “

Bei Auflösung des Ereignisses: „Die CPU-Auslastung des Platform Services-Diensts ist damit kleiner als der Schwellenwert für eine sehr hohe Nutzung von {system_usage_threshold} %. “

Skalieren Sie alle Dienste horizontal.

CPU-Auslastung für Platform Services-Dienst ist hoch.

Bei Erkennung des Ereignisses: „Die CPU-Auslastung des Platform Services-Diensts liegt über dem Schwellenwert für eine hohe Nutzung von {system_usage_threshold} %. “

Bei Auflösung des Ereignisses: „Die CPU-Auslastung des Platform Services-Diensts ist damit kleiner als der Schwellenwert für eine hohe Nutzung von {system_usage_threshold} %. “

Skalieren Sie alle Dienste horizontal.

Arbeitsspeichernutzung für Datenspeicherdienst ist sehr hoch.

Bei Erkennung des Ereignisses: „Die Arbeitsspeichernutzung des Datenspeicherdiensts liegt über dem Schwellenwert für eine sehr hohe Nutzung von {system_usage_threshold} %. “

Bei Auflösung des Ereignisses: „Die Arbeitsspeichernutzung des Datenspeicherdiensts ist damit kleiner als der Schwellenwert für eine sehr hohe Nutzung von {system_usage_threshold} %. “

Skalieren Sie alle Dienste oder den Datenspeicherdienst horizontal.

Arbeitsspeichernutzung für Datenspeicherdienst ist hoch.

Bei Erkennung des Ereignisses: „Die Arbeitsspeichernutzung des Datenspeicherdiensts liegt über dem Schwellenwert für eine hohe Nutzung von {system_usage_threshold} %. “

Bei Auflösung des Ereignisses: „Die Arbeitsspeichernutzung des Datenspeicherdiensts ist damit kleiner als der Schwellenwert für eine hohe Nutzung von {system_usage_threshold} %. “

Skalieren Sie alle Dienste oder den Datenspeicherdienst horizontal.

Arbeitsspeichernutzung für Messaging-Dienst ist sehr hoch.

Bei Erkennung des Ereignisses: „Die Arbeitsspeichernutzung des Messaging-Diensts liegt über dem Schwellenwert für eine sehr hohe Nutzung von {system_usage_threshold} %. “

Bei Auflösung des Ereignisses: „Die Arbeitsspeichernutzung des Messaging-Diensts ist damit kleiner als der Schwellenwert für eine sehr hohe Nutzung von {system_usage_threshold} %. “

Skalieren Sie alle Dienste oder den Messaging-Dienst horizontal.

Arbeitsspeichernutzung für Messaging-Dienst ist hoch.

Bei Erkennung des Ereignisses: „Die Arbeitsspeichernutzung des Messaging-Diensts liegt über dem Schwellenwert für eine hohe Nutzung von {system_usage_threshold} %. “

Bei Auflösung des Ereignisses: „Die Arbeitsspeichernutzung des Messaging-Diensts ist damit kleiner als der Schwellenwert für eine hohe Nutzung von {system_usage_threshold} %. “

Skalieren Sie alle Dienste oder den Messaging-Dienst horizontal.

Arbeitsspeichernutzung für Konfigurationsdatenbankdienst ist sehr hoch.

Bei Erkennung des Ereignisses: „Die Arbeitsspeichernutzung des Konfigurationsdatenbankdiensts liegt über dem Schwellenwert für eine sehr hohe Nutzung von {system_usage_threshold} %. “

Bei Auflösung des Ereignisses: „Die Arbeitsspeichernutzung des Konfigurationsdatenbankdiensts ist damit kleiner als der Schwellenwert für eine sehr hohe Nutzung von {system_usage_threshold} %. “

Skalieren Sie alle Dienste horizontal.

Die Arbeitsspeichernutzung für den Konfigurationsdatenbankdienst ist hoch.

Bei Erkennung des Ereignisses: „Die Arbeitsspeichernutzung des Konfigurationsdatenbankdiensts liegt über dem Schwellenwert für eine hohe Nutzung von {system_usage_threshold} %. “

Bei Auflösung des Ereignisses: „Die Arbeitsspeichernutzung des Konfigurationsdatenbankdiensts ist damit kleiner als der Schwellenwert für eine hohe Nutzung von {system_usage_threshold} %. “

Skalieren Sie alle Dienste horizontal.

Arbeitsspeichernnutzung für Metrikdienst ist sehr hoch.

Bei Erkennung des Ereignisses: „Die Arbeitsspeichernutzung des Metrikdiensts liegt über dem Schwellenwert für eine sehr hohe Nutzung von {system_usage_threshold} %. “

Bei Auflösung des Ereignisses: „Die Arbeitsspeichernutzung des Metrikdiensts ist damit kleiner als der Schwellenwert für eine sehr hohe Nutzung von {system_usage_threshold} %. “

Skalieren Sie alle Dienste horizontal.

Arbeitsspeichernnutzung für Metrikdienst ist hoch.

Bei Erkennung des Ereignisses: „Die Arbeitsspeichernutzung des Metrikdiensts liegt über dem Schwellenwert für eine hohe Nutzung von {system_usage_threshold} %. “

Bei Auflösung des Ereignisses: „Die Arbeitsspeichernutzung des Metrikdiensts ist damit kleiner als der Schwellenwert für eine hohe Nutzung von {system_usage_threshold} %. “

Skalieren Sie alle Dienste horizontal.

Arbeitsspeichernutzung für Analysedienst ist sehr hoch.

Bei Erkennung des Ereignisses: „Die Arbeitsspeichernutzung des Analysediensts liegt über dem Schwellenwert für eine sehr hohe Nutzung von {system_usage_threshold} %. “

Bei Auflösung des Ereignisses: „Die Arbeitsspeichernutzung des Analysediensts ist damit kleiner als der Schwellenwert für eine sehr hohe Nutzung von {system_usage_threshold} %. “

Skalieren Sie alle Dienste oder den Analysedienst horizontal.

Arbeitsspeichernutzung für Analysedienst ist hoch.

Bei Erkennung des Ereignisses: „Die Arbeitsspeichernutzung des Analysediensts liegt über dem Schwellenwert für eine hohe Nutzung von {system_usage_threshold} %. “

Bei Auflösung des Ereignisses: „Die Arbeitsspeichernutzung des Analysediensts ist damit kleiner als der Schwellenwert für eine hohe Nutzung von {system_usage_threshold} %. “

Skalieren Sie alle Dienste oder den Analysedienst horizontal.

Arbeitsspeichernutzung für Platform Services-Dienst ist sehr hoch.

Bei Erkennung des Ereignisses: „Die Arbeitsspeichernutzung des Platform Services-Diensts liegt über dem Schwellenwert für eine sehr hohe Nutzung von {system_usage_threshold} %. “

Bei Auflösung des Ereignisses: „Die Arbeitsspeichernutzung des Platform Services-Diensts ist damit kleiner als der Schwellenwert für eine sehr hohe Nutzung von {system_usage_threshold} %. “

Skalieren Sie alle Dienste horizontal.

Arbeitsspeichernutzung für Platform Services-Dienst ist hoch.

Bei Erkennung des Ereignisses: „Die Arbeitsspeichernutzung des Platform Services-Diensts liegt über dem Schwellenwert für eine hohe Nutzung von {system_usage_threshold} %. “

Bei Auflösung des Ereignisses: „Die Arbeitsspeichernutzung des Platform Services-Diensts ist damit kleiner als der Schwellenwert für eine hohe Nutzung von {system_usage_threshold} %. “

Skalieren Sie alle Dienste horizontal.

Festplattennutzung für Datenspeicherdienst ist sehr hoch.

Bei Erkennung des Ereignisses: „Die Festplattennutzung des Datenspeicherdiensts liegt über dem Schwellenwert für eine sehr hohe Nutzung von {system_usage_threshold} %. “

Bei Auflösung des Ereignisses: „Die Festplattennutzung des Datenspeicherdiensts ist damit kleiner als der Schwellenwert für eine sehr hohe Nutzung von {system_usage_threshold} %. “

Skalieren Sie den Datenspeicherdienst horizontal oder vertikal.

Festplattennutzung für Datenspeicherdienst ist hoch.

Bei Erkennung des Ereignisses: „Die Festplattennutzung des Datenspeicherdiensts liegt über dem Schwellenwert für eine hohe Nutzung von {system_usage_threshold} %. “

Bei Auflösung des Ereignisses: „Die Festplattennutzung des Datenspeicherdiensts ist damit kleiner als der Schwellenwert für eine hohe Nutzung von {system_usage_threshold} %. “

Skalieren Sie den Datenspeicherdienst horizontal oder vertikal.

Festplattennutzung für Messaging-Dienst ist sehr hoch.

Bei Erkennung des Ereignisses: „Die Festplattennutzung des Messaging-Diensts liegt über dem Schwellenwert für eine sehr hohe Nutzung von {system_usage_threshold} %. “

Bei Auflösung des Ereignisses: „Die Festplattennutzung des Messaging-Diensts ist damit kleiner als der Schwellenwert für eine sehr hohe Nutzung von {system_usage_threshold} %. “

Dateien müssen nicht bereinigt werden. Skalieren Sie alle Dienste oder den Messaging-Dienst horizontal.

Festplattennutzung für Messaging-Dienst ist hoch.

Bei Erkennung des Ereignisses: „Die Festplattennutzung des Messaging-Diensts liegt über dem Schwellenwert für eine hohe Nutzung von {system_usage_threshold} %. “

Bei Auflösung des Ereignisses: „Die Festplattennutzung des Messaging-Diensts ist damit kleiner als der Schwellenwert für eine hohe Nutzung von {system_usage_threshold} %. “

Dateien müssen nicht bereinigt werden. Skalieren Sie alle Dienste oder den Messaging-Dienst horizontal.

Festplattennutzung für Konfigurationsdatenbankdienst ist sehr hoch.

Bei Erkennung des Ereignisses: „Die Festplattennutzung des Konfigurationsdatenbankdiensts liegt über dem Schwellenwert für eine sehr hohe Nutzung von {system_usage_threshold} %. “

Bei Auflösung des Ereignisses: „Die Festplattennutzung des Konfigurationsdatenbankdiensts ist damit kleiner als der Schwellenwert für eine sehr hohe Nutzung von {system_usage_threshold} %. “

Dateien müssen nicht bereinigt werden. Skalieren Sie alle Dienste horizontal.

Festplattennutzung für Konfigurationsdatenbankdienst ist hoch.

Bei Erkennung des Ereignisses: „Die Festplattennutzung des Konfigurationsdatenbankdiensts liegt über dem Schwellenwert für eine hohe Nutzung von {system_usage_threshold} %. “

Bei Auflösung des Ereignisses: „Die Festplattennutzung des Konfigurationsdatenbankdiensts ist damit kleiner als der Schwellenwert für eine hohe Nutzung von {system_usage_threshold} %. “

Dateien müssen nicht bereinigt werden. Skalieren Sie alle Dienste horizontal.

Festplattennutzung für Metrikdienst ist sehr hoch.

Bei Erkennung des Ereignisses: „Die Festplattennutzung des Metrikdiensts liegt über dem Schwellenwert für eine sehr hohe Nutzung von {system_usage_threshold} %. “

Bei Auflösung des Ereignisses: „Die Festplattennutzung des Metrikdiensts ist damit kleiner als der Schwellenwert für eine sehr hohe Nutzung von {system_usage_threshold} %. “

Dateien müssen nicht bereinigt werden. Skalieren Sie alle Dienste horizontal.

Festplattennutzung für Metrikdienst ist hoch.

Bei Erkennung des Ereignisses: „Die Festplattennutzung des Metrikdiensts liegt über dem Schwellenwert für eine hohe Nutzung von {system_usage_threshold} %. “

Bei Auflösung des Ereignisses: „Die Festplattennutzung des Metrikdiensts ist damit kleiner als der Schwellenwert für eine hohe Nutzung von {system_usage_threshold} %. “

Dateien müssen nicht bereinigt werden. Skalieren Sie alle Dienste horizontal.

Festplattennutzung für Analysedienst ist sehr hoch.

Bei Erkennung des Ereignisses: „Die Festplattennutzung des Analysediensts liegt über dem Schwellenwert für eine sehr hohe Nutzung von {system_usage_threshold} %. “

Bei Auflösung des Ereignisses: „Die Festplattennutzung des Analysediensts ist damit kleiner als der Schwellenwert für eine sehr hohe Nutzung von {system_usage_threshold} %. “

Dateien müssen nicht bereinigt werden. Skalieren Sie alle Dienste oder den Analysedienst horizontal.

Festplattennutzung für Analysedienst ist hoch.

Bei Erkennung des Ereignisses: „Die Festplattennutzung des Analysediensts liegt über dem Schwellenwert für eine hohe Nutzung von {system_usage_threshold} %. “

Bei Auflösung des Ereignisses: „Die Festplattennutzung des Analysediensts ist damit kleiner als der Schwellenwert für eine hohe Nutzung von {system_usage_threshold} %. “

Dateien müssen nicht bereinigt werden. Skalieren Sie alle Dienste oder den Analysedienst horizontal.

Festplattennutzung für Platform Services-Dienst ist sehr hoch.

Bei Erkennung des Ereignisses: „Die Festplattennutzung des Platform Services-Diensts liegt über dem Schwellenwert für eine sehr hohe Nutzung von {system_usage_threshold} %. “

Bei Auflösung des Ereignisses: „Die Festplattennutzung des Platform Services-Diensts ist damit kleiner als der Schwellenwert für eine sehr hohe Nutzung von {system_usage_threshold} %. “

Dateien müssen nicht bereinigt werden. Skalieren Sie alle Dienste horizontal.

Festplattennutzung für Platform Services-Dienst ist hoch.

Bei Erkennung des Ereignisses: „Die Festplattennutzung des Platform Services-Diensts liegt über dem Schwellenwert für eine hohe Nutzung von {system_usage_threshold} %. “

Bei Auflösung des Ereignisses: „Die Festplattennutzung des Platform Services-Diensts ist damit kleiner als der Schwellenwert für eine hohe Nutzung von {system_usage_threshold} %. “

Dateien müssen nicht bereinigt werden. Skalieren Sie alle Dienste horizontal.

Der Dienststatus ist „Herabgestuft“.

Bei Erkennung des Ereignisses: „Der Dienst {napp_service_name} ist herabgestuft. Der Dienst kann möglicherweise weiterhin ein Quorum erreichen, während nicht alle {napp_service_name} zugeordneten Pods stabil sind. Von diesen instabilen Pods verbrauchte Ressourcen können freigegeben werden. “

Bei Auflösung des Ereignisses: „Der Dienst {napp_service_name} wird ordnungsgemäß ausgeführt. “

Navigieren Sie in der NSX-Benutzeroberfläche zu „System“ | „NSX Application Platform“ | „Kerndienste“, um zu überprüfen, welcher Dienst herabgestuft ist. Rufen Sie NSX API „GET /napp/api/v1/platform/monitor/feature/health“ auf, um zu überprüfen, welcher Dienst aus welchem Grund herabgestuft wurde. Rufen Sie den folgenden CLI-Befehl auf, um den herabgestuften Dienst gegebenenfalls neu zu starten: kubectl rollout restart &ltstatefulset/deployment&gt &ltservice_name&gt -n &ltnamespace&gt. Herabgestufte Dienste funktionieren möglicherweise ordnungsgemäß, ihre Leistung ist jedoch nicht optimal.

Der Dienststatus ist „Inaktiv“.

Bei Erkennung des Ereignisses: „Dienst {napp_service_name} wird nicht ausgeführt. “

Bei Auflösung des Ereignisses: „Der Dienst {napp_service_name} wird ordnungsgemäß ausgeführt. “

Navigieren Sie in der NSX-Benutzeroberfläche zu „System“ | „NSX Application Platform“ | „Kerndienste“, um zu überprüfen, welcher Dienst herabgestuft ist. Rufen Sie die NSX API „GET /napp/api/v1/platform/monitor/feature/health“ auf, um zu prüfen, welcher bestimmte Dienst ausgefallen ist und welcher Grund dafür vorliegt. Rufen Sie den folgenden CLI-Befehl auf, um den herabgestuften Dienst kubectl rollout restart &ltstatefulset/deployment&gt &ltservice_name&gt -n &ltnamespace&gt neu zu starten.

Dienst herabgestuft.

Bei Erkennung des Ereignisses: „Der Dienst {nsxaas_service_name} ist herabgestuft. Im aktuellen Zustand funktioniert der Dienst möglicherweise mit reduzierter Effizienz, was sich auf die Arbeitslasten der Kunden auswirken kann. {Service_down_reason}“

Bei Auflösung des Ereignisses: „Der Dienst {nsxaas_service_name} befindet sich nicht mehr in einem herabgestuften Zustand. “

Überprüfen Sie die in der Alarmbeschreibung enthaltenen Daten zur Identifizierung des Dienstes, zur Lokalisierung der Bereitstellung des Dienstes und zusätzliche Daten, die vom Zustandsüberwachungsdienst erfasst werden. Überprüfen Sie gegebenenfalls auch die vom Metrikdienst oder von Wavefront aufgezeichneten Verlaufsdaten.

Dienst nicht verfügbar.

Bei Erkennung des Ereignisses: „Der Dienst {nsxaas_service_name} ist inaktiv. {Service_down_reason}“

Bei Auflösung des Ereignisses: „Der Dienst {nsxaas_service_name} ist wieder verfügbar. “

Überprüfen Sie die in der Alarmbeschreibung enthaltenen Daten zur Identifizierung des Dienstes, zur Lokalisierung der Bereitstellung des Dienstes und zusätzliche Daten, die vom Zustandsüberwachungsdienst erfasst werden. Überprüfen Sie gegebenenfalls auch die vom Metrikdienst oder von Wavefront aufgezeichneten Verlaufsdaten.

Das Benutzerkennwort ist abgelaufen.

Bei Erkennung des Ereignisses: „Das Kennwort für Benutzer {username} ist abgelaufen. “

Bei Auflösung des Ereignisses: „Das Kennwort für Benutzer {username} wurde erfolgreich geändert oder ist nicht mehr abgelaufen oder der Benutzer ist nicht mehr aktiv. “

Das Kennwort für den Benutzer {username} muss jetzt geändert werden, um auf das System zugreifen zu können. Wenn Sie beispielsweise ein neues Kennwort für einen Benutzer anwenden möchten, rufen Sie die folgende NSX API mit einem gültigen Kennwort im Anforderungstext auf: PUT /api/v1/node/users/&ltuserid&gt, wobei &ltuserid&gt die ID des Benutzers ist. Wenn das Kennwort des Admin-Benutzers (mit &ltuserid&gt 10000) abgelaufen ist, muss sich der Admin über SSH (sofern aktiviert) oder über die Konsole beim System anmelden, um das Kennwort zu ändern. Bei der Eingabe des aktuellen, abgelaufenen Kennworts wird der Admin aufgefordert, ein neues Kennwort einzugeben.

Das Benutzerkennwort läuft in Kürze ab.

Bei Erkennung des Ereignisses: „Das Kennwort für Benutzer {username} läuft ab in {password_expiration_days} Tagen. “

Bei Auflösung des Ereignisses: „Das Kennwort für den Benutzer {username} wurde erfolgreich geändert oder ist nicht mehr abgelaufen oder der Benutzer ist nicht mehr aktiv. “

Stellen Sie sicher, dass das Kennwort für Benutzer {username} sofort geändert wird. Wenn Sie beispielsweise ein neues Kennwort für einen Benutzer anwenden möchten, rufen Sie die folgende NSX API mit einem gültigen Kennwort im Anforderungstext auf: PUT /api/v1/node/users/&ltuserid&gt, wobei &ltuserid&gt die ID des Benutzers ist.

Das Benutzerkennwort läuft in Kürze ab.

Bei Erkennung des Ereignisses: „Das Kennwort für den Benutzer {username} nähert sich dem Ablauf in {password_expiration_days} Tagen. “

Bei Auflösung des Ereignisses: „Das Kennwort für den Benutzer {username} wurde erfolgreich geändert oder ist nicht mehr abgelaufen oder der Benutzer ist nicht mehr aktiv. “

Das Kennwort für Benutzer {username} muss in Kürze geändert werden. Wenn Sie beispielsweise ein neues Kennwort für einen Benutzer anwenden möchten, rufen Sie die folgende NSX API mit einem gültigen Kennwort im Anforderungstext auf: PUT /api/v1/node/users/&ltuserid&gt, wobei &ltuserid&gt die ID des Benutzers ist.

Installation des physischen Servers (BMS) fehlgeschlagen.

Bei Erkennung des Ereignisses: „Die Installation des physischen Servers {transport_node_name} ({entity_id}) ist fehlgeschlagen. “

Bei Auflösung des Ereignisses: „Die Installation des physischen Servers {transport_node_name} ({entity_id}) ist abgeschlossen. “

Navigieren Sie zu „System“ > „Fabric“ > „Knoten“ > „Host-Transportknoten“, und beheben Sie den Fehler auf dem Knoten.

Upgrade des physischen Servers (BMS) fehlgeschlagen.

Bei Erkennung des Ereignisses: „Das Upgrade des physischen Servers {transport_node_name} ({entity_id}) ist fehlgeschlagen. “

Bei Auflösung des Ereignisses: „Das Upgrade des physischen Servers {transport_node_name} ({entity_id}) ist abgeschlossen. “

Navigieren Sie zu „System“ > „Upgrade“, beheben Sie den Fehler, und lösen Sie dann das Upgrade erneut aus.

Deinstallation des physischen Servers (BMS) fehlgeschlagen.

Bei Erkennung des Ereignisses: „Die Deinstallation des physischen Servers {transport_node_name} ({entity_id}) ist fehlgeschlagen. “

Bei Auflösung des Ereignisses: „Die Deinstallation des physischen Servers {transport_node_name} ({entity_id}) ist abgeschlossen. “

Navigieren Sie zu „System“ > „Fabric“ > „Knoten“ > „Host-Transportknoten“, und beheben Sie den Fehler auf dem Knoten.

Die Anzahl der Einheiten hat den Grenzwert für die Richtlinieneinschränkung erreicht.

Bei Erkennung des Ereignisses: „Die Anzahl der Einheiten vom Typ {constraint_type} in {constraint_type_path} beträgt derzeit {current_count} und hat damit den maximalen Grenzwert von {constraint_limit} erreicht. “

Bei Auflösung des Ereignisses: „{constraint_type}-Anzahl ist damit kleiner als der Schwellenwert. “

Überprüfen Sie die Nutzung von {constraint_type}. Aktualisieren Sie die Einschränkung, um den Grenzwert zu erhöhen oder den nicht verwendeten {constraint_type} zu löschen.

Die BFD-Sitzung ist inaktiv.

Bei Erkennung des Ereignisses: „In Router {lr_id} ist die BFD-Sitzung für Peer {peer_address} inaktiv. “

Bei Auflösung des Ereignisses: „In Router {lr_id} ist die BFD-Sitzung für Peer {peer_address} aktiv. “

1. Rufen Sie den NSX-CLI-Befehl get logical-routers auf.
2. Wechseln Sie zum Dienstrouter {sr_id}
3. Führen Sie den NSX-CLI-Befehl ping {peer_address} aus und überprüfen Sie den Konnektivität.

Statische Route wurde entfernt.

Bei Erkennung des Ereignisses: „In Router {lr_id} wurde die statische Route {entity_id} ({static_address}) entfernt, weil BFD inaktiv war. “

Bei Auflösung des Ereignisses: „In Router {lr_id} wurde die statische Route {entity_id} ({static_address}) wieder hinzugefügt, da BFD wiederhergestellt wurde. “

Der statische Routing-Eintrag wurde aufgrund einer inaktiven BFD-Sitzung entfernt.
1. Rufen Sie den NSX-CLI-Befehl get logical-routers auf.
2. Wechseln Sie zum Dienstrouter {sr_id}.
3. Rufen Sie den NSX-CLI-Befehl ping &ltBFD peer IP address&gt auf, um die Konnektivität zu überprüfen. Überprüfen Sie außerdem die Konfiguration sowohl im NSX- als auch im BFD-Peer, um sicherzustellen, dass die Timer nicht geändert wurden.

Der BGP-Nachbar ist inaktiv.

Bei Erkennung des Ereignisses: „In Router {lr_id} ist der BGP-Nachbar {entity_id} ({bgp_neighbor_ip}) inaktiv. Grund: {failure_reason}. “

Bei Auflösung des Ereignisses: „In Router {lr_id} ist der BGP-Nachbar {entity_id} ({bgp_neighbor_ip}) aktiv. “

1. Rufen Sie den NSX-CLI-Befehl get logical-routers auf.
2. Wechseln Sie zum Dienstrouter {sr_id}. Wenn als Grund ein Netzwerk- oder Konfigurationsfehler angezeigt wird:
3. Rufen Sie den NSX-CLI-Befehl get bgp neighbor summary auf, um den BGP-Nachbarstatus zu prüfen. Wenn als Grund Edge ist nicht bereit angezeigt wird, überprüfen Sie, warum sich der Edge-Knoten nicht in einem guten Zustand befindet.
4. Rufen Sie den NSX-CLI-Befehl get edge-cluster status auf, um zu überprüfen, warum der Edge-Knoten möglicherweise ausgefallen ist.
5. Rufen Sie die NSX-CLI-Befehle get bfd-config und get bfd-sessions auf, um zu überprüfen, ob BFD ordnungsgemäß ausgeführt wird.
6. Überprüfen Sie alle Alarme im Zusammenhang mit dem Edge-Systemzustand, um weitere Informationen zu erhalten. Überprüfen Sie /var/log/syslog, um festzustellen, ob Fehler bezüglich der BGP-Konnektivität vorliegen.

Proxy-ARP ist für Dienst-IP nicht konfiguriert.

Bei Erkennung des Ereignisses: „Die Proxy-ARP für Dienst-IP {service_ip} und Diensteinheit {entity_id} ist nicht konfiguriert, da die Anzahl der ARP-Proxy-Einträge, die aufgrund einer Überlappung der Dienst-IP mit dem Subnetz von lrport {lrport_id} auf Router {lr_id} generiert wurde, den zulässigen Schwellenwert von 16384 überschritten hat. “

Bei Auflösung des Ereignisses: „Die Proxy-ARP für Diensteinheit {entity_id} wurde erfolgreich generiert, da sich die Überlappung der Dienst-IP mit dem Subnetz von lrport {lrport_id} auf Router {lr_id} innerhalb des zulässigen Grenzwerts von 16384 Einträgen befindet. “

Konfigurieren Sie die Dienst-IP {service_ip} für die Diensteinheit {entity_id} neu oder ändern Sie das Subnetz von lrport {lrport_id} auf Router {lr_id} so, dass die Proxy-ARP-Einträge, die aufgrund der Überlappung zwischen der Dienst-IP und dem Subnetz von lrport generiert werden, kleiner als der zulässige Schwellenwert von 16384 sind.

Alle BGP/BFD-Sitzungen sind inaktiv.

Bei Erkennung des Ereignisses: „Alle BGP/BFD-Sitzungen sind inaktiv. “

Bei Auflösung des Ereignisses: „Mindestens eine BGP/BFD-Sitzung ist aktiv. “

Rufen Sie den NSX-CLI-Befehl get logical-routers auf, um den Tier-0-Dienstrouter abzurufen und zu diesem VRF zu wechseln. Rufen Sie dann die folgenden NSX-CLI-Befehle auf.
1. ping &ltBFD Peer-IP-Adresse&gt, um die Konnektivität zu überprüfen.
2. get bfd-config und get bfd-sessions, um zu überprüfen, ob BFD ordnungsgemäß ausgeführt wird.
3. get bgp neighbor summary, um zu überprüfen, ob BGP ordnungsgemäß ausgeführt wird. Überprüfen Sie auch /var/log/syslog, um festzustellen, ob Fehler bezüglich der BGP-Konnektivität vorliegen.

OSPF-Nachbar wurde vom vollständigen Zustand in einen anderen versetzt.

Bei Erkennung des Ereignisses: „OSPF-Nachbar {peer_address} wurde vom vollständigen Zustand in einen anderen versetzt. “

Bei Auflösung des Ereignisses: „OSPF-Nachbar {peer_address} wurde in den vollständigen Zustand versetzt. “

1. Rufen Sie den NSX-CLI-Befehl get logical-routers, um die VRF-ID abzurufen und zum Tier-0-Dienstrouter zu wechseln.
2. Führen Sie get ospf neighbor aus, um den aktuellen Zustand dieses Nachbarn zu überprüfen. Wenn der Nachbar nicht in der Ausgabe aufgeführt wird, ist der Nachbar ausgefallen oder nicht mehr im Netzwerk.
3. Rufen Sie den NSX-CLI-Befehl ping &ltOSPF neighbor IP address&gt auf, um die Konnektivität zu überprüfen.
4. Überprüfen Sie außerdem die Konfiguration sowohl für NSX als auch den Peer-Router, um sicherzustellen, dass Timer und Bereichs-ID übereinstimmen.
5. Überprüfen Sie „/var/log/syslog“, um zu sehen, ob Fehler in Zusammenhang mit der Konnektivität vorliegen.

Die maximale IPv4-Routengrenze nähert sich auf dem Edge-Knoten.

Bei Erkennung des Ereignisses: „Der Grenzwert für IPv4-Routen hat {route_limit_threshold} auf dem Tier-0-Gateway und allen Tier0-VRFs auf dem Edge-Knoten {edge_node} erreicht. “

Bei Auflösung des Ereignisses: „IPv4-Routen befinden sich innerhalb des Grenzwerts von {route_limit_threshold} auf Tier0-Gateway und allen Tier0-VRFs auf dem Edge-Knoten {edge_node}. “

1. Überprüfen Sie die Route Redistribution-Richtlinien und Routen, die von allen externen Peers empfangen wurden.
2. Sie sollten die Anzahl Routen reduzieren, indem Sie Routing-Richtlinien und Filter entsprechend anwenden.

Die maximale IPv6-Routengrenze nähert sich auf dem Edge-Knoten.

Bei Erkennung des Ereignisses: „Der Grenzwert für IPv6-Routen hat {route_limit_threshold} auf dem Tier-0-Gateway und allen Tier0-VRFs auf dem Edge-Knoten {edge_node} erreicht. “

Bei Auflösung des Ereignisses: „IPv6-Routen befinden sich innerhalb des Grenzwerts von {route_limit_threshold} auf Tier0-Gateway und allen Tier0-VRFs auf dem Edge-Knoten {edge_node}. “

1. Überprüfen Sie die Route Redistribution-Richtlinien und Routen, die von allen externen Peers empfangen wurden.
2. Sie sollten die Anzahl Routen reduzieren, indem Sie Routing-Richtlinien und Filter entsprechend anwenden.

Die maximale IPv4-Routengrenze wurde auf dem Edge-Knoten überschritten.

Bei Erkennung des Ereignisses: „Der Grenzwert für IPv4-Routen hat den Grenzwert {route_limit_maximum} auf dem Tier-0-Gateway und allen Tier0-VRFs auf dem Edge-Knoten {edge_node} überschritten. “

Bei Auflösung des Ereignisses: „IPv4-Routen befinden sich innerhalb des Grenzwerts von {route_limit_maximum} auf Tier0-Gateway und allen Tier0-VRFs auf dem Edge-Knoten {edge_node}. “

1. Überprüfen Sie die Route Redistribution-Richtlinien und Routen, die von allen externen Peers empfangen wurden.
2. Sie sollten die Anzahl Routen reduzieren, indem Sie Routing-Richtlinien und Filter entsprechend anwenden.

Die maximale IPv6-Routengrenze wurde auf dem Edge-Knoten überschritten.

Bei Erkennung des Ereignisses: „Der Grenzwert für IPv6-Routen hat den Grenzwert {route_limit_maximum} auf dem Tier-0-Gateway und allen Tier0-VRFs auf dem Edge-Knoten {edge_node} überschritten. “

Bei Auflösung des Ereignisses: „IPv6-Routen befinden sich innerhalb des Grenzwerts von {route_limit_maximum} auf Tier0-Gateway und allen Tier0-VRFs auf dem Edge-Knoten {edge_node}. “

1. Überprüfen Sie die Route Redistribution-Richtlinien und Routen, die von allen externen Peers empfangen wurden.
2. Sie sollten die Anzahl Routen reduzieren, indem Sie Routing-Richtlinien und Filter entsprechend anwenden.

Die maximale Anzahl der vom BGP-Nachbarn empfangenen IPv4-Präfixe nähert sich.

Bei Erkennung des Ereignisses: „Die Anzahl der von {bgp_neighbor_ip} empfangenen IPv4-{subsequent_address_family}-Präfixe erreicht {prefixes_count_threshold}. Der für diesen Peer definierte Grenzwert ist {prefixes_count_max}. “

Bei Auflösung des Ereignisses: „Die Anzahl der von {bgp_neighbor_ip} empfangenen IPv4- {subsequent_address_family}-Präfixe liegt innerhalb des Grenzwerts {prefixes_count_threshold}. “

1. Überprüfen Sie die BGP-Routing-Richtlinien im externen Router.
2. Sie sollten die Anzahl der vom BGP-Peer angekündigten Routen reduzieren, indem Sie Routing-Richtlinien und Filter auf den externen Router anwenden.
3. Erhöhen Sie bei Bedarf die Einstellungen für die maximalen Präfixe im Abschnitt „BGP-Nachbarkonfiguration“.

Die maximale Anzahl der vom BGP-Nachbarn empfangenen IPv6-Präfixe nähert sich.

Bei Erkennung des Ereignisses: „Die Anzahl der von {bgp_neighbor_ip} empfangenen IPv6-{subsequent_address_family}-Präfixe erreicht {prefixes_count_threshold}. Der für diesen Peer definierte Grenzwert ist {prefixes_count_max}. “

Bei Auflösung des Ereignisses: „Die Anzahl der von {bgp_neighbor_ip} empfangenen IPv6-{subsequent_address_family}-Präfixe liegt innerhalb des Grenzwerts {prefixes_count_threshold}. “

1. Überprüfen Sie die BGP-Routing-Richtlinien im externen Router.
2. Sie sollten die Anzahl der vom BGP-Peer angekündigten Routen reduzieren, indem Sie Routing-Richtlinien und Filter auf den externen Router anwenden.
3. Erhöhen Sie bei Bedarf die Einstellungen für die maximalen Präfixe im Abschnitt „BGP-Nachbarkonfiguration“.

Die maximale Anzahl der vom BGP-Nachbarn empfangenen IPv4-Präfixe wurde überschritten.

Bei Erkennung des Ereignisses: „Die Anzahl der von {bgp_neighbor_ip} empfangenen IPv4-{subsequent_address_family}-Präfixe hat den für diesen Peer definierten Grenzwert {prefixes_count_max} überschritten. “

Bei Auflösung des Ereignisses: „Die Anzahl der von {bgp_neighbor_ip} empfangenen IPv4-{subsequent_address_family}-Präfixe liegt innerhalb des Grenzwerts {prefixes_count_max}. “

1. Überprüfen Sie die BGP-Routing-Richtlinien im externen Router.
2. Sie sollten die Anzahl der vom BGP-Peer angekündigten Routen reduzieren, indem Sie Routing-Richtlinien und Filter auf den externen Router anwenden.
3. Erhöhen Sie bei Bedarf die Einstellungen für die maximalen Präfixe im Abschnitt „BGP-Nachbarkonfiguration“.

Die maximale Anzahl der vom BGP-Nachbarn empfangenen IPv6-Präfixe wurde überschritten.

Bei Erkennung des Ereignisses: „Die Anzahl der von {bgp_neighbor_ip} empfangenen IPv6-{subsequent_address_family}-Präfixe hat den für diesen Peer definierten Grenzwert {prefixes_count_max} überschritten. “

Bei Auflösung des Ereignisses: „Die Anzahl der von {bgp_neighbor_ip} empfangenen IPv6-{subsequent_address_family}-Präfixe liegt innerhalb des Grenzwerts {prefixes_count_max}. “

1. Überprüfen Sie die BGP-Routing-Richtlinien im externen Router.
2. Sie sollten die Anzahl der vom BGP-Peer angekündigten Routen reduzieren, indem Sie Routing-Richtlinien und Filter auf den externen Router anwenden.
3. Erhöhen Sie bei Bedarf die Einstellungen für die maximalen Präfixe im Abschnitt „BGP-Nachbarkonfiguration“.

Der NSX-Sicherheitsstatus ist nicht NDcPP-konform.

Bei Erkennung des Ereignisses: „Eine der ‚NDcPP‘-Konformitätsanforderungen wird verletzt. Das bedeutet, dass der NSX-Status im Hinblick auf NDcPP derzeit nicht konform ist. “

Bei Auflösung des Ereignisses: „Die ‚NDcPP‘-Konformitätsprobleme wurden alle behoben. “

Führen Sie den Konformitätsbericht über das Menü „Startseite – Überwachung und Dashboard – Konformitätsbericht“ aus und beheben Sie alle Probleme, die mit dem Konformitätsnamen „NDcPP“ gekennzeichnet sind.

Der NSX-Sicherheitsstatus ist nicht EAL4+-konform.

Bei Erkennung des Ereignisses: „Eine der ‚EAL4+‘-Konformitätsanforderungen wird verletzt. Das bedeutet, dass der NSX-Status im Hinblick auf EAL4+ derzeit nicht konform ist. “

Bei Auflösung des Ereignisses: „Die ‚EAL4+‘-Konformitätsprobleme wurden alle behoben. “

Führen Sie den Konformitätsbericht über das Menü „Startseite – Überwachung und Dashboard – Konformitätsbericht“ aus und beheben Sie alle Probleme, die mit dem Konformitätsnamen „EAL4+“ gekennzeichnet sind.

Die NSX-Sicherheitskonfiguration ist nicht NDcPP-konform.

Bei Erkennung des Ereignisses: „Eine der ‚NDcPP‘-Konformitätsanforderungen wird verletzt. Das bedeutet, dass die NSX-Konfiguration im Hinblick auf NDcPP derzeit nicht konform ist. “

Bei Auflösung des Ereignisses: „Die ‚NDcPP‘-Konformitätsprobleme wurden alle behoben. “

Führen Sie den Konformitätsbericht über das Menü „Startseite – Überwachung und Dashboard – Konformitätsbericht“ aus und beheben Sie alle Probleme, die mit dem Konformitätsnamen „NDcPP“ gekennzeichnet sind.

Die NSX-Sicherheitskonfiguration ist nicht EAL4+-konform.

Bei Erkennung des Ereignisses: „Eine der ‚EAL4+‘-Konformitätsanforderungen wird verletzt. Das bedeutet, dass die NSX-Konfiguration im Hinblick auf EAL4+ derzeit nicht konform ist. “

Bei Auflösung des Ereignisses: „Die ‚EAL4+‘-Konformitätsprobleme wurden alle behoben. “

Führen Sie den Konformitätsbericht über das Menü „Startseite – Überwachung und Dashboard – Konformitätsbericht“ aus und beheben Sie alle Probleme, die mit dem Konformitätsnamen „EAL4+“ gekennzeichnet sind.

Dienstbereitstellung war erfolgreich.

Bei Erkennung des Ereignisses: „Die Dienstbereitstellung {entity_id} für den Dienst {service_name} auf dem Cluster {vcenter_cluster_id} war erfolgreich. “

Bei Auflösung des Ereignisses: „Die Dienstbereitstellung {entity_id} auf dem Cluster {vcenter_cluster_id} war erfolgreich. Es ist keine Aktion erforderlich. “

Es ist keine Aktion erforderlich.

Dienstbereitstellung ist fehlgeschlagen.

Bei Erkennung des Ereignisses: „Die Dienstbereitstellung {entity_id} für den Dienst {service_name} auf dem Cluster {vcenter_cluster_id} ist fehlgeschlagen. Grund: {Failure_reason}“

Bei Auflösung des Ereignisses: „Die fehlgeschlagene Dienstbereitstellung {entity_id} wurde entfernt. “

Löschen Sie die Dienstbereitstellung über die NSX-Benutzeroberfläche oder die API. Führen Sie eine der im KB-Artikel beschriebenen Korrekturaktionen durch und wiederholen Sie die Dienstbereitstellung.

Löschen der Dienstbereitstellung war erfolgreich.

Bei Erkennung des Ereignisses: „Das Löschen der Dienstbereitstellung {entity_id} für den Dienst {service_name} auf dem Cluster {vcenter_cluster_id} war erfolgreich. “

Bei Auflösung des Ereignisses: „Das Löschen der Dienstbereitstellung {entity_id} auf dem Cluster {vcenter_cluster_id} war erfolgreich. Es ist keine Aktion erforderlich. “

Es ist keine Aktion erforderlich.

Löschen der Dienstbereitstellung ist fehlgeschlagen.

Bei Erkennung des Ereignisses: „Das Löschen der Dienstbereitstellung {entity_id} für den Dienst {service_name} auf dem Cluster {vcenter_cluster_id} ist fehlgeschlagen. Grund: {Failure_reason}“

Bei Auflösung des Ereignisses: „Der Name der fehlgeschlagenen Dienstbereitstellung {entity_id} wurde entfernt. “

Löschen Sie die Dienstbereitstellung über die NSX-Benutzeroberfläche oder die API. Führen Sie eine der im KB-Artikel beschriebenen Korrekturaktionen durch und wiederholen Sie das Löschen der Dienstbereitstellung. Lösen Sie den Alarm manuell auf, nachdem Sie überprüft haben, ob alle VMs und Objekte gelöscht wurden.

SVM funktioniert im Dienst.

Bei Erkennung des Ereignisses: „Die Integritätsprüfung für SVM {entity_id} für den Dienst {service_name} funktioniert auf {hostname_or_ip_address_with_port} ordnungsgemäß. “

Bei Auflösung des Ereignisses: „Die SVM {entity_id} funktioniert ordnungsgemäß. Es ist keine Aktion erforderlich. “

Es ist keine Aktion erforderlich.

SVM funktioniert nicht im Dienst.

Bei Erkennung des Ereignisses: „Die Integritätsprüfung für SVM {entity_id} für den Dienst {service_name} funktioniert auf {hostname_or_ip_address_with_port} nicht ordnungsgemäß. Grund: {failure_reason}. “

Bei Auflösung des Ereignisses: „Der SVM {entity_id} mit dem falschen Status wurde entfernt. “

Löschen Sie die Dienstbereitstellung über die NSX-Benutzeroberfläche oder die API. Führen Sie eine der im KB-Artikel beschriebenen Korrekturmaßnahmen durch und wiederholen Sie die Dienstbereitstellung gegebenenfalls.

Der Status der Service Insertion-Infrastruktur ist inaktiv und auf dem Host nicht aktiviert.

Bei Erkennung des Ereignisses: „SPF ist auf Portebene auf dem Host {transport_node_id} nicht aktiviert und der Status ist inaktiv. Grund: {failure_reason}. “

Bei Auflösung des Ereignisses: „Der Infrastrukturstatus der Service Insertion ist aktiv und wurde auf dem Host korrekt aktiviert. “

Führen Sie eine Korrekturmaßnahme aus dem KB-Artikel durch und überprüfen Sie, ob der Status aktiv ist. Beheben Sie den Alarm manuell, nachdem Sie den Status überprüft haben.

Status der SVM-Aktivität ist inaktiv.

Bei Erkennung des Ereignisses: „Der Status der SVM-Aktivität ist auf {entity_id} inaktiv und der Datenverkehrsfluss wird beeinträchtigt. “

Bei Auflösung des Ereignisses: „Die SVM-Aktivität hat einen aktiven Status und ist erwartungsgemäß konfiguriert. “

Führen Sie eine Korrekturmaßnahme aus dem KB-Artikel durch und überprüfen Sie, ob der Status aktiv ist.

Dienstkettenpfad ist inaktiv.

Bei Erkennung des Ereignisses: „Der Dienstkettenpfad ist auf {entity_id} inaktiv und der Datenverkehrsfluss wird beeinträchtigt. “

Bei Auflösung des Ereignisses: „Der Dienstkettenpfad ist aktiv und erwartungsgemäß konfiguriert. “

Führen Sie eine Korrekturmaßnahme aus dem KB-Artikel durch und überprüfen Sie, ob der Status aktiv ist.

Neuer Host wurde im Cluster hinzugefügt.

Bei Erkennung des Ereignisses: „Der neue, im Cluster {vcenter_cluster_id} und SVM hinzugefügte Host wird bereitgestellt. “

Bei Auflösung des Ereignisses: „Der neue Host wurde erfolgreich hinzugefügt. “

Suchen Sie nach dem VM-Bereitstellungsstatus und warten Sie, bis sie eingeschaltet wird.

TEP ist fehlerhaft.

Bei Erkennung des Ereignisses: „TEP:{vtep_name} von VDS:{dvs_name} auf Transportknoten:{transport_node_id}. Bei Overlay-Arbeitslasten, die diesen TEP verwenden, kommt es zu einem Netzwerkausfall. Grund: {vtep_fault_reason}. “

Bei Auflösung des Ereignisses: „TEP:{vtep_name} von VDS:{dvs_name} auf Transportknoten:{transport_node_id} ist fehlerfrei. “

1. Überprüfen Sie, ob der TEP eine gültige IP-Adresse oder andere Underlay-Konnektivitätsprobleme aufweist.
2. Aktivieren Sie TEP-HA, um einen Failover von Arbeitslasten auf andere fehlerfreie TEPs auszuführen.

TEP-HA aktiviert.

Bei Erkennung des Ereignisses: „TEP-HA aktiviert für TEP:{vtep_name} von VDS:{dvs_name} auf Transportknoten:{transport_node_id}. “

Bei Auflösung des Ereignisses: „TEP-HA gelöscht für TEP:{vtep_name} von VDS:{dvs_name} auf Transportknoten:{transport_node_id}. “

Aktivieren Sie AutoWiederherstellen, oder rufen Sie die manuelle Wiederherstellung für TEP:{vtep_name} auf VDS:{dvs_name} auf Transportknoten:{transport_node_id} auf.

AutoWiederherstellen ist erfolgreich.

Bei Erkennung des Ereignisses: „Automatische Wiederherstellung für TEP:{vtep_name} von VDS:{dvs_name} auf Transportknoten:{transport_node_id} ist erfolgreich. “

Bei Auflösung des Ereignisses: „Automatische Wiederherstellung für TEP:{vtep_name} von VDS:{dvs_name} auf Transportknoten:{transport_node_id} wurde gelöscht. “

Keine.

AutoWiederherstellen fehlgeschlagen.

Bei Erkennung des Ereignisses: „Automatische Wiederherstellung für TEP:{vtep_name} von VDS:{dvs_name} auf Transportknoten:{transport_node_id} ist fehlgeschlagen. Overlay-Arbeitslasten, die diesen TEP verwenden, führen ein Failover auf andere fehlerfreie TEPs durch. Wenn keine anderen fehlerfreien TEPs vorhanden sind, kommt es bei Overlay-Arbeitslasten zu einem Netzwerkausfall. “

Bei Auflösung des Ereignisses: „Automatische Wiederherstellung für TEP:{vtep_name} von VDS:{dvs_name} auf Transportknoten:{transport_node_id} wurde gelöscht. “

Überprüfen Sie, ob der TEP eine gültige IP-Adresse oder andere Underlay-Konnektivitätsprobleme aufweist.

TEP ist auf DPU fehlerhaft.

Bei Erkennung des Ereignisses: „TEP:{vtep_name} von VDS:{dvs_name} auf Transportknoten:{transport_node_id} auf DPU {dpu_id}. Bei Overlay-Arbeitslasten, die diesen TEP verwenden, kommt es zu einem Netzwerkausfall. Grund: {vtep_fault_reason}. “

Bei Auflösung des Ereignisses: „TEP:{vtep_name} von VDS:{dvs_name} auf Transportknoten:{transport_node_id} auf DPU {dpu_id} ist fehlerfrei. “

1. Überprüfen Sie, ob der TEP eine gültige IP-Adresse oder andere Underlay-Konnektivitätsprobleme aufweist.
2. Aktivieren Sie TEP-HA, um einen Failover von Arbeitslasten auf andere fehlerfreie TEPs auszuführen.

TEP-HA auf DPU aktiviert.

Bei Erkennung des Ereignisses: „TEP-HA aktiviert für TEP:{vtep_name} von VDS:{dvs_name} auf Transportknoten:{transport_node_id} auf DPU {dpu_id}. “

Bei Auflösung des Ereignisses: „TEP-HA gelöscht für TEP:{vtep_name} von VDS:{dvs_name} auf Transportknoten:{transport_node_id} auf DPU {dpu_id}. “

Aktivieren Sie AutoWiederherstellen, oder rufen Sie die manuelle Wiederherstellung für TEP {vtep_name} auf VDS {dvs_name} auf Transportknoten {transport_node_id} auf DPU {dpu_id} auf.

AutoWiederherstellen auf DPU erfolgreich.

Bei Erkennung des Ereignisses: „Automatische Wiederherstellung für TEP {vtep_name} von VDS {dvs_name} auf Transportknoten {transport_node_id} auf DPU {dpu_id} ist erfolgreich. “

Bei Auflösung des Ereignisses: „Automatische Wiederherstellung für TEP:{vtep_name} von VDS:{dvs_name} auf Transportknoten:{transport_node_id} auf DPU {dpu_id} wurde gelöscht. “

Keine.

AutoWiederherstellung auf DPU fehlgeschlagen.

Bei Erkennung des Ereignisses: „Automatische Wiederherstellung für TEP:{vtep_name} von VDS:{dvs_name} auf Transportknoten:{transport_node_id} auf DPU {dpu_id} ist fehlgeschlagen. Overlay-Arbeitslasten, die diesen TEP verwenden, führen ein Failover auf andere fehlerfreie TEPs durch. Wenn keine anderen fehlerfreien TEPs vorhanden sind, kommt es bei Overlay-Arbeitslasten zu einem Netzwerkausfall. “

Bei Auflösung des Ereignisses: „Automatische Wiederherstellung für TEP:{vtep_name} von VDS:{dvs_name} auf Transportknoten:{transport_node_id} auf DPU {dpu_id} wurde gelöscht. “

Überprüfen Sie, ob der TEP eine gültige IP-Adresse oder andere Underlay-Konnektivitätsprobleme aufweist.

Uplink auf DPU wird inaktiv.

Bei Erkennung des Ereignisses: „Uplink auf DPU {dpu_id} wird inaktiv. “

Bei Auflösung des Ereignisses: „Uplink auf DPU {dpu_id} wird aktiv. “

Überprüfen Sie den Status der physischen Netzwerkkarten von Uplinks auf den Hosts auf DPU {dpu_id}. Ermitteln Sie den zugeordneten Namen dieser physischen Netzwerkkarte auf dem Host und führen Sie dann eine Überprüfung der Benutzeroberfläche durch.
1. Navigieren Sie in der NSX-Benutzeroberfläche zu „Fabric“ | „Knoten“ | „Transportknoten“ | „Host-Transportknoten“.
2. Überprüfen Sie in der Liste „Host-Transportknoten“ die Spalte „Knotenstatus“. Suchen Sie den Transportknoten mit herabgestuftem oder inaktivem Knotenstatus.
3. Wählen Sie „&lttransport node&gt“ | „Überwachen“ aus. Überprüfen Sie die Bindung (Uplink), für die eine Herabstufung oder Inaktivität angegeben ist. Stellen Sie zum Vermeiden eines herabgestuften Zustands sicher, dass alle Uplink-Schnittstellen verbunden und aktiv sind. Dabei ist es unerheblich, ob sie verwendet werden oder nicht.

LACP auf DPU meldet Mitglied inaktiv.

Bei Erkennung des Ereignisses: „LACP auf DPU {dpu_id} meldet Mitglied inaktiv. “

Bei Auflösung des Ereignisses: „LACP auf DPU {dpu_id} meldet Mitglied als aktiv. “

Überprüfen Sie den Verbindungsstatus der LAG-Mitglieder auf DPU {dpu_id}. Ermitteln Sie den zugeordneten Namen der zugehörigen physischen Netzwerkkarte auf dem Host und führen Sie dann eine Überprüfung der Benutzeroberfläche durch.
1. Navigieren Sie in der NSX-Benutzeroberfläche zu „Fabric“ | „Knoten“ | „Transportknoten“ | „Host-Transportknoten“.
2. Überprüfen Sie in der Liste „Host-Transportknoten“ die Spalte „Knotenstatus“. Suchen Sie den Transportknoten mit herabgestuftem oder inaktivem Knotenstatus.
3. Wählen Sie „&lttransport node&gt“ | „Überwachen“ aus. Finden Sie die Bindung (Uplink), die als herabgestuft oder inaktiv gemeldet wird.
4. Überprüfen Sie die Statusdetails des LACP-Mitglieds, indem Sie sich bei der fehlgeschlagenen DPU {dpu_id} anmelden und esxcli network vswitch dvs vmware lacp status get ausführen.

Uplink wird inaktiv.

Bei Erkennung des Ereignisses: „Uplink wird inaktiv. “

Bei Auflösung des Ereignisses: „Uplink wird aktiv. “

Überprüfen Sie den Status der physischen Netzwerkkarten von Uplinks auf Hosts.
1. Navigieren Sie in der NSX-Benutzeroberfläche zu „Fabric“ | „Knoten“ | „Transportknoten“ | „Host-Transportknoten“.
2. Überprüfen Sie in der Liste „Host-Transportknoten“ die Spalte „Knotenstatus“. Suchen Sie den Transportknoten mit herabgestuftem oder inaktivem Knotenstatus.
3. Wählen Sie „&lttransport node&gt“ | „Überwachen“ aus. Überprüfen Sie die Bindung (Uplink), für die eine Herabstufung oder Inaktivität angegeben ist. Stellen Sie zum Vermeiden eines herabgestuften Zustands sicher, dass alle Uplink-Schnittstellen verbunden und aktiv sind. Dabei ist es unerheblich, ob sie verwendet werden oder nicht.

Uplink wird inaktiv.

Bei Erkennung des Ereignisses: „Uplink wird inaktiv. “

Bei Auflösung des Ereignisses: „Uplink wird aktiv. “

Überprüfen Sie den Status der physischen Netzwerkkarten von Uplinks auf Hosts.
1. Navigieren Sie in der NSX-Benutzeroberfläche zu „Fabric“ | „Knoten“ | „Transportknoten“ | „Host-Transportknoten“.
2. Überprüfen Sie in der Liste „Host-Transportknoten“ die Spalte „Knotenstatus“. Suchen Sie den Transportknoten mit herabgestuftem oder inaktivem Knotenstatus.
3. Wählen Sie „&lttransport node&gt“ | „Überwachen“ aus. Überprüfen Sie die Bindung (Uplink), für die eine Herabstufung oder Inaktivität angegeben ist. Stellen Sie zum Vermeiden eines herabgestuften Zustands sicher, dass alle Uplink-Schnittstellen verbunden und aktiv sind. Dabei ist es unerheblich, ob sie verwendet werden oder nicht.

LACP meldet Mitglied als inaktiv.

Bei Erkennung des Ereignisses: „LACP meldet Mitglied als inaktiv. “

Bei Auflösung des Ereignisses: „LACP meldet Mitglied als aktiv. “

Überprüfen Sie den Verbindungsstatus der LAG-Mitglieder auf den Hosts.
1. Navigieren Sie in der NSX-Benutzeroberfläche zu „Fabric“ | „Knoten“ | „Transportknoten“ | „Host-Transportknoten“.
2. Überprüfen Sie in der Liste „Host-Transportknoten“ die Spalte „Knotenstatus“. Suchen Sie den Transportknoten mit herabgestuftem oder inaktivem Knotenstatus.
3. Wählen Sie „&lttransport node&gt“ | „Überwachen“ aus. Finden Sie die Bindung (Uplink), die als herabgestuft oder inaktiv gemeldet wird.
4. Überprüfen Sie die Statusdetails des LACP-Mitglieds, indem Sie sich beim ausgefallenen Host anmelden und esxcli network vswitch dvs vmware lacp status get auf einem ESXi-Host bzw. ovs-appctl bond/show und ovs-appctl lacp/show auf einem KVM-Host ausführen.

Transit Connect kann nicht vollständig realisiert werden.

Bei Erkennung des Ereignisses: „Die Transit Connect-bezogene Konfiguration wird nicht vollständig korrekt realisiert. Mögliche Probleme können sein, dass die Anbieterinformationen nicht abgerufen werden können oder dass ein vorübergehender Kommunikationsfehler beim Anbieter aufgetreten ist. “

Bei Auflösung des Ereignisses: „Transit Connect-Fehler wird behoben. “

Wenn dieser Alarm nicht innerhalb von 10 Minuten automatisch aufgelöst wird, wiederholen Sie die neueste(n) Anforderung(en) im Zusammenhang mit der Transitverbindung. Wenn beispielsweise eine API-Anfrage des TGW-Anhangs diesen Alarm ausgelöst hat, wiederholen Sie die API-Anfrage des TGW-Anhangs. Wenn der Alarm auch nach einem erneuten Versuch nicht aufgelöst wird, führen Sie die folgenden Schritte aus:
1. Überprüfen Sie, ob die Aufgabe weiterhin fehlschlägt oder die Aufgabe wiederhergestellt wurde. a) Identifizieren Sie den Leader Manager-Knoten. Führen Sie nach der Anmeldung bei einem der Knoten den folgenden Befehl aus: – su admin – get cluster status verbose Dies zeigt den Leader Manager-Knoten an. b) Melden Sie sich beim NSX Leader Manager-Knoten an. Überprüfen Sie vmc-app.log auf dem NSX Leader Manager-Knoten: – tail -f /var/log/policy/vmc-app.log c) Durchsuchen Sie die Protokolle nach den folgenden Abzügen – Wenn eine dieser Fehlermeldungen weiterhin alle zwei Minuten angezeigt wird, bedeutet dies, dass die Aufgabe weiterhin fehlschlägt. – Fehler beim Abrufen der TGW-Routentabelle für []. Fehler: [] – Fehler beim Abrufen der TGW-Routen für Anhang [] in Routentabelle []. Fehler – Fehler beim Abrufen der VPC-ID des TGW-Anhangs für []. Fehler: [] – Fehler beim Abrufen der Ressourcen-ID des TGW-Anhangs für []. Fehler: Unbekannter Ressourcentyp – Fehler beim Abrufen von TGW-Anhängen für TGW []. Fehler: [] – Fehler beim Abrufen des lokalen TGW-Anhangs []. Fehler: [] – Fehler beim Auffinden des richtigen TgwAttachment-Status in AWS, Status: [], Überspringen der Aufgabe zum Aktualisieren der TGW-Route – TGW-Anhang [] ist keiner Routentabelle zugeordnet – Kein lokaler TGW-SDDC-Anhang gefunden für []
2. Überprüfen Sie, ob alle AWS-Aufrufe vom NSX Manager auf dem Leader Manager-Knoten fehlgeschlagen sind. Führen Sie den folgenden Befehl aus: – 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 Wenn der AWS-Befehl mit einem Fehler fehlgeschlagen ist, liegt möglicherweise ein Systemproblem in der HTTP Reverse Proxy-Konfiguration auf pop vor, oder es gibt ein AWS-dienstseitiges Problem.
3. Überprüfen Sie, ob der TGW-Anhang noch in AWS vorhanden ist. a) Die TGW-Anhangs-ID wurde mit GET cloud-service/api/v1/infra/associated-groups – aws ec2 describe-transit-gateway-attachments --region gefunden --transit-gateway-attachment-id &ltTGW attachment ID&gt Wenn der TGW-Anhang gelöscht wurde, wenden Sie sich an VMware Support und teilen Sie die SDDC-ID und TGW-Anhang-ID. Nachdem das VMware-Supportteam das Problem identifiziert hat, löschen Sie das zurückgelassene Objekt bei Bedarf manuell. b) Überprüfen Sie, ob dieser TGW-Anhang auf der AWS-Konsole vorhanden ist. c) Eine weitere Option ist die Anmeldung beim NSX Manager, unter Verwendung des AWS-Befehls, um den Status des TGW-Anhangs zu überprüfen: – aws ec2 describe-transit-gateway-attachments --region --transit-gateway-attachment-id &ltTGW attachment ID&gt

IPsec-Dienst ist ausgefallen.

Bei Erkennung des Ereignisses: „Der IPsec-Dienst {entity_id} ist inaktiv. Grund: {service_down_reason}. “

Bei Auflösung des Ereignisses: „Der IPsec-Dienst {entity_id} ist aktiv. “

1. Deaktivieren und aktivieren Sie den IPSec-Dienst über die NSX Manager-Benutzeroberfläche.
2. Wenn das Problem weiterhin besteht, überprüfen Sie Syslog auf Fehlerprotokolle und wenden Sie sich an den VMware Support.

Die richtlinienbasierte IPsec-VPN-Sitzung ist ausgefallen.

Bei Erkennung des Ereignisses: „Die richtlinienbasierte IPsec-VPN-Sitzung {entity_id} ist inaktiv. Grund: {session_down_reason}. “

Bei Auflösung des Ereignisses: „Die richtlinienbasierte IPsec-VPN-Sitzung {entity_id} ist aktiv. “

Überprüfen Sie die IPsec-VPN-Sitzungskonfiguration und beheben Sie Fehler basierend auf dem Grund für die inaktive Sitzung.

Die routenbasierte IPsec-VPN-Sitzung ist ausgefallen.

Bei Erkennung des Ereignisses: „Die routenbasierte IPsec-VPN-Sitzung {entity_id} ist inaktiv. Grund: {session_down_reason}. “

Bei Auflösung des Ereignisses: „Die routenbasierte IPsec-VPN-Sitzung {entity_id} ist aktiv. “

Überprüfen Sie die IPsec-VPN-Sitzungskonfiguration und beheben Sie Fehler basierend auf dem Grund für die inaktive Sitzung.

Die richtlinienbasierten IPsec-VPN-Tunnel sind ausgefallen.

Bei Erkennung des Ereignisses: „Mindestens ein richtlinienbasierter IPsec-VPN-Tunnel in der Sitzung {entity_id} ist inaktiv. “

Bei Auflösung des Ereignisses: „Alle richtlinienbasierten IPsec-VPN-Tunnel in der Sitzung {entity_id} sind aktiv. “

Überprüfen Sie die IPSec-VPN-Sitzungskonfiguration und beheben Sie Fehler basierend auf dem Grund für den inaktiven Tunnel.

Der routenbasierte IPsec-VPN-Tunnel ist ausgefallen.

Bei Erkennung des Ereignisses: „Der routenbasierte IPsec-VPN-Tunnel in der Sitzung {entity_id} ist inaktiv. Grund: {tunnel_down_reason}. “

Bei Auflösung des Ereignisses: „Der routenbasierte IPsec-VPN-Tunnel in der Sitzung {entity_id} ist aktiv. “

Überprüfen Sie die IPSec-VPN-Sitzungskonfiguration und beheben Sie Fehler basierend auf dem Grund für den inaktiven Tunnel.

L2VPN-Sitzung ist inaktiv.

Bei Erkennung des Ereignisses: „Die L2VPN-Sitzung {entity_id} ist inaktiv. “

Bei Auflösung des Ereignisses: „Die L2VPN-Sitzung {entity_id} ist aktiv. “

Überprüfen Sie den L2VPN-Sitzungsstatus hinsichtlich der Ursache für die inaktive Sitzung und beheben Sie Fehler basierend auf der Ursache.