RSS
 

VMware NSX-T Data Center 3.0   |  2020년 4월 7일  |  빌드 15946738

이 릴리스 정보의 추가 사항 및 업데이트 사항을 정기적으로 확인하십시오.

릴리스 정보에 포함된 내용

릴리스 정보에는 다음과 같은 항목이 포함됩니다.

새로운 기능

NSX-T Data Center 3.0는 사설 클라우드, 공용 클라우드 및 다중 클라우드의 가상화된 네트워킹 및 보안에 대한 새로운 기능을 제공하기 위해 여러 가지 새 기능을 포함합니다. 여기에는 다음과 같은 포커스 영역과 새로운 기능이 포함됩니다.

  • 클라우드급 네트워킹: NSX 페더레이션
  • 내장 보안: 분산 IDS, Windows 물리적 서버의 마이크로 세분화, 시간 기반 방화벽 규칙 및 URL 분석의 기능 미리 보기
  • 최신 애플리케이션 네트워킹: NSX-T for vSphere with Kubernetes, 컨테이너 네트워킹 및 보안 기능 개선
  • 차세대 통신 클라우드: VM 이동성, 가속화된 데이터부 성능, NAT64, 컨테이너에 대한 IPv6 지원, NFV에 대한 E-W 서비스 체인을 위한 L3 EVPN

NSX-T Data Center 3.0.0 릴리스에는 다음과 같은 새로운 기능과 향상된 기능이 제공됩니다.

L2 네트워킹

VDS 7.0의 NSX-T 지원

NSX-T는 이제 vSphere VDS 스위치 버전 7.0에서 실행될 수 있습니다. NSX 및 vSphere를 새로 배포하여 이러한 긴밀한 통합을 활용하고 VDS에서 NSX-T를 사용하도록 전환하는 것이 좋습니다. N-VDS NSX-T 호스트 스위치는 향후 릴리스에서 더 이상 사용되지 않습니다. 앞으로는 NSX-T 및 ESXi 호스트 스위치를 통합할 예정입니다. N-VDS는 KVM, NSX-T Edge 노드, 네이티브 공용 클라우드 NSX 에이전트 및 베어메탈 워크로드를 위한 스위치를 유지합니다.

현재 NSX-T ESXi 호스트 스위치인 N-VDS는 이 릴리스에서 계속 지원되며, 현재 ESXi에서 N-VDS를 사용하는 NSX 배포는 계속해서 동일한 스위치를 사용하는 것이 좋습니다. 이렇게 하면 다음과 같은 일석이조의 이점이 있습니다.

  1. 기존 NSX 배포에 대해 N-VDS에서 VDS 7.0로 변환하는 작업은 수동 프로세스입니다. 필요한 경우 VMware 담당자에게 자세한 내용을 문의하십시오.
  2. N-VDS와 VDS 간의 API가 다릅니다. N-VDS 또는 VDS API는 변경되지 않습니다. 하지만 환경에서 VDS를 사용하도록 전환하는 경우 N-VDS API 대신 VDS API를 호출해야 합니다. 이 에코시스템 변경은 N-VDS를 VDS로 변환하기 전에 수행해야 합니다.

N-VDS에서 VDS로 전환할 때 다음과 같은 배포 고려 사항이 권장됩니다.

  • VDS는 vCenter를 통해 구성됩니다. N-VDS는 vCenter와는 별개입니다. VDS에서 NSX-T가 지원되고 N-VDS가 사용 중단되면서 NSX-T는 vCenter와 긴밀하게 연결되며 NSX를 사용하도록 설정하는 데 vCenter가 필요합니다.
  • N-VDS는 ESXi 호스트 관련 구성을 지원할 수 있습니다. VDS는 클러스터 기반 구성을 사용하며 ESXi 호스트 관련 구성을 지원하지 않습니다.
  • 이 릴리스에서 N-VDS 기능과 VDS 기능 간에 완전한 기능 패리티가 있는 것은 아닙니다.
  • VM 및 vmKernel 인터페이스 API에 대한 지원 유형은 N-VDS와 비교할 때 VDS의 경우와 다릅니다.

RHEL 지원: NSX에 대해 지원되는 운영 체제 목록에 RHEL 7.6 및 RHEL 7.7을 추가하였습니다. 이 지원은 KVM 및 베어메탈 워크로드에 적용됩니다.

Edge 브리지:

이제 게스트 VLAN 태그 지정을 위해 구성된 세그먼트가 Edge 브리지를 통해 VLAN으로 확장될 수 있습니다. 이 기능은 세그먼트를 브리지 프로파일에 매핑할 때 VLAN ID 범위를 구성하여 사용하도록 설정할 수 있습니다. 범위의 VLAN ID를 갖는 세그먼트 트래픽은 VLAN에 브리지되며 VLAN 태그가 유지됩니다. 세그먼트-브리지 매핑에서 구성된 범위에 속하는 VLAN ID를 갖는 브리지의 VLAN 측에서 수신된 트래픽은 세그먼트로 브리지되며 해당 VLAN ID가 게스트 VLAN 태그로 유지됩니다.

이제 Edge 브리지에 정책 기반 UI 지원을 사용할 수 있습니다.

VNI당 MAC 제한: 논리적 스위치당 기본 MAC 제한의 기본값은 ESXi 데이터부에서 2,048입니다. 이제 NSX는 논리적 스위치당 MAC 제한을 기본값에서 고객 요구 사항에 맞게 변경할 수 있는 기능을 제공합니다.

Windows 2016 베어메탈 서버 지원

NSX는 다음과 같은 사용 사례를 지원합니다.

  1. VLAN 지원 가상화 워크로드와의 연결

  2. 오버레이 지원 가상화 워크로드와의 연결

  3. 가상 및 물리적 워크로드 간 통신 보안

  4. 물리적 워크로드 간 통신 보안

다음에 대한 지원을 사용할 수 있습니다.

  • 두 PNIC 사례(관리 및 애플리케이션에서 별도의 IP 사용)

  • 한 PNIC 사례(관리 및 애플리케이션에서 동일한 IP 사용)

현재 지원되는 최대값에 대해서는 VMware 구성 최대값을 참조하십시오.

고급 데이터 경로

  • ENS의 Zero tx copy 지원 - 이제 더 큰 패킷 크기(600-700B)의 경우 Zero tx copy가 지원됩니다. 이는 vSphere 7.0부터 지원되며, l2/l3 캐시 누락을 개선하여 전반적인 성능을 향상시킵니다.

  • FPO Flow Director 오프로드 및 연결된 vmkapi 변경 - NIC 오프로드에 대한 N-VDS가 지원되고 향상된 데이터 경로의 성능이 개선됩니다.

  • U-ENS 데이터부 통합 - ENS(고급 네트워크 스택) 및 FC(흐름 캐시)는 NSX-T에 대해 N-VDS(또는 vswitch)에서 빠른 경로를 제공합니다. FC는 통신용으로 더 많이 사용되지만 ENS는 일반 용도로 사용됩니다.

  • ENS 성능 최적화 - 캐시 사용률과 패킷 크기와 관련해서 성능이 개선되었습니다.

페더레이션

NSX-T 3.0에서는 GM(글로벌 관리자)이라는 단일 창 방식을 통해 여러 온-프레미스 데이터 센터를 페더레이션할 수 있는 기능을 도입했습니다. GM은 그래픽 사용자 인터페이스 및 의도 기반 REST API 끝점을 제공합니다. GM을 통해 여러 위치 및 확장된 네트워킹 개체에 걸쳐 일관된 보안 정책을 구성할 수 있습니다. Tier0 및 Tier1 게이트웨이와 세그먼트.

확장 및 업그레이드 제한이 지정된 경우(아래의 "페더레이션의 알려진 문제" 참조) 페더레이션은 NSX-T 3.0.x 릴리스의 운영 배포에 적합하지 않습니다.

Edge 플랫폼

  • 새로운 Edge VM XLarge 폼 팩터는 고급 서비스를 위해 더 많은 확장 기능과 더 나은 처리량을 제공합니다.
  • 베어메탈 Edge에서 Edge VM에 지원되는 BFD 간격이 500ms 및 50ms로 단축되어 Tier-0 게이트웨이의 컨버전스 시간이 개선되었습니다.
  • 향상된 Edge VM 배포: NSX를 통한 Edge VM 배포 중에 다음 작업이 수행됩니다.
    • ESX 재부팅할 때 Edge VM 자동 시작
    • DFW 제외 목록에 Edge VM이 추가됨
    • 매개 변수 SSH 허용, 루트 로그인 허용, NTP 서버 목록, 도메인 검색 목록, DNS 서버 목록 및 기본 사용자 자격 증명 구성

L3 네트워킹

  • UI/API를 통해 Tier0 게이트웨이 HA 모드를 변경하면 UI 및 API를 통해 Tier-0 게이트웨이 고가용성 모드를 활성/활성에서 활성/대기로, 그 반대로 변경하는 옵션을 사용할 수 있습니다.
  • VRF Lite 지원은 Tier-0 게이트웨이에서 VRF(가상 라우팅 전달)를 통해 다중 테넌트 데이터부를 격리합니다. VRF에는 고유한 격리된 라우팅 테이블, 업링크, NAT 및 게이트웨이 방화벽 서비스가 있습니다.
  • L3 EVPN 지원은 노스바운드 연결 옵션을 제공하여 MP-BGP EVPN AFI(경로 유형 5)를 통해 Tier-0 게이트웨이의 모든 VRF를 제공자 Edge로 보급하고, VRF당 하나의 VNI를 사용하여 VXLAN 캡슐화를 통해 데이터부에서 격리를 유지합니다.
  • Tier-1 게이트웨이의 속도 제한 지원을 통해 Tier1 게이트웨이 업링크를 송신 및 수신하는 모든 트래픽의 속도를 제한할 수 있습니다.
  • 정책 및 UI의 메타데이터 프록시 지원은 의도 기반 API 및 정책 UI를 개선하여 메타데이터 프록시를 구성합니다.
  • DHCP 서버 정책 및 UI는 의도 기반 API 및 정책 UI를 개선하여 세그먼트에 로컬로 DHCP 서버를 구성합니다.
  • L3에 대한 정책 API는 의도 기반 API 및 정책 UI를 개선하여 게이트웨이에서 런타임 정보를 검색합니다.
  • L3 멀티캐스트(1단계):
    • NSX-T 3.0은 NSX-T의 멀티캐스트를 처음으로 도입했습니다.
    • 멀티캐스트 복제는 T0에서만 지원되며, 멀티캐스트 워크로드가 있어야 하는 모든 호스트는 T0에 연결되어야 합니다. T1은 향후 릴리스에서 지원됩니다.
    • 또한 NSX-T 3.0에는 Edge에서 TOR로의 업링크가 하나만 있습니다. 향후 릴리스에서는 이중화가 기본적으로 제공되며 PIM을 지원하는 TOR에 대해 여러 업링크가 있을 수 있습니다.
    • RP는 항상 NSX 도메인 외부에서 프로그래밍되어야 합니다.
    • NSX-T 3.0에서 멀티캐스트 트래픽에 대해 지원되는 Edge 서비스는 없습니다.

IPv6

  • NAT64는 IPv4에서 IPv6로의 전환 메커니즘을 제공합니다. 표준 RFC 6146에 따라 IPv6에서 IPv4로의 상태 저장 네트워크 주소 변환을 제공합니다.
  • 상태 저장 DHCPv6 지원 - 이제 NSX는 Edge 노드에서 호스팅되는 NSX 네이티브 DHCP 서버를 통해 IPv6 주소 및 연결된 매개 변수의 상태 저장 전달을 지원합니다.

방화벽

  • NSX 페더레이션을 사용하여 여러 사이트에서 일관된 보안 정책 유지 - NSX-T 3.0에는 여러 NSX Manager를 관리할 수 있는 GM(글로벌 관리자) 개념이 도입되었습니다. NSX-T 3.0에서는 글로벌 관리자가 단일 창 방식을 통해 여러 사이트에 걸쳐 일관된 보안 정책을 제공합니다.
  • 보안 대시보드 소개- NSX-T 3.0에는 보안 관리자 및 방화벽 관리자가 방화벽 및 분산 IDS의 현재 작동 상태를 한눈에 볼 수 있는 새로운 보안 개요 대시보드가 도입되었습니다.
  • 방화벽 규칙에 대한 시간 기반 스케줄링 - NSX-T 3.0에서는 이제 특정 시간 간격으로 특정 규칙의 적용을 예약할 수 있습니다.
  • VLAN 기반 마이크로 세분화를 빠르게 수행하기 위한 마법사 도입 - 매우 간단한 단계로 NSX-T를 사용하여 세분화를 도입하도록 데이터 센터를 구성할 수 있습니다.
  • Windows 물리적 서버의 마이크로 세분화 - NSX-T 3.0에서 Windows 물리적 서버에 대한 마이크로 세분화를 도입했습니다.
  • URL 분석 - 기능 미리 보기 - URL의 검색, 분류 및 신뢰도 점수를 사용한 URL 필터링의 미리 보기를 도입했습니다. 이 기능 미리 보기는 게이트웨이 방화벽에서만 사용할 수 있습니다.
  • KVM에서 FW에 대한 TCP/UDP 및 ICMP 세션 타이머 구성 지원 - KVM에서 실행되는 워크로드에 대해 방화벽 타이머 구성 변경이 지원됩니다.

ID 기반 방화벽

  • ID 방화벽 규칙의 일부로 VDI 환경에 대한 ICMP 트래픽 필터링 - VDI 사용자가 ICMP 프로토콜을 기준으로 트래픽을 필터링하기 위한 ID 방화벽 규칙을 생성할 수 있도록 합니다. VDI로 제한되며 RDSH 사용자는 사용할 수 없습니다.
  • ID 방화벽 그룹에 대한 AD 그룹을 선택적으로 동기화 - ID 방화벽 규칙의 끝점으로 사용할 특정 AD 그룹을 동기화할 수 있습니다. 이 기능은 AD 그룹의 성능 및 사용 편의성을 최적화합니다. 이 기능은 현재 API를 사용하여 사용할 수 있습니다.
  • ID 방화벽 규칙에 대한 UDP 트래픽 필터링 - UDP 트래픽을 ID 방화벽 규칙의 일부로 필터링할 수 있습니다.

D-IDS(분산 침입 탐지 시스템)

NSX 플랫폼에는 플랫폼의 위협 및 취약성 감지 기능으로 분산 침입 감지 기능이 도입되었습니다. 이 기능을 사용하면 하이퍼바이저 내에서 침입 감지 기능을 사용하도록 설정하여 취약한 네트워크 트래픽을 감지할 수 있습니다. 이 분산 메커니즘은 보다 세분화된 규칙 검사를 통해 VM 기준 및 VM의 vNIC 기준으로 사용하도록 설정할 수 있습니다. 이 기능 세트의 일부로 NSX Manager는 NSX 서명 서비스에서 최신 서명 팩을 다운로드할 수 있습니다. 이렇게 하면 환경의 최신 위협 서명으로 NSX 분산 IDS를 업데이트할 수 있습니다

서비스 삽입 및 Guest Introspection

  • Edge의 NFV-SFC에 대한 E-W 서비스 체인 - 여러 서비스를 연결하는 기능이 초기에는 분산 트래픽에만 사용할 수 있었지만 이제는 Edge 트래픽에 사용할 수 있습니다. 이제 동-서 서비스 체인을 확장하여 Edge 트래픽을 리디렉션할 수도 있습니다.
  • NSX 서비스 VM의 복제 사용 안 함 - 이제 VM 오작동을 방지하기 위해 서비스 VM 복제가 vSphere Client에서 금지됩니다.

로드 밸런싱

  • 다중 모니터 및 'AND' 조건에 대한 로드 밸런서 상태 점검 지원 - 이 향상된 기능을 통해 여러 활성 상태 모니터를 하나의 상태 모니터링 정책으로 구성할 수 있습니다. 멤버가 정상 상태로 간주되려면 모든 활성 상태 모니터가 검사를 성공적으로 통과해야 합니다.
  • 계층 4 및 계층 7 가상 서버에 대한 연결 삭제 - 계층 4 가상 서버는 지정된 네트워크에서의 연결을 허용하거나 거부하는 새로운 옵션을 제공합니다. 계층 7 가상 서버에 대한 LB 규칙에서는 그룹을 사용하여 네트워크를 지정하고, 새 작업 "삭제"를 사용하여 HTTP 상태 코드를 반환하는 대신 요청을 자동으로 삭제할 수 있습니다.
  • LB 가상 서버 및 멤버에 대한 IPv6 지원 - IPv6 멤버로의 IPv6 VIP 로드 밸런싱이 지원됩니다.
  • JSON Web Token 지원 - 로드 밸런서는 JSON Web Token 또는 JWT의 유효성을 검사하고 해당 페이로드를 기준으로 액세스 권한을 부여할 수 있습니다.
  • 로드 밸런서 규칙에 따라 SSL 패스스루 및 동적 SSL 종료 - 로드 밸런서는 SSL을 종료하지 않고 SSL Client Hello의 SNI를 기준으로 풀을 선택할 수 있습니다. 또한 SNI를 기준으로 SSL 패스스루, SSL 오프로드 또는 종단 간 SSL을 수행할 수 있습니다.
  • 로드 밸런서 초대형 지원 - 보다 나은 확장을 위해 XLarge Edge에 대해 초대형 폼 팩터가 도입되었습니다.
  • vSphere with Kubernetes용 DLB- vSphere with Kubernetes를 통해 관리되는 k8s 클러스터 IP에 대해 분산 로드 밸런서가 지원됩니다. 다른 워크로드 유형에서는 DLB가 지원되지 않습니다.

VPN

  • VPN 대량 암호화에 대한 Intel QAT 지원 - Intel QAT 카드는 베어메탈 Edge에서 VPN 대량 암호화를 오프로드하도록 지원됩니다.
  • L2VPN에 대한 로컬 송신 - 두 개의 로컬 게이트웨이를 동일한 게이트웨이 IP 주소의 확장된 네트워크에 연결하여 아웃바운드 트래픽이 로컬 게이트웨이를 통해 전송되도록 할 수 있습니다.
  • 요청 시 DPD - 요청 시 DPD는 원격 장애를 빠르게 감지하면서 짧은 DPD 연결 유지 간격을 방지하기 위해 지원됩니다.
  • Tier-1 LR의 L2 VPN - L2 VPN 서비스는 Tier-1 게이트웨이에서 지원됩니다.
  • VPN 세션에 대한 상태 저장 페일오버 - IKE SA 및 IPsec SA는 상태 저장 페일오버를 위해 실시간으로 대기 VPN 서비스와 동기화됩니다.
  • PMTU 검색 - 패킷 조각화를 방지하기 위해 L2 및 L3 VPN 서비스 둘 다에서 PMTU 검색이 지원됩니다.

자동화, OpenStack 및 기타 CMP

  • 검색 API 사용 가능 - API를 통해 NSX-T 검색 기능(이미 UI에서 사용 가능)을 제공합니다. 이렇게 하면 태그, 유형, 이름 또는 기타 특성을 기준으로 NSX-T 개체를 반환하고 자동화를 간소화하는 강력한 쿼리를 만들 수 있습니다. 검색 API의 자세한 사용 방법은 API 가이드에 설명되어 있습니다.
  • NSX-T의 Terraform 제공자 - 선언적 API 지원 - Terraform 제공자는 온-프레미스의 선언적 NSX-T용 API에서 논리적 개체를 구성하는 기능을 제공합니다. NSX-T 정책 API 모델의 유연성과 추가 기능을 통해 Terraform의 이점을 활용할 수 있습니다. 새 리소스 및 데이터 소스는 네트워킹(Tier-0 게이트웨이, Tier-1 게이트웨이, 세그먼트), 보안(중앙 집중식 및 분산 방화벽, 그룹) 및 서비스(로드 밸런서, NAT, DHCP)의 보다 광범위한 생성자를 통해 Infrastructure as Code를 허용합니다. 자세한 내용은 Terraform 제공자 릴리스 정보에서 확인할 수 있습니다.
  • NSX-T용 Ansible 모듈-업그레이드 및 논리적 개체 지원 - NSX-T용 Ansible 모듈이 설치 외에 업그레이드도 지원하도록 개선되었습니다. 또한 선언적 API에서 Tier-0 게이트웨이, Tier-1 게이트웨이, 세그먼트 및 분산 방화벽 규칙을 구성하여 환경을 설정할 수 있습니다. 이를 통해 환경의 설정, 업그레이드 및 기본 토폴로지 생성을 자동화할 수 있습니다. 자세한 내용은 Ansible 모듈 릴리스 정보에서 확인할 수 있습니다.
  • OpenStack 통합 기능 향상 - 확장된 IPv6, VPNaaS 지원, vRF lite 지원 - NSX-T용 Neutron 플러그인 선언적 API는 IPv6 및 VPNaaS를 확장하고 포괄합니다. VPNaaS를 통해 NSX-T에서 생성된 OpenStack IPsec VPN에서 구성할 수 있지만, IPv6 구현을 통해 이전 릴리스에 이미 있는 모든 기능에 로드 밸런서가 추가로 지원됩니다. 또한 OpenStack Neutron 플러그인은 Tier-0 외에 Tier-0 vRF-lite를 외부 네트워크로 사용하는 것을 검증하여 대규모 엔터프라이즈 및 서비스 제공자가 최소량의 Edge 리소스를 사용하여 격리 및 유연성을 제공하도록 허용합니다. 자세한 내용은 OpenStack Neutron 플러그인 릴리스 정보에서 확인할 수 있습니다.

컨테이너 네트워킹 및 보안

  • 사용자 인터페이스의 컨테이너 인벤토리 및 모니터링 - 컨테이너 클러스터, 네임스페이스, 네트워크 정책, 포드 수준 인벤토리를 NSX-T 사용자 인터페이스에서 시각화할 수 있습니다. 또한 컨테이너/K8 개체와 NSX-T 논리적 개체 간 공동 관계에 대한 가시성이 제공됩니다.
  • IPAM 유연성- NSX 정책 IP 블록 API가 가변 크기의 IP 서브넷을 구현하도록 개선되었습니다. 이 기능은 NSX Container Plugin이 정책 API를 사용하여 네임스페이스의 가변 크기 서브넷을 구현하도록 지원합니다.
  • NCP 구성 요소 상태 모니터링 - NSX Manager UI/API를 사용하여 NCP 상태, NSX 노드 에이전트 상태, NSX Hyperbus 에이전트 상태와 같은 NSX Container Plugin 및 관련 구성 요소 상태 정보를 모니터링할 수 있습니다.

NSX Cloud

  • 애플리케이션 ID 및 URL 필터링- 이제 NSX Cloud를 통해 공용 클라우드의 선택적 네이티브 서비스에 대한 애플리케이션 ID 및 URL 기능을 사용할 수 있습니다. 이를 통해 NSX Cloud에서 일관된 단일 정책을 사용하여 공용 클라우드에서 보호할 수 있는 워크로드/서비스의 범위가 확장됩니다. AWS 및 Azure에서 가장 일반적으로 사용되는 서비스부터 지원할 예정입니다.
  • AWS 및 Azure 정부 클라우드 지원- 상업용 클라우드(AWS 및 Azure)에서 NSX Cloud의 모든 기능은 이제 정부 클라우드(미국의 모든 정부 클라우드 지역)로 확장됩니다. 기능은 해당 공용 클라우드 제공자의 API/가용성 지원에 따라 좌우됩니다.
  • SLES 12sp3(SUSE 12 SP3) 지원 - 이제 SLES 12sp3를 실행하는 에이전트가 있는 공용 클라우드 VM이 지원됩니다.
  • 에이전트 없는 VPC 및 VNet에서 VPN 지원 - VPC 및 VNET이 에이전트 없는 모드에서 실행되는 경우에도 온-프레미스 또는 공용 클라우드(AWS 및 Azure)에 있는 Edge 간에 VPN 연결을 설정할 수 있습니다.

작업

  • 씬 및 씩 디스크 모드 지원 - 이제 NSX Manager 및 NSX Intelligence 장치는 씬 모드 및 씩 모드 둘 다를 지원하며 배포 시 두 가지 선택 사항을 제공합니다.
  • NSX Manager의 디스크 크기 증가 - NSX-T 3.0부터 NSX Manager의 디스크 크기가 200GB에서 300GB(클러스터의 NSX Manager 노드 기준)로 증가합니다. 새 NSX Manager 설치 중에 기본 데이터스토어에 충분한 디스크 공간이 있는지 확인하십시오. NSX-T 3.0으로 업그레이드하는 동안 NSX Manager를 업그레이드하기 전에 새 데이터스토어가 추가되었는지 확인하십시오.
  • NSX-T에서 VIB 크기 감소 - 모든 NSX 호스트 설치에서 NSX-T 3.0의 VIB 설치 공간이 감소되므로 하이퍼바이저에 NSX와 함께 ESX 및 다른 타사 VIB를 설치할 수 있습니다.
  • 페더레이션 업그레이드 지원 - NSX 페더레이션을 사용하여 관리자는 업그레이드 가이드의 자세한 호환성 매트릭스에 따라 글로벌 관리자와 로컬 관리자를 비동기식으로 업그레이드할 수 있습니다.
  • N-vDS에 대한 주기적 MTU/VLAN 상태 점검 - 이제 NSX 호스트 스위치(N-vDS)에 상태 점검을 사용할 수 있습니다.
  • 무중단 인플레이스 업그레이드 - NSX 전송 노드의 인플레이스 업그레이드가 좀 더 개선되었으며 업그레이드 가이드에 제공되는 주의 항목 수가 감소되었습니다.
  • Traceflow 정책 지원 - 이제 [정책] 탭(이전의 [간소화] 탭)에서 Traceflow 디버깅 도구를 사용할 수 있습니다.
  • 호스트 수준에서 TN 설치를 따르고 진행률 표시줄 제공 - 관리자는 UI에서 하이퍼바이저의 NSX 설치에 대한 자세한 진행률을 볼 수 있습니다.
  • Spoofguard에 대한 Traceflow 관찰 - 이제 Traceflow 디버깅 도구에 Spoofguard 기능으로 인해 발생할 수 있는 패킷 손실이 표시됩니다.
  • 호스트가 VC 클러스터를 벗어날 때 NSX를 자동으로 제거하는 기능 - 사용자가 전송 노드를 vSphere 클러스터 외부로 이동하면 NSX가 자동으로 제거됩니다. 이에 대한 자세한 내용은 업그레이드 가이드에서 확인할 수 있습니다.
  • 중앙 장치 구성 - 이제 NSX는 관리자에게 노드 단위로 로컬 CLI 구성을 사용하도록 요구하는 대신, 중앙 집중식으로 NSX Manager 및 Edge 노드 간에 공통된 설정을 구성하는 기능을 지원합니다.
  • SNMP 트랩 - NSX는 이제 지원되는 하이퍼바이저 호스트의 NSX Manager, Edge 노드 및 NSX 구성 요소에서 SNMP 트랩 알림을 생성하는 기능을 지원합니다. 이러한 트랩 알림은 NSX에서 생성되는 이벤트 및 경보에 대한 것입니다. NSX MIB는 NSX 다운로드 사이트에서 NSX 전달물의 일부로 제공됩니다.
  • NSX 경보 프레임워크 및 시스템 경보/이벤트 - 이번 NSX 릴리스에서는 운영 환경에서 NSX를 성공적으로 실행하는 데 도움이 되는 경고 및 경보의 전달을 개선하는 경보 프레임워크를 지원합니다. 지원되는 경보 목록은 NSX 설명서에 제공됩니다.

인벤토리

  • NSX 태그 목록 및 대량 작업 지원- NSX-T는 NSX 태그를 나열하고 NSX 태그를 여러 가상 시스템에 할당/할당 해제할 수 있도록 하는 UI/API 지원을 추가합니다.
  • 물리적 서버 목록 - NSX-T는 물리적 서버를 나열하기 위한 UI 지원을 추가합니다.

사용 편의성 및 사용자 인터페이스

  • 네트워크 토폴로지의 그래픽 시각화 - PDF로 내보내는 기능을 통해 Tier 0 게이트웨이, Tier 1 게이트웨이, 세그먼트 및 연결된 워크로드(VM, 컨테이너)의 대화형 네트워크 토폴로지 다이어그램을 제공합니다.
  • 새로운 시작 마법사 - 간단한 3단계로 클러스터의 VLAN 마이크로 세분화를 준비할 수 있는 새로운 시작 마법사가 도입되었습니다.
  • 검색 결과에서 작업 및 경보에 빠르게 액세스- [향상된 검색 결과] 페이지를 통해 관련 작업 및 경보에 빠르게 액세스할 수 있습니다. 네트워킹, 보안, 인벤토리 및 시스템 개체에 대해 더 많은 검색 기준을 추가했습니다.
  • NSX 정책 및 관리자 모드에 대한 사용자 인터페이스 기본 설정 - 사용자 인터페이스 내에서 NSX 정책 모드와 NSX Manager 모드 간을 전환할 수 있을 뿐 아니라 기본 디스플레이를 제어할 수도 있습니다. 기본적으로 새로 설치하면 NSX 정책 모드에서 UI가 표시되고 UI 모드 전환기가 숨겨집니다. NSX Manager 모드를 통해 생성된 개체(예: NSX 업그레이드 또는 클라우드 관리 플랫폼)를 포함하는 환경에서는 기본적으로 UI 모드 전환기를 UI의 오른쪽 상단 모서리에 표시합니다.
  • 시스템 장치의 UI 디자인 개선 사항 개요 - NSX 시스템 장치의 리소스 작업 및 운영 상태를 표시하기 위한 UI 설계 레이아웃이 개선되었습니다.

라이센싱

  • 새 VMware NSX Data Center 라이센스- 새 추가 기능 라이센스에 대한 지원, 2020년 4월에 도입된 VMware NSX Data Center 분산 위협 방지를 추가하고, 2018년 6월에 도입된 NSX Data Center 라이센스(Standard, Professional, Advanced, Enterprise Plus, Remote Office Branch Office)와 이전 VMware NSX for vSphere 라이센스 키를 계속 지원합니다. 또한 라이센스 사용량 보고서는 마이크로 세분화, 페더레이션 사용량을 코어, CPU, CCU 및 VM 메트릭으로 캡처합니다. 분산 침입 감지 사용량은 CPU 기준입니다. NSX 라이센스에 대한 자세한 내용은 VMware 기술 자료 문서 52462를 참조하십시오.
  • vShield Endpoint 관리 지원 - NSX-T는 vShield Endpoint 바이러스 백신 오프로드 기능을 관리하도록 지원합니다. 자세한 내용은 VMware 기술 자료 문서 2110078을 참조하십시오.
  • 기본 라이센스 및 평가 키 배포 변경 - 설치 시 기본 라이센스는 바이러스 백신 오프로드 기능에 한하여 vShield Endpoint 배포 및 관리를 위해 NSX를 사용할 수 있는 "NSX for vShield Endpoint"입니다. 평가판 라이센스 키는 VMware 판매 또는 VMware 평가 웹 사이트를 통해 요청할 수 있습니다.
  • NSX 평가판 라이센스 만료 - 60일 후에 NSX 평가판 라이센스가 만료되면 개체를 삭제할 수 있지만 생성하거나 편집할 수는 없습니다.

AAA 및 플랫폼 보안

  • LDAP를 통한 네이티브 AD 기반 인증 - 이 기능은 NSX 관리자 및 사용자가 LDAP(Lightweight Directory Access Protocol)와의 직접 AD(Active Directory) 통합을 통해 NSX-T 플랫폼에서 인증 및 온보딩을 수행하도록 지원합니다. 대부분의 엔터프라이즈/비즈니스 사용자 자격 증명은 Microsoft 기반 AD에 저장됩니다. 직접 AD 구성은 사용이 적합하지 않거나 운영을 좀 더 복잡하게 하는 추가 ID 시스템 구성 작업이 필요 없으므로 사용자 온보딩이 간소화됩니다. 또한 이 기능을 사용하면 강력한 검색 옵션과 함께 NSX-T RBAC 기능을 사용하여 역할 할당을 위해 관련 AD 사용자/그룹을 식별할 수 있습니다. 보안(LDAPS, startTLS) 및 일반 LDAP 구성이 둘 다 지원됩니다. 이제 NSX-T 고객은 Workspace One Access(이전의 vIDM) 또는 네이티브 AD 구성, vIDM 및 직접 AD 구성 조합을 유연하게 구성하여 운영 요구 사항을 충족할 수 있습니다.
  • OpenLDAP와의 통합 - 네이티브 AD 통합 지원 외에도, NSX-T 3.0은 OpenLDAP 디렉토리 서비스를 사용하는 사용자를 유연하게 인증 및 온보딩할 수 있도록 합니다.
  • vSphere with Kubernetes에서 AAA for NSX-T 기능 - vSphere 7.0 장치에서 컨테이너화된 애플리케이션 및 Kubernetes 기능을 실행하는 사용자는 vSphere 장치를 통한 추가 인증 없이도 제한된 수의 NSX 네트워킹 기능을 활용하고 문제를 해결할 수 있습니다.
  • API "대신" 기능- 특히 PI(주체 ID) 또는 서비스 계정을 사용하여 API 호출을 수행할 때 다른 NSX 사용자 대신 API 작업을 호출할 수 있는지 여부를 지정하여 파생된 사용자 작업을 추적할 수 있습니다. “X-NSX-EUSER: <username>" 헤더를 사용하여 API를 호출하면 추가 사용자 활동 정보 “euser=<username>”을 포함하는 감사 로그가 생성됩니다. 이 기능은 "작업"을 수행한 "사용자"에 대한 컨텍스트 데이터가 포함된 풍부한 감사 추적을 유지하는 심층 사용자 회계에 유용합니다.
  • 원격 사용자를 위한 세션 기반 인증 - NSX-T 3.0에는 로컬 및 원격 사용자가 쿠키 기반 세션을 생성하고 API 기반 활동을 인증 및 유지할 수 있도록 하는 향상된 인증 기능이 있습니다. 새로운 개선 사항은 API 사용자의 세션 생성을 간소화하고 반복적인 인증을 방지하여 효율적인 API 작업 및 보안 규정 준수를 촉진합니다. vIDM 및 LDAP 기반 원격 사용자가 둘 다 지원됩니다.
  • API 쓰기 호출에 대한 별도의 감사 로그 - 이 기능은 API 쓰기 호출에 대한 정보만 포함하는 감사 로그 컨텐츠를 검색하는 기능을 지원합니다. "이전 및 이후” 상태를 추적하여 감사 추적의 가독성을 향상시킵니다.
  • 쿠키 기반 인증 사용/사용 안 함 - NSX 관리자는 이제 쿠키(세션 기반) 기반 API 인증을 해제하여 NSX-T 플랫폼 작업의 보안 상태를 향상시킬 수 있습니다. 쿠키 기반 인증은 기본적으로 사용할 수 있으며 해제된 후에 다시 사용하도록 설정할 수 있습니다.
  • 기본 인증 사용/사용 안 함 - 기본 인증의 보안 사용과 관련된 NSX 관리자는 이제 API 및 CLI 사용을 위해 기본 인증을 사용하지 않도록 설정하거나 다시 사용하도록 설정할 수 있습니다. 기본적으로 기본 인증 지원을 사용할 수 있습니다.

NSX Data Center for vSphere에서 NSX-T Data Center로의 마이그레이션

  • 유지 보수 모드를 사용하는 마이그레이션 조정기 - vSphere 7.0 및 vDS 7.0을 사용하는 경우 마이그레이션 조정기는 호스트를 N-VDS로 마이그레이션하는 대신 기존 vDS(버전 7.0)로 마이그레이션합니다. 이렇게 하면 고객 환경에 마이그레이션이 미치는 영향이 최소화됩니다.
  • vDS 7.0을 사용하여 NSX Data Center for vSphere에서 NSX-T Data Center로 마이그레이션 - 이제 NSX 마이그레이션 조정기는 최종 호스트 마이그레이션 단계에 대한 유지 보수 모드를 지원합니다. 이 모드를 사용하면 호스트를 NSX for vSphere에서 NSX-T로 변환하기 전에 호스트에서 가상 시스템을 마이그레이션할 수 있습니다. 호스트를 유지 보수 모드로 전환하여 가상 시스템의 송수신 데이터 트래픽에 미치는 영향을 최소화하기 위해 vMotion을 사용하여 가상 시스템을 마이그레이션할 수 있습니다.

NSX Intelligence

호환성 및 시스템 요구 사항

호환성 및 시스템 요구 사항에 대한 자세한 내용은 NSX-T Data Center 설치 가이드를 참조하십시오.

API 사용 중지 및 일반 동작 변경

  • InterSR iBGP 피어링 동작 변경 - NSX-T 3.0부터 SR 간 iBGP 피어링 전용의 새로운 VRF가 도입되었습니다. 이 VRF의 이름은 'inter_sr_vrf'이고 자동으로 구축된 iBGP 피어링 인접성을 통해 보급된 경로가 이제 앞서 언급한 전용 VRF에 설치됩니다.
  • 애플리케이션 검색 제거 - 이 기능은 더 이상 사용되지 않으며 제거되었습니다.
  • NSX-T 2.4 및 2.5에서 업그레이드할 때 "고급 네트워킹 및 보안” UI 변경 - NSX-T Data Center 2.4 및 2.5에서 업그레이드하는 경우 "고급 네트워킹 및 보안" UI 탭에 있던 메뉴 옵션을 "관리자" 모드를 클릭하여 NSX-T Data Center 3.0에서 사용할 수 있습니다.
  • NSX-T Data Center 2.4 및 2.5에는 다음과 같은 구성이 있습니다.
    • 분산 방화벽에 대한 두 가지 기본 규칙은 정책 인터페이스에 대한 규칙과 고급 네트워킹 및 보안 인터페이스에 대한 규칙입니다.
    • 분산 방화벽 사용 또는 사용 안 함 두 가지 설정은 정책 인터페이스에 대한 규칙과 고급 네트워킹 및 보안 인터페이스에 대한 규칙입니다.
    • NSX-T Data Center 3.0에서 정책 구성이 있는 경우 기본 규칙 및 분산 방화벽 사용/사용 안 함 설정은 정책 모드에서만 사용할 수 있습니다. 관리자(이전 고급 네트워킹 및 보안) 구성만 있는 경우에는 관리자 모드에서 이러한 설정을 구성할 수 있습니다. 모드에 대한 자세한 정보는 NSX-T Data Center 관리 가이드의 "NSX Manager 개요"를 참조하십시오.
  • API 사용 중단 정책- VMware는 이제 NSX API 가이드에 API 사용 중단 정책을 게시하여 NSX로 자동화하는 고객이 어떤 API가 더 이상 사용되지 않는 것으로 간주되는지와 이러한 API가 향후 제품에서 제거될 시기를 파악할 수 있도록 합니다.

API 및 CLI 리소스

자동화를 위해 NSX-T Data Center API 또는 CLI를 사용하려면 code.vmware.com을 참조하십시오.

API 설명서는 API 참조 탭에서 사용할 수 있습니다. CLI 설명서는 설명서 탭에서 사용할 수 있습니다.

사용 가능한 언어

NSX-T Data Center는 영어, 독일어, 프랑스어, 일본어, 중국어 간체, 한국어, 중국어 번체 및 스페인어를 비롯한 여러 언어로 현지화되었습니다. NSX-T Data Center 현지화는 브라우저 언어 설정을 활용하기 때문에 설정이 원하는 언어와 일치하는지 확인하십시오.

문서 개정 이력

2020년 4월 7일 1차 개정판.
2020년 4월 20일 2차 개정판. 알려진 문제 2550327, 2546509가 추가되었습니다.
2020년 5월 8일 3차 개정판. 알려진 문제 2499819을 추가함.
2020년 5월 14일 4차 개정판. 알려진 문제 2543239를 추가함.
2020년 5월 22일 5차 개정판. 알려진 문제 2541923를 추가함.
2020년 6월 1일 6차 개정판. 알려진 문제 2518183, 2543353, 2561740을 추가함.
2020년 8월 24일 7차 개정판. 알려진 문제 2577452를 추가했습니다.
2020년 8월 28일 8차 개정판. 알려진 문제 2622672, 2630808, 2630813, 2630819를 추가했습니다.
2021년 3월 15일. 9차 개정판. 알려진 문제 2730634를 추가했습니다.
2021년 9월 17일. 10차 개정판. 알려진 문제 2761589를 추가했습니다.
2021년 10월 11일. 11차 개정판. API 사용 중지 및 일반 동작 변경 섹션을 업데이트했습니다.
2022년 2월 15일. 12차 개정판. 새로운 기능 섹션에서 프로세서 이름이 제거되었습니다.
2022년 5월 18일. 13차 개정판. 알려진 문제 2959572를 추가했습니다.

해결된 문제

  • 해결된 문제 2387578 - 관리/TEP 인터페이스를 통해 동일한 클러스터의 Edge 간에 BFD 세션을 구성하지 않습니다.

    이 수정 이전에는 관리/TEP 인터페이스의 BFD 패킷이 허용되는 최대 홉 수에 관계없이 단일 홉 BFD 포트를 사용하여 전송되었습니다. 이제 단일 홉 및 다중 홉 BFD 포트가 모두 지원됩니다. Edge-클러스터 프로파일의 허용되는 최대 BFD 홉을 하나로 구성하는 경우 단일 홉 BFD가 사용됩니다. 1보다 큰 값의 경우 다중 홉 BFD가 사용됩니다. 허용되는 최대 홉의 기본값은 255입니다. 이전 릴리스에서 업그레이드하면 분할 브레인이 발생하지 않습니다. 업그레이드하는 동안 단일 홉 BFD 포트가 사용됩니다. 업그레이드 후에는 구성에 반영된 포트가 사용됩니다.

  • 해결된 문제 2275388 - 경로를 거부하는 필터가 추가되기 전에 루프백 인터페이스/연결된 인터페이스 경로가 재배포될 수 있습니다.

    불필요한 경로 업데이트를 수행하면 몇 초 동안 트래픽에서 차선의 라우팅이 발생할 수 있습니다. 

  • 해결된 문제 2275708 - 개인 키에 암호가 있으면 개인 키를 사용하여 인증서를 가져올 수 없습니다.

    "인증서에 대해 잘못된 PEM 데이터를 받았습니다 (오류 코드: 2002)."라는 메시지가 반환됩니다. 개인 키를 사용하여 새 인증서를 가져올 수 없습니다.

  • 해결된 문제 2378970 - 분산 방화벽에 대한 클러스터 수준 [사용]/[사용 안 함] 설정이 [사용 안 함]으로 잘못 표시됩니다.

    간소화된 UI의 IDFW에 대한 클러스터 수준 사용/사용 안 함 설정이 관리부에서 [사용]으로 설정되었지만 [사용 안 함]으로 표시될 수 있습니다. 2.4.x에서 2.5로 업그레이드한 후 명시적으로 변경할 때까지 이러한 부정확함이 지속됩니다. 

  • 해결된 문제 2292096 - "get service router config route-maps" CLI 명령이 빈 출력을 반환합니다.

    경로 맵이 구성되어 있는 경우에도 "get service router config route-maps" CLI 명령이 빈 출력을 반환합니다. 이는 표시 문제일 뿐입니다.

  • 해결된 문제 2416130 - CSP(중앙 집중식 서비스 포트)가 DR의 다운링크에 연결된 경우 ARP 프록시가 없습니다.

    CSP(중앙 집중식 서비스 포트)가 DR의 다운링크에 연결된 경우 ARP 프록시가 없기 때문에 트래픽이 통과하지 못합니다. 

  • 해결된 문제 2448006 - 규칙 매핑에서 일치하지 않는 방화벽 섹션의 쿼리가 실패합니다.

    GetSectionWithRules API 호출을 사용할 경우 규칙 매핑 불일치가 있는 방화벽 섹션을 쿼리하면 실패합니다. UI는 GetSection 및 GetRules API 호출에 따라 달라지기 때문에 영향을 받지 않습니다.

  • 해결된 문제 2441985 - 일부 경우에 NSX-T Data Center 2.5.0에서 NSX-T Data Center 2.5.1로의 호스트 실시간 업그레이드가 실패할 수 있습니다.

    일부 경우에 NSX-T Data Center 2.5.0에서 NSX-T Data Center 2.5.1로의 호스트 실시간 업그레이드가 실패하고 다음 오류가 표시됩니다.
    업그레이드 단위를 업그레이드하는 동안 예기치 않은 오류가 발생했습니다. 다음 오류를 나타내며 호스트 34206ca2-67e1-4ab0-99aa-488c3beac5cb에서 오프라인 번들 설치가 실패했습니다. ['/etc/init.d/nsx-datapath', 'start', 'upgrade'] 실행 동안 [LiveInstallationError] 오류 발생: 반환 코드: 1 출력: ioctl 실패: 이러한 파일 또는 디렉터리가 시작되지 않음 업그레이드 시작 예외: Traceback(가장 최근 호출을 맨 마지막에 표시): File "/etc/init.d/nsx-datapath", line 1394, in CheckAllFiltersCleared() File "/etc/init.d/nsx-datapath", line 413, in CheckAllFiltersCleared if FilterIsCleared(): File "/etc/init.d/nsx-datapath", line 393, in FilterIsCleared output = os.popen(cmd).read() File "/build/mts/release/bora-13885523/bora/build/esx/release/vmvisor/sys-boot/lib64/python3.5/os.py", line 1037, in popen File "/build/mts/release/bora-13885523/bora/build/esx/release/vmvisor/sys-boot/lib64/python3.5/subprocess.py", line 676, in __init__ File "/build/mts/release/bora-13885523/bora/build/esx/release/vmvisor/sys-boot/lib64/python3.5/subprocess.py", line 1228, in _execute_child OSError: [Errno 28] 디바이스에 남은 공간이 없습니다. 계속하면 안전하지 않습니다. 완료되지 않은 업데이트를 삭제하려면 호스트를 즉시 재부팅하십시오. 자세한 내용은 로그 파일을 참조하십시오.

  • 해결된 문제 2477859 - 드문 경우지만 데이터 마이그레이션 작업 중에 NSX Manager 업그레이드가 실패할 수 있습니다.

    NSX-T Data Center 2.5.1로 업그레이드하는 경우 이전 버전의 논리적 라우터 삭제가 올바르게 처리되지 않은 매우 드문 시나리오에서, 이 오류가 발생하여 데이터 마이그레이션 작업 중에 NSX Manager 업그레이드가 실패할 수 있습니다. NullPointer 예외.

  • 해결된 문제 2481033 - 전원이 켜진 VM이 있는 호스트에 연결된 ESXi 호스트 전송 노드 및 전송 노드 프로파일을 업데이트하면 다음 오류를 나타내며 실패합니다. “호스트에 전원이 켜진 VM이 있습니다. 전송 노드 생성/업데이트/삭제를 수행하려면 해당 VM을 이동하거나 전원을 꺼야 합니다.”

    VMK 마이그레이션이 지정되어 있고 해당 ESXi 호스트에 전원이 켜진 VM이 있는 경우 ESXi 호스트 전송 노드(TN)의 업데이트가 실패합니다. TNP의 VMK 마이그레이션 설정과 관계없이 이러한 TN에 연결된 전송 노드 프로파일(TNP)에 대한 업데이트가 실패합니다. 이 문제는 전원이 켜진 VM으로 인해 마이그레이션 유효성 검사가 실패하여 TN 또는 TNP가 업데이트되지 못하기 때문에 발생합니다.

  • 해결된 문제 2483552 - 2.4.x에서 2.5.x로 업그레이드한 후 "nsx-exporter" 바이너리가 호스트에서 제거됨

    NSX-T Data Center를 버전 2.4.x에서 버전 2.5.x로 업그레이드한 후 nsx-exporter(/opt/vmware/nsx-exporter) 및 nsx-aggservice(/opt/vmware/nsx-aggservice)의 바이너리를 제거하면 nsx-exporter 실행이 중지됩니다.

알려진 문제

알려진 문제는 다음과 같이 분류됩니다.

일반적인 알려진 문제
  • 문제 2320529 - 새로 추가된 데이터스토어에 대해 타사 VM을 추가한 후 “서비스 배포를 위해 스토리지에 액세스할 수 없습니다.” 오류가 발생함.

    클러스터의 모든 호스트에서 스토리지에 액세스할 수 있는 경우에도, 새로 추가된 데이터스토어에 대해 타사 VM을 추가한 후 "서비스 배포를 위해 스토리지에 액세스할 수 없습니다." 오류가 발생합니다. 이 오류 상태는 최대 30분 동안 지속됩니다.

    30분 후에 다시 시도하십시오. 또는 다음 API를 호출하여 데이터스토어의 캐시 항목을 업데이트하십시오.

    https://<nsx-manager>/api/v1/fabric/compute-collections/<CC Ext ID>/storage-resources?uniform_cluster_access=true&source=realtime

    여기서   <nsx-manager>는 서비스 배포 API가 실패한 NSX Manager의 IP 주소이고, < CC Ext ID>는 배포가 시도되는 클러스터의 NSX에 있는 식별자입니다.

  • 문제 2328126 - 베어메탈 문제: Linux OS 결합 인터페이스가 NSX 업링크 프로파일에서 사용될 때 오류를 반환함.

    Linux OS에서 결합 인터페이스를 생성한 다음, NSX 업링크 프로파일에서 이 인터페이스를 사용하면 다음과 같은 오류 메시지가 표시됩니다. "전송 노드를 생성하지 못할 수 있습니다." 이 문제는 VMware가 Linux OS 결합을 지원하지 않기 때문에 발생합니다. 그렇지만 VMware는 베어메탈 서버 전송 노드에 대해 OVS(Open vSwitch) 결합을 지원합니다.

    해결 방법: 이 문제가 발생한 경우 기술 자료 67835 베어메탈 서버가 NSX-T의 전송 노드 구성에 대해 OVS 결합을 지원함을 참조하십시오.

  • 문제 2390624 - 반선호도 규칙은 호스트가 유지 보수 모드일 때 vMotion에서 서비스 VM을 차단합니다.

    서비스 VM이 정확히 두 개의 호스트가 있는 클러스터에 배포된 경우 반선호도 규칙이 있는 HA 쌍은 유지 보수 모드 작업 중에 VM이 다른 호스트로 vMotion되지 않도록 합니다. 이로 인해 호스트가 자동으로 유지 보수 모드로 전환되지 않을 수 있습니다.

    해결 방법: vCenter에서 유지 보수 모드 작업이 시작되기 전에 호스트에서 서비스 VM의 전원을 끄십시오.

  • 문제 2389993 - 정책 페이지 또는 API를 사용하여 재배포 규칙을 수정한 후 경로 맵이 제거되었습니다.

    재배포 규칙에서 관리부 UI/API를 사용하여 추가된 경로 맵이 있는 경우, 간소화(정책) UI/API의 동일한 재배포 규칙을 수정하면 해당 경로 맵이 제거됩니다.

    해결 방법: 관리부 인터페이스 또는 API를 반환하여 경로 맵을 복원함으로써 동일한 규칙에 다시 추가할 수 있습니다. 재배포 규칙에 경로 맵을 포함하려는 경우 항상 관리부 인터페이스 또는 API를 사용하여 생성 및 수정하는 것이 좋습니다.

  • 문제 2329273 - 동일한 Edge 노드에서 동일한 세그먼트로 브리징된 VLAN 간에 연결이 없습니다.

    동일한 Edge 노드에서 한 세그먼트를 두 번 브리징하는 것은 지원되지 않습니다. 하지만 두 개의 VLAN을 두 개의 서로 다른 Edge 노드에 있는 동일한 세그먼트로 브리징할 수 있습니다.

    해결 방법: 없음 

  • 문제 2355113 - Microsoft Azure에서 가속화된 네트워킹을 사용하도록 설정한 상태로 RedHat 및 CentOS 워크로드 VM에 NSX Tools를 설치할 수 없습니다.

    Microsoft Azure에서 RedHat(7.4 이상) 또는 CentOS(7.4 이상) 기반 OS에서 가속화된 네트워킹을 사용하도록 설정하고 NSX 에이전트를 설치한 경우 이더넷 인터페이스에서 IP 주소를 가져오지 않습니다.

    해결 방법: Microsoft Azure에서 RedHat 또는 CentOS 기반 VM을 부팅한 후 NSX Tools를 설치하기 전에 https://www.microsoft.com/en-us/download/details.aspx?id=55106에서 사용할 수 있는 최신 Linux 통합 서비스 드라이버를 설치하십시오.

  • 문제 2370555 - 사용자가 고급 인터페이스에서 특정 개체를 삭제할 수 있지만, 해당 삭제가 단순화된 인터페이스에 반영되지 않습니다.

    특히, 분산 방화벽 제외 목록의 일부로 추가된 그룹은 고급 인터페이스 분산 방화벽 제외 목록 설정에서 삭제할 수 있습니다. 이로 인해 인터페이스에서 일관되지 않은 동작이 발생합니다.

    해결 방법: 이 문제를 해결하려면 다음 절차를 사용하십시오.

    1. 단순화된 인터페이스의 제외 목록에 개체를 추가합니다.
    2. 해당 개체가 고급 인터페이스의 분산 방화벽 제외 목록에 표시되는지 확인합니다.
    3. 고급 인터페이스의 분산 방화벽 제외 목록에서 개체를 삭제합니다.
    4. 단순화된 인터페이스에서 제외 목록의 두 번째 개체로 돌아온 후 해당 개체를 적용합니다.
    5. 새 개체가 고급 인터페이스에 나타나는지 확인합니다.
  • 문제 2520803 - EVPN 배포에서 수동 경로 구분자 및 경로 대상 구성에 대한 인코딩 형식

    현재 유형-0 인코딩과 유형-1 인코딩에서 수동 경로 구분자를 구성할 수 있습니다. 그러나 EVPN 배포에서 수동 경로 구분자를 구성하기 위해 유형-1 인코딩 체계를 사용하는 것이 좋습니다. 또한 수동 경로 대상 구성에 대해 유형 0 인코딩만 허용됩니다.

    해결 방법: 경로 구분자에 대해 Type-1 인코딩만 구성합니다.

  • 문제 2490064 - "외부 LB"가 설정된 VMware Identity Manager를 사용하지 않도록 설정하려고 하면 작동하지 않습니다.

    "외부 LB"가 있는 NSX에서 VMware Identity Manager 통합을 사용하도록 설정한 후 "외부 LB"를 해제하여 통합을 사용하지 않도록 설정하면 약 1분 후에 초기 구성이 다시 표시되고 로컬 변경 내용을 덮어씁니다.

    해결 방법: vIDM을 사용하지 않도록 설정하려고 할 경우 외부 LB 플래그를 해제하지 말고 vIDM 통합만 해제하십시오. 이렇게 하면 해당 구성이 데이터베이스에 저장되고 다른 노드와 동기화됩니다.

  • 문제 2516481 - 1개의 UA 노드가 새로운 API 호출 수락을 중지하고 "서버가 오버로드되었습니다." 메시지가 표시됩니다.

    1개의 UA 노드가 새로운 API 호출 수락을 중지하고 "서버가 오버로드되었습니다." 메시지가 표시됩니다. 약 200개의 연결이 CLOSE_WAIT 상태에서 중지되었습니다. 이러한 연결은 아직 닫히지 않았습니다. 새 API 호출은 거부됩니다.

    해결 방법:

    다음 명령을 사용하여 proton 서비스를 다시 시작합니다. 

    service proton restart

     

  • 문제 2529228 - 백업 및 복원 후, 시스템의 인증서가 일관되지 않은 상태가 되고 고객이 백업 시 설정한 인증서가 사라집니다.

    역방향 프록시 및 APH는 백업 된 클러스터에서 사용한 것과는 다른 인증서를 사용하기 시작합니다.

    해결 방법:

    1. 3개의 새 노드에서 Tomcat 인증서를 업데이트하고 API POST /api/v1/node/services/http?action=apply_certificate&certificate_id=<cert-id>를 사용하여 원래 상태(백업된 클러스터와 동일한 상태)로 다시 전환합니다. 인증서 ID는 원래 설정(백업된 클러스터)에서 사용 중이던 tomcat 인증서의 ID에 해당합니다.
    2. API POST /api/v1/cluster/api-certificate?action=set_cluster_certificate&certificate_id=<cert-id>를 사용하여 기본 노드에서 클러스터 인증서를 적용합니다. 인증서 ID는 원래 설정(백업된 클러스터)에서 사용 중이던 클러스터 인증서의 ID에 해당합니다.
    3. 3개의 새 노드에서 APH 인증서를 업데이트하고 API POST /api/v1/trust-management/certificates?action=set_appliance_proxy_certificate_for_inter_site_communication을 사용하여 원래 상태(백업된 클러스터와 동일한 상태)로 다시 전환합니다.
    4. GET /api/v1/trust-management/certificates의 출력(특히 used_by 섹션)을 검사하고, 루트 명령줄에서 다음을 사용하여 이전 노드 uuid(백업이 수행된 클러스터의 노드 uuid)에 연결된 모든 인증서를 해제합니다. "curl -i -k -X POST -H 'Content-type: application/json' -H 'X-NSX-Username:admin' -H 'X-NSX-Groups:superuser' -T data.json "http://127.0.0.1:7440/nsxapi/api/v1/trust-management/certificates/cert-id?action=release". 이 API는 로컬 전용이며 클러스터에 있는 한 노드의 명령줄에서 root 권한으로 실행해야 합니다. 이전 노드 uuid(백업이 수행된 클러스터의 노드 uuid)에 연결된 모든 인증서에 대해 이 단계를 수행해야 합니다. 
    5. 이제 사용되지 않은 모든 인증서를 삭제하고 "/api/v1/trust-management/certificates" 및 클러스터 안정성을 확인합니다.
  • 문제 2535793 - CNC(중앙 노드 구성) 사용 안 함 플래그가 관리자 노드에서 적용되지 않습니다.

    사용자가 CNC 프로파일을 변경하면(UI의 [시스템] -> [패브릭] -> [프로파일]을 참조) 해당 관리자 노드에서 CNC가 로컬로 사용하지 않도록 설정되더라도(CLI set node central-config disabled 참조) 관리자 노드에서 로컬로 변경한 NTP, syslog, SNMP 구성 항목이 덮어쓰입니다. 하지만 로컬 NTP, syslog, SNMP 구성은 CNC 프로파일이 변경되지 않는 한 유지됩니다.

    해결 방법:

    두 가지 옵션이 있습니다.

    • 옵션 1은 로컬 변경 없이 CNC를 사용하는 것입니다(즉, get node central-config를 Enabled로 지정).
    • 옵션 2는 CNC 프로파일을 지우고 NTP, syslog, SNMP 설정에 맞춰 각 관리자를 개별적으로 구성하는 것입니다. 옵션 1에서 옵션 2로 전환하려면 다음 해결 방법을 사용하십시오.
    1. CNC 프로파일에서 모든 구성을 삭제합니다.
    2. 잠시 후에 모든 관리자 및 Edge 노드에서 구성이 삭제되었는지 확인합니다(각 노드에서 노드 API 또는 CLI 사용). 또한 SNMP 구성이 모든 KVM HV 노드에서 삭제되었는지 확인합니다.
    3. 각 관리자 및 Edge 노드에서 NTP, syslog 및 SNMP를 개별적으로 구성합니다(NSX 노드 API 또는 CLI 사용).
    4. VMware SNMP 에이전트 구성 명령을 사용하여 각 KVM HV 노드에서 VMware SNMP 에이전트를 개별적으로 구성합니다.
  • 문제 2537989 - VIP(가상 IP)를 지울 경우 일부 노드에서 vIDM 통합이 지워지지 않습니다.

    가상 IP가 있는 클러스터에서 VMware Identity Manager가 구성되어 있으면 가상 IP를 사용하지 않도록 설정해도 클러스터 전체에서 VMware Identity Manager 통합이 지워지는 것은 아닙니다. VIP를 사용하지 않도록 설정한 경우 각 개별 노드에서 vIDM 통합을 수동으로 수정해야 합니다.

    해결 방법: 각 노드로 개별적으로 이동하여 각 노드에서 vIDM 구성을 수동으로 수정합니다.

  • 문제 2538956 - DHCP 프로파일에 "NOT SET" 메시지가 표시되고, 세그먼트에서 게이트웨이 DHCP를 구성할 때 [적용] 버튼이 사용되지 않도록 설정됩니다.

    연결된 게이트웨이에 구성된 DHCP가 없을 때 세그먼트에서 게이트웨이 DHCP를 구성하려고 하면 저장할 유효한 DHCP가 없기 때문에 DHCP 프로파일을 적용할 수 없습니다.

    해결 방법: 없음.

  • 문제 2525205 - 특정 상황에서 관리부 클러스터 작업이 실패합니다.

    관리자 N2에서 "join" 명령을 실행하여 관리자 N2를 관리자 N1에 연결하려고 하면 join 명령이 실패합니다. 관리부 클러스터를 구성할 수 없으므로 가용성에 영향을 줄 수 있습니다.

    해결 방법:

    1. 클러스터에 관리자 N1을 유지하려면 관리자 N1에 대해 "deactivate" CLI 명령을 실행합니다. 이렇게 하면 클러스터의 다른 모든 관리자가 제거되고 관리자 N1이 클러스터의 유일한 멤버가 됩니다.
    2. "systemctl start corfu-nonconfig-server" 명령을 실행하여 비구성 Corfu 서버가 관리자 N1에서 실행 중인지 확인합니다.
    3. "join" 명령을 실행하여 다른 새 관리자를 클러스터에 연결합니다.
  • 문제 2526769 - 다중 노드 클러스터에서 복원이 실패합니다.

    다중 노드 클러스터에서 복원을 시작하면 복원이 실패하고 장치를 다시 배포해야 합니다.

    해결 방법: 새 설정을 배포하고(노드 클러스터 1개) 복원을 시작합니다.

  • 문제 2538041 - 글로벌 관리자에서 관리자 모드 IP 집합을 포함하는 그룹을 생성할 수 있습니다.

    글로벌 관리자를 사용하면 관리자 모드에서 생성된 IP 집합이 포함된 그룹을 생성할 수 있습니다. 구성이 수락되지만 로컬 관리자에서 그룹이 구현되지 않습니다.

    해결 방법: 없음.

  • 문제 2463947 - 선점형 모드 HA가 구성되고 IPSec HA가 사용되도록 설정된 경우, 이중 페일오버 시 VPN을 통한 패킷 손실이 확인됩니다.

    VPN을 통한 트래픽이 피어 측에서 삭제됩니다. IPSec 재생 오류가 늘어납니다.

    해결 방법: 다음 IPSec 키가 재생성될 때까지 기다립니다. 또는 특정 IPSec 세션을 사용하지 않도록 설정했다가 사용하도록 설정합니다.

  • 문제 2515006 - NSX-v에서 NSX-T로의 마이그레이션 롤백이 간헐적으로 실패합니다.

    NSX-v에서 NSX-T로 마이그레이션하는 동안 롤백이 실패하고 다음 메시지가 표시됩니다. "엔티티 Edge 클러스터 <edge-cluster-id>가 엔티티 <logical-router-id>로 참조되고 있으므로 삭제할 수 없습니다."

    해결 방법: 실패 후 10-15분 동안 기다렸다가 롤백을 다시 시도합니다. 그래도 실패하면 NSX-T 장치 및 Edge를 삭제하고 다시 배포한 다음, 마이그레이션을 다시 시작합니다.

  • 문제 2523212 - nsx-policy-manager가 응답하지 않고 다시 시작됩니다.

    nsx-policy-manager에 대한 API 호출이 실패하고 서비스를 사용할 수 없게 됩니다. 다시 시작하여 사용할 수 있게 될 때까지 정책 관리자에 액세스할 수 없게 됩니다.

    해결 방법: 최대 2,000개의 개체로 API를 호출합니다.

  • 문제 2482672 - L2VPN을 통해 확장되는 격리된 오버레이 세그먼트가 피어 사이트의 기본 게이트웨이에 연결할 수 없습니다.

    T0/T1 오버레이 세그먼트가 사이트 1에서 L2VPN을 통해 확장되고 격리된 오버레이 세그먼트가 사이트 2에서 L2VPN을 통해 확장되도록 사이트 1과 사이트 2 간에 L2VPN 터널이 구성됩니다. 또한 동일한 전송 영역의 사이트 2에 다른 T0/T1 오버레이 세그먼트가 있으며, 격리된 세그먼트에 연결된 워크로드 VM이 있는 ESXi 호스트에 DR 인스턴스가 있습니다.

    격리된 세그먼트(사이트 2)의 VM이 기본 게이트웨이(사이트 1에 있는 DR 다운링크)에 연결하려고 하면 기본 게이트웨이로의 유니캐스트 패킷이 사이트 2 ESXi 호스트에서 수신되고 원격 사이트로 전달되지 않습니다. 피어 사이트의 기본 게이트웨이에 대한 L3 연결이 실패합니다.

    해결 방법: 사이트 2의 격리된 오버레이 세그먼트를 LR에 연결하고 사이트 1과 동일한 게이트웨이 IP 주소를 지정합니다.

  • 문제 2521071 - 글로벌 관리자에서 생성된 세그먼트의 경우 BridgeProfile 구성이 있으면 계층 2 브리징 구성이 개별 NSX 사이트에 적용되지 않습니다.

    세그먼트의 통합 상태는 "오류"로 유지됩니다. 이 문제는 지정된 NSX 사이트에서 브리지 끝점을 생성하지 못하기 때문에 발생합니다. 글로벌 관리자를 통해 생성된 세그먼트에서 BridgeProfile을 성공적으로 구성할 수 없습니다.

    해결 방법: NSX 사이트에서 세그먼트를 생성하고 브리지 프로파일을 사용하여 구성합니다.

  • 문제 2527671 - DHCP 서버가 구성되지 않은 경우 Tier0/Tier1 게이트웨이 또는 세그먼트에서 DHCP 통계/상태를 검색하면 구현이 실패했다는 오류 메시지가 표시됩니다.

    기능에는 영향을 미치지 않습니다. 이 오류 메시지는 올바르지 않으며 DHCP 서버가 구성되지 않은 것으로 보고해야 합니다.

    해결 방법: 없음.

  • 문제 2532127 - LDAP 사용자는 사용자의 Active Directory 항목에 UPN(userPrincipalName) 특성이 포함되어 있지 않고 samAccountName 특성만 포함되어 있을 때만 NSX에 로그인할 수 없습니다.

    사용자 인증이 실패하고 사용자가 NSX 사용자 인터페이스에 로그인할 수 없습니다.

    해결 방법: 없음.

  • 문제 2533617 - 서비스를 생성, 업데이트 또는 삭제하는 동안 API 호출이 성공하지만 서비스 엔티티 업데이트 구현이 실패합니다.

    서비스(NatRule, LB VIP 등)를 생성, 업데이트 또는 삭제하는 동안 API 호출이 성공하지만 백그라운드의 작업 제출 실패로 인해 서비스 엔티티 업데이트가 처리되지 않습니다. 서비스에 액세스할 수 없게 됩니다.

    해결 방법: 구현이 실패한 서비스 엔티티가 있는 논리적 라우터에 대해 ReProcessLogicalRouter API를 수동으로 실행하십시오.

  • 문제 2540733 - 클러스터에서 동일한 호스트를 다시 추가하면 서비스 인스턴스가 생성되지 않습니다.

    호스트에 서비스 VM이 있는 경우에도 클러스터에서 동일한 호스트를 다시 추가하면 NSX의 서비스 인스턴스가 생성되지 않습니다. 배포 상태가 성공으로 표시되지만 지정된 호스트의 보호가 종료됩니다.

    해결 방법: 호스트에서 서비스 VM을 삭제합니다. 이렇게 하면 NSX 사용자 인터페이스에 표시되는 문제가 생성됩니다. 문제를 해결하는 동안 NSX의 새 SVM 및 해당 서비스 인스턴스가 생성됩니다.

  • 문제 2532796 - 최신 Windows KB 업데이트에서 HNSEndpoint를 삭제하지 못했습니다.

    Windows를 최신 KB 업데이트(2020년 3월까지)로 업데이트하면 HNSEndpoint의 삭제가 중단됩니다. Windows 컨테이너 인스턴스는 삭제할 수 없습니다. 이로 인해 동일한 HNSEndpoint 이름을 사용하여 새 컨테이너를 생성할 때 충돌이 발생할 수 있습니다.

    해결 방법: 없음.

  • 문제 2530822 - vCenter에서 NSX-T 확장이 생성되었지만 NSX Manager에 vCenter를 등록하지 못합니다.

    vCenter에서 "com.vmware.nsx.management.nsxt” 확장이 생성되더라도 NSX에서 vCenter를 계산 관리자로 등록하면 NSX-T에서 계산 관리자 등록 상태가 “등록되지 않음”으로 유지됩니다. Edge의 자동 설치와 같은 vCenter의 작업을 vCenter Server 계산 관리자를 사용하여 수행할 수 없습니다.

    해결 방법:

    1. NSX-T Manager에서 계산 관리자를 삭제합니다.
    2. vCenter 관리 개체 브라우저를 사용하여 vCenter에서 "com.vmware.nsx.management.nsxt" 확장을 삭제합니다.
  • 문제 2482580 - IDFW/IDS 클러스터가 vCenter에서 삭제될 때 IDFW/IDS 구성이 업데이트되지 않습니다.

    IDFW/IDS가 사용되도록 설정된 클러스터가 vCenter에서 삭제되면 NSX 관리부에 필요한 업데이트에 대한 알림이 표시되지 않습니다. 이로 인해 IDFW/IDS 지원 클러스터의 수가 부정확해집니다. 기능에는 영향을 미치지 않습니다. 사용하도록 설정된 클러스터의 개수만 올바르지 않습니다.

    해결 방법: 없음.

  • 문제 2533365 - 호스트를 IDFW 지원 클러스터에서 새 클러스터로 이동할 경우(이전에는 IDFW에 대해 사용/사용 안 함으로 절대 설정되지 않음) 이동된 호스트에서 IDFW가 사용하지 않도록 설정되지 않습니다.

    호스트를 IDFW 지원 클러스터에서 다른 클러스터로 이동할 경우(이전에는 IDFW에 대해 사용/사용 안 함으로 절대 설정되지 않음) IDFW가 이동된 호스트에서 사용하도록 설정됩니다. 이렇게 하면 이동된 호스트에서 의도치 않은 IDFW 규칙이 적용됩니다.

    해결 방법: 클러스터 2에서 IDFW를 사용하도록 설정했다가 사용하지 않도록 설정합니다. 이렇게 하면 이러한 클러스터 간에 호스트를 이동하거나 나중에 이러한 클러스터에서 IDFW를 사용/사용 안 함으로 설정할 수 있습니다.

  • 문제 2536877 - XFF(X-Forwarded-For)는 전송 단계에서 로드 밸런서 규칙이 구성된 잘못된 데이터(HTTPS 트래픽)를 표시합니다.

    전송 단계에서 로드 밸런서 규칙을 지정하여 XFF(INSERT/REPLACE)로 HTTP 프로파일을 구성하는 경우 잘못된 XFF 헤더 값이 표시될 수 있습니다.

    해결 방법: 변수 조건 및 일치를 사용하여 "요청 재작성 단계"에서 로드 밸런서 규칙을 구성합니다(빌드 내 변수 사용). 이렇게 하면 우선 순위가 적용되고 X-Forwarded-For 및 X-Forwarded-Port의 잘못된 값이 올바른 값으로 바뀝니다.

  • 문제 2534855 - 간소화된 UI 또는 정책 API에서 생성된 Tier-0 게이트웨이의 경로 맵과 재배포 규칙이 고급 UI(또는 MP API)에서 생성된 경로 맵과 재배포 규칙을 대체합니다.

    업그레이드하는 동안 간소화된 UI(또는 정책 API)에서 생성된 기존 경로 맵과 규칙은 고급 UI(또는 MP API)에서 직접 수행된 구성을 대체합니다.

    해결 방법: 업그레이드후에 고급 UI(MP UI)에 생성된 재배포 규칙/경로 맵이 손실되면 고급 UI(MP) 또는 간소화된 UI(정책)에서 모든 규칙을 생성할 수 있습니다. NSX-T 3.0에서는 재배포에 완전히 지원되는 기능이 있으므로 항상 재배포 규칙에 대해 정책과 MP를 동시에 사용하지 말고 둘 중 하나만 사용하십시오.

  • 문제 2535355 - 특정 상황에서 NSX-T 3.0으로 업그레이드한 후 세션 타이머가 적용되지 않을 수 있습니다.

    세션 타이머 설정이 적용되지 않습니다. 연결 세션(예: tcp established, tcp fin wait)은 사용자 지정 세션 타이머 대신 시스템 기본 세션 타이머를 사용합니다. 이로 인해 연결(tcp/udp/icmp) 세션이 예상보다 길거나 더 짧게 설정될 수 있습니다.

    해결 방법: 없음.

  • 문제 2534933 - LDAP 기반 CDP(CRL 배포 지점)가 있는 인증서를 tomcat/cluster 인증서로 적용하지 못합니다.

    LDAP CDP가 있는 CA 서명 인증서를 cluster/tomcat 인증서로 사용할 수 없습니다.

    해결 방법: VMware 기술 자료 문서 78794를 참조합니다.

  • 문제 2538557 - IP 검색 프로파일에서 ARP 스누핑이 사용하도록 설정된 경우 ARP 패킷에 있는 Spoofguard가 작동하지 않을 수 있습니다.

    IP 검색 프로파일에서 Spoofguard 및 ARP 스누핑이 사용하도록 설정된 경우에도 게스트 VM의 ARP 캐시 항목이 잘못될 수 있습니다. Spoofguard 기능이 ARP 패킷에서 작동하지 않습니다.

    해결 방법: ARP 스누핑을 사용하지 않도록 설정합니다. IP 검색 프로파일 또는 수동 바인딩에서 VMtools 또는 DHCP 스누핑 옵션을 사용합니다.

  • 문제 2550327 - 초안 기능이 글로벌 관리자에서 지원되지 않지만 초안 API는 사용할 수 있습니다.

    초안 기능이 글로벌 관리자 UI에서 사용하지 않도록 설정됩니다. 초안 게시가 예상대로 작동하지 않을 수 있으며 글로벌 관리자와 로컬 관리자 방화벽 구성 간의 불일치가 발생할 수 있습니다.

    해결 방법: 수동으로 이전 방화벽 구성으로 되돌립니다.

  • 문제 2499819 - vMotion 오류로 인해 유지 보수를 토대로 하는 NSX for vSphere에서 vCenter 6.5 또는 6.7용 NSX-T Data Center 호스트로 마이그레이션하는 데 실패할 수 있습니다.

    이 오류 메시지는 호스트 마이그레이션 페이지에 다음과 같이 표시됩니다.
    호스트 마이그레이션 동안 마이그레이션 전 단계가 실패했습니다. [이유: [vMotion] 마이그레이션을 진행할 수 없음: vMotion vm b'3-vm_Client_VM_Ubuntu_1404-shared-1410’에 대한 최대 시도 횟수에 도달함].

    해결 방법: 호스트 마이그레이션을 다시 시도합니다.

  • 문제 2543239 - NSX-T Data Center 3.0.0으로 업그레이드한 이후에 NAT 트래픽 흐름이 특정 NAT 규칙에 대한 방화벽 처리를 수행하지 않습니다.

    이 문제는 NSX-T Data Center 3.0.0에서 방화벽 매개 변수 "없음"이 더는 사용되지 않기 때문에 발생합니다. 사용자 인터페이스에서 "없음"으로 방화벽 매개 변수를 사용하여 구성된 NAT 규칙 및 "Firewall_Match" 매개 변수 없이 API를 통해 구성된 NAT 규칙은 필요한 방화벽 규칙이 게이트웨이 방화벽에서 구성된 경우에도 방화벽 사후 업그레이드 처리를 수행하지 않습니다.

    해결 방법: 자세한 내용은 VMware 기술 자료 문서 79010을 참조하십시오.

  • 문제 2541923 - 글로벌 관리자에서 Tier-0 VRF 생성이 지원되지 않습니다.

    글로벌 관리자에서 단일 위치 Tier-0 게이트웨이에서 VRF를 구성할 수 있지만 이 구성은 지원되지 않습니다. 글로벌 관리자에서 확장된 Tier-0 게이트웨이에 VRF를 구성하는 경우 오류가 표시됩니다.

    해결 방법: 없음.

  • 문제 2518183 - 관리자 UI 화면의 경우 [경보] 열에 최신 경보 수가 항상 표시되지는 않습니다.

    최근에 생성된 경보가 관리자 엔터티 화면에 반영되지 않습니다.

    해결 방법:

    1. 관리자 엔티티 화면을 새로 고쳐 올바른 경보 수를 확인합니다.
    2. 경보 대시보드 페이지에서도 누락된 경보 세부 정보를 볼 수 있습니다.
  • 문제 2543353 - NSX T0 Edge가 IPsec 터널링 트래픽에 대해 잘못된 UDP 체크섬 사후 eSP 캡슐화를 계산합니다.

    UDP 패킷의 체크섬이 잘못되어 트래픽이 삭제되었습니다.

    해결 방법: 없음.

  • 문제 2561740 - NSGroup에서 업데이트되지 않은 유효 멤버 때문에 PAS 송신 DFW 규칙이 적용되지 않습니다.

    ConcurrentUpdateException으로 인해 논리적 포트 생성이 처리되지 않아 해당 NSGroup을 업데이트하지 못했습니다.

    해결 방법: 없음.

  • 문제 2572394 - SFTP 서버를 사용할 때 백업을 수행할 수 없습니다. 여기서는 "keyboard-interactive" 인증이 사용되도록 설정되었지만 "암호" 인증이 사용되지 않도록 설정되었습니다.

    SFTP 서버를 사용할 수 없습니다. 여기서는 "keyboard-interactive" 인증이 사용되도록 설정되었지만 "암호" 인증이 사용되지 않도록 설정되었습니다.

    해결 방법: Ubuntu 기반 서버를 SFTP 서버로 사용하거나 SFTP 서버에서 "암호" 인증을 사용하도록 설정합니다.

  • 문제 2577452: 글로벌 관리자에서 인증서를 바꾸면 이 글로벌 관리자에 추가된 위치에서 연결이 끊깁니다.

    글로벌 관리자에서 역방향 프록시 또는 APH(장치 프록시 허브) 인증서를 바꾸면 REST API 및 NSX RPC 연결이 끊어져서 이 글로벌 관리자에 추가된 위치와의 연결이 끊어집니다.

    해결 방법:

    • 다음 API를 사용하여 로컬 관리자 또는 글로벌 관리자의 인증서를 변경하는 경우 이 문제를 방지하기 위해 몇 가지 구성을 추가로 변경해야 합니다.
      • 노드 API 인증서 변경: POST https:// /api/v1/node/services/http?action=apply_certificate&certificate_id=
      • 클러스터 API 인증서 변경: POST https:// /api/v1/cluster/api-certificate?action=set_cluster_certificate&certificate_id=
      • 장치 프록시 인증서 변경: POST https:// /api/v1/trust-management/certificates?action=set_appliance_proxy_certificate_for_inter_site_communication
    • 로컬 관리자 노드 또는 클러스터에서 API 인증서를 변경하는 경우 글로벌 관리자에서 이 위치를 다시 추가해야 합니다.
    • 글로벌 관리자 노드 또는 클러스터에서 API 인증서를 변경하는 경우 글로벌 관리자에서 이전에 연결된 모든 위치를 다시 추가해야 합니다.
    • 로컬 관리자에서 장치 프록시 인증서를 변경하는 경우 "restart service applianceproxy"를 사용하여 클러스터의 모든 노드에서 장치 프록시 서비스를 다시 시작하고 글로벌 관리자에서 해당 위치를 다시 추가해야 합니다.

    NSX-T Data Center 설치 가이드의 위치 추가를 참조하십시오. 

  • 문제 2730634: 업그레이드 후 네트워킹 구성 요소 페이지에 "인덱스가 동기화되지 않습니다." 오류가 표시됩니다.

    업그레이드 후 네트워킹 구성 요소 페이지에 "인덱스가 동기화되지 않습니다." 오류가 표시됩니다.

    해결 방법: 관리자 자격 증명으로 NSX Manager에 로그인하고 "start search resync policy" 명령을 실행합니다. 네트워킹 구성 요소를 로드하는 데 몇 분 정도 걸립니다.

  • 문제 2761589: NSX-T 2.x에서 NSX-T 3.x로 업그레이드한 후 관리부의 기본 계층 3 규칙 구성이 DENY_ALL에서 ALLOW_ALL로 변경됩니다.

    이 문제는 규칙이 정책을 통해 구성되지 않은 경우와 관리부의 기본 계층 3 규칙에 삭제 작업이 있는 경우 발생합니다. 업그레이드 후 관리부의 기본 계층 3 규칙 구성이 DENY_ALL에서 ALLOW_ALL로 변경됩니다.

    해결 방법: 기본 계층 3 규칙의 작업을 정책 UI 사후 업그레이드에서 삭제로 설정합니다.

  • 문제 2959572: 기본 VRF에서 BGP를 사용하지 않도록 설정한 후 노드를 재부팅하면 BGP 연결이 끊어집니다.

    모든 VRF가 BGP로 구성된 다중 VRF 설정에서 재부팅 후 모든 BGP 구성이 손실됩니다. 이 문제는 재부팅하기 전에 기본 VRF에서 BGP를 사용하지 않도록 설정한 경우에 발생할 수 있습니다.

    해결 방법: 기본 VRF에서 BGP를 사용하도록 설정합니다. 모든 연결이 복원될 때까지 기다렸다가 기본 VRF에서 BGP를 다시 끕니다.

설치에 대한 알려진 문제
  • 문제 2522909 - Invaildurl를 나타내며 업그레이드 배포가 실패한 경우 url을 수정한 후 서비스 vm 업그레이드가 작동하지 않습니다.

    업그레이드가 잘못된 url을 사용하여 실패 상태가 되며 업그레이드가 차단됩니다.

    해결 방법: 업그레이드가 트리거할 새 deployment_spec을 생성합니다.

  • 문제 2530110 - NSX-T Data Center 3.0.0으로 업그레이드하거나 NSX Manager 노드를 다시 시작한 후에 클러스터 상태가 저하됩니다.

    다시 시작된 노드의 모니터링 애플리케이션이 종료 상태일 때 MONITORING 그룹의 성능이 저하됩니다. 복원이 실패할 수 있습니다. 모니터링 애플리케이션이 종료 상태인 관리자의 경보가 표시되지 않을 수 있습니다.

    해결 방법: 모니터링 애플리케이션이 종료 상태인 영향을 받은 NSX-T Manager 노드를 다시 시작합니다.

업그레이드에 대한 알려진 문제
  • 문제 2546509 - vSphere 6.7에서 vSphere 7.0으로 ESXi를 업그레이드한 후 ESXi 7.0 NSX 커널 모듈이 설치되지 않습니다.

    ESXi 6.7에서 7.0으로 업그레이드한 후 전송 노드 상태가 종료됩니다.

    해결 방법: VMware 기술 자료 문서 78679를 참조합니다.

  • 문제 2541232 - NSX-T 3.0.0으로 업그레이드하면 CORFU/config 디스크 공간이 100%에 도달할 수 있습니다.

    이는 이전 버전의 NSX-T에서 AppDiscovery 기능을 사용하도록 설정된 상태로 업그레이드하는 경우에만 발생합니다. /Config 파티션은 100%에 도달하고 그 후 NSX 관리 클러스터가 불안정해집니다.

    해결 방법: 자세한 내용은 VMware 기술 자료 문서 78551을 참조하십시오.

  • 문제 2475963 - 공간 부족으로 인해 NSX-T VIB를 설치하지 못했습니다.

    ESXi 호스트의 부트 뱅크에 공간이 부족하여 NSX-T VIB가 설치되지 못하고 BootBankInstaller pyc를 반환합니다. 오류 타사 벤더에서 제공하는 일부 ESXi 이미지에는 사용되지 않고 크기가 비교적 커질 수 있는 VIB가 포함될 수 있습니다. 이로 인해 VIB를 설치/업그레이드할 때 bootbank/alt-bootbank에 공간이 부족해질 수 있습니다.

    해결 방법: 기술 자료 문서 74864 ESXi 호스트의 부트 뱅크에 공간이 부족하여 NSX-T VIB를 설치하지 못함을 참조하십시오.

  • 문제 2400379 - [컨텍스트 프로파일] 페이지에 지원되지 않는 APP_ID 오류 메시지가 표시됩니다.

    [컨텍스트 프로파일] 페이지에 다음과 같은 오류 메시지가 표시됩니다. “이 컨텍스트 프로파일은 지원되지 않는 APP_ID - [<APP_ID>]을(를) 사용합니다. 규칙에서 사용되고 있지 않은지 확인한 후 이 컨텍스트 프로파일을 수동으로 삭제하십시오.” 이 문제는 데이터 경로에서 더 이상 작동하지 않으며 사용되지 않는 6가지 APP_ID(AD_BKUP, SKIP, AD_NSP, SAP, SUNRPC, SVN)가 업그레이드 후에도 존재하기 때문에 발생합니다.

    해결 방법: 더 이상 사용되지 않는지 확인한 후에 6가지 APP_ID 컨텍스트 프로파일을 수동으로 삭제하십시오.

  • 문제 2462079 - ESXi 호스트에 오래된 DV 필터가 있는 경우 업그레이드 중에 ESXi 호스트의 일부 버전이 재부팅됩니다.

    유지 보수 모드를 NSX-T 2.5.1로 업그레이드하는 중 ESXi 6.5-U2/U3 및/또는 6.7-U1/U2를 실행하는 호스트의 경우 VM이 이동된 후 호스트에 오래된 DV 필터가 있으면 호스트가 재부팅될 수 있습니다.

    해결 방법: NSX-T Data Center 업그레이드 중에 호스트 재부팅을 방지하려면 NSX-T Data Center 2.5.1로 업그레이드하기 전에 ESXi 6.7 U3 또는 ESXi 6.5 P04로 업그레이드하십시오. 자세한 내용은 기술 자료 문서 76607을 참조하십시오.

  • 문제 2515489 - NSX-T 3.0으로 업그레이드한 후 첫 번째 인증서 기반 IPSec VPN 세션이 실행되지 못하고 "구성 실패" 오류를 표시합니다.

    하나의 인증서 기반 IPSec VPN 세션 아래에서 터널에 대해 트래픽 손실이 표시될 수 있습니다.

    해결 방법: CA 인증서를 제거하고 다시 추가하여 문제가 있는 IPSec VPN 세션의 로컬 끝점을 수정합니다. 이로 인해 동일한 로컬 끝점을 사용하는 모든 IPSec VPN 세션에 대해 세션 플랩이 발생합니다.

  • 문제 2536980 - "재부팅" 단계에서 PCG 업그레이드가 실패합니다.

    CSM 업그레이드 UI에서 PCG 업그레이드가 실패합니다. PCG CLI "get upgrade progress-status"를 실행하면 "reboot" 작업의 상태가 SUCCESS로 표시됩니다. PCG가 NSX-T 3.0으로 업그레이드하지 못하며 작동하지 않습니다.

    해결 방법: PCG 장치 CLI를 통해 실패한 PCG 업그레이드를 다음 순서로 완료하십시오.

    1. start upgrade-bundle VMware-NSX-public-gateway-<target-version> step migrate_users
      예: start upgrade-bundle VMware-NSX-public-gateway-3.0.0.0.0.34747521 step migrate_users
    2. start upgrade-bundle VMware-NSX-public-gateway-<target-version> step 41-postboot-exit_maintenance_mode
      예: start upgrade-bundle VMware-NSX-public-gateway-3.0.0.0.0.34747521 step 41-postboot-exit_maintenance_mode
    3. start upgrade-bundle VMware-NSX-public-gateway-<target-version> step finish_upgrade
      예: start upgrade-bundle VMware-NSX-public-gateway-3.0.0.0.0.34747521 step finish_upgrade
NSX Edge에 대한 알려진 문제
  • 문제 2283559 - https://<nsx-manager>/api/v1/routing-table 및 https://<nsx-manager>/api/v1/forwarding-table MP API는 Edge에 RIB에 대해 65k 이상의 경로, FIB에 대해 100k 이상의 경로가 있는 경우 오류를 반환합니다.

    Edge에 RIB에 대해 65k 이상의 경로와 FIB에 대해 100k 이상의 경로가 있으면 MP에서 Edge로 보내는 요청이 10초 이상 소요되어 결과적으로 시간이 초과됩니다. 이 API는 읽기 전용이며, API/UI를 사용하여 RIB에 대해 65k 이상의 경로와 FIB에 대해 100k 이상의 경로를 다운로드해야 하는 경우에만 영향을 줍니다.

    해결 방법: 두 가지 방법으로 RIB/FIB를 가져올 수 있습니다.

    • 이러한 API는 네트워크 접두사 또는 경로 유형에 기반하여 필터링 옵션을 지원합니다. 이러한 옵션을 사용하여 원하는 경로를 다운로드할 수 있습니다.
    • 전체 RIB/FIB 테이블이 필요하고 시간 초과가 없는 경우 CLI가 지원됩니다.
  • 문제 2513231 - 논리적 라우터당 (기본) 최대 arp 수는 20k입니다.

    Edge는 총 arp/neigh 항목을 Edge 노드당 10만 개, 논리적 라우터당 2만 개로 제한합니다. 이러한 제한에 도달하면 Edge는 더 많은 arp/neigh 항목을 arp 캐시 테이블에 추가할 수 없습니다. arp 확인이 실패하고 arp 확인이 수행되지 않기 때문에 패킷이 손실됩니다.

    해결 방법: 다음 CLI 명령을 사용하여 논리적 라우터당 arp 제한을 늘릴 수 있습니다.

    edge1> set dataplane neighbor     

  max-arp-logical-router          max-arp-logical-router

  max-arp-transport-node          max-arp-transport-node

  max-packet-held-transport-node  max-packet-held-transport-node


edge1> set debug

edge1> set dataplane neighbor max-arp-logical-router 30000

maximum number of arp per logical router: 30000

edge1> get dataplane neighbor info                        

arp cache timeout(s)                    : 1200

maximum number of arp per node          : 100000

number of arp entries per node          : 1

maximum number of mbuf held per node    : 1000

number of mbuf held per node            : 0

maximum number of arp per logical router: 30000

    참고: 사용된 최대 수는 지속되지 않습니다. datapathd가 다시 시작되거나 Edge 노드가 재부팅되면 동일한 명령을 다시 실행해야 합니다.

  • 문제 2521230 - 'get bgp neighbor summary’ 아래에 표시된 BFD 상태가 최신 BFD 세션 상태를 올바르게 반영하지 않을 수 있습니다.

    BGP 및 BFD는 세션을 독립적으로 설정할 수 있습니다. 'get bgp neighbor summary'의 일부로 BGP도 BFD 상태를 표시합니다. BGP가 종료되면 BFD 알림을 처리하지 않으며 마지막으로 알려진 상태를 계속 표시합니다. 이로 인해 BFD에 대해 이전 상태가 계속 표시될 수 있습니다.

    해결 방법: ‘get bfd-sessions’의 출력을 사용하고 '상태' 필드를 확인하여 최신 BFD 상태를 가져옵니다.

  • 문제 2532755 - routing-table의 CLI 출력 및 정책 출력이 일치하지 않습니다.

    UI에서 다운로드한 라우팅 테이블에 있는 경로 수가 CLI 출력과 비교할 때 더 많습니다. 정책에서 다운로드한 출력에 추가 경로(기본 경로)가 나열됩니다. 기능에는 영향을 미치지 않습니다.

    해결 방법: 없음.

NSX Cloud에 대한 알려진 문제
  • 문제 2289150 - AWS에 대한 PCM 호출이 시작되지 못합니다.

    CSM에서 AWS 계정의 PCG 역할을 old-pcg-role에서 new-pcg-role로 업데이트하면 CSM이 AWS에서 PCG 인스턴스에 대한 역할을 new-pcg-role로 업데이트합니다. 하지만 PCM은 PCG 역할이 업데이트되었다는 사실을 모르기 때문에 old-pcg-role을 사용하여 생성된 이전 AWS 클라이언트를 계속해서 사용합니다. 그 결과 AWS 클라우드 인벤토리 검색 및 기타 AWS 클라우드 호출이 실패합니다.

    해결 방법: 이 문제가 발생한 경우, 적어도 6.5시간 동안 새 역할로 변경한 직후에 이전 PCG 역할을 수정/삭제하지 마십시오. PCG를 다시 시작하면 모든 AWS 클라이언트가 새 역할 자격 증명을 사용하여 다시 초기화됩니다.

보안에 대한 알려진 문제
  • 문제 2491800 - AR 채널 SSL 인증서가 주기적으로 유효성을 검사하지 않으므로 기존 연결에서 만료/해지된 인증서를 사용하게 될 수 있습니다.

    만료/해지된 SSL을 사용하여 연결되어 있을 수 있습니다.

    해결 방법: 관리자 노드에서 APH를 다시 시작하여 재연결을 트리거합니다.

페더레이션의 알려진 문제
  • 문제 2533116 - 페더레이션 A에서 특정 사이트의 백업을 생성하고 페더레이션 B의 다른 사이트에서 복원하면 페더레이션 A의 사이트 세부 정보가 페더레이션 B에 잘못 추가됩니다.

    글로벌 관리자를 업그레이드한 후 백업 UI에 빈 페이지가 표시될 수 있습니다.

    해결 방법: 없음.

  • 문제 2532343 - 페더레이션 배포에서 RTEP MTU 크기가 VTEP MTU 크기보다 작은 경우 IP 조각화가 발생하여 물리적 라우터가 IP 조각과 IP 조각을 삭제하며 사이트 간 트래픽이 중지됩니다.

    RTEP MTU 크기(1500)가 VTEP MTU(1600)보다 작으면 tracepath 도구가 완료되지 않습니다. 대규모 ping(즉, ping -s 2000)도 실패합니다. 더 작은 RTEP MTU는 사용할 수 없습니다.

    해결 방법: RTEP 및 VTEP에서 동일한 MTU를 사용합니다.

  • 문제 2535234 - 크로스 vCenter vMotion 동안 VM 태그가 재설정됩니다.

    사이트 1에서 페더레이션 설정의 사이트 2로 vMotion을 수행했다가 30분 내에 사이트 1로 다시 vMotion을 실행하면 태그가 사이트 1에 적용된 태그로 재설정됩니다. VM 태그 기반 글로벌 정책을 사용하는 경우 정책이 적용되지 않습니다.

    해결 방법: 사이트 1에서 태그를 다시 적용합니다.

  • 문제 2630813 - 계산 VM에 대한 SRM 복구 또는 콜드 vMotion 시 VM 및 세그먼트 포트에 적용된 모든 NSX 태그가 손실됩니다.

    SRM 복구 테스트 또는 실행이 시작되면 재해 복구 위치의 복제된 계산 VM에 NSX 태그가 적용되지 않습니다. VM 콜드 vMotion을 다른 LM이 관리하는 다른 위치에 대한 콜드 vMotion의 경우에도 VM에서 해당 새 위치에 NSX 태그가 적용되지 않습니다.

  • 2630819: GM에서 LM을 등록하기 전에 LM 외부 VIP를 사용하지 않아야 합니다.

    페더레이션과 PKS를 동일한 LM에서 사용해야 하는 경우, 외부 VIP를 생성하고 LM 인증서를 변경하기 위한 PKS 작업을 GM에 LM을 등록하기 전에 수행해야 합니다. 이러한 작업을 반대 순서로 진행하면 LM 인증서를 변경한 후 LM 및 GM 사이의 통신이 불가능해지고 이 LM의 글로벌 구성이 손실됩니다.

  • 문제 2622672: 베어메탈 Edge 노드는 페더레이션에서 사용할 수 없습니다.

    RTEP(위치 간 통신)에는 베어메탈 Edge 노드를 구성할 수 없습니다.

  • 문제 2630808 - 3.0.0/3.0.1에서 상위 릴리스로의 업그레이드가 중단됩니다.

    글로벌 관리자 또는 로컬 관리자가 3.0.0/3.0.1에서 상위 릴리스로 업그레이드되는 즉시 GM과 LM 사이의 통신이 불가능해집니다.

    해결 방법: LM 및 GM 간의 통신을 복원하려면 모든 LM 및 GM을 상위 릴리스로 업그레이드해야 합니다.

check-circle-line exclamation-circle-line close-line
Scroll to top icon