경보 서비스가 오버로드됩니다.

이벤트가 감지된 경우: "많은 양의 경보가 보고되었기 때문에 경보 서비스가 일시적으로 오버로드됩니다. NSX UI 및 GET /api/v1/alarms NSX API는 새 경보의 보고를 중지했습니다. 그러나 syslog 항목 및 SNMP 트랩(사용하도록 설정된 경우)이 내보내지면서 여전히 기본 이벤트 세부 정보를 보고합니다. 많은 양의 경보를 유발하는 기본 문제가 해결되면 경보 서비스가 새 경보를 다시 보고하기 시작합니다. "

이벤트가 해결된 경우: "많은 양의 경보가 완화되었으며 새 경보가 다시 보고되는 중입니다. "

NSX UI의 [경보] 페이지를 사용하거나 GET /api/v1/alarms?status=OPEN,ACKNOWLEDGED,SUPPRESSED NSX API를 사용하여 모든 활성 경보를 검토하십시오. 각 활성 경보에 대해 권장되는 작업을 따라 근본 원인을 조사하십시오. 충분한 경보가 해결되면 경보 서비스에서 새 경보를 다시 보고하기 시작합니다.

특정 경보 유형이 과도하게 감지되었습니다.

이벤트가 감지된 경우: "대량의 {event_id} 경보로 인해 경보 서비스가 이 유형의 경보 보고를 일시적으로 중지했습니다. NSX UI 및 GET /api/v1/alarms NSX API는 이러한 경보의 새 인스턴스에 대한 보고를 중지했습니다. 그러나 syslog 항목 및 SNMP 트랩(사용하도록 설정된 경우)이 내보내지면서 여전히 기본 이벤트 세부 정보를 보고합니다. 많은 양의 {event_id} 경보를 유발하는 기본 문제가 해결되면 새로운 문제가 다시 감지될 때 경보 서비스가 새 {event_id} 경보를 보고하기 시작합니다. "

이벤트가 해결된 경우: "많은 양의 {event_id} 경보가 완화되었으며 이 유형의 새로운 경보가 다시 보고되는 중입니다. "

NSX UI의 [경보] 페이지를 사용하거나 NSX API GET /api/v1/alarms?status=OPEN,ACKNOWLEDGED,SUPPRESSED를 사용하여 {event_id} 유형의 모든 활성 경보를 검토하십시오. 각 활성 경보에 대해 권장되는 작업을 따라 근본 원인을 조사하십시오. 충분한 경보가 해결되면 경보 서비스에서 새 {event_id} 경보를 다시 보고하기 시작합니다.

모니터링되는 로그 파일 중 하나 이상에 쓸 수 없습니다.

이벤트가 감지된 경우: "모니터링되는 로그 파일 중 하나 이상에 읽기 전용 사용 권한이 있거나 관리자, 글로벌 관리자, Edge, 공용 클라우드 게이트웨이, KVM 또는 Linux 물리적 서버 노드에 대한 사용자/그룹 소유권이 잘못되었습니다. 또는 Windows 물리적 서버 노드에 로그 폴더가 없습니다. 또는 관리자, 글로벌 관리자, Edge 또는 공용 클라우드 게이트웨이 노드에 rsyslog.log가 없습니다. "

이벤트가 해결된 경우: "모니터링되는 모든 로그 파일에 관리자, 글로벌 관리자, Edge, 공용 클라우드 게이트웨이, KVM 또는 Linux 물리적 서버 노드에 대한 올바른 파일 사용 권한 및 소유권이 있습니다. 그리고 로그 폴더가 Windows 물리적 서버 노드에 있습니다. 그리고 관리자, 글로벌 관리자, Edge 또는 공용 클라우드 게이트웨이 노드에 rsyslog.log가 있습니다. "

1. Manager 및 글로벌 관리자 노드, Edge 및 공용 클라우드 게이트웨이 노드에서 Ubuntu KVM 호스트 노드는 /var/log 디렉토리에 대한 사용 권한이 775이고 소유권이 root:syslog인지 확인합니다. Rhel KVM 및 BMS 호스트 노드에서 /var/log 디렉토리에 대한 사용 권한이 755이고 소유권이 root:root인지 확인합니다.
2. Manager 및 글로벌 관리자 노드에서 /var/log의 auth.log, nsx-audit.log, nsx-audit-write.log, rsyslog.log 및 syslog에 대한 파일 사용 권한이 640이고 소유권이 syslog:admin인지 확인합니다.
3. Edge 및 공용 클라우드 게이트웨이 노드에서 /var/log의 rsyslog.log 및 syslog에 대한 파일 사용 권한이 640이고 소유권이 syslog:admin인지 확인합니다.
4. Ubuntu KVM 호스트 및 Ubuntu 물리적 서버 노드의 /var/log에서 auth.log 및 vmware/nsx-syslog의 파일 사용 권한이 640이고 소유권이 syslog:admin인지 확인합니다.
5. Rhel KVM 호스트 노드 및 Centos/Rhel/Sles 물리적 서버 노드에서 /var/log에서 vmware/nsx-syslog의 파일 사용 권한이 640이고 소유권이 root:root인지 확인합니다.
6. 이러한 파일에 잘못된 사용 권한 또는 소유권이 있는 경우 chmod &ltmode&gt &ltpath&gt 및 chown &ltuser&gt:&ltgroup&gt &ltpath&gt 명령을 호출합니다.
7. 관리자, 글로벌 관리자, Edge 또는 공용 클라우드 게이트웨이 노드에 rsyslog.log가 누락된 경우 로깅 서비스를 다시 시작하고 /var/log/rsyslog.log를 재생성하는 NSX CLI 명령 restart service syslog를 호출합니다.
8. Windows 물리적 서버 노드에서 로그 폴더 C:\ProgramData\VMware\NSX\Logs가 있는지 확인합니다. 그렇지 않은 경우 Windows 물리적 서버 노드에 NSX를 다시 설치해 보십시오.

잘못된 원격 로깅 서버 구성으로 인해 로그 메시지를 배달할 수 없습니다.

이벤트가 감지된 경우: "로깅 서버 {hostname_or_ip_address_with_port}({entity_id})에 대한 로그 메시지는 확인할 수 없는 FQDN, 잘못된 TLS 인증서 또는 누락된 NSX 장치 iptables 규칙으로 인해 제공될 수 없습니다. "

이벤트가 해결된 경우: "로깅 서버 {hostname_or_ip_address_with_port}({entity_id})에 대한 구성이 올바른 것으로 나타납니다. "

1. {hostname_or_ip_address_with_port}가 올바른 호스트 이름 또는 IP 주소와 포트인지 확인합니다.
2. 로깅 서버가 FQDN을 사용하여 지정된 경우 NSX CLI 명령 nslookup &ltfqdn&gt을 사용하여 NSX 장치에서 FQDN을 확인할 수 있는지 확인합니다. 확인할 수 없는 경우 올바른 FQDN이 지정되어 있고 네트워크 DNS 서버에 FQDN에 대한 필수 항목이 있는지 확인합니다.
3. 로깅 서버가 TLS를 사용하도록 구성된 경우 지정된 인증서가 유효한지 확인합니다. 예를 들어 로깅 서버가 실제로 인증서를 사용하고 있는지 확인하거나 openssl 명령 openssl x509 -in &ltcert-file-path&gt -noout -dates를 사용하여 인증서가 만료되지 않았는지 확인합니다.
4. NSX 장치는 iptables 규칙을 사용하여 송신 트래픽을 명시적으로 허용합니다. 필요에 따라 로깅 서버 iptables 규칙을 재구성하는 NSX CLI 명령 verify logging-servers를 호출하여 로깅 서버의 iptables 규칙이 올바르게 구성되었는지 확인합니다.
5. 어떤 이유로든 로깅 서버가 잘못 구성되면 NSX CLI `del logging-server &lthostname-or-ip-address[:port]&gt proto &ltproto&gt level &ltlevel&gt` 명령을 사용하여 삭제한 후 올바른 구성으로 다시 추가해야 합니다.

최소 용량 임계값이 초과되었습니다.

이벤트가 감지된 경우: {capacity_display_name}에 대해 시스템에 정의된 개체 수가 최소 용량 임계값 {min_capacity_threshold}%를 초과하는 {capacity_usage_count}에 도달했습니다. "

이벤트가 해결된 경우: "시스템에서 {capacity_display_name}에 대해 정의된 개체 수가 {capacity_usage_count}에 도달했으며 최소 용량 임계값 {min_capacity_threshold}% 이하입니다. "

NSX UI의 용량 페이지로 이동하고 현재 사용량과 임계값 제한을 검토합니다. 현재 사용량이 예상되는 경우 최소 임곗값을 늘리는 것이 좋습니다. 현재 사용량이 예상되지 않는 경우 사용량을 최소 임계값 이하로 줄이도록 구성된 네트워크 정책을 검토합니다.

최대 용량 임계값이 초과되었습니다.

이벤트가 감지된 경우: "{capacity_display_name}에 대해 시스템에 정의된 개체 수가 최대 용량 임계값 {max_capacity_threshold}%를 초과하는 {capacity_usage_count}에 도달했습니다. "

이벤트가 해결된 경우: 시스템에서 {capacity_display_name}에 대해 정의된 개체 수가 {capacity_usage_count}에 도달했으며 최대 용량 임계값 {max_capacity_threshold}% 이하입니다. "

NSX UI의 용량 페이지로 이동하고 현재 사용량과 임계값 제한을 검토합니다. 현재 사용량이 예상되는 경우 최대 임곗값을 늘리는 것이 좋습니다. 현재 사용량이 예기치 않은 경우 사용량을 최대 임계값 이하로 줄이도록 구성된 네트워크 정책을 검토합니다.

최대 용량이 초과되었습니다.

이벤트가 감지된 경우: {capacity_display_name}에 대해 시스템에 정의된 개체 수가 지원되는 최대 개수 {max_supported_capacity_count}을(를) 초과하는 {capacity_usage_count}에 도달했습니다. "

이벤트가 해결된 경우: "시스템에서 {capacity_display_name}에 대해 정의된 개체 수가 {capacity_usage_count}에 도달했으며 지원되는 최대 수 {max_supported_capacity_count} 이하입니다. "

생성된 NSX 개체의 수가 NSX에서 지원되는 제한 내에 있는지 확인합니다. 사용되지 않는 개체가 있는 경우 시스템에서 해당 NSX UI 또는 API를 사용하여 삭제합니다. 모든 관리자 노드 및/또는 Edge 노드의 폼 팩터를 늘리는 것이 좋습니다. 각 노드 유형의 폼 팩터는 동일해야 합니다. 동일하지 않으면 배포된 가장 낮은 폼 팩터에 대한 용량 제한이 사용됩니다.

인증서가 만료되었습니다.

이벤트가 감지된 경우: "인증서 {entity_id}이(가) 만료되었습니다. "

이벤트가 해결된 경우: "만료된 인증서 {entity_id}이(가) 제거되었거나 더 이상 만료 상태가 아닙니다. "

현재 인증서를 사용하고 있는 서비스가 만료되지 않은 새 인증서를 사용하도록 업데이트되었는지 확인합니다. 만료된 인증서가 더 이상 사용되지 않는 경우 DELETE {api_collection_path}{entity_id} NSX API를 호출하여 인증서를 삭제해야 합니다. 만료된 인증서가 NAPP 플랫폼에 사용되는 경우 NSX와 NAPP 플랫폼 간의 연결이 끊어질 수 있습니다. 연결 복구를 위해 자체 서명된 NAPP CA 인증서를 사용하려면 NAPP Platform 문제 해결 문서를 확인하십시오.

인증서가 곧 만료됩니다.

이벤트가 감지된 경우: "인증서 {entity_id}이(가) 곧 만료됩니다. "

이벤트가 해결된 경우: "만료될 인증서 {entity_id}이(가) 제거되었거나 더 이상 만료될 예정이 아닙니다. "

현재 인증서를 사용하고 있는 서비스가 곧 만료될 예정이 아닌 새 인증서를 사용하도록 업데이트되었는지 확인합니다. 만료 예정인 인증서가 더 이상 사용되지 않는 경우 DELETE {api_collection_path}{entity_id} NSX API를 호출하여 인증서를 삭제해야 합니다.

인증서가 곧 만료될 예정입니다.

이벤트가 감지된 경우: "인증서 {entity_id}이(가) 곧 만료될 예정입니다. "

이벤트가 해결된 경우: "만료 예정인 인증서 {entity_id}이(가) 제거되었거나 더 이상 만료에 가까워지지 않습니다. "

현재 인증서를 사용하고 있는 서비스가 곧 만료될 예정이 아닌 새 인증서를 사용하도록 업데이트되었는지 확인합니다. 만료 예정인 인증서가 더 이상 사용되지 않는 경우 DELETE {api_collection_path}{entity_id} NSX API를 호출하여 인증서를 삭제해야 합니다.

신뢰할 수 있는 CA 번들에 대한 업데이트가 권장됩니다.

이벤트가 감지된 경우: "신뢰할 수 있는 CA 번들 {entity_id}이(가) {ca_bundle_age_threshold}일 전에 업데이트되었습니다. 신뢰할 수 있는 CA 번들에 대한 업데이트가 권장됩니다. "

이벤트가 해결된 경우: "신뢰할 수 있는 CA 번들 {entity_id}이(가) 제거되었거나 업데이트되었거나 더 이상 사용되지 않습니다. "

현재 신뢰할 수 있는 CA 번들을 사용하는 서비스가 최근에 업데이트된 신뢰할 수 있는 CA 번들을 사용하도록 업데이트되었는지 확인합니다. 시스템에서 제공하는 번들인 경우가 아니면 PUT /policy/api/v1/infra/cabundles/{entity_id} NSX API를 사용하여 번들을 업데이트할 수 있습니다. 만료된 번들을 더 이상 사용하지 않는 경우 DELETE /policy/api/v1/infra/cabundles/{entity_id} NSX API를 호출하여 삭제해야 합니다(시스템 제공 번들이 아닌 경우).

신뢰할 수 있는 CA 번들에 대한 업데이트가 제안됩니다.

이벤트가 감지된 경우: "신뢰할 수 있는 CA 번들 {entity_id}이(가) {ca_bundle_age_threshold}일 전에 업데이트되었습니다. 신뢰할 수 있는 CA 번들에 대한 업데이트가 제안됩니다. "

이벤트가 해결된 경우: "신뢰할 수 있는 CA 번들 {entity_id}이(가) 제거되었거나 업데이트되었거나 더 이상 사용되지 않습니다. "

현재 신뢰할 수 있는 CA 번들을 사용하는 서비스가 최근에 업데이트된 신뢰할 수 있는 CA 번들을 사용하도록 업데이트되었는지 확인합니다. 시스템에서 제공하는 번들인 경우가 아니면 PUT /policy/api/v1/infra/cabundles/{entity_id} NSX API를 사용하여 번들을 업데이트할 수 있습니다. 만료된 번들을 더 이상 사용하지 않는 경우 DELETE /policy/api/v1/infra/cabundles/{entity_id} NSX API를 호출하여 삭제해야 합니다(시스템 제공 번들이 아닌 경우).

인증서가 만료되었습니다.

이벤트가 감지된 경우: 전송 노드 {entity_id}에 대한 인증서가 만료되었습니다. "

이벤트가 해결된 경우: "전송 노드 {entity_id}에 대해 만료된 인증서가 교체되었거나 더 이상 만료 상태가 아닙니다. "

전송 노드 {entity_id} 인증서를 만료되지 않은 인증서로 교체합니다. 만료된 인증서는 POST /api/v1/trust-management/certificates/action/replace-host-certificate/{entity_id} NSX API를 호출하여 교체해야 합니다. 만료된 인증서가 전송 노드에서 사용되는 경우 전송 노드와 관리자 노드 간의 연결이 끊어집니다.

인증서가 곧 만료됩니다.

이벤트가 감지된 경우: "전송 노드 {entity_id}의 인증서가 곧 만료될 예정입니다. "

이벤트가 해결된 경우: "전송 노드 {entity_id}에 대해 만료될 인증서가 제거되었거나 더 이상 만료될 예정이 아닙니다. "

전송 노드 {entity_id} 인증서를 만료되지 않은 인증서로 교체합니다. 만료된 인증서는 POST /api/v1/trust-management/certificates/action/replace-host-certificate/{entity_id} NSX API를 호출하여 교체해야 합니다. 인증서를 교체하지 않을 경우 인증서가 만료되면 전송 노드와 관리자 노드 간의 연결이 끊어집니다.

인증서가 곧 만료될 예정입니다.

이벤트가 감지된 경우: "전송 노드 {entity_id}의 인증서가 곧 만료될 예정입니다. "

이벤트가 해결된 경우: "전송 노드 {entity_id}에 대해 만료될 인증서가 제거되었거나 더 이상 만료에 가까워지지 않습니다. "

전송 노드 {entity_id} 인증서를 만료되지 않은 인증서로 교체합니다. 만료된 인증서는 POST /api/v1/trust-management/certificates/action/replace-host-certificate/{entity_id} NSX API를 호출하여 교체해야 합니다. 인증서를 교체하지 않을 경우 인증서가 만료되면 전송 노드와 관리자 노드 간의 연결이 끊어집니다.

그룹 멤버가 종료되었습니다.

이벤트가 감지된 경우: "{group_type} 서비스의 그룹 멤버 {manager_node_id}이(가) 종료되었습니다. "

이벤트가 해결된 경우: "{group_type}의 그룹 멤버 {manager_node_id}이(가) 실행 중입니다. "

1. NSX CLI 명령 'get cluster status'를 호출하여 클러스터의 그룹 멤버 상태를 봅니다.
2. 노드에서 {group_type}에 대한 서비스가 실행 중인지 확인합니다. GET /api/v1/node/services/&ltservice_name&gt/status NSX API 또는 get service &ltservice_name&gt NSX CLI 명령을 호출하여 서비스가 실행 중인지 확인합니다. 실행되고 있지 않으면 POST /api/v1/node/services/&ltservice_name&gt?action=restart NSX API 또는 restart service &ltservice_name&gt NSX CLI를 호출하여 서비스를 다시 시작합니다.
3. 서비스 {group_type}의 /var/log/를 확인하여 보고된 오류가 있는지 알아봅니다.

서비스의 모든 그룹 멤버가 종료되었습니다.

이벤트가 감지된 경우: "{group_type} 서비스의 모든 그룹 멤버 {manager_node_ids}이(가) 종료되었습니다. "

이벤트가 해결된 경우: "서비스 {group_type}의 모든 그룹 멤버 {manager_node_ids}이(가) 실행 중입니다. "

1. 노드에서 {group_type}에 대한 서비스가 실행 중인지 확인합니다. GET /api/v1/node/services/&ltservice_name&gt/status NSX API 또는 get service &ltservice_name&gt NSX CLI 명령을 호출하여 서비스가 실행 중인지 확인합니다. 실행되고 있지 않으면 POST /api/v1/node/services/&ltservice_name&gt?action=restart NSX API 또는 restart service &ltservice_name&gt NSX CLI를 호출하여 서비스를 다시 시작합니다.
2. 서비스 {group_type}의 /var/log/를 확인하여 보고된 오류가 있는지 알아봅니다.

DPU에서 하이퍼버스가 관리자 노드와 통신할 수 없습니다.

이벤트가 감지된 경우: "DPU {dpu_id}에서 하이퍼버스가 관리자 노드와 통신할 수 없습니다. "

이벤트가 해결된 경우: "DPU {dpu_id}에서 하이퍼버스가 관리자 노드와 통신할 수 있습니다. "

DPU {dpu_id}에서 하이퍼버스 VMkernel 인터페이스(vmk50)가 누락되었을 수 있습니다. 기술 자료 문서 https://kb.vmware.com/s/article/67432를 참조하십시오.

Hyperbus가 관리자 노드와 통신할 수 없습니다.

이벤트가 감지된 경우: "Hyperbus가 관리자 노드와 통신할 수 없습니다. "

이벤트가 해결된 경우: "Hyperbus가 관리자 노드와 통신할 수 있습니다. "

Hyperbus vmkernel 인터페이스(vmk50)가 누락되었을 수 있습니다. 기술 자료 문서 https://kb.vmware.com/s/article/67432를 참조하십시오.

지정된 수집기는 DPU의 지정된 DVS에서 vmknic를 통해 연결할 수 없습니다.

이벤트가 감지된 경우: "{vertical_name} 수집기 {collector_ip}에 DPU {dpu_id}의 DVS {dvs_alias}에서 vmknic(스택 {stack_alias})를 통해 연결할 수 없지만 다른 DVS의 vmknic(스택 {stack_alias})를 통해 연결할 수 있습니다. "

이벤트가 해결된 경우: "{vertical_name} 수집기 {collector_ip}에 DPU {dpu_id}의 DVS {dvs_alias}에 있는 vmknic(스택 {stack_alias})를 통해 연결할 수 있거나 {vertical_name} 수집기 {collector_ip}에 완전히 연결할 수 없습니다. "

주의가 켜져 있다고 해서 수집기에 연결할 수 없다는 의미는 아닙니다. DVS {dvs_alias} 기준의 세로에서 생성된 내보낸 흐름은 DVS {dvs_alias} 외에 DVS의 vmknic를 통해 수집기 {collector_ip}에 계속 연결할 수 있습니다. 허용할 수 없는 경우 사용자는 DVS {dvs_alias}에서 스택 {stack_alias}을(를) 사용하여 vmknic를 생성하고 해당 IPv4(6) 주소로 구성할 수 있습니다. 그런 다음 ESXi를 통해 SSH에서 DPU로 사용하도록 설정하여 vmkping {collector_ip} -S {stack_alias} -I vmkX를 호출하여 DPU {dpu_id}에 새로 생성된 vmknic를 통해 {vertical_name} 수집기 {collector_ip}에 연결할 수 있는지 확인합니다.

지정된 수집기는 DPU의 기존 vmknic를 통해 연결할 수 없습니다.

이벤트가 감지된 경우: "{vertical_name} 수집기 {collector_ip}에 DPU {dpu_id}의 DVS에 있는 기존 vmknic(스택 {stack_alias})를 통해 연결할 수 없습니다. "

이벤트가 해결된 경우: "이제 DPU {dpu_id}의 기존 vmknic(스택 {stack_alias})를 사용하여 {vertical_name} 수집기 {collector_ip}에 연결할 수 있습니다. "

DVS에서 지정된 수직으로 수집기를 연결할 수 있도록 하려면 예상 스택 {stack_alias}이(가) 있는 vmknic가 생성되고 해당 IPv4(6) 주소로 구성되어야 하며 {vertical_name} 수집기 {collector_ip}에 대한 네트워크 연결 상태도 좋아야 합니다. 따라서 사용자는 DPU {dpu_id}에 대한 검사를 수행하고 필요한 구성을 수행하여 조건이 충족되는지 확인해야 합니다. 마지막으로 ESXi를 통해 SSH에서 DPU로 사용하도록 설정하여 vmkping {collector_ip} -S {stack_alias}에 성공하면 문제가 없음을 나타냅니다.

관리자 노드 간 평균 네트워크 지연 시간이 깁니다.

이벤트가 감지된 경우: “관리자 노드 {manager_node_id}({appliance_address})과(와) {remote_manager_node_id}({remote_appliance_address}) 사이의 평균 네트워크 지연 시간이 지난 5분 동안 10ms를 초과합니다. "

이벤트가 해결된 경우: "관리자 노드 {manager_node_id}({appliance_address})과 {remote_manager_node_id}({remote_appliance_address}) 사이의 평균 네트워크 지연 시간이 10ms 미만입니다. "

관리자 노드 간의 ping 트래픽을 차단하는 방화벽 규칙이 없는지 확인합니다. 로컬 네트워크를 공유하는 다른 높은 대역폭 서버 및 애플리케이션이 있는 경우 다른 네트워크로 이동하는 것이 좋습니다.

관리자 노드로의 전송 노드 제어부 연결이 오랫동안 끊겼습니다.

이벤트가 감지된 경우: "관리자 노드 {appliance_address}에 대한 전송 노드 {entity_id} 제어부가 전송 노드의 관점에서 최소 {timeout_in_minutes}분 동안 종료되었습니다. "

이벤트가 해결된 경우: "전송 노드 {entity_id}은(는) 관리자 노드 {appliance_address}에 대한 제어부 연결을 복원합니다. "

1. ping을 통해 전송 노드 {entity_id}에서 관리자 노드 {appliance_address} 인터페이스로의 연결을 확인합니다. Ping할 수 없는 경우 네트워크 연결이 끊기는지 확인합니다.
2. netstat 출력을 사용하여 TCP 연결을 설정했는지 확인하고 관리자 노드의 컨트롤러 서비스 {appliance_address}이(가) 포트 1235에서 연결을 수신하고 있는지 확인합니다. 확인되지 않을 경우 방화벽 (또는) iptables 규칙을 확인하여 포트 1235가 전송 노드 {entity_id} 연결 요청을 차단하고 있는지 확인합니다. 언더레이에서 관리자 노드와 전송 노드 간에 필요한 IP 포트를 차단하는 호스트 방화벽이나 네트워크 방화벽이 없는지 확인합니다. 이 내용은 https://ports.vmware.com/의 포트 및 프로토콜 도구에 설명되어 있습니다.
3. 전송 노드 {entity_id}이(가) 계속 유지 보수 모드일 수 있습니다. 다음 API를 통해 전송 노드가 유지 보수 모드에 있는지 여부를 확인할 수 있습니다. GET https://&ltnsx-mgr&gt/api/v1/transport-nodes/&lttn-uuid&gt. 유지 보수 모드가 설정되면 전송 노드가 컨트롤러 서비스에 연결되지 않습니다. 이는 일반적으로 호스트 업그레이드가 진행 중인 경우에 발생합니다. 몇 분 동안 기다렸다가 연결을 다시 확인합니다.

관리자 노드로의 전송 노드 제어부 연결이 끊겼습니다.

이벤트가 감지된 경우: "관리자 노드 {appliance_address}에 대한 전송 노드 {entity_id} 제어부가 전송 노드의 관점에서 최소 {timeout_in_minutes}분 동안 종료되었습니다. "

이벤트가 해결된 경우: "전송 노드 {entity_id}은(는) 관리자 노드 {appliance_address}에 대한 제어부 연결을 복원합니다. "

1. ping을 통해 전송 노드 {entity_id}에서 관리자 노드 {appliance_address} 인터페이스로의 연결을 확인합니다. Ping할 수 없는 경우 네트워크 연결이 끊기는지 확인합니다.
2. netstat 출력을 사용하여 TCP 연결을 설정했는지 확인하고 관리자 노드의 컨트롤러 서비스 {appliance_address}이(가) 포트 1235에서 연결을 수신하고 있는지 확인합니다. 확인되지 않을 경우 방화벽 (또는) iptables 규칙을 확인하여 포트 1235가 전송 노드 {entity_id} 연결 요청을 차단하고 있는지 확인합니다. 언더레이에서 관리자 노드와 전송 노드 간에 필요한 IP 포트를 차단하는 호스트 방화벽이나 네트워크 방화벽이 없는지 확인합니다. 이 내용은 https://ports.vmware.com/의 포트 및 프로토콜 도구에 설명되어 있습니다.
3. 전송 노드 {entity_id}이(가) 계속 유지 보수 모드일 수 있습니다. 다음 API를 통해 전송 노드가 유지 보수 모드에 있는지 여부를 확인할 수 있습니다. GET https://&ltnsx-mgr&gt/api/v1/transport-nodes/&lttn-uuid&gt 유지 보수 모드가 설정되면 전송 노드가 컨트롤러 서비스에 연결되지 않습니다. 이는 일반적으로 호스트 업그레이드가 진행 중인 경우에 발생합니다. 몇 분 동안 기다렸다가 연결을 다시 확인합니다. 참고: 이 경보는 위험하지 않으며 해결해야 합니다. 경고가 장기간 해결되지 않는 경우가 아니면 이 경보의 알림을 보기 위해 GSS에 연결할 필요가 없습니다.

전송 노드로의 컨트롤러 서비스 연결이 끊겼습니다.

이벤트가 감지된 경우: "전송 노드 {transport_node_name}({entity_id})에 대한 관리자 노드의 컨트롤러 서비스 {appliance_address}({central_control_plane_id})이(가) 컨트롤러 서비스의 관점에서 최소 3분 동안 종료되었습니다. "

이벤트가 해결된 경우: "관리자 노드의 컨트롤러 서비스 {appliance_address}({central_control_plane_id})과(와) 전송 노드 {entity_id}(과)와의 연결이 복원되었습니다. "

1. ping 및 traceroute를 통해 컨트롤러 서비스 {central_control_plane_id} 및 전송 노드 {entity_id} 인터페이스에서의 연결을 확인하십시오. 이 작업은 NSX Manager 노드 admin CLI에서 수행할 수 있습니다. ping 테스트 결과로 삭제가 표시되지 않아야 하며 일관된 지연 시간 값이 표시되어야 합니다. 지연 시간이 150ms 이하로 유지되는 것이 좋습니다.
2. NSX UI에서 시스템 | 패브릭 | 노드 | 전송 노드 {entity_id}(으)로 이동하여 관리자 노드의 컨트롤러 서비스 {appliance_address}({central_control_plane_id})과(와) 전송 노드 {entity_id} 간에 TCP 연결이 설정되어 있는지 확인합니다. 이 연결이 없으면 네트워크 및 호스트의 방화벽 규칙을 확인하여 포트 1235가 전송 노드 {entity_id} 연결 요청을 차단하고 있는지 확인합니다. 언더레이에서 관리자 노드와 전송 노드 간에 필요한 IP 포트를 차단하는 호스트 방화벽이나 네트워크 방화벽이 없는지 확인합니다. 이 내용은 https://ports.vmware.com/의 포트 및 프로토콜 도구에 설명되어 있습니다.

전송 노드에 대한 컨트롤러 서비스 연결이 너무 오랫동안 종료되었습니다.

이벤트가 감지된 경우: "전송 노드 {transport_node_name}({entity_id})에 대한 관리자 노드의 컨트롤러 서비스 {appliance_address}({central_control_plane_id})이(가) 컨트롤러 서비스의 관점에서 최소 15분 동안 종료되었습니다. "

이벤트가 해결된 경우: "관리자 노드의 컨트롤러 서비스 {appliance_address}({central_control_plane_id})과(와) 전송 노드 {entity_id}(과)와의 연결이 복원되었습니다. "

1. ping 및 traceroute를 통해 컨트롤러 서비스 {central_control_plane_id} 및 전송 노드 {entity_id} 인터페이스에서의 연결을 확인하십시오. 이 작업은 NSX Manager 노드 admin CLI에서 수행할 수 있습니다. ping 테스트 결과로 삭제가 표시되지 않아야 하며 일관된 지연 시간 값이 표시되어야 합니다. 지연 시간이 150ms 이하로 유지되는 것이 좋습니다.
2. NSX UI에서 시스템 | 패브릭 | 노드 | 전송 노드 {entity_id}(으)로 이동하여 관리자 노드의 컨트롤러 서비스 {appliance_address}({central_control_plane_id})과(와) 전송 노드 {entity_id} 간에 TCP 연결이 설정되어 있는지 확인합니다. 이 연결이 없으면 네트워크 및 호스트의 방화벽 규칙을 확인하여 포트 1235가 전송 노드 {entity_id} 연결 요청을 차단하고 있는지 확인합니다. 언더레이에서 관리자 노드와 전송 노드 간에 필요한 IP 포트를 차단하는 호스트 방화벽이나 네트워크 방화벽이 없는지 확인합니다. 이 내용은 https://ports.vmware.com/의 포트 및 프로토콜 도구에 설명되어 있습니다.

관리자-컨트롤러 채널이 종료되었습니다.

이벤트가 감지된 경우: 관리자 노드 {manager_node_name}({appliance_address})에서 관리 기능과 제어 기능 간 통신이 실패했습니다. "

이벤트가 해결된 경우: "관리자 노드 {manager_node_name}({appliance_address})에서 관리 기능과 제어 기능 간 통신이 복원되었습니다. "

1. 관리자 노드 {manager_node_name}({appliance_address})에서 다음 NSX CLI 명령 get service applianceproxy를 호출하여 60분 동안 서비스의 상태를 주기적으로 확인합니다.
2. 서비스가 60분 넘게 실행되고 있지 않으면 NSX CLI 명령 restart service applianceproxy를 호출하고 상태를 다시 확인합니다. 서비스가 여전히 종료된 경우 VMware 지원 서비스에 문의하십시오.

전송 노드로의 관리 채널이 종료되었습니다.

이벤트가 감지된 경우: "전송 노드 {transport_node_name}({transport_node_address})에 대한 관리 채널이 5분 동안 종료되었습니다. "

이벤트가 해결된 경우: "전송 노드 {transport_node_name}({transport_node_address})에 대한 관리 채널이 실행 중입니다. "

관리자 노드와 전송 노드 {transport_node_name}({transport_node_address}) 간에 네트워크 연결이 있는지와 노드 간 트래픽을 차단하는 방화벽이 없는지 확인합니다. Windows 전송 노드의 Windows PowerShell에서 명령 C:\NSX\nsx-proxy\nsx-proxy.ps1 status를 호출하여 nsx-proxy 서비스가 전송 노드에서 실행되고 있는지 확인합니다. 실행 중이 아니면 C:\NSX\nsx-proxy\nsx-proxy.ps1 restart 명령을 호출하여 다시 시작합니다. 다른 모든 전송 노드에서 명령 /etc/init.d/nsx-proxy status를 호출하여 nsx-proxy 서비스가 전송 노드에서 실행되고 있는지 확인합니다. 실행 중이 아니면 /etc/init.d/nsx-proxy restart 명령을 호출하여 다시 시작합니다.

전송 노드로의 관리 채널이 너무 오랫동안 종료되었습니다.

이벤트가 감지된 경우: "전송 노드 {transport_node_name}({transport_node_address})에 대한 관리 채널이 15분 동안 종료되었습니다. "

이벤트가 해결된 경우: "전송 노드 {transport_node_name}({transport_node_address})에 대한 관리 채널이 실행 중입니다. "

관리자 노드와 전송 노드 {transport_node_name}({transport_node_address}) 간에 네트워크 연결이 있는지와 노드 간 트래픽을 차단하는 방화벽이 없는지 확인합니다. Windows 전송 노드의 Windows PowerShell에서 명령 C:\NSX\nsx-proxy\nsx-proxy.ps1 status를 호출하여 nsx-proxy 서비스가 전송 노드에서 실행되고 있는지 확인합니다. 실행 중이 아니면 C:\NSX\nsx-proxy\nsx-proxy.ps1 restart 명령을 호출하여 다시 시작합니다. 다른 모든 전송 노드에서 명령 /etc/init.d/nsx-proxy status를 호출하여 nsx-proxy 서비스가 전송 노드에서 실행되고 있는지 확인합니다. 실행 중이 아니면 /etc/init.d/nsx-proxy restart 명령을 호출하여 다시 시작합니다.

관리자 노드의 FQDN에 대한 DNS 조회가 실패했습니다.

이벤트가 감지된 경우: "FQDN이 {appliance_fqdn}인 관리자 노드 {entity_id}에 대한 DNS 조회가 실패했으며 publish_fqdns 플래그가 설정되었습니다. "

이벤트가 해결된 경우: "FQDN {appliance_fqdn}인 관리자 노드 {entity_id}에 대한 FQDN 조회가 성공했거나 publish_fqdns 플래그가 지워졌습니다. "

1. 모든 관리자 노드에 올바른 FQDN을 할당하고 DNS 구성이 모든 관리자 노드의 FQDN을 성공적으로 조회하기 위해 올바른지 확인합니다.
2. 또는 요청 본문에서 publish_fqdns가 false로 설정된 NSX API PUT /api/v1/configs/management를 호출하여 FQDN을 사용하지 않도록 설정합니다. 전송 노드 및 페더레이션에서 이 클러스터의 관리자 노드로의 호출 후에는 IP 주소만 사용합니다.

관리자 노드의 IP 주소에 대한 DNS 역방향 조회가 실패했습니다.

이벤트가 감지된 경우: "IP 주소가 {appliance_address}인 관리자 노드 {entity_id}에 대한 역방향 DNS 조회가 실패했으며 publish_fqdns 플래그가 설정되었습니다. "

이벤트가 해결된 경우: "IP 주소가 {appliance_address}인 관리자 노드 {entity_id}에 대한 역방향 DNS 조회가 성공했거나 publish_fqdns 플래그가 지워졌습니다. "

1. 모든 관리자 노드에 올바른 FQDN을 할당하고 DNS 구성이 관리자 노드의 IP 주소를 성공적으로 역방향으로 조회하기 위해 올바른지 확인합니다.
2. 또는 요청 본문에서 publish_fqdns가 false로 설정된 NSX API PUT /api/v1/configs/management를 호출하여 FQDN을 사용하지 않도록 설정합니다. 전송 노드 및 페더레이션에서 이 클러스터의 관리자 노드로의 호출 후에는 IP 주소만 사용합니다.

관리자 노드로의 관리 채널이 종료되었습니다.

이벤트가 감지된 경우: "관리자 노드 {manager_node_id}({appliance_address})로의 관리 채널이 5분 동안 종료되었습니다. "

이벤트가 해결된 경우: "관리자 노드 {manager_node_id}({appliance_address})에 대한 관리 채널이 실행 중입니다. "

전송 노드 {transport_node_id}과(와) 마스터 관리자 노드 간에 네트워크 연결이 있는지 확인합니다. 또한 노드 간의 트래픽을 차단하는 방화벽이 없는지 확인합니다. /etc/init.d/messaging-manager status 명령을 호출하여 메시징 관리자 서비스가 관리자 노드에서 실행되고 있는지 확인합니다. 메시징 관리자가 실행 중이 아니면 /etc/init.d/messaging-manager restart 명령을 호출하여 다시 시작합니다.

관리자 노드로의 관리 채널이 너무 오랫동안 종료되었습니다.

이벤트가 감지된 경우: "관리자 노드 {manager_node_id}({appliance_address})로의 관리 채널이 15분 동안 종료되었습니다. "

이벤트가 해결된 경우: "관리자 노드 {manager_node_id}({appliance_address})에 대한 관리 채널이 실행 중입니다. "

전송 노드 {transport_node_id}과(와) 마스터 관리자 노드 간에 네트워크 연결이 있는지 확인합니다. 또한 노드 간의 트래픽을 차단하는 방화벽이 없는지 확인합니다. /etc/init.d/messaging-manager status 명령을 호출하여 메시징 관리자 서비스가 관리자 노드에서 실행되고 있는지 확인합니다. 메시징 관리자가 실행 중이 아니면 /etc/init.d/messaging-manager restart 명령을 호출하여 다시 시작합니다.

관리-전송 노드로의 네트워크 지연 시간이 높습니다.

이벤트가 감지된 경우: "관리자 노드와 호스트 {transport_node_name}({transport_node_address}) 간의 평균 네트워크 지연 시간이 5분 동안 150밀리초 이상입니다. "

이벤트가 해결된 경우: "관리자 노드와 호스트 {transport_node_name}({transport_node_address}) 간의 평균 네트워크 지연 시간이 정상입니다. "

1. 5분 동안 기다려 경보가 자동으로 해결되는지 확인합니다.
2. 관리자 노드에서 NSX 전송 노드를 ping합니다. ping 테스트 결과로 삭제가 표시되지 않아야 하며 일관된 지연 시간 값이 표시되어야 합니다. 지연 시간이 150ms 이하로 유지되는 것이 좋습니다.
3. 다른 물리적 네트워크 계층 문제가 있는지 검사합니다. 문제가 지속되면 VMware 지원 서비스에 문의하십시오.

IP 풀의 IP 주소가 모두 사용되었습니다.

이벤트가 감지된 경우: "DHCP 서버 {dhcp_server_id}의 IP 풀 {entity_id}에 있는 주소가 모두 사용되었습니다. 마지막 DHCP 요청이 실패하고 향후 요청은 실패합니다. "

이벤트가 해결된 경우: "DHCP 서버 {dhcp_server_id}의 IP 풀 {entity_id}에 있는 주소가 더 이상 모두 사용되지 않습니다. 마지막 DHCP 요청에 리스가 할당되었습니다. "

NSX UI에서 또는 NSX CLI 명령 get dhcp ip-pool을 호출하여 DHCP 서버가 실행 중인 Edge 노드에서 DHCP 풀 구성을 검토합니다. 또한 NSX CLI 명령 get dhcp lease를 호출하여 Edge 노드의 현재 활성 리스를 검토합니다. 리스를 활성 VM 수와 비교합니다. VM의 수가 활성 리스 수와 비교하여 낮은 경우 DHCP 서버 구성의 리스 시간을 줄이는 것을 고려하십시오. 또한 NSX UI의 네트워킹 | 세그먼트 | 세그먼트 페이지로 이동하여 DHCP 서버의 풀 범위를 확장하는 것이 좋습니다.

IP 풀이 오버로드되었습니다.

이벤트가 감지된 경우: "DHCP 서버 {dhcp_server_id} IP 풀 {entity_id} 사용량이 곧 고갈될 예정이며 {dhcp_pool_usage}% IP가 할당되었습니다. "

이벤트가 해결된 경우: "DHCP 서버 {dhcp_server_id} IP 풀 {entity_id}이(가) 높은 사용량 임계값보다 작아졌습니다. "

NSX UI에서 또는 NSX CLI 명령 get dhcp ip-pool을 호출하여 DHCP 서버가 실행 중인 Edge 노드에서 DHCP 풀 구성을 검토합니다. 또한 NSX CLI 명령 get dhcp lease를 호출하여 Edge 노드의 현재 활성 리스를 검토합니다. 리스를 활성 VM 수와 비교합니다. VM의 수가 활성 리스 수와 비교하여 낮은 경우 DHCP 서버 구성의 리스 시간을 줄이는 것을 고려하십시오. 또한 NSX UI의 네트워킹 | 세그먼트 | 세그먼트 페이지로 이동하여 DHCP 서버의 풀 범위를 확장하는 것이 좋습니다.

DFW CPU 사용량이 매우 높습니다.

이벤트가 감지된 경우: "전송 노드 {entity_id}의 DFW CPU 사용량이 {system_resource_usage}%에 도달했으며, 이것은 매우 높은 임계값 {system_usage_threshold}% 이상입니다. "

이벤트가 해결된 경우: "전송 노드 {entity_id}의 DFW CPU 사용량이 {system_resource_usage}%에 도달했으며, 이것은 매우 높은 임계값 {system_usage_threshold}% 미만입니다. "

이 호스트의 VM 워크로드를 다른 호스트로 재조정하는 것이 좋습니다. 최적화를 위해 보안 설계를 검토하십시오. 예를 들어 전체 데이터 센터에 규칙이 적용되지 않는 경우 적용 대상 구성을 사용합니다.

DFW CPU 사용량이 DPU에서 너무 높습니다.

이벤트가 감지된 경우: "전송 노드 {entity_id}의 DFW CPU 사용량이 DPU {dpu_id}에서 {system_resource_usage}%에 도달했으며, 이것은 매우 높은 임계값 {system_usage_threshold}% 이상입니다. "

이벤트가 해결된 경우: "전송 노드 {entity_id}의 DFW CPU 사용량이 DPU {dpu_id}에서 {system_resource_usage}%에 도달했으며, 이것은 매우 높은 임계값 {system_usage_threshold}% 미만입니다. "

이 호스트의 VM 워크로드를 다른 호스트로 재조정하는 것이 좋습니다. 최적화를 위해 보안 설계를 검토하십시오. 예를 들어 전체 데이터 센터에 규칙이 적용되지 않는 경우 적용 대상 구성을 사용합니다.

DFW 메모리 사용량이 매우 높습니다.

이벤트가 감지된 경우: "전송 노드 {entity_id}의 DFW 메모리 사용량 {heap_type}이(가) {system_resource_usage}%에 도달했으며, 이것은 매우 높은 임계값 {system_usage_threshold}% 이상입니다. "

이벤트가 해결된 경우: "전송 노드 {entity_id}의 DFW 메모리 사용량 {heap_type}이(가) {system_resource_usage}%에 도달했으며, 이것은 매우 높은 임계값 {system_usage_threshold}% 미만입니다. "

호스트에서 NSX CLI 명령 get firewall thresholds를 호출하여 현재 DFW 메모리 사용량을 봅니다. 이 호스트의 워크로드를 다른 호스트로 재조정하는 것이 좋습니다.

DFW 메모리 사용량이 DPU에서 너무 높습니다.

이벤트가 감지된 경우: "전송 노드 {entity_id}의 DFW 메모리 사용량 {heap_type}이(가) DPU {dpu_id}에서 {system_resource_usage}%에 도달했으며, 이것은 매우 높은 임계값 {system_usage_threshold}% 이상입니다. "

이벤트가 해결된 경우: "전송 노드 {entity_id}의 DFW 메모리 사용량 {heap_type}이(가) DPU {dpu_id}에서 {system_resource_usage}%에 도달했으며, 이것은 매우 높은 임계값 {system_usage_threshold}% 미만입니다. "

DPU에서 NSX CLI 명령 get firewall thresholds를 호출하여 현재 DFW 메모리 사용량을 확인합니다. 이 호스트의 워크로드를 다른 호스트로 재조정하는 것이 좋습니다.

DFW vMotion에 실패했습니다. 포트 연결이 끊겼습니다.

이벤트가 감지된 경우: "대상 호스트 {transport_node_name}에 있는 DFW용 DFW vMotion 필터 {entity_id}이(가) 실패했으며 엔티티 포트의 연결이 끊겼습니다. "

이벤트가 해결된 경우: "대상 호스트 {transport_node_name}의 DFW 필터 {entity_id}에 대한 DFW 구성이 성공적으로 수행되었으며 DFW vMotion 실패로 인한 오류가 제거되었습니다. "

NSX Manager의 호스트에 있는 VM을 확인하고, NSX Manager UI를 통해 DFW 구성을 수동으로 다시 푸시합니다. 다시 푸시할 DFW 정책은 DFW 필터 {entity_id}(으)로 추적할 수 있습니다. 또한 DFW 필터가 연결된 VM을 찾아 다시 시작하는 것이 좋습니다.

DFW 플러드 제한이 주의 수준에 도달했습니다.

이벤트가 감지된 경우: "호스트 {transport_node_name}의 DFW 필터 {entity_id}에 대한 DFW 플러드 제한이 프로토콜 {protocol_name}에 대해 구성된 제한의 주의 수준인 80%에 도달했습니다. "

이벤트가 해결된 경우: "프로토콜 {protocol_name}에 대한 호스트 {transport_node_name}의 DFW 필터 {entity_id}에 대한 주의 플러드 제한 조건이 지워졌습니다. "

NSX Manager의 호스트에서 VM을 확인하고 프로토콜 {protocol_name}에 대해 DFW 필터 {entity_id}의 구성된 플러드 주의 수준을 확인합니다.

DFW 플러드 제한이 위험 수준에 도달했습니다.

이벤트가 감지된 경우: "호스트 {transport_node_name}의 DFW 필터 {entity_id}에 대한 DFW 플러드 제한이 프로토콜 {protocol_name}에 대해 구성된 제한의 위험 수준인 98%에 도달했습니다. "

이벤트가 해결된 경우: "프로토콜 {protocol_name}에 대한 호스트 {transport_node_name}의 DFW 필터 {entity_id}에 대한 위험 플러드 제한 조건이 지워졌습니다. "

NSX Manager의 호스트에서 VM을 확인하고 프로토콜 {protocol_name}에 대해 DFW 필터 {entity_id}의 구성된 플러드 위험 수준을 확인합니다.

DFW 세션 수가 높습니다.

이벤트가 감지된 경우: "DFW 세션 수가 전송 노드 {entity_id}에서 높으며 임계값 {system_usage_threshold}% 이상인 {system_resource_usage}%에 도달했습니다. "

이벤트가 해결된 경우: "전송 노드 {entity_id}의 DFW 세션 수가 {system_resource_usage}%에 도달했으며, 이것은 임계값 {system_usage_threshold}% 미만입니다. "

호스트에 있는 워크로드의 네트워크 트래픽 로드 수준을 검토합니다. 이 호스트의 워크로드를 다른 호스트로 재조정하는 것이 좋습니다.

vNIC당 DFW 규칙 제한이 최대 제한을 초과하려고 합니다.

이벤트가 감지된 경우: "대상 호스트 {transport_node_name}에 대한 VIF {entity_id}에 대한 DFW 규칙 제한이 최대 제한을 초과하려고 합니다. "

이벤트가 해결된 경우: "대상 호스트 {transport_node_name}의 VIF {entity_id}에 대한 DFW 규칙 제한이 최대 제한 미만으로 감소했습니다. "

ESX 호스트 {transport_node_name}에 로그인하고 NSX CLI 명령 get firewall &ltVIF_UUID&gt ruleset rules를 호출하여 해당 VIF에 구성된 규칙에 대한 규칙 통계를 가져옵니다. VIF {entity_id}에 대해 구성된 규칙 수를 줄입니다.

vNIC당 DFW 규칙 제한이 최대 제한에 도달하고 있습니다.

이벤트가 감지된 경우: "대상 호스트 {transport_node_name}에 대한 VIF {entity_id}에 대한 DFW 규칙 제한이 최대 제한에 가까워지고 있습니다. "

이벤트가 해결된 경우: "대상 호스트 {transport_node_name}의 VIF {entity_id}에 대한 DFW 규칙 제한이 임계값 미만으로 감소했습니다. "

ESX 호스트 {transport_node_name}에 로그인하고 NSX CLI 명령 get firewall &ltVIF_UUID&gt ruleset rules를 호출하여 해당 VIF에 구성된 규칙에 대한 규칙 통계를 가져옵니다. VIF {entity_id}에 대해 구성된 규칙 수를 줄입니다.

호스트당 DFW 규칙 제한이 최대 제한을 초과하려고 합니다.

이벤트가 감지된 경우: "호스트 {transport_node_name}에 대한 DFW 규칙 제한이 최대 제한을 초과하려고 합니다. "

이벤트가 해결된 경우: "호스트 {transport_node_name}에 대한 DFW 규칙 제한이 최대 제한 미만으로 감소했습니다. "

ESX 호스트 {transport_node_name}에 로그인하고 NSX CLI 명령get firewall rule-stats total을 호출하여 ESX 호스트 {transport_node_name}에 구성된 규칙에 대한 규칙 통계를 가져옵니다. 호스트 {transport_node_name}에 대해 구성된 규칙 수를 줄입니다. NSX CLI 명령 get firewall &ltVIF_UUID&gt ruleset rules를 사용하여 다양한 VIF에 대해 구성된 규칙 수를 확인합니다. 다양한 VIF에 대해 구성된 규칙 수를 줄입니다.

호스트당 DFW 규칙 제한이 최대 제한에 도달하고 있습니다.

이벤트가 감지된 경우: "호스트 {transport_node_name}에 대한 DFW 규칙 제한이 최대 제한에 가까워지고 있습니다. "

이벤트가 해결된 경우: "호스트 {transport_node_name}에 대한 DFW 규칙 제한이 임계값 미만으로 감소했습니다. "

ESX 호스트 {transport_node_name}에 로그인하고 NSX CLI 명령get firewall rule-stats total을 호출하여 ESX 호스트 {transport_node_name}에 구성된 규칙에 대한 규칙 통계를 가져옵니다. 호스트 {transport_node_name}에 대해 구성된 규칙 수를 줄입니다. NSX CLI 명령 get firewall &ltVIF_UUID&gt ruleset rules를 사용하여 다양한 VIF에 대해 구성된 규칙 수를 확인합니다. 다양한 VIF에 대해 구성된 규칙 수를 줄입니다.

최대 침입 이벤트 수에 도달했습니다.

이벤트가 감지된 경우: "시스템의 침입 이벤트 수가 최대 허용 값 {max_ids_events_allowed}보다 높은 {ids_events_count}입니다. "

이벤트가 해결된 경우: "시스템의 침입 이벤트 수가 최대 허용 값 {max_ids_events_allowed}보다 낮은 {ids_events_count}입니다. "

수동 작업은 필요하지 않습니다. 지우기 작업이 3분마다 자동으로 시작되고 이전 레코드의 10%를 삭제하여 시스템의 총 침입 이벤트 수를 임계값인 150만 개 미만으로 유지합니다.

NSX IDPS 엔진 메모리 사용량이 75% 이상에 도달했습니다.

이벤트가 감지된 경우: "NSX-IDPS 엔진 메모리 사용량이 높은 임계값 75% 이상인 {system_resource_usage}%에 도달했습니다. "

이벤트가 해결된 경우: "NSX-IDPS 엔진 메모리 사용량이 높은 임계값 75%보다 낮은 {system_resource_usage}%에 도달했습니다. "

이 호스트의 VM 워크로드를 다른 호스트로 재조정하는 것이 좋습니다.

DPU에서 NSX IDPS 엔진 메모리 사용량이 75% 이상에 도달했습니다.

이벤트가 감지된 경우: "NSX-IDPS 엔진 메모리 사용량이 DPU {dpu_id}에서 높은 임계값 75% 이상인 {system_resource_usage}%에 도달했습니다. "

이벤트가 해결된 경우: "DPU {dpu_id}의 NSX-IDPS 엔진 메모리 사용량이 높은 임계값 75%보다 낮은 {system_resource_usage}%에 도달했습니다. "

이 호스트의 VM 워크로드를 다른 호스트로 재조정하는 것이 좋습니다.

NSX IDPS 엔진 메모리 사용량이 85% 이상에 도달했습니다.

이벤트가 감지된 경우: "NSX-IDPS 엔진 메모리 사용량이 중간 임계값 85% 이상인 {system_resource_usage}%에 도달했습니다. "

이벤트가 해결된 경우: "NSX-IDPS 엔진 메모리 사용량이 중간 임계값 85%보다 낮은 {system_resource_usage}%에 도달했습니다. "

이 호스트의 VM 워크로드를 다른 호스트로 재조정하는 것이 좋습니다.

DPU에서 NSX IDPS 엔진 메모리 사용량이 85% 이상에 도달했습니다.

이벤트가 감지된 경우: "NSX-IDPS 엔진 메모리 사용량이 DPU {dpu_id}에서 중간 임계값 85% 이상인 {system_resource_usage}%에 도달했습니다. "

이벤트가 해결된 경우: "DPU {dpu_id}의 NSX-IDPS 엔진 메모리 사용량이 중간 임계값 85%보다 낮은 {system_resource_usage}%에 도달했습니다. "

이 호스트의 VM 워크로드를 다른 호스트로 재조정하는 것이 좋습니다.

NSX IDPS 엔진 메모리 사용량이 95% 이상에 도달했습니다.

이벤트가 감지된 경우: "NSX-IDPS 엔진 메모리 사용량이 매우 높은 임계값 95% 이상인 {system_resource_usage}%에 도달했습니다. "

이벤트가 해결된 경우: "NSX-IDPS 엔진 메모리 사용량이 매우 높은 임계값 95%보다 낮은 {system_resource_usage}%에 도달했습니다. "

이 호스트의 VM 워크로드를 다른 호스트로 재조정하는 것이 좋습니다.

DPU에서 NSX IDPS 엔진 메모리 사용량이 95% 이상에 도달했습니다.

이벤트가 감지된 경우: "NSX-IDPS 엔진 메모리 사용량이 DPU {dpu_id}에서 매우 높은 임계값 95% 이상인 {system_resource_usage}%에 도달했습니다. "

이벤트가 해결된 경우: "DPU {dpu_id}의 NSX-IDPS 엔진 메모리 사용량이 매우 높은 임계값 95%보다 낮은 {system_resource_usage}%에 도달했습니다. "

이 호스트의 VM 워크로드를 다른 호스트로 재조정하는 것이 좋습니다.

NSX IDPS 엔진 CPU 사용량이 75% 이상에 도달했습니다.

이벤트가 감지된 경우: "NSX-IDPS 엔진 CPU 사용량이 높은 임계값 75% 이상인 {system_resource_usage}%에 도달했습니다. "

이벤트가 해결된 경우: "NSX-IDPS 엔진 CPU 사용량이 높은 임계값 75%보다 낮은 {system_resource_usage}%에 도달했습니다. "

이 호스트의 VM 워크로드를 다른 호스트로 재조정하는 것이 좋습니다.

NSX IDPS 엔진 CPU 사용량이 85% 이상에 도달했습니다.

이벤트가 감지된 경우: "NSX-IDPS 엔진 CPU 사용량이 중간 임계값 85% 이상인 {system_resource_usage}%에 도달했습니다. "

이벤트가 해결된 경우: "NSX-IDPS 엔진 CPU 사용량이 중간 임계값 85%보다 낮은 {system_resource_usage}%에 도달했습니다. "

이 호스트의 VM 워크로드를 다른 호스트로 재조정하는 것이 좋습니다.

NSX IDPS 엔진 CPU 사용량이 95% 이상을 초과했습니다.

이벤트가 감지된 경우: "NSX-IDPS 엔진 CPU 사용량이 매우 높은 임계값 95% 이상인 {system_resource_usage}%에 도달했습니다. "

이벤트가 해결된 경우: "NSX-IDPS 엔진 CPU 사용량이 매우 높은 임계값 95%보다 낮은 {system_resource_usage}%에 도달했습니다. "

이 호스트의 VM 워크로드를 다른 호스트로 재조정하는 것이 좋습니다.

NSX IDPS는 NSX 정책을 통해 사용하도록 설정되고 IDPS 규칙이 구성되었지만 NSX IDPS 엔진이 종료되었습니다.

이벤트가 감지된 경우: "NSX IDPS는 NSX 정책을 통해 사용하도록 설정되고 IDPS 규칙이 구성되었지만 NSX IDPS 엔진이 종료되었습니다. "

이벤트가 해결된 경우: "NSX IDPS는 아래의 경우 중 하나입니다. 1. NSX IDPS는 NSX 정책을 통해 사용하지 않도록 설정됩니다. 2. NSX IDPS 엔진이 사용하도록 설정되고, NSX-IDPS 엔진 및 vdpi가 실행 중이고, NSX IDPS가 사용하도록 설정되었으며 IDPS 규칙이 NSX 정책을 통해 구성되었습니다. "

1. /var/log/nsx-syslog.log에 보고된 오류가 있는지 확인합니다.
2. NSX CLI 명령 get ids engine status를 호출하여 NSX 분산 IDPS가 사용 안 함 상태인지 확인합니다. 이 경우 /etc/init.d/nsx-idps start를 호출하여 서비스를 시작합니다.
3. /etc/init.d/nsx-vdpi status를 호출하여 nsx-vdpi가 실행 중인지 확인합니다. 그러지 않으면 /etc/init.d/nsx-vdpi start를 호출하여 서비스를 시작합니다.

NSX IDPS는 NSX 정책을 통해 사용하도록 설정되고 IDPS 규칙이 구성되었지만 DPU에서 NSX IDPS 엔진이 종료되었습니다.

이벤트가 감지된 경우: "NSX IDPS는 NSX 정책을 통해 사용하도록 설정되고 IDPS 규칙이 구성되었지만 DPU {dpu_id}에서 NSX IDPS 엔진이 종료되었습니다. "

이벤트가 해결된 경우: "NSX IDPS는 DPU {dpu_id}에서 아래의 경우 중 하나입니다. 1. NSX IDPS는 NSX 정책을 통해 사용하지 않도록 설정됩니다. 2. NSX IDPS 엔진이 사용하도록 설정되고, NSX-IDPS 엔진 및 vdpi가 실행 중이고, NSX IDPS가 사용하도록 설정되었으며 IDPS 규칙이 NSX 정책을 통해 구성되었습니다. "

1. /var/log/nsx-idps/nsx-idps.log 및 /var/log/nsx-syslog.log를 확인하여 보고된 오류가 있는지 알아봅니다.
2. NSX CLI 명령 get ids engine status를 호출하여 NSX 분산 IDPS가 사용 안 함 상태인지 확인합니다. 이 경우 /etc/init.d/nsx-idps start를 호출하여 서비스를 시작합니다.
3. /etc/init.d/nsx-vdpi status를 호출하여 nsx-vdpi가 실행 중인지 확인합니다. 그러지 않으면 /etc/init.d/nsx-vdpi start를 호출하여 서비스를 시작합니다.

분산 IDPS 엔진에 대한 CPU 활용률이 높습니다.

이벤트가 감지된 경우: "분산 IDPS 엔진에 대한 CPU 활용률이 높은 임계값 {system_usage_threshold}% 이상입니다. "

이벤트가 해결된 경우: "분산 IDPS 엔진에 대한 CPU 활용률이 높은 임계값 {system_usage_threshold}% 미만입니다. "

초과 구독 이유를 검토합니다. 특정 애플리케이션을 다른 호스트로 이동합니다.

분산 IDPS 엔진에 대한 CPU 활용률이 매우 높습니다.

이벤트가 감지된 경우: "분산 IDPS 엔진에 대한 CPU 활용률이 매우 높은 임계값 {system_usage_threshold}% 이상입니다. "

이벤트가 해결된 경우: "분산 IDPS 엔진에 대한 CPU 활용률이 매우 높은 임계값 {system_usage_threshold}% 미만입니다. "

초과 구독 이유를 검토합니다. 특정 애플리케이션을 다른 호스트로 이동합니다.

분산 IDPS 엔진에 대한 네트워크 활용률이 높습니다.

이벤트가 감지된 경우: "분산 IDPS 엔진에 대한 네트워크 활용률이 높은 임계값 {system_usage_threshold}% 이상입니다. "

이벤트가 해결된 경우: "분산 IDPS 엔진에 대한 네트워크 활용률이 높은 임계값 {system_usage_threshold}% 미만입니다. "

초과 구독 이유를 검토합니다. IDPS 규칙을 검토하여 IDPS 서비스에 따라 좌우되는 트래픽 양을 줄입니다.

분산 IDPS 엔진에 대한 네트워크 활용률이 매우 높습니다.

이벤트가 감지된 경우: "분산 IDPS 엔진에 대한 네트워크 활용률이 매우 높은 임계값 {system_usage_threshold}% 이상입니다. "

이벤트가 해결된 경우: "분산 IDPS 엔진에 대한 네트워크 활용률이 매우 높은 임계값 {system_usage_threshold}% 미만입니다. "

초과 구독 이유를 검토합니다. IDPS 규칙을 검토하여 IDPS 서비스에 따라 좌우되는 트래픽 양을 줄입니다.

CPU 초과 구독으로 인해 분산 IDPS 엔진이 트래픽을 삭제했습니다.

이벤트가 감지된 경우: "IDPS 엔진에 CPU 리소스가 부족하여 들어오는 트래픽을 처리할 수 없으므로 과도한 트래픽이 삭제됩니다. 자세한 내용을 보려면 ESX 호스트에 로그인하고 vsipioctl getdpiinfo -s 명령을 실행한 후 초과 구독 통계를 확인하십시오. "

이벤트가 해결된 경우: "분산 IDPS 엔진에는 적절한 CPU 리소스가 있으며 트래픽을 삭제하지 않습니다. "

초과 구독 이유를 검토합니다. 특정 애플리케이션을 다른 호스트로 이동합니다.

네트워크 초과 구독으로 인해 분산 IDPS 엔진이 트래픽을 삭제했습니다.

이벤트가 감지된 경우: "IDPS 엔진이 들어오는 트래픽을 처리할 수 없으므로 과도한 트래픽이 삭제됩니다. 자세한 내용을 보려면 ESX 호스트에 로그인하고 vsipioctl getdpiinfo -s 명령을 실행한 후 초과 구독 통계를 확인하십시오. "

이벤트가 해결된 경우: "분산 IDPS 엔진은 트래픽을 삭제하지 않습니다. "

초과 구독 이유를 검토합니다. IDPS 규칙을 검토하여 IDPS 서비스에 따라 좌우되는 트래픽 양을 줄입니다.

CPU 초과 구독으로 인해 분산 IDPS 엔진이 트래픽을 우회했습니다.

이벤트가 감지된 경우: "IDPS 엔진은 CPU 리소스가 부족하여 수신 트래픽 속도에 맞출 수 없으므로 과도한 트래픽이 우회됩니다. 자세한 내용을 보려면 ESX 호스트에 로그인하고 vsipioctl getdpiinfo -s 명령을 실행한 후 초과 구독 통계를 확인하십시오. "

이벤트가 해결된 경우: "분산 IDPS 엔진에는 적절한 CPU 리소스가 있으며 트래픽을 우회하지 않습니다. "

초과 구독 이유를 검토합니다. 특정 애플리케이션을 다른 호스트로 이동합니다.

네트워크 초과 구독으로 인해 분산 IDPS 엔진이 트래픽을 우회했습니다.

이벤트가 감지된 경우: "IDPS 엔진이 들어오는 트래픽을 처리할 수 없으므로 과도한 트래픽이 우회됩니다. 자세한 내용을 보려면 ESX 호스트에 로그인하고 vsipioctl getdpiinfo -s 명령을 실행한 후 초과 구독 통계를 확인하십시오. "

이벤트가 해결된 경우: "분산 IDPS 엔진은 트래픽을 우회하지 않습니다. "

초과 구독 이유를 검토합니다. IDPS 규칙을 검토하여 IDPS 서비스에 따라 좌우되는 트래픽 양을 줄입니다.

DNS 전달자가 종료되었습니다.

이벤트가 감지된 경우: "DNS 전달자 {entity_id}이(가) 실행되고 있지 않습니다. 이것은 현재 사용하도록 설정된 식별된 DNS 전달자에 영향을 미칩니다. "

이벤트가 해결된 경우: "DNS 전달자 {entity_id}이(가) 다시 실행되고 있습니다. "

1. NSX CLI 명령 get dns-forwarders status를 호출하여 DNS 전달자가 종료 상태인지 확인합니다.
2. /var/log/syslog에 보고된 오류가 있는지 확인합니다.
3. 지원 번들을 수집하고 NSX 지원 팀에 문의하십시오.

DNS 전달자를 사용하지 않도록 설정했습니다.

이벤트가 감지된 경우: "DNS 전달자 {entity_id}이(가) 사용되지 않도록 설정되었습니다. "

이벤트가 해결된 경우: "DNS 전달자 {entity_id}이(가) 사용되도록 설정되었습니다. "

1. NSX CLI 명령 get dns-forwarders status를 호출하여 DNS 전달자가 사용 안 함 상태인지 확인합니다.
2. NSX 정책 API 또는 관리자 API를 사용하여 DNS 전달자를 사용하도록 설정합니다.

하나의 DNS 전달자 업스트림 서버가 시간 초과되었습니다.

이벤트가 감지된 경우: "DNS 전달자 {intent_path}({dns_id})이(가) 업스트림 서버 {dns_upstream_ip}에서 적시에 응답을 수신하지 못했습니다. 시간 초과한 FQDN에 대한 계산 인스턴스 연결이 영향을 받을 수 있습니다. "

이벤트가 해결된 경우: "DNS 전달자 {intent_path}({dns_id}) 업스트림 서버 {dns_upstream_ip}이(가) 정상입니다. "

1. NSX API GET /api/v1/dns/forwarders/{dns_id}/nslookup? address=&ltaddress&gt&server_ip={dns_upstream_ip}&source_ip=&ltsource_ip&gt를 호출합니다. 이 API 요청은 DNS 전달자의 네트워크 네임스페이스에서 업스트림 서버에 대한 DNS 조회를 트리거합니다. &ltaddress&gt은(는) 업스트림 서버와 동일한 도메인에 있는 IP 주소 또는 FQDN입니다. &ltsource_ip&gt은(는) 업스트림 서버 영역의 IP 주소입니다. API가 연결 시간 초과 응답을 반환하는 경우 네트워크 오류 또는 업스트림 서버 문제가 있을 수 있습니다. DSN 조회가 업스트림 서버에 도달하지 않는 이유 또는 업스트림 서버가 응답을 반환하지 않는 이유를 확인하십시오. API 응답에 업스트림 서버가 응답하고 있다고 표시되면 2단계를 계속 진행합니다.
2. NSX API GET /api/v1/dns/forwarders/{dns_id}/nslookup? Address=&ltaddress&gt를 호출합니다. 이 API 요청은 DNS 전달자에 대한 DNS 조회를 트리거합니다. API가 유효한 응답을 반환하는 경우 업스트림 서버가 복구된 것일 수 있으며 이 경보는 몇 분 내에 해결되어야 합니다. API가 연결 시간 초과 응답을 반환하는 경우 3단계를 계속 진행합니다.
3. NSX CLI 명령 `get dns-forwarder {dns_id} live-debug server-ip {dns_upstream_ip}`를 호출합니다. 이 명령은 업스트림 서버에서 라이브 디버깅을 트리거하고 DNS 전달자가 응답받지 못하는 이유를 보여주는 세부 정보 및 통계를 기록합니다.

Edge 노드 설정이 일치하지 않습니다.

이벤트가 감지된 경우: "Edge 노드 {entity_id} 설정 구성이 정책 의도 구성과 일치하지 않습니다. UI 또는 API에서 사용자에게 표시되는 Edge 노드 구성이 인식된 구성과 다릅니다. NSX Manager 외부에서 사용자가 인식한 Edge 노드 변경 내용이 이 경보의 세부 정보에 표시되고 UI 또는 API의 모든 편집 내용이 인식된 구성을 덮어씁니다. Edge 노드와 다른 필드가 런타임 데이터에 나열됩니다. {edge_node_setting_mismatch_reason} "

이벤트가 해결된 경우: "Edge 노드 {entity_id} 노드 설정이 이제 정책 의도와 일치합니다. "

이 Edge 전송 노드 {entity_id}의 노드 설정을 검토합니다. 경보를 해결하려면 다음 작업 중 하나를 수행하십시오.
1. API - PUT https://&ltmanager-ip&gt/api/v1/transport-nodes/&lttn-id&gt를 사용하여 Edge 전송 노드 설정 정책 의도를 수동으로 업데이트합니다.
2. Edge 전송 노드 확인 관리자를 통해 이 Edge 전송 노드에 대한 의도 또는 인식된 Edge 노드 설정을 수락하여 이 경보를 해결합니다.
3. refresh API - POST https://&ltmanager-ip&gt/api/v1/transport-nodes/&lttn-id&gt?action=refresh_node_configuration&resource_type=EdgeNode를 사용하여 Edge 노드 설정 구성을 수락하는 방식으로 경보를 해결합니다.

Edge VM vSphere 설정이 일치하지 않습니다.

이벤트가 감지된 경우: "vSphere의 Edge 노드 {entity_id} 구성이 정책 의도 구성과 일치하지 않습니다. UI 또는 API에서 사용자에게 표시되는 Edge 노드 구성이 인식된 구성과 다릅니다. NSX Manager 외부에서 사용자가 인식한 Edge 노드 변경 내용이 이 경보의 세부 정보에 표시되고 UI 또는 API의 모든 편집 내용이 인식된 구성을 덮어씁니다. Edge 노드와 다른 필드가 런타임 데이터에 나열됩니다. {edge_vm_vsphere_settings_mismatch_reason} "

이벤트가 해결된 경우: "Edge 노드 {entity_id} VM vSphere 설정이 이제 정책 의도와 일치합니다. "

이 Edge 전송 노드 {entity_id}의 vSphere 구성을 검토합니다. 경보를 해결하려면 다음 작업 중 하나를 수행하십시오.
1. Edge 전송 노드 확인 관리자를 통해 이 Edge 전송 노드에 대한 의도 또는 vSphere 인식 Edge 노드 구성을 수락하여 이 경보를 해결합니다.
2. refresh API - POST https://&ltmanager-ip&gt/api/v1/transport-nodes/&lttn-id&gt?action=refresh_node_configuration&resource_type=EdgeNode를 사용하여 Edge 노드 vSphere 인식 구성을 수락하는 방식으로 경보를 해결합니다.

Edge 노드 설정 및 vSphere 설정이 변경됩니다.

이벤트가 감지된 경우: "Edge 노드 {entity_id} 설정 및 vSphere 구성이 변경되었으며 정책 의도 구성과 일치하지 않습니다. UI 또는 API에서 사용자에게 표시되는 Edge 노드 구성이 인식된 구성과 다릅니다. NSX Manager 외부에서 사용자가 인식한 Edge 노드 변경 내용이 이 경보의 세부 정보에 표시되고 UI 또는 API의 모든 편집 내용이 인식된 구성을 덮어씁니다. Edge 노드 설정 및 vSphere 구성과 다른 필드가 런타임 데이터에 나열됩니다. {edge_node_settings_and_vsphere_settings_mismatch_reason} "

이벤트가 해결된 경우: "Edge 노드 {entity_id} 노드 설정 및 vSphere 설정이 이제 정책 의도와 일치합니다. "

이 Edge 전송 노드 {entity_id}의 노드 설정 및 vSphere 구성을 검토합니다. 경보를 해결하려면 다음 작업 중 하나를 수행하십시오.
1. 다음 API를 사용하여 Edge 전송 노드 설정 정책 의도를 수동으로 업데이트합니다. PUT https://&ltmanager-ip&gt/api/v1/transport-nodes/&lttn-id&gt.
2. Edge 전송 노드 확인 관리자를 통해 이 Edge 전송 노드에 대한 의도 또는 vSphere 인식 Edge 노드 구성이나 인식된 Edge 노드 설정을 수락하여 이 경보를 해결합니다.
3. refresh API - POST https://&ltmanager-ip&gt/api/v1/transport-nodes/&lttn-id&gt?action=refresh_node_configuration&resource_type=EdgeNode를 사용하여 Edge 노드 설정 및 vSphere 인식 구성을 수락하는 방식으로 경보를 해결합니다.

Edge vSphere 위치가 일치하지 않음

이벤트가 감지된 경우: "vMotion을 사용하여 Edge 노드 {entity_id}을(를) 이동했습니다. vSphere의 Edge 노드 {entity_id} 구성이 정책 의도 구성과 일치하지 않습니다. UI 또는 API에서 사용자에게 표시되는 Edge 노드 구성이 인식된 구성과 다릅니다. NSX Manager 외부에서 사용자가 인식한 Edge 노드 변경 내용이 이 경보의 세부 정보에 표시됩니다. Edge 노드와 다른 필드가 런타임 데이터에 나열됩니다. {edge_vsphere_location_mismatch_reason} "

이벤트가 해결된 경우: "Edge 노드 {entity_id} 노드 vSphere 설정이 이제 정책 의도와 일치합니다. "

이 Edge 전송 노드 {entity_id}의 vSphere 구성을 검토합니다. 경보를 해결하려면 다음 작업 중 하나를 수행하십시오.
1. refresh API - POST https://&ltmanager-ip&gt/api/v1/transport-nodes/&lttn-id&gt?action=refresh_node_configuration&resource_type=EdgeNode를 사용하여 Edge 노드 vSphere 인식 구성을 수락하는 방식으로 경보를 해결합니다.
2. 이전 위치로 돌아가려면 NSX Redeploy API - POST https://&ltmanager-ip&gt/api/v1/transport-nodes/&lttn-id&gt?action=redeploy를 사용하십시오. 원래 호스트로의 vMotion은 지원되지 않습니다.

자동 Edge VM이 NSX 인벤토리에 있지만 vCenter에는 없습니다.

이벤트가 감지된 경우: "Edge 전송 노드 {entity_id} vSphere 배치 매개 변수에 해당하는 moref id {vm_moref_id}의 VM {policy_edge_vm_name}이(가) NSX 인벤토리에 있지만 vCenter에는 없습니다. VM이 vCenter에서 제거되었는지 또는 다른 VM moref id의 VM이 있는지 확인하십시오. "

이벤트가 해결된 경우: "VM MoRef ID가 {vm_moref_id}인 Edge 노드 {entity_id}이(가) NSX 인벤토리와 vCenter 둘 다에 있습니다. "

VM의 관리 개체 참조 moref id는 vm-number 형식으로, vCenter UI에서 Edge VM을 선택할 때 URL에 표시됩니다. 예: vm-12011 in https://&ltvc-url>/ui/app/vm;nav=h/urn:vmomi:VirtualMachine:vm-12011:164ff798-c4f1-495b-a0be-adfba337e5d2/summary 이 Edge 전송 노드 {entity_id}에 대한 vCenter에서 moref ID가 {vm_moref_id}인 VM {policy_edge_vm_name}을(를) 찾으십시오. vCenter에 다른 moref id의 Edge VM이 있는 경우 아래 작업을 수행하십시오. NSX에서 JSON 요청 페이로드 속성 vm_id 및 vm_deployment_config로 배치 API를 추가하거나 업데이트하여 새 vm moref id 및 vSphere 배포 매개 변수를 업데이트합니다. POST https://&ltmanager-ip&gt/api/v1/transport-nodes/&lttn-id&gt?action=addOrUpdatePlacementReferences. 이름이 {policy_edge_vm_name}인 Edge VM이 vCenter에 없으면 NSX 다시 배포 API를 사용하여 Edge 노드에 대한 새 VM을 배포합니다. POST https://&ltmanager-ip&gt/api/v1/transport-nodes/&lttn-id&gt?action=redeploy.

자동 Edge VM이 NSX 인벤토리와 vCenter 둘 다에 없습니다.

이벤트가 감지된 경우: "Edge 전송 노드 {entity_id} vSphere 배치 매개 변수에 해당하는 moref id {vm_moref_id}의 VM {policy_edge_vm_name}을(를) NSX 인벤토리 및 vCenter 둘 다에서 찾을 수 없습니다. 이 Edge 전송 노드 {entity_id}의 vSphere 구성에 있는 배치 매개 변수는 moref {vm_moref_id}인 VM을 참조합니다. "

이벤트가 해결된 경우: "VM MoRef ID가 {vm_moref_id}인 Edge 노드 {entity_id}이(가) NSX 인벤토리와 vCenter 둘 다에 있습니다. "

VM의 관리 개체 참조 moref id는 vm-number 형식으로, vCenter UI에서 Edge VM을 선택할 때 URL에 표시됩니다. 예: vm-12011 in https://&ltvc-url>/ui/app/vm;nav=h/urn:vmomi:VirtualMachine:vm-12011:164ff798-c4f1-495b-a0be-adfba337e5d2/summary 이 Edge 전송 노드 {entity_id}에 대한 vCenter에서 moref ID가 {vm_moref_id}인 VM {policy_edge_vm_name}을(를) 찾으십시오. 경보를 해결하려면 아래 작업을 수행하십시오. - vSphere VM이 삭제되었는지 또는 다른 MoRef ID가 있는지 확인하십시오.
1. VM이 여전히 vCenter에 있는 경우 Edge 전송 노드를 유지 보수 모드로 전환한 다음, vCenter에서 Edge VM의 전원을 끄고 삭제합니다. NSX 다시 배포 API를 사용하여 Edge 노드에 대한 새 VM을 배포합니다. Edge VM이 트래픽을 전달하는 경우 중간 기간 동안 Edge 전송 노드에 대한 데이터 트래픽이 차단됩니다.
2. VM이 vCenter에 없으면 다시 배포 API를 사용하여 Edge 노드에 대해 새 VM을 배포합니다. POST https://&ltmanager-ip&gt/api/v1/transport-nodes/&lttn-id&gt?action=redeploy.

다시 배포하는 동안 vCenter의 이전 Edge VM에 대한 전원 끄기 및 삭제 작업이 실패했습니다.

이벤트가 감지된 경우: "다시 배포 작업 동안 vCenter에서 moref ID가 {vm_moref_id}인 Edge 노드 {entity_id} VM의 전원을 끄고 삭제하지 못했습니다. Moref id가 {new_vm_moref_id}인 새 Edge VM이 배포되었습니다. 이 Edge에 대한 이전 VM과 새 VM은 동시에 작동하며 IP 충돌 및 네트워킹 문제가 발생할 수 있습니다. "

이벤트가 해결된 경우: 오래된 VM moref id가 {vm_moref_id}인 Edge 노드 {entity_id}을(를) NSX 인벤토리 및 vCenter 둘 다에서 더 이상 찾을 수 없습니다. moref id가 {new_vm_moref_id}인 배포된 새 VM이 NSX 인벤토리와 vCenter 둘 다에 있습니다. "

VM의 관리 개체 참조 moref id는 vm-number 형식으로, vCenter UI에서 Edge VM을 선택할 때 URL에 표시됩니다. 예: vm-12011 in https://&ltvc-url>/ui/app/vm;nav=h/urn:vmomi:VirtualMachine:vm-12011:164ff798-c4f1-495b-a0be-adfba337e5d2/summary 이 Edge 전송 노드 {entity_id}에 대한 vCenter에서 moref ID가 {vm_moref_id}인 VM {policy_edge_vm_name}을(를) 찾으십시오. vCenter에서 moref id가 {vm_moref_id}인 이전 Edge VM {policy_edge_vm_name}의 전원을 끄고 삭제하십시오.

Edge 노드에 하드웨어 버전 불일치가 있습니다.

이벤트가 감지된 경우: "Edge 클러스터 {edge_cluster_name}의 Edge 노드 {transport_node_name}에 하드웨어 버전 {edge_tn_hw_version}이(가) 있으며 이 버전은 Edge 클러스터에서 가장 높은 하드웨어 버전 {edge_cluster_highest_hw_version}보다 낮습니다. "

이벤트가 해결된 경우: "이제 Edge 노드 {transport_node_name} 하드웨어 버전 불일치가 해결되었습니다. "

KB 문서에 따라 Edge 노드 {transport_node_name}에 대한 하드웨어 버전 불일치 경보를 해결하십시오.

Edge 클러스터 멤버 재배치 실패 경보

이벤트가 감지된 경우: "전송 노드 ID가 {transport_node_id}인 Edge 클러스터 멤버 인덱스 {member_index_id}에 대해 모든 서비스 컨텍스트를 재배치하기 위한 Edge 클러스터 {edge_cluster_id} 작업이 실패했습니다."

이벤트가 해결된 경우: "이제 {transport_node_id} 재배치 실패가 있는 Edge 노드가 해결되었습니다. "

Edge 클러스터에 사용할 수 있는 용량을 검토하십시오. 더 많은 용량이 필요한 경우 Edge 클러스터 크기를 조정합니다. Edge 클러스터 멤버 재배치 작업을 다시 시도하십시오.

Edge 노드 CPU 사용량이 매우 높습니다.

이벤트가 감지된 경우: "Edge 노드 {entity_id}의 CPU 사용량이 {system_resource_usage}%에 도달했으며, 이것은 매우 높은 임계값 {system_usage_threshold}% 이상입니다. "

이벤트가 해결된 경우: "Edge 노드 {entity_id}의 CPU 사용량이 {system_resource_usage}%에 도달했으며, 이것은 매우 높은 임계값 {system_usage_threshold}% 미만입니다. "

이 Edge 노드의 구성, 실행 중인 서비스 및 크기 조정을 검토하십시오. 해당 워크로드에 맞게 Edge 장치 폼 팩터 크기를 조정하거나 다른 Edge 노드로 서비스를 재조정하는 것이 좋습니다.

Edge 노드 CPU 사용량이 높습니다.

이벤트가 감지된 경우: "Edge 노드 {entity_id}의 CPU 사용량이 {system_resource_usage}%에 도달했으며, 이것은 높은 임계값 {system_usage_threshold}% 이상입니다. "

이벤트가 해결된 경우: "Edge 노드 {entity_id}의 CPU 사용량이 {system_resource_usage}%에 도달했으며, 이것은 높은 임계값 {system_usage_threshold}% 미만입니다. "

이 Edge 노드의 구성, 실행 중인 서비스 및 크기 조정을 검토하십시오. 해당 워크로드에 맞게 Edge 장치 폼 팩터 크기를 조정하거나 다른 Edge 노드로 서비스를 재조정하는 것이 좋습니다.

Edge 노드 메모리 사용량이 매우 높습니다.

이벤트가 감지된 경우: "Edge 노드 {entity_id}의 메모리 사용량이 {system_resource_usage}%에 도달했으며, 이것은 매우 높은 임계값 {system_usage_threshold}% 이상입니다. "

이벤트가 해결된 경우: "Edge 노드 {entity_id}의 메모리 사용량이 {system_resource_usage}%에 도달했으며, 이것은 매우 높은 임계값 {system_usage_threshold}% 미만입니다. "

이 Edge 노드의 구성, 실행 중인 서비스 및 크기 조정을 검토하십시오. 해당 워크로드에 맞게 Edge 장치 폼 팩터 크기를 조정하거나 다른 Edge 노드로 서비스를 재조정하는 것이 좋습니다.

Edge 노드 메모리 사용량이 높습니다.

이벤트가 감지된 경우: "Edge 노드 {entity_id}의 메모리 사용량이 {system_resource_usage}%에 도달했으며, 이것은 높은 임계값 {system_usage_threshold}% 이상입니다. "

이벤트가 해결된 경우: "Edge 노드 {entity_id}의 메모리 사용량이 {system_resource_usage}%에 도달했으며, 이것은 높은 임계값 {system_usage_threshold}% 미만입니다. "

이 Edge 노드의 구성, 실행 중인 서비스 및 크기 조정을 검토하십시오. 해당 워크로드에 맞게 Edge 장치 폼 팩터 크기를 조정하거나 다른 Edge 노드로 서비스를 재조정하는 것이 좋습니다.

Edge 노드 디스크 사용량이 매우 높습니다.

이벤트가 감지된 경우: "Edge 노드의 디스크 파티션 {disk_partition_name}의 디스크 사용량이 {system_resource_usage}%에 도달했으며, 이것은 매우 높은 임계값 {system_usage_threshold}% 이상입니다. "

이벤트가 해결된 경우: "Edge 노드의 디스크 파티션 {disk_partition_name}의 디스크 사용량이 {system_resource_usage}%에 도달했으며, 이것은 매우 높은 임계값 {system_usage_threshold}% 미만입니다. "

사용량이 많은 파티션을 검사하고 제거할 수 있는 예기치 않은 큰 파일이 있는지 확인합니다.

Edge 노드 디스크 사용량이 높습니다.

이벤트가 감지된 경우: "Edge 노드의 디스크 파티션 {disk_partition_name}의 디스크 사용량이 {system_resource_usage}%에 도달했으며, 이것은 높은 임계값 {system_usage_threshold}% 이상입니다. "

이벤트가 해결된 경우: "Edge 노드의 디스크 파티션 {disk_partition_name}의 디스크 사용량이 {system_resource_usage}%에 도달했으며, 이것은 높은 임계값 {system_usage_threshold}% 미만입니다. "

사용량이 많은 파티션을 검사하고 제거할 수 있는 예기치 않은 큰 파일이 있는지 확인합니다.

Edge 노드 데이터 경로 CPU 사용량이 매우 높습니다.

이벤트가 감지된 경우: "Edge 노드 {entity_id}의 데이터 경로 CPU 사용량이 최소 2분 동안 매우 높은 임계값 이상인 {datapath_resource_usage}%에 도달했습니다. "

이벤트가 해결된 경우: "Edge 노드 {entity_id}의 CPU 사용량이 매우 높은 임계값보다 낮아졌습니다. "

NSX CLI 명령 get dataplane cpu stats를 호출하고 Edge 노드의 CPU 통계를 검토하여 CPU 코어당 패킷 속도를 표시합니다. 더 높은 패킷 속도에는 더 높은 CPU 사용량이 예상됩니다. Edge 장치 폼 팩터 크기를 늘리고 이 Edge 노드의 서비스를 동일한 클러스터 또는 다른 Edge 클러스터의 다른 Edge 노드로 재조정하는 것이 좋습니다.

Edge 노드 데이터 경로 CPU 사용량이 높습니다.

이벤트가 감지된 경우: "Edge 노드 {entity_id}의 데이터 경로 CPU 사용량이 최소 2분 동안 높은 임계값 이상인 {datapath_resource_usage}%에 도달했습니다. "

이벤트가 해결된 경우: "Edge 노드 {entity_id}의 CPU 사용량이 높은 임계값보다 낮아졌습니다. "

NSX CLI 명령 get dataplane cpu stats를 호출하고 Edge 노드의 CPU 통계를 검토하여 CPU 코어당 패킷 속도를 표시합니다. 더 높은 패킷 속도에는 더 높은 CPU 사용량이 예상됩니다. Edge 장치 폼 팩터 크기를 늘리고 이 Edge 노드의 서비스를 동일한 클러스터 또는 다른 Edge 클러스터의 다른 Edge 노드로 재조정하는 것이 좋습니다.

Edge 노드 데이터 경로 구성에 실패했습니다.

이벤트가 감지된 경우: "3번의 시도 후에도 Edge 노드에서 데이터 경로를 사용하도록 설정하지 못했습니다. "

이벤트가 해결된 경우: "Edge 노드의 데이터 경로를 사용하도록 설정했습니다. "

관리자 노드에 대한 Edge 노드 연결이 정상인지 확인합니다. Edge 노드 NSX CLI에서 get services 명령을 호출하여 서비스 상태를 확인합니다. 데이터부 서비스가 중지된 경우 start service dataplane 명령을 호출하여 다시 시작합니다.

Edge 암호화 드라이버가 종료되었습니다.

이벤트가 감지된 경우: Edge 노드 암호화 드라이버 {edge_crypto_drv_name}이(가) 종료되었습니다. "

이벤트가 해결된 경우: "Edge 노드 암호화 드라이버 {edge_crypto_drv_name}이(가) 실행 중입니다. "

필요에 따라 Edge 노드를 업그레이드합니다.

Edge 노드 데이터 경로 mempool이 높습니다.

이벤트가 감지된 경우: "Edge 노드 {entity_id}의 {mempool_name}에 대한 데이터 경로 mempool 사용량이 {system_resource_usage}%에 도달했으며, 이것은 높은 임계값 {system_usage_threshold}% 이상입니다. "

이벤트가 해결된 경우: "Edge 노드 {entity_id}의 {mempool_name}에 대한 데이터 경로 mempool 사용량이 {system_resource_usage}%에 도달했으며, 이것은 높은 임계값 {system_usage_threshold}% 미만입니다. "

루트 사용자로 로그인하고 edge-appctl -t /var/run/vmware/edge/dpd.ctl mempool/show 및 edge-appctl -t /var/run/vmware/edge/dpd.ctl memory/show malloc_heap 명령을 호출하여 DPDK 메모리 사용량을 확인합니다.

Edge 노드 글로벌 ARP 테이블 사용량이 높습니다.

이벤트가 감지된 경우: "Edge 노드 {entity_id}의 글로벌 ARP 테이블 사용량이 2분 넘게 높은 임계값을 초과하는 {datapath_resource_usage}%에 도달했습니다. "

이벤트가 해결된 경우: "Edge 노드 {entity_id}의 글로벌 ARP 테이블 사용량이 높은 임계값보다 낮아졌습니다. "

루트 사용자로 로그인하고 명령 edge-appctl -t /var/run/vmware/edge/dpd.ctl neigh/show를 호출한 후 neigh 캐시 사용량이 정상적인지 확인합니다. 정상적이면 edge-appctl -t /var/run/vmware/edge/dpd.ctl neigh/set_param max_entries 명령을 호출하여 ARP 테이블 크기를 늘리십시오.

Edge 노드 NIC가 일시적으로 RX 링 버퍼를 벗어납니다.

이벤트가 감지된 경우: "Edge NIC {edge_nic_name} 수신 링 버퍼가 Edge 노드 {entity_id}에서 {rx_ring_buffer_overflow_percentage}%만큼 오버플로되었습니다. 누락된 패킷 수는 {rx_misses}이고 처리된 패킷 수는 {rx_processed}입니다. "

이벤트가 해결된 경우: "Edge 노드 {entity_id}의 Edge NIC {edge_nic_name} 수신 링 버퍼 사용량이 더 이상 오버플로되지 않습니다. "

Edge 노드에서 NSX CLI 명령 get dataplane cpu stats를 실행하고 다음을 확인합니다.
1. CPU 사용량이 높은 경우(예: > 90%) `start capture interface &ltinterface-name&gt direction input 또는 start capture interface &ltinterface-name&gt direction input core &ltcore-id&gt` 명령을 사용하여 인터페이스에서 패킷 캡처를 수행합니다(사용량이 높은 특정 코어에서 수신하는 패킷 캡처). 그런 다음, 캡처를 분석하여 대부분의 조각화된 패킷 또는 ipsec 패킷이 있는지 확인합니다. 이러한 패킷이 있다면 이것은 예상되는 동작입니다. 그렇지 않은 경우 데이터 경로가 다른 작업에 사용 중일 수 있습니다. 이 경보가 2-3분 넘게 지속되면 VMware 지원 서비스에 문의하십시오.
2. CPU 사용량이 크지 않은 경우(90% 미만인 경우) get dataplane cpu stats 명령을 사용하여 rx pps가 높은지 확인합니다(트래픽 속도가 증가하는지 확인하려는 경우). 그런 다음, set dataplane ring-size rx 명령을 사용하여 링 크기를 1024로 늘립니다 . 참고 - 링 크기가 1024배까지 지속적으로 증가하면 약간의 성능 문제가 발생할 수 있습니다. 링 크기를 늘인 후에도 문제가 지속되면 Edge가 트래픽을 수용하기 위해 더 큰 폼 팩터 배포가 필요하다는 것을 나타냅니다.
3. 경보가 플래핑을 계속하는 경우, 즉 트리거되었다가 바로 해결되면 버스티 트래픽으로 인한 것입니다. 이 경우 위에 설명된 대로 rx pps가 경보 활성 기간 동안 이 수치가 높지 않은 경우 VMware 지원 서비스에 문의하십시오. pps가 높으면 버스티 트래픽을 확인합니다. 경보를 표시하지 않는 것이 좋습니다. 참고 - 높은 pps 값으로 간주되는 상황을 결정하는 구체적인 벤치마크는 없습니다. 인프라 및 트래픽 유형에 따라 다릅니다. 경보가 비활성 상태일 때와 활성 상태일 때를 확인하여 이러한 유형 간을 비교할 수 있습니다.

Edge 노드 NIC가 일시적으로 TX 링 버퍼를 벗어납니다.

이벤트가 감지된 경우: "Edge NIC {edge_nic_name} 전송 링 버퍼가 Edge 노드 {entity_id}에서 {tx_ring_buffer_overflow_percentage}%만큼 오버플로되었습니다. 누락된 패킷 수는 {tx_misses}이고 처리된 패킷 수는 {tx_processed}입니다. "

이벤트가 해결된 경우: "Edge 노드 {entity_id}의 Edge NIC {edge_nic_name} 전송 링 버퍼 사용량이 더 이상 오버플로되지 않습니다. "

1. 하이퍼바이저가 Edge와 함께 많은 VM을 수용하는 경우 Edge VM이 실행될 시간이 없으므로 하이퍼바이저에서 패킷이 검색되지 않을 수 있습니다. 그 후에는 Edge VM을 VM이 거의 없는 호스트로 마이그레이션할 수 있습니다.
2. 'set dataplane ring-size tx ` 명령을 사용하여 링 크기를 1024로 늘립니다. 링 크기를 늘인 후에도 문제가 지속되면 ESX 측 전송 링 버퍼의 값이 더 낮을 수 있으므로 VMware 지원 서비스에 문의하십시오. ESX 측에 문제가 없는 경우 트래픽을 수용하기 위해 Edge를 더 큰 폼 팩터 배포로 확장해야 함을 나타냅니다.
3. 경보가 플래핑을 계속하는 경우, 즉 트리거되었다가 바로 해결되면 버스티 트래픽으로 인한 것입니다. 이 경우 get dataplane cpu stats 명령을 사용하여 tx pps를 확인합니다. 경보 활성 기간 동안 이 수치가 높지 않은 경우 VMware 지원 서비스에 문의하십시오. pps가 높으면 버스티 트래픽을 확인합니다. 경보를 표시하지 않는 것이 좋습니다. 참고 - 높은 pps 값으로 간주되는 상황을 결정하는 구체적인 벤치마크는 없습니다. 인프라 및 트래픽 유형에 따라 다릅니다. 경보가 비활성 상태일 때와 활성 상태일 때를 확인하여 이러한 유형 간을 비교할 수 있습니다.

Edge 노드 NIC 링크가 종료되었습니다.

이벤트가 감지된 경우: "Edge 노드 NIC {edge_nic_name} 링크가 종료되었습니다. "

이벤트가 해결된 경우: "Edge 노드 NIC {edge_nic_name} 링크가 실행 중입니다. "

Edge 노드에서 NSX CLI 명령 get interfaces를 호출하여 NIC 링크가 물리적으로 종료되었는지 확인합니다. 종료된 경우 케이블 연결을 확인합니다.

Edge 노드 디스크가 읽기 전용입니다.

이벤트가 감지된 경우: "Edge 노드의 다음 디스크 파티션이 읽기 전용 모드입니다. {disk_partition_name} "

이벤트가 해결된 경우: "Edge 노드의 다음 디스크 파티션이 읽기 전용 모드에서 복구되었습니다. {disk_partition_name} "

읽기 전용 파티션을 검토하여 재부팅으로 문제가 해결되었는지 또는 디스크를 교체해야 하는지 확인합니다. 자세한 내용은 GSS에 문의하십시오.

Edge 노드의 데이터 경로 스레드가 교착 상태에 있습니다.

이벤트가 감지된 경우: Edge 노드 데이터 경로 스레드 {edge_thread_name}이(가) 교착 상태입니다. "

이벤트가 해결된 경우: "Edge 노드 데이터 경로 스레드 {edge_thread_name}이(가) 교착 상태에서 해제되었습니다. "

NSX CLI 명령 restart service dataplane을 호출하여 데이터부 서비스를 다시 시작합니다.

Edge 노드 데이터 경로 NIC 처리량이 매우 높습니다.

이벤트가 감지된 경우: "Edge 노드 {entity_id}의 {edge_nic_name}에 대한 데이터 경로 NIC 처리량이 {nic_throughput}%에 도달했습니다. 이 값은 매우 높은 임계값 {nic_throughput_threshold}% 이상입니다. "

이벤트가 해결된 경우: "Edge 노드 {entity_id}의 {edge_nic_name}에 대한 데이터 경로 NIC 처리량이 {nic_throughput}%에 도달했습니다. 이 값은 매우 높은 임계값 {nic_throughput_threshold}% 미만입니다. "

NIC의 트래픽 처리량 수준을 검토하고 구성 변경이 필요한지 확인합니다. 'get dataplane thoughput &ltseconds&gt’ 명령을 사용하여 처리량을 모니터링할 수 있습니다.

Edge 노드 데이터 경로 NIC 처리량이 높습니다.

이벤트가 감지된 경우: "Edge 노드 {entity_id}의 {edge_nic_name}에 대한 데이터 경로 NIC 처리량이 {nic_throughput}%에 도달했습니다. 이 값은 높은 임계값 {nic_throughput_threshold}% 이상입니다. "

이벤트가 해결된 경우: "Edge 노드 {entity_id}의 {edge_nic_name}에 대한 데이터 경로 NIC 처리량이 {nic_throughput}%에 도달했습니다. 이 값은 높은 임계값 {nic_throughput_threshold}% 미만입니다. "

NIC의 트래픽 처리량 수준을 검토하고 구성 변경이 필요한지 확인합니다. 'get dataplane thoughput &ltseconds&gt’ 명령을 사용하여 처리량을 모니터링할 수 있습니다.

장애 도메인의 모든 멤버가 종료되었습니다.

이벤트가 감지된 경우: 장애 도메인 {transport_node_id}의 모든 멤버가 종료되었습니다. "

이벤트가 해결된 경우: "장애 도메인 {transport_node_id}의 모든 멤버에 연결할 수 있습니다. "

1. {transport_node_id}(으)로 식별된 Edge 노드에서 NSX CLI 명령 get managers 및 get controllers를 호출하여 관리부 및 제어부에 대한 연결을 검사합니다.
2. NSX CLI 명령 get interface eth0를 호출하여 관리 인터페이스 상태를 검사합니다.
3. CLI get services를 호출하여 dataplane/local-controller/nestdb/router 등의 핵심 서비스 상태를 확인합니다.
4. /var/log/syslog를 검사하여 의심스러운 오류를 찾습니다.
5. Edge 노드를 재부팅합니다.

마이크로 흐름 캐시 적중률이 감소하고 데이터 경로 CPU가 높습니다.

이벤트가 감지된 경우: "Edge 노드 {entity_id}에서 마이크로 흐름 캐시 적중률이 코어 {core_id}에 대해 지정된 임계값 {flow_cache_threshold}% 미만으로 감소했으며 데이터 경로 CPU 사용량은 지난 30분 동안 증가했습니다. "

이벤트가 해결된 경우: "흐름 캐시 적중률이 정상 범위에 있습니다. "

캐시 흐름 적중률이 지난 30분 동안 감소했으며, 이는 Edge 성능이 저하되었을 수 있음을 나타냅니다. 트래픽은 계속 전달되며 문제가 발생하지 않을 수도 있습니다. 지난 30분 동안 트래픽이 높은 경우 Edge {entity_id} 코어 {core_id}에 대한 데이터 경로 CPU 활용률을 확인합니다. 새 흐름의 첫 번째 패킷은 빠른 경로 처리를 위해 흐름 캐시를 설정하는 데 사용되므로 지속적으로 새 흐름이 생성되면 Edge의 흐름 캐시 적중률이 낮아집니다. Edge 장치 크기를 늘리거나 활성/활성 게이트웨이에 사용되는 Edge 노드의 수를 늘려야 할 수 있습니다.

메가 흐름 캐시 적중률이 감소하고 데이터 경로 CPU가 높습니다.

이벤트가 감지된 경우: "Edge 노드 {entity_id}에서 메가 흐름 캐시 적중률이 코어 {core_id}에 대해 지정된 임계값 {flow_cache_threshold}% 미만으로 감소했으며 데이터 경로 CPU 사용량은 지난 30분 동안 증가했습니다. "

이벤트가 해결된 경우: "흐름 캐시 적중률이 정상 범위에 있습니다. "

캐시 흐름 적중률이 지난 30분 동안 감소했으며, 이는 Edge 성능이 저하되었을 수 있음을 나타냅니다. 트래픽은 계속 전달되며 문제가 발생하지 않을 수도 있습니다. 지난 30분 동안 트래픽이 높은 경우 Edge {entity_id} 코어 {core_id}에 대한 데이터 경로 CPU 활용률을 확인합니다. 새 흐름의 첫 번째 패킷은 빠른 경로 처리를 위해 흐름 캐시를 설정하는 데 사용되므로 지속적으로 새 흐름이 생성되면 Edge의 흐름 캐시 적중률이 낮아집니다. Edge 장치 크기를 늘리거나 활성/활성 게이트웨이에 사용되는 Edge 노드의 수를 늘려야 할 수 있습니다.

계산 관리자의 EAM(ESX Agent Manager) 서비스가 종료되었습니다.

이벤트가 감지된 경우: "계산 관리자 {entity_id}의 EAM(ESX Agent Manager) 서비스가 종료되었습니다. "

이벤트가 해결된 경우: "계산 관리자 {entity_id}의 EAM(ESX Agent Manager) 서비스가 실행 중이거나 계산 관리자 {entity_id}이(가) 제거되었습니다. "

EAM(ESX Agent Manager) 서비스를 시작합니다. vCenter에 대해 SSH를 수행하고 service vmware-eam start 명령을 호출합니다.

호스트 모듈 및 파트너 SVM 연결이 종료되었습니다.

이벤트가 감지된 경우: "호스트 모듈 및 파트너 SVM {entity_id} 간의 연결이 종료되었습니다. "

이벤트가 해결된 경우: "호스트 모듈 및 파트너 SVM {entity_id} 간의 연결이 실행 중입니다. "

https://kb.vmware.com/s/article/85844을 참조하고 파트너 SVM {entity_id}이(가) 호스트 모듈에 다시 연결되었는지 확인합니다.

RTEP BGP 인접 네트워크가 종료되었습니다.

이벤트가 감지된 경우: "소스 IP {bgp_source_ip}에서 원격 위치 {remote_site_name} 인접 항목 IP {bgp_neighbor_ip}로의 RTEP(원격 터널 끝점) BGP 세션이 종료되었습니다. 이유: {failure_reason}. "

이벤트가 해결된 경우: "소스 IP {bgp_source_ip}에서 원격 위치 {remote_site_name} 인접 항목 IP {bgp_neighbor_ip}로의 RTEP(원격 터널 끝점) BGP 세션이 설정되었습니다. "

1. 영향을 받는 Edge 노드에서 NSX CLI 명령 get logical-routers를 호출합니다.
2. REMOTE_TUNNEL_VRF 컨텍스트로 전환합니다.
3. NSX CLI 명령 get bgp neighbor summary를 호출하여 BGP 인접 항목 상태를 확인합니다.
4. 또는 NSX API GET /api/v1/transport-nodes/&lttransport-node-id&gt/inter-site/bgp/summary를 호출하여 BGP 인접 항목 상태를 가져옵니다.
5. NSX CLI 명령 get interfaces를 호출하고 이름이 remote-tunnel-endpoint인 인터페이스에 올바른 RTEP IP 주소가 할당되었는지 확인합니다.
6. 할당된 RTEP IP 주소({bgp_source_ip})와 원격 위치 {remote_site_name} 인접 항목 IP {bgp_neighbor_ip} 사이에서 ping이 성공적으로 작동하는지 확인합니다.
7. BGP와 관련된 오류가 있는지 /var/log/syslog를 확인합니다.
8. NSX API GET 또는 PUT /api/v1/transport-nodes/&lttransport-node-id&gt를 호출하여 Edge 노드에서 remote_tunnel_endpoint 구성을 가져오고 업데이트합니다. 이렇게 하면 영향을 받는 Edge 노드에 할당된 RTEP IP가 업데이트됩니다. Edge가 준비되지 않음으로 표시되는 경우 Edge 노드가 정상 상태가 아닌 이유를 확인합니다.
1. NSX CLI 명령 get edge-cluster status를 호출하여 Edge 노드가 종료된 이유를 확인합니다.
2. NSX CLI 명령 get bfd-config 및 get bfd-sessions를 호출하여 BFD가 잘 실행되고 있는지 확인합니다.
3. Edge 상태 관련 경보를 확인하여 자세한 내용을 확인합니다.

원격 위치 간의 동기화가 3분 이상 실패했습니다.

이벤트가 감지된 경우: "{site_name}({site_id})과(와) {remote_site_name}({remote_site_id}) 간의 동기화가 3분 넘게 실패했습니다. "

이벤트가 해결된 경우: "이제 원격 위치 {site_name}({site_id})과(와) {remote_site_name}({remote_site_id})이(가) 동기화됩니다. "

1. NSX CLI 명령 get site-replicator remote-sites를 호출하여 원격 위치 간의 연결 상태를 가져옵니다. 원격 위치가 연결되었지만 동기화되지 않은 경우에도 위치가 마스터 확인 프로세스에 있을 수 있습니다. 이 경우 약 10초 동안 기다린 후 CLI를 다시 호출하여 원격 위치의 상태를 확인하십시오. 위치가 연결되지 않은 경우 다음 단계를 시도합니다.
2. Ping을 통해 {site_name}({site_id}) 위치에 있는 LM(로컬 관리자)에서 {remote_site_name}({remote_site_id}) 위치에 있는 LM으로의 연결을 확인하십시오. Ping할 수 없는 경우 WAN 연결이 끊기는지 확인합니다. 물리적 네트워크 연결 문제가 없는 경우 다음 단계를 시도하십시오.
3. 경보를 트리거한 위치 {site_name}({site_id})의 로컬 클러스터에 있는 관리자 노드의 /var/log/cloudnet/nsx-ccp.log 파일을 확인하여 사이트 간 통신 오류가 있는지 알아봅니다. 또한 /var/log/syslog 내에서 nsx-appl-proxy 하위 구성 요소에 의해 기록되는 오류를 확인합니다.

원격 위치 간의 동기화가 15분 이상 실패했습니다.

이벤트가 감지된 경우: “{site_name}({site_id})과(와) {remote_site_name}({remote_site_id}) 간의 동기화가 15분 넘게 실패했습니다. "

이벤트가 해결된 경우: "이제 원격 사이트 {site_name}({site_id})과(와) {remote_site_name}({remote_site_id})이(가) 동기화됩니다. "

1. NSX CLI 명령 get site-replicator remote-sites를 호출하여 원격 위치 간의 연결 상태를 가져옵니다. 원격 위치가 연결되었지만 동기화되지 않은 경우에도 위치가 마스터 확인 프로세스에 있을 수 있습니다. 이 경우 약 10초 동안 기다린 후 CLI를 다시 호출하여 원격 위치의 상태를 확인하십시오. 위치가 연결되지 않은 경우 다음 단계를 시도합니다.
2. Ping을 통해 {site_name}({site_id}) 위치에 있는 LM(로컬 관리자)에서 {remote_site_name}({remote_site_id}) 위치에 있는 LM으로의 연결을 확인하십시오. Ping할 수 없는 경우 WAN 연결이 끊기는지 확인합니다. 물리적 네트워크 연결 문제가 없는 경우 다음 단계를 시도하십시오.
3. 경보를 트리거한 위치 {site_name}({site_id})의 로컬 클러스터에 있는 관리자 노드의 /var/log/cloudnet/nsx-ccp.log 파일을 확인하여 사이트 간 통신 오류가 있는지 알아봅니다. 또한 /var/log/syslog 내에서 nsx-appl-proxy 하위 구성 요소에 의해 기록되는 오류를 확인합니다.

RTEP 위치 연결이 끊어졌습니다.

이벤트가 감지된 경우: "Edge 노드 {transport_node_name}과(와) 원격 위치 {remote_site_name}에 대한 RTEP(원격 터널 끝점) 연결이 끊어졌습니다. "

이벤트가 해결된 경우: "Edge 노드 {transport_node_name}과(와) 원격 위치 {remote_site_name}에 대한 RTEP(원격 터널 끝점) 연결이 복원되었습니다. "

1. 영향을 받는 Edge 노드 {transport_node_name}에서 NSX CLI 명령 get logical-routers를 호출합니다.
2. REMOTE_TUNNEL_VRF 컨텍스트로 전환합니다.
3. NSX CLI 명령 get bgp neighbor summary를 호출하여 BGP 인접 항목 상태를 확인합니다.
4. 또는 NSX API GET /api/v1/transport-nodes/&lttransport-node-id&gt/inter-site/bgp/summary를 호출하여 BGP 인접 항목 상태를 가져옵니다.
5. NSX CLI 명령 get interfaces를 호출하고 이름이 remote-tunnel-endpoint인 인터페이스에 올바른 RTEP IP 주소가 할당되었는지 확인합니다.
6. 할당된 RTEP IP 주소와 원격 위치 {remote_site_name}의 RTEP IP 주소 사이에서 ping이 성공적으로 작동하는지 확인합니다.
7. BGP와 관련된 오류가 있는지 /var/log/syslog를 확인합니다.
8. NSX API GET 또는 PUT /api/v1/transport-nodes/&lttransport-node-id&gt를 호출하여 Edge 노드에서 remote_tunnel_endpoint 구성을 가져오고 업데이트합니다. 이렇게 하면 영향을 받는 Edge 노드 {transport_node_name}에 할당된 RTEP IP가 업데이트됩니다.

여러 글로벌 관리자 노드가 동시에 활성 상태입니다.

이벤트가 감지된 경우: "여러 글로벌 관리자 노드가 활성 상태입니다. {active_global_managers}. 글로벌 관리자 노드는 한 번에 하나만 활성 상태여야 합니다. "

이벤트가 해결된 경우: 글로벌 관리자 노드 {active_global_manager}이(가) 현재 유일한 활성 글로벌 관리자 노드입니다. "

하나의 글로벌 관리자 노드만 활성 노드로 구성하고 다른 모든 글로벌 관리자 노드는 대기 노드로 구성합니다.

글로벌 관리자 간 지연 시간이 2분 넘게 예상보다 높습니다.

이벤트가 감지된 경우: "글로벌 관리자 {from_gm_path}과(와) {to_gm_path} 간 지연 시간이 예상보다 깁니다. "

이벤트가 해결된 경우: "글로벌 관리자 {from_gm_path}과(와) {to_gm_path} 간 지연 시간이 예상 수준보다 낮습니다. "

ping을 통해 글로벌 관리자 {from_gm_path}({site_id})에서 글로벌 관리자 {to_gm_path}({remote_site_id})(으)로의 연결을 확인합니다. Ping할 수 없는 경우 WAN 연결이 끊기는지 확인합니다.

활성 글로벌 관리자에서 대기 글로벌 관리자로 동기화할 수 없습니다.

이벤트가 감지된 경우: "활성 글로벌 관리자 {from_gm_path}에서 대기 글로벌 관리자 {to_gm_path}(으)로 동기화할 수 없습니다. "

이벤트가 해결된 경우: "활성 글로벌 관리자 {from_gm_path}에서 대기 {to_gm_path}(으)로의 동기화가 정상입니다. "

ping을 통해 글로벌 관리자 {from_gm_path}({site_id})에서 글로벌 관리자 {to_gm_path}({remote_site_id})(으)로의 연결을 확인합니다.

활성 글로벌 관리자에서 대기 글로벌 관리자로 5분 넘게 동기화할 수 없습니다.

이벤트가 감지된 경우: "활성 글로벌 관리자 {from_gm_path}에서 대기 글로벌 관리자 {to_gm_path}로 5분 넘게 동기화할 수 없습니다. "

이벤트가 해결된 경우: "활성 글로벌 관리자 {from_gm_path}에서 대기 {to_gm_path}(으)로의 동기화가 정상입니다. "

ping을 통해 글로벌 관리자 {from_gm_path}({site_id})에서 글로벌 관리자 {to_gm_path}({remote_site_id})(으)로의 연결을 확인합니다.

GM(글로벌 관리자)과 LM(로컬 관리자) 간의 데이터 동기화가 실패했습니다.

이벤트가 감지된 경우: "사이트 {site_name}({site_id})과(와) {remote_site_name}({remote_site_id}) 간의 데이터 동기화가 {flow_identifier}에 대해 실패했습니다. 이유: {sync_issue_reason} "

이벤트가 해결된 경우: "이제 사이트 {site_name}({site_id})과(와) {remote_site_name}({remote_site_id})이(가) {flow_identifier}에 대해 동기화됩니다. "

1. ping을 통해 원격 사이트와 로컬 사이트 간의 네트워크 연결을 확인합니다.
2. 로컬 사이트와 원격 사이트 간에 포트 TCP/1236 트래픽이 허용되는지 확인합니다.
3. 로컬 사이트와 원격 사이트 모두에서 async-replicator 서비스가 실행 중인지 확인합니다. GET /api/v1/node/services/async_replicator/status NSX API 또는 get service async_replicator NSX CLI 명령을 호출하여 서비스가 실행 중인지 확인합니다. 실행되고 있지 않으면 POST /api/v1/node/services/async_replicator?action=restart NSX API 또는 restart service async_replicator NSX CLI를 호출하여 서비스를 다시 시작합니다.
4. /var/log/async-replicator/ar.log에 보고된 오류가 있는지 확인합니다.

GM(글로벌 관리자)과 LM(로컬 관리자) 간의 데이터 동기화가 장기간 실패했습니다.

이벤트가 감지된 경우: "사이트 {site_name}({site_id})과(와) {remote_site_name}({remote_site_id}) 간의 데이터 동기화가 {flow_identifier}에 대해 오랜 시간 동안 실패했습니다. 이유: {sync_issue_reason}. "

이벤트가 해결된 경우: "이제 사이트 {site_name}({site_id})과(와) {remote_site_name}({remote_site_id})이(가) {flow_identifier}에 대해 동기화됩니다. "

1. ping을 통해 원격 사이트와 로컬 사이트 간의 네트워크 연결을 확인합니다.
2. 로컬 사이트와 원격 사이트 간에 포트 TCP/1236 트래픽이 허용되는지 확인합니다.
3. 로컬 사이트와 원격 사이트 모두에서 async-replicator 서비스가 실행 중인지 확인합니다. GET /api/v1/node/services/async_replicator/status NSX API 또는 get service async_replicator NSX CLI 명령을 호출하여 서비스가 실행 중인지 확인합니다. 실행되고 있지 않으면 POST /api/v1/node/services/async_replicator?action=restart NSX API 또는 restart service async_replicator NSX CLI를 호출하여 서비스를 다시 시작합니다.
4. /var/log/async-replicator/ar.log에 보고된 오류가 있는지 확인합니다.
5. 지원 번들을 수집하고 NSX 지원 팀에 문의하십시오.

대기열 점유 크기 임계값이 주의를 초과했습니다.

이벤트가 감지된 경우: "사이트 {site_name}({site_id})과(와) {remote_site_name}({remote_site_id}) 간의 데이터를 동기화하는 데 사용되는 대기열 ({queue_name})이(가) 최대 임계값 {queue_size_threshold}% 이상인 {queue_size} 크기에 도달했습니다. "

이벤트가 해결된 경우: "사이트 {site_name}({site_id})과(와) {remote_site_name}({remote_site_id}) 간의 데이터를 동기화하는 데 사용되는 대기열 ({queue_name})이(가) 최대 임계값 {queue_size_threshold}% 미만인 {queue_size} 크기에 도달했습니다. "

원격 사이트 또는 오버로드된 시스템과의 통신 문제로 인해 대기열 크기가 임계값을 초과할 수 있습니다. 시스템 성능 및 /var/log/async-replicator/ar.log를 확인하여 보고된 오류가 있는지 알아보십시오.

글로벌 관리자와 로컬 관리자 간 지연 시간이 2분 넘게 예상보다 높았습니다.

이벤트가 감지된 경우: "사이트 {site_name}({site_id})과(와) {remote_site_name}({remote_site_id}) 간의 지연 시간이 {latency_threshold} 임계값을 초과하는 {latency_value}에 도달했습니다. "

이벤트가 해결된 경우: "사이트 {site_name}({site_id})과(와) {remote_site_name}({remote_site_id}) 간의 지연 시간이 {latency_threshold} 임계값 미만인 {latency_value}에 도달했습니다. "

1. ping을 통해 원격 사이트와 로컬 사이트 간의 네트워크 연결을 확인합니다.
2. 로컬 사이트와 원격 사이트 간에 포트 TCP/1236 트래픽이 허용되는지 확인합니다.
3. /var/log/async-replicator/ar.log에 보고된 오류가 있는지 확인합니다.

글로벌 관리자에서 구성 가져오기를 진행하는 동안 로컬 관리자가 복원됩니다.

이벤트가 감지된 경우: "사이트 {site_name}({site_id})에서 구성 가져오기를 진행 중입니다. 그러나 {site_name}({site_id}) 사이트는 관리자에 의해 백업에서 복원되어 일관되지 않은 상태가 됩니다. "

이벤트가 해결된 경우: "사이트 {site_name}({site_id})의 구성 불일치가 해결되었습니다. "

1. NSX Global Manager 장치 CLI에 로그인합니다.
2. 루트로 전환합니다.
3. 로컬 모드에서 NSX API DELETE http://localhost:64440 /gm/api/v1/infra/sites/&ltsite-name&gt/onboarding/status를 호출하면 글로벌 관리자의 사이트 온보딩 상태가 삭제됩니다.
4. 구성 온보딩을 다시 시작합니다.

IP 트래픽에 대한 게이트웨이 방화벽 흐름 테이블 사용량이 높습니다. 사용량이 최대 제한에 도달하면 게이트웨이 방화벽에 의해 새 흐름이 삭제됩니다.

이벤트가 감지된 경우: "논리적 라우터 {entity_id}의 IP에 대한 게이트웨이 방화벽 흐름 테이블 사용량이 높은 임계값 {system_usage_threshold}% 이상인 {firewall_ip_flow_usage}%에 도달했습니다. 사용량이 최대 제한에 도달하면 게이트웨이 방화벽에 의해 새 흐름이 삭제됩니다. "

이벤트가 해결된 경우: "논리적 라우터 {entity_id}의 비 IP 흐름에 대한 게이트웨이 방화벽 흐름 테이블 사용량이 높은 임계값 {system_usage_threshold}% 미만입니다. "

Edge 노드에서 admin 사용자로 로그인하고 적절한 인터페이스 uuid를 사용하여 NSX CLI 명령 get firewall &ltLR_INT_UUID&gt interface stats | json을 호출한 후 IP 흐름에 대한 흐름 테이블 사용량을 확인합니다. 게이트웨이를 통과하는 트래픽 흐름이 DOS 공격 또는 비정상 버스트가 아닌지 확인합니다. 트래픽이 정상 로드 내에 있는 것으로 나타나지만 경보 임계값에 도달한 경우 경보 임계값을 늘리거나 새 트래픽을 다른 Edge 노드로 라우팅하는 것이 좋습니다.

IP 트래픽에 대한 게이트웨이 방화벽 흐름 테이블이 설정된 임계값을 초과했습니다. 사용량이 최대 제한에 도달하면 게이트웨이 방화벽에 의해 새 흐름이 삭제됩니다.

이벤트가 감지된 경우: "논리적 라우터 {entity_id}의 IP 트래픽에 대한 게이트웨이 방화벽 흐름 테이블 사용량이 높은 임계값 {system_usage_threshold}% 이상인 {firewall_ip_flow_usage}%에 도달했습니다. 사용량이 최대 제한에 도달하면 게이트웨이 방화벽에 의해 새 흐름이 삭제됩니다. "

이벤트가 해결된 경우: "논리적 라우터 {entity_id}의 게이트웨이 방화벽 흐름 테이블 사용량이 높은 임계값 {system_usage_threshold}% 미만입니다. "

Edge 노드에서 admin 사용자로 로그인하고 적절한 인터페이스 uuid를 사용하여 NSX CLI 명령 get firewall &ltLR_INT_UUID&gt interface stats | json을 호출한 후 IP 흐름에 대한 흐름 테이블 사용량을 확인합니다. 게이트웨이를 통과하는 트래픽 흐름이 DOS 공격 또는 비정상 버스트가 아닌지 확인합니다. 트래픽이 정상 로드 내에 있는 것으로 나타나지만 경보 임계값에 도달한 경우 경보 임계값을 늘리거나 새 트래픽을 다른 Edge 노드로 라우팅하는 것이 좋습니다.

UDP 트래픽에 대한 게이트웨이 방화벽 흐름 테이블 사용량이 높습니다. 사용량이 최대 제한에 도달하면 게이트웨이 방화벽에 의해 새 흐름이 삭제됩니다.

이벤트가 감지된 경우: "논리적 라우터 {entity_id}의 UDP에 대한 게이트웨이 방화벽 흐름 테이블 사용량이 높은 임계값 {system_usage_threshold}% 이상인 {firewall_udp_flow_usage}%에 도달했습니다. 사용량이 최대 제한에 도달하면 게이트웨이 방화벽에 의해 새 흐름이 삭제됩니다. "

이벤트가 해결된 경우: "논리적 라우터 {entity_id}의 UDP에 대한 게이트웨이 방화벽 흐름 테이블 사용량이 높은 임계값 미만입니다. "

Edge 노드에서 admin 사용자로 로그인하고 적절한 인터페이스 uuid를 사용하여 NSX CLI 명령 get firewall &ltLR_INT_UUID&gt interface stats | json을 호출한 후 UDP 흐름에 대한 흐름 테이블 사용량을 확인합니다. 게이트웨이를 통과하는 트래픽 흐름이 DOS 공격 또는 비정상 버스트가 아닌지 확인합니다. 트래픽이 정상 로드 내에 있는 것으로 나타나지만 경보 임계값에 도달한 경우 경보 임계값을 늘리거나 새 트래픽을 다른 Edge 노드로 라우팅하는 것이 좋습니다.

UDP 트래픽에 대한 게이트웨이 방화벽 흐름 테이블이 설정된 임계값을 초과했습니다. 사용량이 최대 제한에 도달하면 게이트웨이 방화벽에 의해 새 흐름이 삭제됩니다.

이벤트가 감지된 경우: "논리적 라우터 {entity_id}의 UDP 트래픽에 대한 게이트웨이 방화벽 흐름 테이블 사용량이 높은 임계값 {system_usage_threshold}% 이상인 {firewall_udp_flow_usage}%에 도달했습니다. 사용량이 최대 제한에 도달하면 게이트웨이 방화벽에 의해 새 흐름이 삭제됩니다. "

이벤트가 해결된 경우: "논리적 라우터 {entity_id}의 게이트웨이 방화벽 흐름 테이블 사용량이 높은 임계값 미만입니다. "

Edge 노드에서 admin 사용자로 로그인하고 적절한 인터페이스 uuid를 사용하여 NSX CLI 명령 get firewall &ltLR_INT_UUID&gt interface stats | json을 호출한 후 UDP 흐름에 대한 흐름 테이블 사용량을 확인합니다. 게이트웨이를 통과하는 트래픽 흐름이 DOS 공격 또는 비정상 버스트가 아닌지 확인합니다. 트래픽이 정상 로드 내에 있는 것으로 나타나지만 경보 임계값에 도달한 경우 경보 임계값을 늘리거나 새 트래픽을 다른 Edge 노드로 라우팅하는 것이 좋습니다.

ICMP 트래픽에 대한 게이트웨이 방화벽 흐름 테이블 사용량이 높습니다. 사용량이 최대 제한에 도달하면 게이트웨이 방화벽에 의해 새 흐름이 삭제됩니다.

이벤트가 감지된 경우: "논리적 라우터 {entity_id}의 ICMP에 대한 게이트웨이 방화벽 흐름 테이블 사용량이 높은 임계값 {system_usage_threshold}% 이상인 {firewall_icmp_flow_usage}%에 도달했습니다. 사용량이 최대 제한에 도달하면 게이트웨이 방화벽에 의해 새 흐름이 삭제됩니다. "

이벤트가 해결된 경우: "논리적 라우터 {entity_id}의 ICMP에 대한 게이트웨이 방화벽 흐름 테이블 사용량이 높은 임계값 {system_usage_threshold}% 미만입니다. "

Edge 노드에서 admin 사용자로 로그인하고 적절한 인터페이스 uuid를 사용하여 NSX CLI 명령 get firewall &ltLR_INT_UUID&gt interface stats | json을 호출한 후 ICMP 흐름에 대한 흐름 테이블 사용량을 확인합니다. 게이트웨이를 통과하는 트래픽 흐름이 DOS 공격 또는 비정상 버스트가 아닌지 확인합니다. 트래픽이 정상 로드 내에 있는 것으로 나타나지만 경보 임계값에 도달한 경우 경보 임계값을 늘리거나 새 트래픽을 다른 Edge 노드로 라우팅하는 것이 좋습니다.

ICMP 트래픽에 대한 게이트웨이 방화벽 흐름 테이블이 설정된 임계값을 초과했습니다. 사용량이 최대 제한에 도달하면 게이트웨이 방화벽에 의해 새 흐름이 삭제됩니다.

이벤트가 감지된 경우: "논리적 라우터 {entity_id}의 ICMP 트래픽에 대한 게이트웨이 방화벽 흐름 테이블 사용량이 높은 임계값 {system_usage_threshold}% 이상인 {firewall_icmp_flow_usage}%에 도달했습니다. 사용량이 최대 제한에 도달하면 게이트웨이 방화벽에 의해 새 흐름이 삭제됩니다. "

이벤트가 해결된 경우: "논리적 라우터 {entity_id}의 게이트웨이 방화벽 흐름 테이블 사용량이 높은 임계값 {system_usage_threshold}% 미만입니다. "

Edge 노드에서 admin 사용자로 로그인하고 적절한 인터페이스 uuid를 사용하여 NSX CLI 명령 get firewall &ltLR_INT_UUID&gt interface stats | json을 호출한 후 ICMP 흐름에 대한 흐름 테이블 사용량을 확인합니다. 게이트웨이를 통과하는 트래픽 흐름이 DOS 공격 또는 비정상 버스트가 아닌지 확인합니다. 트래픽이 정상 로드 내에 있는 것으로 나타나지만 경보 임계값에 도달한 경우 경보 임계값을 늘리거나 새 트래픽을 다른 Edge 노드로 라우팅하는 것이 좋습니다.

TCP 절반 개방 트래픽에 대한 게이트웨이 방화벽 흐름 테이블 사용량이 높습니다. 사용량이 최대 제한에 도달하면 게이트웨이 방화벽에 의해 새 흐름이 삭제됩니다.

이벤트가 감지된 경우: "논리적 라우터 {entity_id}의 TCP에 대한 게이트웨이 방화벽 흐름 테이블 사용량이 높은 임계값 {system_usage_threshold}% 이상인 {firewall_halfopen_flow_usage}%에 도달했습니다. 사용량이 최대 제한에 도달하면 게이트웨이 방화벽에 의해 새 흐름이 삭제됩니다. "

이벤트가 해결된 경우: "논리적 라우터 {entity_id}의 TCP 절반 개방에 대한 게이트웨이 방화벽 흐름 테이블 사용량이 높은 임계값 {system_usage_threshold}% 미만입니다. "

Edge 노드에서 admin 사용자로 로그인하고 적절한 인터페이스 uuid를 사용하여 NSX CLI 명령 get firewall &ltLR_INT_UUID&gt interface stats | json을 호출한 후 TCP 절반 개방 흐름에 대한 흐름 테이블 사용량을 확인합니다. 게이트웨이를 통과하는 트래픽 흐름이 DOS 공격 또는 비정상 버스트가 아닌지 확인합니다. 트래픽이 정상 로드 내에 있는 것으로 나타나지만 경보 임계값에 도달한 경우 경보 임계값을 늘리거나 새 트래픽을 다른 Edge 노드로 라우팅하는 것이 좋습니다.

TCP 절반 개방 트래픽에 대한 게이트웨이 방화벽 흐름 테이블이 설정된 임계값을 초과했습니다. 사용량이 최대 제한에 도달하면 게이트웨이 방화벽에 의해 새 흐름이 삭제됩니다.

이벤트가 감지된 경우: "논리적 라우터 {entity_id}의 TCP 절반 개방 트래픽에 대한 게이트웨이 방화벽 흐름 테이블 사용량이 높은 임계값 {system_usage_threshold}% 이상인 {firewall_halfopen_flow_usage}%에 도달했습니다. 사용량이 최대 제한에 도달하면 게이트웨이 방화벽에 의해 새 흐름이 삭제됩니다. "

이벤트가 해결된 경우: "논리적 라우터 {entity_id}의 게이트웨이 방화벽 흐름 테이블 사용량이 높은 임계값 {system_usage_threshold}% 미만입니다. "

Edge 노드에서 admin 사용자로 로그인하고 적절한 인터페이스 uuid를 사용하여 NSX CLI 명령 get firewall &ltLR_INT_UUID&gt interface stats | json을 호출한 후 TCP 절반 개방 흐름에 대한 흐름 테이블 사용량을 확인합니다. 게이트웨이를 통과하는 트래픽 흐름이 DOS 공격 또는 비정상 버스트가 아닌지 확인합니다. 트래픽이 정상 로드 내에 있는 것으로 나타나지만 경보 임계값에 도달한 경우 경보 임계값을 늘리거나 새 트래픽을 다른 Edge 노드로 라우팅하는 것이 좋습니다.

전송된 그룹 요소의 총 수가 최대 제한을 초과했습니다.

이벤트가 감지된 경우: "최대 수 제한인 {group_max_number_limit}개 이상인 그룹 {group_id}에 {group_size}개 이상의 변환된 요소가 있습니다. 이로 인해 처리 시간이 길어지고 시간 초과 및 중단이 발생할 수 있습니다. 각 요소 유형의 현재 개수는 다음과 같습니다. IP 집합:{ip_count}, MAC 집합:{mac_count}, VIFS:{vif_count}, 논리적 스위치 포트:{lsp_count}, 논리적 라우터 포트:{lrp_count}, AdGroups:{sid_count}. "

이벤트가 해결된 경우: "그룹 {group_id}의 총 요소 수가 최대 제한인 {group_max_number_limit}개 미만입니다. "

1. 크기가 초과한 그룹 {group_id}에서 그룹 요소를 조정하는 것이 좋습니다.
2. 크기가 초과한 그룹 {group_id}을(를) 여러 개의 소규모 그룹으로 분할하고 크기가 초과한 그룹의 멤버를 이러한 그룹으로 분산하는 것이 좋습니다.

Tier0 게이트웨이가 페일오버되었습니다.

이벤트가 감지된 경우: "Tier0 게이트웨이 {entity_id}이(가) {previous_gateway_state}에서 {current_gateway_state}, service-router {service_router_id}(으)로 페일오버됩니다."

이벤트가 해결된 경우: "이제 Tier0 게이트웨이 {entity_id}이(가) 실행되고 있습니다. "

NSX CLI 명령 get logical-router &ltservice_router_id&gt를 호출하여 Tier0 service-router vrf ID를 식별합니다. vrf &ltvrf-id&gt를 호출하여 vrf 컨텍스트로 전환한 후 get high-availability status를 호출하여 종료된 서비스를 확인합니다.

Tier1 게이트웨이가 페일오버되었습니다.

이벤트가 감지된 경우: "Tier1 게이트웨이 {entity_id}이(가) {previous_gateway_state}에서 {current_gateway_state}, service-router {service_router_id}(으)로 페일오버됩니다."

이벤트가 해결된 경우: "이제 Tier1 게이트웨이 {entity_id}이(가) 실행되고 있습니다. "

NSX CLI 명령 get logical-router &ltservice_router_id&gt를 호출하여 Tier1 service-router vrf ID를 식별합니다. vrf &ltvrf-id&gt를 호출하여 vrf 컨텍스트로 전환한 후 get high-availability status를 호출하여 종료된 서비스를 확인합니다.

서비스 그룹에 활성 인스턴스가 없습니다.

이벤트가 감지된 경우: "서비스 그룹 클러스터 {entity_id}에 현재 활성 인스턴스가 없습니다. Edge 노드 {transport_node_id}에서는 상태 {ha_state}(0: 종료, 1: 대기, 2: 활성)이고, Edge 노드 {transport_node_id2}에서는 상태 {ha_state2}입니다. "

이벤트가 해결된 경우: "Tier0 서비스 그룹 클러스터 {entity_id}의 Edge 노드 {transport_node_id}에 하나의 활성 인스턴스가 있습니다. "

NSX CLI 명령 get logical-router &ltservice_router_id&gt service_group을 호출하여 지정된 service-router 아래에 구성된 모든 서비스 그룹을 확인합니다. 출력에서 서비스 그룹이 활성 상태를 벗어나는 이유를 검토하십시오.

서비스 그룹에 활성 인스턴스가 없습니다.

이벤트가 감지된 경우: "서비스 그룹 클러스터 {entity_id}에 현재 활성 인스턴스가 없습니다. Edge 노드 {transport_node_id}에서는 상태 {ha_state}(0: 종료, 1: 대기, 2: 활성)이고, Edge 노드 {transport_node_id2}에서는 상태 {ha_state2}입니다. "

이벤트가 해결된 경우: "Tier1 서비스 그룹 클러스터 {entity_id}의 Edge 노드 {transport_node_id}에 하나의 활성 인스턴스가 있습니다. "

NSX CLI 명령 get logical-router &ltservice_router_id&gt service_group을 호출하여 지정된 service-router 아래에 구성된 모든 서비스 그룹을 확인합니다. 출력에서 서비스 그룹이 활성 상태를 벗어나는 이유를 검토하십시오.

서비스 그룹의 대기 인스턴스가 실패했습니다.

이벤트가 감지된 경우: Edge 노드 {transport_node_id}의 Tier0 서비스 라우터 {service_router_id}에 연결된 서비스 그룹 클러스터 {entity_id}이(가) 실패했습니다. 따라서 서비스 그룹 클러스터에 현재 대기 인스턴스가 없습니다. "

이벤트가 해결된 경우: "서비스 그룹 클러스터 {entity_id}이(가) Edge 노드 {transport_node_id}에서 상태 {ha_state}(0: 종료, 1: 대기, 2: 활성)이고 Edge 노드 {transport_node_id2}에서 상태 {ha_state2}입니다. "

NSX CLI 명령 get logical-router &ltservice_router_id&gt service_group을 호출하여 지정된 service-router 아래에 구성된 모든 서비스 그룹을 확인합니다. 출력을 검토하여 이전에 대기한 서비스 그룹에 대한 실패 이유를 확인하십시오.

서비스 그룹의 대기 인스턴스가 실패했습니다.

이벤트가 감지된 경우: Edge 노드 {transport_node_id}의 Tier1 서비스 라우터 {service_router_id}에 연결된 서비스 그룹 클러스터 {entity_id}이(가) 실패했습니다. 따라서 서비스 그룹 클러스터에 현재 대기 인스턴스가 없습니다. "

이벤트가 해결된 경우: "서비스 그룹 클러스터 {entity_id}이(가) Edge 노드 {transport_node_id}에서 상태 {ha_state}(0: 종료, 1: 대기, 2: 활성)이고 Edge 노드 {transport_node_id2}에서 상태 {ha_state2}입니다. "

NSX CLI 명령 get logical-router &ltservice_router_id&gt service_group을 호출하여 지정된 service-router 아래에 구성된 모든 서비스 그룹을 확인합니다. 출력을 검토하여 이전에 대기한 서비스 그룹에 대한 실패 이유를 확인하십시오.

LDAP 서버에 대한 연결이 끊어졌습니다.

이벤트가 감지된 경우: "LDAP 서버 {ldap_server}에 대한 연결이 끊어졌습니다. "

이벤트가 해결된 경우: "LDAP 서버 {ldap_server}에 대한 연결이 복원되었습니다. "

다음을 확인하십시오.
1. NSX 노드에서 LDAP 서버에 연결할 수 있습니다.
2. LDAP 서버 세부 정보는 NSX에서 올바르게 구성되어 있습니다.
3. LDAP 서버가 제대로 실행되고 있습니다.
4. LDAP 서버와 NSX 노드 간에 액세스를 차단하는 방화벽이 없습니다. 이 문제가 수정되면 ID 방화벽 AD의 NSX UI에서 [연결 테스트]를 사용하여 연결을 테스트합니다.

델타 동기화를 수행하는 동안 오류가 발생했습니다.

이벤트가 감지된 경우: "{directory_domain}와(과)의 델타 동기화를 수행하는 동안 오류가 발생했습니다. "

이벤트가 해결된 경우: "{directory_domain}와(과)의 델타 동기화를 수행하는 동안 오류가 발생하지 않았습니다. "

1. LDAP 서버에 대한 연결이 끊어졌다는 경보가 있는지 확인합니다.
2. /var/log/syslog에서 오류 세부 정보를 찾습니다. 경보 트리거 시간에 LDAP 개체를 동기화할 때 오류가 발생했습니다. 텍스트를 검색합니다.
3. 오류를 유발할 수 있는 최근 AD 변경 내용이 있는지를 AD 관리자에게 문의하십시오.
4. 오류가 지속되면 기술 지원 번들을 수집한 후 VMware 기술 지원 서비스에 문의하십시오.

Edge 노드의 터널 상태가 종료입니다.

이벤트가 감지된 경우: "Edge 노드 {entity_id}의 전체 터널 상태가 종료입니다. "

이벤트가 해결된 경우: "Edge 노드 {entity_id}의 터널이 복원되었습니다. "

NSX CLI 명령 get tunnel-ports를 호출하여 모든 터널 포트를 가져오고, NSX CLI 명령 get tunnel-port &ltUUID&gt stats를 호출하여 삭제가 발생했는지 각 터널 통계를 확인합니다. 또한 터널 관련 오류가 있는지 /var/log/syslog를 확인합니다.

DPU에 대한 서비스의 상태가 비정상입니다.

이벤트가 감지된 경우: "DPU {dpu_id}에서 서비스 {service_name}이(가) 10초 동안 응답하지 않았습니다. "

이벤트가 해결된 경우: "DPU {dpu_id}에서 서비스 {service_name}이(가) 다시 응답합니다. "

/etc/init.d/{service_name} status를 호출하여 DPU {dpu_id}에서 {service_name} 서비스가 계속 실행되고 있는지 확인하십시오. 서비스가 실행 중으로 보고되면 /etc/init.d/{service_name} restart로 수행할 수 있는 작업을 다시 시작해야 할 수 있습니다. status 명령을 다시 실행하여 서비스가 현재 실행되고 있는지 확인합니다. 서비스를 다시 시작해도 문제가 해결되지 않거나 성공적으로 다시 시작한 후에도 문제가 발생하면 VMware 지원 서비스에 문의하십시오.

서비스 상태가 비정상입니다.

이벤트가 감지된 경우: "서비스 {service_name}이(가) 10초 동안 응답하지 않았습니다. "

이벤트가 해결된 경우: "서비스 {service_name}이(가) 다시 응답합니다. "

/etc/init.d/{service_name} status를 호출하여 {service_name} 서비스가 계속 실행되고 있는지 확인하십시오. 서비스가 실행 중으로 보고되면 /etc/init.d/{service_name} restart로 수행할 수 있는 작업을 다시 시작해야 할 수 있습니다. status 명령을 다시 실행하여 서비스가 현재 실행되고 있는지 확인합니다. /etc/init.d/{service_name} 스크립트를 사용할 수 없는 경우 systemctl {service_name} status를 호출하고 루트 사용 권한으로 systemctl {service_name} restart를 호출하여 다시 시작하십시오. 서비스를 다시 시작해도 문제가 해결되지 않거나 성공적으로 다시 시작한 후에도 문제가 발생하면 VMware 지원 서비스에 문의하십시오.

지정된 대상에 메트릭을 전달하지 못했습니다.

이벤트가 감지된 경우: "SHA에서 대상 {metrics_target_alias}({metrics_target_address}:{metrics_target_port})(으)로 메트릭을 전달하지 못했습니다. "

이벤트가 해결된 경우: "대상 {metrics_target_alias}({metrics_target_address}:{metrics_target_port})에 대한 메트릭 전송이 복구되었습니다. "

사용자는 실패를 유발하는 문제를 제외하기 위해 다음 검사를 수행해야 합니다. 1. 연결을 위해 전달된 대상 주소 {metrics_target_address} 및 포트 {metrics_target_port}(포트가 지정되지 않은 경우 기본값은 443)이 예상된 대상인지 확인합니다. 2. /opt/vmware/nsx-nestdb/bin/nestdb-cli --cmd 'put vmware.nsx.nestdb.CommonAgentHostConfigMsg'를 사용하여 인증서가 올바른지 확인합니다. 3. 대상 {metrics_target_address}에 연결할 수 있는지 확인합니다. 4. docker ps | grep metrics_manager를 실행하여 대상 {metrics_target_address}의 메트릭 관리자가 실행 중인지 확인합니다. 5. 대상에서 netstat -a | grep {metrics_target_port}(으)로 포트 {metrics_target_port}이(가) 열려 있는지 확인합니다. 6. iptables -S OUTPUT | grep {metrics_target_port}(EDGE/UA) 또는 localcli network firewall ruleset list | grep nsx-sha-tsdb(ESX)로 노드에서 ALLOW 방화벽 규칙이 설치되어 있는지 확인합니다. 7. SHA 데몬을 다시 시작하여 /etc/init.d/netopa restart(ESX), /etc/init.d/nsx-netopa restart(EDGE) 또는 /etc/init.d/nsx-sha restart(UA)로 해결할 수 있는지 확인합니다.

Edge 서비스가 최소 1분 동안 종료되었습니다.

이벤트가 감지된 경우: "서비스 {edge_service_name}이(가) 1분 이상 종료되었습니다. {service_down_reason} "

이벤트가 해결된 경우: "서비스 {edge_service_name}이(가) 실행 중입니다. "

Edge 노드에서 /var/log/core 디렉토리에서 코어 파일을 찾아 오류 때문에 서비스가 종료되지 않았는지 확인합니다. 또한 NSX CLI 명령 get services를 호출하여 서비스가 중지되었는지 확인합니다. 이 경우 start service &ltservice-name&gt을 호출하여 서비스를 다시 시작합니다.

Edge 서비스 상태가 변경되었습니다.

이벤트가 감지된 경우: "서비스 {edge_service_name}이(가) {previous_service_state}에서 {current_service_state}(으)로 변경되었습니다. {service_down_reason} "

이벤트가 해결된 경우: "서비스 {edge_service_name}이(가) {previous_service_state}에서 {current_service_state}(으)로 변경되었습니다. "

Edge 노드에서 /var/log/core 디렉토리에서 코어 파일을 찾아 오류 때문에 서비스가 종료되지 않았는지 확인합니다. 또한 NSX CLI 명령 get services를 호출하여 서비스가 중지되었는지 확인합니다. 이 경우 start service &ltservice-name&gt을 호출하여 서비스를 다시 시작합니다.

애플리케이션이 충돌하고 코어 덤프를 생성했습니다.

이벤트가 감지된 경우: "NSX 노드 {node_display_or_host_name}의 애플리케이션에서 충돌이 발생했습니다. 발견된 코어 파일 수는 {core_dump_count}입니다. 코어 덤프 파일을 포함한 지원 번들을 수집하고 VMware 지원 팀에 문의하십시오. "

이벤트가 해결된 경우: "모든 코어 덤프 파일이 시스템에서 취소됩니다. "

NSX Manager UI 또는 API를 사용하여 NSX 노드 {node_display_or_host_name}에 대한 지원 번들을 수집합니다. 참고로, 노드에서 로컬 복사본을 제거하거나 보존하기 위해 NSX 기술 지원 번들로 이동하거나 복사하도록 코어 덤프를 설정할 수 있습니다. 코어 덤프 파일이 포함된 지원 번들 복사본은 VMware 지원 팀이 문제를 해결하는 데 필수적입니다. 시스템에서 코어 덤프 파일을 제거하기 전에 코어 덤프 파일을 포함한 최신 기술 지원 번들 복사본을 저장하는 것이 가장 좋습니다. 자세한 내용은 KB 문서를 참조하십시오.

전송 노드가 해당 Intelligence 노드의 메시징 브로커에서 연결이 끊어졌습니다. 데이터 수집이 영향을 받습니다.

이벤트가 감지된 경우: "전송 노드 {entity_id}의 흐름 내보내기가 Intelligence 노드의 메시징 브로커에서 연결이 끊어졌습니다. 데이터 수집이 영향을 받습니다. "

이벤트가 해결된 경우: "전송 노드 {entity_id}의 흐름 내보내기가 Intelligence 노드의 메시징 브로커에 다시 연결되었습니다. "

메시징 서비스가 Intelligence 노드에서 실행되고 있지 않은 경우 다시 시작합니다. 전송 노드 흐름 내보내기와 Intelligence 노드 간의 네트워크 연결 실패를 해결합니다.

Intelligence 노드 CPU 사용량이 매우 높습니다.

이벤트가 감지된 경우: "Intelligence 노드 {intelligence_node_id}의 CPU 사용량이 매우 높은 임계값 {system_usage_threshold}%를 초과합니다. "

이벤트가 해결된 경우: "Intelligence 노드 {intelligence_node_id}의 CPU 사용량이 매우 높은 임계값 {system_usage_threshold}% 미만입니다. "

top 명령을 사용하여 CPU 사용량이 가장 많은 프로세스를 확인한 다음, /var/log/syslog 및 이러한 프로세스의 로컬 로그를 확인하여 해결되지 않은 오류가 있는지 확인합니다.

Intelligence 노드 CPU 사용량이 높습니다.

이벤트가 감지된 경우: "Intelligence 노드 {intelligence_node_id}의 CPU 사용량이 높은 임계값 {system_usage_threshold}%를 초과합니다. "

이벤트가 해결된 경우: "Intelligence 노드 {intelligence_node_id}의 CPU 사용량이 높은 임계값 {system_usage_threshold}% 미만입니다. "

top 명령을 사용하여 CPU 사용량이 가장 많은 프로세스를 확인한 다음, /var/log/syslog 및 이러한 프로세스의 로컬 로그를 확인하여 해결되지 않은 오류가 있는지 확인합니다.

Intelligence 노드 메모리 사용량이 매우 높습니다.

이벤트가 감지된 경우: "Intelligence 노드 {intelligence_node_id}의 메모리 사용량이 매우 높은 임계값 {system_usage_threshold}%를 초과합니다. "

이벤트가 해결된 경우: "Intelligence 노드 {intelligence_node_id}의 메모리 사용량이 매우 높은 임계값 {system_usage_threshold}% 미만입니다. "

top 명령을 사용하여 메모리 사용량이 가장 많은 프로세스를 확인한 다음, /var/log/syslog 및 이러한 프로세스의 로컬 로그를 확인하여 해결되지 않은 오류가 있는지 확인합니다.

Intelligence 노드 메모리 사용량이 높습니다.

이벤트가 감지된 경우: "Intelligence 노드 {intelligence_node_id}의 메모리 사용량이 높은 임계값 {system_usage_threshold}%를 초과합니다. "

이벤트가 해결된 경우: "Intelligence 노드 {intelligence_node_id}의 메모리 사용량이 높은 임계값 {system_usage_threshold}% 미만입니다. "

top 명령을 사용하여 메모리 사용량이 가장 많은 프로세스를 확인한 다음, /var/log/syslog 및 이러한 프로세스의 로컬 로그를 확인하여 해결되지 않은 오류가 있는지 확인합니다.

Intelligence 노드 디스크 사용량이 매우 높습니다.

이벤트가 감지된 경우: "Intelligence 노드 {intelligence_node_id}에서 디스크 파티션 {disk_partition_name}의 디스크 사용량이 매우 높은 임계값 {system_usage_threshold}%를 초과합니다. "

이벤트가 해결된 경우: "Intelligence 노드 {intelligence_node_id}에서 디스크 파티션 {disk_partition_name}의 디스크 사용량이 매우 높은 임계값 {system_usage_threshold}% 미만입니다. "

디스크 파티션 {disk_partition_name}을(를) 검사하고 제거할 수 있는 예기치 않은 큰 파일이 있는지 확인합니다.

Intelligence 노드 디스크 사용량이 높습니다.

이벤트가 감지된 경우: "Intelligence 노드 {intelligence_node_id}에서 디스크 파티션 {disk_partition_name}의 디스크 사용량이 높은 임계값 {system_usage_threshold}%를 초과합니다. "

이벤트가 해결된 경우: "Intelligence 노드 {intelligence_node_id}에서 디스크 파티션 {disk_partition_name}의 디스크 사용량이 높은 임계값 {system_usage_threshold}% 미만입니다. "

디스크 파티션 {disk_partition_name}을(를) 검사하고 제거할 수 있는 예기치 않은 큰 파일이 있는지 확인합니다.

Intelligence 노드 데이터 디스크 파티션 사용량이 매우 높습니다.

이벤트가 감지된 경우: "Intelligence 노드 {intelligence_node_id}에서 디스크 파티션 /data의 디스크 사용량이 매우 높은 임계값 {system_usage_threshold}%를 초과합니다. "

이벤트가 해결된 경우: "Intelligence 노드 {intelligence_node_id}에서 디스크 파티션 /data의 디스크 사용량이 매우 높은 임계값 {system_usage_threshold}% 미만입니다. "

디스크 사용량이 임계값보다 낮아질 때까지 NSX intelligence 데이터 수집을 중지합니다. NSX UI에서 [시스템] | [장치] | [NSX Intelligence 장치]로 이동합니다. 그런 다음, [작업]을 클릭하고 데이터 수집을 중지합니다.

Intelligence 노드 데이터 디스크 파티션 사용량이 높습니다.

이벤트가 감지된 경우: "Intelligence 노드 {intelligence_node_id}에서 디스크 파티션 /data의 디스크 사용량이 높은 임계값 {system_usage_threshold}%를 초과합니다. "

이벤트가 해결된 경우: "Intelligence 노드 {intelligence_node_id}에서 디스크 파티션 /data의 디스크 사용량이 높은 임계값 {system_usage_threshold}% 미만입니다. "

디스크 사용량이 임계값보다 낮아질 때까지 NSX intelligence 데이터 수집을 중지합니다. 디스크 파티션 /data를 검사하고 제거할 수 있는 예기치 않은 큰 파일이 있는지 확인합니다.

Intelligence 노드 스토리지 지연 시간이 높습니다.

이벤트가 감지된 경우: "Intelligence 노드 {intelligence_node_id}에서 디스크 파티션 {disk_partition_name}의 스토리지 지연 시간이 높은 임계값 {system_usage_threshold}밀리초를 초과합니다. "

이벤트가 해결된 경우: "Intelligence 노드 {intelligence_node_id}에서 디스크 파티션 {disk_partition_name}의 스토리지 지연 시간이 높은 임계값 {system_usage_threshold}밀리초 미만입니다. "

I/O 요청의 폭발적 증가로 인해 일시적으로 높은 스토리지 지연 시간이 발생할 수 있습니다. 스토리지 지연 시간이 30분 넘게 높게 유지되는 경우에는 NSX Intelligence 장치를 낮은 지연 시간 디스크에 배포하거나 동일한 스토리지 디바이스를 다른 VM과 공유하지 않는 것이 좋습니다.

Intelligence 노드 상태가 저하됨입니다.

이벤트가 감지된 경우: "Intelligence 노드 {intelligence_node_id} 상태가 성능 저하됨입니다. "

이벤트가 해결된 경우: "Intelligence 노드 {intelligence_node_id}이(가) 제대로 실행되고 있습니다. "

NSX API GET /napp/api/v1/platform/monitor/category/health를 호출하여 종료된 특정 포드와 그 이유를 확인합니다. CLI 명령 kubectl rollout restart &ltstatefulset/deployment&gt &ltservice_name&gt -n &ltnamespace&gt를 호출하여 성능이 저하된 서비스를 다시 시작합니다.

IP 블록 사용량이 매우 높습니다.

이벤트가 감지된 경우: "{intent_path}의 IP 블록 사용량이 매우 높습니다. IP 블록이 총 용량에 거의 가까워지고 있으며 IP 블록을 사용하는 서브넷 생성이 실패할 수 있습니다. "

이벤트가 해결된 경우: "{intent_path}의 IP 블록 사용량이 임계값 수준 미만입니다. "

IP 블록 사용량을 검토합니다. 리소스 생성을 위해 새 IP 블록을 사용하거나 사용하지 않는 IP 서브넷을 IP 블록에서 삭제합니다. IP 블록에 사용되는 서브넷을 확인하려면 다음을 수행합니다. NSX UI에서 [네트워킹] | [IP 주소 풀] | [IP 주소 풀] 탭으로 이동합니다. IP 블록이 사용되고 있는 IP 풀을 선택하고 UI에서 [서브넷 및 할당된 IP] 열을 선택합니다. IP 풀에 대해 할당이 사용되지 않으며 향후 사용하지 않을 예정이면 서브넷 또는 IP 풀을 삭제합니다. 다음 API를 사용하여 IP 풀에서 IP 블록을 사용하고 있는지 확인하고 IP 할당이 완료되었는지도 확인합니다. IP 풀의 구성된 서브넷을 가져오려면 NSX API GET /policy/api/v1/infra/ip-pools/&ltip-pool&gt/ip-subnets를 호출합니다. IP 할당을 가져오려면 NSX API GET /policy/api/v1/infra/ip-pools/&ltip-pool&gt/ip-allocations를 호출합니다. 참고: 할당된 IP가 없고 향후 사용할 계획이 없는 IP 풀/서브넷만 삭제해야 합니다.

IP 풀 사용량이 매우 높습니다.

이벤트가 감지된 경우: "{intent_path}의 IP 풀 사용량이 매우 높습니다. IP 풀이 총 용량에 가까워지고 있습니다. 엔티티/서비스의 생성은 IP 풀에서 할당되는 IP에 따라 다를 수 있습니다. "

이벤트가 해결된 경우: "이제 IP 풀 사용량 {intent_path}이(가) 정상입니다. "

IP 풀 사용량을 검토합니다. 사용되지 않는 IP 할당을 IP 풀에서 해제하거나 새 IP 풀을 생성한 후 이를 사용할 수 있습니다. NSX UI에서 [네트워킹] | [IP 주소 풀] | [IP 주소 풀] 탭으로 이동합니다. IP 풀을 선택하고 [할당된 IP] 열을 확인합니다. 여기에는 IP 풀에서 할당된 IP가 표시됩니다. 어떤 IP도 사용되고 있지 않은 것으로 나타나면 해당 IP를 해제할 수 있습니다. 사용하지 않은 IP를 해제하려면 다음을 호출합니다. NSX API DELETE /policy/api/v1/infra/ip-pools/&ltip-pool&gt/ip-allocations/&ltip-allocation&gt

라이센스가 만료되었습니다.

이벤트가 감지된 경우: "{displayed_license_key}(으)로 끝나는 {license_edition_type} 라이센스 키가 만료되었습니다. "

이벤트가 해결된 경우: "{displayed_license_key}(으)로 끝나는 만료된 {license_edition_type} 라이센스 키가 제거 또는 업데이트되었거나 더 이상 만료될 예정이 아닙니다. "

[시스템] | [라이센스]로 이동한 후 [추가]를 클릭하여 NSX UI를 사용하여 만료되지 않은 새 라이센스를 추가하고 새 라이센스의 키를 지정합니다. 라이센스의 확인란을 선택하고 [삭제]를 클릭하여 만료된 라이센스를 삭제해야 합니다.

라이센스가 곧 만료됩니다.

이벤트가 감지된 경우: "{displayed_license_key}(으)로 끝나는 {license_edition_type} 라이센스 키가 곧 만료됩니다. "

이벤트가 해결된 경우: "{displayed_license_key}(으)로 끝나는 만료될 {license_edition_type} 라이센스 키가 제거 또는 업데이트되었거나 더 이상 만료될 예정이 아닙니다. "

며칠 후에 라이센스가 만료될 예정입니다. [시스템] | [라이센스]로 이동한 후 [추가]를 클릭하여 NSX UI를 사용하여 만료될 예정이 아닌 새 라이센스를 추가하고 새 라이센스의 키를 지정합니다. 라이센스의 확인란을 선택하고 [삭제]를 클릭하여 만료된 라이센스를 삭제해야 합니다.

로드 밸런서 CPU 사용량이 매우 높습니다.

이벤트가 감지된 경우: "로드 밸런서 {entity_id}의 CPU 사용량이 매우 높습니다. 임계값은 {system_usage_threshold}%입니다. "

이벤트가 해결된 경우: "로드 밸런서 {entity_id}의 CPU 사용량이 충분히 낮습니다. 임계값은 {system_usage_threshold}%입니다. "

로드 밸런서 CPU 활용률이 시스템 사용량 임계값보다 높은 경우 이 로드 밸런서에 비해 워크로드가 너무 높은 것입니다. 로드 밸런서 크기를 소형에서 중형으로 또는 중형에서 대형으로 변경하여 로드 밸런서 서비스의 크기를 다시 조정합니다. 이 로드 밸런서의 CPU 활용률이 여전히 높은 경우에는 해당 워크로드에 대한 Edge 장치 폼 팩터 크기를 조정하거나 로드 밸런서 서비스를 다른 Edge 노드로 이동하는 것이 좋습니다.

로드 밸런서 서비스가 성능 저하됨 상태입니다.

이벤트가 감지된 경우: "로드 밸런서 서비스 {entity_id}이(가) 성능 저하됨 상태입니다. "

이벤트가 해결된 경우: "로드 밸런서 서비스 {entity_id}이(가) 성능 저하됨 상태가 아닙니다. "

중앙 집중식 로드 밸런서의 경우: 성능 저하됨 상태는 대기 Edge 노드의 로드 밸런서 상태가 준비되지 않은 것을 의미하므로 대기 Edge 노드에서 로드 밸런서 상태를 확인합니다. 대기 Edge 노드에서 NSX CLI 명령 get load-balancer &ltlb-uuid&gt status를 호출합니다. 로드 밸런서 서비스의 LB-State가 not_ready이거나 출력이 없는 경우 Edge 노드를 유지 보수 모드로 전환했다가 유지 보수 모드를 종료합니다. 분산 로드 밸런서:
1. NSX API GET /policy/api/v1/infra/lb-services/&ltLBService&gt/detailed-status?source=realtime을 호출하여 자세한 상태를 확인합니다.
2. API 출력에서 상태가 준비되지 않음 또는 충돌인 0이 아닌 instance_number를 보고하는 ESXi 호스트를 찾습니다.
3. ESXi 호스트 노드에서 NSX CLI 명령 `get load-balancer &ltlb-uuid&gt status`를 호출합니다. ‘충돌하는 LSP’가 보고되는 경우 이 LSP가 다른 로드 밸런서 서비스에 연결되어 있는지를 확인합니다. 이 충돌이 허용 가능한지 여부를 확인합니다. ‘준비되지 않은 LSP’가 보고되면 NSX CLI 명령 get logical-switch-port status를 호출하여 이 LSP의 상태를 확인합니다. 참고: 성능 저하됨 상태가 일시적 상태일 수 있으므로 5분 안에 자동으로 해결할 수 있는 경우 경보를 무시하십시오.

분산 로드 밸런서 서비스가 종료되었습니다.

이벤트가 감지된 경우: "분산 로드 밸런서 서비스 {entity_id}이(가) 종료되었습니다. "

이벤트가 해결된 경우: "분산 로드 밸런서 서비스 {entity_id}이(가) 실행 중입니다. "

ESXi 호스트 노드에서 NSX CLI 명령 `get load-balancer &ltlb-uuid&gt status`를 호출합니다. ‘충돌하는 LSP’가 보고되는 경우 이 LSP가 다른 로드 밸런서 서비스에 연결되어 있는지를 확인합니다. 이 충돌이 허용 가능한지 여부를 확인합니다. ‘준비되지 않은 LSP’가 보고되면 NSX CLI 명령 get logical-switch-port status를 호출하여 이 LSP의 상태를 확인합니다.

중앙 로드 밸런서 서비스가 종료되었습니다.

이벤트가 감지된 경우: "중앙 로드 밸런서 서비스 {entity_id}이(가) 종료되었습니다. "

이벤트가 해결된 경우: "중앙 로드 밸런서 서비스 {entity_id}이(가) 실행 중입니다. "

활성 Edge 노드에서 NSX CLI 명령 get load-balancer &ltlb-uuid&gt status를 호출하여 로드 밸런서 상태를 검사합니다. 로드 밸런서 서비스의 LB-State가 not_ready이거나 출력이 없는 경우 Edge 노드를 유지 보수 모드로 전환했다가 유지 보수 모드를 종료합니다.

로드 밸런서 가상 서비스가 종료되었습니다.

이벤트가 감지된 경우: "로드 밸런서 가상 서버 {entity_id}이(가) 종료되었습니다. "

이벤트가 해결된 경우: "로드 밸런서 가상 서버 {entity_id}이(가) 실행 중입니다. "

로드 밸런서 풀을 참조하여 상태를 확인하고 해당 구성을 검토합니다. 잘못 구성된 경우 재구성하고 가상 서버에서 로드 밸런서 풀을 제거한 다음, 가상 서버에 다시 추가합니다.

로드 밸런서 풀이 종료되었습니다.

이벤트가 감지된 경우: "로드 밸런서 풀 {entity_id} 상태가 종료입니다. "

이벤트가 해결된 경우: "로드 밸런서 풀 {entity_id} 상태가 실행 중입니다."

로드 밸런서 풀을 참조하여 NSX CLI 명령 get load-balancer &ltlb-uuid&gt pool &ltpool-uuid&gt status 또는 NSX API GET /policy/api/v1/infra/lb-services/&ltlb-service-id&gt/lb-pools/&ltlb-pool-id&gt/detailed-status를 호출하여 종료된 멤버를 확인합니다. 종료 또는 알 수 없음이 보고되는 경우 풀 멤버를 확인하십시오. 로드 밸런서에서 영향을 받는 풀 멤버로의 네트워크 연결을 확인합니다. 각 풀 멤버의 애플리케이션 상태를 확인합니다. 또한 구성된 모니터를 사용하여 각 풀 멤버의 상태를 확인합니다. 멤버의 상태가 설정되면 모니터의 ‘상승 카운트’ 구성에 따라 풀 멤버 상태가 정상으로 업데이트됩니다. 풀 멤버를 재부팅하거나 Edge 노드를 유지 보수 모드로 전환한 다음, 유지 보수 모드를 종료하여 문제를 해결합니다.

로드 밸런서 사용량이 많습니다.

이벤트가 감지된 경우: "Edge 노드 {entity_id}의 로드 밸런서 서비스 사용량이 높습니다. 임계값은 {system_usage_threshold}%입니다. "

이벤트가 해결된 경우: "Edge 노드 {entity_id}의 로드 밸런서 서비스 사용량이 충분히 낮습니다. 임계값은 {system_usage_threshold}%입니다. "

이 Edge 노드에 여러 LB 인스턴스가 구성된 경우 새 Edge 노드를 배포하고 일부 LB 인스턴스를 해당 새 Edge 노드로 이동합니다. 동일한 크기(소형/중형/기타)의 Edge 노드에 단일 LB 인스턴스(소형/중형/기타)만 구성된 경우 더 큰 크기의 새 Edge를 배포하고 LB 인스턴스를 새 Edge 노드로 이동합니다.

로드 밸런서 풀 멤버 사용량이 매우 많습니다.

이벤트가 감지된 경우: "Edge 노드 {entity_id}의 풀 멤버 사용량이 매우 높습니다. 임계값은 {system_usage_threshold}%입니다. "

이벤트가 해결된 경우: "Edge 노드 {entity_id}의 풀 멤버 사용량이 충분히 낮습니다. 임계값은 {system_usage_threshold}%입니다. "

새 Edge 노드를 배포하고 기존 Edge 노드의 로드 밸런서 서비스를 새로 배포한 Edge 노드로 이동합니다.

Edge 노드의 메모리 사용량이 높기 때문에 로드 밸런서 구성이 인식되지 않습니다.

이벤트가 감지된 경우: "Edge 노드 {transport_node_id}의 메모리 사용량이 높기 때문에 로드 밸런서 구성 {entity_id}이(가) 인식되지 않습니다. "

이벤트가 해결된 경우: "로드 밸런서 구성 {entity_id}이(가) {transport_node_id}에서 인식되지 않습니다. "

대형 로드 밸런서보다 소형 및 중형 로드 밸런서를 정의하는 것이 좋습니다. 사용 가능한 Edge 노드 간에 로드 밸런서 서비스를 분산합니다. 정의된 가상 서버 수를 줄입니다.

서비스 상태가 종료입니다.

이벤트가 감지된 경우: "서비스 {mps_service_name}이(가) {transport_node_name}에서 실행되고 있지 않습니다. "

이벤트가 해결된 경우: "서비스 {mps_service_name}이(가) {transport_node_name}에서 올바르게 실행되고 있습니다. "

1. {nsx_edge_tn_name}(으)로 식별된 Edge 노드에서 NSX CLI get services를 호출하여 {mps_service_name}의 상태를 확인합니다. /var/log/syslog를 검사하여 의심스러운 오류를 찾습니다.
2. {nsx_esx_tn_name}(으)로 식별된 호스트 노드에서 연결된 맬웨어 차단 서비스 VM {entity_id}에 로그인하고 {mps_service_name}의 상태를 확인합니다. 연결된 맬웨어 차단 서비스 VM {entity_id}에서 /var/log/syslog를 검사하여 의심스러운 오류를 찾습니다.

서비스 상태가 성능 저하됨입니다.

이벤트가 감지된 경우: "서비스 {mps_service_name}이(가) {transport_node_name}에서 성능이 저하됩니다. 파일 추출 기능과 통신할 수 없습니다. {transport_node_name}에서 모든 파일 추출 기능이 일시 중지됩니다. "

이벤트가 해결된 경우: "서비스 {mps_service_name}이(가) {transport_node_name}에서 올바르게 실행되고 있습니다. "

1. {nsx_edge_tn_name}(으)로 식별된 Edge 노드에서 NSX CLI get ids engine status를 호출하여 file_extraction(IDS) 서비스의 상태를 확인합니다. /var/log/syslog를 검사하여 파일 추출(IDS) 서비스 및/또는 {mps_service_name}에 대한 의심스러운 오류를 찾습니다.
2. {nsx_esx_tn_name}(으)로 식별된 호스트 노드에서 연결된 맬웨어 차단 서비스 VM {entity_id}에 로그인하고 파일 추출(NXGI) 서비스의 상태를 확인합니다. 연결된 맬웨어 차단 서비스 VM {entity_id}에서 /var/log/syslog를 검사하여 의심스러운 오류를 찾습니다.

서비스 상태가 성능 저하됨입니다.

이벤트가 감지된 경우: "서비스 {mps_service_name}이(가) NSX Application Platform에서 성능이 저하됩니다. 맬웨어 차단 데이터베이스와 통신할 수 없습니다. "

이벤트가 해결된 경우: "서비스 {mps_service_name}이(가) NSX Application Platform에서 올바르게 실행되고 있습니다. "

NSX UI에서 [시스템] | [NSX Application Platform] | [핵심 서비스]로 이동하여 성능 저하된 서비스를 확인합니다. NSX API GET /napp/api/v1/platform/monitor/feature/health를 호출하여 종료된 특정 서비스와 그 이유를 확인합니다. CLI 명령 kubectl rollout restart &ltstatefulset/deployment&gt &ltservice_name&gt -n &ltnamespace&gt를 호출하여 성능이 저하된 서비스를 다시 시작합니다. 맬웨어 차단 데이터베이스 서비스의 상태를 확인합니다.

서비스 상태가 성능 저하됨입니다.

이벤트가 감지된 경우: "서비스 {mps_service_name}이(가) NSX Application Platform에서 성능이 저하됩니다. analyst_api 서비스와 통신할 수 없습니다. 검사된 파일 결과가 최신이 아닐 수 있습니다. "

이벤트가 해결된 경우: "서비스 {mps_service_name}이(가) NSX Application Platform에서 올바르게 실행되고 있습니다. "

NSX UI에서 [시스템] | [NSX Application Platform] | [핵심 서비스]로 이동하여 성능 저하된 서비스를 확인합니다. NSX API GET /napp/api/v1/platform/monitor/feature/health를 호출하여 종료된 특정 서비스와 그 이유를 확인합니다. CLI 명령 kubectl rollout restart &ltstatefulset/deployment&gt &ltservice_name&gt -n &ltnamespace&gt를 호출하여 성능이 저하된 서비스를 다시 시작합니다. 맬웨어 차단 Cloud Connector 서비스의 상태를 확인합니다.

서비스 상태가 성능 저하됨입니다.

이벤트가 감지된 경우: "서비스 {mps_service_name}이(가) NSX Application Platform에서 성능이 저하됩니다. NTICS 신뢰도 서비스와 통신할 수 없습니다. 검사된 파일 신뢰도가 최신이 아닐 수 있습니다. "

이벤트가 해결된 경우: "서비스 {mps_service_name}이(가) NSX Application Platform에서 올바르게 실행되고 있습니다. "

NSX UI에서 [시스템] | [NSX Application Platform] | [핵심 서비스]로 이동하여 성능 저하된 서비스를 확인합니다. NSX API GET /napp/api/v1/platform/monitor/feature/health를 호출하여 종료된 특정 서비스와 그 이유를 확인합니다. CLI 명령 kubectl rollout restart &ltstatefulset/deployment&gt &ltservice_name&gt -n &ltnamespace&gt를 호출하여 성능이 저하된 서비스를 다시 시작합니다. NTICS 서비스에 대한 액세스가 종료되는지 확인합니다.

관리자 노드 CPU 사용량이 매우 높습니다.

이벤트가 감지된 경우: "관리자 노드 {entity_id}의 CPU 사용량이 {system_resource_usage}%에 도달했으며, 이것은 매우 높은 임계값 {system_usage_threshold}% 이상입니다. "

이벤트가 해결된 경우: "관리자 노드 {entity_id}의 CPU 사용량이 {system_resource_usage}%에 도달했으며, 이것은 매우 높은 임계값 {system_usage_threshold}% 미만입니다. "

이 관리자 노드의 구성, 실행 중인 서비스 및 크기 조정을 검토하십시오. 관리자 장치 폼 팩터 크기를 조정하는 것이 좋습니다.

관리자 노드 CPU 사용량이 높습니다.

이벤트가 감지된 경우: "관리자 노드 {entity_id}의 CPU 사용량이 {system_resource_usage}%에 도달했으며, 이것은 높은 임계값 {system_usage_threshold}% 이상입니다. "

이벤트가 해결된 경우: "관리자 노드 {entity_id}의 CPU 사용량이 {system_resource_usage}%에 도달했으며, 이것은 높은 임계값 {system_usage_threshold}% 미만입니다. "

이 관리자 노드의 구성, 실행 중인 서비스 및 크기 조정을 검토하십시오. 관리자 장치 폼 팩터 크기를 조정하는 것이 좋습니다.

관리자 노드 메모리 사용량이 매우 높습니다.

이벤트가 감지된 경우: "관리자 노드 {entity_id}의 메모리 사용량이 {system_resource_usage}%에 도달했으며, 이것은 매우 높은 임계값 {system_usage_threshold}% 이상입니다. "

이벤트가 해결된 경우: "관리자 노드 {entity_id}의 메모리 사용량이 {system_resource_usage}%에 도달했으며, 이것은 매우 높은 임계값 {system_usage_threshold}% 미만입니다. "

이 관리자 노드의 구성, 실행 중인 서비스 및 크기 조정을 검토하십시오. 관리자 장치 폼 팩터 크기를 조정하는 것이 좋습니다.

관리자 노드 메모리 사용량이 높습니다.

이벤트가 감지된 경우: "관리자노드 {entity_id}의 메모리 사용량이 {system_resource_usage}%에 도달했으며, 이것은 높은 임계값 {system_usage_threshold}% 이상입니다. "

이벤트가 해결된 경우: "관리자 노드 {entity_id}의 메모리 사용량이 {system_resource_usage}%에 도달했으며, 이것은 높은 임계값 {system_usage_threshold}% 미만입니다. "

이 관리자 노드의 구성, 실행 중인 서비스 및 크기 조정을 검토하십시오. 관리자 장치 폼 팩터 크기를 조정하는 것이 좋습니다.

관리자 노드 디스크 사용량이 매우 높습니다.

이벤트가 감지된 경우: "관리자 노드의 디스크 파티션 {disk_partition_name}의 디스크 사용량이 {system_resource_usage}%에 도달했으며, 이것은 매우 높은 임계값 {system_usage_threshold}% 이상입니다. "

이벤트가 해결된 경우: "관리자 노드의 디스크 파티션 {disk_partition_name}의 디스크 사용량이 {system_resource_usage}%에 도달했으며, 이것은 매우 높은 임계값 {system_usage_threshold}% 미만입니다. "

사용량이 많은 파티션을 검사하고 제거할 수 있는 예기치 않은 큰 파일이 있는지 확인합니다.

관리자 노드 디스크 사용량이 높습니다.

이벤트가 감지된 경우: "관리자 노드의 디스크 파티션 {disk_partition_name}의 디스크 사용량이 {system_resource_usage}%에 도달했으며, 이것은 높은 임계값 {system_usage_threshold}% 이상입니다. "

이벤트가 해결된 경우: "관리자 노드의 디스크 파티션 {disk_partition_name}의 디스크 사용량이 {system_resource_usage}%에 도달했으며, 이것은 높은 임계값 {system_usage_threshold}% 미만입니다. "

사용량이 많은 파티션을 검사하고 제거할 수 있는 예기치 않은 큰 파일이 있는지 확인합니다.

관리자 노드 구성 디스크 사용량이 매우 높습니다.

이벤트가 감지된 경우: "관리자 노드의 디스크 파티션 /config의 디스크 사용량이 {system_resource_usage}%에 도달했으며, 이것은 매우 높은 임계값 {system_usage_threshold}% 이상입니다. 이것은 /config/corfu 디렉토리 아래의 NSX 데이터스토어 서비스의 디스크 사용량이 매우 높음을 나타낼 수 있습니다. "

이벤트가 해결된 경우: "관리자 노드의 디스크 파티션 /config의 디스크 사용량이 {system_resource_usage}%에 도달했으며, 이것은 매우 높은 임계값 {system_usage_threshold}% 미만입니다. "

/opt/vmware/tools/support/inspect_checkpoint_issues.py에서 보고된 문제가 있는 경우 다음 도구를 실행하고 GSS에 문의하십시오.

관리자 노드 구성 디스크 사용량이 높습니다.

이벤트가 감지된 경우: "관리자 노드의 디스크 파티션 /config의 디스크 사용량이 {system_resource_usage}%에 도달했으며, 이것은 높은 임계값 {system_usage_threshold}% 이상입니다. 이것은 /config/corfu 디렉토리 아래의 NSX 데이터스토어 서비스의 디스크 사용량이 증가하고 있음을 나타낼 수 있습니다. "

이벤트가 해결된 경우: "관리자 노드의 디스크 파티션 /config의 디스크 사용량이 {system_resource_usage}%에 도달했으며, 이것은 높은 임계값 {system_usage_threshold}% 미만입니다. "

/opt/vmware/tools/support/inspect_checkpoint_issues.py에서 보고된 문제가 있는 경우 다음 도구를 실행하고 GSS에 문의하십시오.

관리자 노드 구성 디스크 사용량이 매우 높습니다.

이벤트가 감지된 경우: "관리자 노드의 디스크 파티션 /nonconfig의 디스크 사용량이 {system_resource_usage}%에 도달했으며, 이것은 매우 높은 임계값 {system_usage_threshold}% 이상입니다. 이것은 /nonconfig/corfu 디렉토리 아래의 NSX 데이터스토어 서비스의 디스크 사용량이 매우 높음을 나타낼 수 있습니다. "

이벤트가 해결된 경우: "관리자 노드의 디스크 파티션 /nonconfig의 디스크 사용량이 {system_resource_usage}%에 도달했으며, 이것은 매우 높은 임계값 {system_usage_threshold}% 미만입니다. "

/opt/vmware/tools/support/inspect_checkpoint_issues.py --nonconfig에서 보고된 문제가 있는 경우 다음 도구를 실행하고 GSS에 문의하십시오.

관리자 노드 구성 디스크 사용량이 높습니다.

이벤트가 감지된 경우: "관리자 노드의 디스크 파티션 /nonconfig의 디스크 사용량이 {system_resource_usage}%에 도달했으며, 이것은 매우 임계값 {system_usage_threshold}% 이상입니다. 이것은 /nonconfig/corfu 디렉토리 아래의 NSX 데이터스토어 서비스의 디스크 사용량이 증가하고 있음을 나타낼 수 있습니다. "

이벤트가 해결된 경우: "관리자 노드의 디스크 파티션 /nonconfig의 디스크 사용량이 {system_resource_usage}%에 도달했으며, 이것은 높은 임계값 {system_usage_threshold}% 미만입니다. "

/opt/vmware/tools/support/inspect_checkpoint_issues.py --nonconfig에서 보고된 문제가 있는 경우 다음 도구를 실행하고 GSS에 문의하십시오.

관리자 노드의 IP 주소를 다른 디바이스에서 사용하고 있습니다.

이벤트가 감지된 경우: "Manager node {entity_id} IP 주소 {duplicate_ip_address}이(가) 현재 네트워크의 다른 디바이스에서 사용되고 있습니다. "

이벤트가 해결된 경우: "관리자 노드 {entity_id}에 할당된 IP 주소를 사용하는 디바이스가 더 이상 {duplicate_ip_address}을(를) 사용하지 않는 것 같습니다. "

1. 관리자의 IP 주소를 사용하는 디바이스를 확인하고 디바이스에 새 IP 주소를 할당합니다. 참고: 새 IP 주소를 사용하도록 관리자를 재구성하는 것은 지원되지 않습니다.
2. 고정 IP 주소 풀/DHCP 서버가 올바르게 구성되었는지 확인합니다.
3. 수동으로 할당된 디바이스의 IP 주소를 수정합니다.

관리자 노드 디스크는 읽기 전용입니다.

이벤트가 감지된 경우: "관리자 노드 {entity_id}의 다음 디스크 파티션이 읽기 전용 모드입니다: {disk_partition_name} "

이벤트가 해결된 경우: "관리자 노드 {entity_id}의 다음 디스크 파티션이 읽기 전용 모드에서 복구되었습니다: {disk_partition_name} "

읽기 전용 파티션을 검토하여 재부팅으로 문제가 해결되었는지 또는 디스크를 교체해야 하는지 확인합니다. 자세한 내용은 GSS에 문의하십시오.

관리자 FQDN에 대한 DNS 항목이 없습니다.

이벤트가 감지된 경우: "관리자 노드 {manager_node_name}({entity_id})에 대한 DNS 구성이 잘못되었습니다. 관리자 노드가 이중 스택이거나 CA 서명된 API 인증서가 사용되었지만 관리자 노드의 IP 주소가 FQDN으로 확인되지 않거나 다른 FQDN으로 확인되었습니다. "

이벤트가 해결된 경우: "관리자 노드 {manager_node_name}({entity_id})에 대한 DNS 구성이 올바릅니다. 관리자 노드가 이중 스택이 아니며 CA 서명된 API 인증서가 더 이상 사용되지 않거나 관리자 노드의 IP 주소가 동일한 FQDN으로 확인되었습니다. "

1. 관리자 노드에 적절한 DNS 서버가 구성되어 있는지 확인합니다.
2. DNS 서버에 관리자 노드의 IP 주소를 역방향으로 조회하면 동일한 FQDN이 반환되고, FQDN을 정방향으로 조회하면 관리자 노드의 모든 IP 주소가 반환되도록 적절한 A 레코드 및 PTR 레코드가 구성되어 있는지 확인합니다.
3. 또는 관리자 노드가 이중 스택이 아닌 경우 API 서비스 유형에 대한 CA 서명된 인증서를 자체 서명된 인증서로 바꿉니다.

관리자 VIP에 대한 FQDN 항목이 누락되었습니다.

이벤트가 감지된 경우: "NSX Manager에 대한 이중 스택 또는 CA 서명된 API 인증서의 경우 관리자 노드 {entity_id}에 대한 가상 IPv4 주소 {ipv4_address} 및 가상 IPv6 주소 {ipv6_address}이(가) 동일한 FQDN으로 확인되어야 합니다. "

이벤트가 해결된 경우: "관리자 노드 {entity_id}에 대한 이중 스택 VIP 주소가 동일한 FQDN으로 확인되었습니다. "

VIP 주소에 대한 DNS 항목을 검토하여 동일한 FQDN으로 확인되는지 알아봅니다.

동일한 전송 영역에 연결된 전송 노드 간에 MTU 구성이 일치하지 않습니다.

이벤트가 감지된 경우: "동일한 전송 영역에 연결된 전송 노드(ESXi, KVM 및 Edge) 간에 MTU 구성이 일치하지 않습니다. 동일한 전송 영역에 연결된 모든 스위치의 MTU 값이 일관되지 않으므로 연결 문제가 발생합니다. "

이벤트가 해결된 경우: "동일한 전송 영역에 연결된 전송 노드 간의 모든 MTU 값이 이제 일치합니다. "

1. NSX UI에서 [시스템] | [패브릭] | [설정] | [MTU 구성 확인] | [불일치]로 이동하여 불일치 세부 정보를 확인합니다.
2. 요청 본문에서 mtu와 함께 NSX API PUT /api/v1/host-switch-profiles/&lthost-switch-profile-id&gt를 호출하거나 요청 본문에서 physical_uplink_mtu와 함께 API PUT /api/v1/global-configs/SwitchingGlobalConfig를 호출하여 동일한 전송 영역에 연결된 모든 스위치에 대해 동일한 MTU 값을 설정합니다.

글로벌 라우터 MTU 구성이 오버레이 전송 영역의 MTU보다 큽니다.

이벤트가 감지된 경우: "글로벌 라우터 MTU 구성이 Tier0 또는 Tier1에 연결되는 오버레이 전송 영역의 스위치 MTU보다 큽니다. Geneve 캡슐화에 100 할당량이 필요하므로 글로벌 라우터 MTU 값은 모든 스위치 MTU 값보다 적어도 100 이상 작아야 합니다. "

이벤트가 해결된 경우: "이제 글로벌 라우터 MTU가 오버레이 전송 영역의 MTU보다 작습니다. "

1. NSX UI에서 [시스템] | [패브릭] | [설정] | [MTU 구성 확인] | [불일치]로 이동하여 불일치 세부 정보를 확인합니다.
2. 요청 본문에서 mtu와 함께 NSX API PUT /api/v1/host-switch-profiles/&lthost-switch-profile-id&gt를 호출하거나 요청 본문에서 physical_uplink_mtu와 함께 API PUT /api/v1/global-configs/SwitchingGlobalConfig를 호출하여 스위치에 대해 더 큰 MTU 값을 설정합니다.
3. 또는 요청 본문에서 logical_uplink_mtu와 함께 NSX API PUT /api/v1/global-configs/RoutingGlobalConfig를 호출하여 글로벌 라우터 구성의 더 작은 MTU 값을 설정합니다.

게이트웨이의 SNAT 포트 사용량이 높습니다.

이벤트가 감지된 경우: "SNAT IP {snat_ip_address}에 대한 논리적 라우터 {entity_id}의 SNAT 포트 사용량이 높은 임계값 {system_usage_threshold}%에 도달했습니다. 사용량이 최대 제한에 도달하면 새 흐름이 SNAT되지 않습니다. "

이벤트가 해결된 경우: "SNAT IP {snat_ip_address}에 대한 논리적 라우터 {entity_id}의 SNAT 포트 사용량이 높은 임계값 {system_usage_threshold}% 미만입니다. "

Edge 노드에서 admin 사용자로 로그인하고 적절한 인터페이스 uuid를 사용하여 NSX CLI 명령 get firewall &ltLR_INT_UUID&gt connection state를 호출한 후 SNAT IP {snat_ip_address}에 대한 다양한 SNAT 매핑을 확인합니다. 게이트웨이를 통과하는 트래픽 흐름이 서비스 거부 공격 또는 변칙 버스트가 아닌지 검사합니다. 트래픽이 정상 로드 내에 있는 것으로 나타나지만 경보 임계값에 도달한 경우 SNAT IP 주소를 더 추가하여 로드를 분산하거나 새 트래픽을 다른 Edge 노드로 라우팅하는 것이 좋습니다.

관리자 노드에서 NCP가 종료되었거나 비정상 상태임을 감지했습니다.

이벤트가 감지된 경우: "관리자 노드에서 NCP가 종료되었거나 비정상 상태임을 감지했습니다. "

이벤트가 해결된 경우: "관리자 노드에서 NCP가 다시 실행 중 또는 정상 상태임을 감지했습니다. "

문제가 있는 클러스터를 찾으려면 NSX UI를 사용하고 [경보] 페이지로 이동하십시오. 이 경보 인스턴스의 엔티티 이름 값은 클러스터 이름을 식별합니다. 또는 NSX API GET /api/v1/systemhealth/container-cluster/ncp/status를 호출하여 모든 클러스터 상태를 가져오고, 종료 또는 알 수 없음을 보고하는 클러스터의 이름을 확인합니다. 그런 다음, NSX UI [인벤토리] | [컨테이너] | [클러스터] 페이지에서 이름으로 클러스터를 찾고 모든 Kubernetes 및 PAS 클러스터 멤버가 나열된 [노드] 탭을 클릭합니다. Kubernetes 클러스터의 경우:
1. 모든 클러스터 멤버에서 K8s 마스터 노드를 찾아 마스터 노드에 로그인한 후 NCP 포드 작동 여부를 확인합니다. 그런 다음, kubectl 명령 kubectl get pods --all-namespaces를 호출합니다. NCP 포드에 문제가 있는 경우 kubectl logs 명령을 사용하여 문제를 확인하고 오류를 수정하십시오.
2. NCP와 Kubernetes API 서버 간의 연결을 확인합니다. NCP 포드 내에서 NSX CLI를 사용하고 마스터 VM에서 kubectl exec -it &ltNCP-Pod-Name&gt -n nsx-system bash nsxcli get ncp-k8s-api-server status 명령을 호출하여 이 연결 상태를 확인합니다. 연결에 문제가 있는 경우 네트워크 및 NCP 구성을 모두 확인하십시오.
3. NCP와 NSX Manager 사이의 연결을 확인합니다. NCP 포드 내에서 NSX CLI를 사용하고 마스터 VM에서 kubectl exec -it &ltNCP-Pod-Name&gt -n nsx-system bash nsxcli get ncp-nsx status 명령을 호출하여 이 연결 상태를 확인합니다. 연결에 문제가 있는 경우 네트워크 및 NCP 구성을 모두 확인하십시오. PAS 클러스터의 경우:
1. 가상 시스템 간 네트워크 연결을 확인하고 네트워크 문제를 수정합니다.
2. 노드 및 서비스의 상태를 확인하고 충돌하는 노드 또는 서비스를 수정합니다. bosh vms 및 bosh instances -p 명령을 호출하여 노드 및 서비스의 상태를 확인합니다.

노드 VM 내부에서 실행 중인 에이전트가 DPU에서 종료된 듯합니다.

이벤트가 감지된 경우: "노드 VM 내부에서 실행 중인 에이전트가 DPU {dpu_id}에서 종료된 듯합니다. "

이벤트가 해결된 경우: "노드 VM 내부의 에이전트에서 DPU {dpu_id}에서 실행 중입니다. "

1. DPU {dpu_id}에서 Vmk50이 누락된 경우 기술 자료 문서 https://kb.vmware.com/s/article/67432를 참조하십시오.
2. DPU {dpu_id}에서 Hyperbus 4094가 누락된 경우 DPU {dpu_id}에서 nsx-cfgagent를 다시 시작하거나 컨테이너 호스트 VM을 다시 시작하면 도움이 될 수 있습니다.
3. 컨테이너 호스트 VIF가 차단된 경우 컨트롤러에 대한 연결을 확인하고 모든 구성이 전송되었는지 확인합니다.
4. DPU {dpu_id}에서 nsx-cfg-agent가 중지된 경우 DPU {dpu_id}에서 nsx-cfgagent를 다시 시작합니다.
5. node-agent 패키지가 누락된 경우 node-agent 패키지가 컨테이너 호스트 VM에 성공적으로 설치되었는지 확인합니다.
6. 컨테이너 호스트 VM의 node-agent에 대한 인터페이스가 종료된 경우 컨테이너 호스트 VM 내부의 eth1 인터페이스 상태를 확인합니다.

노드 VM 내에서 실행 중인 에이전트가 종료된 것 같습니다.

이벤트가 감지된 경우: "노드 VM 내에서 실행 중인 에이전트가 종료된 것 같습니다. "

이벤트가 해결된 경우: "노드 VM 내의 에이전트가 실행되고 있습니다. "

ESX의 경우:
1. Vmk50이 누락된 경우 기술 자료 문서 https://kb.vmware.com/s/article/67432를 참조하십시오.
2. Hyperbus 4094가 누락된 경우 nsx-cfgagent를 다시 시작하거나 컨테이너 호스트 VM을 다시 시작하면 도움이 될 수 있습니다.
3. 컨테이너 호스트 VIF가 차단된 경우 컨트롤러에 대한 연결을 확인하고 모든 구성이 전송되었는지 확인합니다.
4. nsx-cfg-agent가 중지된 경우 nsx-cfgagent를 다시 시작합니다. KVM의 경우:
1. Hyperbus 네임스페이스가 누락된 경우 nsx-opsagent를 다시 시작하여 네임스페이스를 쉽게 재생성할 수 있습니다.
2. Hyperbus 네임스페이스 내에 Hyperbus 인터페이스가 없으면 nsx-opsagent를 다시 시작하는 것이 도움이 될 수 있습니다.
3. nsx-agent가 중지된 경우 nsx-agent를 다시 시작합니다. ESX 및 KVM의 경우:
1. node-agent 패키지가 누락된 경우 node-agent 패키지가 컨테이너 호스트 VM에 성공적으로 설치되었는지 확인합니다.
2. 컨테이너 호스트 VM의 node-agent에 대한 인터페이스가 종료된 경우 컨테이너 호스트 VM 내부의 eth1 인터페이스 상태를 확인합니다.

NSX Application Platform 클러스터와 NSX 관리 클러스터의 연결이 끊겼습니다.

이벤트가 감지된 경우: "NSX Application Platform 클러스터 {napp_cluster_id}과(와) NSX 관리 클러스터의 연결이 끊겼습니다. "

이벤트가 해결된 경우: "NSX Application Platform 클러스터 {napp_cluster_id}이(가) NSX 관리 클러스터에 다시 연결되었습니다. "

관리자 클러스터 인증서, 관리자 노드 인증서, kafka 인증서 및 수신 인증서가 NSX Manager 및 NSX Application Platform 클러스터 둘 다에서 일치하는지 확인합니다. 위에 언급된 인증서의 만료 날짜를 확인하여 인증서가 유효한지 검사합니다. NSX Manager 및 NSX Application Platform 클러스터 간의 네트워크 연결을 확인하고 네트워크 연결 실패를 해결하십시오.

메시징 항목 Raw Flow에서 느린 데이터 처리가 감지되었습니다.

이벤트가 감지된 경우: "메시징 항목 Raw Flow의 보류 중인 메시지 수가 보류 중인 메시지 임계값인 {napp_messaging_lag_threshold}을(를) 초과합니다. "

이벤트가 해결된 경우: "메시징 항목 Raw Flow의 보류 중인 메시지 수가 보류 중인 메시지 임계값인 {napp_messaging_lag_threshold} 미만입니다. "

노드를 추가한 다음, 애플리케이션 NSX Application Platform 클러스터를 수직 확장합니다. 병목 현상이 특정 서비스(예: 분석 서비스)로 인해 발생할 수 있는 경우 새 노드를 추가할 때 특정 서비스를 수직 확장하십시오.

메시징 항목 Over Flow에서 느린 데이터 처리가 감지되었습니다.

이벤트가 감지된 경우: "메시징 항목 Over Flow의 보류 중인 메시지 수가 보류 중인 메시지 임계값인 {napp_messaging_lag_threshold}을(를) 초과합니다. "

이벤트가 해결된 경우: "메시징 항목 Over Flow의 보류 중인 메시지 수가 보류 중인 메시지 임계값인 {napp_messaging_lag_threshold} 미만입니다. "

노드를 추가한 다음, 애플리케이션 NSX Application Platform 클러스터를 수직 확장합니다. 병목 현상이 특정 서비스(예: 분석 서비스)로 인해 발생할 수 있는 경우 새 노드를 추가할 때 특정 서비스를 수직 확장하십시오.

전송 노드가 해당 NSX Application Platform 클러스터의 메시징 브로커에서 연결 해제되었습니다. 데이터 수집이 영향을 받습니다.

이벤트가 감지된 경우: "전송 노드 {entity_id}의 흐름 내보내기와 NSX Application Platform 클러스터의 메시징 브로커 간의 연결이 해제되었습니다. 데이터 수집이 영향을 받습니다. "

이벤트가 해결된 경우: "전송 노드 {entity_id}의 흐름 내보내기가 NSX Application Platform 클러스터의 메시징 브로커에 다시 연결되었습니다. "

메시징 서비스가 NSX Application Platform 클러스터에서 실행되고 있지 않으면 다시 시작합니다. 전송 노드 흐름 내보내기와 NSX Application Platform 클러스터 간의 네트워크 연결 실패를 해결합니다.

전송 노드가 해당 Intelligence 노드의 메시징 브로커에서 연결이 끊어졌습니다. DPU에서 데이터 수집이 영향을 받습니다.

이벤트가 감지된 경우: "전송 노드 {entity_id} DPU {dpu_id}의 흐름 내보내기가 Intelligence 노드의 메시징 브로커에서 연결이 끊어졌습니다. 데이터 수집이 영향을 받습니다. "

이벤트가 해결된 경우: "전송 노드 {entity_id} DPU {dpu_id}의 흐름 내보내기가 Intelligence 노드의 메시징 브로커에 다시 연결되었습니다. "

메시징 서비스가 Intelligence 노드에서 실행되고 있지 않은 경우 다시 시작합니다. 전송 노드 흐름 내보내기와 Intelligence 노드 간의 네트워크 연결 실패를 해결합니다.

NSX Application Platform 클러스터 CPU 사용량이 매우 높습니다.

이벤트가 감지된 경우: "NSX Application Platform 클러스터 {napp_cluster_id}의 CPU 사용량이 매우 높은 임계값 {system_usage_threshold}%를 초과합니다. "

이벤트가 해결된 경우: "NSX Application Platform 클러스터 {napp_cluster_id}의 CPU 사용량이 매우 높은 임계값 {system_usage_threshold}% 미만입니다. "

NSX UI에서 [시스템] | [NSX Application Platform] | [핵심 서비스]로 이동한 후 개별 서비스의 [시스템 로드] 필드를 확인하여 메모리가 부족한 서비스를 확인할 수 있습니다. 로드를 줄일 수 있는지 여부를 확인합니다. 더 많은 계산 성능이 필요한 경우 [확장] 버튼을 클릭하여 더 많은 리소스를 요청하십시오.

NSX Application Platform 클러스터 CPU 사용량이 높습니다.

이벤트가 감지된 경우: "NSX Application Platform 클러스터 {napp_cluster_id}의 CPU 사용량이 높은 임계값 {system_usage_threshold}%를 초과합니다. "

이벤트가 해결된 경우: "NSX Application Platform 클러스터 {napp_cluster_id}의 CPU 사용량이 높은 임계값 {system_usage_threshold}% 미만입니다. "

NSX UI에서 [시스템] | [NSX Application Platform] | [핵심 서비스]로 이동한 후 개별 서비스의 [시스템 로드] 필드를 확인하여 메모리가 부족한 서비스를 확인할 수 있습니다. 로드를 줄일 수 있는지 여부를 확인합니다. 더 많은 계산 성능이 필요한 경우 [확장] 버튼을 클릭하여 더 많은 리소스를 요청하십시오.

NSX Application Platform 클러스터 메모리 사용량이 매우 높습니다.

이벤트가 감지된 경우: "NSX Application Platform 클러스터 {napp_cluster_id}의 메모리 사용량이 매우 높은 임계값 {system_usage_threshold}%를 초과합니다. "

이벤트가 해결된 경우: "NSX Application Platform 클러스터 {napp_cluster_id}의 메모리 사용량이 매우 높은 임계값 {system_usage_threshold}% 미만입니다. "

NSX UI에서 [시스템] | [NSX Application Platform] | [핵심 서비스]로 이동한 후 개별 서비스의 [메모리] 필드를 확인하여 메모리가 부족한 서비스를 확인할 수 있습니다. 로드를 줄일 수 있는지 여부를 확인합니다. 더 많은 메모리가 필요한 경우 [확장] 버튼을 클릭하여 더 많은 리소스를 요청하십시오.

NSX Application Platform 클러스터 메모리 사용량이 높습니다.

이벤트가 감지된 경우: "NSX Application Platform 클러스터 {napp_cluster_id}의 메모리 사용량이 높은 임계값 {system_usage_threshold}%를 초과합니다. "

이벤트가 해결된 경우: "NSX Application Platform 클러스터 {napp_cluster_id}의 메모리 사용량이 높은 임계값 {system_usage_threshold}% 미만입니다. "

NSX UI에서 [시스템] | [NSX Application Platform] | [핵심 서비스]로 이동한 후 개별 서비스의 [메모리] 필드를 확인하여 메모리가 부족한 서비스를 확인할 수 있습니다. 로드를 줄일 수 있는지 여부를 확인합니다. 더 많은 메모리가 필요한 경우 [확장] 버튼을 클릭하여 더 많은 리소스를 요청하십시오.

NSX Application Platform 클러스터 디스크 사용량이 매우 높습니다.

이벤트가 감지된 경우: "NSX Application Platform 클러스터 {napp_cluster_id}의 디스크 사용량이 매우 높은 임계값 {system_usage_threshold}%를 초과합니다. "

이벤트가 해결된 경우: "NSX Application Platform 클러스터 {napp_cluster_id}의 디스크 사용량이 매우 높은 임계값 {system_usage_threshold}% 미만입니다. "

NSX UI에서 [시스템] | [NSX Application Platform] | [핵심 서비스]로 이동한 후 개별 서비스의 [스토리지] 필드를 확인하여 메모리가 부족한 서비스를 확인할 수 있습니다. 로드를 줄일 수 있는지 여부를 확인합니다. 더 많은 디스크 스토리지가 필요한 경우 [확장] 버튼을 클릭하여 더 많은 리소스를 요청하십시오. Data Storage 서비스의 메모리가 부족한 경우 다른 방법은 [수직 확장] 버튼을 클릭하여 디스크 크기를 늘리는 것입니다.

NSX Application Platform 클러스터 디스크 사용량이 높습니다.

이벤트가 감지된 경우: "NSX Application Platform 클러스터 {napp_cluster_id}의 디스크 사용량이 높은 임계값 {system_usage_threshold}%를 초과합니다. "

이벤트가 해결된 경우: "NSX Application Platform 클러스터 {napp_cluster_id}의 디스크 사용량이 높은 임계값 {system_usage_threshold}% 미만입니다. "

NSX UI에서 [시스템] | [NSX Application Platform] | [핵심 서비스]로 이동한 후 개별 서비스의 [스토리지] 필드를 확인하여 메모리가 부족한 서비스를 확인할 수 있습니다. 로드를 줄일 수 있는지 여부를 확인합니다. 더 많은 디스크 스토리지가 필요한 경우 [확장] 버튼을 클릭하여 더 많은 리소스를 요청하십시오. Data Storage 서비스의 메모리가 부족한 경우 다른 방법은 [수직 확장] 버튼을 클릭하여 디스크 크기를 늘리는 것입니다.

NSX Application Platform 클러스터 전체 상태가 성능 저하됨입니다.

이벤트가 감지된 경우: NSX Application Platform 클러스터 {napp_cluster_id} 전체 상태가 성능 저하됨입니다. "

이벤트가 해결된 경우: "NSX Application Platform 클러스터 {napp_cluster_id}이(가) 제대로 실행되고 있습니다. "

노드 및 서비스의 경보에서 추가 정보를 확인합니다.

NSX Application Platform 클러스터 전체 상태가 종료입니다.

이벤트가 감지된 경우: "NSX Application Platform 클러스터 {napp_cluster_id} 전체 상태가 종료입니다. "

이벤트가 해결된 경우: "NSX Application Platform 클러스터 {napp_cluster_id}이(가) 제대로 실행되고 있습니다. "

노드 및 서비스의 경보에서 추가 정보를 확인합니다.

NSX Application Platform 노드 CPU 사용량이 매우 높습니다.

이벤트가 감지된 경우: "NSX Application Platform 노드 {napp_node_name}의 CPU 사용량이 매우 높은 임계값 {system_usage_threshold}%를 초과합니다. "

이벤트가 해결된 경우: "NSX Application Platform 노드 {napp_node_name}의 CPU 사용량이 매우 높은 임계값 {system_usage_threshold}% 미만입니다. "

NSX UI에서 [시스템] | [NSX Application Platform] | [핵심 서비스]로 이동한 후 개별 서비스의 [시스템 로드] 필드를 확인하여 메모리가 부족한 서비스를 확인할 수 있습니다. 로드를 줄일 수 있는지 여부를 확인합니다. 소수의 노드만 CPU 사용량이 높을 경우 기본적으로 Kubernetes는 서비스를 자동으로 다시 스케줄링합니다. 대부분의 노드의 CPU 사용량이 높고 로드를 줄일 수 없는 경우 [확장] 버튼을 클릭하여 더 많은 리소스를 요청합니다.

NSX Application Platform 노드 CPU 사용량이 높습니다.

이벤트가 감지된 경우: "NSX Application Platform 노드 {napp_node_name}의 CPU 사용량이 높은 임계값 {system_usage_threshold}%를 초과합니다. "

이벤트가 해결된 경우: "NSX Application Platform 노드 {napp_node_name}의 CPU 사용량이 높은 임계값 {system_usage_threshold}% 미만입니다. "

NSX UI에서 [시스템] | [NSX Application Platform] | [핵심 서비스]로 이동한 후 개별 서비스의 [시스템 로드] 필드를 확인하여 메모리가 부족한 서비스를 확인할 수 있습니다. 로드를 줄일 수 있는지 여부를 확인합니다. 소수의 노드만 CPU 사용량이 높을 경우 기본적으로 Kubernetes는 서비스를 자동으로 다시 스케줄링합니다. 대부분의 노드의 CPU 사용량이 높고 로드를 줄일 수 없는 경우 [확장] 버튼을 클릭하여 더 많은 리소스를 요청합니다.

NSX Application Platform 노드 메모리 사용량이 매우 높습니다.

이벤트가 감지된 경우: "NSX Application Platform 노드 {napp_node_name}의 메모리 사용량이 매우 높은 임계값 {system_usage_threshold}%를 초과합니다. "

이벤트가 해결된 경우: "NSX Application Platform 노드 {napp_node_name}의 메모리 사용량이 매우 높은 임계값 {system_usage_threshold}% 미만입니다. "

NSX UI에서 [시스템] | [NSX Application Platform] | [핵심 서비스]로 이동한 후 개별 서비스의 [메모리] 필드를 확인하여 메모리가 부족한 서비스를 확인할 수 있습니다. 로드를 줄일 수 있는지 여부를 확인합니다. 소수의 노드만 메모리 사용량이 높을 경우 기본적으로 Kubernetes는 서비스를 자동으로 다시 스케줄링합니다. 대부분의 노드의 메모리 사용량이 높고 로드를 줄일 수 없는 경우 [확장] 버튼을 클릭하여 더 많은 리소스를 요청합니다.

NSX Application Platform 노드 메모리 사용량이 높습니다.

이벤트가 감지된 경우: "NSX Application Platform 노드 {napp_node_name}의 메모리 사용량이 높은 임계값 {system_usage_threshold}%를 초과합니다. "

이벤트가 해결된 경우: "NSX Application Platform 노드 {napp_node_name}의 메모리 사용량이 높은 임계값 {system_usage_threshold}% 미만입니다. "

NSX UI에서 [시스템] | [NSX Application Platform] | [핵심 서비스]로 이동한 후 개별 서비스의 [메모리] 필드를 확인하여 메모리가 부족한 서비스를 확인할 수 있습니다. 로드를 줄일 수 있는지 여부를 확인합니다. 소수의 노드만 메모리 사용량이 높을 경우 기본적으로 Kubernetes는 서비스를 자동으로 다시 스케줄링합니다. 대부분의 노드의 메모리 사용량이 높고 로드를 줄일 수 없는 경우 [확장] 버튼을 클릭하여 더 많은 리소스를 요청합니다.

NSX Application Platform 노드 디스크 사용량이 매우 높습니다.

이벤트가 감지된 경우: "NSX Application Platform 노드 {napp_node_name}의 디스크 사용량이 매우 높은 임계값 {system_usage_threshold}%를 초과합니다. "

이벤트가 해결된 경우: "NSX Application Platform 노드 {napp_node_name}의 디스크 사용량이 매우 높은 임계값 {system_usage_threshold}% 미만입니다. "

NSX UI에서 [시스템] | [NSX Application Platform] | [핵심 서비스]로 이동한 후 개별 서비스의 [스토리지] 필드를 확인하여 메모리가 부족한 서비스를 확인할 수 있습니다. 사용되지 않는 데이터나 로그를 정리하여 디스크 리소스를 확보하고 로드가 감소할 수 있는지 확인합니다. 더 많은 디스크 스토리지가 필요한 경우 메모리 부족 상태의 서비스를 확장합니다. Data Storage 서비스의 메모리가 부족한 경우 다른 방법은 [수직 확장] 버튼을 클릭하여 디스크 크기를 늘리는 것입니다.

NSX Application Platform 노드 디스크 사용량이 높습니다.

이벤트가 감지된 경우: "NSX Application Platform 노드 {napp_node_name}의 디스크 사용량이 높은 임계값 {system_usage_threshold}%를 초과합니다. "

이벤트가 해결된 경우: "NSX Application Platform 노드 {napp_node_name}의 디스크 사용량이 높은 임계값 {system_usage_threshold}% 미만입니다. "

NSX UI에서 [시스템] | [NSX Application Platform] | [핵심 서비스]로 이동한 후 개별 서비스의 [스토리지] 필드를 확인하여 메모리가 부족한 서비스를 확인할 수 있습니다. 사용되지 않는 데이터나 로그를 정리하여 디스크 리소스를 확보하고 로드가 감소할 수 있는지 확인합니다. 더 많은 디스크 스토리지가 필요한 경우 메모리 부족 상태의 서비스를 확장합니다. Data Storage 서비스의 메모리가 부족한 경우 다른 방법은 [수직 확장] 버튼을 클릭하여 디스크 크기를 늘리는 것입니다.

NSX Application Platform 노드 상태가 성능 저하됨입니다.

이벤트가 감지된 경우: "NSX Application Platform 노드 {napp_node_name} 상태가 성능 저하됨입니다. "

이벤트가 해결된 경우: "NSX Application Platform 노드 {napp_node_name}이(가) 정상적으로 실행되고 있습니다. "

NSX UI에서 [시스템] | [NSX Application Platform] | [리소스]로 이동하여 성능 저하된 노드를 확인합니다. 노드의 네트워크, 메모리 및 CPU 사용량을 확인합니다. 작업자 노드인 경우 노드를 재부팅합니다.

NSX Application Platform 노드 상태가 종료입니다.

이벤트가 감지된 경우: "NSX Application Platform 노드 {napp_node_name}이(가) 실행되고 있지 않습니다. "

이벤트가 해결된 경우: "NSX Application Platform 노드 {napp_node_name}이(가) 정상적으로 실행되고 있습니다. "

NSX UI에서 [시스템] | [NSX Application Platform] | [리소스]로 이동하여 종료된 노드를 확인합니다. 노드의 네트워크, 메모리 및 CPU 사용량을 확인합니다. 작업자 노드인 경우 노드를 재부팅합니다.

Data Storage 서비스 CPU 사용량이 매우 높습니다.

이벤트가 감지된 경우: "Data Storage 서비스의 CPU 사용량이 매우 높은 임계값인 {system_usage_threshold}%를 초과합니다. "

이벤트가 해결된 경우: "Data Storage 서비스의 CPU 사용량이 매우 높은 임계값인 {system_usage_threshold}% 미만입니다. "

모든 서비스 또는 Data Storage 서비스를 확장합니다.

Data Storage 서비스 CPU 사용량이 높습니다.

이벤트가 감지된 경우: "Data Storage 서비스의 CPU 사용량이 높은 임계값인 {system_usage_threshold}%를 초과합니다. "

이벤트가 해결된 경우: "Data Storage 서비스의 CPU 사용량이 높은 임계값인 {system_usage_threshold}% 미만입니다. "

모든 서비스 또는 Data Storage 서비스를 확장합니다.

Messaging 서비스 CPU 사용량이 매우 높습니다.

이벤트가 감지된 경우: "Messaging 서비스의 CPU 사용량이 매우 높은 임계값 {system_usage_threshold}%를 초과합니다. "

이벤트가 해결된 경우: "Messaging 서비스의 CPU 사용량이 매우 높은 임계값 {system_usage_threshold}% 미만입니다. "

모든 서비스 또는 Messaging 서비스를 확장합니다.

Messaging 서비스 CPU 사용량이 높습니다.

이벤트가 감지된 경우: "Messaging 서비스의 CPU 사용량이 높은 임계값 {system_usage_threshold}%를 초과합니다. "

이벤트가 해결된 경우: "Messaging 서비스의 CPU 사용량이 높은 임계값 {system_usage_threshold}% 미만입니다. "

모든 서비스 또는 Messaging 서비스를 확장합니다.

Configuration Database 서비스 CPU 사용량이 매우 높습니다.

이벤트가 감지된 경우: "Configuration Database 서비스의 CPU 사용량이 매우 높은 임계값인 {system_usage_threshold}%를 초과합니다. "

이벤트가 해결된 경우: "Configuration Database 서비스의 CPU 사용량이 매우 높은 임계값인 {system_usage_threshold}% 미만입니다. "

모든 서비스를 확장합니다.

Configuration Database 서비스 CPU 사용량이 높습니다.

이벤트가 감지된 경우: "Configuration Database 서비스의 CPU 사용량이 높은 임계값인 {system_usage_threshold}%를 초과합니다. "

이벤트가 해결된 경우: "Configuration Database 서비스의 CPU 사용량이 높은 임계값인 {system_usage_threshold}% 미만입니다. "

모든 서비스를 확장합니다.

메트릭 서비스 CPU 사용량이 매우 높습니다.

이벤트가 감지된 경우: "메트릭 서비스의 CPU 사용량이 매우 높은 임계값 {system_usage_threshold}%를 초과합니다. "

이벤트가 해결된 경우: "메트릭 서비스의 CPU 사용량이 매우 높은 임계값 {system_usage_threshold}% 미만입니다. "

모든 서비스를 확장합니다.

메트릭 서비스 CPU 사용량이 높습니다.

이벤트가 감지된 경우: "Metrics 서비스의 CPU 사용량이 높은 임계값 {system_usage_threshold}%를 초과합니다. "

이벤트가 해결된 경우: "Metrics 서비스의 CPU 사용량이 높은 임계값 {system_usage_threshold}% 미만입니다. "

모든 서비스를 확장합니다.

분석 서비스 CPU 사용량이 매우 높습니다.

이벤트가 감지된 경우: "Analytics 서비스의 CPU 사용량이 매우 높은 임계값 {system_usage_threshold}%를 초과합니다. "

이벤트가 해결된 경우: "Analytics 서비스의 CPU 사용량이 매우 높은 임계값 {system_usage_threshold}% 미만입니다. "

모든 서비스 또는 Analytics 서비스를 확장합니다.

분석 서비스 CPU 사용량이 높습니다.

이벤트가 감지된 경우: "Analytics 서비스의 CPU 사용량이 높은 임계값 {system_usage_threshold}%를 초과합니다. "

이벤트가 해결된 경우: "Analytics 서비스의 CPU 사용량이 높은 임계값 {system_usage_threshold}% 미만입니다. "

모든 서비스 또는 Analytics 서비스를 확장합니다.

Platform Services 서비스 CPU 사용량이 매우 높습니다.

이벤트가 감지된 경우: "Platform Services 서비스의 CPU 사용량이 매우 높은 임계값 {system_usage_threshold}%를 초과합니다. "

이벤트가 해결된 경우: "Platform Services 서비스의 CPU 사용량이 매우 높은 임계값 {system_usage_threshold}% 미만입니다. "

모든 서비스를 확장합니다.

Platform Services 서비스 CPU 사용량이 높습니다.

이벤트가 감지된 경우: "Platform Services 서비스의 CPU 사용량이 높은 임계값 {system_usage_threshold}%를 초과합니다. "

이벤트가 해결된 경우: "Platform Services 서비스의 CPU 사용량이 높은 임계값 {system_usage_threshold}% 미만입니다. "

모든 서비스를 확장합니다.

Data Storage 서비스 메모리 사용량이 매우 높습니다.

이벤트가 감지된 경우: "Data Storage 서비스의 메모리 사용량이 매우 높은 임계값인 {system_usage_threshold}%를 초과합니다. "

이벤트가 해결된 경우: "Data Storage 서비스의 메모리 사용량이 매우 높은 임계값인 {system_usage_threshold}% 미만입니다. "

모든 서비스 또는 Data Storage 서비스를 확장합니다.

Data Storage 서비스 메모리 사용량이 높습니다.

이벤트가 감지된 경우: "Data Storage 서비스의 메모리 사용량이 높은 임계값인 {system_usage_threshold}%를 초과합니다. "

이벤트가 해결된 경우: "Data Storage 서비스의 메모리 사용량이 높은 임계값인 {system_usage_threshold}% 미만입니다. "

모든 서비스 또는 Data Storage 서비스를 확장합니다.

Messaging 서비스 메모리 사용량이 매우 높습니다.

이벤트가 감지된 경우: "Messaging 서비스의 메모리 사용량이 매우 높은 임계값 {system_usage_threshold}%를 초과합니다. "

이벤트가 해결된 경우: "Messaging 서비스의 메모리 사용량이 매우 높은 임계값 {system_usage_threshold}% 미만입니다. "

모든 서비스 또는 Messaging 서비스를 확장합니다.

Messaging 서비스 메모리 사용량이 높습니다.

이벤트가 감지된 경우: "Messaging 서비스의 메모리 사용량이 높은 임계값 {system_usage_threshold}%를 초과합니다. "

이벤트가 해결된 경우: "Messaging 서비스의 메모리 사용량이 높은 임계값 {system_usage_threshold}% 미만입니다. "

모든 서비스 또는 Messaging 서비스를 확장합니다.

Configuration Database 서비스 메모리 사용량이 매우 높습니다.

이벤트가 감지된 경우: "Configuration Database 서비스의 메모리 사용량이 매우 높은 임계값인 {system_usage_threshold}%를 초과합니다. "

이벤트가 해결된 경우: "Configuration Database 서비스의 메모리 사용량이 매우 높은 임계값인 {system_usage_threshold}% 미만입니다. "

모든 서비스를 확장합니다.

Configuration Database 서비스 메모리 사용량이 많습니다.

이벤트가 감지된 경우: "Configuration Database 서비스의 메모리 사용량이 높은 임계값인 {system_usage_threshold}%를 초과합니다. "

이벤트가 해결된 경우: "Configuration Database 서비스의 메모리 사용량이 높은 임계값인 {system_usage_threshold}% 미만입니다. "

모든 서비스를 확장합니다.

메트릭 서비스 메모리 사용량이 매우 높습니다.

이벤트가 감지된 경우: "Metrics 서비스의 메모리 사용량이 매우 높은 임계값 {system_usage_threshold}%를 초과합니다. "

이벤트가 해결된 경우: "Metrics 서비스의 메모리 사용량이 매우 높은 임계값 {system_usage_threshold}% 미만입니다. "

모든 서비스를 확장합니다.

메트릭 서비스 메모리 사용량이 높습니다.

이벤트가 감지된 경우: "Metrics 서비스의 메모리 사용량이 높은 임계값 {system_usage_threshold}%를 초과합니다. "

이벤트가 해결된 경우: "Metrics 서비스의 메모리 사용량이 높은 임계값 {system_usage_threshold}% 미만입니다. "

모든 서비스를 확장합니다.

Analytics 서비스 메모리 사용량이 매우 높습니다.

이벤트가 감지된 경우: "Analytics 서비스의 메모리 사용량이 매우 높은 임계값 {system_usage_threshold}%를 초과합니다. "

이벤트가 해결된 경우: "Analytics 서비스의 메모리 사용량이 매우 높은 임계값 {system_usage_threshold}% 미만입니다. "

모든 서비스 또는 Analytics 서비스를 확장합니다.

분석 서비스 메모리 사용량이 높습니다.

이벤트가 감지된 경우: "Analytics 서비스의 메모리 사용량이 높은 임계값 {system_usage_threshold}%를 초과합니다. "

이벤트가 해결된 경우: "Analytics 서비스의 메모리 사용량이 높은 임계값 {system_usage_threshold}% 미만입니다. "

모든 서비스 또는 Analytics 서비스를 확장합니다.

Platform Services 서비스 메모리 사용량이 매우 높습니다.

이벤트가 감지된 경우: "Platform Services 서비스의 메모리 사용량이 매우 높은 임계값 {system_usage_threshold}%를 초과합니다. "

이벤트가 해결된 경우: "Platform Services 서비스의 메모리 사용량이 매우 높은 임계값 {system_usage_threshold}% 미만입니다. "

모든 서비스를 확장합니다.

Platform Services 서비스 메모리 사용량이 높습니다.

이벤트가 감지된 경우: "Platform Services 서비스의 메모리 사용량이 높은 임계값 {system_usage_threshold}%를 초과합니다. "

이벤트가 해결된 경우: "Platform Services 서비스의 메모리 사용량이 높은 임계값 {system_usage_threshold}% 미만입니다. "

모든 서비스를 확장합니다.

Data Storage 서비스 디스크 사용량이 매우 높습니다.

이벤트가 감지된 경우: "Data Storage 서비스의 디스크 사용량이 매우 높은 임계값인 {system_usage_threshold}%를 초과합니다. "

이벤트가 해결된 경우: "Data Storage 서비스의 디스크 사용량이 매우 높은 임계값인 {system_usage_threshold}% 미만입니다. "

Data Storage 서비스를 확장하거나 수직 확장합니다.

Data Storage 서비스 디스크 사용량이 높습니다.

이벤트가 감지된 경우: "Data Storage 서비스의 디스크 사용량이 높은 임계값인 {system_usage_threshold}%를 초과합니다. "

이벤트가 해결된 경우: "Data Storage 서비스의 디스크 사용량이 높은 임계값인 {system_usage_threshold}% 미만입니다. "

Data Storage 서비스를 확장하거나 수직 확장합니다.

Messaging 서비스 디스크 사용량이 매우 높습니다.

이벤트가 감지된 경우: "Messaging 서비스의 디스크 사용량이 매우 높은 임계값 {system_usage_threshold}%를 초과합니다. "

이벤트가 해결된 경우: "Messaging 서비스의 디스크 사용량이 매우 높은 임계값 {system_usage_threshold}% 미만입니다. "

필요하지 않은 파일을 정리합니다. 모든 서비스 또는 Messaging 서비스를 확장합니다.

Messaging 서비스 디스크 사용량이 높습니다.

이벤트가 감지된 경우: "Messaging 서비스의 디스크 사용량이 높은 임계값 {system_usage_threshold}%를 초과합니다. "

이벤트가 해결된 경우: "Messaging 서비스의 디스크 사용량이 높은 임계값 {system_usage_threshold}% 미만입니다. "

필요하지 않은 파일을 정리합니다. 모든 서비스 또는 Messaging 서비스를 확장합니다.

Configuration Database 서비스 디스크 사용량이 매우 높습니다.

이벤트가 감지된 경우: "Configuration Database 서비스의 디스크 사용량이 매우 높은 임계값인 {system_usage_threshold}%를 초과합니다. "

이벤트가 해결된 경우: "Configuration Database 서비스의 디스크 사용량이 매우 높은 임계값인 {system_usage_threshold}% 미만입니다. "

필요하지 않은 파일을 정리합니다. 모든 서비스를 확장합니다.

Configuration Database 서비스 디스크 사용량이 높습니다.

이벤트가 감지된 경우: "Configuration Database 서비스의 디스크 사용량이 높은 임계값인 {system_usage_threshold}%를 초과합니다. "

이벤트가 해결된 경우: "Configuration Database 서비스의 디스크 사용량이 높은 임계값인 {system_usage_threshold}% 미만입니다. "

필요하지 않은 파일을 정리합니다. 모든 서비스를 확장합니다.

메트릭 서비스 디스크 사용량이 매우 높습니다.

이벤트가 감지된 경우: "메트릭 서비스의 디스크 사용량이 매우 높은 임계값 {system_usage_threshold}%를 초과합니다. "

이벤트가 해결된 경우: "메트릭 서비스의 디스크 사용량이 매우 높은 임계값 {system_usage_threshold}% 미만입니다. "

필요하지 않은 파일을 정리합니다. 모든 서비스를 확장합니다.

메트릭 서비스 디스크 사용량이 높습니다.

이벤트가 감지된 경우: "메트릭 서비스의 디스크 사용량이 높은 임계값 {system_usage_threshold}%를 초과합니다. "

이벤트가 해결된 경우: "메트릭 서비스의 디스크 사용량이 높은 임계값 {system_usage_threshold}% 미만입니다. "

필요하지 않은 파일을 정리합니다. 모든 서비스를 확장합니다.

분석 서비스 디스크 사용량이 매우 높습니다.

이벤트가 감지된 경우: "분석 서비스의 디스크 사용량이 매우 높은 임계값 {system_usage_threshold}%를 초과합니다. "

이벤트가 해결된 경우: "분석 서비스의 디스크 사용량이 매우 높은 임계값 {system_usage_threshold}% 미만입니다. "

필요하지 않은 파일을 정리합니다. 모든 서비스 또는 Analytics 서비스를 확장합니다.

분석 서비스 디스크 사용량이 높습니다.

이벤트가 감지된 경우: "분석 서비스의 디스크 사용량이 높은 임계값 {system_usage_threshold}%를 초과합니다. "

이벤트가 해결된 경우: "분석 서비스의 디스크 사용량이 높은 임계값 {system_usage_threshold}% 미만입니다. "

필요하지 않은 파일을 정리합니다. 모든 서비스 또는 Analytics 서비스를 확장합니다.

Platform Services 서비스 디스크 사용량이 매우 높습니다.

이벤트가 감지된 경우: "Platform Services 서비스의 디스크 사용량이 매우 높은 임계값 {system_usage_threshold}%를 초과합니다. "

이벤트가 해결된 경우: "Platform Services 서비스의 디스크 사용량이 매우 높은 임계값 {system_usage_threshold}% 미만입니다. "

필요하지 않은 파일을 정리합니다. 모든 서비스를 확장합니다.

Platform Services 서비스 디스크 사용량이 높습니다.

이벤트가 감지된 경우: "Platform Services 서비스의 디스크 사용량이 높은 임계값 {system_usage_threshold}%를 초과합니다. "

이벤트가 해결된 경우: "Platform Services 서비스의 디스크 사용량이 높은 임계값 {system_usage_threshold}% 미만입니다. "

필요하지 않은 파일을 정리합니다. 모든 서비스를 확장합니다.

서비스 상태가 성능 저하됨입니다.

이벤트가 감지된 경우: "서비스 {napp_service_name} 상태가 성능 저하됨입니다. {napp_service_name}과(와) 연결된 포드가 모두 안정적이지는 않지만 서비스는 여전히 쿼럼에 연결할 수 있습니다. 이러한 불안정한 포드에 사용되는 리소스는 해제될 수 있습니다. "

이벤트가 해결된 경우: "서비스 {napp_service_name}이(가) 제대로 실행되고 있습니다. "

NSX UI에서 [시스템] | [NSX Application Platform] | [핵심 서비스]로 이동하여 성능 저하된 서비스를 확인합니다. NSX API GET /napp/api/v1/platform/monitor/feature/health를 호출하여 성능이 저하된 특정 서비스와 그 이유를 확인합니다. 필요한 경우 CLI 명령 kubectl rollout restart &ltstatefulset/deployment&gt &ltservice_name&gt -n &ltnamespace&gt를 호출하여 성능이 저하된 서비스를 다시 시작합니다. 성능이 저하된 서비스가 올바르게 작동할 수 있지만 성능이 최적화되지는 않습니다.

서비스 상태가 종료입니다.

이벤트가 감지된 경우: "서비스 {napp_service_name}이(가) 실행되고 있지 않습니다. "

이벤트가 해결된 경우: "서비스 {napp_service_name}이(가) 제대로 실행되고 있습니다. "

NSX UI에서 [시스템] | [NSX Application Platform] | [핵심 서비스]로 이동하여 성능 저하된 서비스를 확인합니다. NSX API GET /napp/api/v1/platform/monitor/feature/health를 호출하여 종료된 특정 서비스와 그 이유를 확인합니다. CLI 명령 kubectl rollout restart &ltstatefulset/deployment&gt &ltservice_name&gt -n &ltnamespace&gt를 호출하여 성능이 저하된 서비스를 다시 시작합니다.

서비스 성능이 저하되었습니다.

이벤트가 감지된 경우: "서비스 {nsxaas_service_name} 상태가 성능 저하됨입니다. 현재 상태에서는 서비스 효율성이 저하되어 고객 워크로드에 영향을 줄 수 있습니다. {service_down_reason} "

이벤트가 해결된 경우: "서비스 {nsxaas_service_name}이(가) 더 이상 성능 저하됨 상태가 아닙니다. "

서비스가 배포되고 상태 모니터링 서비스에서 추가 데이터가 캡처된 경우 서비스를 식별하는 경보 설명 데이터를 검토합니다. 또한 해당되는 경우 메트릭 서비스 또는 Wavefront에서 기록된 기간별 데이터를 검토합니다.

서비스가 종료되었습니다.

이벤트가 감지된 경우: "서비스 {nsxaas_service_name}이(가) 종료되었습니다. {service_down_reason} "

이벤트가 해결된 경우: "서비스 {nsxaas_service_name}을(를) 다시 사용할 수 있습니다. "

서비스가 배포되고 상태 모니터링 서비스에서 추가 데이터가 캡처된 경우 서비스를 식별하는 경보 설명 데이터를 검토합니다. 또한 해당되는 경우 메트릭 서비스 또는 Wavefront에서 기록된 기간별 데이터를 검토합니다.

사용자 암호가 만료되었습니다.

이벤트가 감지된 경우: "사용자 {username}의 암호가 만료되었습니다. "

이벤트가 해결된 경우: "사용자 {username}의 암호가 변경되었거나 더 이상 만료되지 않았거나 사용자가 더 이상 활성 상태가 아닙니다. "

시스템에 액세스하려면 사용자 {username}의 암호를 지금 변경해야 합니다. 예를 들어, 사용자에게 새 암호를 적용하려면 요청 본문에서 올바른 암호를 사용하여 다음 NSX API를 호출합니다. PUT /api/v1/node/users/&ltuserid&gt. 여기서 &ltuserid&gt는 사용자의 ID입니다. admin 사용자(&ltuserid&gt가 10,000) 암호가 만료된 경우 admin은 암호를 변경하기 위해 SSH(사용하도록 설정된 경우) 또는 콘솔을 통해 시스템에 로그인해야 합니다. 현재 만료된 암호를 입력하면 admin에게 새 암호를 입력하라는 메시지가 표시됩니다.

사용자 암호가 곧 만료됩니다.

이벤트가 감지된 경우: "사용자 {username}의 암호가 {password_expiration_days}일 후에 곧 만료됩니다. "

이벤트가 해결된 경우: "사용자 {username}의 암호가 변경되었거나 더 이상 만료되지 않았거나 사용자가 더 이상 활성 상태가 아닙니다. "

사용자 {username}의 암호가 즉시 변경되었는지 확인합니다. 예를 들어, 사용자에게 새 암호를 적용하려면 요청 본문에서 올바른 암호를 사용하여 다음 NSX API를 호출합니다. PUT /api/v1/node/users/&ltuserid&gt. 여기서 &ltuserid&gt는 사용자의 ID입니다.

사용자 암호가 곧 만료될 예정입니다.

이벤트가 감지된 경우: "사용자 {username}의 암호가 {password_expiration_days}일 후에 만료됩니다. "

이벤트가 해결된 경우: "사용자 {username}의 암호가 변경되었거나 더 이상 만료되지 않았거나 사용자가 더 이상 활성 상태가 아닙니다. "

사용자 {username}의 암호를 곧 변경해야 합니다. 예를 들어, 사용자에게 새 암호를 적용하려면 요청 본문에서 올바른 암호를 사용하여 다음 NSX API를 호출합니다. PUT /api/v1/node/users/&ltuserid&gt. 여기서 &ltuserid&gt는 사용자의 ID입니다.

물리적 서버(BMS) 설치에 실패했습니다.

이벤트가 감지된 경우: "물리적 서버 {transport_node_name}({entity_id}) 설치에 실패했습니다. "

이벤트가 해결된 경우: "물리적 서버 {transport_node_name}({entity_id}) 설치가 완료되었습니다. "

[시스템] > [패브릭] > [노드] > [호스트 전송 노드]로 이동하여 노드에서 오류를 해결하십시오.

물리적 서버(BMS) 업그레이드에 실패했습니다.

이벤트가 감지된 경우: "물리적 서버 {transport_node_name}({entity_id}) 업그레이드에 실패했습니다. "

이벤트가 해결된 경우: "물리적 서버 {transport_node_name}({entity_id}) 업그레이드가 완료되었습니다. "

[시스템] > [업그레이드]로 이동하여 오류를 해결한 다음, 업그레이드를 다시 트리거하십시오.

물리적 서버(BMS) 제거에 실패했습니다.

이벤트가 감지된 경우: "물리적 서버 {transport_node_name}({entity_id}) 제거에 실패했습니다. "

이벤트가 해결된 경우: "물리적 서버 {transport_node_name}({entity_id}) 제거가 완료되었습니다. "

[시스템] > [패브릭] > [노드] > [호스트 전송 노드]로 이동하여 노드에서 오류를 해결하십시오.

엔티티 수가 정책 제약 조건 제한에 도달했습니다.

이벤트가 감지된 경우: "{constraint_type_path}에서 {constraint_type} 유형의 엔티티 수가 현재 {current_count}에서 최대 제한인 {constraint_limit}개에 도달했습니다. "

이벤트가 해결된 경우: "{constraint_type} 개수가 임계값 미만입니다. "

{constraint_type} 사용량을 검토합니다. 제약 조건을 업데이트하여 제한을 늘리거나 사용되지 않은 {constraint_type}을(를) 삭제합니다.

BFD 세션이 종료되었습니다.

이벤트가 감지된 경우: "라우터 {lr_id}에서 피어 {peer_address}에 대한 BFD 세션이 종료되었습니다. "

이벤트가 해결된 경우: "라우터 {lr_id}에서 피어 {peer_address}에 대한 BFD 세션이 실행 중입니다. "

1. NSX CLI 명령 get logical-routers를 호출합니다.
2. service-router {sr_id}(으)로 전환합니다.
3. NSX CLI 명령 ping {peer_address}를 호출하여 연결을 확인합니다.

고정 경로가 제거되었습니다.

이벤트가 감지된 경우: "라우터 {lr_id}에서 BFD가 종료되었기 때문에 고정 경로 {entity_id}({static_address}) 이(가) 제거되었습니다. "

이벤트가 해결된 경우: "라우터 {lr_id}에서 BFD가 복구되었으므로 고정 경로 {entity_id}({static_address})이(가) 다시 추가되었습니다. "

BFD 세션이 종료되었기 때문에 고정 라우팅 항목이 제거되었습니다.
1. NSX CLI 명령 get logical-routers를 호출합니다.
2. service-router {sr_id}(으)로 전환합니다.
3. NSX CLI 명령 ping &ltBFD peer IP address&gt를 호출하여 연결을 확인합니다. 또한 NSX와 BFD 피어 모두의 구성을 확인하여 타이머가 변경되지 않았는지 확인합니다.

BGP 인접 네트워크가 종료되었습니다.

이벤트가 감지된 경우: "라우터 {lr_id}에서 BGP 인접 항목 {entity_id}({bgp_neighbor_ip})이(가) 종료되었습니다. 이유: {failure_reason}. "

이벤트가 해결된 경우: "라우터 {lr_id}에서 BGP 인접 항목 {entity_id}({bgp_neighbor_ip})이(가) 실행 중입니다. "

1. NSX CLI 명령 get logical-routers를 호출합니다.
2. service-router {sr_id}(으)로 전환합니다. 이유에 네트워크 또는 구성 오류가 표시된 경우 -
3. NSX CLI 명령 get bgp neighbor summary를 호출하여 BGP 인접 항목 상태를 확인합니다. Edge가 준비되지 않음으로 표시되는 경우 Edge 노드가 정상 상태가 아닌 이유를 확인합니다.
4. NSX CLI 명령 get edge-cluster status를 호출하여 Edge 노드가 종료된 이유를 확인합니다.
5. NSX CLI 명령 get bfd-config 및 get bfd-sessions를 호출하여 BFD가 잘 실행되고 있는지 확인합니다.
6. Edge 상태 관련 경보를 확인하여 자세한 내용을 확인합니다. /var/log/syslog 를 확인하여 BGP 연결과 관련된 오류가 있는지 확인합니다.

프록시 ARP가 서비스 IP에 대해 구성되지 않았습니다.

이벤트가 감지된 경우: "라우터 {lr_id}에서 lrport {lrport_id}의 서브넷과 서비스 IP가 겹치기 때문에 생성된 ARP 프록시 항목의 수가 허용되는 임계값 제한인 16384를 초과하기 때문에 서비스 IP {service_ip} 및 서비스 엔티티 {entity_id}에 대한 프록시 ARP가 구성되지 않습니다. "

이벤트가 해결된 경우: "라우터 {lr_id}에서 lrport {lrport_id}의 서브넷과 겹치는 서비스 IP가 허용되는 제한인 16384개 항목을 초과하지 않으므로 서비스 엔티티 {entity_id}에 대한 프록시 ARP가 생성됩니다. "

서비스 엔티티 {entity_id}에 대한 서비스 IP {service_ip}을(를) 재구성하거나, 서비스 IP와 lrport의 서브넷 간 겹침으로 인해 생성된 프록시 ARP 항목이 허용되는 임계값 제한인 16384보다 작게 유지되도록 라우터 {lr_id}에서 lrport {lrport_id}의 서브넷을 변경하십시오.

모든 BGP/BFD 세션이 종료되었습니다.

이벤트가 감지된 경우: "모든 BGP/BFD 세션이 종료되었습니다. "

이벤트가 해결된 경우: "하나 이상의 BGP/BFD 세션이 실행 중입니다. "

NSX CLI 명령 get logical-routers를 호출하여 Tier0 서비스 라우터를 가져오고 이 vrf로 전환한 후 다음 NSX CLI 명령을 호출합니다.
1. ping &ltBFD peer IP address&gt를 호출하여 연결을 확인합니다.
2. get bfd-config 및 get bfd-sessions를 호출하여 BFD가 잘 실행되고 있는지 확인합니다.
3. get bgp neighbor summary를 호출하여 BGP가 잘 실행되고 있는지 확인합니다. 또한 /var/log/syslog 를 확인하여 BGP 연결과 관련된 오류가 있는지 확인합니다.

OSPF 인접 네트워크가 전체에서 다른 상태로 전환되었습니다.

이벤트가 감지된 경우: "OSPF 인접 네트워크 {peer_address}이(가) 전체에서 다른 상태로 전환되었습니다. "

이벤트가 해결된 경우: "OSPF 인접 네트워크 {peer_address}이(가) 전체 상태로 전환되었습니다. "

1. NSX CLI 명령 get logical-routers를 호출하여 vrf ID를 가져오고 TIER0 서비스 라우터로 전환합니다.
2. get ospf neighbor를 실행하여 이 인접 네트워크의 현재 상태를 확인합니다. 인접 네트워크가 출력에 표시되지 않으면 인접 네트워크가 종료되었거나 네트워크에서 연결이 끊어집니다.
3. NSX CLI 명령 ping &ltOSPF neighbor IP address&gt를 호출하여 연결을 확인합니다.
4. 또한 NSX 및 피어 라우터 모두에 대한 구성을 확인하여 타이머 및 area-id가 일치하는지 확인합니다.
5. /var/log/syslog를 확인하여 연결과 관련된 오류가 있는지 알아봅니다.

Edge 노드에서 최대 IPv4 경로 제한이 가까워지고 있습니다.

이벤트가 감지된 경우: "IPv4 경로 제한이 Tier0 게이트웨이 및 Edge 노드 {edge_node}의 모든 Tier0 VRF에서 {route_limit_threshold}개에 도달했습니다. "

이벤트가 해결된 경우: "IPv4 경로가 Tier0 게이트웨이 및 Edge 노드 {edge_node}의 모든 Tier0 VRF에서 제한인 {route_limit_threshold}개 내에 있습니다. "

1. 경로 재배포 정책 및 모든 외부 피어에서 수신된 경로를 확인하십시오.
2. 이에 따라 라우팅 정책 및 필터를 적용하여 경로 수를 줄이는 것을 고려하십시오.

Edge 노드에서 최대 IPv6 경로 제한이 가까워지고 있습니다.

이벤트가 감지된 경우: "IPv6 경로 제한이 Tier0 게이트웨이 및 Edge 노드 {edge_node}의 모든 Tier0 VRF에서 {route_limit_threshold}개에 도달했습니다. "

이벤트가 해결된 경우: "IPv6 경로가 Tier0 게이트웨이 및 Edge 노드 {edge_node}의 모든 Tier0 VRF에서 제한인 {route_limit_threshold}개 내에 있습니다. "

1. 경로 재배포 정책 및 모든 외부 피어에서 수신된 경로를 확인하십시오.
2. 이에 따라 라우팅 정책 및 필터를 적용하여 경로 수를 줄이는 것을 고려하십시오.

Edge 노드에서 최대 IPv4 경로 제한을 초과했습니다.

이벤트가 감지된 경우: "IPv4 경로가 Tier0 게이트웨이 및 Edge 노드 {edge_node}의 모든 Tier0 VRF에서 제한인 {route_limit_maximum}개를 초과했습니다. "

이벤트가 해결된 경우: "IPv4 경로가 Tier0 게이트웨이 및 Edge 노드 {edge_node}의 모든 Tier0 VRF에서 제한인 {route_limit_maximum}개 내에 있습니다. "

1. 경로 재배포 정책 및 모든 외부 피어에서 수신된 경로를 확인하십시오.
2. 이에 따라 라우팅 정책 및 필터를 적용하여 경로 수를 줄이는 것을 고려하십시오.

Edge 노드에서 최대 IPv6 경로 제한을 초과했습니다.

이벤트가 감지된 경우: "IPv6 경로가 Tier0 게이트웨이 및 Edge 노드 {edge_node}의 모든 Tier0 VRF에서 제한인 {route_limit_maximum}개를 초과했습니다. "

이벤트가 해결된 경우: "IPv6 경로가 Tier0 게이트웨이 및 Edge 노드 {edge_node}의 모든 Tier0 VRF에서 제한인 {route_limit_maximum}개 내에 있습니다. "

1. 경로 재배포 정책 및 모든 외부 피어에서 수신된 경로를 확인하십시오.
2. 이에 따라 라우팅 정책 및 필터를 적용하여 경로 수를 줄이는 것을 고려하십시오.

BGP 인접 항목에서 수신된 최대 IPv4 접두사에 곧 도달합니다.

이벤트가 감지된 경우: "{bgp_neighbor_ip}에서 수신된 IPv4 {subsequent_address_family} 접두사 수가 {prefixes_count_threshold}에 도달했습니다. 이 피어에 대해 정의된 제한은 {prefixes_count_max}입니다. "

이벤트가 해결된 경우: "{bgp_neighbor_ip}에서 수신된 IPv4 {subsequent_address_family} 접두사 수가 한도인 {prefixes_count_threshold}개 내에 있습니다. "

1. 외부 라우터에서 BGP 라우팅 정책을 확인하십시오.
2. 외부 라우터에 라우팅 정책 및 필터를 적용하여 BGP 피어에서 보급하는 경로 수를 줄이는 것을 고려하십시오.
3. 필요한 경우 BGP 인접 항목 구성 섹션에서 최대 접두사 설정을 늘리십시오.

BGP 인접 항목에서 수신된 최대 IPv6 접두사에 곧 도달합니다.

이벤트가 감지된 경우: "{bgp_neighbor_ip}에서 수신된 IPv6 {subsequent_address_family} 접두사 수가 {prefixes_count_threshold}에 도달했습니다. 이 피어에 대해 정의된 제한은 {prefixes_count_max}입니다. "

이벤트가 해결된 경우: "{bgp_neighbor_ip}에서 수신된 IPv6 {subsequent_address_family} 접두사 수가 한도인 {prefixes_count_threshold}개 내에 있습니다. "

1. 외부 라우터에서 BGP 라우팅 정책을 확인하십시오.
2. 외부 라우터에 라우팅 정책 및 필터를 적용하여 BGP 피어에서 보급하는 경로 수를 줄이는 것을 고려하십시오.
3. 필요한 경우 BGP 인접 항목 구성 섹션에서 최대 접두사 설정을 늘리십시오.

BGP 인접 항목에서 수신된 최대 IPv4 접두사를 초과했습니다.

이벤트가 감지된 경우: "{bgp_neighbor_ip}에서 수신된 IPv4 {subsequent_address_family} 접두사 수가 이 피어의 한도인 {prefixes_count_max}개를 초과했습니다. "

이벤트가 해결된 경우: "{bgp_neighbor_ip}에서 수신된 IPv4 {subsequent_address_family} 접두사 수가 한도인 {prefixes_count_max}개 내에 있습니다. "

1. 외부 라우터에서 BGP 라우팅 정책을 확인하십시오.
2. 외부 라우터에 라우팅 정책 및 필터를 적용하여 BGP 피어에서 보급하는 경로 수를 줄이는 것을 고려하십시오.
3. 필요한 경우 BGP 인접 항목 구성 섹션에서 최대 접두사 설정을 늘리십시오.

BGP 인접 항목에서 수신된 최대 IPv6 접두사를 초과했습니다.

이벤트가 감지된 경우: "{bgp_neighbor_ip}에서 수신된 IPv6 {subsequent_address_family} 접두사 수가 이 피어의 한도인 {prefixes_count_max}개를 초과했습니다. "

이벤트가 해결된 경우: "{bgp_neighbor_ip}에서 수신된 IPv6 {subsequent_address_family} 접두사 수가 한도인 {prefixes_count_max}개 내에 있습니다. "

1. 외부 라우터에서 BGP 라우팅 정책을 확인하십시오.
2. 외부 라우터에 라우팅 정책 및 필터를 적용하여 BGP 피어에서 보급하는 경로 수를 줄이는 것을 고려하십시오.
3. 필요한 경우 BGP 인접 항목 구성 섹션에서 최대 접두사 설정을 늘리십시오.

NSX 보안 상태가 NDcPP와 호환되지 않습니다.

이벤트가 감지된 경우: "NDcPP 규정 준수 요구 사항 중 하나를 위반하고 있습니다. 즉, NSX 상태가 현재 NDcPP와 관련하여 비준수 상태입니다. "

이벤트가 해결된 경우: "NDcPP 규정 준수 문제가 모두 해결되었습니다. "

UI 홈 - [모니터링 및 대시보드] - [규정 준수 보고서] 메뉴에서 규정 준수 보고서를 실행하고 NDcPP 규정 준수 이름으로 표시된 모든 문제를 해결합니다.

NSX 보안 상태는 EAL4+와 호환되지 않습니다.

이벤트가 감지된 경우: "EAL4+ 규정 준수 요구 사항 중 하나를 위반하고 있습니다. 즉, NSX 상태가 현재 EAL4+와 관련하여 비준수 상태입니다. "

이벤트가 해결된 경우: "EAL4+ 규정 준수 문제가 모두 해결되었습니다. "

UI 홈 - [모니터링 및 대시보드] - [규정 준수 보고서] 메뉴에서 규정 준수 보고서를 실행하고 EAL4+ 규정 준수 이름으로 표시된 모든 문제를 해결합니다.

NSX 보안 구성이 NDcPP와 호환되지 않습니다.

이벤트가 감지된 경우: "NDcPP 규정 준수 요구 사항 중 하나를 위반하고 있습니다. 즉, NSX 구성이 현재 NDcPP와 관련하여 비준수 상태입니다. "

이벤트가 해결된 경우: "NDcPP 규정 준수 문제가 모두 해결되었습니다. "

UI 홈 - [모니터링 및 대시보드] - [규정 준수 보고서] 메뉴에서 규정 준수 보고서를 실행하고 NDcPP 규정 준수 이름으로 표시된 모든 문제를 해결합니다.

NSX 보안 구성이 EAL4+와 호환되지 않습니다.

이벤트가 감지된 경우: "EAL4+ 규정 준수 요구 사항 중 하나를 위반하고 있습니다. 즉, NSX 구성이 현재 EAL4+와 관련하여 비준수 상태입니다. "

이벤트가 해결된 경우: "EAL4+ 규정 준수 문제가 모두 해결되었습니다. "

UI 홈 - [모니터링 및 대시보드] - [규정 준수 보고서] 메뉴에서 규정 준수 보고서를 실행하고 EAL4+ 규정 준수 이름으로 표시된 모든 문제를 해결합니다.

서비스 배포에 성공했습니다.

이벤트가 감지된 경우: "클러스터 {vcenter_cluster_id}의 서비스 {service_name}에 대한 서비스 배포 {entity_id}이(가) 성공했습니다. "

이벤트가 해결된 경우: "클러스터 {vcenter_cluster_id}에서 서비스 배포 {entity_id}이(가) 성공했으며 어떠한 작업도 필요하지 않습니다. "

어떠한 작업도 필요하지 않습니다.

서비스 배포에 실패했습니다.

이벤트가 감지된 경우: "클러스터 {vcenter_cluster_id}의 서비스 {service_name}에 대한 서비스 배포 {entity_id}이(가) 실패했습니다. 이유: {failure_reason} "

이벤트가 해결된 경우: "실패한 서비스 배포 {entity_id}이(가) 제거되었습니다. "

NSX UI 또는 API를 사용하여 서비스 배포를 삭제하십시오. KB에서 수정 작업을 수행하고 서비스 배포를 다시 시도합니다.

서비스 배포를 삭제했습니다.

이벤트가 감지된 경우: "클러스터 {vcenter_cluster_id}의 서비스 {service_name}에 대한 서비스 배포 {entity_id}을(를) 삭제했습니다. "

이벤트가 해결된 경우: "클러스터 {vcenter_cluster_id}에서 서비스 배포 {entity_id}의 삭제가 성공했으며 어떠한 작업도 필요하지 않습니다. "

어떠한 작업도 필요하지 않습니다.

서비스 배포를 삭제하지 못했습니다.

이벤트가 감지된 경우: "클러스터 {vcenter_cluster_id} 서비스 {service_name}에 대한 서비스 배포 {entity_id}을(를) 삭제하지 못했습니다. 이유: {failure_reason} "

이벤트가 해결된 경우: "실패한 서비스 배포 이름 {entity_id}이(가) 제거되었습니다. "

NSX UI 또는 API를 사용하여 서비스 배포를 삭제하십시오. KB에서 수정 작업을 수행하고 서비스 배포를 다시 삭제하십시오. 모든 VM 및 개체가 삭제되었는지 확인한 후 경보를 수동으로 해결하십시오.

SVM이 서비스되고 있습니다.

이벤트가 감지된 경우: "서비스 {service_name}에 대한 SVM {entity_id}의 상태 점검이 {hostname_or_ip_address_with_port}에서 올바르게 작동합니다. "

이벤트가 해결된 경우: "SVM {entity_id}이(가) 올바르게 작동 중이며 어떠한 작업도 필요하지 않습니다. "

어떠한 작업도 필요하지 않습니다.

SVM이 서비스되고 있지 않습니다.

이벤트가 감지된 경우: "서비스 {service_name}에 대한 SVM {entity_id}의 상태 점검이 {hostname_or_ip_address_with_port}에서 올바르게 작동하지 않습니다. 이유: {failure_reason}. "

이벤트가 해결된 경우: "잘못된 상태의 SVM {entity_id}이(가) 제거되었습니다. "

NSX UI 또는 API를 사용하여 서비스 배포를 삭제하십시오. KB에서 수정 작업을 수행하고 필요한 경우 서비스 배포를 다시 시도합니다.

서비스 삽입 인프라 상태가 종료되었으며 호스트에서 사용하도록 설정되지 않았습니다.

이벤트가 감지된 경우: "호스트 {transport_node_id}의 포트 수준에서 SPF가 사용하도록 설정되지 않았으며 상태가 종료입니다. 이유: {failure_reason}. "

이벤트가 해결된 경우: "서비스 삽입 인프라 상태가 실행 중이며 호스트에서 올바르게 사용되도록 설정되었습니다. "

KB에서 수정 작업을 수행하고 상태가 실행 중인지 확인합니다. 상태를 확인한 후 경보를 수동으로 해결하십시오.

SVM 작동 상태가 종료입니다.

이벤트가 감지된 경우: "SVM 작동 상태가 {entity_id}에서 종료이며 트래픽 흐름이 영향을 받습니다. "

이벤트가 해결된 경우: "SVM 작동 상태가 실행 중이며 예상대로 구성되었습니다. "

KB에서 수정 작업을 수행하고 상태가 실행 중인지 확인합니다.

서비스 체인 경로가 종료되었습니다.

이벤트가 감지된 경우: "{entity_id}에서 서비스 체인 경로가 종료되고 트래픽 흐름이 영향을 받습니다. "

이벤트가 해결된 경우: "서비스 체인 경로가 작동 중이며 예상대로 구성되었습니다. "

KB에서 수정 작업을 수행하고 상태가 실행 중인지 확인합니다.

클러스터에 새 호스트가 추가되었습니다.

이벤트가 감지된 경우: "클러스터 {vcenter_cluster_id}에서 새 호스트가 추가되고 SVM이 배포됩니다. "

이벤트가 해결된 경우: "새 호스트를 추가했습니다. "

VM 배포 상태를 확인하고 전원이 켜질 때까지 기다립니다.

TEP가 비정상입니다.

이벤트가 감지된 경우: "전송 노드 {transport_node_id}에서 VDS {dvs_name}의 TEP {vtep_name}. 이 TEP를 사용하는 오버레이 워크로드에서 네트워크 중단이 발생합니다. 이유: {vtep_fault_reason}. "

이벤트가 해결된 경우: "전송 노드 {transport_node_id}에서 VDS {dvs_name}의 TEP {vtep_name}이(가) 정상입니다. "

1. TEP에 유효한 IP 또는 다른 언더레이 연결 문제가 있는지 확인합니다.
2. TEP HA를 사용하도록 설정하여 워크로드를 다른 정상 TEP로 페일오버합니다.

TEP HA가 활성화되었습니다.

이벤트가 감지된 경우: "전송 노드 {transport_node_id}에서 VDS {dvs_name}의 TEP {vtep_name}에 대해 TEP HA가 활성화되었습니다. "

이벤트가 해결된 경우: "전송 노드 {transport_node_id}에서 VDS {dvs_name}의 TEP {vtep_name}에 대해 TEP HA가 지워졌습니다. "

전송 노드 {transport_node_id}에서 VDS {dvs_name}의 TEP {vtep_name}에 대해 자동 복구를 사용하도록 설정하거나 수동 복구를 호출합니다.

자동 복구가 성공했습니다.

이벤트가 감지된 경우: "전송 노드 {transport_node_id}에서 VDS {dvs_name}의 TEP {vtep_name}에 대한 자동 복구가 성공했습니다. "

이벤트가 해결된 경우: "전송 노드 {transport_node_id}에서 VDS {dvs_name}의 TEP {vtep_name}에 대한 자동 복구가 지워졌습니다. "

없음.

자동 복구가 실패했습니다.

이벤트가 감지된 경우: "전송 노드 {transport_node_id}에서 VDS {dvs_name}의 TEP {vtep_name}에 대한 자동 복구가 실패했습니다. 이 TEP를 사용하는 오버레이 워크로드는 다른 정상 TEP로 페일오버됩니다. 다른 정상 TEP가 없으면 오버레이 워크로드에서 네트워크 중단이 발생합니다. "

이벤트가 해결된 경우: "전송 노드 {transport_node_id}에서 VDS {dvs_name}의 TEP {vtep_name}에 대한 자동 복구가 지워졌습니다. "

TEP에 유효한 IP 또는 다른 언더레이 연결 문제가 있는지 확인합니다.

DPU에서 TEP가 비정상입니다.

이벤트가 감지된 경우: "DPU {dpu_id}의 전송 노드 {transport_node_id}에서 VDS {dvs_name}의 TEP {vtep_name}. 이 TEP를 사용하는 오버레이 워크로드에서 네트워크 중단이 발생합니다. 이유: {vtep_fault_reason}. "

이벤트가 해결된 경우: "DPU {dpu_id}의 전송 노드 {transport_node_id}에서 VDS {dvs_name}의 TEP {vtep_name}이(가) 정상입니다. "

1. TEP에 유효한 IP 또는 다른 언더레이 연결 문제가 있는지 확인합니다.
2. TEP HA를 사용하도록 설정하여 워크로드를 다른 정상 TEP로 페일오버합니다.

DPU에서 TEP HA가 활성화되었습니다.

이벤트가 감지된 경우: "DPU {dpu_id}의 전송 노드 {transport_node_id}에서 VDS {dvs_name}의 TEP {vtep_name}에 대해 TEP HA가 활성화되었습니다. "

이벤트가 해결된 경우: "DPU {dpu_id}의 전송 노드 {transport_node_id}에서 VDS {dvs_name}의 TEP {vtep_name}에 대해 TEP HA가 지워졌습니다. "

DPU {dpu_id}의 전송 노드 {transport_node_id}에서 VDS {dvs_name}의 TEP {vtep_name}에 대해 자동 복구를 사용하도록 설정하거나 수동 복구를 호출합니다.

DPU에서 자동 복구가 성공했습니다.

이벤트가 감지된 경우: "DPU {dpu_id}의 전송 노드 {transport_node_id}에서 VDS {dvs_name}의 TEP {vtep_name}에 대한 자동 복구가 성공했습니다. "

이벤트가 해결된 경우: "DPU {dpu_id}의 전송 노드 {transport_node_id}에서 VDS {dvs_name}의 TEP {vtep_name}에 대한 자동 복구가 지워졌습니다. "

없음.

DPU에서 자동 복구가 실패했습니다.

이벤트가 감지된 경우: "DPU {dpu_id}의 전송 노드 {transport_node_id}에서 VDS {dvs_name}의 TEP {vtep_name}에 대한 자동 복구가 실패했습니다. 이 TEP를 사용하는 오버레이 워크로드는 다른 정상 TEP로 페일오버됩니다. 다른 정상 TEP가 없으면 오버레이 워크로드에서 네트워크 중단이 발생합니다. "

이벤트가 해결된 경우: "DPU {dpu_id}의 전송 노드 {transport_node_id}에서 VDS {dvs_name}의 TEP {vtep_name}에 대한 자동 복구가 지워졌습니다. "

TEP에 유효한 IP 또는 다른 언더레이 연결 문제가 있는지 확인합니다.

DPU의 업링크가 종료 중입니다.

이벤트가 감지된 경우: "DPU {dpu_id}의 업링크가 종료 중입니다. "

이벤트가 해결된 경우: "DPU {dpu_id}의 업링크가 실행 중입니다. "

DPU {dpu_id}에서 업링크의 물리적 NIC 상태를 확인합니다. 호스트에서 이 물리적 NIC의 매핑된 이름을 찾은 다음 UI를 확인합니다.
1. NSX UI에서 패브릭 | 노드 | 전송 노드 | 호스트 전송 노드로 이동합니다.
2. [호스트 전송 노드] 목록에서 [노드 상태] 열을 확인합니다. 상태가 성능 저하됨 또는 종료인 전송 노드를 찾습니다.
3. &lt전송 노드&gt | 모니터링을 선택합니다. 성능 저하됨 또는 종료를 보고하는 결합(업링크)의 상태 세부 정보를 확인합니다. 성능 저하됨 상태를 방지하려면 사용 중인지 여부와 관계없이 모든 업링크 인터페이스가 연결되어 있고 실행 중 상태인지 확인합니다.

DPU의 LACP가 멤버를 종료로 보고합니다.

이벤트가 감지된 경우: "DPU {dpu_id}의 LACP가 멤버를 종료로 보고합니다. "

이벤트가 해결된 경우: "DPU {dpu_id}의 LACP가 멤버를 실행 중으로 보고합니다. "

DPU {dpu_id}에서 LAG 멤버의 연결 상태를 확인합니다. 호스트에서 관련된 물리적 NIC의 매핑된 이름을 찾은 다음 UI를 확인합니다.
1. NSX UI에서 패브릭 | 노드 | 전송 노드 | 호스트 전송 노드로 이동합니다.
2. [호스트 전송 노드] 목록에서 [노드 상태] 열을 확인합니다. 상태가 성능 저하됨 또는 종료인 전송 노드를 찾습니다.
3. &lt전송 노드&gt | 모니터링을 선택합니다. 성능 저하됨 또는 종료를 보고하는 결합(업링크)을 찾습니다.
4. 실패한 DPU {dpu_id}에 로그인하고 esxcli network vswitch dvs vmware lacp status get을 호출하여 LACP 멤버 상태 세부 정보를 확인합니다.

업링크가 종료됩니다.

이벤트가 감지된 경우: "업링크가 종료됩니다. "

이벤트가 해결된 경우: "업링크가 실행 중입니다. "

호스트에서 업링크의 물리적 NIC 상태를 확인합니다.
1. NSX UI에서 패브릭 | 노드 | 전송 노드 | 호스트 전송 노드로 이동합니다.
2. [호스트 전송 노드] 목록에서 [노드 상태] 열을 확인합니다. 상태가 성능 저하됨 또는 종료인 전송 노드를 찾습니다.
3. &lt전송 노드&gt | 모니터링을 선택합니다. 성능 저하됨 또는 종료를 보고하는 결합(업링크)의 상태 세부 정보를 확인합니다. 성능 저하됨 상태를 방지하려면 사용 중인지 여부와 관계없이 모든 업링크 인터페이스가 연결되어 있고 실행 중 상태인지 확인합니다.

업링크가 종료됩니다.

이벤트가 감지된 경우: "업링크가 종료됩니다. "

이벤트가 해결된 경우: "업링크가 실행 중입니다. "

호스트에서 업링크의 물리적 NIC 상태를 확인합니다.
1. NSX UI에서 패브릭 | 노드 | 전송 노드 | 호스트 전송 노드로 이동합니다.
2. [호스트 전송 노드] 목록에서 [노드 상태] 열을 확인합니다. 상태가 성능 저하됨 또는 종료인 전송 노드를 찾습니다.
3. &lt전송 노드&gt | 모니터링을 선택합니다. 성능 저하됨 또는 종료를 보고하는 결합(업링크)의 상태 세부 정보를 확인합니다. 성능 저하됨 상태를 방지하려면 사용 중인지 여부와 관계없이 모든 업링크 인터페이스가 연결되어 있고 실행 중 상태인지 확인합니다.

LACP는 멤버를 종료 상태로 보고합니다.

이벤트가 감지된 경우: "LACP는 멤버를 종료 상태로 보고합니다. "

이벤트가 해결된 경우: "LACP는 멤버를 실행 중 상태로 보고합니다. "

호스트에서 LAG 멤버의 연결 상태를 확인합니다.
1. NSX UI에서 패브릭 | 노드 | 전송 노드 | 호스트 전송 노드로 이동합니다.
2. [호스트 전송 노드] 목록에서 [노드 상태] 열을 확인합니다. 상태가 성능 저하됨 또는 종료인 전송 노드를 찾습니다.
3. &lt전송 노드&gt | 모니터링을 선택합니다. 성능 저하됨 또는 종료를 보고하는 결합(업링크)을 찾습니다.
4. 실패한 호스트에 로그인하고 ESXi 호스트에서 esxcli network vswitch dvs vmware lacp status get을 호출하거나 KVM 호스트에서 ovs-appctl bond/show 및 ovs-appctl lacp/show를 호출하여 LACP 멤버 상태 세부 정보를 확인합니다.

전송 연결을 완전히 인식하지 못했습니다.

이벤트가 감지된 경우: "전송 연결 관련 구성이 완전히 올바르게 인식되지 않았습니다. 제공자 정보를 검색하지 못하거나 일시적인 제공자 통신 오류가 발생할 수 있습니다. "

이벤트가 해결된 경우: "전송 연결 장애가 수정되었습니다. "

이 경보가 10분 내에 자동으로 해결되지 않으면 가장 최근의 전송 연결 관련 요청을 다시 시도합니다. 예를 들어 TGW 연결 API 요청이 이 경보를 트리거한 경우 TGW 연결 API 요청을 다시 시도합니다. 다시 시도한 후에도 경보가 해결되지 않으면 다음 단계를 시도하십시오.
1. 작업이 계속 실패하는지 작업이 복구되었는지 확인합니다. a) 리더 관리자 노드를 식별합니다. 노드 중 하나에 로그인한 후 다음 명령을 실행합니다. - su admin - get cluster status verbose 그러면 리더 관리자 노드가 표시됩니다. b) NSX 리더 관리자 노드에 로그인합니다. NSX 리더 관리자 노드에서 vmc-app.log를 확인합니다. - tail -f /var/log/policy/vmc-app.log c) 로그에서 다음 출력을 확인합니다. - 이러한 오류 메시지 중 하나가 2분마다 계속 표시되면 작업이 계속 실패하는 것입니다. - []에 대한 TGW 경로 테이블을 가져오지 못했습니다. 오류: [] - 연결 []에 대한 TGW 경로를 경로 테이블 []에서 가져오지 못했습니다. 오류 - []에 대한 TGW 연결 VPC ID를 가져오지 못했습니다. 오류: [] - []에 대한 TGW 연결 리소스 ID를 가져오지 못했습니다. 오류: 알 수 없는 리소스 유형 - TGW []에 대한 TGW 첨부 파일을 가져오지 못했습니다. 오류: [] - 로컬 TGW 연결 []을(를) 가져오지 못했습니다. 오류: [] - AWS, 상태: []에서 올바른 TgwAttachment 상태를 찾지 못했습니다. [], TGW 경로 업데이트 작업을 건너뜁니다. - TGW 연결 []이(가) 경로 테이블에 연결되어 있지 않습니다. - []에 대한 로컬 TGW SDDC 연결을 찾을 수 없습니다.
2. 리더 관리자 노드에서 NSX Manager의 모든 AWS 호출이 실패했는지 확인합니다. 다음 명령을 실행합니다. - 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 aws 명령이 오류와 함께 실패하면 POP의 HTTP 역방향 프록시 구성에 시스템 문제가 있거나 AWS 서비스 측 문제가 있는 것일 수 있습니다.
3. TGW 연결이 AWS에 여전히 있는지 확인합니다. a) GET cloud-service/api/v1/infra/associated-groups - aws ec2 describe-transit-gateway-attachments --region을 사용하여 TGW 연결 ID를 찾을 수 있습니다. --transit-gateway-attachment-id &ltTGW attachment ID&gt TGW 연결이 삭제된 경우 VMware 지원 서비스에 문의하고 SDDC ID 및 TGW 연결 ID를 공유하십시오. VMware 지원 팀이 문제를 파악한 후 필요한 경우 남아 있는 개체를 수동으로 삭제합니다. b) 이 TGW 연결이 AWS 콘솔에 있는지 확인합니다. c) 다른 옵션은 NSX Manager에 로그인하고 aws 명령을 사용하여 TGW 연결 상태를 확인하는 것입니다. - aws ec2 describe-transit-gateway-attachments --region --transit-gateway-attachment-id &ltTGW attachment ID&gt

IPsec 서비스가 종료되었습니다.

이벤트가 감지된 경우: "IPsec 서비스 {entity_id}이(가) 종료되었습니다. 이유: {service_down_reason}. "

이벤트가 해결된 경우: "IPsec 서비스 {entity_id}이(가) 실행 중입니다. "

1. NSX Manager UI에서 IPsec 서비스를 사용하지 않도록 설정했다가 사용하도록 설정합니다.
2. 문제가 계속되면 syslog에서 오류 로그를 확인하고 VMware 지원 서비스에 문의하십시오.

정책 기반 IPsec VPN 세션이 종료되었습니다.

이벤트가 감지된 경우: "정책 기반 IPsec VPN 세션 {entity_id}이(가) 종료되었습니다. 이유: {session_down_reason}. "

이벤트가 해결된 경우: "정책 기반 IPsec VPN 세션 {entity_id}이(가) 실행 중입니다. "

IPsec VPN 세션 구성을 확인하고 세션 종료 이유에 따라 오류를 해결하십시오.

경로 기반 IPsec VPN 세션이 종료되었습니다.

이벤트가 감지된 경우: "경로 기반 IPsec VPN 세션 {entity_id}이(가) 종료되었습니다. 이유: {session_down_reason}. "

이벤트가 해결된 경우: "경로 기반 IPsec VPN 세션 {entity_id}이(가) 실행 중입니다. "

IPsec VPN 세션 구성을 확인하고 세션 종료 이유에 따라 오류를 해결하십시오.

정책 기반 IPsec VPN 터널이 종료되었습니다.

이벤트가 감지된 경우: "세션 {entity_id}에서 하나 이상의 정책 기반 IPsec VPN 터널이 종료되었습니다. "

이벤트가 해결된 경우: "세션 {entity_id}의 모든 정책 기반 IPsec VPN 터널이 실행 중입니다. "

IPsec VPN 세션 구성을 확인하고 터널 종료 이유에 따라 오류를 해결하십시오.

경로 기반 IPsec VPN 터널이 종료되었습니다.

이벤트가 감지된 경우: "세션 {entity_id}의 경로 기반 IPsec VPN 터널이 종료되었습니다. 이유: {tunnel_down_reason}. "

이벤트가 해결된 경우: "세션 {entity_id}의 경로 기반 IPsec VPN 터널이 실행 중입니다. "

IPsec VPN 세션 구성을 확인하고 터널 종료 이유에 따라 오류를 해결하십시오.

L2VPN 세션이 종료되었습니다.

이벤트가 감지된 경우: "L2VPN 세션 {entity_id}이(가) 종료되었습니다. "

이벤트가 해결된 경우: "L2VPN 세션 {entity_id}이(가) 실행 중입니다. "

L2VPN 세션 상태에서 세션 종료 이유를 확인하고 이유에 따라 오류를 해결하십시오.