2. ESXi and Virtual Machines

ESXi 일반 고려 사항(ESXi General Considerations)

이 절에서는 ESXi의 여러 가지 일반적인 성능 고려 사항에 대한 지침을 제공한다.

ESXi 6.7에서는 기본적으로 가상 하드웨어 버전 14를 사용하여 가상 시스템을 생성한다. 이 기본값은 호스트, 클러스터 또는 전체 데이터 센터에 대해 변경할 수 있다.

 

ESXi CPU 고려사항(ESXi CPU Considerations)

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

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

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)로서 읽혀져야 한다.

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

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

하이퍼스레딩(Hyper-Threading)

누마(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개 이상인 시스템에서만 사용하도록 설정된다.

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

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

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

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

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

스눕 모드(Snoop Mode) 선택

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

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

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 옵션

전원 정책 선택에 대한 자세한 내용은 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"을 참조하십시오.

 

ESXi 메모리 고려사항

아래의 절은 ESXi 메모리 고려사항에 대한 지침을 제공한다.

메모리 오버헤드

가상화는 자체 코드와 데이터 구조에 필요한 추가 메모리 때문에 필요한 물리적 메모리의 양을 증가시킨다. 이 추가 메모리 요구 사항은 다음과 같은 두 가지 구성 요소로 분리할 수 있다.

1    VMkernel 및 다양한 호스트 에이전트(hostd, vpxa 등)에 대한 시스템 차원의 메모리 공간 오버헤드.

ESXi는 호스트가 메모리 압박을 받을 때 시스템 스왑 파일을 사용하여 이 메모리 오버헤드를 최대 1GB까지 줄일 수 있도록 허용한다. 이 기능을 사용하려면 먼저 시스템 스왑 파일을 수동으로 생성해야 한다. ESXi 콘솔에서 esxcli sched swap set -d true -n <datastore name> 명령을 실행하여 이 작업을 수행할 수 있다.
스왑 파일은 1GB이며 지정된 데이터스토어의 루트에 생성된다.

이 시스템 스왑 파일은 가상 시스템별 메모리 공간 오버헤드의 VMX 구성 요소에서 메모리 페이지를 저장하는 가상 시스템별 스왑 파일과 다르다.

2    각 가상 시스템의 추가 메모리 공간 오버헤드.

가상 머신별 메모리 공간 오버헤드는 다음과 같은 범주로 추가로 나눌 수 있다.

이러한 목적으로 예약된 메모리 양은 vCPU 수, 게스트 운영 체제의 구성된 메모리, 게스트 운영 체제가 32비트인지 64비트인지, VMM 실행 모드, 가상 시스템에 사용하도록 설정된 기능 등 다양한 요소에 따라 달라진다. 이러한 오버헤드에 대한 자세한 내용은 vSphere Resource Management를 참조하기 바란다.

가상 시스템의 전원을 켤 때 VMM 및 가상 디바이스 메모리 요구 사항은 완전히 예약되어 있지만, VMX 스왑이라는 기능은 가상 시스템당 VMX 메모리 예약을 크게 줄여 호스트 메모리가 오버 커밋될 때 더 많은 메모리를 스왑 아웃할 수 있다. 이는 각 가상 시스템에 예약된 오버헤드 메모리의 상당한 감소를 나타낸다.

각 가상 시스템에 대한 VMX 스왑 파일 생성(따라서 해당 가상 시스템에 대한 호스트 메모리 예약 감소)은 자동으로 수행된다. 기본적으로 이 파일은 가상 시스템의 작업 디렉토리(가상 시스템의 .vmx 파일에서 workingDir에 의해 지정된 디렉토리 또는 이 변수가 설정되지 않은 경우 .vmx 파일이 있는 디렉토리에서)에 생성되지만 sched.swap.vmxSwapDir로 다른 위치를 설정할 수 있다.

필요한 디스크 공간은 다양하지만 대형 가상 시스템의 경우에도 일반적으로 100MB 미만(일반적으로 가상 시스템이 3D 그래픽용으로 구성된 경우 300MB 미만)이다. sched.swap.vmxSwapEnabled를 FALSE로 설정하여 VMX 스왑 파일 생성을 사용하지 않도록 설정할 수 있다.

VMX 스왑 파일은 호스트 캐시 또는 일반 호스트 수준 스왑과 전혀 관련이 없으며, 두 파일 모두 "Memory Overcommit Techniques"에 설명되어 있다.

또한 ESXi는 페이지 공유(32페이지의 "메모리 오버 커밋 기술" 참조)와 같은 최적화 기능을 제공하여 기본 서버에서 사용되는 물리적 메모리 양을 줄인다. 어떤 경우에는 이러한 최적화가 오버헤드에 의해 차지하는 메모리보다 더 많은 메모리를 절약할 수 있다.

메모리 사이징

가상 시스템에 할당하는 메모리 양을 주의하여 선택하십시오.

작업 세트를 유지하는 데 필요한 양을 초과하여 가상 시스템에 할당된 메모리는 일반적으로 파일 시스템 캐시를 위해 게스트 운영 체제에 의해 사용된다. 호스트 수준의 메모리 리소스가 부족해지면 ESXi는 일반적으로 메모리 벌룬("Memory Overcommit Techniques"에서 설명)을 사용하여 이러한 캐시에 사용된 메모리 부분을 회수할 수 있다.

그러나 메모리를 과도하게 할당하면 가상 시스템 메모리 오버헤드가 불필요하게 증가한다. ESXi는 일반적으로 오버할당된 메모리를 회수할 수 있지만 이 오버할당된 메모리와 관련된 오버헤드는 회수할 수 없으므로 더 많은 가상 시스템을 지원하는 데 사용될 수 있는 메모리를 소비한다.

메모리 오버 커밋 기술

ESXi는 페이지 공유, 벌루닝, 메모리 압축, 호스트 캐시로 스왑, 정기적인 스와핑 등 5가지 메모리 관리 메커니즘을 사용하여 각 가상 시스템에 필요한 시스템 물리적 메모리 양을 동적으로 줄인다.

메모리 관리에 대한 자세한 내용은 Understanding Memory Resource Management in VMware vSphere 5.0(이 백서에서는 vSphere 5.0을 특히 다루지만 대부분의 개념은 vSphere 6.7에 적용됨) 및 Memory Overcommitment in the ESX Server를 참조하기 바란다.

메모리 오버 커밋이 가상 시스템의 성능에 영향을 미치기 시작하는 것으로 의심되는 경우 다음 단계를 수행하십시오.

메모리 오버 커밋이 워크로드 성능에 영향을 미치기 시작하는 지점은 워크로드에 따라 크게 달라진다. 이 절에서 설명하는 영역은 대부분의 작업 부하와 관련이 있을 것이다. 그러나 이러한 작업 부하 중 일부는 다른 작업 부하보다 성능에 더 일찍 영향을 미칠 것이다.

    1. vSphere Client에서 해당 가상 시스템을 선택하고 Monitor > Performance > Advanced을 선택한 다음 오른쪽 상단의 Memory 선택 드롭다운에서 Ballooned memory(Average)을 확인한다.
      벌루닝이 없는 경우 ESXi는 과도한 메모리 압박을 받지 않으므로 메모리 오버 커밋이 해당 가상 시스템의 성능에 영향을 미치지 않는다는 것을 알 수 있다.

      이 표시기는 벌룬 드라이버가 가상 시스템에 설치되어 있고 작동이 차단되지 않은 경우에만 의미가 있다.
      일부 풍선은 매우 정상적이며 문제를 나타내지 않는다.

    2. vSphere Client에서 해당 가상 시스템을 선택하고 Monitor > Performance > Advanced을 선택한 다음 오른쪽 상단의 Memory 선택 드롭다운에서 Memory를 선택한 Consumed 메모리와 Active 메모리의 값을 비교한다. 소비량이 활성보다 높은 경우, 이는 게스트가 현재 최상의 성능을 위해 필요한 모든 메모리를 확보하고 있음을 시사한다.
    3. vSphere Client에서 해당 가상 시스템을 선택하고 Monitor > Utilization를 선택한 다음 Guest Memory 창을 확장한 다음 Swapped 및 Compressed 값을 확인한다. 여기서 0이 아닌 값은 호스트 수준에서 스와핑 또는 압축을 나타내며, 이는 보다 유의미한 메모리 압력을 나타낸다.
    4. 해당 가상 시스템 내에서 게스트 운영 체제 스왑 작업을 확인한다.
      이는 스왑 활동이 게스트 운영 체제 내의 다른 문제와 전적으로 관련될 수도 있지만(또는 게스트 메모리 크기가 단순히 너무 작다는 표시일 수도 있음) 벌룬이 성능에 영향을 미치기 시작할 수 있음을 나타낼 수 있다.

메모리 페이지 공유

vSphere 6.0(및 일부 이전 릴리스에 대한 패치 또는 업데이트에 포함)부터 페이지 공유는 가상 시스템 내에서 기본적으로 사용하도록 설정되지만("VM 내 공유"), 가상 시스템 간의 페이지 공유("VM 간 공유")는 동일한 "salt" 값을 가질 때만(아래 설명 참조) 사용 가능하다. 이러한 변경은 가상 머신에 대한 최고의 보안을 보장하기 위해 이루어졌다.

페이지 공유를 사용하도록 설정해도 공유되지 않는 2MB 대용량 메모리 페이지("2MB Large Memory Pages" 참조)가 널리 보급되어 있기 때문에, 이러한 변화는 대부분의 배포에서 메모리 사용량에 작은 영향을 미칠 가능성이 있다.

그러나 소규모 메모리 페이지를 광범위하게 사용하는 환경(예: 많은 VDI 구축)에서는 가상 머신 간에 페이지를 공유하는 것이 메모리 사용량을 상당히 줄일 수 있다.

기본적으로 특정 가상 시스템의 salt 값인 가상 시스템의 vc.uuid는 단일 ESXi 호스트의 가상 시스템 간에 항상 고유하므로 VM 간 페이지 공유를 차단한다.

다음 방법 중 하나를 사용하여 VM 간 페이지 공유를 활성화할 수 있다.

참고 호스트 구성 옵션 Mem에 대한 자세한 내용은 다음을 참조하십시오.ShareForceSalting은 VMware KB 문서 2097593을 참조하십시오.

페이지 공유 및 관련 보안 문제에 대한 자세한 내용은 VMware KB 문서 2080735 및 2097593을 참조하기 바란다.

메모리 스왑 최적화

위의 "메모리 오버 커밋 기술"에서 설명한 바와 같이 ESXi는 호스트 수준 스와핑 없이 제한된 양의 메모리 오버커밋을 지원한다. 그러나 오버 커밋이 너무 커서 다른 메모리 회수 기법이 충분하지 않으면 ESXi는 호스트 수준의 메모리 스와핑을 사용하며 가상 시스템 성능에 상당한 영향을 줄 수 있다.

이 절에서는 호스트 수준의 스와핑을 방지하거나 줄이는 방법을 설명하고, 불가피한 경우 성능에 미치는 영향을 줄이는 기법을 제시한다.

호스트 캐시로 스왑을 사용하는 것과 일반 스왑 파일을 SSD에 저장하는 것은 호스트 스왑 성능을 향상시키기 위한 두 가지 다른 접근 방식이다. 호스트 캐시로 스왑하면 잠재적으로 제한된 SSD 공간을 최대한 활용하는 동시에 일부 SSD가 가장 잘 작동하는 대규모 블록 크기에 최적화된다.

일반 스왑 파일을 SSD에 배치하는 것과 SSD의 호스트 캐시로 스왑을 사용하는 것은 호스트 스왑 성능을 향상시키기 위한 두 가지 다른 접근 방식이다. 호스트의 전체 스왑 파일 요구에 충분한 SSD 공간을 확보하는 것은 이례적이기 때문에 호스트 캐시로 스왑할 때 로컬 SSD를 사용하는 것이 좋다.

실행 중인 가상 시스템에 적용할 때 이러한 메모리 예약의 효과는 점진적으로만 나타날 수 있다. 즉시 전체 효과를 보려면 가상 시스템의 전원을 껐다가 켜야 한다.

그러나 리소스 예약을 구성하면 시스템에서 실행할 수 있는 가상 시스템의 수가 감소한다는 점에 유의해야 한다. 이는 ESXi가 모든 예약(가상 시스템 및 오버헤드 모두에 대해)을 충족할 수 있을 만큼 호스트 메모리를 충분히 사용할 수 있으며, 그렇게 하면 사용 가능한 메모리가 예약된 양보다 적게 감소할 경우 가상 시스템의 전원을 켜지 않기 때문이다.

메모리 예약은 ESXi가 가상 시스템에 예약하는 물리적 메모리 양에 대한 보장된 하한 값이다. 각 가상 시스템의 설정 창에서 vSphere Client를 통해 구성할 수 있다(가상 시스템을 마우스 오른쪽 버튼으로 클릭하고 Edit Settings을 선택하고 Virtual Hardware 탭을 선택하고 Memory를 확장한 다음 원하는 예약을 설정).

2MB 대용량 메모리 페이지

ESXi는 일반적인 4KB 메모리 페이지 외에도 2MB 메모리 페이지(일반적으로 "대형 페이지"라고 함)를 제공한다. (일부 CPU는 1GB 메모리 페이지를 지원하지만 이 책에서 "대형 페이지"라는 용어는 2MB 페이지를 지칭할 때만 사용된다는 점에 유의하기 바란다.)

ESXi는 가능한 경우 언제든지 이 2MB 시스템 메모리 페이지를 게스트 운영 체제에 할당하며, 게스트 운영 체제에서 요청을 하지 않더라도 이렇게 한다(게스트 운영 체제 메모리 고려 사항("Guest Operating System Memory Considerations"에서 설명한 것처럼 큰 페이지의 모든 이점은 게스트 운영 체제와 애플리케이션이 이 페이지를 함께 사용할 때만 제공된다)). 대형 페이지를 사용하면 TLB misses를 크게 줄일 수 있어 대부분의 작업 부하, 특히 활성 메모리 작업 세트가 큰 작업 세트의 성능을 향상시킬 수 있다. 또한 큰 페이지는 가상 머신당 메모리 공간 오버헤드를 약간 줄일 수 있다.

큰 페이지를 사용하면 페이지 공유 동작도 바꿀 수 있다. ESXi는 일반적으로 메모리 요구와 관계없이 페이지 공유를 사용하지만(vSphere 6.0에서 이 동작이 변경된 방식을 읽으려면 "Memory Page Sharing" 참조), ESXi는 대형 페이지를 공유하지 않는다. 따라서 대형 페이지의 경우, 메모리 오버 커밋이 큰 페이지를 작은 페이지로 분할하도록 요구할 정도로 충분히 높을 때까지 페이지 공유는 일어나지 않을 수 있다. 자세한 내용은 VMware KB 문서 1021095 및 1021896을 참조하기 바란다.