I. 개요
NSX-T(Transformer)는 VMware의 또 다른 NSX 플랫폼으로, NSX-T는 VMware Photon 플랫폼과 통합됩니다. VMware NSX-T는 이기종 엔드포인트 및 기술 스택을 처리하는 새로운 애플리케이션 프레임워크 및 아키텍처를 위한 솔루션에 중점을 둡니다. 이러한 환경에는 vSphere 하이퍼바이저 외에도 다른 하이퍼바이저, 컨테이너, 베어메탈 및 퍼블릭 클라우드가 포함될 수 있습니다. NSX-T는 분산 방화벽, 논리적 스위칭 및 분산 라우팅을 제공합니다. NSX-V와 마찬가지로 NSX-T 아키텍처에는 독립적인 데이터 플레인, 제어 플레인 및 관리 플레인이 내장되어 있습니다 . NSX-T Data Center는 관리, 제어, 데이터라는 세 가지 별도의 통합 작업 영역을 구현하여 작동합니다. 이러한 작업 표면은 NSX Manager 및 전송 노드라는 두 가지 유형의 노드에 있는 일련의 프로세스, 모듈 및 에이전트로 구현됩니다.
2. 건축
NSX-T 아키텍처는 네 가지 기본 속성을 중심으로 설계되었습니다 . 위의 다이어그램은 모든 사이트, 클라우드, 엔드포인트 장치 전반에 걸쳐 이러한 속성의 보편성을 보여줍니다. 이를 통해 인프라 수준(예: 하드웨어, 하이퍼바이저)뿐만 아니라 퍼블릭 클라우드(예: AWS, Azure) 및 컨테이너 수준(예: K8, Pivotal)에서 더 큰 분리를 가능하게 하는 동시에 도메인 간 구현을 위한 플랫폼을 유지하면서 네 가지 주요 속성을 제공 합니다 . . NSX-T 아키텍처의 주요 가치 개념과 기능은 다음과 같습니다.
● 정책 및 일관성: RESTful API를 통해 일회성 정책 정의 및 최종 상태 구현을 허용하여 오늘날 자동화 환경의 요구 사항을 충족합니다. NSX-T는 여러 개의 독립적인 시스템 인벤토리 정보 및 제어를 유지하여 다양한 도메인에서 원하는 결과를 얻습니다.
● 네트워킹 및 연결 : 컴퓨팅 관리자/도메인에 바인딩하지 않고도 여러 vSphere 및 kvm 노드를 사용하여 일관된 논리적 스위칭 및 분산 라우팅을 허용합니다. 도메인별 구현을 통해 컨테이너와 클라우드 간의 연결이 더욱 확장되는 동시에 이기종 엔드포인트에 대한 연결도 제공됩니다.
● 보안 및 서비스 : 연결이 네트워크와 동일한 통합 보안 정책 모델을 사용하도록 허용합니다. 이를 통해 로드 밸런서, NAT, EDGEfw 및 dfw와 같은 서비스를 여러 컴퓨팅 도메인에 걸쳐 구현할 수 있습니다. 보안 운영 규칙에는 가상 머신과 컨테이너 워크로드 전반에 걸쳐 일관된 보안을 제공하는 것이 전체 프레임워크의 무결성을 보장하는 데 중요하다고 명시되어 있습니다.
● 가시성 : 컴퓨팅 도메인 전반에 걸쳐 공통 도구 세트를 통해 일관된 모니터링, 메트릭 수집 및 흐름 추적이 가능합니다. 이는 혼합 워크로드를 운영할 때 매우 중요합니다. 일반적으로 가상 머신에 중심을 둔 워크로드와 컨테이너에는 유사한 작업을 수행하기 위한 매우 다른 도구가 있습니다.
이러한 속성을 통해 이질성, 애플리케이션 일관성 및 확장성을 통해 다양한 요구 사항을 지원할 수 있습니다. 또한 NSX-T는 DPDK 라이브러리를 지원하여 유선 속도의 상태 저장 서비스(예: 로드 밸런서, NAT)를 제공합니다.
2.1 아키텍처 구성요소
NSX-T는 소프트웨어에서 전체 네트워크 서비스 세트(예: 스위칭, 라우팅, 방화벽 관리, QoS)를 복제합니다. 이러한 서비스는 어떤 조합으로든 프로그래밍 방식으로 결합되어 몇 초 만에 고유하고 독립적인 가상 네트워크를 생성할 수 있습니다. NSX-T는 관리, 제어, 데이터라는 세 가지 개별적이지만 통합된 영역을 통해 작업을 수행합니다. 이 세 가지 평면은 세 가지 유형의 노드( 관리자, 컨트롤러 및 전송 장치) 에 상주하는 프로세스, 모듈 및 에이전트 세트로 구현됩니다 .
각 노드는 관리부 에이전트를 호스팅합니다.
NSX Manager 노드는 API 서비스 및 관리부 클러스터 데몬을 호스팅합니다. 3개의 노드가 있는 클러스터를 지원하고 정책 관리자, 관리 및 중앙 제어 서비스를 노드 클러스터에 통합합니다. NSX Manager 클러스터는 사용자 인터페이스 및 API의 고가용성을 제공합니다. 관리부 노드와 제어부 노드가 통합되면 NSX-T Data Center 관리자가 배포하고 관리해야 하는 가상 장치의 수가 줄어듭니다.
NSX Controller 노드는 중앙 제어부 클러스터 데몬을 호스팅합니다.
전송 노드는 로컬 제어 플레인 데몬과 전달 엔진을 호스팅합니다.
● 관리 구성 요소는 최대 16개의 vCenter, 컨테이너 오케스트레이션 및 공용 클라우드 환경을 관리할 수 있으며, MPA(관리부 에이전트)는 데이터부(네트워크 전송 노드)에 상주하여 도메인 NSX-T 관리자 통신을 완료합니다. NSX 2.4 이전 버전에서는 , 각 관리 구성 요소는 역할 기반 독립 장치, 관리 장치 및 3개의 컨트롤러 장치로 구성됩니다. NSX는 총 4개의 관리 장치 + 각 서비스 장치를 배포해야 합니다. 2.4부터 NSX Manager, NSX Policy Manager 및 NSX Controller는 공통 가상 머신에 공존합니다.
그리고 클러스터를 사용하려면 3개의 고유한 NSX-vm 디바이스가 필요합니다. NSX-T는 확장 및 이중화를 위해 이러한 NSX Manager 장치 3개의 클러스터를 사용합니다. NSX-T 관리자는 전체 클러스터를 즉시 동기화할 수 있도록 모든 정보를 메모리 내 데이터베이스에 저장하는 동시에 디스크에 쓰기, 구성 또는 읽기 작업을 세 장치 중 하나에서 수행할 수 있습니다. 대부분의 작업이 메모리에서 발생한다는 점을 고려하면 NSX Manager 장치 디스크에 대한 성능 요구 사항이 크게 줄어듭니다. 이들 3개 어플라이언스 각각에는 관리자 프로세스가 직접 또는 로드 밸런서를 통해 액세스할 수 있는 전용 IP 주소가 있습니다. NSX Manager는 NSX-T 환경을 관리할 수 있는 웹 기반 사용자 인터페이스를 제공합니다. 또한 API 호출을 처리하는 API 서버를 호스팅합니다. 여기에는 모든 리소스에 대한 액세스 권한이 있지만 소프트웨어 설치를 위한 운영 체제에 대한 액세스 권한이 없는 admin이라는 사용자 계정이 내장되어 있습니다. NSX-T 업그레이드 파일은 설치가 허용되는 유일한 파일입니다. 관리자의 사용자 이름과 역할 권한을 변경할 수 있지만 관리자를 삭제할 수는 없습니다. NSX Manager에서 세션 ID와 토큰은 각 세션마다 고유하며 사용자가 로그오프하거나 일정 기간 동안 비활성 상태이면 만료됩니다. 또한 각 세션에는 세션 하이재킹을 방지하기 위해 세션 통신을 암호화하는 시간 기록이 있습니다.
● NSX-T는 제어 평면을 두 부분으로 나눕니다.
● 중앙 제어 플레인(CCP: Central Control Room): 실제로 관리 클러스터의 VM 장치(일반적으로 CCP 장치로 알려짐)이며, 이 장치(관리 네트워크)의 통신은 모든 데이터 플레인(비즈니스 네트워크)에서 논리적으로 격리됩니다. ) 트래픽; 따라서 해당 트래픽 및 장애가 실제 비즈니스 트래픽에 영향을 미치지 않으며 비즈니스 네트워크의 데이터가 관리 네트워크에 침투하지 않아 관리 및 제어 위험이 발생합니다. / Local Control Plane (LCP: End Control) : 이 구성
요소
는 배포 위치 - ---전송 노드(데이터 노드)는 데이터 평면의 전송 노드에서 라우팅 항목 및 방화벽 규칙을 전달하는 역할을 담당합니다.
\
● 데이터 플레인
전송 노드는 NSX-T 데이터부를 구현하는 로컬 제어부 데몬과 전달 엔진을 실행하는 호스트입니다. 전송 노드에서 실행되는 NSX-T 가상 스위치는 N-VDS이고, ESXi 호스트부에서는 N-VDS가 VDS에 연결되며, NSX-T 3.0 이후에는 OVS를 기반으로 N-VDS가 구현됩니다(플랫폼은 중요하지 않음). 다른 플랫폼의 네트워크 환경을 충족하는 구현이기도 함) NSX-T에는 두 가지 유형의 전송 노드가 있습니다. 하이퍼바이저 전송 노드: VMware ESXi™ 및 KVM 하이퍼바이저를 지원하여 다음을 제공합니다
. 이러한 하이퍼바이저에서 실행되는 VM을 위한 네트워크 서비스,
엣지 노드: VMware NSX-T Edge™ 노드는 서비스 게이트웨이 장치이며 어플라이언스는 베어 메탈/VM일 수 있습니다. 이러한 엣지 장치는 서비스 자체가 아니라 는 일부 네트워크 서비스에 대한 소비 리소스 풀일 뿐이며 그 중 2개는 계층 브리지는 NSX-T 오버레이 계층과 VLAN 지원 물리적 네트워크 간의 통신 브리징을 담당하는 장치입니다 . 보조 브리지는 특히 브리징을 위해 2개의 ESXi 하이퍼바이저(VLAN별 활성/대기) 클러스터를 통해 구현됩니다.
대기 Edge 노드에서 CLI 명령 set l2bridge-port <uuid> state active를 실행하여 대기 Edge 노드를 활성 노드로 수동으로 설정할 수 있습니다. 이 명령은 비활성 모드에서만 적용될 수 있습니다. 그렇지 않으면 오류가 발생합니다. 비활성 모드에서 이 명령이 대기 노드에 적용되면 HA 장애 조치가 트리거되고 활성 노드에 적용되면 무시됩니다.
1) Tier-0 게이트웨이
Tier-0 게이트웨이는 Tier-0 논리적 라우터의 기능을 수행하고 논리적 네트워크 와 물리적 네트워크 간의 트래픽을 처리합니다 . 엣지 노드는 하나의 Tier-0 게이트웨이 또는 논리적 라우터만 지원할 수 있습니다. 따라서 Tier-0 게이트웨이 또는 논리적 라우터를 생성할 때 생성된 Tier-0 게이트웨이 또는 논리적 라우터가 NSX Edge 클러스터의 Edge 노드 수를 초과하지 않는지 확인해야 합니다 . Tier-0 게이트웨이는 일반적으로 Tier-1 게이트웨이에 연결되고 외부 연결은 물리적 네트워크에 연결되며 외부 네트워크에 대한 정적 경로는 Tier-0 게이트웨이에서 구성될 수도 있습니다. 정적 경로를 구성한 후에는 Tier-0에서 Tier-1로의 경로를 알릴 필요가 없습니다. Tier-1 게이트웨이는 연결된 Tier-0 게이트웨이의 정적 기본 경로를 자동으로 학습합니다.
2) Tier-1 게이트웨이
Tier-1 게이트웨이에는 세그먼트에 대한 다운링크 연결과 Tier-0 게이트웨이에 대한 업링크 연결이 있습니다. Tier-1 게이트웨이는 일반적으로 북쪽 방향으로 Tier-0 게이트웨이에 연결되고 남쪽 방향으로 세그먼트에 연결됩니다. Tier-1 게이트웨이에서 경로 공지 및 정적 경로를 구성할 수 있습니다. 재귀적 정적 라우팅을 지원합니다.
3) 논리적 라우팅 DLR
4) 마이크로 세분화
NSX-T Data Center에서 세그먼트는 계층 2 가상 도메인입니다. 세분화는 이전에 논리적 스위치로 알려져 있었습니다 . 가상 머신 인터페이스와 게이트웨이 인터페이스에 대한 가상 레이어 2 스위칭을 제공하는 엔터티입니다. NSX-T Data Center에는 두 가지 유형의 세그먼트가 있습니다.
VLAN 지원 세분화: 물리적 인프라에서 기존 VLAN으로 구현되는 레이어 2 브로드캐스트 도메인입니다. 이는 두 개의 서로 다른 호스트(동일한 VLAN 지원 세그먼트에 연결됨)에 있는 두 가상 머신 간의 트래픽이 두 호스트 간의 VLAN을 통해 이동함을 의미합니다. 결과적으로 두 가상 머신이 VLAN 지원 분할을 통해 계층 2에서 통신하려면 물리적 인프라에 적절한 VLAN을 프로비저닝해야 한다는 제한이 있습니다.
오버레이 네트워크 지원 세그먼트: 서로 다른 호스트(동일한 오버레이 네트워크 세그먼트에 연결됨)에 있는 두 가상 머신 간의 레이어 2 트래픽은 호스트 간 터널을 통해 전달됩니다. NSX-T Data Center는 물리적 인프라에서 분할별 구성 없이 이 IP 터널을 인스턴스화하고 유지 관리합니다 . 따라서 가상 네트워크 인프라는 물리적 네트워크 인프라와 분리됩니다 . 즉, 물리적 네트워크 인프라를 구성하지 않고도 세그먼트를 동적으로 생성할 수 있습니다 .
5) 호스트 스위치:
관리하는 개체는 네트워크의 다양한 호스트에 네트워크 연결 서비스를 제공하는 가상 네트워크 스위치입니다. 이 개체는 NSX-T 네트워크 연결에 참여하는 각 호스트에서 인스턴스화 됩니다 . NSX-T에서는 다음 호스트 스위치가 지원됩니다.
1. NSX-T 가상 분산 스위치 : NSX-T는 여러 VMware vCenter Server 인스턴스, KVM, 컨테이너 및 기타 외부 배포 또는 클라우드 구현을 포함하여 다양한 컴퓨팅 도메인 간의 연결을 표준화하기 위해 호스트 스위치를 도입합니다.
NSX-T 가상 분산 스위치는 환경에 필요한 성능을 기반으로 구성될 수 있습니다.
표준: 일반 트래픽 처리량이 필요한 일반 워크로드에 대해 구성됩니다.
향상: 더 높은 트래픽 처리량이 필요한 통신 작업 부하에 맞게 구성되었습니다.
2. vSphere Distributed Virtual Switch : vCenter Server 환경의 스위치와 연결된 모든 호스트의 네트워크 연결 구성에 대한 중앙 집중식 관리 및 모니터링을 제공합니다.
자세한 내용은 공식 문서를 참조하세요 .
2.2 포트와 프로토콜
3. 관련 개념
3.1 관련 개념
1) 이질성:
이기종 환경의 요구 사항을 충족하기 위한 NSX-T의 기본 요구 사항은 계산 관리자에 의존하지 않는 것입니다 . 여러 가상화 장치 및/또는 여러 워크로드도 지원하므로 더 이상 NSX와 vCenter의 1:1 매핑이 없어도 제약을 받지 않습니다. NSX-T의 관리, 제어 및 데이터 플레인 구성 요소는 유연성, 확장성 및 성능을 염두에 두고 설계되었습니다.
관리부 는 모든 컴퓨팅 관리자(vSphere 포함)와 독립적으로 설계되었습니다. VMware NSX-T® Manager™는 완전한 독립형이므로 프로그래밍 방식이나 GUI를 통해 NSX 기능을 간단하게 관리할 수 있습니다.
컨트롤 플레인은 특정 엔드포인트에서 중앙 집중식 클러스터( CCP )와 로컬 구성 요소( LCP )의 두 가지 구성 요소로 나뉩 니다 . 이를 통해 컨트롤 플레인은 지역화된 구현(데이터 플레인 구현 및 보안 구현)으로 확장되고 더욱 효율적이며 이기종 환경을 허용할 수 있습니다.
데이터 플레인의 경우 특정 정규화된 인스턴스가 다양한 환경에서 설계되었습니다. NSX-T는 여러 VMware vCenter® 인스턴스, KVM, 컨테이너 및 N-VDS 라고 하는 기타 비기본 구현을 포함하여 다양한 컴퓨팅 도메인 간의 연결을 표준화하는 호스트 스위치를 도입합니다 . N-VDS 스위치의 모든 기능은 ESXi VDS7.0에서 완벽하게 구현되므로 ESXi 고객은 VDS를 변경하지 않고도 전체 NSX-T 기능을 최대한 활용하여 일관된 환경을 제공할 수 있습니다.
2) 애플리케이션 일관성
MSX-T는 가상 머신 또는 컨테이너에서 실행되는 워크로드에 원활한 네트워크 가상화를 제공합니다. NSX는 여러 CaaS(서비스로서의 통신, 관련 MAAS 및 TAAS) 및 PaaS 솔루션을 지원합니다. NSX-T는 애플리케이션을 핵심 구조로 사용하여 구축됩니다. 컨테이너 및 클라우드 네이티브 애플리케이션을 완벽하게 지원하는 NSX는 물리적 서버부터 VM 및 컨테이너까지 모든 것을 포함하는 환경에 대한 가시성을 관리하고 향상시키는 공통 프레임워크를
제공합니다 . NCP 주요 구성 요소는 컨테이너에서 실행되고 NSX 관리자 및 Kubernetes API 서버와 통신합니다. (k8s/openshift의 경우) NCP는 컨테이너 및 기타 리소스의 변경 사항을 모니터링합니다. 또한 NSX API를 통해 논리적 포트, 스위치, 라우터, 보안 그룹과 같은 컨테이너의 네트워크 리소스를 관리합니다.
3.2. VDS NSX-T 주의사항
NSX-T는 vSphere와 독립적인 네트워크 가상화 플랫폼으로 설계되었습니다. 물론 목표는 vSphere를 완전히 버리는 것이 아니라 더 넓은 범위의 네트워크를 제공하고 vsphere를 넘어서는 서비스를 제공하는 것입니다. 동일한 NSX-T는 여러 vCenter에 네트워크 서비스를 동시에 제공할 수 있습니다(예: KVM, 클라우드 또는 베어메탈 서버로 확장).
vSphere와 분리되는 또 다른 이유는 NSX-T가 자체 릴리스 주기를 갖도록 기능 및 버그 수정이 vSphere의 타임라인과 독립적이 되도록 하기 위해서입니다. 이를 달성하기 위해 NSX-T 가상 스위치 N-VDS는 기존 소프트웨어 인프라를 활용하여 vSphere가 타사 가상 스위치에 대한 일련의 API 호출을 통해 네트워킹을 사용할 수 있도록 합니다. 따라서 NSX-T 세그먼트는 "퍼지 네트워크"로 표시됩니다. 이는 이러한 개체가 완전히 독립적이며 vSphere에서 관리할 수 없음을 명확하게 보여주는 이름입니다.
NSX-T 3.0에서는 이제 VDS에서 직접 NSX-T를 실행할 수 있습니다(VDS 버전은 7.0 이상이어야 함). NSX-T는 여러 vCenter에서 원활하게 작동하므로 vCenter 독립성을 유지합니다. 그러나 VDS가 필요하므로 이제 NSX-T를 ESXi 호스트에서 실행하려면 vCenter가 필요합니다.
NSX-T 네트워크 세그먼트의 범위는 해당 세그먼트가 속한 전송 영역 에 따라 정의 됩니다. 이는 "test-segment"가 전송 영역 "Overlay"에 정의된 경우 이 세그먼트는 전송 영역 "Overlay"에 연결된 모든 호스트에서 사용할 수 있음을 의미합니다. 아래 그림에 표시된 대로 N-VDS("nvds1이라고 함) ")에는 두 개의 ESXi 호스트가 연결(준비)되어 있으며 네트워크 세그먼트를 공유합니다.
위 이미지의 왼쪽 에는 vCenter의 "test-segment"에 대한 불투명 네트워크 표현이 표시됩니다. 관리자는 불투명 네트워크를 선택하여 ESXi1 및 ESXi2에 있는 가상 머신의 가상 NIC를 이 세그먼트에 직접 연결할 수 있습니다 . 다음은 vCenter의 불투명 네트워크에 대한 정보를 보여주는 MOB(Managed Object Browser) 스냅샷입니다. "요약"과 "extraConfig" 콘텐츠의 일부를 참고하세요.
그림의 주요 내용은 다음과 같습니다.
- 논리적 스위치 "test-segment"의 이름입니다.
- 논리 스위치 UUID: "7884ca6a-4e8f-4b52-98f6-a265cf0e19f8".
- 불투명 네트워크가 NSX 세그먼트를 나타내는 경우 extraConfig 필드는 세그먼트 경로 "/infra/segments/test-segment"도 제공합니다. 가상 머신이 이 불투명 네트워크에 연결된 경우 네트워크 유형과 논리 스위치의 UUID를 보여주는 더 자세한 정보도 표시됩니다.
● VDS에서 NSX-T 기능을 활성화합니다.
위 그림에 표시된 것처럼 "test-segment"는 두 호스트 모두에서 dvportgroup으로 제공될 수 있습니다. NSX-T의 dvportgroup 표현이기 때문에 이를 "NSX-T dvportgroup"이라고 부릅니다. dvportgroup 아이콘에는 NSX-T 개체를 다루고 있음을 나타내기 위해 작은 "N"도 표시됩니다. 그러나 네트워크 사용자의 관점에서 보면 가상 머신은 이전 사례에서 불투명 네트워크에 연결할 수 있었던 것처럼 dvportgroup NSX-T에 연결할 수 있습니다. dvportgroup은 VDS에 속하므로 계층 구조의 "VDS1" 아래에 "test-segment"가 표시되는 것을 볼 수 있습니다. MOB 아래 해당 NSX-T dvportgroup은 다음과 같습니다.
위 그림에서 왼쪽 부분은 기존 dvportgroup과 유사합니다. 차트 오른쪽에 표시된 "config" 부분에 주의하세요.
- 값이 NSX인 "backingType"이 있으며 이는 NSX 개체임을 명시적으로 나타냅니다.
- 세그먼트 이름과 세그먼트 ID, 그리고 세그먼트가 속한 전송 영역의 이름과 UUID NSX-T를 가져올 수 있습니다. 이 특정 시나리오에서는 이 두 필드가 동일합니다.
- 세그먼트와 연결된 논리적 스위치는 "logicalSwitchUuid" 필드에서 참조됩니다. 이 값은 이전 N-VDS 기반 예시에 표시된 "opaqueNetworkId"와 동일합니다. 이는 vCenter에서 동일한 개체를 다른 방식으로 표현하기 때문입니다.
- NSX-T용 dvportgroup은 항상 "임시"입니다. 가상 머신이 이 dvportgroup NSX-T에 연결되면 백엔드는 위의 NSX-T dvportgroup 개체만 가리킵니다.
● 여러 VDS의 NSX-T:
위 그림은 ESXi1 호스트가 VDS1에서 NSX를 실행하고 ESX2 호스트가 VDS2 위에서 NSX-T를 실행할 때 발생하는 상황을 보여줍니다. 그림 왼쪽의 vCenter 네트워크 보기에는 각각 "test-segment"라는 NSX-T dvportgroup이 있는 VDS1 및 VDS2가 표시됩니다. VDS에서 NSX-T를 실행한다는 것은 기본적으로 다른 vCenter에서 표시되는 NVDS 모델을 사용한다는 것을 의미하지만 기능은 동일하게 유지되어야 하기 때문입니다. 따라서 이 경우 "테스트 세그먼트"의 범위는 여전히 "오버레이" 전송 영역에 의해 정의됩니다. ESXi 호스트1과 호스트2는 동일한 "오버레이" 전송 영역에 연결되어 있으므로 "오버레이"에 정의된 세그먼트를 호스트1과 호스트2에서 사용할 수 있어야 합니다. dvportgroup은 vCenter의 VDS 아래에 정의되어 있으므로 VDS1 및 VDS2에 NSX-T dvportgroup을 복사해야 합니다. 이 두 dvportgroup은 실제로 두 개의 서로 다른 VDS에 있는 동일한 가상 포트 NSX-T를 나타냅니다 . 다음 그림은 MOB의 VDS2 아래에 있는 dvportgroup NSX-T "test-segment"의 정보를 보여줍니다.
위에 표시된 것처럼 VDS2에 있는 NSX-T dvportgroup은 VDS1에 있는 것과 다른 관리 개체 ID를 가지고 있음을 알 수 있습니다(dvportgroup- 57) (dvportgroup-59). 이러한 개체는 서로 다른 두 개의 vCenter 개체입니다. 그러나 둘은 동일한 NSX-T 세그먼트를 가리키고 있으며, logicSwitchUuid 및 SegmentID 필드를 확인하면 물론 이 두 필드는 동일합니다.
다음 그림은 N-VDS로 준비된 호스트 1과 호스트 2의 VDS에 설치된 NSX-T를 보여줍니다. 이 경우 "test-segment" 세그먼트의 불투명 네트워크와 NSX-T dvportgroup 표현이 모두 vCenter에 나타납니다.
NSX-T 2.3 이전에는 계층 2 브로드캐스트 도메인을 나타내는 개체는 논리적 스위치 UUID에서 NSX에 의해 고유하게 식별되는 논리적 스위치였습니다.
NSX-T 2.4에서는 동일한 목적으로 분할 개념을 도입했습니다. 세그먼트는 논리적 스위치와 다음과 같은 일부 추가 매개변수를 포함하는 개체입니다.
세그먼트는 세그먼트 경로 로 고유하게 식별됩니다 . 위의 예에서 사용된 분할은 세그먼트 경로로 "/infra/segments/test-segment"를 갖습니다. 경로의 마지막 부분(여기서는 "test-segment")을 세그먼트 ID라고 합니다. 대부분의 경우 세그먼트 ID는 세그먼트의 이름입니다.
동일한 세그먼트는 여러 VDS에 걸쳐 있으며, NSX용으로 준비된 여러 VDS에 걸쳐 전송 영역이 확장되면 각 VDS에는 전송 영역의 각 세그먼트에 대한 NSX-T dvportgroup이 있습니다. 이러한 NSX-T dvportgroup은 나타내는 세그먼트에 따라 이름이 지정됩니다. 즉, 동일한 이름을 가진 여러 dvportgroup을 의미합니다. 이는 이전에 vCenter에서 사용할 수 없었던 정보입니다. dvportgroups는 이전에 vCenter에서 고유했습니다.
NSX-T 세그먼트의 경우 세그먼트 경로는 세그먼트의 고유 식별자이며 이 식별자는 NSX-T입니다. 네트워크 관리자는 여러 세그먼트에 동일한 이름을 사용할 수 있습니다 . NSX-T는 세그먼트 ID가 서로 다른지 확인합니다 . 두 번째 "테스트 세그먼트"가 "오버레이" 전송 영역에 생성되었다고 가정합니다. 이 새 세그먼트에는 세그먼트 ID에 추가 문자열이 추가되어 기존 문자열과 다릅니다.
vCenter는 dvportgroup의 기존 dvportgroup과 동일한 이름을 가진 NSX-T dvportgroup 생성을 허용하지 않습니다. 그러나 dvportgroup이 VDS 아래에 "test"가 이미 존재한다고 나타내는 경우 NSX-T는 NSX-T를 생성합니다. dvportgroup "test", 둘 다 여기서 "test"dvportgroup은 동일한 유형이 아닙니다.
PowerCLI의 NSX 분산 포트 그룹 쿼리:
Get-VDPortGroup -Name "MyVDPortGroup" -VDSwitch "MyVDSwitch"
//如果某个特定的分布式端口组需要使用 LogicalSwitch UUID 进行引用，则可以使用 ExtensionData 过滤特定的 UUID。
Get-VDPortGroup -VDSwitch "MyVDSwitch" | where {
$_.ExtensionData.Config.LogicalSwitchUuid -eq ‘9c6388c3-2ad6-41c6-bcaa-a23edefcea38’}
3.3. VSS에서 N-VDS 스위치로 VMkernel 마이그레이션
NSX-T Data Center 3.0부터 vSphere Distributed Switch를 사용하여 전송 노드를 생성할 수 있습니다. 설치 중에 VMkernel을 N-VDS 스위치로 마이그레이션하려면 VMkernel을 기존 논리적 스위치에 매핑합니다. NSX Manager는 VMkernel을 N-VDS의 매핑된 논리적 스위치로 마이그레이션합니다. VMkernel 인터페이스를 VSS 또는 DVS 스위치에서 클러스터 수준의 N-VDS 스위치로 마이그레이션하려면 마이그레이션에 필요한 네트워크 매핑 세부 정보로 전송 노드 프로파일을 구성합니다(VMkernel 인터페이스를 논리적 스위치에 매핑). 마찬가지로 호스트 노드에서 VMkernel 인터페이스를 마이그레이션하려면 전송 노드 구성을 구성합니다. VMkernel 인터페이스를 VSS 또는 DVS 스위치로 다시 마이그레이션하려면 오프로드 프로세스 중에 구현될 전송 노드 구성 파일에서 오프로드 네트워크 매핑(논리 포트를 VMkernel 인터페이스에 매핑)을 구성합니다. 마이그레이션 중에 현재 사용 중인 물리적 NIC는 N-VDS 스위치로 마이그레이션되고, 사용 가능하거나 유휴 상태인 물리적 NIC는 마이그레이션 후에 N-VDS 스위치에 연결됩니다. 전송 노드 구성 파일은 클러스터의 모든 구성원 호스트에 적용됩니다. 그러나 특정 호스트에서 VMkernel 인터페이스 마이그레이션을 제한하려는 경우 호스트를 직접 구성할 수 있습니다. 마이그레이션 후 N-VDS는 N-VDS 스위치에 연결된 인터페이스에 대한 VLAN 및 오버레이의 트래픽을 처리합니다. NSX-T UI 또는 전송 노드 API를 사용하여 VMkernel 인터페이스 및 PNIC를 VDS에서 N-VDS 스위치로 마이그레이션한 후 vCenter Server가 VDS에 대한 경고를 표시합니다. 호스트를 VDS에 연결해야 하는 경우 VDS에서 호스트를 제거합니다. vCenter Server는 더 이상 VDS에 대한 경고를 표시하지 않습니다. 대상: NSX-T Data Center를 제거할 때 VMkernel 인터페이스를 VSS 또는 DVS 스위치로 다시 마이그레이션, VMkernel을 다시 포트 그룹으로 마이그레이션할 때 N-VDS 스위치에서 VSS 또는 DVS 스위치로 VMkernel 인터페이스 마이그레이션 DVS 스위치를 사용하려면 그룹 유형이 임시로 설정되어 있는지 확인하세요.
시험 조건:
vmk0과 vmk1은 vSwitch0에 연결되고, vmnic0과 vmnic1은 vSwitch0에 각각 업링크 1과 2로 구성됩니다.
NVSX 스위치에는 vmnic 또는 VMkernel 어댑터가 구성되어 있지 않습니다.
마이그레이션하기 전에 ESXi 호스트에는 두 개의 물리적 포트 vmnic0 및 vmnic1 에서 두 개의 업링크가 있어야 합니다 . 여기서 vmnic0은 활성화되어 VSS에 연결되도록 구성되고 vmnic1은 사용되지 않습니다. 또한 vmk0, vmk1 및 vmk2의 세 가지 VMkernel 인터페이스가 있습니다. NSX-T Data Center Manager UI 또는 NSX-T Data Center API를 사용하여 VMkernel 인터페이스를 마이그레이션할 수 있습니다. 마이그레이션 후에는 vmnic0, vmnic1 및 해당 VMkernel 인터페이스가 N-VDS 스위치로 마이그레이션됩니다. vmnic0 및 vmnic1은 VLAN 및 오버레이 전송 영역을 통해 연결됩니다.
VMkernel 마이그레이션에 대한 참고 사항:
- 물리적 NIC 및 VMkernel 마이그레이션 : 고정된 물리적 NIC 및 연결된 VMkernel 인터페이스를 N-VDS 스위치로 마이그레이션하기 전에 호스트 스위치의 네트워크 매핑(물리적 NIC에서 포트 그룹으로의 매핑)을 기록해 둡니다.
- 물리적 NIC 마이그레이션만 : 물리적 NIC만 마이그레이션하려는 경우 관리 VMkernel 인터페이스에 연결된 관리 물리적 NIC를 마이그레이션하지 마십시오. 이로 인해 호스트에 대한 연결이 끊어집니다 . 연결은 전송 노드 구성 파일에 Migrate-Only PNIC 필드를 추가합니다.
- 마이그레이션 재개 : VMkernel 인터페이스를 고정된 물리적 NIC가 있는 VSS 또는 DVS 호스트 스위치 로 다시 마이그레이션하기 전에 호스트 스위치의 네트워크 매핑(물리적 NIC에서 포트 그룹으로의 매핑)을 기록해 두십시오. 이는 오프로드된 네트워크 매핑 필드의 호스트 스위치 매핑으로 전송 노드 프로필을 구성하기 위한 전제 조건입니다. 이 매핑이 없으면 NSX-T Data Center는 VMkernel 인터페이스를 다시 마이그레이션해야 하는 포트 그룹을 알 수 없습니다. 이 상황으로 인해 vSAN 네트워크에 대한 연결이 끊어질 수 있습니다.
- 마이그레이션 전에 vCenter Server 등록: VMkernel 또는 DVS 스위치에 연결된 물리적 NIC를 마이그레이션하려는 경우 NSX Manager에 vCenter Server를 등록해야 합니다.
- VLAN ID 일치: 마이그레이션 후 관리 NIC 및 관리 VMkernel 인터페이스는 마이그레이션 전에 관리 NIC가 연결된 것과 동일한 VLAN에 있어야 합니다. vmnic0 및 vmk0이 이미 관리 네트워크에 연결되어 있고 다른 VLAN으로 마이그레이션되면 호스트에 대한 연결이 끊어집니다.
- VSS 스위치로 마이그레이션: 두 개의 VMkernel 인터페이스를 VSS 스위치의 동일한 포트 그룹으로 다시 마이그레이션할 수 없습니다.
- vMotion: VMkernel 및/또는 PNIC 마이그레이션 전에 vMotion을 수행하여 가상 머신 워크로드를 다른 호스트로 이동합니다. 마이그레이션이 실패하더라도 워크로드 VM은 영향을 받지 않습니다.
- vSAN: 호스트에서 vSAN 트래픽을 실행 중인 경우 vCenter Server를 통해 호스트를 유지 관리 모드로 전환하고 vMotion 기능을 사용하여 VMkernel 및/또는 PNIC 마이그레이션 전에 가상 머신을 호스트 밖으로 이동합니다.
- 마이그레이션: VMkernel이 이미 대상 스위치에 연결되어 있는 경우에도 동일한 스위치로 마이그레이션하기 위해 VMkernel을 선택할 수 있습니다. 이 속성은 멱등성 VMK 및/또는 PNIC 마이그레이션 작업을 허용합니다. 이는 PNIC만 대상 스위치로 마이그레이션하려는 경우에 유용합니다. 마이그레이션에는 항상 하나 이상의 VMkernel과 하나의 PNIC가 필요 하므로 PNIC만 대상 스위치로 마이그레이션하는 경우 대상 스위치로 마이그레이션된 VMkernel을 선택할 수 있습니다. VMkernel을 마이그레이션할 필요가 없는 경우 vCenter Server를 통해 소스 또는 대상 스위치에 임시 VMkernel을 생성합니다 . 그런 다음 PNIC와 함께 마이그레이션하고 마이그레이션이 완료되면 vCenter Server를 통해 임시 VMkernel을 삭제합니다 .
- MAC 공유: VMkernel 인터페이스와 PNIC의 MAC이 동일 하고 동일한 스위치 에 있는 경우 마이그레이션 후에 사용하려면 동일한 대상 스위치로 함께 마이그레이션 해야 합니다 . 항상 vmk0과 vmnic0을 동일한 스위치에 유지하십시오. 다음 명령을 실행하여 호스트의 모든 VMK 및 PNIC에서 사용하는 MAC를 확인할 수 있습니다.
esxcfg-vmknic -l
esxcfg-nics -l
\- 마이그레이션 후 생성된 VIF 논리적 포트 : VMkernel을 VSS 또는 DVS 스위치에서 N-VDS 스위치로 마이그레이션한 후 VIF 유형 논리적 스위치 포트가 NSX Manager에 생성됩니다 . 이러한 VIF 논리적 스위치 포트에서는 분산 방화벽 규칙을 생성할 수 없습니다.
VDS 버전 7.0 및 NSX-T3.2 버전은 VDS에서 NSX-T를 직접 실행할 수 있습니다.
전송 노드 구성 파일은 클러스터에 적용되는 구성을 정의하는 템플릿입니다. 독립형 호스트를 준비하는 데는 적합하지 않습니다. 전송 노드 구성 파일을 적용하여 전송 노드 역할을 할 vCenter Server 클러스터 호스트를 준비합니다. 전송 노드 프로필은 전송 영역, 멤버 호스트 및 N-VDS 스위치 구성(업링크 프로필, IP 할당, 업링크 가상 인터페이스에 대한 물리적 NIC 매핑 등 포함)을 정의합니다. 전송 노드 프로필은 호스트에만 사용할 수 있습니다. NSX Edge 전송 노드에는 적용할 수 없습니다. 전송 노드 생성은 전송 노드 구성 파일이 vCenter Server 클러스터에 적용될 때 시작됩니다. NSX Manager는 클러스터의 호스트를 준비하고 모든 호스트에 NSX-T Data Center 구성 요소를 설치합니다. 호스트의 전송 노드는 전송 노드 구성 파일에 지정된 구성을 기반으로 생성됩니다. 알아채다:
NSX-T Data Center는 첫 번째 N-VDS를 통과하는 트래픽이 두 번째 N-VDS를 통과하는 트래픽과 격리되도록 트래픽 격리를 제공합니다. 외부 세계로의 북-남 트래픽을 허용하려면 각 N-VDS의 물리적 NIC를 호스트의 Edge VM에 매핑해야 합니다. 첫 번째 전송 영역의 가상 머신에서 이동하는 패킷은 외부 라우터 또는 외부 가상 머신을 통해 두 번째 전송 영역의 가상 머신으로 라우팅되어야 합니다.
각 N-VDS 스위치에는 고유한 이름이 있어야 합니다. NSX-T Data Center에서는 중복된 스위치 이름을 허용하지 않습니다.
전송 노드 구성 또는 전송 노드 프로필 구성의 각 N-VDS 또는 VDS 호스트와 연결된 각 전송 영역 ID는 고유해야 합니다.
브라우저에서 관리자 권한을 사용하여 https://, 즉 NSX-T 독립 페이지인 시스템 > 패브릭 > 구성 파일 > 전송 노드 구성 파일 >에서 NSX Manager에 로그인합니다.
호스트가 전송 노드로 구성된 경우 [ESXi VMkernel 및 물리적 어댑터 마이그레이션]을 사용하고 시스템 > 패브릭 > 호스트 전송 노드로 이동하여 전송 노드를 선택한 다음 작업 > ESX VMkernel 및 물리적 어댑터 마이그레이션을 클릭할 수 있습니다. 업데이트된 VMkernel 어댑터 및 물리적 어댑터는 N-VDS 스위치로 마이그레이션되거나 마이그레이션된 항목이 ESXi 호스트의 VSS 또는 VDS 스위치로 복원됩니다.
참고: 위의 두 vmnic과 업링크 간의 매핑 관계는 일관되어야 합니다. 그렇지 않으면 마이그레이션이 실패합니다.
VMkernel 인터페이스를 N-VDS 스위치로 마이그레이션하기 위한 요약 워크플로:
필요한 경우 논리적 스위치를 생성합니다. VMkernel 인터페이스와 물리적 NIC를 N-VDS 스위치로 마이그레이션하려는 호스트에서 가상 시스템의 전원을 끕니다.
전송 노드를 생성할 때 VMkernel 인터페이스를 마이그레이션하는 데 사용되는 네트워크 맵으로 전송 노드 구성 파일을 구성합니다. 네트워크 매핑은 VMkernel 인터페이스를 논리적 스위치에 매핑하는 것을 의미합니다.
vCenter Server의 네트워크 어댑터 매핑이 VMkernel 스위치와 N-VDS 스위치의 새로운 연결을 반영하는지 확인합니다 . 물리적 NIC가 고정된 경우 NSX-T Data Center의 매핑이 vCenter Server의 물리적 NIC에 고정된 모든 VMkernel을 반영하는지 확인합니다.
NSX Manager에서 네트워크 → 세분화로 이동합니다. 세그먼트 페이지에서 VMkernel 인터페이스가 새로 생성된 논리적 포트를 통해 세그먼트에 연결되어 있는지 확인합니다.
시스템 > 노드 > 호스트 전송 노드로 이동합니다. 각 전송 노드에 대해 노드 상태 열의 상태가 성공인지 확인하여 전송 노드 구성이 성공적으로 확인되었는지 확인합니다.
호스트 전송 노드 페이지에서 구성 상태의 상태가 성공인지 확인하여 호스트가 지정된 구성으로 성공적으로 구현되었는지 확인합니다.
네트워크 인터페이스를 N-VDS로 마이그레이션하기 전과 후:
VMkernel 인터페이스와 물리적 NIC를 VSS 또는 DVS 스위치에서 N-VDS 스위치로 마이그레이션하거나 인터페이스를 다시 VSS 또는 DVS 호스트 스위치로 마이그레이션할 때 다음 오류가 발생할 수 있습니다.
| 에러 코드 | 질문 | 이유 | 해결책 |
|---|---|---|---|
| 8224 | 전송 노드 구성에 지정된 호스트 스위치를 찾을 수 없습니다. | 호스트 스위치 ID를 찾을 수 없습니다. | * 반드시 호스트 스위치 이름으로 전송 영역을 생성한 후 전송 노드를 생성하시기 바랍니다. * 전송 노드 구성에서는 유효한 호스트 스위치를 사용하십시오. |
| 8225 | VMkernel 마이그레이션이 진행 중입니다. | 마이그레이션이 진행 중입니다. | 다른 작업을 수행하기 전에 마이그레이션이 완료될 때까지 기다리십시오. |
| 8226 | VMkernel 마이그레이션은 ESXi 호스트에서만 지원됩니다. | 마이그레이션은 ESXi 호스트에만 유효합니다. | 마이그레이션을 시작하기 전에 호스트가 ESXi 호스트인지 확인하십시오. |
| 8227 | 호스트 스위치 이름에는 VMkernel 인터페이스가 추가되지 않습니다. | 여러 호스트 스위치가 있는 호스트에서 NSX-T Data Center는 각 VMkernel 인터페이스와 해당 호스트 스위치의 연결을 인식하지 못합니다. | * 호스트에 N-VDS 호스트 스위치가 여러 개 있는 경우 호스트가 연결된 N-VDS의 호스트 스위치 이름이 VMkernel 인터페이스와 함께 추가되는지 확인하세요. * 예를 들어 N-VDS 호스트 스위치 이름 nsxvswitch1 및 VMkernel1과 다른 N-VDS 호스트 스위치 이름 nsxvswitch2 및 VMkernel2를 사용하여 호스트를 오프로드하기 위한 네트워크 매핑은 device_name: VMkernel1@nsxvswitch1, Destination_network: DPortGroup과 같이 정의되어야 합니다. |
| 8228 | device_name 필드에 사용된 호스트 스위치를 호스트에서 찾을 수 없습니다. | 호스트 스위치 이름이 올바르지 않습니다. | 올바른 호스트 스위치 이름을 입력하십시오. |
| 8229 | 전송 노드는 논리적 스위치에 대한 전송 영역을 지정하지 않습니다. | 추가된 환승 구역이 없습니다. | 전송 노드 구성에 전송 영역을 추가합니다. |
| 8230 | 호스트 스위치에는 물리적 네트워크 카드가 없습니다. | 호스트 스위치에는 물리적 NIC가 하나 이상 있어야 합니다. | 업링크 프로파일에 대해 하나 이상의 물리적 NIC를 지정하고 논리적 스위치에 대해 VMkernel 네트워크 매핑 구성을 지정합니다. < |