The vMotion Process Under the Hood

얼마전에 The vMotion Process Under the Hood 라는 제목의 포스트가 VMware 블로그에 올라왔습니다.

 

https://blogs.vmware.com/vsphere/2019/07/the-vmotion-process-under-the-hood.html

 

vMotion 에 대해 한번 딥하게 생각해 보고 싶으신분이라면 한번 읽어보시면 좋겠습니다.

 

조금 오래되긴 했습니다만 다음 글도 추전합니다.

 

vSphere 5.1 vMotion Deep Dive

https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/techpaper/vmware-vmotion-performance-vsphere5.pdf

https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/techpaper/vmware-vsphere51-vmotion-performance-white-paper.pdf

 

친절하게도 VMware 공인 강사분중 한분이 해당 글을 번역해둔것이 있습니다. 영어로 인해 고통받지 않고 싶으신분들은 대신 읽어보셔도 좋을듯 합니다.

 

https://sddc.098.co.kr/books/vmware-vsphere/page/the-vmotion-process-under-the-hood

 

위와 같이 원본도 있고, 대체자료도 있지만 굳이 별도의 포스트를 작성하는 것은 개인적인 이해를 돕기 위함입니다. 원문의 내용 + 개인적으로 추가하고자 하는 내용을 담았습니다.

 

vMotion 하면 사실 VMware 하면 대표적으로 떠오르는 기능이죠. 뭐 Storage vMotion 도 있고, 요새 HCX 내에서도 사용됩니다만, 일단 원문의 취지에 맞춰서 Compute-only Migration 만 다루겠습니다.

 

vCenter 에서 VM 을 선택하고 우클릭을하면 Migrate 라는 메뉴가 있죠. 해당 메뉴를 클릭하면 다음과 같은 과정이 진행됩니다. vMotion 이 실제로 진행될 수 있는지 사전 점검하는 과정이라고 보시면 되겠습니다.

  • Source 와 Destination(Target) 호스트간의 호환성 체크, 대표적으로 CPU Generation 등이 있을 것입니다. 또 예전에는 Shared Storage 가 MUST 였지만 요새는 Shared nothing vMotion 도 가능하죠. EVC 도 한몫 할 수 있는 부분이겠습니다.
  • 대상 VM 의 구성정보 (Virtual Hardware 나 CPU Affinity rule 등이 있는지)
  • vMotion Network 정보 1G 인지 10G 인지 Source 및 Destination 호스트의 네트워크에 vMotion 네트워크가 존재하는지 등등.. 참고로 1G냐 10G냐에 따라서 동시에 실행가능한 vMotion 숫자가 달라집니다.

 

vCenter 에서 이러한 정보들을 취합해서 Source 와 Destination 에 제공합니다. 좀 더 상세하게 들여다보면 vCenter 의 VPXD 과 ESXi 호스트의 VPXA 간에 주고 받는것이죠. ESXi VPXA 에서 해당 정보를 받으면 이것을 실제로 수행하도록 Hostd 로 보냅니다. 

이러한 과정을 거쳐 실제로 vMotion 이 트리거 되면 VM 의 상태가 intermediate 로 변경되고, 이 때에는 VM 의 설정값 등은 변경할 수 없는 상태가 됩니다.

 

그럼 그 이후의 과정은 어떻게 되느냐, 일단 vMotion 간에 변경되는 데이터를 담아내기 위한 page tracers 가 설치 되며, 이때 약간의 stunned 이 발생할 수 있습니다. 이 과정동안에는 Guest OS 가 Source ESXi 호스트의 로컬 메모리에 바로 데이터를 쓰지 않고, VMM 프로세서로 보내고, 해당 프로세서는 그 데이터를 소스 호스트의 메모리와, Destination 호스트의 메모리로 각각 보내는거죠.  몇번의 Phase 를 돌면서, 메모리카피가 끝날때까지 수행됩니다. 

 

만약 vMotion Network 에서 사용가능한 대역폭이 모잘라서, 변경되는 데이터를 계속 카피가 어려운 경우에는 SDPS 라는 기능이 동작해서 메모리가 변경되는 것을 줄입니다. 일종의 VM 의 CPU Cycle 을 줄이는 기능입니다. 예전 경험상으로 1G 등에서 동시에 다수의 vMotion 을 걸거나, 또는 전용의 vMotion 네트웍을 사용하지 않는 경우에는 SDPS 가 동작하는 시간이 길어서 실제로 VM 이 Hang 처럼 보이는 사례가 있었습니다. 1G 네트워크라면 보통 한개를 수행할 때 110MB/s 정도 나오는데, 거의 뭐 10MB/s 도 안나오는 상황이였던걸로 기억합니다.

 

암튼 메모리 복사까지 잘 되었다면 이제 switch over phase 로 들어가는데요, 한가지 염두해줄 필요는 이 switchover 자체가 보통 1초 이내에 끝나기 때문에, 네트워크 단절등을 경험하지 않을수도 있지만, 그렇다고 해서 100% 무중단이다 라고 이야기 하기는 어렵습니다. 예전 경험으로 vMotion 을 하고 나서 어플리케이션에 영향이 있었다 라고 하길래, 그 어플리케이션이 감당할 수 있는 네트워크 타임아웃은 몇초인가요? 라고 물어봤더니 공장 라인에서 사용하는 것이라 굉장히 민감하다고 하더군요. 그래서 그런 어플리케이션이 있을 경우에는 vMotion 을 쓰시지 않는게 좋겠습니다 라고 하고 종결한 경험이 있네요. 

 

Destination Host 으로 Switchover 가 끝나면 이제 Migration 이 끝났다고 볼 수 있겠죠.

 

대충 요약하면 이정도 일텐데, 몇가지 다시한번 언급하고 싶습니다.

 

  1. vMotion Network 에 따라서 SDPS 이 동작하게 되면, VM 이 hang 상태처럼 보일 수 있다. 
  2. vMotion 은 100% 무중단이라고 이야기하기는 어렵다. 
  3. 왠만하면 I/O 가 덜 헤비할 때 하자. 
  4. 10G 를 씁시다!
  5. 전용의 vMotion Network 을 씁시다!

 

참고 – 만약 vMotion TCP/IP stack 을 사용하실 경우에는 일반 vmkping 이 안되기 때문에 옵션을 꼭 걸어주서야 합니다.

예 – vmkping -S vMotion IP address

vmkping_succes