ESXi 네트워킹 고려사항

이 하위 섹션은 ESXi의 네트워킹 고려 사항에 대한 지침을 제공한다.

일반적인 ESXi 네트워킹 고려 사항

  • 네이티브 환경에서는 CPU 활용도가 네트워크 처리량에 큰 역할을 한다. 높은 수준의 처리량을 처리하려면 더 많은 CPU 리소스가 필요하다. 가상화된 워크로드의 네트워크 처리량에 대한 CPU 리소스 가용성의 영향은 훨씬 더 크다. CPU 자원이 부족하면 최대 처리량이 제한되기 때문에 높은 처리량 워크로드의 CPU 활용도를 모니터링하는 것이 중요하다.
  • 물리적 NIC를 여러 소비자(즉, 가상 시스템 및/또는 vmkernel)가 공유하는 경우 이러한 각 소비자는 다른 사용자의 성능에 영향을 미칠 수 있다. 그러므로 최상의 네트워크 성능을 위해서는 무거운 네트워킹 I/O를 사용하는 소비자(다른 소비자의 네트워크 성능을 감소시킬 수 있기 때문에)와 지연 시간에 민감한 워크로드를 가진 소비자(다른 소비자의 영향을 더 많이 받을 수 있기 때문에)에는 별도의 물리적 NIC를 사용하십시오.
    10Gb/s 이상의 NIC는 멀티 큐 지원을 제공하므로 이러한 소비자를 다른 대기열로 분리할 수 있다. 따라서 이러한 고속 NIC에 사용 가능한 대기열이 충분한 한 이 권장 사항은 일반적으로 해당 NIC에 적용되지 않는다.
    또한 NetIOC(아래 설명)를 사용하여 트래픽의 특정 클래스에 대한 대역폭을 예약할 수 있으며, 서로 다른 흐름 간의 리소스 격리를 제공할 수 있다. 이 기능은 어떤 속도의 NIC에도 사용할 수 있지만, 10Gb/s 및 고속 NIC에 특히 유용하다. 이러한 NIC는 여러 소비자가 더 자주 공유하기 때문이다.
  • 동일한 ESXi 시스템에 있는 두 가상 시스템 간에 네트워크 연결을 설정하려면 두 가상 시스템을 동일한 가상 스위치에 연결하십시오. 가상 시스템이 서로 다른 가상 스위치에 연결되어 있으면 트래픽이 와이어를 통과하여 불필요한 CPU 및 네트워크 오버헤드를 발생시킨다.

Network I/O Control (NetIOC)

Network I/O Control(NetIOC)을 통해 네트워크 리소스 풀에 네트워크 대역폭을 할당할 수 있다. 미리 정의된 9개의 리소스 풀(관리 트래픽, Fault Tolerance 트래픽, iSCSI 트래픽, NFS 트래픽, vSAN 트래픽, vMotion 트래픽, vSphere Replication(VR) 트래픽, vSphere Data Protection Backup 트래픽, 가상 시스템 트래픽) 중에서 선택하거나 사용자 정의 리소스 풀을 생성할 수 있다. 각 리소스 풀은 포트 그룹과 연결된다.

vSphere 6.0은 NetIOC 버전 2(NetIOCv2)에서처럼 물리적 어댑터 레벨이 아닌 전체 Distributed Switch 수준에서 대역폭을 할당하는 NetIOC 버전 3(NetIOCv3)을 도입했다. 이 책은 NetIOCv3만을 기술하고 있다.
vSphere 6.7에서 새 vSphere Distributed Switch를 생성할 때 해당 스위치는 기본적으로 NetIOCv3을 사용한다. 그러나 이전 ESXi 버전에서 업그레이드된 스위치는 NetIOCv3로 자동으로 업그레이드되지 않는 경우도 있다. 이에 대한 자세한 내용은 vSphere Networking for version 6.7을 참조하기 바란다.

NetIOC는 특정 요구에 대한 대역폭을 보장할 수 있으며, 한 리소스 풀이 다른 리소스 풀에 영향을 미치지 않도록 방지할 수 있다.

vSphere 6.0을 기준으로 DRS(VMware Distributed Resource Scheduler(DRS) 참조)가 호스트 간에 가상 시스템을 로드 밸런싱할 때 계산에 NetIOC 대역폭 예약을 포함하게 된다.

NetIOC에 대한 자세한 내용은 Performance Evaluation of Network I/O Control in VMware vSphere 6.0 and vSphere Networking for version 6.7를 참조하기 바란다.

Network I/O Control 구성

NetIOC를 사용하면 네트워크 대역폭을 리소스 풀뿐만 아니라 공유, 예약 또는 제한을 사용하여 개별 가상 NIC에 할당할 수 있다.

  • 공유는 네트워크 링크 대역폭의 일부를 총 공유에 대한 공유 비율에 상당하는 리소스 풀이나 가상 NIC에 할당하는 데 사용할 수 있다. 리소스 풀이나 가상 NIC가 전체 할당을 사용하지 않으면 사용되지 않은 대역폭을 동일한 물리적 NIC를 사용하는 다른 대역폭 소비자가 사용할 수 있다.
  • 대역폭 예약은 리소스 풀이나 가상 NIC에 대한 최소 대역폭(Mb/s)을 보장하는 데 사용할 수 있다. 총 대역폭 예약은 기본 물리적 어댑터 용량의 75%로 제한된다. 리소스 풀이나 가상 NIC가 전체 예약을 사용하지 않으면 사용되지 않은 대역폭을 동일한 물리적 NIC를 사용하는 다른 대역폭 소비자에게 사용할 수 있다.
  • Limits는 리소스 풀 또는 가상 NIC의 최대 대역폭 활용률(Mb/s 또는 Gb/s)을 특정 vDS(가상 Distributed Switch)를 통해 물리적 NIC 별로 설정하는데 사용된다. 이러한 Limits은 vDS가 포화 상태가 아닌 경우에도 적용되며, 잠재적으로 소비자의 대역폭을 제한하면서 동시에 일부 대역폭을 사용하지 않게 된다. 한편, 소비자의 대역폭 활용률이 제한치보다 낮을 경우, 사용하지 않은 대역폭은 동일한 물리적 NIC를 사용하는 다른 대역폭 소비자에게 이용 가능하다.

Network I/O Control 고급 성능 옵션

vSphere 6.5에 도입된 옵션인 HClock Multiqueue는 작은 패킷과 높은 패킷 속도가 있는 일부 환경에서 성능을 향상시킬 수 있다. 기본적으로 사용하지 않도록 설정된 이 옵션은 여러 가상 NIC 또는 여러 vmknic가 단일 물리적 NIC의 여러 하드웨어 전송 대기열에 트래픽을 분산할 수 있도록 허용한다.

ESXi 호스트에 대해 다음과 같이 이 옵션을 사용하도록 설정하고 구성할 수 있다:

  1. 다음 명령을 실행해서 HClock Multiqueue를 활성화한다 : esxcli system settings advanced set -i n -o /Net/NetSchedNetSchedHClkMQ
    (n의 값이 1이면 기능이 활성화되고 0이면 형상이 비활성화된다.)
  2. 다음 명령을 실행하여 HClock이 사용할 최대 대기열 수를 구성한다: esxcli system settings advanced set -i n -o /Net/NetSchedHClkMaxHwQueue
    (여기서 n은 최대 대기열 수이며, 기본값은 2).
  3. ESXi 호스트에서 각 물리적 NIC를 다운시켰다가, 다시 업한다:
    esxcli network nic down -n vmnicX esxcli network nic up -n vmnicX
    (여기서 X는 명령이 적용되는 vmnic를 구분한다).

DirectPath I/O

vSphere DirectPath I/O는 게스트 운영 체제가 하드웨어 디바이스에 직접 액세스할 수 있도록 Intel VT-d 및 AMD-Vi 하드웨어 지원("하드웨어 지원 I/O MMU 가상화(VT-d 및 AMD-Vi" 참조)을 활용한다. 네트워킹의 경우 DirectPath I/O를 통해 가상 시스템이 에뮬레이션된 디바이스(예: E1000) 또는 반가상화된 디바이스(예: VMXNET 또는 VMXNET3)를 사용하는 대신 물리적 NIC에 직접 액세스할 수 있다. DirectPath I/O는 처리량을 제한적으로 증가시키지만 네트워킹 집약적인 워크로드의 CPU 비용을 절감한다.

DirectPath I/O는 vMotion, 물리적 NIC 공유, 스냅샷, 일시 중단/재개, Fault Tolerance, NetIOC, 메모리 오버 커밋, VMSafe 또는 NSX 네트워크 가상화와 호환되지 않는다.

일반적인 가상 시스템과 해당 워크로드에는 DirectPath I/O를 사용할 필요가 없다. 그러나 네트워킹이 매우 많고(특히 패킷 속도가 높은 워크로드) 위에서 언급한 핵심 가상화 기능이 필요하지 않은 워크로드의 경우 DirectPath I/O가 CPU 사용량을 줄이는 데 유용할 수 있다.

Single Root I/O Virtualization (SR-IOV)

vSphere는 하드웨어 디바이스에 대한 게스트 직접 액세스의 새로운 모드인 SR-IOV(단일 루트 I/O 가상화)를 지원한다. SR-IOV에는 Intel VT-d 또는 AMD-Vi 하드웨어 지원("하드웨어 지원 I/O MMU 가상화(VT-d 및 AMD-Vi)"에 설명되어 있음) 외에 BIOS, 물리적 NIC, 네트워크 드라이버 지원도 필요하다. 지원되는 구성에 대한 자세한 내용은 6.7 버전의 vSphere Networking을 참조하기 바란다.

SR-IOV는 DirectPath I/O와 유사한 성능 이점 및 트레이드오프를 제공한다. SR-IOV는 패킷 속도가 매우 높거나 지연 시간이 매우 짧은 워크로드에서 유용하다. DirectPath I/O와 마찬가지로 SR-IOV도 vMotion과 같은 특정 핵심 가상화 기능과 호환되지 않는다(자세한 내용은 "DirectPath I/O"에서 Cisco UCS 플랫폼 이외의 하드웨어에 대한 호환성 목록을 참조하십시오). 그러나 SR-IOV는 단일 물리적 디바이스를 여러 게스트 간에 공유할 수 있도록 허용한다.

SplitRx 모드

SplitRx 모드는 단일 네트워크 대기열에서 수신된 네트워크 패킷을 처리하기 위해 여러 물리적 CPU를 사용한다.
이 기능은 특정 워크로드의 네트워크 성능을 크게 향상시킬 수 있다. 이러한 워크로드에는 다음이 포함된다.

  • 하나의 ESXi 호스트에 있는 여러 가상 시스템이 모두 동일한 소스에서 멀티캐스트 트래픽을 수신하고 있다.
    (SplitRx 모드는 일반적으로 이러한 워크로드의 처리량과 CPU 효율성을 향상시킬 것이다.)
  • 동일한 ESXi 호스트에 있는 두 가상 시스템 간의 vNetwork Appliance(DVFilter) API를 통한 트래픽
    (SplitRx 모드는 일반적으로 이러한 워크로드의 처리량과 최대 패킷 속도를 향상시킬 것이다.)

SplitRx 모드는 위에서 설명한 대로 네트워크 트래픽이 물리적 NIC를 통해 들어오는 경우에만 자동으로 사용하도록 설정되며, 트래픽이 ESXi 호스트 내부에만 적용되는 것은 아니다. 그러나 트래픽이 완전히 내부인 경우, "개별 가상 NIC에 대해 SplitRx 모드 사용 또는 사용 안 함"에 설명된 대로 SplitRx 모드를 수동으로 사용하도록 설정할 수 있다.

전체 ESXi 호스트에 대해 SplitRx 모드 비활성화

NetSplitRxMode 변수를 사용하면 ESXi 호스트 전체에서 이 자동 동작을 사용하지 않도록 설정할 수 있다.

이 변수에 대해 가능한 값은 다음과 같다.

  • NetSplitRxMode = "0"
    이 값은 ESXi 호스트에 대해 splitRx 모드를 사용하지 않도록 설정함
  • NetSplitRxMode = "1"
    이 값(기본값)은 ESXi 호스트에 대해 splitRx 모드를 사용하도록 설정함.

vSphere Client를 통해 이 변수를 변경하려면:

  1. 변경할 ESXi 호스트를 선택한다.
  2. Configure 탭에서 System을 확장한 다음 Advanced System 설정을 누른다.
  3. 오른쪽 상단 모서리에 있는 Edit을 누른다.
  4. NetSplitRxMode를 찾는다(Net.NetSplitRxMode 아래).
  5. 변경할 값을 클릭하고 원하는 대로 구성한다.
  6. OK를 눌러 Edit Advanced System Settings 창을 닫는다.

변경 사항은 즉시 적용되며 ESXi 호스트를 다시 시작할 필요가 없다.

개별 가상 NIC에 대해 SplitRx 모드 활성화 또는 비활성화

또한 각 가상 시스템의 .vmx 파일에 있는 ethernetX.emuRxMode 변수를 사용하여 각 가상 NIC(글로벌 NetSplitRxMode 설정 재정의)에 대해 SplitRx 모드 기능을 개별적으로 구성할 수 있다(여기서 X는 네트워크 어댑터의 ID로 대체됨).

이 변수에 대해 가능한 값은 다음과 같다.

  • ethernetX.emuRxMode = "0"
    이 값은 ethernetX의 splitRx 모드를 비활성화한다.
  • ethernetX.emuRxMode = "1"
    이 값은 ethernetX에 splitRx 모드를 활성화한다.

vSphere Client를 통해 이 변수를 변경하려면:

  1. 변경할 가상 시스템을 마우스 오른쪽 버튼으로 누른 다음 Edit Settings을 선택한다.
  2. VM Options 탭에서 Advanced을 확장한 다음 EDIT CONFIGURATION을 누른다.
  3. ethernetX.emuRxMode(여기서 X는 원하는 NIC의 수)를 찾아 원하는 대로 구성한다. 변수가 없는 경우 ADD CONFIGURATION PARAMS를 클릭하고 새 매개 변수로 입력한다.
  4. OK를 눌러 Configuration Parameters 창을 닫는다.
  5. OK를 눌러 Edit Settings 창을 닫는다.

변경 내용은 가상 시스템이 다시 시작되거나 관련 vNIC가 가상 시스템에서 연결이 끊어졌다가 다시 연결될 때까지 적용되지 않는다.

Receive Side Scaling (RSS)

RS(Receive Side Scaling)는 단일 NIC의 네트워크 패킷을 여러 개의 하드웨어 대기열을 생성하여 여러 CPU에 병렬로 스케줄링할 수 있는 기능이다. 이는 패킷을 높은 속도로 수신하는 NIC의 네트워크 처리량을 증가시킬 수 있지만 CPU 오버헤드도 증가시킬 수 있다.

특정 10Gb/s 또는 40Gb/s 이더넷 물리적 NIC를 사용하는 경우 ESXi는 물리적 NIC의 RSS 기능을 가상 NIC에서 사용할 수 있도록 허용한다. 이는 단일 MAC 주소가 대량의 네트워크 트래픽(예: VXLAN 또는 네트워크 집약적 가상 어플라이언스)을 얻는 환경에서 특히 유용할 수 있다.

CPU 오버헤드가 증가할 가능성이 있기 때문에 이 기능은 기본적으로 사용하지 않도록 설정되어 있다.

이 기능을 다음과 같이 활성화할 수 있다.

  • Intel 82599EB SFI/SFP+ 10Gb/s NIC의 경우:
    vmkload_mod ixgbe RSS="4"를 실행해서 드라이버 로드
    여러 Intel 82599EB SFI/SFP+ 10Gb/s NIC에서 이 기능을 실행하려면 각 추가 NIC에 대해 쉼표로 구분된 4를 포함해서(예: 이러한 NIC 3개에서 이 기능을 사용하도록 설정하려면 vmkload_mod ixgbe RSS="4,4,4") 실행한다.
  • Mellanox Technologies MT27500 제품군 ConnectX-3 10Gb/s 또는 40Gb/s NIC의 경우:
    vmkload_mod nmlx4_en num_ring_per_rss_queue=4를 실행하여 드라이버 로드

    여러 MT27500 Family ConnectX-3 10Gb/s 또는 40Gb/s NIC에서 이 기능을 사용하도록 설정하려면 각 추가 NIC에 대해 쉼표로 구분된 4를 추가한다(예: 이러한 NIC 3개에서 이 기능을 사용하려면 vmkload_mod nmlx4_en num_ring_rss_queue=4,4,4).

vmkload_mod로 드라이버를 로드한 후 다음 명령을 사용하여 vmkdevmgr이 NIC를 다시 검색하도록 한다.
'kill -HUP "<vmkdevmgr의 pid>"'
(여기서 <vmkdevmgr의 pid>는 vmkdevmgr 프로세스의 프로세스 ID이다.)

  • 이 기능을 사용할 각 가상 시스템의 .vmx 파일에 ethernetX.pNicFeatures = "4"를 추가한다(여기서 X는 기능을 추가해야 하는 가상 네트워크 카드의 번호다).

가상 네트워크 인터럽트 병합

가상 네트워크 인터럽트 병합은 인터럽트 수를 줄여 CPU 활용률을 잠재적으로 낮출 수 있다. 이로 인해 네트워크 지연 시간이 증가할 수 있지만, 많은 워크로드가 수백마이크로초에서 몇 밀리초까지 추가 네트워크 지연 시간에 영향을 받지 않으며, 가상 네트워킹 오버헤드를 줄이면 단일 ESXi 호스트에서 더 많은 가상 시스템을 실행할 수 있다.

기본적으로 이 기능은 ESXi의 모든 가상 NIC에 대해 사용하도록 설정된다. 그러나 VMXNET3 가상 NIC의 경우 이 기능을 세 가지 구성 방식 중 하나로 설정하거나 ethernetX.coalescingScheme 변수를 변경하여 사용하지 않도록 설정할 수 있다(여기서 X는 구성할 가상 NIC의 번호).

  • ethernetX.coalescingScheme 변수가 .vmx 파일에 없거나, 변수가 존재하여 rbc(요율 기반 병합의 약자)로 설정된 경우 기능이 활성화됨(기본값)
    이 경우 ethernetX.coalescingParams 변수를 사용하여 가상 네트워크 인터럽트 속도를 초당 인터럽트로 설정할 수 있다. 값은 100에서 10만 사이이며 기본값은 4000이다.
  • 이 기능은 가상 시스템을 중단하거나 ethernetX.coalescingScheme을 정적으로 설정하여 패킷을 전송하기 전에 미리 정의된 수의 패킷을 대기열에 넣도록 설정할 수 있다.
    이 경우 ethernetX.coalescingParams 변수를 사용하여 ESXi가 대기할 패킷 수를 설정할 수 있다. 값은 1에서 64까지이며 기본값은 64이다. 대기열 크기가 클수록 가상 시스템과 VMkernel 사이의 컨텍스트 스위치 수가 줄어들어 가상 시스템과 VMkernel 모두에서 CPU 활용률이 감소할 수 있다.
    그러나 대기 중인 패킷 수에 관계없이 ESXi는 인터럽트를 보내거나 패킷을 전송하기 전에 4밀리초 이내에 대기한다. 가상 시스템이 유휴 상태인 것과 같은 다른 이벤트도 가상 시스템 인터럽트 또는 패킷 전송을 트리거할 수 있으므로 패킷이 전체 4밀리초 동안 지연되는 경우는 거의 없다.
  • ethernetX.coalescingScheme을 adapt로 설정하여 이 기능을 adaptive로 설정할 수 있다. 이 설정은 가상 시스템 로드와 전체 시스템 로드 모두에 대한 인터럽트 속도를 기본으로 하며, 로드가 높을 때는 인터럽트 속도를 낮추고 로드가 낮을 때는 인터럽트 속도를 높인다.
  • ethernetX.coalescingScheme을 사용하지 않도록 설정하여 기능을 사용하지 않도록 설정할 수 있다. 이 기능을 비활성화하면 일반적으로 더 많은 인터럽트(따라서 더 높은 CPU 사용률)가 발생하지만, 일반적으로 네트워크 지연 시간이 감소한다.

vSphere Client를 통해 VMXNET3 가상 인터럽트 병합 구성 방법

  1. 변경할 가상 시스템을 마우스 오른쪽 버튼으로 누른 다음 Edit Settings을 선택한다.
  2. VM Options 탭에서, Advanced을 확장한 다음, EDIT CONFIGURATION을 누른다.
  3. 변경하고자 하는 변수를 찾아 설정한다.
    • 가상 인터럽트 병합 체계를 선택하는 경우 ethernetX.coalescingScheme(여기서 X는 구성할 가상 NIC의 번호)을 찾아 원하는 값으로 설정한다.
      변수가 없는 경우 ADD CONFIGURATION PARAM를 클릭하고 새 매개 변수로 입력한다.
    • 가상 네트워크 인터럽트 속도 또는 대기열 크기를 구성하는 경우 ethernetX.coalescingParams(여기서 X는 구성할 가상 NIC의 번호)를 찾아 원하는 값으로 설정한다.
      변수가 없는 경우 ADD CONFIGURATION PARAMS를 클릭하고 새 매개 변수로 입력한다.
  4. 확인을 눌러 Configuration Parameters 창을 닫으십시오.
  5. 확인을 눌러 설정 편집 창을 닫으십시오.

변경 내용은 가상 시스템을 다시 시작할 때까지 적용되지 않는다.

네트워크 지연 시간에 민감한 워크로드 실행

기본적으로 ESXi 네트워크 스택은 낮은 CPU 비용으로 높은 네트워크를 구동하도록 구성되어 있다. 이 기본 구성은 더 나은 확장성과 더 높은 통합 비율을 제공하지만, 네트워크 지연 시간이 더 길어질 가능성이 있다. vSphere는 네트워크 지연 시간에 매우 민감한 워크로드(즉, 대기 시간에 영향을 받는 워크로드)의 성능을 개선하기 위한 다양한 구성 옵션을 제공한다. 이 절에서는 이러한 옵션에 대해 설명한다. 이 항목에 대한 자세한 내용은 Best Practices for Performance Tuning of Latency-Sensitive Workloads in vSphere VMs을 위한 모범 사례를 참조하십시오.

  • 네트워크 지연 시간에 매우 민감한 특정 가상 시스템을 지정하십시오.
    vSphere를 사용하면 가상 시스템의 네트워크 지연 시간 감도를 High(기본값 Normal)으로 설정할 수 있다. 이로 인해 스케줄러는 가상 시스템의 각 vCPU에 대해 하나의 물리적 CPU 코어를 단독으로 할당하려고 시도하게 된다. 배정이 성공하면 네트워크 관련 대기 시간과 지터가 크게 줄어든다. 이는 또한 할당된 물리적 코어를 다른 가상 시스템이나 vmkernel 월드에서 더 이상 사용할 수 없음을 의미한다.
    네트워크 지연 시간 감도를 높게 설정할 때 다음과 같은 추가 중요 사항을 고려한다.
  • 가상 시스템에 대해 네트워크 지연 시간 감도를 높음으로 설정하기 전에 해당 가상 시스템의 메모리를 100% 예약해야 한다.
  • 100% CPU 예약을 미리 설정하여 가상 시스템에 사용하는 CPU 코어가 단독으로 할당되도록 할 수 있다.

가상 시스템이 버전 14 이전의 가상 하드웨어 버전을 사용하는 경우 지연 시간 감도를 높게 설정하기 위해 100% CPU 예약이 필요하지 않지만, 그렇게 하지 않으면 가상 시스템이 기존 CPU 오버 커밋으로 인해 물리적 CPU에 독점적으로 액세스하지 못할 수 있다.
가상 시스템이 가상 하드웨어 버전 14 이상을 사용하고 Latency-sensitivity=high, 100% CPU 예약은 실제로 전원을 켜기 위한 요구 사항이다. (이는 "latency.enforceCpuMin" = FALSE를 설정하여 변경할 수 있다.)

  • CPU 코어와 메모리 모두에 대한 예약과 Latency-sensitivity=high 설정은 vMotion을 사용하여 가상 시스템을 다른 호스트로 이동할 때 유지된다.
  • 메모리를 완전히 예약한다.
    Latency-sensitivity=high(위 설명과 같이)을 사용하기 위해 필요한 것 외에도, 메모리를 완전히 예약하면 해당 옵션이 설정되지 않은 경우에도 지연 시간을 줄이는 데 도움이 될 수 있다.
  • CPU를 완전히 예약한다.
    Latency-sensitivity=high가 안정적으로 작동할 수 있도록 허용하는 것 외에도, Latency-sensitivity=high 값을 설정하지 않아도 전체 CPU 예약을 하면 네트워크 지연 시간을 줄이는 데 도움이 될 수 있다.
  • Latency-sensitivity=high으로 설정되고 전체 CPU 예약이 있는 가상 시스템의 지연 시간 및 지터를 추가로 줄이기 위해 sched.cpu.latencySensitivity.sysContexts 옵션(Edit Settings > VM Options > Advanced > Edit Configuration)을 사용하여 관련 시스템 컨텍스트 전용 CPU 코어를 예약할 수도 있다.
    옵션이 없으면 추가할 수 있다. 이 옵션은 CPU 스케줄러가 이 VM과 관련하여 감지한 시스템 컨텍스트에 대해 단독으로 예약할 추가 코어의 수를 지정한다.
    시스템 컨텍스트에 대한 배타적 친화력은 최상의 기준으로 얻으며 자동으로 설정 해제될 수 있다.
  • 지연 시간에 민감한 트래픽에는 SR-IOV 또는 DirectPath I/O를 사용한다.
    VMXNET3 및 E1000과 같은 가상 네트워크 어댑터는 패킷당 몇 마이크로초의 순서에 따라 가상화 오버헤드를 발생시킨다. 이 오버헤드가 바람직하지 않고 특정 핵심 가상화 기능이 필요하지 않은 경우, DirectPath I/O("DirectPath I/O" 참조) 또는 SR-IOV("Single Root I/O Virtualization(SR-IOV) 참조"를 사용하여 가상 시스템에 네트워크 디바이스에 직접 액세스할 수 있도록 함으로써 네트워크 지연 시간을 줄일 수 있다. 어느 경우든 게스트의 디바이스 인터럽트 레이트를 조정할 것을 권장한다.
    VMXNET3 가상 네트워크 어댑터는 직접 디바이스 액세스를 사용할 수 없거나 바람직하지 않은 경우 최선의 선택이다("게스트 운영 체제 네트워킹 고려 사항" 참조).
  • 호스트 전원 관리 설정 조정
    최신 서버 하드웨어의 일부 전원 관리 기능은 네트워크 지연 시간을 증가시킬 수 있다. 원하는 경우 다음과 같이 비활성화할 수 있다.
  • ESXi 호스트 전원 정책을 최대 성능("ESXi의 호스트 전원 관리"에서 설명한 대로 최대 성능으로 설정하거나 BIOS에서 전원 관리를 사용하지 않도록 설정("전원 관리 BIOS 설정"에서 설명한 대로)).
  • BIOS에서 C1E 및 기타 C-상태 사용 안 함("전원 관리 BIOS 설정"에서 설명).
  • BIOS에서 Turbo Boost 활성화(20페이지의 "일반 BIOS 설정"에서 설명).
  • 가상 네트워크 어댑터 조정
    대부분의 범용 워크로드와 적당히 대기 시간에 민감한 워크로드의 경우 기본 설정으로 유지되는 VMXNET3 가상 네트워크 어댑터가 최상의 성능을 제공할 것이다. 패킷 속도가 낮거나 활성 스레드가 적은 워크로드에서는 원하는 NIC에 대해 VMXNET3 가상 인터럽트 병합 기능을 사용하지 않도록 설정하여 이점이 있을 수 있다. 다른 경우, 특히 많은 수의 네트워크 요청이 있는 워크로드의 경우 인터럽트 병합 기능을 사용하지 않도록 설정하면 성능이 저하될 수 있다.
    가상 인터럽트 병합에 대한 자세한 내용과 해당 구성을 변경하는 지침은 "가상 네트워크 인터럽트 병합"을 참조하기 바란다.

호스트-와이드 성능 조정

기본적으로 ESXi는 높은 통합 비율을 지원하면서도 모든 가상 시스템과 모든 개별 요청에 대해 좋은 응답 시간을 제공한다. 그러나 모든 응답 시간을 낮게 유지하는 것보다 평균 응답 시간을 낮게 유지하는 것이 더 중요한 시나리오가 있다. vSphere 6.0에 도입된 기능인 호스트 전체 성능 튜닝(밀도 모드라고도 함)을 통해 시스템 관리자는 매우 높은 통합 비율(기능이 없는 경우보다 최대 10% 더 높음)에 대해 개별 ESXi 호스트를 최적화할 수 있다.

밀도 모드(dense mode)를 사용하도록 설정한 경우 ESXi는 가상 시스템 수, vCPU 수 및 총 CPU 사용률을 모니터링하고, 세 가지 임계값(numVM >=numPCPU, numvCPU >=2 * numPCPU, CPUU=50)을 모두 초과하면 밀도 모드 최적화가 구현된다.

밀도 모드는 기본적으로 패킷을 다양한 지점에서 보다 공격적으로 배치한다. 이것은 주로 두 가지 일을 완수한다.

  • 패킷 처리를 위한 하이퍼바이저 오버헤드 감소
    하이퍼바이저 오버헤드가 낮으면 가상 머신에 더 많은 CPU 리소스가 남는다. 이는 CPU 활용도가 높을 때 평균 응답 시간이 예비 CPU 리소스의 가용성에 큰 영향을 받기 때문에 이로운 것이다.
  • 가상 시스템 실행 중단 횟수 감소
    중단 횟수를 줄이면 가상 시스템의 효율성이 높아질 수 있다.

밀도 모드는 패킷의 일괄 처리를 증가시키기 때문에 개별 요청의 지연 시간을 증가시킬 수 있다. 낮은 CPU 사용률 조건 또는 일부 가상 시스템이 불균형적으로 많은 양의 네트워크 처리량을 사용하는 경우, 밀도 모드를 사용하도록 설정하면 시스템 전체 처리량이 감소할 수 있다(단, 처리량 단위당 CPU 사용률은 감소함). 따라서 우리는 모든 호스트에서 단순하게 사용하도록 설정하는 것이 아니라 그 절충이 유용한 호스트에서만 밀도 모드를 사용하도록 설정할 것을 권장한다.

밀도 모드를 사용하거나 사용하지 않도록 설정하려면 vSphere Client(또는 esxcli)를 사용하여 다음과 같이 /Net/NetTuneHostMode 변수를 변경하십시오.

  • 밀도 모드 비활성화(기본 구성): /Net/NetTuneHostMode = "default"
  • 밀도 모드 활성화: /Net/NetTuneHostMode = "dense"

밀도 모드가 활성화된 경우에도 호스트의 통합 비율과 CPU 활용률이 위에서 설명한 임계값에 도달할 때만 밀도 모드 최적화가 구현된다.