ESXi 메모리 고려사항

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

메모리 오버헤드

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

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

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

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

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

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

    • VMX(가상 시스템 실행 파일) 프로세스를 위해 예약된 메모리.
      게스트를 부트스트랩하고 지원하는 데 필요한 데이터 구조(즉, 스레드 스택, 텍스트 및 힙)에 사용된다.
    • VMM(가상 시스템 모니터)용으로 예약된 메모리.
      가상 하드웨어에 필요한 데이터 구조(예: TLB, 메모리 매핑 및 CPU 상태)에 사용된다.
    • 다양한 가상 디바이스(예: 마우스, 키보드, SVGA, USB 등)용으로 예약된 메모리
    • 커널, 관리 에이전트 등 다른 서브시스템용으로 예약된 메모리

이러한 목적으로 예약된 메모리 양은 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페이지의 "메모리 오버 커밋 기술" 참조)와 같은 최적화 기능을 제공하여 기본 서버에서 사용되는 물리적 메모리 양을 줄인다. 어떤 경우에는 이러한 최적화가 오버헤드에 의해 차지하는 메모리보다 더 많은 메모리를 절약할 수 있다.

메모리 사이징

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

    • 가상 머신에서 실행할 애플리케이션 작업 세트를 보관하기에 충분한 메모리를 할당해서, 스레싱(thrashing)을 최소화해야 한다. 스레싱은 성능에 극적으로 영향을 미칠 수 있기 때문에 메모리 할당량이 부족하지 않도록 하는 것이 매우 중요하다.
    • 반면에 메모리 과다할당의 성능 영향은 메모리 과소할당보다 훨씬 덜하지만, 그럼에도 불구하고 당신은 상당한 과다분할을 피해야 한다.

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

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

메모리 오버 커밋 기술

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

    • 페이지 공유(Page Sharing): ESXi는 소유 기술을 사용하여 가상 시스템 간에 메모리 페이지를 투명하게 공유해서, 메모리 페이지의 중복 복사본을 제거할 수 있다. 페이지가 가상 시스템 내에서 기본적으로 공유되는 반면, vSphere 6.0 페이지는 더 이상 가상 시스템 간에 기본적으로 공유되지 않는다.
      대부분의 환경에서는 이러한 변화가 거의 영향을 미치지 않아야 한다. 메모리 사용량에 영향을 미칠 수 있는 환경에 대한 자세한 내용과 원하는 경우 이전 기본 동작을 실행하는 방법에 대한 지침은 "Memory Page Sharing"를 참조하기 바란다.
    • 풍선(Ballooning): 호스트 메모리가 부족해지기 시작하고 가상 시스템의 메모리 사용량이 메모리 대상에 접근하면 ESXi는 벌룬을 사용하여 해당 가상 시스템의 메모리 요구량을 줄인다. 게스트 운영 체제에 설치된 VMware에서 제공하는 vmmemctl 모듈을 VMware Tools 제품군의 일부로 사용하면 ESXi를 통해 게스트 운영 체제가 가장 가치가 낮다고 생각되는 메모리 페이지를 포기하게 할 수 있다. 풍선은 유사한 메모리 제약 조건 하에서 네이티브 시스템과 밀접하게 일치하는 성능을 제공한다. 벌룬을 사용하려면 게스트 운영 체제를 충분한 스왑 공간으로 구성해야 한다.
    • 메모리 압축(Memory Compression): 가상 시스템의 메모리 사용량이 호스트 수준 스와핑이 필요한 수준에 근접하면 ESXi는 메모리 압축을 사용하여 스왑 아웃해야 할 메모리 페이지 수를 줄인다. 압축 해제 대기 시간이 스왑 인 지연 시간보다 훨씬 작기 때문에 메모리 페이지를 압축하면 해당 페이지를 스왑 아웃하는 것보다 성능에 미치는 영향이 훨씬 적다.
    • 호스트 캐시로 스왑: 메모리 압축이 가상 시스템의 메모리 사용량을 충분히 낮게 유지하지 못하면 ESXi는 다음으로 호스트 수준 스와핑을 사용하여 호스트 캐시로의 메모리를 강제로 재확보할 수 있다(구성된 경우). 호스트 캐시로 스왑은 사용자가 SSD 스토리지에 특수 스왑 캐시를 구성할 수 있는 기능이다. 대부분의 경우 이 호스트 캐쉬(SSD에 있는 경우)는 일반 스왑 파일(일반적으로 하드 디스크 스토리지에 있는 경우)보다 훨씬 빨라져 액세스 지연 시간을 크게 줄일 수 있다. 따라서 ESXi 스왑 아웃되는 페이지 중 일부가 활성 상태일 수 있지만 호스트 캐시로 스왑하면 일반적인 호스트 수준 스왑보다 성능에 미치는 영향이 훨씬 적다.
    • 정규 호스트-레벨 스왑: 호스트 캐시가 꽉 차거나 호스트 캐시가 구성되지 않은 경우 ESXi는 다음에 페이지를 일반 스왑 파일로 스왑 아웃하여 가상 시스템에서 메모리를 회수할 것이다. 호스트 캐시로 스왑과 마찬가지로 ESXi 스왑 아웃되는 페이지 중 일부가 활성 상태일 수 있다. 그러나 호스트 캐시로 스왑하는 것과 달리 이 메커니즘은 액세스 지연이 높기 때문에 가상 시스템 성능이 크게 저하될 수 있다.(이 스와핑은 게스트 운영 체제의 제어 하에 가상 시스템 내에서 발생할 수 있는 스와핑과는 구별된다는 점에 유의하십시오.

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

    • ESXi에서는 페이지 공유, 벌루닝, 메모리 압축 및 호스트 캐쉬로의 스왑을 사용하여 상당한 메모리 오버 커밋을 허용하지만, 일반적으로 성능에 거의 영향을 미치지 않거나 전혀 영향을 미치지 않는 경우, 활성 메모리 페이지를 스왑하는 데 일반 호스트 수준 스와핑이 사용될 정도로 메모리를 오버커밋하지 않도록 해야 한다.

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

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

    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 간 페이지 공유를 활성화할 수 있다.

  • ESXi 호스트의 모든 가상 시스템 간에 VM 간 페이지 공유를 사용하도록 설정하려면 호스트 구성 옵션 Mem.ShareForceSalting을 0으로 설정한다. 이는 vSphere 6.0 이전 버전의 원래 기본 동작을 복제한다.

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

  • 구성 옵션 sched.mem.pshare.salt를 사용하여 가상 시스템의 .vmx 파일에 salt 값을 수동으로 지정한다. 이 옵션을 사용하면 salt 값이 동일한 가상 시스템 풀을 생성할 수 있으므로 해당 풀의 다른 가상 시스템과 메모리 페이지를 공유할 수 있다.
    원하는 경우 환경의 모든 가상 시스템에 대해 동일한 salt 값을 구성해서 효과적으로 단일 페이지 공유 풀을 생성할 수 있다(이전 버전의 vSphere의 기본 동작을 복제함).

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

메모리 스왑 최적화

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

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

  • ESXi에서는 페이지 공유, 벌루닝 및 메모리 압축을 사용하여 호스트 수준의 메모리 스와핑의 필요성을 줄이므로 이러한 기술을 사용하지 않도록 설정하지 않는다.
  • ESXi에서 메모리를 오버커밋하도록 선택한 경우 ESXi 시스템에 스왑 공간이 충분한지 확인한다. 가상 시스템의 전원을 처음 켤 때 ESXi는 가상 시스템의 구성된 메모리 크기와 메모리 예약 간의 차이와 동일한 크기의 가상 시스템에 대한 스왑 파일을 생성함 따라서 사용 가능한 디스크 공간은 최소한 이 정도여야 한다("메모리 오버헤드"에 설명된 대로 VMX 스왑에 필요한 공간도 포함).
  • 호스트 캐시로의 스왑 기능에 사용할 SSD(설치된 경우)로 특수 호스트 캐시를 선택적으로 구성할 수 있다. 이 스왑 캐시는 호스트에서 실행 중인 모든 가상 시스템에서 공유되며, 가장 활성 상태인 페이지의 호스트 수준 스와핑은 SSD의 짧은 지연 시간을 통해 이점을 얻을 수 있다. 이를 통해 비교적 적은 양의 SSD 스토리지로 잠재적으로 상당한 성능 향상이 가능하다.

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

  • 오버 커밋된 호스트가 호스트 캐시로 스왑을 사용하더라도 일반 스왑 파일을 생성해야 한다. 그러나 호스트 캐시로 스왑하면 일반 스왑 파일이 저장되는 스토리지 속도가 훨씬 덜 중요하게 된다.
    호스트가 호스트 캐시로 스왑을 사용하지 않고 메모리가 스레싱될 정도로 오버 커밋되어 가상 시스템 스왑 파일을 짧은 지연 시간에 배치하면 고대역폭 스토리지 시스템이 스와핑으로 인한 성능 영향을 최소화할 수 있다.
  • 가장 좋은 선택은 대개 로컬 SSD일 것이다.

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

  • 호스트에 로컬 SSD가 없다면 두 번째 선택은 원격 SSD일 것이다. 이렇게 하면 원격 액세스에 대한 지연 시간이 추가되지만 SSD의 대기 시간이 짧을 수 있다.
  • SSD 스토리지를 사용할 수 없는 경우 일반 스왑 파일을 가장 빠른 가용 스토리지에 저장한다. Fibre Channel SAN 어레이 또는 고속 로컬 디스크일 수 있다.
  • 로컬 스토리지(SSD 또는 하드 드라이브)에 스왑 파일을 배치하면 vMotion 성능이 저하될 수 있다. 이는 가상 시스템에 메모리 페이지가 로컬 스왑 파일에 있는 경우 해당 가상 시스템에서 vMotion 작업을 계속하려면 가상 시스템을 메모리로 스왑 인해야 하기 때문이다.
  • 일반 스왑 파일에 사용되는 스토리지 유형이나 위치에 관계없이 최상의 성능을 발휘하고 공간이 부족해질 가능성을 피하기 위해 스왑 파일을 씬 프로비저닝 스토리지에 배치해서는 안 된다.

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

그러나 리소스 예약을 구성하면 시스템에서 실행할 수 있는 가상 시스템의 수가 감소한다는 점에 유의해야 한다. 이는 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을 참조하기 바란다.