VMware HCX를 직접 사용해 본 경험을 바탕으로, 최근 금융 서비스 회사와의 프로젝트 계획의 일환으로 Azure VMware Solution(AVS)에 대해 몇 주 동안 조사했습니다. 해당 고객은 여러 클러스터에 걸쳐 500개의 VM이 있는 온프레미스 VMware 환경을 AVS로 마이그레이션하고자 합니다. 핵심 애플리케이션 리팩토링 없이 데이터 센터를 대피시키려는 목표 때문입니다. 이 블로그 게시물 "VMware HCX를 사용하여 Azure VMware Solution으로 워크로드 마이그레이션: 실무 가이드" 에서는 제가 조사한 내용을 바탕으로 실용적이고 구체적인 계획을 제시하고 이러한 유형의 마이그레이션에 대한 접근 방식을 제시합니다. 자세한 설명은 생략하고, 전략, 아키텍처, 도구, 연구를 통해 얻은 교훈, 그리고 피해야 할 함정에 대해 중점적으로 설명하겠습니다. 이 글은 VMware HCX를 사용하여 온프레미스 환경에서 Azure VMware Solution으로 워크로드를 마이그레이션하려는 모든 분들을 위해 작성되었습니다.

마이그레이션 계획의 토대를 마련하기 위해 AVS와 HCX의 기본 사항을 먼저 살펴보겠습니다.

Azure VMware 솔루션 및 VMware HCX 이해

마이그레이션 계획을 논의하기 전에 AVS와 HCX가 제공하는 서비스를 명확하게 이해하는 것이 중요합니다. 많은 전문가들이 관련된 세부적인 사항들을 과소평가하여 마이그레이션 계획 과정에서 오해와 실수를 저지르게 됩니다.

AVS는 Azure에 호스팅되는 전용 VMware 소프트웨어 정의 데이터 센터(SDDC) 환경을 제공하는 Microsoft 관리 서비스입니다. 컴퓨팅을 위한 vSphere, 스토리지를 위한 vSAN, 네트워크 가상화를 위한 NSX-T 등 익숙한 구성 요소를 포함합니다. 이 환경은 베어 메탈 서버에 호스팅되며 Azure SQL 또는 Azure AD와 같은 네이티브 Azure 서비스와 통합할 수 있습니다. AVS는 온프레미스 VMware 환경을 미러링하므로 고객이 워크로드를 재설계하지 않고도 데이터 센터를 확장하거나 이전할 수 있는 잠재적인 옵션입니다.

VMware HCX는 마이그레이션의 엔진입니다. 대량 VM 이동, 라이브 마이그레이션, 재해 복구 및 네트워크 확장을 위한 도구를 제공하며, 대역폭 사용량을 줄이기 위한 WAN 최적화(압축 및 중복 제거)와 같은 기능도 제공합니다. HCX는 IP 주소를 변경하거나 복잡한 종속성을 재구성하지 않고도 워크로드를 이동할 수 있으므로 AVS(애플리케이션 보안 시스템) 프로젝트에 특히 유용합니다. 제가 사용할 주요 HCX 마이그레이션 방법은 다음과 같습니다.

• vMotion : 가동 중인 VM을 다운타임 없이 라이브 마이그레이션합니다. 대역폭에 민감하므로 신중한 계획이 필요합니다.
• 대량 마이그레이션 : 최소 컷오버 다운타임(~분)으로 예약된 복제를 수행합니다. 대용량 작업에 적합합니다.
• 복제 지원 vMotion(RAV) : 사전 시딩과 vMotion을 결합하여 데이터베이스와 같은 대규모의 높은 변경률의 VM을 지원합니다.
• 콜드 마이그레이션 : 마이그레이션 전에 전원을 끌 수 있는 VM의 경우 레거시 또는 테스트 워크로드에 자주 사용됩니다.
• OS 지원 마이그레이션(OSAM) : 물리적 서버나 Hyper-V 워크로드를 vSphere로 마이그레이션하는 데 사용됩니다.

올바른 마이그레이션 유형을 선택하는 것이 중요합니다. 중요한 워크로드에는 vMotion을, 일반 VM에는 Bulk를, 그리고 vSphere가 아닌 환경처럼 필요한 경우에만 OSAM을 혼합하여 사용하는 것을 권장합니다. 참고로, 아래 비교표를 참고해 보세요.

이러한 기술을 미리 이해하면 불필요한 위험과 다운타임을 방지하는 데 도움이 됩니다. 이는 복잡한 프로젝트를 시작하기 전에 도구를 미리 아는 것과 같습니다. 성공으로 가는 지름길입니다. 이러한 기반을 마련한 후, 다음 단계는 고객 환경을 면밀히 평가하여 마이그레이션 준비 상태를 확인하는 것입니다.

이주 전 평가

적절한 탐색 단계는 모든 성공적인 AVS 마이그레이션의 기반입니다. 제 연구에 따르면 이 단계를 건너뛰거나 서두르면 심각한 문제가 발생할 수 있으므로, VMware 네이티브 도구와 Azure 네이티브 도구를 함께 사용하여 고객 환경을 분석하는 데 충분한 시간을 할애하여 준비 상태를 유지하는 것이 좋습니다.

저는 다음과 같은 방식으로 평가에 접근하기를 제안합니다.

• VM 인벤토리 및 크기 조정 : RVTools 또는 vRealize Operations를 사용하여 CPU, RAM, 디스크 및 스냅샷 정보를 수집합니다. Azure Migrate는 크기 권장 사항을 생성하고 레거시 OS 버전과 같이 지원되지 않는 구성을 플래그로 지정할 수 있습니다.
• 애플리케이션 종속성 매핑 : Azure Migrate의 종속성 시각화를 활용하여 최소 30일 동안 실행하여 트래픽 흐름을 파악합니다. 이를 통해 문서화되지 않은 MSSQL 인스턴스에 백엔드 호출을 수행하는 레거시 웹 서버와 같은 숨겨진 종속성을 파악할 수 있습니다.
• 호환성 검사 : vSphere 버전(6.5 이상), 가상 하드웨어 호환성, OS 지원 및 네트워크 토폴로지를 확인하세요. 검증을 위해 VMware 상호 운용성 매트릭스 및 HCX 설명서를 활용하세요.
• 워크로드 분류 : 미션 크리티컬, 프로덕션, 개발, 보관 등의 범주로 워크로드를 분류합니다. 이를 통해 단계별 마이그레이션 및 롤백 옵션을 계획하는 데 도움이 됩니다.
• 특수 워크로드 : 원시 장치 매핑(RDM), PCI 패스스루 장치 또는 HCX 복제 제한(일반적으로 8TB)을 초과하는 대용량 디스크 등 추가 계획이 필요한 VM을 파악합니다. 문제 발생을 방지하기 위해 RDM을 VMDK로 변환하는 것을 계획합니다.
• 규정 준수 평가 : 규정 준수를 보장하기 위해 GDPR이나 HIPAA와 같은 요구 사항을 Azure 정책에 매핑합니다.

철저한 마이그레이션 전 평가는 마치 집을 짓기 위한 기초를 다지는 것과 같습니다. 이 부분이 제대로 된다면 나머지 마이그레이션은 훨씬 더 수월해집니다. 중요한 것은 잠재적인 장애물을 조기에 파악하는 것입니다. 평가가 계획되었으니, 이제 HCX 통합을 위한 온프레미스 환경을 준비하는 단계로 넘어가겠습니다.

온프레미스 환경 준비

발견 단계가 완료되면 다음 단계는 HCX 통합을 위해 고객의 온프레미스 인프라를 준비하는 것입니다. 이 단계는 대부분 기술적인 내용이지만, 지연으로 인해 일정이 지연되는 것을 방지하기 위해 네트워크 및 방화벽 팀과 조기에 협력하는 것이 좋습니다.

제가 제안하는 준비 계획은 다음과 같습니다.

• HCX 커넥터 배포 : vSphere 환경에 HCX 커넥터 OVA를 배포합니다. vCenter 및 NSX Manager에 등록하고, 서비스 메시 설정을 진행하기 전에 등록이 완료되었는지 확인합니다.
• 네트워크 구성 및 준비 :
  • 온프레미스 사이트와 AVS 환경 간의 레이어 3 연결을 검증합니다.
  • 모든 HCX 어플라이언스 간에 필수 포트(TCP 443, UDP 4500)를 엽니다.
  • vCenter, HCX 및 NSX 구성 요소에 대한 DNS 확인을 양방향으로 보장합니다.
  • 인증이나 복제에 영향을 미치는 시간 편차 문제를 방지하려면 NTP 설정을 동기화하세요.
• 워크로드 그룹화 : 애플리케이션, 종속성 및 비즈니스 기간을 기준으로 논리적 마이그레이션 그룹을 생성합니다. 이를 통해 웹 서버와 데이터베이스를 그룹화하는 등 마이그레이션 계획 수립 및 테스트가 간소화됩니다.

온프레미스 환경을 철저히 준비하는 것이 전체 마이그레이션의 토대를 마련합니다. 시간 동기화 문제와 같은 사소한 실수가 문제 해결에 몇 시간씩 소요될 수 있으므로, 세부 사항에 대한 주의가 매우 중요합니다. 이제 환경이 준비되었으니, 마이그레이션 아키텍처를 설계할 전략적 계획 단계로 넘어가겠습니다.

VMware에서 AVS로의 마이그레이션을 위한 전략적 계획

전략적 계획은 마이그레이션이 구체화되는 단계입니다. 이 단계에서는 네트워킹, 리소스 크기 조정, HCX 구성, AVS 설정 등을 신중하게 고려해야 합니다. 성공적인 마이그레이션을 위해 이 단계를 핵심 영역으로 나누어 설명하겠습니다.

네트워킹 고려 사항

이는 아키텍처에서 가장 복잡한 부분입니다. HCX와 AVS의 네트워킹은 강력하지만 잘못 구성하면 심각한 문제를 야기할 수 있습니다. 따라서 고객의 잠재적 요구 사항에 맞춰 세부적으로 살펴보겠습니다.

• ExpressRoute : 낮은 지연 시간과 높은 대역폭이 필요한 프로덕션 워크로드(예: 실시간 데이터를 사용하는 금융 앱)에 권장됩니다. 프라이빗 피어링을 사용하고 HCX 성능을 위해 MTU 설정이 1600바이트를 지원하는지 확인하십시오. 대규모 배포 또는 다중 사이트 연결이 필요한 고객에게 적합합니다.
• 사이트 간 VPN은 지연 시간 허용 범위가 높은 소규모 또는 테스트 환경에 비용 효율적인 대안입니다. 고객의 초기 마이그레이션이 파일럿 단계 또는 중요하지 않은 워크로드로 제한되는 경우에 이상적입니다.
• 결정 매트릭스 : 100개 이상의 VM이나 고성능 요구 사항에는 ExpressRoute를 사용하고, 50개 미만의 VM이나 초기 테스트에는 VPN을 사용합니다.
• 글로벌 도달 범위 : ExpressRoute 회선이 여러 Azure 지역에 걸쳐 있는 경우(예: 고객이 미국 동부 및 서부 지역에서 운영하는 경우) 필요합니다. 허브와 AVS 프라이빗 클라우드 간 라우팅을 지원합니다. 고객이 다중 지역 전략을 사용하는 경우 이 기능을 고려하십시오.
• 2계층 네트워크 확장 : HCX NE를 사용하면 VM이 IP 주소를 유지할 수 있습니다. 각 어플라이언스는 최대 8개의 VLAN을 지원하므로, 고객이 더 많은 네트워크를 확장해야 할 경우 추가 어플라이언스를 계획하십시오.
• 모빌리티 최적화 네트워킹(MON) : Azure를 통해 최적화된 송신을 활성화하여 비대칭 라우팅을 해결합니다. 특히 고객이 확장된 네트워크를 사용하는 경우, 반환 트래픽에 대한 방화벽 규칙을 구성하세요.
• 허브-스포크 토폴로지 : 공유 서비스(DNS, ID, 모니터링)를 사용하는 허브에 연결된 스포크 VNet에 AVS를 배치합니다. 고객은 보안 및 관리를 중앙에서 관리하는 것이 좋습니다.
• Azure vNet 통합 : Azure 서비스를 사용한 하이브리드 시나리오에서 허브 VNet과 AVS VNet을 연동하여 고객이 Azure 기본 도구를 활용할 수 있도록 보장합니다.

네트워크 설정 다이어그램은 다음과 같습니다.

AVS 구성

AVS 환경 구성은 고객의 요구를 충족하는 데 매우 중요합니다. 여기에는 온프레미스 환경 및 마이그레이션 목표에 맞춰 SDDC를 설정하는 것이 포함됩니다.

• 노드 크기 조정 : 최소 3개 노드 클러스터에서 AV36개 노드(36코어, 576GB RAM, 15.36TB NVMe)로 시작하세요. 고객의 VM 수(예: VM 500개에는 6~8개 노드가 필요할 수 있음)와 성능 요구 사항에 따라 확장하세요.
• vSAN 구성 : 중복성을 위해 Fault Tolerance(FTT=1, RAID-1)를 활성화합니다. 스토리지 최적화를 위해 중복 제거 및 압축을 계획하되, 복제 트래픽 및 스냅샷으로 인한 잠재적 오버헤드를 모니터링합니다.
• NSX-T 설정 : 고객의 온프레미스 네트워크 토폴로지에 맞게 NSX-T 세그먼트를 구성합니다. L2 확장 통합을 계획하고 보안 정책(예: 분산 방화벽 규칙)을 정의합니다.
• Azure 통합 : Azure vNet 피어링을 설정하고 공유 서비스(예: DNS, Azure AD)를 위한 허브 VNet과 통합합니다. 고객의 기존 Azure 구독과의 호환성을 보장합니다.
• 리소스 할당 : Azure Migrate 크기 권장 사항에 따라 CPU, RAM 및 스토리지를 할당하고 성장에 대비해 20~30% 여유 공간을 추가합니다.

AVS를 사용한 HCX에 대한 네트워크 설계 고려 사항

VMware HCX를 사용하여 온프레미스 환경에서 Azure VMware Solution으로 워크로드를 마이그레이션할 때 네트워크 설계는 아키텍처에서 가장 중요한 부분 중 하나가 됩니다. HCX가 모빌리티 및 네트워크 확장의 복잡성을 상당 부분 처리하지만, 부적절한 라우팅, 세분화 및 어플라이언스 배치 계획은 심각한 중단이나 마이그레이션 실패를 초래할 수 있습니다.

이 섹션의 개념을 뒷받침하기 위해 HCX를 AVS로 마이그레이션할 때 가장 중요한 네트워크 설계 고려 사항을 요약한 아래 이미지를 만들었습니다.

허브 앤 스포크 토폴로지

다이어그램의 왼쪽 상단 사분면은 허브-스포크 네트워크 아키텍처를 보여줍니다 . 이는 Azure에서 권장되는 디자인 패턴입니다. AVS 프라이빗 클라우드는 스포크 가상 네트워크(VNet)로 배포되는 반면, 허브에는 DNS, Active Directory, NVA 방화벽, 모니터링, ExpressRoute 게이트웨이와 같은 중앙 집중식 서비스가 포함됩니다. 각 스포크는 VNet 피어링을 통해 허브에 연결되어 공유 서비스를 통한 트래픽 흐름을 허용하는 동시에 스포크 간 수평 이동을 격리합니다.

이러한 설계는 라우팅을 간소화하고, 중앙 지점에서 보안 정책을 시행하며, 여러 지역이나 환경 전반에서 일관성을 보장합니다.

NSX-T 세그먼트 계획

AVS는 네트워크 가상화에 NSX-T를 사용하고 , HCX는 온프레미스 환경에서 AVS로 레이어 2 네트워크를 확장할 수 있습니다. 하지만 모든 네트워크를 확장할 수 있거나 확장해야 하는 것은 아닙니다.

이미지의 오른쪽 상단 사분면은 일반적인 문제인 서브넷 중복을 보여줍니다 . 기존 세그먼트와 동일한 IP 범위를 사용하는 AVS로 네트워크를 확장하면 라우팅 충돌과 예측할 수 없는 동작이 발생합니다. 이미지는 서브넷을 복제할 때 192.168.12.0/24여러 소스에서 확장되거나 두 번 이상 사용될 경우 문제가 발생할 수 있음을 보여줍니다.

네트워크 확장을 배포하기 전에 항상 서브넷을 신중하게 문서화하고 계획하세요.

서비스 메시 범위

왼쪽 하단 사분면에서는 HCX 서비스 메시 고려 사항을 다룹니다. 이는 HCX 연결의 핵심으로, 온프레미스 환경과 AVS 환경 간의 경로를 정의합니다. 각 서비스 메시에는 양쪽에 구축된 인터커넥트 및 네트워크 확장과 같은 어플라이언스가 포함됩니다.

주요 고려 사항:

• 각 NE 어플라이언스는 최대 8개의 확장 네트워크를 지원합니다.
• 처리량 제한 과 예상 마이그레이션 동시성을 고려해야 합니다.
• 서비스 메시는 클러스터별로 신중하게 범위를 지정해야 합니다.

이 다이어그램은 NE 어플라이언스가 확장 한계에 도달할 수 있음을 보여줍니다. 8개 이상의 네트워크를 확장하는 경우, 추가 어플라이언스를 구축하거나 여러 메시에 걸쳐 마이그레이션을 분할하십시오.

모빌리티 최적화 네트워킹(MON)

이는 레이어 2 네트워크 확장을 사용할 때 가장 간과되지만 중요한 기능 중 하나입니다. 이미지 중앙에 표시된 것처럼, 모빌리티 최적화 네트워킹(MON)을 사용하면 마이그레이션된 VM이 원래 온프레미스 IP 주소를 유지하더라도 AVS의 로컬 라우팅을 사용할 수 있습니다.

MON이 없으면 인터넷이나 Azure 서비스에서 반환되는 트래픽이 온프레미스 게이트웨이를 통해 다시 라우팅되어 비대칭 라우팅 및 트래픽 손실이 발생할 수 있습니다. 다이어그램은 두 가지 가능한 흐름을 보여줍니다.

• VM이 Azure 게이트웨이를 직접 사용하는 파선 HCX MON 경로
• 라우팅 문제를 야기하는 최적화되지 않은 경로인 비대칭 경로로 표시된 곡선 경로

MON을 활성화하려면 다음이 필요합니다.

• AVS 세그먼트에 NSX-T 게이트웨이 지원이 있는지 확인하십시오.
• 로컬 이탈을 허용하기 위한 올바른 방화벽 규칙
• 라우팅 변경 및 테스트 검증에 대한 인식

MON은 특히 Azure 네이티브 서비스나 인터넷 엔드포인트에 액세스하는 애플리케이션의 경우 많은 마이그레이션 이후 문제를 해결합니다.

방화벽 및 라우팅

오른쪽 상단 사분면에 표시된 또 다른 핵심 사항은 방화벽과 라우팅 인식 의 중요성입니다 . HCX는 모든 어플라이언스 간에 여러 포트(예: TCP 443 및 UDP 4500)를 양방향으로 개방해야 합니다. 특히 MON이 활성화된 경우 리턴 라우팅은 예측 가능하고 대칭적이어야 합니다 .

Azure 또는 온프레미스에서 네트워크 가상 어플라이언스(NVA)를 사용하는 경우, 해당 어플라이언스가 NAT를 수행하거나 HCX가 사용하는 트래픽을 차단하지 않는지 확인하세요. 연결 문제가 발생하는 경우, 방화벽이나 라우팅 구성 오류로 인해 발생하는 경우가 많습니다.

ExpressRoute 및 MTU 고려 사항

마지막으로, 오른쪽 하단 사분면은 많은 팀이 검증 과정에서 간과하는 MTU 크기와 ExpressRoute 구성을 강조합니다 . HCX Interconnect 트래픽은 단편화에 민감합니다. AVS 환경에는 최소 1500의 MTU가 필요하며 , 특히 대량 또는 RAV 마이그레이션 방식을 사용할 때 성능과 안정성을 위해 점보 프레임(1600바이트 이상)을 활성화하는 것이 좋습니다.

프로덕션 마이그레이션을 시작하기 전에 항상 MTU 경로를 종단 간 테스트하세요.

클러스터 및 리소스 계획

AVS 프라이빗 클라우드는 단순히 온프레미스 호스트 수만이 아니라 고객의 실제 사용 데이터를 기반으로 해야 합니다. AVS 노드는 일관된 성능을 제공하지만, 통합에는 신중한 계획이 필요합니다.

• 용량 계획 : CPU, RAM 및 스토리지 사용량 보고서에는 Azure Migrate 또는 vRealize Operations를 사용하세요. 용량 증가 및 급증에 대비하여 20~30%의 여유 용량을 추가하세요.
• 클러스터 크기 조정 : 최소 3개 노드 클러스터로 시작하여 500개 VM 부하에 따라 점진적으로 확장합니다.
• 스토리지 고려 사항 : 중복성을 위해 FTT=1, RAID-1로 vSAN을 구성하십시오. 스토리지 사용량을 관리하기 위해 중복 제거/압축을 모니터링하십시오.

HCX 서비스 메시 및 마이그레이션 방법

HCX 서비스 메시는 마이그레이션 트래픽 흐름 방식을 정의하여 마이그레이션 인프라의 초석을 제공합니다. 이 부분의 구성 오류는 프로젝트를 방해할 수 있습니다.

• 서비스 메시 배포 : 온프레미스 HCX 커넥터를 AVS HCX 클라우드 매니저와 연결합니다. 정확한 라우팅을 위해 컴퓨팅 및 네트워크 프로필을 정의합니다.
• HCX Interconnect : 안전하고 암호화된 마이그레이션 트래픽을 처리합니다. 적절한 대역폭을 확보하세요.
• 네트워크 확장(NE) : L2 스트레칭에 필요함. 용량 계획(어플라이언스당 8개 VLAN)
• 모빌리티 최적화 네트워킹(MON) : 마이그레이션 후 비대칭 라우팅을 방지합니다.
• 마이그레이션 방법 :
  • vMotion: 중요한 앱(예: 웹 서버).
  • 대량: 개발/테스트 VM.
  • RAV: 데이터베이스(예: SQL Server).
  • 추위: 레거시 시스템.
  • OSAM: 물리적 Linux 서버.

서비스 메시 레이아웃은 다음과 같습니다.

계획 단계에서 네트워킹, AVS 구성, 크기 조정 및 HCX 구성을 정확하게 설정하는 것은 매우 중요합니다. 마치 튼튼한 집의 기초를 쌓는 것과 같습니다. 서브넷 겹침과 같은 작은 실수도 심각한 지연을 초래할 수 있습니다. 아키텍처 설계를 완료했으니, 이제 마이그레이션 실행 계획 단계로 넘어가 보겠습니다.

마이그레이션 실행 및 운영

마이그레이션을 효과적으로 실행하려면 신중한 계획과 엄격한 검증이 필요합니다. 바로 이 부분에서 준비가 빛을 발하며, 성공을 위한 체계적인 접근 방식을 간략하게 설명하겠습니다.

제가 제안하는 실행 계획은 다음과 같습니다.

• HCX 설정 : HCX Manager를 사용하여 온프레미스 vCenter와 AVS vCenter를 페어링합니다. 컴퓨팅/네트워크 프로필을 사용하여 서비스 메시를 배포합니다.
• 네트워크 확장 : HCX NE를 통해 VLAN을 확장하고, ping 테스트로 검증하여 문제를 조기에 포착합니다.
• 파일럿 웨이브 : 대량 마이그레이션을 사용하여 프로세스를 테스트하기 위해 5~10개의 비중요 VM으로 시작합니다.
• 예약된 웨이브 : 비즈니스 윈도우에 맞춰 조정하세요. 중요한 VM에는 vMotion/RAV를 사용하여 다운타임을 최소화하세요.
• 롤백 전략 : 검증될 때까지 전원이 꺼진 소스 VM을 보관합니다.
• 모니터링 및 로깅 : HCX 대시보드를 사용하고 추적을 위해 VM에 태그를 지정하여 가시성을 유지합니다.

마이그레이션 워크플로는 다음과 같습니다.

성공의 핵심은 각 단계마다 엄격한 검증을 거치는 단계적 접근 방식입니다. 파일럿 웨이브는 실제 운영 환경으로의 마이그레이션 전에 문제를 파악하고 해결하는 데 도움이 될 것입니다. 워크로드가 AVS에 배치되면 다음 단계는 최적화 및 완료를 위한 계획 수립입니다.

마이그레이션 후 최적화 및 마무리

마이그레이션 후 최적화는 간과되는 경우가 많지만, AVS로 워크로드를 이전하여 얻을 수 있는 이점을 최대한 활용하는 데 매우 중요합니다. 이 단계는 최적의 성능, 리소스 효율성 및 비용 관리를 보장합니다.

제가 추천하는 최적화 계획은 다음과 같습니다.

• 성능 검증 : Azure Monitor와 vRealize Operations를 사용하여 CPU, 메모리, 디스크 지연 시간 및 네트워크 처리량을 확인합니다.
• 검증 체크리스트 :
  • 앱 기능.
  • DNS 확인.
  • 네트워크 연결성.
• 워크로드 적정 크기 조정 : VM 크기가 너무 크면 리소스가 낭비됩니다. Azure 권장 사항을 활용하여 가능한 경우 VM 크기를 줄이세요.
• 네트워크 확장 해제 : NSX-T 세그먼트로 전환한 후 사용하지 않는 L2 확장을 제거합니다.
• 비용 관리 : Azure Cost Management를 사용하여 예산과 알림을 설정하고, 업무 시간 외에는 프로덕션 환경이 아닌 VM의 종료를 예약할 수 있습니다.
• 거버넌스 :
  • Azure Automation으로 패치합니다.
  • Azure Policy 준수 여부를 감사합니다.

마이그레이션 후 최적화는 AVS에 대한 투자를 극대화하고 장기적인 안정성을 보장합니다. 단순히 클라우드에 접속하는 것만이 아니라, 클라우드에 접속한 후 효율적으로 운영하는 것이 중요합니다. 최적화된 환경을 바탕으로 보안, 규정 준수 및 거버넌스의 핵심 측면을 살펴보겠습니다.

보안, 규정 준수 및 거버넌스

워크로드를 AVS로 마이그레이션하려면 인프라를 Azure의 거버넌스 및 보안 모델과 통합해야 합니다. 워크로드를 보호하고 신뢰를 유지하려면 조직의 표준을 AVS 환경으로 원활하게 확장하는 것이 필수적입니다.

제가 제안하는 보안 및 거버넌스 계획은 다음과 같습니다.

• ID 및 액세스 관리(IAM) : 역할 기반 액세스 제어(RBAC)를 위해 Azure Active Directory(Azure AD)를 통합합니다. vCenter 접근 권한을 필수 인력으로 제한합니다.
• 보안 통합 : Azure Firewall, Defender for Cloud, Azure Sentinel을 사용하여 위협을 탐지하고 대응합니다.
• 규정 준수 관리 : Azure Policy를 활용하여 PCI-DSS, GDPR 또는 ISO 27001과 같은 표준을 시행합니다. Azure Security Center를 통해 정기 감사를 수행합니다.
• 중앙 집중식 로깅 및 모니터링 : 가시성을 높이기 위해 Azure Monitor 또는 Sentinel로 로그를 스트리밍합니다.

강력한 보안, 규정 준수 및 거버넌스 조치는 워크로드를 보호하고 비즈니스 연속성을 보장하는 데 필수적이며, 특히 금융과 같이 규제가 엄격한 산업의 경우 더욱 그렇습니다. 마이그레이션 계획에 대한 최종적인 생각과 의견을 공유해 보겠습니다.

마지막 생각

VMware HCX를 사용하여 AVS로 마이그레이션을 계획하는 것은 전략적이고 세부적인 작업으로, 신중한 준비와 VMware에 대한 심층적인 전문 지식이 필요합니다. 제 연구에 따르면 성공적인 마이그레이션은 정확한 평가, 세부적인 준비, 견고한 네트워킹 구성, 적절한 AVS 설정, 그리고 철저한 마이그레이션 후 최적화에 달려 있습니다. 고객의 500개 VM을 이전하는 이 계획은 최소한의 중단으로 원활하게 전환하기 위한 체계적인 접근 방식을 제시합니다.

HCX와 AVS를 통해 제공되는 기술과 도구 덕분에 프로세스 관리가 더욱 수월해졌지만, 명확한 소통, 상세한 문서화, 그리고 모든 단계에서 엄격한 검증의 중요성을 절대 과소평가해서는 안 된다는 것을 깨달았습니다. 마이그레이션 기간을 비즈니스 요구 사항에 맞추고 팀 간의 원활한 협업을 보장하는 것은 기술 설정만큼이나 중요합니다. 사전 계획 및 테스트에 상당한 노력을 투자하는 것을 강력히 권장합니다. 위험을 줄일 수 있고, 원활한 전환을 보장하여 마이그레이션을 단순한 기술적 성과가 아닌 비즈니스 성공으로 만들어 줍니다.

제 연구 결과와 이 계획이 AVS 마이그레이션 여정에 도움이 되기를 바랍니다. 궁금한 점이나 공유하고 싶은 경험이 있으시면 언제든지 댓글을 남겨주시거나 직접 연락해 주세요. 앞으로 더 많은 논의를 기대하겠습니다.

자주 묻는 질문

제가 자주 접하는 질문에 대한 답변은 다음과 같습니다.

• 예상 다운타임은 얼마나 되나요? vMotion은 다운타임이 없고, 대량 마이그레이션은 몇 분 정도 걸리며, 콜드 마이그레이션은 다운타임이 더 길어집니다.
• AVS 라이선스는 어떻게 적용되나요? Azure Hybrid Benefit을 사용하면 Windows Server 및 SQL Server 라이선스 비용을 절감할 수 있습니다.
• 문제가 발생하면 어떻게 되나요? 안전한 롤백을 위해 마이그레이션된 워크로드가 완전히 검증될 때까지 소스 VM을 보관하세요.

추가 자료 및 공식 참조

공식 문서를 살펴보거나 HCX 및 Azure VMware Solution의 특정 영역을 더 자세히 알아보고 싶은 독자를 위해 다음과 같은 권장 리소스를 소개합니다.

• VMware HCX 설명서
  https://docs.vmware.com/en/VMware-HCX/index.html
• Azure VMware 솔루션 설명서 – Microsoft Learn
  https://learn.microsoft.com/en-us/azure/azure-vmware/
• AVS에서 VMware HCX 구성
  https://learn.microsoft.com/en-us/azure/azure-vmware/configure-vmware-hcx
• AVS 마이그레이션 아키텍처
  https://learn.microsoft.com/en-us/azure/azure-vmware/architecture-migrate

워크로드 검색 및 평가에 대한 Azure Migrate 설명서를 검토할 수도 있습니다 .

• https://learn.microsoft.com/en-us/azure/migrate/migrate-overview

이 VMware HCX란 무엇이며, 어떻게 작동하나요 ? 에서는 HCX에 대한 간단한 설명과 마이그레이션 시나리오 유형, 그리고 HCX가 워크로드 마이그레이션에 어떻게 도움이 될 수 있는지에 대해 알려드리겠습니다.

VMware HCX(이전 명칭: Hybrid Cloud Extension 및 NSX Hybrid Connect)는 대규모 확장이 가능한 하이퍼바이저 기반 슈퍼컴퓨팅 플랫폼으로, 온디맨드 셀프 서비스 클라우드 형태로 제공되어 고객이 수십 개의 VMware ESXi 호스트에서 복잡한 실시간 애플리케이션과 고성능 분석을 몇 초 만에 실행할 수 있도록 지원합니다. 사전 하드웨어 구매는 필요하지 않습니다.

HCX란 무엇인가요?

VMware HCX는 데이터센터와 클라우드 전반에서 간소화된 애플리케이션 마이그레이션, 워크로드 리밸런싱, 비즈니스 연속성을 지원하는 애플리케이션 모빌리티 플랫폼입니다. 무제한 모빌리티, 안전한 대규모 마이그레이션, 하이브리드 네트워킹 등의 기능을 제공합니다. 또한, HCX는 VMware vSphere Replication 프로토콜을 활용하여 사전 정의된 일정에 따라 가상 머신을 병렬로 이동하는 대량 마이그레이션 옵션을 제공합니다. HCX는 환경 및 사용 사례에 따라 소스(HCX 커넥터) 또는 대상(HCX 클라우드)으로 구축할 수 있습니다.

HCX 데이터 마이그레이션 프로세스

HCX 데이터 마이그레이션 프로세스는 간단합니다. HCX를 사용하면 단 몇 분 만에 한 위치에서 다른 위치로 데이터를 마이그레이션할 수 있습니다. 소스 위치와 대상 위치를 선택하고 마이그레이션할 데이터 양을 지정하기만 하면 됩니다. 그러면 HCX가 두 위치 간에 데이터를 자동으로 전송합니다.

성공적인 HCX 마이그레이션 수행

성공적인 HCX 마이그레이션을 수행하려면 다음과 같은 주요 단계를 따라야 합니다.

1. 마이그레이션 계획 및 준비: 마이그레이션 프로세스를 시작하기 전에 이에 따른 계획과 준비가 필수적입니다. 여기에는 마이그레이션할 가상 머신과 애플리케이션을 파악하고, 마이그레이션 방식(vMotion 또는 대량 마이그레이션)을 결정하고, 원본 환경과 대상 환경 간의 네트워크 연결을 평가하는 것이 포함됩니다.
2. HCX 구성 요소 구성: 다음 단계는 마이그레이션 요구 사항에 따라 HCX 커넥터 및 HCX 클라우드를 포함한 HCX 구성 요소를 구성하는 것입니다. 여기에는 상호 연결 네트워크 설정, 사이트 쌍 생성, 필요한 경우 복제 활성화가 포함됩니다.
3. 마이그레이션 설정 테스트: HCX 구성 요소를 구성한 후에는 마이그레이션 설정이 제대로 작동하는지 확인하기 위해 마이그레이션 설정 테스트가 매우 중요합니다. 여기에는 네트워크 연결 테스트, 복제 설정 검증, 가상 머신의 성공적인 마이그레이션 가능 여부 확인이 포함됩니다.
4. 마이그레이션 수행: 마이그레이션 설정 테스트 및 검증이 완료된 후 마이그레이션 프로세스를 시작할 수 있습니다. 마이그레이션이 문제 없이 원활하게 진행되도록 주의 깊게 모니터링하는 것이 중요합니다.
5. 마이그레이션 확인: 마이그레이션이 완료되면 가상 머신과 애플리케이션이 새 환경에서 제대로 작동하는지 확인하는 것이 필수적입니다. 여기에는 애플리케이션 성능 테스트, 네트워크 연결 확인, 데이터 무결성 검증이 포함됩니다.

위의 단계를 따르면 조직은 원활하고 성공적인 HCX 마이그레이션을 보장하여 비즈니스 운영의 중단과 가동 중지 시간을 최소화할 수 있습니다.

HCX 마이그레이션의 두 가지 시나리오:

레거시 환경, vSphere 또는 레거시 KVM/Hyper-V에서 VMware Cloud Foundation(VCF) 환경으로 마이그레이션합니다.

VCF용 HCX

샘플 고객 시나리오

• 프라이빗 클라우드 구축
• 레거시 DC에서 VCF로 변환
• 여러 DC 지역 통합
• VCF에서 VCF 버전으로 업그레이드
• vSphere 7 업그레이드

HCX의 장점

• 대규모 이주 추진
• 자동 vSphere 업그레이드
• 사업에 영향 없음
• vSphere가 아닌 워크로드 마이그레이션
• 기존 IP/네트워크를 새 SDDC에 매핑
• 몇 달/몇 주 만에 변환 가속화
• 고객이 직접 하는 셀프 서비스

기존 환경(vSphere)에서 AWS 환경의 VMware Cloud(VMC)로 마이그레이션하고 DR 사이트로 보호합니다.

AWS의 VMC용 HCX

샘플 고객 시나리오

• 온프레미스 VMC 마이그레이션
• VMC 지역 간 재조정
• VMC에서 기존 DR 측으로 보호

HCX의 장점

• 라이브 대규모 마이그레이션
• DR 사이트 보호를 위한 DRaaS + HCX
• 지역 간 이주
• 보안 마이그레이션 및 DR 트래픽
• 네트워크 및 IP 보존
• 대규모 L2 확장성

위의 예에서는 HCX가 워크로드(레거시 또는 신규 버전)를 물리적 데이터 센터나 하이퍼스칼라로 마이그레이션하고 해당 환경을 재해 복구 사이트로 복제하는 방법을 보여줍니다.

VMware HCX 마이그레이션 요약

오늘은 HCX 시리즈로 돌아가서 앞으로 몇 주 동안 HCX 시리즈를 완성해 보려고 합니다. 이번 세 번째 HCX - HCX 시리즈 관련 서비스 메시 생성 및 사이트 연결 방법 블로그 게시물에서는 HCX 서비스 메시를 생성하고 사이트를 연결하는 방법을 설명하겠습니다.

이전 HCX 블로그 게시물 "HCX - 네트워크 및 컴퓨팅 프로필 생성 방법" 에서 HCX 네트워크 프로필과 컴퓨팅 프로필을 생성했습니다. 즉, 두 사이트와 인프라(컴퓨팅 프로필)가 연결되어 HCX에서 볼 수 있게 되었습니다. 이제 서비스 메시를 생성하고 사이트를 연결하여 두 사이트 간에 VM을 마이그레이션해야 합니다.

HCX 서비스 메시란 무엇인가요?

HCX 서비스 메시는 서비스 메시 프로필, 소스 사이트 컴퓨팅 프로필, 대상 사이트 컴퓨팅 프로필의 세 가지 구성 요소로 구성됩니다. 서비스 메시 프로필은 소스 및 대상 위치와 관련 설정을 정의합니다. 또한 액세스 제어 목록(ACL), 방화벽 규칙, 암호화 설정과 같은 보안 요구 사항도 포함합니다. 컴퓨팅 프로필은 환경 내에서 할당하고 관리할 수 있는 리소스(CPU, 메모리, 스토리지)를 정의합니다.

서비스 메시가 생성되면 두 사이트 간의 연결을 정의하여 애플리케이션과 데이터의 안전하고 일관된 전송을 가능하게 합니다. 또한 방화벽 설정, ACL 구성, 암호화 적용 등 사이트 전반의 네트워크 및 보안 설정을 직관적으로 관리할 수 있는 기능을 제공합니다. 서비스 메시는 HCX 중앙 대시보드에서 모니터링 및 관리할 수 있으므로 두 사이트 간 서비스의 상태와 성능을 확인할 수 있습니다.

HCX 서비스 메시는 소스 사이트와 대상 사이트 간의 엔드투엔드 서비스를 효과적으로 구성하여 클라우드 또는 온프레미스 인프라 전반에서 애플리케이션, 데이터 및 워크로드를 안전하고 효율적으로 이동할 수 있는 방법을 제공합니다. 이 블로그 게시물에서는 HCX 서비스 메시를 생성하고 두 사이트(온프레미스 vCenter)를 연결하는 방법을 살펴보겠습니다.

HCX 서비스 메시 설치 방법

HCX 커넥터에서 '상호 연결' 옵션으로 이동한 후 '서비스 메시' 탭에서 '서비스 메시 생성'을 클릭하세요 . 그러면 서비스 메시 프로세스가 시작됩니다.

다음 옵션은 소스 사이트(HCX 커넥터)와 대상 사이트(HCX 클라우드)를 선택하는 것입니다. 사이트를 선택하고 " 계속"을 클릭하세요 .

다음으로, HCX 시리즈에서 이전 블로그 게시물에서 생성한 컴퓨팅 프로필을 선택하고 계속을 클릭합니다 .

이전 블로그 게시물에서도 살펴보았듯이, 네트워크 프로필을 생성할 때는 해당 서비스 메시에서 활성화할 서비스를 선택해야 합니다. 각 서비스는 소스 및 대상 vCenter에 저장된 HCX 어플라이언스를 생성합니다.

이 경우에는 모든 기능을 활성화하겠습니다. 단, 라이선스 제한으로 인해 사용할 수 없는 기능은 제외합니다(이전 블로그 게시물에서 설명했습니다).

활성화하려는 서비스를 선택하고 계속을 클릭합니다.

참고: 언제든지 서비스 메시로 돌아가서 옵션에서 서비스 메시에 더 많은 서비스를 추가할 수 있습니다.

이 옵션에서는 Service Mesh가 네트워크 확장 어플라이언스에 사용하는 이전 HCX 블로그 게시물에서 생성한 vCenter 네트워크를 선택합니다.

참고: 이미지에 나와 있듯이 이 옵션은 NSX-T가 대상에서 HCX와 함께 작동하는 경우 사용되며, NSX-T 오버레이 전송 영역을 사용하려면 필수(지원)입니다. 저는 NSX-T에 구성되어 대상 vCenter에서 사용 가능한 전송 영역 오버레이를 사용했습니다.

다음으로, 이전 HCX 블로그 게시물에서 생성한 네트워크 프로필을 사용합니다. 소스 및 대상 네트워크(vCenter에 있는 네트워크)에서 선택해야 하는 네트워크를 확인하세요.

이 섹션에서는 HCX 네트워크, 업링크, 관리, 복제 및 vMotion을 설정해야 합니다. 이 네트워크들은 Service Mesh가 Service Mesh 어플라이언스 간 연결에 사용할 네트워크와 VM 마이그레이션에 사용할 네트워크입니다.

마지막은 WAN입니다. 필수는 아니지만(이전 서비스인 Mesh에서 선택했습니다), 저대역폭 네트워크를 사용하거나 클라우드 환경으로 마이그레이션하는 경우 필수적입니다.

HCX 서비스 메시 네트워크 토폴로지에서 볼 수 있듯이 모든 네트워크는 소스에서 목적지까지 생성되고 연결됩니다.

서비스 메시의 이름을 지정하여 마무리합니다. 요약을 클릭하면 모든 네트워크를 확인할 수 있습니다. "마침"을 클릭하면 서비스 메시가 생성되고 모든 서비스 메시 어플라이언스가 생성됩니다.

HCX Service Mesh를 배포할 때 오류가 발생할 수 있으며 Service Mesh Appliance가 배포되지 않습니다.

어떤 문제는 쉽게 해결하고 계속 진행할 수 있지만, 어떤 문제는 문제를 파악하기 위해 더 많은 문제 해결이 필요합니다(가장 흔한 문제는 네트워크 문제입니다).

• 첫 번째 오류
  네트워크 업링크 포트 그룹에 충분한 사용 가능한 IP가 없습니다.

• 두 번째 오류
  : 서비스 메시를 생성할 수 없습니다. NSX-T 오버레이 전송 영역만 지원됩니다.

• 세 번째 오류
  HCX – IX 어플라이언스 터널 다운 – 서비스 메시 서비스 파이프라인 상태가 다운되었습니다.

모든 오류가 수정되면 HCX 서비스 메시 배포를 계속할 수 있습니다.

다음 이미지에서는 대상 및 소스에 배포될 모든 HCX 서비스 메시 어플라이언스를 볼 수 있습니다. 즉, 두 사이트 간에 HCX 네트워크 연결이 존재합니다.

소스에서는 HCX가 새로운 "더미 ESXi 호스트"를 생성합니다. 이를 Mobility Agent라고 합니다. Mobility Agent는 HCX Interconnect에 의해 배포되는 가상 호스트입니다.

HCX 모빌리티 에이전트는 vMotion, Cold, RAV(Replication Assisted vMotion) 등 대상 사이트로의 마이그레이션을 수행하는 데 사용됩니다. 소스 사이트의 가상 머신에서 실행되며, 대상 환경으로 빠르고 안전하게 마이그레이션할 수 있도록 지원합니다. 이 소프트웨어는 HCX 솔루션에 포함되어 있으며 성공적인 마이그레이션을 위해 필수적입니다.

HCX 모빌리티 에이전트는 네트워크를 통해 VM과 관련 데이터를 안전하게 전송하여 서로 다른 환경 간에 워크로드를 원활하게 마이그레이션할 수 있도록 합니다.

모든 서비스 메시 어플라이언스가 배포되면 모든 어플라이언스가 정상 작동하고 정상적으로 작동하는지 다시 한번 확인할 수 있습니다. 또한 각 어플라이언스에 대한 정보(서비스, IP 주소 등)도 확인할 수 있습니다.

마지막 작업으로 HCX Service Mesh 배포를 마쳤으며, 이제 두 사이트가 연결되어 마이그레이션 작업을 시작할 준비가 되었습니다.

다음 HCX 시리즈 블로그 게시물에서는 두 사이트 간 VM 마이그레이션을 시작하겠습니다.

HCX 시리즈:

• HCX Manager와 Connector를 페어링하여 설치하는 방법
• HCX – 네트워크 및 컴퓨팅 프로필을 만드는 방법
• 서비스 메시를 생성하고 사이트를 연결하는 방법
• 네트워크 확장을 생성하고 VM을 마이그레이션하는 방법(곧 제공)
• … 그리고 더 많은 것

오류:

• HCX Manager 및 HCX Connector DNS가 배포 후 작동하지 않습니다.
• HCX 로그인 오류: 기본 SSO 관리자를 사용하여 액세스가 거부되었습니다.
• HCX – 네트워크 업링크 포트 그룹에 충분한 사용 가능한 IP가 없습니다.
• HCX - 서비스 메시를 생성할 수 없음 - NSX-T 오버레이 전송 영역만 지원됨
• HCX – IX 어플라이언스 터널 다운 – 서비스 메시 서비스 파이프라인 상태가 다운되었습니다.

HCX 시리즈에 대한 두 번째 HCX - 네트워크 및 컴퓨팅 프로필 생성 방법 블로그 게시물에서는 네트워크 프로필에 대해 알아보겠습니다. 네트워크 프로필을 생성하는 방법, 그리고 모범 사례와 요구 사항은 무엇인지 살펴보겠습니다.

이전 HCX 블로그 게시물 " HCX Manager와 Connector 설치 및 페어링 방법" 에서 HCX Cloud Manager와 HCX Connector Appliance를 설치하고 페어링했습니다. 이제 두 사이트 모두 서로를 인식할 수 있습니다. 하지만 관리, vMotion, 복제, 업링크(사이트 간 연결), 네트워크 확장 등의 통신을 설정할 네트워크를 구축해야 합니다.

먼저, HCX에서 네트워크 프로필을 구현하는 데 필요한 요구 사항이 무엇인지 알아보겠습니다.

• vCenter 또는 NSX-t의 가상 스위치
  • 하나의 기본 vSphere 포트 그룹(VSS 또는 VDS) 또는 NSX 기반 네트워크.

• IP 주소 정보:

• • 게이트웨이 IP, 네트워크 접두사 및 MTU, DNS
  • HCX는 Service Mesh 배포 중에 IP 주소 풀을 예약하여 사용할 수 있습니다 .

네트워크 프로필 구성은 서비스 메시 배포(IX, NE 및 OSAM 어플라이언스에 할당된 IP 주소) 중에만 사용됩니다 . HCX 컴퓨팅 프로필은 항상 하나 이상의 네트워크 프로필을 사용하여 인프라에 연결합니다.

네트워크 프로필 유형:

관리 및 업링크는 관리 연결에 사용되고, vMotion, 복제 및 게스트 네트워크 네트워크 프로필은 마이그레이션 작업에 사용됩니다.

• HCX 관리
  Service Mesh 구성 요소가 HCX Manager, vCenter Server, NTP 및 DNS에 연결하는 데 사용됩니다.

• HCX 업링크
  는 Service Mesh 구성 요소가 피어 어플라이언스에 도달하는 데 사용됩니다.

중요:
목적지 HCX 시스템에 인터넷을 통해 접속해야 하는 경우, 업링크 네트워크 프로필을 사용하여 공용 IP 주소를 할당하십시오. 목적지 NAT 구성은 지원되지 않습니다.
소스 HCX 시스템은 공용 IP 주소가 필요하지 않으며 기존 SNAT를 사용하여 구성할 수 있습니다.

• HCX vMotion
  Service Mesh 구성 요소가 ESXi 클러스터에 연결하여 vMotion 기반 서비스를 제공하는 데 사용됩니다.

• HCX 복제는
  Service Mesh 구성 요소가 복제 기반 서비스를 위해 ESXi 클러스터에 연결하는 데 사용됩니다.

참고:
이 네트워크 프로필 유형은 ESXi vSphere Replication VMkernel 트래픽과 호환되지만 vSphere Replication NFC VMkernel 트래픽에는 사용할 수 없습니다. vSphere Replication NFC VMkernel 트래픽은 항상 관리 네트워크를 사용합니다.

• 
  OSAM 배포에서 Service Mesh Sentinel Gateway가 Sentinel 에이전트에 연결하는 데 사용되는 HCX 게스트 네트워크 입니다.

Mesh Applications Services가 배포되고 Compute Profile과 함께 사용되는 경우 네트워크 프로필이 사용됩니다.

• HCX-IX(마이그레이션, DR)
• HCX-NE(네트워크 확장)
• HCX-WO(WAN 최적화)
• HCX-Sentinel 게이트웨이(OSAM)
• HCX-Sentinel 데이터 수신기

HCX 서비스 가전제품 예시:

Mesh를 구축할 때 HCX 어플라이언스에 대해 더 자세히 설명하겠습니다.

참고: 제 HCX 인프라 랩에서는 IX, NE, WO 서비스만 사용합니다. HCX-Sentinel Gateway와 HCX-Sentinel Data Receive에는 Enterprise 라이선스가 필요하고, 저는 NSX-T에서 제공하는 Advanced 라이선스를 사용하고 있으므로 이 세 가지 서비스만 활성화했습니다.

HCX 네트워크 프로필을 만들기 전에 네트워크 프로필의 배포 유형이 5가지 있습니다.

• HCX 네트워크 구성 1 – 전용 vMotion을 통한 공유 관리, 복제 및 업링크
• HCX 네트워크 구성 2 – 전용 복제 네트워크
• HCX 네트워크 구성 3 – 전용 업링크 네트워크
• HCX 네트워크 구성 4 – 게스트 네트워크를 사용한 OS 지원 마이그레이션
• HCX 네트워크 구성 5 - 관리 네트워크를 사용한 OS 지원 마이그레이션

이 HCX 랩에서는 다양한 배포 유형을 사용합니다. 관리 및 업링크에는 공유 네트워킹을 사용하고, vMotion 및 복제에는 2개의 vNIC가 있는 격리된 네트워크를 사용합니다.

내 구성:

vCenter 소스:

vCenter 관리 포트 그룹:

• HCX 매니지먼트 포르투그룹
• HCX 업링크 포르투그룹

2개의 전용 vNIC가 있는 vCenter 새 vDS

• HCX v모션
• HCX 복제

vCenter Targer VCF:

vCenter 관리 포트 그룹:

• HCX 매니지먼트 포르투그룹
• CX 업링크 포르투그룹

2개의 전용 vNIC가 있는 vCenter 새 vDS

• HCX v모션
• HCX 복제

이 구성에서는 관리 및 업링크를 ESXi 관리의 vNIC와 공유합니다. vMotion 및 복제에서는 트래픽을 위해 두 개의 전용 물리적 인터페이스를 공유합니다.

HCX 네트워크 프로필 토폴로지의 예입니다.

다양한 유형의 네트워크 프로필과 디자인에 대한 자세한 내용은 여기에서 확인할 수 있습니다 .

HCX 네트워크 프로필을 만드는 방법

사이트 페어링이 완료되면(이전 HCX 블로그 게시물 에서 설명 ) 이제 네트워크 프로필을 만들 수 있습니다.

참고: HCX 커넥터 소스 의 예를 보여드리겠습니다. 이 예를 사용하여 HCX Cloud Manager 대상에서 네트워크 프로필을 생성하세요.

HCX 커넥터에 로그인하고 상호 연결 옵션으로 이동한 후 네트워크 프로필 탭을 선택 하고 네트워크 프로필 만들기를 클릭합니다 .

네트워크 프로필 생성을 시작하세요. 먼저 관리 네트워크 프로필을 생성하겠습니다 .

먼저 , 이 네트워크 프로필에 사용할 vSwitch, vDS 또는 NSX 네트워크(HCX 커넥터의 경우 필수 아님)를 선택하세요. 이 경우에는 vDS입니다.

둘째 , HCX 관리를 위해 만든 포트 그룹을 선택합니다.

셋째 , 관리용 IP 풀 주소를 추가합니다. 어플라이언스당 IP 주소가 하나씩 필요합니다. IP 주소를 하나만 배포하므로 IP 주소가 하나 더 필요합니다. 하지만 여기에 전체 IP 풀 범위를 추가할 수 있습니다. HCX는 필요한 IP 주소를 사용하며, 저는 여기에 두 개를 추가하겠습니다.

나머지 정보(마스크, 게이트웨이, DNS, DNS 접미사)를 입력하세요. 관리에는 1500 MTU, vMotion 및 복제에는 9000 MTU를 사용하겠습니다. 네트워크에 맞는 MTU 크기를 사용하세요.

MTU 크기, 대역폭 및 대기 시간 요구 사항은 다음과 같습니다.

네트워크 언더레이 최소 요구 사항에 대한 모든 정보는 여기에서 확인하세요 .

넷째 , 더 나은 네트워크 카탈로그를 위해 관리 트래픽 유형을 선택합니다(필수는 아니며, 메시 프로필을 생성할 때 각 네트워크 유형을 식별하기 위한 것일 뿐입니다). 그리고 생성을 클릭하여 마무리합니다 .

이제 관리 네트워크 프로필이 생성되었습니다. 관리 네트워크 프로필을 생성한 후 복제 네트워크 프로필을 생성해 보겠습니다. 위에서 설명한 옵션과 동일하지만, 복제에는 MTU 9000을 사용합니다.

마지막으로 Uplink와 vMotion을 생성해 보겠습니다.

관리, 업링크, vMotion, 복제 네트워크 프로필을 생성했습니다.

마지막 작업은 HCX Connect 소스에서 HCX 네트워크 프로필 생성을 완료하는 것입니다. 이후 HCX Manager Target 측에서 프로필을 생성하거나 HCX Connect의 다음 단계인 "컴퓨트 프로필 생성"으로 이동할 수 있습니다.

HCX 컴퓨팅 프로필을 만드는 방법

HCX의 컴퓨팅 프로필이란 무엇인가요?

컴퓨팅 프로필은 서비스 메시가 추가될 때 HCX가 소스 또는 대상 사이트에서 Interconnect 전용 가상 어플라이언스를 배포하는 데 사용하는 컴퓨팅, 스토리지 및 네트워크 설정을 포함하는 HCX Connect 인프라입니다.

Mesh는 소스의 컴퓨팅 프로파일을 타겟의 컴퓨팅 프로파일에 연결합니다. 이는 마이그레이션을 위해 두 인프라를 연결할 뿐만 아니라, Mesh가 Interconnect 전용 가상 어플라이언스 서비스를 배포하여 HCX 인프라 연결을 구축할 수 있도록 하기 위함입니다.

HCX 커넥터에 로그인하고 상호 연결 옵션으로 이동한 후 컴퓨팅 프로필 탭을 선택 하고 컴퓨팅 프로필 만들기를 클릭합니다 .

먼저, 컴퓨트 프로필에 이름을 지정합니다(저는 항상 위치를 추적하기 위해 사이트 이름으로 컴퓨트를 식별합니다)

다음으로, HCX 인터커넥트 어플라이언스에 필요한 서비스를 선택하세요. 간단한 구성에는 하이브리드 인터커넥트 , 크로스 클라우드 vMotion 마이그레이션, 대량 마이그레이션, 이렇게 세 가지 서비스만 필요합니다. 더욱 고급 HCX 구현을 위해 다음과 같은 추가 서비스가 제공됩니다.

• WAN 최적화 – 데이터 중복 제거 및 회선 조정과 같은 WAN 최적화 기술. 저대역폭 인프라 또는 인터넷 멀티 클라우드 마이그레이션에 적합합니다.
• 네트워크 확장 – 통합 근접 라우팅을 갖춘 고처리량 네트워크 확장 서비스는 IP/MAC 주소가 유지되는 사이트 전체에서 원활한 모빌리티와 간단한 재해 복구 계획을 가능하게 합니다.
  
• 재해 복구 – 재해 복구 서비스는 앱 수준 재해부터 사이트 전체 재해까지 워크로드를 보호하는 비즈니스 연속성 솔루션입니다.
  

HCX Enterprise 라이선스를 사용하면:

• 복제 지원 vMotion 마이그레이션 – VMware HCX 복제 지원 vMotion(RAV)은 VMware HCX 대량 마이그레이션(병렬 작업, 복원력 및 스케줄링)과 VMware HCX vMotion(가동 중단 없는 가상 머신 상태 마이그레이션)의 장점을 결합합니다.
• SRM 통합 – VMware Site Recovery Manager에서 DR을 구성하는 기능을 제공합니다. HCX는 VM 복제를 위한 SRM 확장 기능으로 사용할 수 있습니다.
  
• OS 지원 마이그레이션 – OS 지원 마이그레이션 서비스는 OpenStack 워크로드를 vSphere 환경으로 가져오는 데 사용할 수 있으며 레거시 시스템이나 KVM 또는 Hyper-V와 같은 다른 하이퍼바이저에서 VM을 마이그레이션하는 데에도 사용할 수 있습니다.
  

다음에 보여드리는 것처럼 이 HCX 랩에서는 모든 HCX 고급 서비스를 활성화하겠습니다.

다음으로, 컴퓨팅 프로필에 사용할 데이터 센터 또는 클러스터를 선택합니다.

다음 섹션에서는 클러스터, 데이터 저장소, VM 폴더(선택 사항)를 선택합니다.

참고: 이 선택 사항은 HCX 어플라이언스가 배포될 위치라는 점을 잊지 마세요. 또한 이 어플라이언스를 실행하기 위해 vCPU와 vMemory를 예약할 수 있습니다. 프로덕션 환경인 경우, 모든 서비스가 리소스 부족 없이 정상적으로 실행될 수 있도록 100%(사용 가능한 경우)를 예약하는 것이 좋습니다.

다음으로, 이전에 생성한 네트워크 프로필을 선택하겠습니다. 먼저 관리 네트워크 프로필을 선택하세요.

다음으로, 업링크 네트워크 프로필을 선택합니다.

참고: 네트워크 프로필 유형 확인란을 사용하는 경우 HCX는 이것이 Uplink에 대해 생성한 네트워크 프로필이라는 것을 녹색 아이콘(다음 이미지에서 볼 수 있음)으로 강조 표시합니다.

다음은 vMotion 네트워크 프로필입니다. 역시 HCX에서 권장하는 프로필을 사용하세요.

보시다시피, 네트워크 프로필을 선택할 때마다 HCX가 디자인에 맞게 네트워크를 만들기 시작합니다.

마지막으로 선택할 것은 복제 네트워크입니다.

네트워크 확장 서비스를 선택했으므로 이 네트워크에는 네트워크 프로필이 아닌 네트워크를 사용해야 합니다. 이 경우, 이 서비스용으로 생성된 NSX-T 오버레이 포트 그룹을 사용하겠습니다.

중요 참고 사항: 소스 또는 대상(필수)에서 NSX-T를 사용하는 경우 vSwith 또는 vDS 포트 그룹이 아닌 NSX-T 오버레이 네트워크를 사용해야 합니다.

작업이 완료되면 모든 설정을 다시 한 번 확인하고 '마침'을 클릭하세요.

다음 이미지에서 볼 수 있듯이, HCX 네트워크 프로필을 사용하여 컴퓨팅 리소스와 함께 어플라이언스 서비스에 대한 컴퓨팅 프로필이 생성됩니다.

마무리로, 네트워크 프로필을 생성한 후 타겟에 컴퓨팅 프로필도 생성했습니다. 메시가 생성되면 HCX 인프라가 HCX 인터커넥트 어플라이언스와 연결할 준비가 되었습니다.

HCX Cloud Manager 대상에서 HCX 네트워크 프로필과 HCX 컴퓨팅 프로필을 구성하여 이 섹션을 마무리합니다. 다음으로, 모든 HCX Interconnect 서비스 어플라이언스를 배포할 HCX 메시를 생성한 후 두 위치 간 VM 마이그레이션을 시작합니다.

블로그 게시물이 좀 길었다면 죄송하지만, HCX를 사용한 적이 없는 사람도 배포 방법과 작동 방식을 이해할 수 있도록 각 부분을 자세히 설명하고 싶습니다.

다음 HCX 시리즈 블로그 게시물에서는 HCX 메시를 만드는 방법을 설명하겠습니다.

HCX 시리즈:

• HCX Manager와 Connector를 페어링하여 설치하는 방법
• HCX – 네트워크 및 컴퓨팅 프로필을 만드는 방법(이것)
• 서비스 메시를 생성하고 사이트를 연결하는 방법(곧 제공)
• 네트워크 확장을 생성하고 VM을 마이그레이션하는 방법(곧 제공)
• … 그리고 더 많은 것

오류:

• HCX Manager 및 HCX Connector DNS가 배포 후 작동하지 않습니다.
• HCX 로그인 오류: 기본 SSO 관리자를 사용하여 액세스가 거부되었습니다.

한동안 HCX( Hybrid Cloud Extension 의 약자)를 사용하지 않았습니다 . 적어도 인프라 설치는 하지 않았습니다. 최근에는 일부 VM과 앱 마이그레이션에만 사용했습니다. 그래서 HCX 인프라 랩을 구축할 때가 되었고, 이 HCX Manager와 Connector 설치 및 페어링 방법에서 그 방법을 설명하겠습니다.

HCX 관련 글을 몇 개 작성하고 다양한 HCX 구현 및 마이그레이션에 대해 설명하겠습니다. 이 첫 번째 블로그 게시물에서는 HCX Manager OVA와 HCX Connector OVA만 설치하고 사이트 페어링을 진행하겠습니다.

이 초기 HCX 배포를 위한 환경은 다음과 같습니다.

대상: VCF v4.2(vCenter 7.0 및 NSX-T v3.2 포함)
소스: vCenter 7.0(NSX-T 없음)

대상 HCX 관리자: v4.4.0-build 20427536
소스 HCX 커넥터: v4.4.2-build-20502808

라이선스: HCX Advanced 라이선스를 제공하는 NSX-T 라이선스를 사용하겠습니다. 이 실습에서는 이 라이선스로 충분합니다.

HCX Manager OVA 설치는 간단한 OVA 어플라이언스 배포이므로 자세한 내용은 다루지 않겠습니다.

먼저, VMware 계정에서 HCX Manager를 다운로드해야 합니다(AWS, Azure 등에 배포하는 경우 클라우드 서비스에서 OVA를 배포할 수 있습니다).

HCX Manager Appliance를 대상(이 경우 VCF vCenter)에 배포했지만, 이는 필수 사항은 아닙니다. vCenter와 Cloud Director, NSX OVA 등과 마찬가지로, 어떤 vCenter에든 배포한 후 적절한 vCenter/SSO에 연결할 수 있습니다.

위에서 볼 수 있듯이, 이는 비밀번호, IP 주소, 게이트웨이, DNS 등을 설정하는 표준 OVA 배포일 뿐입니다.

참고: 이전 블로그 게시물 에서 설명했듯이 DNS 항목을 두 개 이상 추가하면 어플라이언스가 DNS에 저장되지 않는 버그가 있습니다. 따라서 DNS는 하나만 추가하세요. 어플라이언스 배포 후에 추가 DNS 항목을 추가할 수 있습니다.

HCX Manager가 배포된 후 OVA 배포 시 설정된 관리자 사용자 이름과 비밀번호를 사용하여 https://ip-fqdn:9443을 통해 관리자 VAMI에 연결합니다 .

다음으로, HCX Manager Appliance를 구성해 보겠습니다.

이 섹션에서는 라이선스를 활성화해야 합니다. 위에서 말씀드렸듯이 NSX-T Enterprise 라이선스를 사용할 수 있습니다. 이 경우 복제 지원 vMotion 마이그레이션 , SRM 통합 또는 OS 지원 마이그레이션과 같은 HCX 서비스를 사용하지 않는 한 추가 HCX 라이선스가 필요하지 않습니다. 이러한 서비스에는 HCX Enterprise 라이선스가 필요합니다.

HCX 라이선스에 대한 자세한 내용은 여기에서 확인할 수 있습니다 .

참고: 기본 라이센스 서버 https://connect.hcx.vmware.com을 변경하지 마세요.

라이선스가 활성화되면 HCX가 HCX를 업데이트하고 HCX 서비스를 활성화합니다.

인터넷 연결 상태와 최신 업데이트에 따라 몇 분이 걸릴 수 있습니다.

HCX 관리자가 최신 상태로 업데이트되면 해당 HCX 관리자의 위치를 ​​설정해야 합니다. 온프레미스 배포의 경우 이는 정보일 뿐입니다. 클라우드 배포는 인근 데이터 센터를 사용하는 클라우드 서비스를 위한 것이며 자동으로 수행됩니다.

다음으로, 이 HCX 관리자 시스템의 이름을 지정하세요. 다시 한번 말씀드리지만, 이는 참조용입니다.

다음으로, HCX Manager인 vSphere(VCF이지만 vSphere에 연결될 예정)를 연결합니다. VMware Cloud Director 인프라에도 연결할 수 있습니다.

다음으로, HCX Manager를 대상 vCenter와 NSX-T에 연결합니다. 두 HCX 배포 모두에서 동일한 NSX-T 라이선스를 사용해야 합니다. 대상에서는 NSX-T를 사용하는 것이 필수이지만, 소스에서는 필수가 아닙니다.

다음으로, HCX Manager를 SSO/PSC에 연결합니다. 외부 PSC는 더 이상 지원되지 않으므로 vCenter를 연결해야 합니다.

클라우드 마이그레이션이나 내부적으로 연결되지 않은 사이트에 HCX Manager를 배포하는 경우, 인터넷을 통해 해당 사이트에 연결할 수 있도록 공개 URL을 제공해야 합니다. 내부 HCX 배포이므로 HCX Manager FQDN을 사용할 수 있습니다.

HCX 관리자 초기 구성을 완료했습니다. 설정을 다시 확인하고 '다시 시작'을 클릭하세요.

HCX Manager를 재부팅하면 이제 HCX Manager에 로그인할 수 있습니다. SSO에 연결했으므로 SSO 관리자(또는 관리자 권한이 있는 사용자) 자격 증명을 사용해야 합니다. HCX에서 사용하기 위한 사용자 권한 요구 사항은 여기에서 확인하세요.

참고: 특정 SSO 도메인 이름이 있고 기본값( vsphere.local )을 사용하지 않는 경우, HCX 역할 매핑에서 변경하지 않으면 로그인이 실패합니다. SSO 그룹을 적절한 도메인으로 변경하지 않으면 로그인이 실패하는 문제에 대한 제 블로그 게시물을 참조하세요.

이제 HCX 관리자 대시보드에 연결되었습니다.

사이트 페어링을 시작하기 전에 소스 HCX를 배포해야 합니다. 여기서부터 소스에 HCX 커넥터 배포를 시작합니다.

먼저 시스템 업데이트 로 이동한 다음 업데이트 확인을 클릭합니다 . 그러면 " 다운로드 링크 요청" 링크가 표시됩니다 . 링크를 클릭하면 HCX 커넥터를 다운로드하거나, 링크를 복사하여 브라우저에 붙여넣어 소스 사이트에서 다운로드하는 두 가지 옵션이 있습니다. 저는 링크를 복사하여 소스 사이트 브라우저에 붙여넣고 HCX 커넥터 OVA를 다운로드했습니다.

HCX 커넥터 OVA를 만든 후 소스 vCenter(또는 기타)에 배포합니다. 제 경우에는 소스 vCenter입니다.

배포 및 구성 설정은 위에서 설명한 것과 동일하므로 여기에 다시 표시할 필요가 없습니다.

유일한 차이점은 HCX 커넥터 VAMI에 NSX Manager와 Public Access URL 옵션이 없다는 것입니다. HCX Manager 구성에서는 VM이 ​​마이그레이션될 인프라가 Compute이므로 커넥터에 없는 Compute 옵션이 있습니다.

HCX 커넥터를 소스 vCenter에 배포하고 구성한 후 소스 HCX를 대상 HCX에 연결하여 사이트 페어링을 시작할 수 있습니다.

페어링, 메시 생성 등 모든 작업은 항상 소스 HCX 커넥터에서 HCX 관리자로, 즉 소스에서 목적지로 진행되어야 합니다.

소스 사이트에서 소스 vCenter 관리자 자격 증명으로 HCX 커넥터를 열고(SSO 기본 도메인을 사용하지 않는 경우 역할 매핑을 변경하는 것을 잊지 마세요) 사이트 페어링 옵션으로 이동합니다.

사이트 페어링이 완료되면 이제 목적지와 소스를 확인할 수 있습니다. 소스 HCX 커넥터와 목적지, HCX 관리자를 다시 한번 확인하세요. 사이트가 페어링되었고 모든 연결이 녹색으로 표시되면 확인할 수 있습니다.

사이트 페어링이 모두 녹색(소스 및 대상)이면 두 사이트가 연결되었으며 VM 마이그레이션을 위한 HCX 인프라를 구성하기 위해 상호 연결 구성을 시작할 수 있습니다.

Interconnect 구성 및 설정에 대한 자세한 내용은 다른 블로그 게시물에서 설명하겠습니다.

HCX 시리즈:

• HCX Manager와 Connector를 페어링하여 설치하는 방법(이것)
• HCX – 네트워크 및 컴퓨팅 프로필을 만드는 방법
• 서비스 메시를 생성하고 사이트를 연결하는 방법(곧 제공)
• 네트워크 확장을 생성하고 VM을 마이그레이션하는 방법(곧 제공)
• … 그리고 더 많은 것

오류:
HCX 관리자 및 HCX 커넥터 DNS가 HCX 배포 후 작동하지 않습니다.
기본 SSO 관리자를 사용하여 HCX 로그인 오류 액세스가 거부되었습니다.

VMware HCX를 직접 사용해 본 경험을 바탕으로, 최근 금융 서비스 회사와의 프로젝트 계획의 일환으로 Azure VMware Solution(AVS)에 대해 몇 주 동안 조사했습니다. 해당 고객은 여러 클러스터에 걸쳐 500개의 VM이 있는 온프레미스 VMware 환경을 AVS로 마이그레이션하고자 합니다. 핵심 애플리케이션 리팩토링 없이 데이터 센터를 대피시키려는 목표 때문입니다. 이 블로그 게시물 "VMware HCX를 사용하여 Azure VMware Solution으로 워크로드 마이그레이션: 실무 가이드" 에서는 제가 조사한 내용을 바탕으로 실용적이고 구체적인 계획을 제시하고 이러한 유형의 마이그레이션에 대한 접근 방식을 제시합니다. 자세한 설명은 생략하고, 전략, 아키텍처, 도구, 연구를 통해 얻은 교훈, 그리고 피해야 할 함정에 대해 중점적으로 설명하겠습니다. 이 글은 VMware HCX를 사용하여 온프레미스 환경에서 Azure VMware Solution으로 워크로드를 마이그레이션하려는 모든 분들을 위해 작성되었습니다.

마이그레이션 계획의 토대를 마련하기 위해 AVS와 HCX의 기본 사항을 먼저 살펴보겠습니다.

Azure VMware 솔루션 및 VMware HCX 이해

마이그레이션 계획을 논의하기 전에 AVS와 HCX가 제공하는 서비스를 명확하게 이해하는 것이 중요합니다. 많은 전문가들이 관련된 세부적인 사항들을 과소평가하여 마이그레이션 계획 과정에서 오해와 실수를 저지르게 됩니다.

AVS는 Azure에 호스팅되는 전용 VMware 소프트웨어 정의 데이터 센터(SDDC) 환경을 제공하는 Microsoft 관리 서비스입니다. 컴퓨팅을 위한 vSphere, 스토리지를 위한 vSAN, 네트워크 가상화를 위한 NSX-T 등 익숙한 구성 요소를 포함합니다. 이 환경은 베어 메탈 서버에 호스팅되며 Azure SQL 또는 Azure AD와 같은 네이티브 Azure 서비스와 통합할 수 있습니다. AVS는 온프레미스 VMware 환경을 미러링하므로 고객이 워크로드를 재설계하지 않고도 데이터 센터를 확장하거나 이전할 수 있는 잠재적인 옵션입니다.

VMware HCX는 마이그레이션의 엔진입니다. 대량 VM 이동, 라이브 마이그레이션, 재해 복구 및 네트워크 확장을 위한 도구를 제공하며, 대역폭 사용량을 줄이기 위한 WAN 최적화(압축 및 중복 제거)와 같은 기능도 제공합니다. HCX는 IP 주소를 변경하거나 복잡한 종속성을 재구성하지 않고도 워크로드를 이동할 수 있으므로 AVS(애플리케이션 보안 시스템) 프로젝트에 특히 유용합니다. 제가 사용할 주요 HCX 마이그레이션 방법은 다음과 같습니다.

• vMotion : 가동 중인 VM을 다운타임 없이 라이브 마이그레이션합니다. 대역폭에 민감하므로 신중한 계획이 필요합니다.
• 대량 마이그레이션 : 최소 컷오버 다운타임(~분)으로 예약된 복제를 수행합니다. 대용량 작업에 적합합니다.
• 복제 지원 vMotion(RAV) : 사전 시딩과 vMotion을 결합하여 데이터베이스와 같은 대규모의 높은 변경률의 VM을 지원합니다.
• 콜드 마이그레이션 : 마이그레이션 전에 전원을 끌 수 있는 VM의 경우 레거시 또는 테스트 워크로드에 자주 사용됩니다.
• OS 지원 마이그레이션(OSAM) : 물리적 서버나 Hyper-V 워크로드를 vSphere로 마이그레이션하는 데 사용됩니다.

올바른 마이그레이션 유형을 선택하는 것이 중요합니다. 중요한 워크로드에는 vMotion을, 일반 VM에는 Bulk를, 그리고 vSphere가 아닌 환경처럼 필요한 경우에만 OSAM을 혼합하여 사용하는 것을 권장합니다. 참고로, 아래 비교표를 참고해 보세요.

이러한 기술을 미리 이해하면 불필요한 위험과 다운타임을 방지하는 데 도움이 됩니다. 이는 복잡한 프로젝트를 시작하기 전에 도구를 미리 아는 것과 같습니다. 성공으로 가는 지름길입니다. 이러한 기반을 마련한 후, 다음 단계는 고객 환경을 면밀히 평가하여 마이그레이션 준비 상태를 확인하는 것입니다.

이주 전 평가

적절한 탐색 단계는 모든 성공적인 AVS 마이그레이션의 기반입니다. 제 연구에 따르면 이 단계를 건너뛰거나 서두르면 심각한 문제가 발생할 수 있으므로, VMware 네이티브 도구와 Azure 네이티브 도구를 함께 사용하여 고객 환경을 분석하는 데 충분한 시간을 할애하여 준비 상태를 유지하는 것이 좋습니다.

저는 다음과 같은 방식으로 평가에 접근하기를 제안합니다.

• VM 인벤토리 및 크기 조정 : RVTools 또는 vRealize Operations를 사용하여 CPU, RAM, 디스크 및 스냅샷 정보를 수집합니다. Azure Migrate는 크기 권장 사항을 생성하고 레거시 OS 버전과 같이 지원되지 않는 구성을 플래그로 지정할 수 있습니다.
• 애플리케이션 종속성 매핑 : Azure Migrate의 종속성 시각화를 활용하여 최소 30일 동안 실행하여 트래픽 흐름을 파악합니다. 이를 통해 문서화되지 않은 MSSQL 인스턴스에 백엔드 호출을 수행하는 레거시 웹 서버와 같은 숨겨진 종속성을 파악할 수 있습니다.
• 호환성 검사 : vSphere 버전(6.5 이상), 가상 하드웨어 호환성, OS 지원 및 네트워크 토폴로지를 확인하세요. 검증을 위해 VMware 상호 운용성 매트릭스 및 HCX 설명서를 활용하세요.
• 워크로드 분류 : 미션 크리티컬, 프로덕션, 개발, 보관 등의 범주로 워크로드를 분류합니다. 이를 통해 단계별 마이그레이션 및 롤백 옵션을 계획하는 데 도움이 됩니다.
• 특수 워크로드 : 원시 장치 매핑(RDM), PCI 패스스루 장치 또는 HCX 복제 제한(일반적으로 8TB)을 초과하는 대용량 디스크 등 추가 계획이 필요한 VM을 파악합니다. 문제 발생을 방지하기 위해 RDM을 VMDK로 변환하는 것을 계획합니다.
• 규정 준수 평가 : 규정 준수를 보장하기 위해 GDPR이나 HIPAA와 같은 요구 사항을 Azure 정책에 매핑합니다.

철저한 마이그레이션 전 평가는 마치 집을 짓기 위한 기초를 다지는 것과 같습니다. 이 부분이 제대로 된다면 나머지 마이그레이션은 훨씬 더 수월해집니다. 중요한 것은 잠재적인 장애물을 조기에 파악하는 것입니다. 평가가 계획되었으니, 이제 HCX 통합을 위한 온프레미스 환경을 준비하는 단계로 넘어가겠습니다.

온프레미스 환경 준비

발견 단계가 완료되면 다음 단계는 HCX 통합을 위해 고객의 온프레미스 인프라를 준비하는 것입니다. 이 단계는 대부분 기술적인 내용이지만, 지연으로 인해 일정이 지연되는 것을 방지하기 위해 네트워크 및 방화벽 팀과 조기에 협력하는 것이 좋습니다.

제가 제안하는 준비 계획은 다음과 같습니다.

• HCX 커넥터 배포 : vSphere 환경에 HCX 커넥터 OVA를 배포합니다. vCenter 및 NSX Manager에 등록하고, 서비스 메시 설정을 진행하기 전에 등록이 완료되었는지 확인합니다.
• 네트워크 구성 및 준비 :
  • 온프레미스 사이트와 AVS 환경 간의 레이어 3 연결을 검증합니다.
  • 모든 HCX 어플라이언스 간에 필수 포트(TCP 443, UDP 4500)를 엽니다.
  • vCenter, HCX 및 NSX 구성 요소에 대한 DNS 확인을 양방향으로 보장합니다.
  • 인증이나 복제에 영향을 미치는 시간 편차 문제를 방지하려면 NTP 설정을 동기화하세요.
• 워크로드 그룹화 : 애플리케이션, 종속성 및 비즈니스 기간을 기준으로 논리적 마이그레이션 그룹을 생성합니다. 이를 통해 웹 서버와 데이터베이스를 그룹화하는 등 마이그레이션 계획 수립 및 테스트가 간소화됩니다.

온프레미스 환경을 철저히 준비하는 것이 전체 마이그레이션의 토대를 마련합니다. 시간 동기화 문제와 같은 사소한 실수가 문제 해결에 몇 시간씩 소요될 수 있으므로, 세부 사항에 대한 주의가 매우 중요합니다. 이제 환경이 준비되었으니, 마이그레이션 아키텍처를 설계할 전략적 계획 단계로 넘어가겠습니다.

VMware에서 AVS로의 마이그레이션을 위한 전략적 계획

전략적 계획은 마이그레이션이 구체화되는 단계입니다. 이 단계에서는 네트워킹, 리소스 크기 조정, HCX 구성, AVS 설정 등을 신중하게 고려해야 합니다. 성공적인 마이그레이션을 위해 이 단계를 핵심 영역으로 나누어 설명하겠습니다.

네트워킹 고려 사항

이는 아키텍처에서 가장 복잡한 부분입니다. HCX와 AVS의 네트워킹은 강력하지만 잘못 구성하면 심각한 문제를 야기할 수 있습니다. 따라서 고객의 잠재적 요구 사항에 맞춰 세부적으로 살펴보겠습니다.

• ExpressRoute : 낮은 지연 시간과 높은 대역폭이 필요한 프로덕션 워크로드(예: 실시간 데이터를 사용하는 금융 앱)에 권장됩니다. 프라이빗 피어링을 사용하고 HCX 성능을 위해 MTU 설정이 1600바이트를 지원하는지 확인하십시오. 대규모 배포 또는 다중 사이트 연결이 필요한 고객에게 적합합니다.
• 사이트 간 VPN은 지연 시간 허용 범위가 높은 소규모 또는 테스트 환경에 비용 효율적인 대안입니다. 고객의 초기 마이그레이션이 파일럿 단계 또는 중요하지 않은 워크로드로 제한되는 경우에 이상적입니다.
• 결정 매트릭스 : 100개 이상의 VM이나 고성능 요구 사항에는 ExpressRoute를 사용하고, 50개 미만의 VM이나 초기 테스트에는 VPN을 사용합니다.
• 글로벌 도달 범위 : ExpressRoute 회선이 여러 Azure 지역에 걸쳐 있는 경우(예: 고객이 미국 동부 및 서부 지역에서 운영하는 경우) 필요합니다. 허브와 AVS 프라이빗 클라우드 간 라우팅을 지원합니다. 고객이 다중 지역 전략을 사용하는 경우 이 기능을 고려하십시오.
• 2계층 네트워크 확장 : HCX NE를 사용하면 VM이 IP 주소를 유지할 수 있습니다. 각 어플라이언스는 최대 8개의 VLAN을 지원하므로, 고객이 더 많은 네트워크를 확장해야 할 경우 추가 어플라이언스를 계획하십시오.
• 모빌리티 최적화 네트워킹(MON) : Azure를 통해 최적화된 송신을 활성화하여 비대칭 라우팅을 해결합니다. 특히 고객이 확장된 네트워크를 사용하는 경우, 반환 트래픽에 대한 방화벽 규칙을 구성하세요.
• 허브-스포크 토폴로지 : 공유 서비스(DNS, ID, 모니터링)를 사용하는 허브에 연결된 스포크 VNet에 AVS를 배치합니다. 고객은 보안 및 관리를 중앙에서 관리하는 것이 좋습니다.
• Azure vNet 통합 : Azure 서비스를 사용한 하이브리드 시나리오에서 허브 VNet과 AVS VNet을 연동하여 고객이 Azure 기본 도구를 활용할 수 있도록 보장합니다.

네트워크 설정 다이어그램은 다음과 같습니다.

AVS 구성

AVS 환경 구성은 고객의 요구를 충족하는 데 매우 중요합니다. 여기에는 온프레미스 환경 및 마이그레이션 목표에 맞춰 SDDC를 설정하는 것이 포함됩니다.

• 노드 크기 조정 : 최소 3개 노드 클러스터에서 AV36개 노드(36코어, 576GB RAM, 15.36TB NVMe)로 시작하세요. 고객의 VM 수(예: VM 500개에는 6~8개 노드가 필요할 수 있음)와 성능 요구 사항에 따라 확장하세요.
• vSAN 구성 : 중복성을 위해 Fault Tolerance(FTT=1, RAID-1)를 활성화합니다. 스토리지 최적화를 위해 중복 제거 및 압축을 계획하되, 복제 트래픽 및 스냅샷으로 인한 잠재적 오버헤드를 모니터링합니다.
• NSX-T 설정 : 고객의 온프레미스 네트워크 토폴로지에 맞게 NSX-T 세그먼트를 구성합니다. L2 확장 통합을 계획하고 보안 정책(예: 분산 방화벽 규칙)을 정의합니다.
• Azure 통합 : Azure vNet 피어링을 설정하고 공유 서비스(예: DNS, Azure AD)를 위한 허브 VNet과 통합합니다. 고객의 기존 Azure 구독과의 호환성을 보장합니다.
• 리소스 할당 : Azure Migrate 크기 권장 사항에 따라 CPU, RAM 및 스토리지를 할당하고 성장에 대비해 20~30% 여유 공간을 추가합니다.

AVS를 사용한 HCX에 대한 네트워크 설계 고려 사항

VMware HCX를 사용하여 온프레미스 환경에서 Azure VMware Solution으로 워크로드를 마이그레이션할 때 네트워크 설계는 아키텍처에서 가장 중요한 부분 중 하나가 됩니다. HCX가 모빌리티 및 네트워크 확장의 복잡성을 상당 부분 처리하지만, 부적절한 라우팅, 세분화 및 어플라이언스 배치 계획은 심각한 중단이나 마이그레이션 실패를 초래할 수 있습니다.

이 섹션의 개념을 뒷받침하기 위해 HCX를 AVS로 마이그레이션할 때 가장 중요한 네트워크 설계 고려 사항을 요약한 아래 이미지를 만들었습니다.

허브 앤 스포크 토폴로지

다이어그램의 왼쪽 상단 사분면은 허브-스포크 네트워크 아키텍처를 보여줍니다 . 이는 Azure에서 권장되는 디자인 패턴입니다. AVS 프라이빗 클라우드는 스포크 가상 네트워크(VNet)로 배포되는 반면, 허브에는 DNS, Active Directory, NVA 방화벽, 모니터링, ExpressRoute 게이트웨이와 같은 중앙 집중식 서비스가 포함됩니다. 각 스포크는 VNet 피어링을 통해 허브에 연결되어 공유 서비스를 통한 트래픽 흐름을 허용하는 동시에 스포크 간 수평 이동을 격리합니다.

이러한 설계는 라우팅을 간소화하고, 중앙 지점에서 보안 정책을 시행하며, 여러 지역이나 환경 전반에서 일관성을 보장합니다.

NSX-T 세그먼트 계획

AVS는 네트워크 가상화에 NSX-T를 사용하고 , HCX는 온프레미스 환경에서 AVS로 레이어 2 네트워크를 확장할 수 있습니다. 하지만 모든 네트워크를 확장할 수 있거나 확장해야 하는 것은 아닙니다.

이미지의 오른쪽 상단 사분면은 일반적인 문제인 서브넷 중복을 보여줍니다 . 기존 세그먼트와 동일한 IP 범위를 사용하는 AVS로 네트워크를 확장하면 라우팅 충돌과 예측할 수 없는 동작이 발생합니다. 이미지는 서브넷을 복제할 때 192.168.12.0/24여러 소스에서 확장되거나 두 번 이상 사용될 경우 문제가 발생할 수 있음을 보여줍니다.

네트워크 확장을 배포하기 전에 항상 서브넷을 신중하게 문서화하고 계획하세요.

서비스 메시 범위

왼쪽 하단 사분면에서는 HCX 서비스 메시 고려 사항을 다룹니다. 이는 HCX 연결의 핵심으로, 온프레미스 환경과 AVS 환경 간의 경로를 정의합니다. 각 서비스 메시에는 양쪽에 구축된 인터커넥트 및 네트워크 확장과 같은 어플라이언스가 포함됩니다.

주요 고려 사항:

• 각 NE 어플라이언스는 최대 8개의 확장 네트워크를 지원합니다.
• 처리량 제한 과 예상 마이그레이션 동시성을 고려해야 합니다.
• 서비스 메시는 클러스터별로 신중하게 범위를 지정해야 합니다.

이 다이어그램은 NE 어플라이언스가 확장 한계에 도달할 수 있음을 보여줍니다. 8개 이상의 네트워크를 확장하는 경우, 추가 어플라이언스를 구축하거나 여러 메시에 걸쳐 마이그레이션을 분할하십시오.

모빌리티 최적화 네트워킹(MON)

이는 레이어 2 네트워크 확장을 사용할 때 가장 간과되지만 중요한 기능 중 하나입니다. 이미지 중앙에 표시된 것처럼, 모빌리티 최적화 네트워킹(MON)을 사용하면 마이그레이션된 VM이 원래 온프레미스 IP 주소를 유지하더라도 AVS의 로컬 라우팅을 사용할 수 있습니다.

MON이 없으면 인터넷이나 Azure 서비스에서 반환되는 트래픽이 온프레미스 게이트웨이를 통해 다시 라우팅되어 비대칭 라우팅 및 트래픽 손실이 발생할 수 있습니다. 다이어그램은 두 가지 가능한 흐름을 보여줍니다.

• VM이 Azure 게이트웨이를 직접 사용하는 파선 HCX MON 경로
• 라우팅 문제를 야기하는 최적화되지 않은 경로인 비대칭 경로로 표시된 곡선 경로

MON을 활성화하려면 다음이 필요합니다.

• AVS 세그먼트에 NSX-T 게이트웨이 지원이 있는지 확인하십시오.
• 로컬 이탈을 허용하기 위한 올바른 방화벽 규칙
• 라우팅 변경 및 테스트 검증에 대한 인식

MON은 특히 Azure 네이티브 서비스나 인터넷 엔드포인트에 액세스하는 애플리케이션의 경우 많은 마이그레이션 이후 문제를 해결합니다.

방화벽 및 라우팅

오른쪽 상단 사분면에 표시된 또 다른 핵심 사항은 방화벽과 라우팅 인식 의 중요성입니다 . HCX는 모든 어플라이언스 간에 여러 포트(예: TCP 443 및 UDP 4500)를 양방향으로 개방해야 합니다. 특히 MON이 활성화된 경우 리턴 라우팅은 예측 가능하고 대칭적이어야 합니다 .

Azure 또는 온프레미스에서 네트워크 가상 어플라이언스(NVA)를 사용하는 경우, 해당 어플라이언스가 NAT를 수행하거나 HCX가 사용하는 트래픽을 차단하지 않는지 확인하세요. 연결 문제가 발생하는 경우, 방화벽이나 라우팅 구성 오류로 인해 발생하는 경우가 많습니다.

ExpressRoute 및 MTU 고려 사항

마지막으로, 오른쪽 하단 사분면은 많은 팀이 검증 과정에서 간과하는 MTU 크기와 ExpressRoute 구성을 강조합니다 . HCX Interconnect 트래픽은 단편화에 민감합니다. AVS 환경에는 최소 1500의 MTU가 필요하며 , 특히 대량 또는 RAV 마이그레이션 방식을 사용할 때 성능과 안정성을 위해 점보 프레임(1600바이트 이상)을 활성화하는 것이 좋습니다.

프로덕션 마이그레이션을 시작하기 전에 항상 MTU 경로를 종단 간 테스트하세요.

클러스터 및 리소스 계획

AVS 프라이빗 클라우드는 단순히 온프레미스 호스트 수만이 아니라 고객의 실제 사용 데이터를 기반으로 해야 합니다. AVS 노드는 일관된 성능을 제공하지만, 통합에는 신중한 계획이 필요합니다.

• 용량 계획 : CPU, RAM 및 스토리지 사용량 보고서에는 Azure Migrate 또는 vRealize Operations를 사용하세요. 용량 증가 및 급증에 대비하여 20~30%의 여유 용량을 추가하세요.
• 클러스터 크기 조정 : 최소 3개 노드 클러스터로 시작하여 500개 VM 부하에 따라 점진적으로 확장합니다.
• 스토리지 고려 사항 : 중복성을 위해 FTT=1, RAID-1로 vSAN을 구성하십시오. 스토리지 사용량을 관리하기 위해 중복 제거/압축을 모니터링하십시오.

HCX 서비스 메시 및 마이그레이션 방법

HCX 서비스 메시는 마이그레이션 트래픽 흐름 방식을 정의하여 마이그레이션 인프라의 초석을 제공합니다. 이 부분의 구성 오류는 프로젝트를 방해할 수 있습니다.

• 서비스 메시 배포 : 온프레미스 HCX 커넥터를 AVS HCX Cloud Manager와 연결합니다. 정확한 라우팅을 위해 컴퓨팅 및 네트워크 프로필을 정의합니다.
• HCX Interconnect : 안전하고 암호화된 마이그레이션 트래픽을 처리합니다. 적절한 대역폭을 확보하세요.
• 네트워크 확장(NE) : L2 확장에 필요함. 용량(어플라이언스당 8개 VLAN)을 계획합니다.
• 모빌리티 최적화 네트워킹(MON) : 마이그레이션 후 비대칭 라우팅을 방지합니다.
• 마이그레이션 방법 :
  • vMotion: 중요한 앱(예: 웹 서버).
  • 대량: 개발/테스트 VM.
  • RAV: 데이터베이스(예: SQL Server).
  • 추위: 레거시 시스템.
  • OSAM: 물리적 Linux 서버.

서비스 메시 레이아웃은 다음과 같습니다.

계획 단계에서 네트워킹, AVS 구성, 크기 조정 및 HCX 구성을 정확하게 설정하는 것은 매우 중요합니다. 마치 튼튼한 집의 기초를 쌓는 것과 같습니다. 서브넷 겹침과 같은 작은 실수도 심각한 지연을 초래할 수 있습니다. 아키텍처 설계를 완료했으니, 이제 마이그레이션 실행 계획 단계로 넘어가 보겠습니다.

마이그레이션 실행 및 운영

마이그레이션을 효과적으로 실행하려면 신중한 계획과 엄격한 검증이 필요합니다. 바로 이 부분에서 준비가 빛을 발하며, 성공을 위한 체계적인 접근 방식을 간략하게 설명하겠습니다.

제가 제안하는 실행 계획은 다음과 같습니다.

• HCX 설정 : HCX Manager를 사용하여 온프레미스 vCenter와 AVS vCenter를 페어링합니다. 컴퓨팅/네트워크 프로필을 사용하여 서비스 메시를 배포합니다.
• 네트워크 확장 : HCX NE를 통해 VLAN을 확장하고, ping 테스트로 검증하여 문제를 조기에 포착합니다.
• 파일럿 웨이브 : 대량 마이그레이션을 사용하여 프로세스를 테스트하기 위해 5~10개의 비중요 VM으로 시작합니다.
• 예약된 웨이브 : 비즈니스 윈도우에 맞춰 조정하세요. 중요한 VM에는 vMotion/RAV를 사용하여 다운타임을 최소화하세요.
• 롤백 전략 : 검증될 때까지 전원이 꺼진 소스 VM을 보관합니다.
• 모니터링 및 로깅 : HCX 대시보드를 사용하고 추적을 위해 VM에 태그를 지정하여 가시성을 유지합니다.

마이그레이션 워크플로는 다음과 같습니다.

성공의 핵심은 각 단계마다 엄격한 검증을 거치는 단계적 접근 방식입니다. 파일럿 웨이브는 실제 운영 환경으로의 마이그레이션 전에 문제를 파악하고 해결하는 데 도움이 될 것입니다. 워크로드가 AVS에 배치되면 다음 단계는 최적화 및 완료를 위한 계획 수립입니다.

마이그레이션 후 최적화 및 마무리

마이그레이션 후 최적화는 간과되는 경우가 많지만, AVS로 워크로드를 이전하여 얻을 수 있는 이점을 최대한 활용하는 데 매우 중요합니다. 이 단계는 최적의 성능, 리소스 효율성 및 비용 관리를 보장합니다.

제가 추천하는 최적화 계획은 다음과 같습니다.

• 성능 검증 : Azure Monitor와 vRealize Operations를 사용하여 CPU, 메모리, 디스크 지연 시간 및 네트워크 처리량을 확인합니다.
• 검증 체크리스트 :
  • 앱 기능.
  • DNS 확인.
  • 네트워크 연결성.
• 워크로드 적정 크기 조정 : VM 크기가 너무 크면 리소스가 낭비됩니다. Azure 권장 사항을 활용하여 가능한 경우 VM 크기를 줄이세요.
• 네트워크 확장 해제 : NSX-T 세그먼트로 전환한 후 사용하지 않는 L2 확장을 제거합니다.
• 비용 관리 : Azure Cost Management를 사용하여 예산과 알림을 설정하고, 업무 시간 외에는 프로덕션 환경이 아닌 VM의 종료를 예약할 수 있습니다.
• 거버넌스 :
  • Azure Automation으로 패치합니다.
  • Azure Policy 준수 여부를 감사합니다.

마이그레이션 후 최적화는 AVS에 대한 투자를 극대화하고 장기적인 안정성을 보장합니다. 단순히 클라우드에 접속하는 것만이 아니라, 클라우드에 접속한 후 효율적으로 운영하는 것이 중요합니다. 최적화된 환경을 바탕으로 보안, 규정 준수 및 거버넌스의 핵심 측면을 살펴보겠습니다.

보안, 규정 준수 및 거버넌스

워크로드를 AVS로 마이그레이션하려면 인프라를 Azure의 거버넌스 및 보안 모델과 통합해야 합니다. 워크로드를 보호하고 신뢰를 유지하려면 조직의 표준을 AVS 환경으로 원활하게 확장하는 것이 필수적입니다.

제가 제안하는 보안 및 거버넌스 계획은 다음과 같습니다.

• ID 및 액세스 관리(IAM) : 역할 기반 액세스 제어(RBAC)를 위해 Azure Active Directory(Azure AD)를 통합합니다. vCenter 접근 권한을 필수 인력으로 제한합니다.
• 보안 통합 : Azure Firewall, Defender for Cloud, Azure Sentinel을 사용하여 위협을 탐지하고 대응합니다.
• 규정 준수 관리 : Azure Policy를 활용하여 PCI-DSS, GDPR 또는 ISO 27001과 같은 표준을 시행합니다. Azure Security Center를 통해 정기 감사를 수행합니다.
• 중앙 집중식 로깅 및 모니터링 : 가시성을 높이기 위해 Azure Monitor 또는 Sentinel로 로그를 스트리밍합니다.

강력한 보안, 규정 준수 및 거버넌스 조치는 워크로드를 보호하고 비즈니스 연속성을 보장하는 데 필수적이며, 특히 금융과 같이 규제가 엄격한 산업의 경우 더욱 그렇습니다. 마이그레이션 계획에 대한 최종적인 생각과 의견을 공유해 보겠습니다.

마지막 생각

VMware HCX를 사용하여 AVS로 마이그레이션을 계획하는 것은 전략적이고 세부적인 작업으로, 신중한 준비와 VMware에 대한 심층적인 전문 지식이 필요합니다. 제 연구에 따르면 성공적인 마이그레이션은 정확한 평가, 세부적인 준비, 견고한 네트워킹 구성, 적절한 AVS 설정, 그리고 철저한 마이그레이션 후 최적화에 달려 있습니다. 고객의 500개 VM을 이전하는 이 계획은 최소한의 중단으로 원활하게 전환하기 위한 체계적인 접근 방식을 제시합니다.

HCX와 AVS를 통해 제공되는 기술과 도구 덕분에 프로세스 관리가 더욱 수월해졌지만, 명확한 소통, 상세한 문서화, 그리고 모든 단계에서 엄격한 검증의 중요성을 절대 과소평가해서는 안 된다는 것을 깨달았습니다. 마이그레이션 기간을 비즈니스 요구 사항에 맞추고 팀 간의 원활한 협업을 보장하는 것은 기술 설정만큼이나 중요합니다. 사전 계획 및 테스트에 상당한 노력을 투자하는 것을 강력히 권장합니다. 위험을 줄일 수 있고, 원활한 전환을 보장하여 마이그레이션을 단순한 기술적 성과가 아닌 비즈니스 성공으로 만들어 줍니다.

제 연구 결과와 이 계획이 AVS 마이그레이션 여정에 도움이 되기를 바랍니다. 궁금한 점이나 공유하고 싶은 경험이 있으시면 언제든지 댓글을 남겨주시거나 직접 연락해 주세요. 앞으로 더 많은 논의를 기대하겠습니다.

자주 묻는 질문

제가 자주 접하는 질문에 대한 답변은 다음과 같습니다.

• 예상 다운타임은 얼마나 되나요? vMotion은 다운타임이 없고, 대량 마이그레이션은 몇 분 정도 걸리며, 콜드 마이그레이션은 다운타임이 더 길어집니다.
• AVS 라이선스는 어떻게 적용되나요? Azure Hybrid Benefit을 사용하면 Windows Server 및 SQL Server 라이선스 비용을 절감할 수 있습니다.
• 문제가 발생하면 어떻게 되나요? 안전한 롤백을 위해 마이그레이션된 워크로드의 유효성이 완전히 검증될 때까지 소스 VM을 보관하세요.

추가 자료 및 공식 참조

공식 문서를 살펴보거나 HCX 및 Azure VMware Solution의 특정 영역을 더 자세히 알아보고 싶은 독자를 위해 다음과 같은 권장 리소스를 소개합니다.

• VMware HCX 설명서
  https://docs.vmware.com/en/VMware-HCX/index.html
• Azure VMware 솔루션 설명서 – Microsoft Learn
  https://learn.microsoft.com/en-us/azure/azure-vmware/
• AVS에서 VMware HCX 구성
  https://learn.microsoft.com/en-us/azure/azure-vmware/configure-vmware-hcx
• AVS 마이그레이션 아키텍처
  https://learn.microsoft.com/en-us/azure/azure-vmware/architecture-migrate

워크로드 검색 및 평가에 대한 Azure Migrate 설명서를 검토할 수도 있습니다 .

• https://learn.microsoft.com/en-us/azure/migrate/migrate-overview

VMware HCX를 사용하여 Azure VMware 솔루션으로 워크로드 마이그레이션: 실용 가이드

Azure VMware Solution은 Azure 또는 온프레미스를 통한 인터넷 송신을 허용합니다. 인터넷 송신이 Azure를 통해 송신되도록 설정된 경우, 기본적으로 아웃바운드 트래픽 검사는 수행되지 않습니다. 일반적으로 트래픽 검사는 구성되며 NSX-T 또는 Azure 가상 네트워크 내의 네트워크 가상 어플라이언스를 활용합니다. 이 블로그에서는 두 가지 모두 다루지 않습니다. 이 블로그에서는 Azure를 송신 지점으로 사용하여 Azure VMware Solution 인터넷 송신을 활성화하는 방법을 간략하게 설명합니다.

구현 및 구성

1. Azure VMware Service 프라이빗 클라우드로 이동하여 연결, 설정을 선택하고
   
   필요에 따라 인터넷 사용을 전환합니다.