최근에 CPU 소켓 설치 공간이 서로 다른 클러스터 간에 마이그레이션하는 고객으로부터 몇 가지 질문을 받았습니다. 이 문제를 해결하기 위해 EVC(향상된 vMotion 호환성)가 있으므로 클러스터 간에 실시간 워크로드를 마이그레이션할 필요가 없습니다.
EVC는 새로운 CPU 세대의 특정 고유 기능을 마스킹하고 클러스터 전체에서 CPU 기능의 일반적인 기준을 생성합니다. 워크로드가 두 클러스터 간에 이동하더라도 vMotion은 가상 시스템에 동일한 CPU 기능이 있는지 확인합니다. 워크로드를 이동할 계획이면 클러스터의 EVC 모드가 일치하는지 확인하여 가장 부드러운 환경을 구현하십시오.
소켓 구성이 서로 다른 ESXi 호스트 간에 라이브 워크로드를 이동할 때 문제는 가상 시스템의 vNUMA 토폴로지가 물리적 토폴로지와 일치하지 않는다는 것입니다. 가상 NUMA 토폴로지는 두 가지 구성 요소, 즉 가상 시스템에 CPU 토폴로지를 제공하는 구성 요소 VPD로 구성됩니다. VPD는 게스트 OS 및 애플리케이션의 CPU 스케줄링 결정을 최적화하는 데 도움이 됩니다. 이 VPD 구조는 기본적으로 가상 NUMA 토폴로지입니다. 다른 구성 요소인 PPD는 vCPU를 그룹화하고 NUMA 스케줄러가 물리적 NUMA 노드 간에 배치를 결정하는 데 도움이 됩니다.
이 사례에서 흥미로운 점은 VPD와 PPD는 밀접하게 연관되어 있지만 필요에 따라 다를 수 있다는 것입니다. 스케줄러는 두 요소 간의 구성을 미러링하려고 시도합니다. PPD 구성은 동적이지만 VPD 구성은 항상 동일하게 유지됩니다. VM의 전원이 켜진 순간부터 VPD 구성은 변경되지 않습니다. 운영 체제는 일반적으로 전체 CPU 레이아웃이 변경되는 것을 좋아하지 않기 때문에 이는 좋은 점입니다. CPU 핫 추가와 함께 코어를 추가해도 괜찮습니다. 하지만 캐쉬와 소켓 구성을 획기적으로 재배치하는 것은 상당히 어려운 일입니다.
이전에 언급했듯이, VPD는 그대로입니다. 그래도 NUMA 스케줄러는 CPU 스케줄러의 vCPU 그룹을 최적화하도록 PPD를 재구성할 수 있습니다. 언제 이런 일이 일어날까요? 물리적 CPU 구성이 다른 호스트로 VM을 이동하는 경우, 예를 들어 소켓 수 또는 소켓 수당 물리적 코어 수입니다. 이렇게 하면 ESXi는 여전히 이러한 상황에서 최상의 성능을 발휘합니다. 이 상황의 단점은 프레젠테이션과 스케줄링이 일치하지 않는다는 것입니다.
이 기능은 워크로드가 다운타임 없이 서로 다른 CPU 토폴로지 간에 이동성을 누릴 수 있다는 점에서 매우 유용합니다. 하지만 우리는 가능한 모든 공연을 짜내야 할 수도 있습니다. 일부 vCPU는 동일한 캐시를 공유하지 않을 수 있지만 애플리케이션에서는 공유한다고 생각합니다. 또는 일부 vCPU가 동일한 물리적 NUMA 노드에서 함께 스케줄링되지 않아 레이턴시(지연시간이 발생)과 대역폭이 줄어들 수 있습니다. 더 정확히 말하면, 이 불일치는 메모리 인접성과 스케줄러의 작업 선호도 로드 밸런싱 작업에 영향을 미칠 수 있습니다. 따라서 VM 성능에 영향을 미치고 CPU 간 트래픽을 더 많이 생성할 수 있습니다. 이러한 영향은 VM별로 미미할 수 있지만, 모든 VM의 성능 손실을 전체적으로 고려해야 하므로 대규모 환경에서는 수정하는 것이 좋습니다.
소켓당 20개의 물리적 CPU 코어가 있는 이중 소켓 시스템에서 vCPU 36개인 VM을 생성했습니다. 가상 시스템의 전원 켜기 프로세스는 vNUMA 토폴로지를 생성하고 모든 종류의 항목을 VMX 파일에 입력합니다. VMX의 전원을 켜면 VMX 파일에 다음과 같은 항목이 수신됩니다.
numa.autosize.cookie = "360022"
numa.autosize.vcpu.maxPerVirtualNode = "18"
이 예제의 핵심 항목은 numa.autosize.vcpu.maxPerVirtualNode = "18"입니다. NUMA 스케줄러는 최대한 많은 vCPU를 여러 코어에 균등하게 배포하는 것을 좋아하기 때문에 이 값을 선택합니다.
하지만 이 가상 머신이 소켓당 14개의 물리적 코어가 있는 쿼드 소켓 시스템으로 이동하면 어떻게 될까요? NUMA 스케줄러는 이러한 vCPU를 NUMA 노드에 분산하는 세 가지 스케줄링 구조를 생성하지만 게스트 OS와 애플리케이션에 혼란을 주지 않도록 프레젠테이션 계층을 동일하게 유지합니다.
VM의 전원을 켜는 동안 NUMA 토폴로지가 생성되므로 VPD 및 PPD 토폴로지를 다시 재정렬하려면 가상 시스템을 종료한 후 전원을 다시 켜야 합니다. 2019년부터는 더 이상 VM의 전원을 끌 필요가 없습니다. 그리고 인정해야겠어요 저는 그 사실을 최근에야 알았습니다. Bob Plankers(Bob이 아님)는 vmx.reboot.PowerCycle 고급 파라미터에 대해 씁니다. 이 설정은 더 이상 전체 전원을 껐다 켤 필요가 없습니다.
즉, VM 자산을 이중 소켓 시스템에서 쿼드 소켓 시스템으로 마이그레이션하는 프로세스인 경우 VMX가 실행되는 동안(예: PowerCLI / New-AdvancedSetting을 통해) VMX 파일에 다음 조정을 추가할 수 있습니다.
vmx.reboot.PowerCycle = true
numa.autosize.once = false
vmx.reboot.PowerCycle 설정이 VMX 파일에서 자체적으로 제거되지만, VMX 파일에서 numa.autosize.once = false를 제거하는 것이 가장 좋습니다. 그러니 이걸 추적해보세요 설정을 추가하는 것과 마찬가지로 VM이 가동되어 실행되는 동안 설정을 제거할 수 있습니다.
이러한 설정을 VMX에 적용하면 다음에 VM이 재부팅될 때 vNUMA 토폴로지가 변경됩니다. 항상 그렇듯이, 오래된 시스템은 새로운 시스템보다 더 극적으로 반응할 수 있습니다. 결국 시스템의 하드웨어 토폴로지를 변경하고 있습니다. 그러면 이전 Windows 시스템이나 오래된 응용 프로그램의 최적화가 실패할 수 있습니다. 일부 오래된 운영 체제는 이러한 방식을 좋아하지 않아 자체적으로 재구성을 수행하거나 IT 운영 팀의 도움이 필요합니다. 최악의 경우 이를 염두에 두고 고객을 BSOD로 대하게 됩니다. 기존 OS를 사용하는 고객과 협력하여 테스트 및 마이그레이션 계획을 수립하는 것이 좋습니다.
Gilles Le Ridou에게 특별히 감사드립니다. 제 의심을 확인하고, 그의 환경에 대한 시나리오를 실험할 수 있도록 도와주신 것에 대해서요.
출처 : https://frankdenneman.nl/2022/03/11/solving-vnuma-topology-mismatch-when-migrating-between-dual-socket-servers-and-quad-socket-servers/
