NSX Manager에 vCenter Server 등록

vCenter Server의 FQDN/PNID가 변경될 때와 같은 특정 상황에서 NSX Manager에 vCenter Server OIDC를 다시 등록해야 할 수 있습니다.

프로시저

SSH를 통해 vCenter Server Appliance에 연결합니다.
shell 명령을 실행합니다.
vCenter Server 지문을 가져오려면 다음 명령을 실행합니다.
```
- openssl s_client -connect vcenterserver-FQDN:443 </dev/null 2>/dev/null | openssl x509 -fingerprint -sha256 -noout -in /dev/stdin
```
지문이 표시됩니다. 예를 들어 08:77:43:29:E4:D1:6F:29:96:78:5F:BF:D6:45:21:F4:0E:3B:2A:68:05:99:C3:A4:89:8F:F2:0B:EA:3A:BE:9D입니다.
SHA256 지문을 복사하고 콜론을 제거합니다.
08774329E4D16F2996785FBFD64521F40E3B2A680599C3A4898FF20BEA3ABE9D

vCenter Server의 OIDC를 업데이트하려면 다음 명령을 실행합니다.

curl --location --request POST 'https://<NSX-T_ADDRESS>/api/v1/trust-management/oidc-uris' \
    --header 'Content-Type: application/json' \
    --header 'Authorization: Basic <AUTH_CODE>' \
    --data-raw '{
 "oidc_type": "vcenter",
     "oidc_uri": "https://<VC_ADDRESS>/openidconnect/vsphere.local/.well-known/openid-configuration",
     "thumbprint": "<VC_THUMBPRINT>"
    }'

NSX 장치 암호를 변경할 수 없음

root, admin 또는 audit 사용자의 NSX 장치 암호를 변경하지 못할 수 있습니다.

문제

vSphere Client를 통해 root, admin 또는 audit 사용자의 NSX 장치 암호를 변경하려는 시도가 실패할 수 있습니다.

원인

NSX Manager를 설치하는 동안 절차는 세 가지 역할 모두에 대해 하나의 암호만 허용합니다. 나중에 이 암호를 변경하려고 하면 실패할 수 있습니다.

해결책

♦ 암호를 변경하려면 NSX API를 사용합니다.
자세한 내용은 https://kb.vmware.com/s/article/70691 및 " NSX 관리 가이드" 의 내용을 참조하십시오.

실패한 워크플로 및 불안정한 NSX Edge 문제 해결

워크플로가 실패하거나 NSX Edge가 불안정한 경우 문제 해결 단계를 수행할 수 있습니다.

문제

vSphere Client에서 분산 포트 그룹 구성을 변경하면 워크플로가 실패하고 NSX Edge가 불안정해질 수 있습니다.

원인

클러스터 구성의 NSX Edge 클러스터 설정 동안 생성된 오버레이 및 업링크에 대한 분산 포트 그룹의 제거 또는 수정은 설계상 허용되지 않습니다.

해결책

NSX Edge의 VLAN 또는 IP 풀 구성을 변경해야 하는 경우 먼저 NSX의 요소 및 vSphere IaaS control plane 구성 요소를 클러스터에서 제거해야 합니다.

NSX의 요소 제거에 대한 자세한 내용은 "NSX 설치 가이드" 의 내용을 참조하십시오.

NSX 문제 해결을 위한 지원 번들 수집

문제 해결을 위해 등록된 클러스터 및 패브릭 노드에 대한 지원 번들을 수집하고 번들을 시스템에 다운로드하거나 파일 서버에 업로드할 수 있습니다.

번들을 시스템에 다운로드하도록 선택하면, 각 노드에 대한 지원 번들 및 매니페스트 파일로 구성된 단일 아카이브 파일이 제공됩니다. 번들을 파일 서버에 업로드하도록 선택하면 매니페스트 파일과 개별 번들이 파일 서버에 별도로 업로드됩니다.

프로시저

브라우저에서 관리자 권한으로 NSX Manager에 로그인합니다.
시스템 > 지원 번들을 선택합니다.
대상 노드를 선택합니다.
사용 가능한 노드 유형은 관리 노드, Edge, 호스트 및 공용 클라우드 게이트웨이입니다.
(선택 사항) 로그 보존 기간을 일 단위로 지정하면 지정된 일 수보다 오래된 로그를 제외할 수 있습니다.
(선택 사항) 코어 파일 및 감사 로그를 포함할지 아니면 제외할지를 나타내는 스위치를 전환합니다.

참고: 코어 파일 및 감사 로그에는 암호나 암호화 키와 같은 중요한 정보가 포함될 수 있습니다.
(선택 사항) 파일 서버에 번들을 업로드하려면 이 확인란을 선택합니다.
지원 번들 수집을 시작하려면 번들 수집 시작을 클릭합니다.
각 노드의 로그 파일 수에 따라 지원 번들을 수집하는 데 걸리는 시간이 결정됩니다.
수집 프로세스 상태를 모니터링합니다.
상태 탭에 지원 번들 수집에 대한 진행률이 표시됩니다.
번들을 파일 서버로 전송하는 옵션이 설정되지 않은 경우 다운로드를 클릭하여 번들을 다운로드합니다.

NSX에 대한 로그 파일 수집

vSphere IaaS control plane 및 NSX 구성 요소에 있는 로그를 수집하여 오류를 감지하고 문제를 해결할 수 있습니다. 로그 파일은 VMware 지원에서 요청할 수 있습니다.

프로시저

vSphere Client를 사용하여 vCenter Server에 로그인합니다.

다음 로그 파일을 수집합니다.

로그 파일	설명
/var/log/vmware/wcp/wcpsvc.log	vSphere IaaS control plane 사용 설정과 관련된 정보를 포함합니다.
/var/log/vmware/wcp/nsxd.log	NSX 구성 요소 구성과 관련된 정보를 포함합니다.

NSX Manager에 로그인합니다.
특정 vSphere IaaS control plane 작업이 실패하는 경우 NSX Manager가 반환하는 오류에 대한 정보는 /var/log/proton/nsxapi.log를 수집합니다.

NSX 관리 인증서, 지문 또는 IP 주소가 변경되면 WCP 서비스 다시 시작

vSphere IaaS control plane를 설치한 후 NSX 관리 인증서, 지문 또는 IP 주소가 변경되면 WCP 서비스를 다시 시작해야 합니다.

NSX 인증서가 변경되면 vSphere IaaS control plane 서비스 다시 시작

현재 vSphere IaaS control plane에서는 NSX 인증서, 지문 또는 NSX IP 주소가 변경되면 WCP 서비스를 다시 시작해야 변경 사항이 적용됩니다. 변경되었는데도 서비스를 다시 시작하지 않으면 vSphere IaaS control plane와 NSX 간의 통신이 실패하고 NCP가 CrashLoopBackoff 단계로 진입하거나 감독자 리소스가 배포 불가 상태가 되는 등의 특정 증상이 발생할 수 있습니다.

WCP 서비스를 다시 시작하려면 vmon-cli를 사용합니다.

SSH를 사용하여 vCenter Server에 연결하고 루트 사용자로 로그인합니다.
shell 명령을 실행합니다.
vmon-cli -h 명령을 실행하여 사용법 구문 및 옵션을 확인합니다.
vmon-cli -l 명령을 실행하여 wcp 프로세스를 봅니다.
목록 맨 아래에 wcp서비스가 표시됩니다.
vmon-cli --restart wcp 명령을 실행하여 wcp 서비스를 다시 시작합니다.
Completed Restart service request 메시지가 표시됩니다.

vmon-cli -s wcp 명령을 실행하고 wcp 서비스가 시작되었는지 확인합니다.

예:

root@localhost [ ~ ]# vmon-cli -s wcp
Name: wcp
Starttype: AUTOMATIC
RunState: STARTED
RunAsUser: root
CurrentRunStateDuration(ms): 22158
HealthState: HEALTHY
FailStop: N/A
MainProcessId: 34372