ESXi CPU 고려사항(ESXi CPU Considerations)

이 절에서는 VMware ESXi의 CPU 고려 사항에 대한 지침을 제공한다.

  • CPU 가상화는 물리적 프로세서에서 실행될 수 있는 가상 시스템의 워크로드의 비율과 나머지 워크로드의 가상화 비용에 따라 다양한 오버헤드를 추가한다.
  • 많은 워크로드의 경우 CPU 가상화는 매우 적은 양의 오버헤드만 추가하므로 본질적으로 네이티브에 필적하는 성능을 발휘한다.
  • CPU 가상화가 오버헤드를 추가하는 워크로드의 대부분은 CPU 바인딩이 아니며, 즉 대부분의 시간이 지침을 실행하는 대신 사용자 상호 작용, 장치 입력 또는 데이터 검색과 같은 외부 이벤트를 대기하는 데 소비된다. 그렇지 않으면 사용되지 않는 CPU 사이클이 가상화 오버헤드를 흡수할 수 있기 때문에 이러한 워크로드에는 일반적으로 네이티브와 유사한 처리량이 있지만 잠재적으로 지연 시간이 약간 증가할 수 있다.
  • 적은 비율의 워크로드의 경우, CPU 가상화가 오버헤드를 추가하고 CPU 바인딩된 워크로드의 경우 처리량과 지연 시간이 모두 현저하게 저하될 수 있다.

이 절의 나머지 부분에는 최적의 CPU 성능을 위해 VMware에서 권장하는 사례 및 구성이 나열되어 있다.

  • 대부분의 환경에서 ESXi는 가상 시스템 성능에 영향을 주지 않고 상당한 수준의 CPU 오버 커밋(즉, 해당 호스트의 총 물리적 프로세서 코어 수보다 많은 vCPU를 호스트에서 실행함)을 허용한다.
    ESXi 호스트가 CPU 포화 상태가 되면(즉, 호스트의 가상 시스템 및 기타 로드에 호스트의 모든 CPU 리소스가 필요함), 지연 시간에 민감한 워크로드가 제대로 수행되지 않을 수 있다. 이 경우 예를 들어 일부 가상 시스템의 전원을 끄거나 다른 호스트로 마이그레이션(또는 DRS가 자동으로 마이그레이션하도록 허용)하여 CPU 로드를 줄일 수 있다.
  • 호스트의 CPU 사용량을 주기적으로 모니터링하는 것이 좋다. 이는 vSphere Client를 통해 또는 esxtop 또는 resxtop을 사용하여 수행할 수 있다. 아래에서는 esxtop 데이터를 해석하는 방법을 설명한다.
  • esxtop CPU 패널의 첫 번째 라인의 부하 평균이 1보다 크거나 같을 경우, 이는 시스템이 과부하 상태임을 나타낸다.
  • PCPU 라인의 물리적 CPU 사용률은 과부하 상태의 또 다른 징후일 수 있다. 일반적으로 80%의 사용은 합리적인 한도가 되며 90%는 CPU가 과부하 상태에 도달한다는 경고가 되어야 한다. 그러나 조직은 원하는 부하 비율에 대해 다양한 표준을 가질 것이다.
    esxtop 또는 resxtop 사용에 대한 자세한 내용은 VMware Resource Management Guide Appendix A를 참조하기 바란다.
  • 워크로드에서 사용할 수 있는 것보다 더 많은 가상 CPU(vCPU)로 가상 시스템을 구성하면 리소스 사용량이 약간 증가하여 부하가 매우 높은 시스템의 성능에 영향을 줄 수 있다. 일반적인 예로는 워크로드가 효과적으로 사용할 수 있는 것보다 많은 vCPU를 사용하는 가상 시스템에서 실행되는 단일 스레드 워크로드 또는 다중 스레드 워크로드를 들 수 있다.
    게스트 운영 체제에서 vCPU를 일부 사용하지 않더라도 이러한 vCPU를 사용하여 가상 시스템을 구성하면 ESXi에서 호스트의 실제 CPU 사용으로 변환되는 몇 가지 작은 리소스 요구 사항이 여전히 부과된다. 예를 들면 다음과 같다.
  • 일부 게스트 운영 체제에서는 사용되지 않는 vCPU가 여전히 타이머 인터럽트를 사용한다( "Guest Operating System CPU Considerations"에 설명되어 있는 "tickless timer" 커널에서는 해당되지 않음)
  • 여러 vCPU 간에 일관된 메모리 보기를 유지하면 게스트 운영 체제와 ESXi에서 모두 추가 리소스를 사용할 수 있다.
  • 대부분의 게스트 운영 체제는 비활성 기간 동안 유휴 루프를 실행한다. 이 루프 내에서 대부분의 게스트 운영 체제는 HLT 또는 MWAIT 명령을 실행하여 중단된다. 그러나 일부 구형 게스트 운영 체제(Windows 2000(특정 HAL 포함), Solaris 8 및 9, MS-DOS 등)는 유휴 루프 내에서 사용량이 많은 대기 모드를 사용한다. 이로 인해 다른 용도로 사용할 수 있는 리소스(다른 가상 시스템, VMkernel 등)가 소비된다.
    ESXi는 이러한 루프를 자동으로 감지하고 유휴 vCPU의 스케줄을 해제함 이렇게 하면 CPU 오버헤드가 감소하지만 일부 I/O 헤비 워크로드의 성능도 감소할 수 있다. 자세한 내용은 VMware KB 문서 1077 및 2231을 참조하기 바란다.
  • 게스트 운영 체제의 스케줄러가 단일 스레드 워크로드를 여러 vCPU 간에 마이그레이션하여 캐시 지역성을 잃을 수 있다.
    이러한 리소스 요구 사항은 호스트의 실제 CPU 사용량으로 변환된다.
  • 일부 워크로드는 여러 가상 머신으로 쉽게 분할할 수 있다. 경우에 따라 동일한 수의 vCPU에 대해 더 작은 가상 머신("스케일아웃"이라고도 함)이 더 적은 수의 대형 가상 머신("스케일업"이라고도 함)보다 더 나은 성능을 제공할 수 있다. 다른 경우에는 그 반대가 사실이며, 더 적은 수의 대형 가상 머신이 더 나은 성능을 발휘할 것이다. 이러한 변화는 NUMA 노드 크기, CPU 캐시 지역성 및 워크로드 구현 세부 정보를 포함한 여러 요인에 의해 발생할 수 있다. 최상의 선택은 환경에서 특정 워크로드를 사용한 실험을 통해 결정할 수 있다.

ESXi의 Side-Channel 취약점 완화

"Side-Channel Vulnerabilities"에서 설명한 바와 같이, 하이퍼바이저 수준에서 일부 사이드 채널 취약점에 대한 완화가 이루어진다. 이 절에서는 이러한 완화 조치에 대한 간략한 개요를 제공한다.

Speculative Execution 취약점(Spectre, Meltdown, Foreshadow 등으로 알려진)

최신 ESXi 릴리스를 사용해서 어떤 Spectre, Meltdown, Foreshadow 보안 취약성을 완화할 수 있는지에 대한 자세한 내용은 VMware KB 문서 52245, 54951 및 55636을 참조하기 바란다.

"Side-Channel Vulnerabilities"에서 설명한 바와 같이, 이러한 취약성 중 일부는 최근의 CPU 버전에서 완화되며, 잠재적으로 성능에 미치는 영향이 적다.

L1 Terminal Fault(L1 TF)에 대한 스케줄러 옵션 취약점 완화

특정 사이드-채널의 취약성 중 하나인 L1 Terminal Fault(L1 TF) 취약점(CVE-2018-3646)은 선택을 하고 추가 조치를 취해야 한다. 이 취약점은 하이퍼스레딩을 사용하도록 설정한 경우 가상 시스템 간(또는 VM과 ESXi 간)에서 정보 누출을 잠재적으로 허용한다.

VMware KB 문서 55806에서 설명한 것처럼 성능 영향을 크게 주지 않고 이 취약성(sequential-context attack vector)의 한 부분을 자동으로 해결하는 업데이트를 많은 vSphere 버전에서 사용할 수 있다.

이러한 동일한 업데이트는 이 취약성의 다른 부분(concurrent-context attack vector)을 해결할 수 있지만 기본적으로 해결하지는 않는다. 이 취약성의 이 부분을 해결하려면 새로운 ESXi 스케줄러(ESXi Side-Channel-Aware Scheduler라고 함)를 수동으로 사용하도록 설정해야 하며, 이로 인해 특정 가상 시스템 실행 시 상당한 성능 영향과 제한 사항이 있을 수 있다.

Side-Channel-Aware Scheduler(SCAv1)의 초기 버전은 ESXi의 이전 버전 업데이트에서 사용할 수 있게 되었다. SCAv1은 스케줄러가 코어당 하나의 스레드만 사용하도록 제한한다. ESXi 6.7 Update2와 함께 두 번째 버전(SCAv2)이 출시되었다. SCAv2는 멀티스레딩을 지원하지만 동일한 코어에 있는 서로 다른 VM의 스레드를 동시에 스케줄링하지는 않는다. 거의 모든 경우에 SCAv2는 SCAv1보다 낮은 성능의 페널티를 부과한다.

VMware KB 문서 56931에 설명된 HTAware Mitigation Tool를 실행하여 SCAv1 사용 시 발생할 수 있는 잠재적인 문제에 대한 보고서를 얻는다. 이 도구를 사용하여 SCAv1, SCAv2 및 다양한 관련 설정 및 옵션을 활성화 또는 비활성화할 수도 있다.

스케줄러에 대한 자세한 내용은 VMware KB 문서 55806 및 Performance of vSphere 6.7 Scheduling Options(https://www.vmware.com/techpapers/2018/scheduler-options-vsphere67u2-perf.html)을 참조하기 바란다.

UP : SMP HAL/Kernel

하드웨어 추상화 레이어(HAL)와 커널:UP와 SMP의 두 가지 유형이 있다. UP는 역사적으로 "유니프로세서(uniprocessor)를 의미했다, 그러나 이제는 "싱글-코어(single-core)"로 읽혀여야 한다. SMP는 역사적으로 "대칭 다중 프로세서(symmetric multi-processor)"를 의미했지만, 이제는 멀티-코어(multi-core)로서 읽혀져야 한다.

  • 일부 최신 운영 체제(윈도우 비스타, 윈도 서버 2008, 윈도 7 포함)는 UP 및 SMP 설치 모두에 동일한 HAL 또는 커널을 사용하지만, 많은 운영 체제는 UP HAL/커널 또는 SMP HAL/커널을 사용하도록 구성할 수 있다. UP 및 SMP HAL/커널을 모두 제공하는 운영 체제를 실행하는 단일 vCPU 가상 시스템에서 최상의 성능을 얻으려면 UP HAL 또는 커널로 운영 체제를 구성해야 한다.

UP 운영 체제 버전은 단일 코어 시스템용이다. 멀티 코어 시스템에 사용되는 경우 UP 운영 체제 버전은 코어 중 하나만 인식하여 사용한다. 멀티 코어 머신을 완전히 활용하기 위해 필요한 SMP 버전도 싱글 코어 머신에서 사용할 수 있다. 그러나 추가 동기화 코드 때문에 단일 코어 시스템에 사용되는 SMP 운영 체제 버전은 동일한 시스템에서 사용되는 UP 운영 체제 버전보다 약간 느리다.

Windows를 실행하는 기존 가상 시스템을 다중 코어에서 단일 코어로 변경할 때 HAL은 보통 SMP로 유지된다. 최상의 성능을 위해 HAL을 수동으로 UP로 변경해야 한다.

하이퍼스레딩(Hyper-Threading)

  • 하이퍼스레딩 기술(일부 동시 멀티스레딩 또는 시만텍이라고도 함)은 하나의 물리적 프로세서 코어가 두 개의 논리 프로세서처럼 동작하도록 하여 기본적으로 두 개의 독립된 스레드를 동시에 실행할 수 있게 한다. 프로세서 코어가 2배 이상 많은 것과 달리-대략 2배의 성능-, 하이퍼스레딩은 프로세서 파이프라인을 더 바쁘게 유지함으로써 시스템 성능을 약간에서 상당히 향상시킬 수 있다.
    하드웨어 및 BIOS에서 하이퍼스레딩을 지원하는 경우 ESXi에서 하이퍼스레딩을 자동으로 사용 최상의 성능을 위해 다음과 같이 수행할 수 있는 하이퍼스레딩을 사용하도록 설정하는 것이 좋다.
    • 시스템이 하이퍼스레딩 기술을 지원하는지 확인한다. 프로세서가 하이퍼 스레딩을 지원하는 것만으로는 충분하지 않다. BIOS도 이를 지원해야 한다. BIOS에 하이퍼스레딩 지원이 포함되어 있는지 확인하려면 시스템 설명서를 참조하기 바란다.
    • 시스템 BIOS에서 하이퍼스레딩 활성화. 일부 제조업체는 이 옵션의 레이블을 Logical Processor라고 지정하고 다른 제조업체는 Enable Hyper-threading으로 지정한다.
  • ESXi가 하이퍼스레딩을 사용하도록 설정된 시스템에서 실행 중인 경우, CPU 번호는 같은 코어의 논리 프로세서가 연이어서 할당된다. 따라서 CPU 0과 1은 첫 번째 코어에 있고, CPU 2와 3은 두 번째 코어에 있다.
  • ESXi 시스템은 로드가 시스템의 모든 물리적 코어에 부드럽게 분산되도록 프로세서 시간을 지능적으로 관리한다. 논리 프로세서에 대한 작업이 없는 경우 실행 리소스를 해제하고 동일한 코어에 있는 다른 논리적 프로세서에서 실행 중인 가상 시스템이 코어의 전체 실행 리소스를 사용할 수 있도록 하는 중지 상태로 전환된다.
  • 하이퍼스레딩이 있는 시스템에서 CPU 선호도를 사용할 때 주의해야 한다. 두 논리 프로세서가 대부분의 프로세서 리소스를 공유하기 때문에 서로 다른 가상 시스템에서든 단일 SMP 가상 시스템에서든 vCPU를 하나의 코어에 있는 두 논리적 프로세서(예: CPU 0과 1)에 고정하면 성능이 저하될 수 있다.

누마(NUMA, Non-Uniform Memory Access)

이 절에서는 NUMA 하드웨어에서 ESXi를 실행할 때 최상의 성능을 얻는 방법을 설명한다.

NUMA 가상 머신을 생성할 수 있는 다른 기능인 가상 NUMA(vNUMA)는 "Virtual NUMA(vNUMA)"에 설명되어 있다.

일부 시스템에서 노드 인터리빙(Interleaved Memory라고도 함)에 대한 BIOS 설정은 시스템이 NUMA 시스템처럼 동작하는지 아니면 UMA(Uniform Memory Accessing) 시스템처럼 동작하는지 결정한다. 노드 인터리빙이 사용되지 않도록 설정된 경우 ESXi는 시스템을 NUMA로 감지하고 NUMA 최적화를 적용한다. 노드 인터리빙을 사용하도록 설정한 경우 ESXi에서 시스템을 NUMA로 감지하지 못한다. 자세한 내용은 서버 설명서를 참조하십시오.

ESXi와 함께 NUMA 시스템을 사용하는 방법에 대한 자세한 내용은 vSphere Resource Management를 참조하기 바란다.

수동 NUMA 구성

ESXi의 지능형, 적응형 NUMA 스케줄링 및 메모리 배치 정책은 모든 가상 시스템을 투명하게 관리할 수 있으므로 관리자는 손으로 노드 간에 가상 시스템을 밸런싱하는 복잡성을 처리할 필요가 없다. 그러나 수동 제어는 이 기본 동작을 재정의하기 위해 사용할 수 있으며 고급 관리자는 NUMA 배치를 수동으로 설정하는 것을 선호할 수 있다(고급 옵션의 numa.nodeAffinity).

기본적으로 ESXi NUMA 스케줄링 및 관련 최적화는 총 CPU 코어가 4개 이상이고 NUMA 노드당 CPU 코어가 2개 이상인 시스템에서만 사용하도록 설정된다.

이러한 시스템에서는 가상 머신을 다음과 같은 두 범주로 분리할 수 있다.

    • vCPU 수가 각 물리적 NUMA 노드의 코어 수와 같거나 그 이하인 가상 시스템.
      이러한 가상 시스템은 단일 NUMA 노드 내의 모든 코어에 할당되며 해당 NUMA 노드에 로컬 메모리를 우선적으로 할당한다. 즉, 메모리 가용성에 따라 모든 메모리 액세스가 해당 NUMA 노드에 로컬되어 가장 낮은 메모리 액세스 지연 시간이 발생하게 된다.
    • 각 물리적 NUMA 노드의 코어 수보다 vCPU가 많은 가상 시스템("Wide VM"이라고 함).
      이러한 가상 시스템은 두 개 이상의 NUMA 노드에 할당되며 해당 NUMA 노드에 로컬 메모리를 우선적으로 할당한다. 이러한 광범위한 가상 시스템의 vCPU는 때때로 자신의 NUMA 노드 외부의 메모리에 액세스해야 할 수 있기 때문에 NUMA 노드 내에 완전히 들어맞는 가상 시스템보다 평균 메모리 액세스 지연 시간이 더 높을 수 있다.

평균 메모리 액세스 지연 시간의 이러한 잠재적 증가는 가상 NUMA("Virtual NUMA(vNUMA)"에서 설명)를 적절하게 구성함으로써 완화할 수 있으므로 게스트 운영 체제가 메모리-로컬리티 관리 작업의 일부를 담당할 수 있다.

이러한 차이 때문에 일부 환경에서는 vCPU가 더 이상 없는 가상 시스템에 대해 각 물리적 NUMA 노드의 코어 수만큼 약간의 성능 이점이 있을 수 있다.

반대로, 일부 메모리 대역폭 병목 현상이 발생한 워크로드는 한 NUMA 노드 내에 들어갈 가상 머신을 여러 NUMA 노드로 분할할 때 사용할 수 있는 총 메모리 대역폭의 증가로 이득을 얻을 수 있다. 이 분할은 maxPerMachineNode 옵션을 사용하여 NUMA 노드당 배치할 수 있는 vCPU 수를 제한함으로써 달성할 수 있다(Virtual NUMA(vNUMA)를 참조하여 vNUMA에 미치는 영향도 고려한다).

하이퍼 스레드 시스템에서, vCPU 수가 NUMA 노드의 코어 수보다 크지만, 각 물리적 NUMA 노드의 논리적 프로세서 수보다 적은 가상 시스템은 원격 메모리가 있는 전체 코어 대신 로컬 메모리가 있는 논리적 프로세서를 사용하면 이점을 얻을 수 있다. numa.vcpu.preferHT 플래그를 사용하여 특정 가상 시스템에 대해 이 동작을 구성할 수 있다.

스눕 모드(Snoop Mode) 선택

캐시 데이터 일관성을 유지하기 위해 메모리 관련 작업에는 "스누핑"이 필요하다. 스누핑은 프로세서가 로컬 및 원격 프로세서의 캐시 내용을 검색하여 요청된 데이터의 복사본이 해당 캐시에 있는지 여부를 결정하는 메커니즘이다.

다섯 가지의 스눕 모드(모든 모드를 모든 프로세서에서 사용할 수 있는 것은 아님)가 있다.

    • Early Snoop (ES)
    • Home Snoop (HS)
    • Home snoop with Directory and Opportunistic Snoop Broadcast (HS with DIS + OSB)
    • Cluster-on-Die (COD)
    • Sub-NUMA cluster (SNC)

COD(Cluster-on-die) 모드에서는 프로세서 내에서 NUMA 노드를 부팅 시간에 구성할 수 있다. 이 기능은 논리적으로 프로세서를 단일 NUMA 노드(모든 프로세서 리소스를 포함하는) 또는 여러 NUMA 노드(각각 CPU 코어 집합, 마지막 수준 캐시의 부분 및 통합 메모리 컨트롤러로 구성된 노드)로 분할할 수 있다.

SNC(Sub-NUMA Cluster)는 Cluster-on-die와 유사하지만 마지막 레벨 캐시(LLC)를 사용하는 방식에 차이가 있다.

특정 환경에 가장 적합한 스눕 모드는 해당 환경의 특정 워크로드와 기본 하드웨어 모두에 따라 다르므로 이 선택을 할 때 서버 제조업체의 지침을 따를 것을 권장한다.

스눕 모드 및 다이의 클러스터에 대한 자세한 내용은 VMware KB 문서 2142499 및 https://software.intel.com/en-us/articles/intel-xeon-processor-e5-2600-v4-product-family-technical-overview를 참조하기 바란다. sub-NUMA 클러스터에 대한 자세한 내용은 https://software.intel.com/en-us/articles/intel-xeon-processor-scalable-family-technical-overview를 참조하기 바란다.

ESXi에서 호스트 전원 관리

ESXi의 호스트 전원 관리는 전원이 켜져 있는 동안 ESXi 호스트의 전원 소비를 줄이도록 설계되어 있다.

호스트 전원 관리는 전원이 켜진 호스트에는 적용되지만, 매우 다른 절전 기술인 Distributed Power Management는 필요하지 않을 때 ESXi 호스트의 전원을 끄려고 시도한다. 이는 "VMware Distributed Power Management(DPM)"에 설명되어 있다.
호스트 전원 관리와 분산 전원 관리를 함께 사용하여 전력 절약을 최적화할 수 있다.

ESXi의 Power Policy 옵션
    • High Performance
      이 전원 정책은 절전 기능을 사용하지 않으므로 모든 CPU가 완전히 로드된 시스템의 성능을 극대화한다.
    • Balanced
      이 전원 정책(기본값)은 전력 사용 유연성을 유지하면서 호스트 전력 소비를 줄이도록 설계되어 있으며, 따라서 일반적으로 성능 저하가 거의 또는 전혀 발생하지 않는다. 일부 시스템에서 CPU는 유휴 상태이며, 이 정책은 실제로 고성능 정책에서 사용할 수 있는 것보다 활성(비유휴) CPU가 더 빠른 터보 부스트 상태로 진입하도록 허용함으로써 성능을 높일 수 있다.
    • Low Power
      이 전원 정책은 성능 저하를 감수하고 호스트 전력 소비를 보다 적극적으로 줄이기 위해 고안되었다.
    • Custom
      이 전원 정책은 균형 조정과 동일하게 시작하지만 개별 매개변수의 수정을 허용한다.

전원 정책 선택에 대한 자세한 내용은 vSphere Resource Management에서 "Select a CPU Power Management Policy"을 찾아보기 바란다.

사용자 지정 정책에 대한 개별 전원 관리 매개 변수 수정에 대한 자세한 내용은 vSphere Resource Management에서 "Select a CPU Power Management Policy"을 찾아보기 바란다.

또한 서버의 BIOS 설정은 "Hardware BIOS Settings"에 설명된 대로 올바르게 구성되었는지 확인하십시오.

전력 관리 기술의 가용성 확인

경우에 따라 기본 하드웨어에는 ESXi에서 전력을 절약하기 위해 사용할 수 있는 기술 중 하나 이상이 없거나 이러한 기술을 ESXi에서 사용할 수 없게 되는 경우도 있다. 이것은 문제를 일으키지는 않지만, 시스템이 필요 이상으로 많은 전력을 사용하는 결과를 초래할 수 있다.

원하는 경우 다음 단계를 수행하여 하드웨어에 이러한 기술이 있는지, ESXi에서 사용할 수 있는지 확인하십시오.

    1. vSphere Client를 사용하여 관심 호스트를 선택한다.
    2. 해당 호스트에 대한 Configure 탭을 선택한다.
    3. Configure 탭의 왼쪽 창에서 Hardware에서 Power Management를 선택한다.
    4. Technology 필드에는 해당 호스트에서 ESXi에서 현재 사용할 수 있는 기술 목록(ACPI P-상태, ACPI C-상태 또는 둘 다)이 표시된다. 최고의 절전을 위해 ESXi에서 두 가지 기술을 모두 사용할 수 있기를 원할 것이다.
전원 정책 선택

균형 조정의 기본 전원 정책은 일반적으로 CPU 집약적 또는 메모리 집약적 워크로드의 성능에 영향을 미치지 않는다. 그러나 균형 조정 정책은 대기 시간에 민감한 워크로드의 성능을 약간 떨어뜨리는 경우도 있을지 모른다. 이 경우 고성능 전원 정책을 선택하면 완전한 하드웨어 성능이 제공된다. 이에 대한 자세한 내용은 "Running Network Latency Sensitive Workloads"을 참조하십시오.