깡민쓰~IT Story

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