[reinvent 2024] VMware에서 native AWS로 이전

들어가며

VMWare는 브로드컴에 인수된 이후 라이센스 정책을 변경하여 기존 영구라이센스를 종료하고, 구독기반 모델로의 전환을 발표했습니다. 이 변경으로 인해, 일부 고객들은 라이센스 비용이 증가하게 되었습니다.

On-premise환경에서 VMware로 Private Cloud를 구성한 고객의 장기적인 비용증가가 예상되며, 이는 Public Cloud로의 전환의 계기가 될 수 있습니다. 그런 차에 VMware의 인프라를 AWS로 migration에 대비하는 세션을 살펴보려고 합니다.

Agenda

본 세션의 아젠다는 아래와 같습니다.

• Migration from VMware to native AWS  (VMware에서 native AWS로의 Migration)
• VMware versus AWS – High-level comparison  (VMware 대 AWS)
• Command line differences  (커맨드라인 명령어 비교하기)
• Q&A and interactive discussion  (묻고 답하기)

Migration from VMware to native AWS

왜 native AWS로 옮겨가야 하는가? 

이 물음에 대해 확장성과 유연성의 확보, 비용효율성, AWS와 통합, 성능과 보안성의 증대라고 연사는 이야기하고, 충분히 공감합니다. VMware는 정말 훌륭한 소프트웨어이고, On-premise진영에 없어서는 안될 믿을만한 가상화 솔루션입니다.

하지만, 이를 소유한 Broadcom은 무슨 이유인지 모르겠지만 극단적인 라이센스정책을 가동했고, 제가 On-premise의 책임자였다면 Migration장기계획을 세우고 있었을 겁니다. 어쨌든 비용과 지속가능성 면에서 도전적인 일임에 틀림없으니, 수년 내 옮기지않으면 서비스를 지속하기 어려운 일이 벌어질 수도 있습니다.

Rehost vs. Replatforming

AWS의 유명한 Migration에 대한 7가지 전략 중 Rehost와 Replatform에 관한 비교입니다. 왜 Rehost와 Replatform만 있을까요?

7가지 전략 중 Retire, Retain은 Migration대상에서 제외하는 것입니다. 또한, Relocate, Repurchase, Refactor은 다소 인프라관점의 Migration과는 조금 다릅니다. Relocate는 VMware Cloud on AWS 등의 솔루션을 사용하여 워크로드의 최소한의 변경으로 클라우드 환경으로 이전하는 방식입니다. Repurchase는 SaaS 또는 클라우드 네이티브 솔루션으로 교체하는 것입니다. Refactor는 인프라와 맞게 애플리케이션, 아키텍처를 모두 재작성하는 것입니다.

Rehost인 경우, On-premise의 서버 수량만큼 인스턴스를 대응하여 생성하여 구성하는 것입니다.

Replatform인 경우, On-premise의 서버 기능을 식별하여 그에 맞는 리소스로 변경하여 구성하는 것입니다. 데이터베이스라면 RDS, Aurora로, SAN/DAS스토리지는 S3, NAS스토리지는 EFS, 서버는 EC2로 구성하는 것입니다. 2가지의 경우라면, Rehost보다 Replatform전략으로 가는 것이 더 클라우드 특성을 살리고, 비용을 절감하는 방법입니다.

VMware를 AWS로 Migration하는 모범 사례입니다.

• 덜 중요한 워크로드부터 시작하라
  • 덜 중요하고 작은 워크로드부터 조금씩 옮겨보고 검증하며, 자신감을 갖는것이 중요합니다.
• AWS 랜딩존을 사용하라.
  • 지금 시점이라면 랜딩존의 최신 버전인 AWS Control Tower를 사용하라가 더 맞는 표현일것 같습니다. 그리고, 멀티 어카운트 사용을 권장한다는 의미도 내포된것 같습니다.
• 적절한 태깅과 조직을 구성하라.
  • 비용 추적을 위해 조직에 맞게 태깅을 하면 비용 추적 및 관리에 도움이 됩니다.
• 인스턴스선택을 위한 올바른 Sizing
  • On-premise에서 사용하는 인스턴스타입과 매칭하여 선택하고, 향후 모니터링하며 최적화하는 것이 좋습니다.

기술적인 관점이라면, 1,4번 항목이 중요하다 할 수 있겠습니다.

3M 이란 회사의 케이스 스터디가 예시로 제공되었습니다.

• 12시간 만에 500개 애플리케이션이 컷오버되어 Migration완료
• 수 천대의 서버에 배포된 2,200개 애플리케이션이 24개월에 걸쳐 Migration
• 몇 주나 걸리던 리소스 배포타임이 수 분으로 절감

VMware versus AWS

VMware에서의 네트워킹은 물리적 NIC, 물리적 스위치, 가상스위치, 포트그룹으로 구성됩니다.

NSX에 라는 추가 소프트웨어가 없다면, Tenant네트워크 구성이 불가하여 다소 제한된 네트워크 구성에 제한을 받으며, 개별 VM들은 vNIC을 할당받아 네트워크기능을 수행합니다.

AWS에서의 네트워킹은 VPC라는 가상네트워크에 가용영역, 서브넷 내에 EC2 인스턴스가 배치됩니다.

개별 인스턴스는 서브넷의 Network Interface를 할당받아 네트워크기능을 수행합니다.

Command line differences  (커맨드라인 명령어 비교하기)

VMware : 다양한 CLI명령어가 존재합니다.

• ESXi – VMware의 물리적호스트에 설치되는 호스트OS 소프트웨어입니다. 경량이며, 일반적인 OS와 패키지호환이 되지않습니다.
• vicfg-* – vSphere CLI에서 제공하는 명령어 세트이며, ESXi호스트와  vCenter Server를 원격으로 관리할 수 있습니다. 네트워크, 스토리지, 인증, 호스트 등의 다양한 작업이 가능합니다.
• Vmware-cmd, vifs, vmkfstools – 주요 명령어세트에 포함되지않으나, 스토리지 등을 관리하는데 필요한 유틸리티 명령어

AWS : 모든 명령어가 ‘aws’로 시작되어 하위명령어로 완성됩니다.

• Aws ec2 – EC2인스턴스를 생성/삭제/관리하는 명령어 (볼륨, VPC, 서브넷 포함)
• Aws s3 – S3버킷과 객체를 생성/삭제/관리하는 명령어
• Aws rds – RDS를 생성/삭제/관리하는 명령어

VMware에서 NIC를 장착한 VM을 구동하는 명령어의 예시입니다. 윈도우기반의 Hyper-V명령어로 제공됩니다.

• VM생성하기
  • $ New-VM -Name “MyNewVM” -VMHost $vmhost -DiskGB 40 -MemoryGB 4 -NumCpu 2
  • “MyNewVM”명칭으로 40GB디스크, 4GB메모리, 2CPU의 VM을 생성
    
    
• VM에 NIC추가하기
  • $vm = Get-VM -Name “MyNewVM”
    $ New-NetworkAdapter -VM $vm -NetworkName “MyNetworkName” -StartConnected -Type VMXNET3
    $ Get-NetworkAdapter -VM $vm | Set-NetworkAdapter -NetworkName “MyNetworkName” -StartConnected:$true
  • “MyNewVM”명칭의 VM값을 $vm변수에 저장
    “MyNetworkName”명칭의 NIC를 “MyNewVM”VM에 장착
    
    
• VM부팅하기
  • $vm = Get-VM -Name “MyNewVM”
    $ Start-VM -VM $vm

생각보다 명령어가 복잡하여, 스크립트화하여 자동화하는 편이 좋겠습니다.

AWS에서 인스턴스를 구동하는 명령어의 예시입니다.

• EC2인스턴스 생성 및 구동하기
  • $ aws ec2 run-instances –image-id ami-0f1e61a80c7ab943e –count 1 –instance-type t3.micro  –subnet-id subnet-09bd266884eb7e862

상위 표기된 VMware명령보다 더 간결합니다.

VMware vs. AWS CLI간 VM/인스턴스 관리명령어 비교입니다.

명령	ESX CLI	AWS CLI
모든 VM조회하기	Vim-cmd vmsvc/getallvms	Aws ec2 describe-instances
특정VM 시작하기	Vim-cmd vmsvc/power.on <vmid>	Aws ec2 start-instances –instance-ids <instance-id>
특정VM 중지하기	Vim-cmd vmsvc/power.off <vmid>	Aws ec2 stop-instances –instance-ids <instance-id>
특정VM 재부팅하기	Vim-cmd vmsvc/power.reboot <vmid>	Aws ec2 reboot-instances –instance-ids <instance-id>
특정VM 삭제하기	Vim-cmd vmsvc/destroy <vmid>	Aws ec2 terminate-instances –instance-ids <instance-id>

VMware vs. AWS CLI간 스토리지 관리명령어 비교입니다.

명령	ESX CLI	AWS CLI
모든 볼륨 조회하기	Esxcli storage core device list	Aws ec2 describe-volumes
볼륨 생성하기	Vmkfstools -c <size>G -d thin <datastore-path>	Aws ec2 create-volume –availability-zone <zone> –size <size>
볼륨을 VM/인스턴스에 장착하기	Vmkfstools -z <source-vmdk> <destination-vmdk>	Aws ec2 attach-volume –volume-id <volume-id> –instance-id <instance-id> –device <device>
볼륨 스냅샷 생성하기	Vmkfstools -i <source-vmdk> <snapshot-vmdk>	Aws ec2 create-snapshot –volume-id <volume-id>
볼륨용량 확장하기	Vmkfstools -X <new-size>G <vmdk-file>	Aws ec2 modify-volume –volume-id <volume-id> –size <new-size>

VMware vs. AWS CLI간 네트워크 관리명령어 비교입니다.

명령	ESX CLI	AWS CLI
모든 NIC 조회하기	Esxcli network nic list	Aws ec2 describe-network-interfaces
모든 라우팅테이블 조회하기	Esxcli network p route ipv4 list	Aws ec2 describe-route-tables
보안그룹의 ingress룰 추가하기	Esxcli network firewall ruleset set -e  true -r <ruleset-name>	Aws ec2 authorize-security-group-ingress –group-id <sg-id>  –protocol tcp  –port 22  –cidr 0.0.0.0/0
라우팅테이블에 라우팅 추가하기	Esxcli network ip route ipv4 add -g <gateway> -n <network>	Aws ec2 create-route  –route-table-id <rtb-id>  –destination-cidr-block <cidr>

결론

VMware와 AWS CLI간의 차이를 통해 플랫폼간 관점의 차이를 알 수 있었고, Migration에 대비하여 작업의 미세한 부분까지 컨트롤할 준비가 필요하다는 것을 보여준 세션입니다.

제 생각이지만, aws cli가 훨씬 더 간결하고 통일성이 있어서 좋았습니다. 이 세션이 VMware에서 AWS로 Migration을 준비하는 고객 중 실무자에게 직접적인 도움이 될것같고, 어서 빨리 클라우드로의 여정을 시작하셨으면 하는 바램입니다.