[번역] vGPUs and vMotion, why the long stun times?

출처 : http://www.yellow-bricks.com/2020/02/07/vgpus-and-vmotion-why-the-long-stun-times/

vgpu-ecosystem-diagram.png

지난주에 우리 엔지니어 한 명이 내가 매우 흥미로웠던 것을 공유했다. 나는 Virtual Reality 기술과 NVIDIA vGPU로 2개월째 놀고 있다. 한 가지 주목할 점은 VMware(VMware)가 vSphere 6.7에서 vMotion에 대한 지원과 vSphere 6.7 U3에서 다중 vGPU VM의 vMotion에 대한 지원을 소개했다는 것이다. 이를 활성화하려면 먼저 고급 설정을 해야 한다. 윌리엄 램은 자신의 블로그에서 이것을 파워셀이나 UI를 통해 설정하는 방법을 설명했다. 설명서를 읽어보면, vGPU를 사용하도록 설정된 VM에 대해 상대적으로 높은 스턴 시간이라는 점이 눈에 띈다. 예를 들어, 다양한 크기의 vGPU 프레임 버퍼를 사용하는 몇 가지 잠재적인 스턴 시간은 다음과 같다:

  • 2GB - 16.5초
  • 8GB - 61.3초
  • 16GB - 100초 이상(시간 초과!)

 

이 모든 것은 다양한 프레임 버퍼 크기에 대해 여기에 설명되어 있다. 이제 이것에 대해 알아야 할 것이 몇 가지 있다. 우선 언급된 시간은 10GbE와 NVIDIA P40으로 테스트했다. 예를 들어, 이것은 RTX6000이나 RTX8000에서 다를 수 있다. 둘째로, 그들은 10GbE NIC를 사용했다. 다중 NIC vMotion을 사용하거나 예를 들어 25GbE NIC가 결과와 다를 수 있다(시간이 더 낮아야 함). 그러나 더 중요한 것은, 언급된 시간은 전체 프레임 버퍼 메모리가 소비된다고 가정한다. 16GB 프레임 버퍼가 있고 2GB만 소비되는 경우, 물론 위의 100초 이상보다 스턴 시간이 더 짧을 것이다.

자, 이것은 아직 그 질문에 대한 답이 되지 않는데, 왜 그럴까? 도대체 왜 이 시간들이 이렇게 긴가? vMotion 프로세스는 닐스가 이 블로그 게시물에 심도 있게 설명하므로 반복하지 않을 것이다. 또한 무료로 다운로드 받을 수 있는 Clustering Deep Dive 책에도 설명되어 있다. vMotion을 사용하여 "다운타임"(stun time)을 낮게 유지할 수 있는 주요 이유는 vMotion이 사전 복사 프로세스를 사용하여 어떤 메모리 페이지가 변경되었는지 추적하기 때문이다. 즉, vMotion이 시작될 때 메모리 페이지를 대상 호스트에 복사하고, 해당 복사 프로세스 중에 페이지가 변경된 경우 변경된 것으로 표시하고 다시 복사한다. vMotion은 복사해야 하는 메모리 양이 극도로 낮아 원활한 마이그레이션이 이루어질 때까지 이 작업을 수행한다. 이제 VM 메모리를 위해 이렇게 하는 문제가 있다. 불행히도 오늘날 vGPU에서는 이러한 일이 가능하지 않다.

좋아, 그게 무슨 뜻이야? 16GB 프레임 버퍼가 있고 100% 사용된다면 vMotion 프로세스는 VM이 망연자실할 때 16GB 프레임 버퍼 메모리를 소스에서 대상 호스트로 복사해야 할 것이다. VM이 중단되는 이유 단순히 그것이 프레임 버퍼 메모리가 변하지 않는 시점이기 때문에! 그래서 오늘날 불행히도 이것이 상당히 많은 시간이 걸릴 수 있는 이유. vMotion on (멀티) vGPU 지원 VM을 사용할 계획이라면 분명히 고려해야 할 사항!