얼마전에 The vMotion Process Under the Hood 라는 제목의 포스트가 VMware 블로그에 올라왔습니다.
https://blogs.vmware.com/vsphere/2019/07/the-vmotion-process-under-the-hood.html
vMotion 에 대해 한번 딥하게 생각해 보고 싶으신분이라면 한번 읽어보시면 좋겠습니다.
조금 오래되긴 했습니다만 다음 글도 추전합니다.
친절하게도 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 이 끝났다고 볼 수 있겠죠.
대충 요약하면 이정도 일텐데, 몇가지 다시한번 언급하고 싶습니다.
- vMotion Network 에 따라서 SDPS 이 동작하게 되면, VM 이 hang 상태처럼 보일 수 있다.
- vMotion 은 100% 무중단이라고 이야기하기는 어렵다.
- 왠만하면 I/O 가 덜 헤비할 때 하자.
- 10G 를 씁시다!
- 전용의 vMotion Network 을 씁시다!
참고 – 만약 vMotion TCP/IP stack 을 사용하실 경우에는 일반 vmkping 이 안되기 때문에 옵션을 꼭 걸어주서야 합니다.
예 – vmkping -S vMotion IP address
안녕하세요.
문의가 있어서 댓글은 남깁니다.
다른 클러스터의 호스트로 마이그레이션시
스토리지도 공유되어 있지 않다고 했을때
power off 된 vm의 경우에서는 management network 를 통해 migration 이 되는 걸로 알고 있는데 live vmotion 의 경우 vmotion network 를 통해 migration 이 진행되는거죠?
제가 겪은 증상으로는 다른 클러스터로 migration 시 management 에 영향을 준거 같아서 문의를 드립니다.
Shared nothing vMotion 을 하셨다는거죠?
스냅샷이 있을때랑 없을때가 다른데요
스냅샷이 있는 상태에서는 Base VMDK 가 Management network 를 통해 옮겨지고, 스냅샷이 없을때는 Base VMDK 는 vMotion network 를 쓰는데, VMDK 이외의 파일들 (스왑이나 로그 등) 은 Management network 를 씁니다.
아래 링크를 참조하세요.
https://frankdenneman.nl/2012/09/07/vsphere-5-1-vmotion-deepdive/
https://frankdenneman.nl/2013/02/07/why-is-vmotion-using-the-management-network-instead-of-the-vmotion-network/
안녕하세요.
답변 주셔서 감사합니다.
그러면 shared 라고 하면은 스냅샷이 있을때에와 없을때에 동일하게 vmotion network 를 쓴다고 보면 되죠
Shared 에서 vMotion 인 경우에는 스토리지 데이터가 이동하지 않기 때문에 vMotion network 만 사용됩니다. (메모리 카피 용도)
정확하게 알고 싶었던 내용들인데 언제나처럼 잘 정리해주셔서 감사합니다.