개요
아니요, Savage Garden 의 "To the Moon & Back" 노래를 논의하기 위해 음악 블로그 장르로 전환하려는 것이 아닙니다 (이런 내용을 기대하셨다면 죄송합니다). 제목에 오타는 없습니다. VMware HCX 네트워크 확장 기능과 MON 기능( Mobility Optimized Network 라고도 함)을 살펴보겠습니다 .
HCX에 대해 잘 모르시는 분들을 위해 설명드리자면, HCX는 온프레미스에서 클라우드로, 또는 클라우드에서 클라우드로 워크로드를 마이그레이션할 수 있는 VMware 솔루션입니다. 또한 마이그레이션 소스에서 목적지까지 네트워크를 확장할 수 있습니다. HCX는 마이그레이션 프로젝트를 가속화하기 위해 다양한 시나리오에서 사용할 수 있는 매우 강력한 솔루션입니다.
이 글에서는 HCX의 네트워크 확장 부분에 초점을 맞추고, 특히 잘 이해되지 않는 기능인 모빌리티 최적화 네트워크에 대해 알아보겠습니다 .
우리는 무엇에 대해 이야기하지 않을 것인가
이 글에서는 HCX 네트워크 확장 생성에 대해 자세히 다루지 않겠습니다. 이 주제는 공식 문서를 포함하여 인터넷에 이미 잘 정리되어 있으므로 HCX에 익숙하다면 자세한 설명은 필요하지 않을 것입니다.
실험실 설정
이 게시물을 문서화하기 위해 다음 토폴로지를 기반으로 랩을 만들었습니다.
이 연구실에는 다음이 있습니다.
- vCenter와 하이퍼바이저를 갖춘 온프레미스 환경: 호스팅:
- 네트워크( 10.100.115.0/24)
- 라우팅 장치( gw@ 10.100.115.1)와 그 북쪽 연결(인터넷+클라우드 연결)
- 클라우드로 마이그레이션할 가상 머신 세트:migration-vm-X
- 클라우드 환경(Azure 기반):
- ExpressRoute 회로의 착륙
- 내 워크스테이션을 위한 지점 간 VPN 게이트웨이
- vNET:10.100.2.0/24
- 이 vNET의 Azure 네이티브 VM: azure-vm@10.100.2.36
- Azure VMware 솔루션 SDDC에는 다음이 포함됩니다.
- 익스프레스 루트(ER) + 글로벌 리치 연결
- HCX Enterprise 배포 및 구성
- 테스트 VM과 직접 AVS 연결이 가능한 기본 NSX-T 세그먼트 10.100.110.0/24:Ubuntu01
VM 마이그레이션을 준비하기 위해 HCX 네트워크 확장을 사용하여 온프레미스 네트워크를 클라우드로 확장했습니다. 10.100.115.0/24이제 확장된 네트워크( )를 클라우드에서 사용할 수 있습니다.
기본 네트워크 연결
VM 마이그레이션을 시작하기 전에 온프레미스의 기본 네트워크 연결을 살펴보겠습니다.
migration-vm-X온프레미스 gw장치와 기본 경로를 사용하여 인터넷에 접속합니다 (↔ 분홍색) . 이 gw장치는 ExpressRoute 회로 (↔ 주황색) 를 통해 클라우드 환경에 접속하는 데에도 사용됩니다. Azure VMware Solution 기반 VM에 접속하려면 Global Reach 및 AVS ER 회로 (↔ 빨간색) 와 함께 ER 회로가 사용됩니다 .
VM을 클라우드 환경으로 마이그레이션
HCX를 사용하여 클라우드 환경으로 마이그레이션해 보겠습니다 migration-vm-2. 마이그레이션이 성공적으로 완료되어 VM이 클라우드 환경에서 실행 중입니다. VM은 gw기본 게이트웨이가 아직 .으로 구성되어 있으므로 온프레미스 장치를 사용하여 인터넷과 클라우드 환경에 접속하고 있습니다 10.100.115.1.
인터넷 (↔ 분홍색) 또는 클라우드 기반 리소스 (↔ 주황색) 에 접속하는 네트워크 경로는 최적이 아니며, AVS의 다른 NSX-T 세그먼트 (↔ 빨간색) 에 있는 VM에 접속하는 경로를 살펴보면 이는 더욱 분명하게 드러납니다 . 이러한 상황을 (w) 네트워크 트롬보닝 이라고 합니다 .
세그먼트 연결성
NSX-T에서 네트워크 확장이 생성되면 동일한 서브넷 설정을 가진 세그먼트가 생성되고 L2E_접두사가 붙은 이름이 지정됩니다.
스크린샷에서 볼 수 있듯이 이 세그먼트는 비활성화된 gateway connectivity 상태로 구성되어 있습니다 . 즉, 이 세그먼트는 NSX-T 패브릭의 다른 구성 요소에 광고되지 않으며, L3 연결에 T1 게이트웨이를 사용할 수 없습니다.
모빌리티 최적화 네트워크 활성화
네트워크 경로를 개선하기 위해 HCX의 모빌리티 최적화 네트워크 기능을 활성화할 예정입니다. 이 기능은 HCX UI의 네트워크 확장 섹션에서 사용할 수 있으며, 네트워크별로 활성화할 수 있습니다.
이 기능을 활성화하고 기본 설정을 변경하지 않으면 세그먼트의 연결이 활성화되고 이제 T1 게이트웨이를 L3 연결에 사용할 수 있습니다 .
아시다시피, 마이그레이션된 VM의 네트워크 경로는 변경되지 않습니다. 이는 router-location의 기본 설정 때문 입니다 .hcx-enterprise
router -location hcx-enterprise 설정 값은 온-프레미스 gw장치가 마이그레이션된 VM의 기본 게이트웨이로 계속 사용된다는 것을 의미합니다.
세그먼트 연결성
Mobility Optimized Network 기능을 활성화한 후 세그먼트 연결성을 살펴보겠습니다.
gateway connectivity이제 L2E 세그먼트에서 이 기능이 활성화 되었으며, T1 게이트웨이를 L3 연결에 사용할 수 있습니다( 라우터 위치 설정에 따라 다름).
/32Express Route 회로의 BGP 광고에서 NSX-T에서 광고된 새로운 경로도 볼 수 있습니다 .
- 10.100.115.1/32: 확장된 네트워크의 게이트웨이.
라우터 위치 변경
마이그레이션된 VM의 네트워크 경로를 개선하기 위해 마이그레이션된 VM에 클라우드 측 게이트웨이를 사용하도록 라우터 위치 설정을 변경하는 것이 좋습니다 .
네트워크 경로에 다음 변경 사항이 적용됩니다.
- VM/OS에 구성된 기본 게이트웨이는 변경되지 않습니다. 10.100.115.1하지만...
- 별도의 NSX-T 세그먼트에 있는 VM에 도달하려면 트래픽이 온프레미스 gw장치 (↔ 빨간색) 가 아닌 세그먼트의 T1 게이트웨이를 통해 라우팅되어야 합니다 .
- 인터넷에 도달하려면 트래픽이 온프레미스 gw장치 (↔ 분홍색) 가 아닌 세그먼트의 T1 게이트웨이를 통해 라우팅됩니다 .
- 네이티브 클라우드 환경에서 VM에 도달하려면 트래픽이 온프레미스 gw장치 (⇠ 주황색) 를 통해 라우팅됩니다 .
- 하지만 복귀 경로는 해당 구간의 T1 게이트웨이 (⇠ 주황색) 를 통해 이루어집니다 .
보시다시피, AVS 호스팅 또는 인터넷 리소스에 대한 네트워크 경로가 최적화된 것처럼 보이더라도 네이티브 클라우드 리소스에 대한 경로는 그렇지 않고 비대칭적입니다. 이는 모빌리티 최적화 네트워크 기능의 설정 범주인 ' 정책 경로' 때문입니다 . 다음 섹션에서 이 설정에 대해 살펴보겠습니다.
백스테이지에서 무슨 일이 일어났나요?
라우터 위치 설정을 변경했을 때 다음 변경 사항이 적용되었습니다.
T1 게이트웨이의 라우팅 테이블을 살펴보면 마이그레이션된 VM에 대한 새 항목이 추가되었습니다.
Express Route 회로에서는 NSX-T에서 BGP를 통해 광고되는 2개의 새로운 경로도 표시됩니다.
- 10.100.115.1/32: 네트워크 게이트웨이가 이제 AVS에서 광고됩니다( 이 경로는 MON 활성화 이후 이미 광고되었습니다 )
- 10.100.115.12/32: MON이 활성화되고 라우터 위치가 HCX 클라우드 인스턴스로 설정된 마이그레이션된 VM입니다 .
비대칭 라우팅
클라우드 기반 리소스 (사설 네트워크) 로 향하는 네트워크 흐름 에서 볼 수 있듯이 , 비대칭 라우팅이 존재합니다. 트래픽은 온프레미스 장치를 통해 클라우드 기반 리소스에 도달하지만, 그 반대 경로는 클라우드 측 세그먼트의 T1 게이트웨이 (⇠ 주황색)gw 를 통과합니다 .
NSX-T가 마이그레이션된 VM의 경로를 게시함에 따라 /32클라우드 리소스는 이제 세그먼트의 T1 게이트웨이를 통해 마이그레이션된 VM에 직접 도달할 수 있습니다. 이것이 클라우드 리소스에서 AVS로의 경로가 T1 게이트웨이를 통과하는 이유입니다.
migration-vm-X온프레미스 gw장치를 사용하여 클라우드 기반 리소스에 접근하는 이유는 MON이 활성화된 경우 기본 정책 경로가 설정되기 때문입니다.
기본적으로 정책 경로는 RFC1918 주소 공간과 일치하는 트래픽에 대한 기본 게이트웨이로 온-프레미스 장치를 사용하도록 구성 되었습니다 .gw
- 10.0.0.0/8
- 172.16.0.0/12
- 192.168.0.0/16
이를 통해 마이그레이션된 VM은 온프레미스 장치를 기본 게이트웨이로 사용하여 온프레미스 네트워크의 다른 리소스에 도달할 수 있지만 gw, 사용자 지정하지 않은 경우 클라우드 기반 리소스에 대한 트래픽에 대한 비대칭 라우팅도 도입됩니다.
정책 경로를 사용자 지정해 보겠습니다.
모든 정책 경로 제거
정책 경로의 영향을 이해하는 좋은 예는 미리 구성된 정책 경로를 모두 제거하여 테스트를 수행하는 것입니다.
인터넷 (↔ 분홍색) 또는 AVS 기반 리소스 (↔ 빨간색) 의 경우 네트워크 경로는 여전히 이전 섹션의 경로입니다.
네이티브 클라우드 리소스 (↔ 주황색) 의 경우 , 마이그레이션된 VM이 세그먼트의 T1 게이트웨이를 사용하여 L2 브로드캐스트 도메인 외부의 모든 리소스에 도달하므로 네트워크 경로가 이제 대칭적입니다.
이러한 설정은 마이그레이션된 VM이 온프레미스 리소스에 도달하기에는 최적이 아닐 수 있지만 , 온프레미스 리소스에 대한 보다 구체적인 일치 기준을 포함하는 새 정책 경로를 추가하여 사용자 지정할 수 있습니다.
매우 구체적인 정책 경로를 추가합니다.
MON이 활성화된 네트워크 확장에서 정책 경로가 작동하는 방식을 보여주는 또 다른 좋은 예는 최적의 경로로 특정 리소스에 도달하기 위해 매우 구체적인 정책 경로를 추가하는 것입니다.
예제에서는 기본 정책 경로를 다시 만들고 Azure 호스팅 리소스와 일치하는 규칙이 /32있는 경로를 추가합니다 .denyazure-vm
- 10.0.0.0/8: HCX로 소스로 보내기: 허용
- 172.16.0.0/12: HCX로 소스로 보내기: 허용
- 192.168.0.0/16: HCX로 소스로 보내기: 허용
- 10.100.2.36/32: HCX로 소스로 보내기: 거부
이 새로운 설정에서는 Azure 호스팅 리소스에 대한 네트워크 경로가 azure-vm이제 양방향으로 최적화되었습니다.
- 개인 RFC1918 범위(예: 10.0.0.0/8)의 온프레미스 리소스에 도달하려면 온프레미스 gw장치가 사용됩니다 (↔ 보라색) .
- 클라우드 기반 특정 리소스( 10.100.2.36/32)에 접근하기 위해서는 클라우드 측 게이트웨이 (↔주황색) 를 이용합니다 .
참고: 다이어그램을 단순화하기 위해 인터넷 연결을 제거했지만 인터넷에 도달하는 네트워크 경로에는 변화가 없습니다.
인터넷 연결을 위한 정책 경로 사용
이전 섹션에서는 정책 경로를 사용하여 특정 리소스에 도달하는 네트워크 경로를 최적화할 수 있다는 것을 살펴보았습니다. 또한, 정책 경로를 사용하여 인터넷(또는 0.0.0.0/0)에 도달하는 네트워크 경로를 최적화하거나 안내할 수도 있습니다.
기본 정책 경로를 사용한 인터넷 이탈
기본 정책 경로( 라우터 위치가 클라우드 측 게이트웨이로 설정됨) 를 사용하여 인터넷에 도달하는 네트워크 경로를 살펴보겠습니다 .
인터넷( 0.0.0.0/0)은 온프레미스 게이트웨이(기본 정책 경로 사용)를 사용하도록 구성된 RFC1918 주소 공간의 일부가 아니므로 마이그레이션된 VM은 T1 게이트웨이와 세그먼트의 Azure 송신 연결을 사용하여 인터넷 (↔ 분홍색) 에 도달합니다 .
참고 : 인터넷에 접속하는 Azure 이그레스 경로는 Azure VMware Solution SDDC 구성에 따라 달라질 수 있습니다. 이 예에서는 Azure 이그레스가 기본 Microsoft Managed SNAT 로 구성되어 있습니다 . AVS의 인터넷 연결에 대한 자세한 내용은 다음 게시물에서 확인할 수 있습니다. Azure VMware Solution – NSX-T Edge에서 공용 IP 사용 .
특정 정책 경로를 사용한 인터넷 이탈
온프레미스 gw장치를 통해 인터넷에 접속하기 위한 특정 정책 경로를 추가해 보겠습니다( 라우터 위치는 여전히 클라우드 측 게이트웨이로 설정됨):
- 0.0.0.0/0: HCX로 소스로 보내기: 허용
이 새로운 정책 경로를 통해 마이그레이션된 VM은 이제 온프레미스 gw장치를 사용하여 인터넷에 접속합니다 (↔ 분홍색) . 그런 다음 온프레미스 gw장치에 방화벽 규칙을 적용하여 마이그레이션된 VM의 인터넷 액세스를 제어할 수 있습니다.
추가 정책 경로 없이 모든 네트워크 흐름도 이 온프레미스 gw장치를 사용하게 됩니다. 다른 리소스에 도달하는 네트워크 경로를 최적화하기 위해 추가 정책 경로를 추가하지 않고 MON을 활성화하는 것은 역효과가 있을 수 있습니다.
균형의 예술
이전 예제를 실제 운영 환경에서 재현하지 마세요.
이전 예시는 설정 변경에 따른 MON 지원 리소스 및 네트워크 흐름의 동작을 설명하기 위해 제공되었습니다. 문제를 방지하고 네트워크 흐름 경로에서 예상 보안 수준을 유지하려면 배포 환경에 따라 전역 및/또는 특정 흐름 정책을 적용하는 방법을 신중하게 고려해야 할 것입니다.
예를 들어, 흐름이 NSX-T Tier1을 사용하면 온프레미스 방화벽으로 더 이상 보호되지 않으며 NSX-T 수준에서 일부 방화벽 규칙을 설정해야 할 수 있습니다.
또한 MON에는 몇 가지 제한 사항이 있으며 모든 사용 사례에 적합하지 않을 수 있습니다. MON 활성화를 진행하기 전에 기존 문서를 꼼꼼히 검토하는 것이 필수적입니다. AVS 관련 자료는 다음 문서 페이지를 참고하는 것이 좋습니다. VMware HCX 모빌리티 최적화 네트워킹(MON) 가이드 .
마지막으로, 네트워크 확장 컷오버 작업을 마이그레이션 프로젝트의 중요한 단계로 고려하고 신중하게 계획할 것을 강력히 권장합니다 . 모빌리티 최적화 네트워킹(Mobility Optimized Networking) 기능은 네트워크 흐름 경로를 최적화하고 네트워크 트롬보닝(Tromboning) 시나리오를 방지하거나 제한하는 데 큰 도움이 되지만, 모든 네트워크 문제를 해결하거나 네트워크 확장 컷오버 작업을 건너뛸 수 있는 마법 같은 기능이 아니라 마이그레이션 목표 달성을 위한 도구로 간주해야 합니다. 장기적인 네트워크 확장의 경우, 마이그레이션된 VM의 기본 게이트웨이를 클라우드 측 게이트웨이로 변경하는 것이 네트워크 흐름을 최적화하는 좋은 방법이 될 수 있습니다.
'IT이야기 > Azure' 카테고리의 다른 글
| Azure VMware Solution NSX-T 배포 시 타사 방화벽 NVA 사용 (0) | 2025.04.15 |
|---|---|
| Azure Data Explorer 및 Grafana를 사용하여 Azure VMware 솔루션 모니터링 (0) | 2025.04.15 |
| Azure VMware Solution 스토리지를 확장하기 위한 Azure Elastic SAN (0) | 2025.04.15 |
| Azure VMware Solution으로 마이그레이션하는 동안 IP 주소를 유지하는 방법 (2) | 2025.04.15 |
| Azure VMware 솔루션 – NSX-T Edge에서 공용 IP 사용 (0) | 2025.04.15 |