게스트 운영 체제 일반 고려 사항

  • ESXi에서 지원하는 게스트 운영 체제 사용. 목록은 VMware 호환성 가이드를 참조하십시오(http://www.vmware.com/resources/compatibility 로 이동한 다음 What are you looking for: Guest OS 선택).

지원되지 않는 게스트 운영 체제에는 VMware Tools를 사용할 수 없을 수 있음

  • 게스트 운영 체제에 최신 버전의 VMware Tools를 설치한다. ESXi를 업그레이드할 때마다 VMware Tools를 업데이트한다.
    윈도우즈 게스트에 VMware Tools를 설치하면 게스트 운영 체제에 포함된 BusLogic SCSI 드라이버가 VMware에서 제공하는 드라이버로 업데이트된다. VMware 드라이버는 게스트에서 제공하는 Windows 드라이버가 제공하지 않는 최적화 기능을 가지고 있다.
    VMware Tools에는 ESXi의 메모리 재확보에 사용되는 벌룬 드라이버도 포함되어 있다. VMware Tools가 설치되어 있지 않으면 풍선 기능("메모리 오버 커밋 기술"에 설명됨)이 작동하지 않는다.
  • 가상 시스템에서 화면 보호기 및 창 애니메이션 사용하지 않는다. 리눅스에서는 X 서버를 사용할 필요가 없는 경우 사용하지 않도록 설정한다. 화면 보호기, 애니메이션 및 X 서버는 모두 추가 물리적 CPU 리소스를 사용하므로 통합 비율과 다른 가상 시스템의 성능에 영향을 미칠 수 있다.
  • 사용량이 적은 시간에 실행되도록 가상 시스템의 백업 및 바이러스 검사 프로그램 예약한다. 동일한 ESXi 호스트의 여러 가상 시스템에서 동시에 실행되도록 예약하지 않는다. 일반적으로 CPU 사용량을 CPU뿐만 아니라 시간에 따라 균등하게 배분하는 것이 좋다. 로드가 예측 가능한 백업 및 바이러스 검사와 같은 워크로드의 경우 작업을 적절하게 예약하여 쉽게 달성할 수 있다.
  • 가장 정확한 시간 유지를 위해 게스트 운영 체제를 NTP, 윈도우즈 시간 서비스, VMware Tools 시간 동기화 옵션 또는 운영 체제에 적합한 다른 시간 유지 유틸리티를 사용하도록 구성하는 것을 고려한다.

ESXi 5.0에 포함된 버전에서 VMware Tools 시간 동기화 옵션을 선택하는 것이 적합하다. ESXi 5.0 이전 버전은 동일한 수준의 정확도를 위해 설계되지 않았으며 호스트 시간보다 앞서 있을 때 게스트 시간을 조정하지 않는다.

그러나 특정 가상 머신 내에서 VMware Tools 시간 동기화 옵션 또는 다른 시간 유지 유틸리티를 사용할 것을 권장하지만 둘 다 사용할 수는 없다.

가상 머신 내 시간 유지에 대한 모범 사례에 대한 자세한 내용은 VMware KB 문서 1318 및 1006427을 참조한다.

Microsoft Virtualization-Based Security (VBS)

Microsoft VBS(가상화 기반 보안)는 Windows 10 및 Windows Server 2016에서 처음 사용할 수 있는 기능이다. 나머지 OS에서 메모리 일부를 분리하여 운영 체제 보안을 높이기 위해 가상화를 사용한다.

vSphere 6.7부터 시작하여 가상 하드웨어 버전 14를 사용하는 ESXi는 게스트 운영 체제에서 VBS를 지원할 수 있다. 그러나 VBS는 가상화를 사용하므로 가상화 계층 내의 가상화 계층("중첩 가상화"라고도 함)이 생성되어 성능에 영향을 미칠 수 있다.

VBS를 사용하여 최상의 성능을 얻으려면 다음 사항을 고려하십시오.

  • 게스트 OS에서 하이퍼바이저 기반 코드 무결성(Hypervisor-Based Code Integrity)을 사용할 경우, 기본 하드웨어에 Intel Kaby Lake 및 Sky Lake 프로세서에 도입된 기능인 Mode-Based Execution(MBX)가 있으면 성능이 향상될 수 있다.
  • Intel Haswell 프로세서에 도입된 기능인 VMCS 섀도는 중첩된 가상화의 영향을 감소시킨다.

가상 시스템의 성능 측정

가상 시스템 내에서 성능을 측정할 때 주의한다.

  • vSphere를 사용하면 가상화된 CPU 성능 카운터를 활용하여 게스트 운영 체제 내에서 성능 조정 툴을 사용할 수 있다. 자세한 내용은 vSphere 가상 시스템 관리 가이드를 참조하십시오.
  • 특히 프로세서가 오버 커밋된 경우 가상 머신 내에서 측정된 타이밍 값은 부정확할 수 있다.
  • 가상 머신 내에서 성능을 측정하면 ESXi에서 게스트 운영 체제에서 오프로드하는 작업에 사용하는 리소스와 가상화 오버헤드에 사용되는 리소스를 고려하지 못할 수 있다.
    vSphere Client, VMware Tools, esxtop 또는 resxtop과 같은 ESXi 수준의 도구를 사용하여 리소스 활용도를 측정하면 이러한 문제를 방지할 수 있다.

게스트 운영 체제 CPU 고려 사항

이 섹션에서는 게스트 운영 체제의 CPU 고려 사항을 다룬다.

  • SMP 가상 시스템에서 게스트 운영 체제는 vCPU 간에 프로세스를 마이그레이션할 수 있다. 이 마이그레이션은 작은 CPU 오버헤드를 초래할 수 있다. 마이그레이션이 매우 빈번한 경우 게스트 스레드 또는 프로세스를 특정 vCPU에 고정하는 것이 유용할 수 있음(이것은 필요한 것보다 많은 vCPU를 사용하는 가상 시스템을 구성하지 않는 또 다른 이유임).

게스트 운영 체제의 사이드 채널 취약점 완화

"사이드 채널 취약점(Side-Channel Vulnerabilities)"에서 설명한 것처럼 게스트 운영 체제에서 일부 사이드 채널 취약성에 대한 완화가 이루어진다. 이러한 완화는 심각한 보안 취약성을 해결하지만, 성능, 특히 CPU 리소스가 제한된 시스템에도 상당한 영향을 미칠 수 있다.

이러한 성능 영향이 사용자 환경에 문제가 될 수 있는 경우 하드웨어의 이러한 취약성 중 일부를 완화하는 최신 CPU를 선택하면 성능 저하를 줄일 수 있다("사이드 채널 취약성"에서 설명).

Virtual NUMA(vNUMA)

Virtual NUMA(vNUMA)는 게스트 운영 체제에 NUMA 토폴로지를 노출하여 NUMA 인식 게스트 운영 체제 및 애플리케이션이 기본 하드웨어의 NUMA 아키텍처를 가장 효율적으로 사용할 수 있도록 허용한다.

NUMA에 대한 자세한 정보는 "NUMA(Non-Uniform Memory Access, NUMA)"를 참조.

가상 하드웨어 버전 8 이상이 필요한 가상 NUMA는 게스트 운영 체제 및 애플리케이션의 NUMA 최적화 수준에 따라 이점이 크게 달라지지만, 경우에 따라 넓은 가상 머신에 상당한 성능 이점을 제공할 수 있다("NUMA(Non-Uniform Memory Access)"에서 정의).

  • 클러스터가 일치하는 NUMA 아키텍처를 가진 호스트로만 구성된 경우 vNUMA에서 최대의 성능 이점을 얻을 수 있다.
    vNUMA를 사용하도록 설정된 가상 시스템의 전원을 처음 켤 때 vNUMA 토폴로지는 vNUMA가 실행 중인 기본 물리적 호스트의 NUMA 토폴로지에 부분적으로 기반하여 설정되기 때문이다. 기본적으로 가상 시스템의 vNUMA 토폴로지가 초기화되면 해당 가상 시스템의 vCPU 수가 변경되지 않는 한 변경되지 않는다. 즉, vNUMA 가상 시스템을 다른 NUMA 토폴로지로 이동하면 가상 시스템의 vNUMA 토폴로지가 더 이상 기본 물리적 NUMA 토폴로지에 최적화되지 않아 성능이 저하될 수 있다.
  • 가상 시스템의 크기를 조정할 때 물리적 NUMA 노드의 크기를 고려한다.

일부 멀티 코어 프로세서에는 소켓당 코어 수와 다른 NUMA 노드 크기가 있다. 예를 들어, 일부 12코어 프로세서에는 프로세서당 2개의 6코어 NUMA 노드가 있다.

  • 최상의 성능을 위해 물리적 NUMA 노드 내에서 유지하도록 가상 시스템의 크기를 조정해 본다. 예를 들어 NUMA 노드당 6개의 코어가 있는 호스트 시스템이 있는 경우 vCPU가 6개 이하로 가상 시스템의 크기를 조정해 보십시오.
  • 가상 시스템이 단일 물리적 NUMA 노드보다 커야 하는 경우 가능한 적은 수의 물리적 NUMA 노드 간에 균등하게 분할될 수 있도록 가상 시스템의 크기를 조정한다.
  • 호스트의 물리적 프로세서 코어 수를 초과하는 vCPU 수가 있는 가상 시스템을 생성할 때 주의한다. 하이퍼 스레드는 논리적인 스레드로 간주되기 때문에, 때때로 허용되지만 사용될 때 잠재적으로 경합이 발생할 수 있다.
  • vSphere 6.5부터 소켓당 코어 수를 변경하면 더 이상 vNUMA 또는 vNUMA 토폴로지의 구성에 영향을 주지 않는다. 이제 vSocket과 corespersocket의 구성은 소프트웨어 라이센싱과 잠재적으로 관련이 있는 가상 프로세서의 게스트 OS에 대한 프레젠테이션에만 영향을 미친다. vNUMA는 기본 ESXi 호스트를 기반으로 게스트 OS에 표시할 적절한 vNUMA 토폴로지를 자동으로 결정한다.

예를 들어, vSphere 6.5 이전에는 소켓당 16개의 코어가 있는 듀얼 소켓 물리 ESXi 호스트에서 4개의 vSocket 가상 시스템을 생성하고 corespersocket을 4개의 vCPU(총 16개의 vCPU)로 설정한 경우, vNUMA는 corespersocket 설정을 기반으로 4개의 vNUMA 노드를 생성했을 것이다. vSphere 6.5 이상에서는 게스트 OS에 소켓 4개와 소켓당 코어 4개가 표시되지만, 이제 vNUMA는 가상 시스템을 단일 물리적 NUMA 노드에 배치할 수 있기 때문에 전체 가상 시스템에 대해 16코어 vNUMA 노드 1개만 생성하게 된다.

vNUMA에서 corespersocket 설정의 새로운 디커플링은 vSphere가 최상의 vNUMA 토폴로지를 자동으로 결정할 수 있도록 한다.

이 동작을 되돌리고 vNUMA 토폴로지를 직접 제어하려면 vSphere 6.7 Resource Management Guide의 "Virtual NUMA Controls" 섹션에 있는 numa.vcpu.followcorespersocket 설정한다.

  • 기본적으로 vNUMA는 vCPU가 8개 이상인 가상 시스템에 대해서만 사용하도록 설정된다. 그러나 이 기능은 ESXi에서 vNUMA 토폴로지를 자동으로 관리할 수 있도록 허용하면서 소규모 가상 시스템에 사용하도록 설정할 수 있다. 이는 vCPU가 8개 이하인 와이드(wide) 가상 시스템(즉, 각 물리적 NUMA 노드의 코어 수보다 vCPU가 많은 가상 시스템)에 유용할 수 있다.
    vCPU가 8개 이하인 가상 시스템에 대해 다음 줄을 추가하여 vNUMA를 사용하도록 설정할 수 있다.
    numa.vcpu.min = X
    여기서 X는 가상 시스템의 vCPU 수다.

vSphere Client를 통해 이 변수를 변경하려면:
1. 변경할 가상 시스템을 마우스 오른쪽 버튼으로 누른 다음 Edit Settings를 선택한다.
2. VM Options 탭에서 Advanced를 확장한 다음, EDIT CONFIGURATION을 누른다.
3. numa.vcpu.min을 찾아 원하는 대로 구성한다. 변수가 없는 경우 ADD CONFIGURATION PARAMS를 클릭하고 새 매개 변수로 입력하십시오.
4. OK를 눌러 Configuration Parameters 창을 닫는다.
5. OK를 눌러 Edit Settings를 닫는다.

또는 maxPerVirtualNode 옵션을 사용하여 가상 시스템의 vNUMA 토폴로지를 완전히 수동으로 제어할 수 있다. 자세한 내용은 vSphere 6.7 Resource Management Guide의 "Virtual NUMA Controls" 섹션을 참조하십시오.

  • CPU Hot Add는 실행 중인 가상 시스템에 vCPU를 추가할 수 있는 기능이다. 그러나 이 기능을 사용하도록 설정하면 해당 가상 시스템에 대해 vNUMA가 사용되지 않도록 설정되므로 게스트 OS에 단일 vNUMA 노드가 표시된다. vNUMA 지원이 없으면 게스트 OS는 ESXi 호스트의 CPU 및 메모리 가상 토폴로지에 대한 지식이 없다. 이로 인해 게스트 OS가 최적의 스케줄링 결정을 내리지 못해 대규모 가상 머신에서 실행되는 애플리케이션의 성능이 저하될 수 있다.
    이러한 이유로 CPU Hot Add를 사용하려는 경우에만 사용 가능으로 설정한다. 또는 vCPU를 추가하기 전에 가상 시스템의 전원을 끄거나 워크로드에 필요할 수 있는 최대 vCPU 수로 가상 시스템을 구성하게 계획한다. 후자 옵션을 선택할 경우 사용하지 않는 vCPU에 불필요한 오버헤드가 소량 발생한다는 점에 유의하십시오. 또한 사용하지 않는 vCPU는 게스트 OS가 가상 시스템 내에서 다시 성능 저하의 가능성을 가지고 잘못된 스케줄링 결정을 내릴 수 있다.
    자세한 내용은 VMware KB 문서 2040375를 참조하기 바란다.

게스트 운영 체제 메모리 고려 사항

"2MB 대용량 메모리 페이지"에 설명된 바와 같이 ESXi는 게스트 운영 체제에서 큰 메모리 페이지를 사용할 수 있도록 할 수 있다.

운영 체제나 애플리케이션이 네이티브 시스템의 대용량 페이지로부터 이익을 얻을 수 있는 경우, 해당 운영 체제나 애플리케이션은 2MB의 시스템 메모리 페이지를 지원하는 가상 시스템에서 유사한 성능 향상을 달성할 수 있다. 운영 체제 및 응용 프로그램의 설명서를 참조하여 각 운영 체제에서 대용량 메모리 페이지를 사용하도록 구성하는 방법을 확인하십시오.

게스트 운영 체제 스토리지 고려 사항

게스트 운영 체제에 제공되는 가상 스토리지 어댑터는 게스트 내의 디바이스 드라이버, 드라이버 설정 및 기타 요소와 마찬가지로 스토리지 성능에 영향을 줄 수 있다. 이 절에서는 이러한 고려사항을 다룬다.

  • 대부분의 게스트 운영 체제의 경우 ESXi 6.7의 기본 가상 스토리지 어댑터는 게스트 운영 체제 및 가상 하드웨어 버전에 따라 LSI Logic Parallel 또는 LSI Logic SAS다.
    그러나 ESXi에는 반가상화 SCSI 스토리지 어댑터인 PVSCSI(VMware 반가상화라고도 함)도 포함되어 있다. PVSCSI 어댑터는 기본 가상 스토리지 어댑터에 비해 CPU 활용률을 크게 낮추고 처리량을 잠재적으로 증가시킬 수 있으므로 I/O 집약적인 게스트 애플리케이션을 사용하는 환경에 가장 적합하다.

PVSCSI를 사용하려면 가상 시스템이 "ESXi 일반 고려 사항"에 설명된 대로 가상 하드웨어 버전 7 이상을 사용하고 있어야 한다.

PVSCSI 어댑터는 일부 운영 체제에서만 부팅 드라이브에 지원된다. 자세한 내용은 VMware KB 문서 1010398을 참조하십시오.

  • BusLogic Parallel 가상 SCSI 어댑터를 사용하도록 선택하고 윈도우즈 게스트 운영 체제를 사용하는 경우 VMware Tools 패키지에 포함된 사용자 지정 BusLogic 드라이버를 사용하십시오.
  • vSphere 6.5는 NVMe(Non-Volatile Memory Express) 가상 스토리지 어댑터(가상 NVMe 또는 vNVMe)를 도입했다. 이를 통해 네이티브 NVMe 드라이버를 포함하는 최신 게스트 운영 체제는 ESXi가 NVMe 스토리지를 사용하는지 여부에 관계없이 해당 드라이버를 사용하여 ESXi를 통해 스토리지에 액세스할 수 있다.
    vNVMe 가상 스토리지 어댑터는 대기 시간이 매우 짧은 플래시와 비휘발성 메모리 기반 스토리지에 맞게 설계되었기 때문에 느린 디스크 기반 스토리지에 적합하지 않다.
    PVSCSI와 비교하여 vNVMe 가상 스토리지 어댑터는 I/O당 IOPS 및 CPU 비용과 비슷하거나 더 우수하다. 가상 SATA 디바이스에 비해 vNVMe 가상 스토리지 어댑터는 I/O당 CPU 비용이 훨씬 낮고 IOPS가 상당히 높은 로컬 PCIe SSD 디바이스에 액세스한다.
  • 게스트 내의 디스크 파티션이 정렬되었는지 확인한다. 자세한 내용은 어레이 벤더의 권장 사항뿐만 아니라 사용할 적절한 도구에 대한 운영 체제 벤더의 설명서를 참조하십시오.
  • 스토리지 서브시스템에서 4KB 네이티브(4Kn) 또는 512B 에뮬레이션(512e) 드라이브를 사용하는 경우 워크로드가 대부분 4K 정렬 I/O를 발생시킬 경우 최고의 스토리지 성능을 얻을 수 있다. 이 주제에 대한 자세한 내용은 VMware KB 문서 2091600을 참조하거나 http://docs.vmware.com에서 "Device Sector Formats"을 검색한다.

게스트 운영 체제 네트워킹 고려 사항

가상 시스템이 처음 생성되면 ESXi에서 사용할 vNIC(가상 네트워크 어댑터)를 선택할 수 있다. 사용 가능한 옵션은 지정된 게스트 운영 체제와 가상 하드웨어 버전을 기반으로 한다. 일부 운영 체제에는 성능이 가장 뛰어난 가상 네트워크 어댑터를 위한 기본 제공 드라이버가 없기 때문에 사용 가능한 vNIC 목록에 항상 최상의 성능을 제공할 수 있는 드라이버가 포함되지 않을 것이다. 그러나 이러한 경우 드라이버는 나중에 게스트 운영 체제(일반적으로 VMware Tools의 일부로)에 설치되고 vNIC는 다른 유형으로 변경할 수 있다.

이 절에서는 vNIC의 다양한 유형, vNIC를 선택하는 방법 및 vNIC에서 최상의 성능을 얻는 방법을 설명한다.

가상 네트워크 어댑터 유형

가능한 가상 네트워크 어댑터에는 세 가지 에뮬레이션 유형, 세 가지 반가상화 유형 및 하이브리드 어댑터가 포함된다.
에뮬레이션된 가상 네트워크 어댑터

  • AMD 79C970 PCnet32 NIC을 에뮬레이트하는 Vlance 가상 네트워크 어댑터. 이 NIC의 드라이버는 대부분 32비트 운영 체제에서 찾을 수 있다.
  • Intel 82545EM NIC을 에뮬레이트하는 E1000 가상 네트워크 어댑터. 이 NIC의 드라이버는 많은 최신 운영 체제에서 찾을 수 있다.
  • Intel 82574 NIC를 에뮬레이트하는 E1000e 가상 네트워크 어댑터. 이 NIC의 드라이버는 최근 운영 체제의 일부에서 찾을 수 있다.

반가상화 네트워크 어댑터의 VMXNET 제품군은 대부분의 경우 에뮬레이션된 어댑터보다 더 나은 성능을 제공한다. 이러한 반가상화된 네트워크 어댑터는 최소한의 오버헤드로 가상 시스템과 물리적 네트워크 인터페이스 카드 사이의 네트워크 트래픽을 전달하는 이상적인 네트워크 인터페이스를 구현한다. VMXNET 가상 네트워크 어댑터(특히 VMXNET3)는 다른 가상 네트워크 어댑터에서도 찾을 수 없는 성능 기능도 제공한다. VMXNET 제품군 어댑터용 드라이버는 ESXi에서 지원하는 많은 게스트 운영 체제에서 사용할 수 있으며, 최적의 성능을 위해 이러한 어댑터를 지원하는 모든 게스트 운영 체제에 사용해야 한다.

VMXNET 제품군:

  • VMXNET 가상 네트워크 어댑터.
  • VMXNET2 가상 네트워크 어댑터("Enhanced VMXNET"이라고도 함). 이 어댑터는 VMXNET 어댑터를 기반으로 다양한 성능 기능을 추가한다.
  • VMXNET3 가상 네트워크 어댑터(VMXNET Generation 3이라고도 함). 이 어댑터는 VMXNET2의 모든 기능과 몇 가지 새로운 기능을 갖추고 있다.

마지막으로 하이브리드 가상 네트워크 어댑터:

  • Vlance 어댑터를 에뮬레이션하기 시작하지만 올바른 드라이버가 있는 VMXNET 어댑터로 작동할 수 있는 유연한 가상 네트워크 어댑터.

경우에 따라 가상 네트워크 어댑터 옵션에는 SR-IOV 패스스루가 포함된다. 이 기능에 대한 자세한 내용은 "SR-IOV(단일 루트 I/O 가상화)"를 참조하기 바란다.

가상 시스템에서 게스트 네트워크 드라이버가 보고한 네트워크 속도는 기본 물리적 네트워크 인터페이스 카드의 실제 속도를 반영하지 않는다. 예를 들어 ESXi가 에뮬레이션하고 있는 AMD PCnet 카드가 10Mb/s 디바이스이기 때문에 가상 시스템의 Vlance 게스트 드라이버는 10Mb/s의 속도를 보고한다. 서버의 물리적 카드가 100Mb/s, 1Gb/s 이상이어도 그렇다. 그러나 ESXi는 이 상황에서 10Mb/s로 제한되지 않으며 물리적 서버 시스템의 리소스가 허용하는 한 네트워크 패킷을 전송한다.

가상 네트워크 어댑터에 대한 자세한 내용은 VMware KB 문서 1001805 및 Virtual Machine Administration for vSphere 6.7을 참조하기 바란다.

가상 네트워크 어댑터 선택

이 절에서는 최적의 성능을 위해 가상 네트워크 어댑터를 선택하는 방법을 설명한다.

  • 최적의 성능을 위해 지원되는 운영 체제에 VMXNET3 반가상화 네트워크 어댑터를 사용하십시오. 이를 위해서는 가상 머신이 가상 하드웨어 버전 7 이상을 사용해야 하며 경우에 따라 게스트 운영 체제에 VMware Tools를 설치해야 한다.

Microsoft Windows에는 VMXNET3 드라이버가 포함되어 있지 않으므로 운영 체제 설치 중에 다른 가상 네트워크 어댑터(일반적으로 e1000e 또는 e1000)를 사용해야 한다. OS를 설치한 후 VMware Tools(VMXNET3 드라이버 포함)를 설치한 다음 VMXNET3 가상 네트워크 어댑터를 추가한다.

  • VMXNET3이 지원되지 않는 게스트 운영 체제의 경우 e1000e 가상 네트워크 어댑터를 사용하는 것이 권장된다.
  • e1000e가 옵션이 아닌 경우 flexible 장치 유형을 사용하십시오. ESXi에서 "flexible NIC"는 VMware Tools 제품군이 게스트 운영 체제에 설치되어 있고 운영 체제가 VMXNET을 지원하는 경우 각 Vlance 네트워크 디바이스를 VMXNET 디바이스("NIC Morping"이라고도 하는 프로세스)로 자동 변환한다.

가상 네트워크 어댑터 기능 및 구성

이 섹션에서는 다양한 가상 네트워크 어댑터 기능과 최적의 성능을 위해 어댑터를 구성하는 방법을 설명한다.

  • 동일한 ESXi 호스트에 있는 두 가상 시스템을 네트워킹할 때 동일한 vSwitch에 연결을 시도한다. 이러한 방식으로 연결될 때, 이들의 네트워크 속도는 물리적 네트워크 카드의 유선 속도에 의해 제한되지 않는다. 대신, 그들은 호스트 자원이 허용하는 한 빨리 네트워크 패킷을 전송한다.
  • E1000, E1000e, VMXNET2 및 VMXNET3 장치는 점보 프레임을 지원한다. 점보 프레임을 사용하면 더 크고 더 적은 패킷을 사용하여 데이터를 전송할 수 있다. 네트워크 트래픽에서 발생하는 CPU 로드의 대부분은 패킷당 오버헤드이기 때문에 패킷 속도가 낮으면 CPU 로드가 감소하여 성능이 향상될 수 있다.
    점보 프레임을 사용하도록 설정하려면 게스트 네트워크 드라이버와 가상 스위치 구성 모두에서 MTU 크기를 9000으로 설정하십시오. 양쪽 끝에 있는 물리적 NIC와 모든 중간 홉/라우터/스위치도 점보 프레임을 지원해야 한다.
  • ESXi TCP Segmentation Offload(TSO)는 VMkernel에서 기본적으로 사용하도록 설정되지만 가상 시스템에서 지원되는 것은 E1000 디바이스, E1000e 디바이스, VMXNET2 디바이스 또는 VMXNET3 디바이스를 사용하는 경우에만입니다. TSO는 기본 하드웨어가 TSO를 지원하지 않더라도 성능을 향상시킬 수 있다.
  • 이와 유사하게 ESXi에서 Large Receive Offload(LRO)는 VMkernel에서 기본적으로 사용하도록 설정되지만 VMXNET2 디바이스 또는 VMXNET3 디바이스를 사용하는 경우에만 가상 시스템에서 지원된다. LRO는 기본 하드웨어가 LRO를 지원하지 않더라도 성능이 향상될 수 있다.

LRO 지원은 운영 체제에 따라 다르다. 많은 리눅스 변형 모델들이 LRO를 지원한다. 윈도우즈 가상 시스템에서 LRO는 다음과 같은 필수 구성 요소가 충족될 때 지원된다:

  • 가상 시스템은 가상 하드웨어 버전 11 이상을 사용한다.
  • 가상 시스템은 VMXNET3 디바이스를 사용한다.
  • 가상 시스템에서 윈도우즈 Server 2012 이상 또는 윈도우즈 8.0 이상을 실행하고 있다.
  • 게스트 운영 체제에서 VMXNET3 vNIC 드라이버 버전 1.6.6.0 이상을 사용한다.
  • 게스트 운영 체제에서 Receive Segment Coalescing(RSC)를 전체적으로 사용하도록 설정한다.

LRO 구성에 대한 자세한 내용은 vSphere Networking for vSphere 6.7에서 "Large Receive Offload"를 검색하기 바란다.

  • 가상 머신의 수신 처리량이 낮은 것은 수신기 네트워크 디바이스의 수신 버퍼(과잉 수신 링이라고도 함)가 부족하기 때문일 수 있다. 게스트 운영 체제의 네트워크 드라이버에 있는 수신 버퍼가 충분하지 않으면 VMkernel에 패킷이 손실되어 네트워크 처리량이 저하된다. 가능한 해결 방법은 호스트 물리적 CPU 워크로드를 증가시킬 수 있지만 수신 버퍼의 수를 늘리는 것이다.
    VMXNET의 경우 기본 수신 및 전송 버퍼 수는 각각 100개, 최대값은 128개 입니다. VMXNET2의 경우 기본 수신 버퍼 수는 각각 150개와 256개로, 가능한 최대 수신 버퍼는 512개 입니다. 영향을 받는 가상 시스템의 .vmx(구성) 파일에서 버퍼 크기 기본값을 변경하여 이러한 설정을 변경할 수 있다. 자세한 내용은 VMware KB 문서 1010071을 참조하기 바란다.
    E1000, E1000e, VMXNET3의 경우 기본 수신 및 송신 버퍼 수는 게스트 드라이버에 의해 제어되며, 이 버퍼의 최대 수는 모두 4096개일 수 있다. Linux에서는 이러한 값을 ethtool을 사용하여 게스트 내에서부터 변경할 수 있다. 윈도우즈에서는 디바이스 속성 창의 게스트 내에서 값을 변경할 수 있다. 자세한 내용은 VMware KB 문서 1010071을 참조하기 바란다.
  • 여러 개의 수신 및 전송 대기열(흔히 receive-side scaling(RSS) 또는 scalable I/O라고 함)을 통해 단일 NIC의 네트워크 패킷을 여러 CPU에서 병렬로 스케줄링할 수 있다. 다중 대기열이 없으면 네트워크 인터럽트는 한 번에 하나의 CPU에서만 처리할 수 있다. 다중 대기열은 단일 CPU가 네트워크 패킷 처리에 포화되어 병목 현상이 되는 경우에 처리량을 돕는다. 순서가 맞지 않는 패킷 전달을 방지하기 위해 드라이버는 모든 흐름의 패킷을 동일한 CPU로 스케줄링한다.
    E1000e 및 VMXNET3 디바이스는 윈도우즈 Server 2003 SP2 이상, 윈도우즈 7 이상 및 일부 Linux 배포를 포함하여 이 기능을 기본적으로 지원하는 많은 게스트 운영 체제에 대해 다중 대기열을 지원한다.
    Linux 커널 2.6.37 이상에 포함된 VMXNET3 드라이버와 마찬가지로 vSphere 5.0 이상 버전의 VMware Tools에 포함된 VMXNET3 드라이버는 기본적으로 여러 개의 수신 대기열을 사용하도록 설정되어 있다. 자세한 내용은 VMware KB 문서 2020567을 참조하십시오.
    여러 수신 대기열을 사용하도록 설정하면 기능은 기본적으로 가상 시스템에서 1, 2, 4, 8개의 대기열을 구성하여 해당 가상 시스템의 vCPU 수보다 작거나 같은 값 중 가장 큰 값을 선택하십시오.
    Windows와 Linux 모두에서 기본적으로 전송 대기열의 수는 수신 대기열의 수와 동일하다.
    특정 워크로드 및 리소스 가용성으로 최대의 성능을 얻으려면 수신 대기열 수(2의 배수로 설정되어야 하며 최대 8 또는 vCPU 수 중 낮은 값으로 설정되어야 함)에 대해 다른 값을 사용해 본다. 이 설정은 게스트 운영 체제 내의 고급 드라이버 구성 탭에서 변경된다.