Performance Best Practices for VMware vSphere 6.7

Performance Best Practices for VMware vSphere 6.7의 기계번역 작업을 다 했습니다. 영어가 짧아 부정확한 부분도 좀 있지만, 그래도 기계번역 -> 일부 교정을 통해 나름 크게 어색하지 않게 수정했습니다. 특별한 내용을 배운다기 보다는, vSphere 시스템을 구성할 때 어떤 것들을 고려해야하는지 정리되어 있다고 보면 됩니다. 디자인이란게 정답은 없으니까요. 원문 : https://www.vmware.com/techpapers/2019/vsphere-esxi-vcenter-server-67U2-performance-best-practices.html

1. Hardware for Use with VMware vSphere

이 장에서는 VMware vSphere에 사용할 하드웨어를 선택하고 구성하는 방법에 대한 지침을 제공한다.

1. Hardware for Use with VMware vSphere

하드웨어 검증(Validate Your Hardware)

시스템을 배포하기 전에 다음 사항을 권장한다.

1. Hardware for Use with VMware vSphere

하드웨어 CPU 고려사항(Hardware CPU Considerations)

이 절에서는 vSphere 6.7과 함께 사용하기 위한 CPU에 대한 지침을 제공한다.

일반 CPU 고려사항

하드웨어를 선택할 때, vMotion™(DRS, DPM 및 기타 기능에 영향을 미침)과 VMware Fault Tolerance를 위해 VMware vSphere®의 CPU 호환성을 고려하는 것이 좋다. "VMware vMotion 및 Storage vMotion", "DRS(VMware Distributed Resource Scheduler)", "VMware Fault Tolerance" 등 참조.

사이드-채널 취약점

많은 현대의 CPU에서 집합적으로 "사이드-채널 취약점(Side-Channel Vulnerabilities)"으로 알려진 보안 취약점 부류가 발견되었다. 여기에는 Spectre, Meltdown, Foreshadow, L1TF 등으로 불리는 취약성이 포함된다. 이러한 취약점에 대한 완화 조치 중 일부는 성능에 상당히 영향을 미칠 수 있다. 이 주제의 복잡성뿐만 아니라 끊임없이 변화하는 특성 때문에, 이 책에서 완전히 다루지 않는다. VMware 제품과 관련된 이러한 취약성에 대한 최신 정보는 정기적으로 업데이트되는 VMware KB 문서 52245, 54951, 55636을 참조한다.

이러한 취약성은 시스템의 여러 부분에서 다양한 방법으로 완화될 수 있다. 취약성의 변종에 따라 하드웨어, 마이크로코드 또는 소프트웨어에서 완화(mitigation)가 발생할 수 있다.

하드웨어 완화

최근의 CPU 릴리스에는 성능에 거의 영향을 미치지 않고 이러한 취약성 중 일부를 해결할 수 있는 하드웨어 완화가 포함되어 있다. 따라서 이러한 CPU의 다른 측면에서의 성능 향상 외에도, 새로운 시스템에 대해 CPU를 선택하는 것은 특정 취약성에 대해 마이크로코드 또는 소프트웨어 완화가 필요한 구형 프로세서에 비해 훨씬 더 큰 성능 향상을 제공할 수 있다.

마이크로코드 완화

일부 사이드-채널 취약점은 마이크로코드로 완화할 수 있다. 마이크로코드는 CPU의 외부에서 볼 수 있는 명령 집합 아래의 CPU에서 실행되는 코드 계층이다. CPU와 함께 제공되는 마이크로코드는 BIOS 업데이트를 통해 또는 운영 체제를 통해 현장에서 업데이트될 수 있다.

ESXi의 일부 버전은 마이크로코드를 업데이트하여 특정 사이드 채널 취약점을 완화할 수 있다.

소프트웨어 완화

소프트웨어에서 일부 사이드-채널 취약점을 완화할 수 있다. 취약점에 따라 이러한 완화는 하이퍼바이저 수준이나 게스트 운영 체제 수준에서 이루어질 수 있다. 이러한 완화는 "ESXi의 사이드-채널 취약점 완화" 및 "게스트 운영체제에서 사이드-채널 취약점 완화"에서 설명한다.

하드웨어 지원 가상화

Intel®과 AMD의 프로세서는 대부분 가상화를 지원하고 성능을 개선하기 위한 하드웨어 기능을 포함하고 있다. 이러한 기능(하드웨어 지원 CPU 가상화, MMU 가상화, I/O MMU 가상화)은 아래에 설명되어 있다.

가상화 기술에 대한 자세한 내용은 다음 URL을 참조
https://www.vmware.com/techpapers/2009/software-and-hardware-techniques-for-x86-virtualiz-10036.html

하드웨어 지원 CPU 가상화(VT-x 및 AMD-V™)

VT-x(Intel processors) 또는 AMD-V(AMD processors)라고 하는 하드웨어 지원 CPU 가상화 지원은 민감한 이벤트와 명령어를 자동으로 트랩하여, 트랩 및 에뮬레이트 스타일 가상화를 가능하게 하며, 이러한 트랩 처리와 관련된 오버헤드를 줄일 수 있는 보조 기능을 제공한다.

버전 6.7부터 ESXi는 더 이상 소프트웨어 CPU 가상화를 지원하지 않는다.

하드웨어 지원 MMU 가상화(Intel EPT 및 AMD RVI)

AMD 프로세서의 경우 RVI(Rapid Virtualization Indexing) 또는 NTP(Nested Page Table)라고 하는 하드웨어 지원 MMU 가상화와, Intel 프로세서의 경우 EPT(Extended Page Table)이라고 하는 MMU 가상화는 MMU 가상화를 위한 하드웨어 지원을 제공하여 메모리 관리 유닛(Memory Management Unit) 가상화로 인한 오버헤드를 해결한다.

하드웨어 지원 MMU 가상화는 게스트 물리적 메모리를 호스트 물리적 메모리 주소에 매핑하는 추가 페이지 테이블 수준을 허용하므로 ESXi에서 섀도 페이지 테이블을 유지할 필요가 없다. 이로 인해 메모리 사용량이 감소하고 게스트 운영 체제가 페이지 테이블을 자주 수정하는 워크로드의 속도가 빨라진다. 하드웨어 지원 MMU 가상화는 대부분 워크로드의 성능을 향상시키지만, TLB miss를 서비스하는 데 필요한 시간을 증가시켜 TLB를 강조하는 워크로드의 성능은 감소시킨다.

그러나 이러한 증가된 TLB miss 비용은 "2MB 대용량 메모리 페이지"에 설명된 대로 게스트 운영 체제 및 애플리케이션이 대용량 메모리 페이지를 사용하도록 구성해서 줄일 수 있다.

버전 6.7부터 ESXi는 더 이상 소프트웨어 MMU 가상화를 지원하지 않는다.

하드웨어 지원 I/O MMU 가상화(VT-d 및 AMD-Vi)

하드웨어 지원 I/O MMU 가상화로 Intel 프로세서에서 VT-d(Directed I/O), AMD 프로세서에서 AMD I/O 가상화(AMD-Vi 또는 IOMMU)로 불리는 I/O MMU 가상화는 I/O DMA 전송 및 디바이스 인터럽트를 다시 매핑하는 I/O 메모리 관리 기능이다. 이 기능(엄밀히 말하면 CPU가 아닌 칩셋의 기능)은 가상 머신이 네트워크 카드, 스토리지 컨트롤러(HBA), GPU와 같은 하드웨어 I/O 디바이스에 직접 액세스할 수 있도록 할 수 있다.

하드웨어 지원 I/O MMU 가상화 사용에 대한 내용은 "DirectPath I/O"와 "SR-IOV(Single Root I/O Virtualization)"를 참조하기 바란다.

AES-NI 지원

vSphere 6.7에는 AES-NI(Intel의 Advanced Encryption Standard New Instruction Set)를 지원하는 하드웨어에서 성능이 크게 향상되거나 CPU 부하가 크게 감소하거나 둘 다 발생하는 기능이 포함되어 있다. 이 기능으로 최고의 성능을 얻으려면:

AES-NI를 지원하는 호스트는 기본적으로 호스트에서 실행 중인 가상 하드웨어 버전 7 이상의 가상 시스템에 노출된다. EVC(Enhanced vMotion Compatibility)를 사용하거나 CPU 마스크를 수정하여 원할 경우 변경할 수 있다(VMware KB 문서 1993 참조). AES-NI 패스스루를 사용하지 않도록 설정하는 것이 바람직할 수 있는 한 가지 상황은 AES-NI를 지원하는 호스트에서 그렇지 않은 호스트로 vMotion 호환성을 허용하는 경우다.

AES-NI를 사용하는 기능에 대한 자세한 내용은 "vSphere 가상 시스템 암호화 권장 사항", "VMware vMotion 권장 사항", "VMware vSAN"을 참조한다.

 

1. Hardware for Use with VMware vSphere

하드웨어 메모리 고려사항 (Hardware Memory Considerations)

이 절에서는 vSphere 6.7과 함께 사용할 메모리에 대한 지침을 제공한다.

Persistent Memory (PMem)

영구 메모리(Persistent memory, PMem)는 표준 서버 DIMM 슬롯에 맞지만 DRAM에 비해 다양한 장점을 가진 일종의 비휘발성 메모리다. PMem의 유형 및 구성 방식에 따라 다음과 같은 몇 가지 조합이 이점에 포함될 수 있다.

Intel Optane DC Persistent Memory Modules(DCPMM)와 NVDIMM-N 등 다양한 유형의 PMem을 사용할 수 있으며, PMem은 각각 아래에서 논의되며 지원하기 위해 설계된 서버에서만 사용할 수 있다. DCPMM은 다음 두 가지 모드 중 하나로 구성할 수 있다: 메모리 모드(Memory Mode) 및 앱 직접 모드(App Direct Mode).

ESXi 6.5 U3 및 6.7 EP10에서 Memory Mode를 활성화; 6.7 EP10은 App Direct Mode 지원.

Intel Optane DC Persistent Memory Modules (DCPMM)

DCPMM은 휘발성 DRAM보다 용량이 크고, GB당 비용이 저렴하지만 접근 속도가 약간 느린 PMem의 일종이다. DCPMM에서 사용할 수 있는 용량이 클수록 시스템당 더 많은 총 메모리가 허용될 수 있다.

Optane DC Persistent Memory Modes

위에서 언급한 바와 같이 DCPMM은 메모리 모드와 앱 다이렉트 모드 중 하나 또는 각 모드에서 부분적으로 구성할 수 있다.

PMem에서 최고의 성능을 얻으려면 App Direct Mode로 구성하고 vPMEM으로 사용하는 것이 좋다. 최고의 애플리케이션 성능을 얻기 위해서는 마이크로소프트 SQL 서버 2019와 같은 PMem-aware 애플리케이션이 필요할 것이다.

NVDIMM-N Persistent Memory

NVDIMM-N은 휘발성 DRAM과 같은 속도로 작동하지만 재부팅(또는 전원 장애 시 자동으로 저장)해도 컨텐츠가 보관되는 PMem의 일종이다.

NVDIMM-N은 항상 운영 체제에 PMem(DCPMM과 같은 메모리 모드는 없음)으로 표시되므로 ESXi 6.7 EP10과 같은 PMem 인식 운영 체제가 필요하다.

ESXi는 애플리케이션 직접 모드에서 DCPMMM을 사용하는 것과 같은 방식으로 NVDIMM-N을 사용할 수 있다.

NVDIMM-N PMem 성능에 대한 자세한 내용은 Persistent Memory Performance on vSphere 6.7을 참조하기 바란다.

 

1. Hardware for Use with VMware vSphere

하드웨어 네트워킹 고려사항(Hardware Networking Considerations)

이상적인 단일 포트 10Gb/s 이더넷 네트워크 어댑터는 PCIe x8(또는 그 이상) 또는 PCI-X 266을 사용해야 하며, 이중 포트 10Gb/s 이더넷 네트워크 어댑터는 PCIe x16(또는 그 이상)을 사용해야 한다. 실제 이더넷 디바이스(장치 자체에 내장된 브리지 칩 포함)에 대한 경로에는 가급적 "브리지 칩"(예: PCI-X에서 PCIe로 또는 PCI-X에서 PCI-X로)이 없어야 한다. 이상적으로 40Gb/s 이더넷 네트워크 어댑터는 PCI Gen3 x8/x16 슬롯(또는 그 이상)을 사용해야 한다.

단일 가상 스위치(vSwitch)와 물리적 네트워크 사이의 여러 물리적 네트워크 어댑터가 NIC 팀을 구성한다. NIC 팀은 하드웨어 장애나 네트워크 중단 시 수동적 페일오버를 제공할 수 있으며, 일부 구성에서는 트래픽을 물리적 네트워크 어댑터 전체에 분산시켜 성능을 높일 수 있다.

하나의 vSwitch에 연결된 여러 물리적 네트워크 어댑터 간에 로드 밸런싱을 사용할 경우 모든 NIC의 라인 속도가 동일해야 한다.

물리적 NIC가 연결된 물리적 네트워크 스위치(또는 스위치)가 LACP(Link Aggregation Control Protocol)를 지원하는 경우 이 기능을 사용하도록 물리적 네트워크 스위치와 vSwitch를 모두 구성하면 처리량과 가용성이 향상될 수 있다.

 

1. Hardware for Use with VMware vSphere

하드웨어 스토리지 고려사항(Hardware Storage Considerations)

백엔드 스토리지 구성은 성능에 큰 영향을 미칠 수 있다. 스토리지 구성에 대한 자세한 내용은 VMware vSphere 6.7용 vSphere Storage 문서를 참조하기 바란다.

예상보다 낮은 스토리지 성능은 ESXi와 관련된 문제가 아니라, 기본 스토리지 디바이스의 구성 문제로 인해 발생하는 경우가 가장 많다.

스토리지 성능은 워크로드, 하드웨어, 벤더, RAID 레벨, 캐시 크기, 스트라이프 크기 등에 따라 달라지는 방대한 주제다. 스토리지 벤더뿐 아니라 VMware의 적절한 설명서를 참조하기 바란다.

많은 워크로드가 I/O 작업의 지연 시간에 매우 민감하다. 따라서 저장 장치를 올바르게 구성하는 것이 중요하다. 이 절의 나머지 부분에는 최적의 스토리지 성능을 위해 VMware에서 권장하는 사례 및 구성이 나열되어 있다.

vSphere Flash Infrastructure 계층은 PCIe 플래시 카드 또는 SAS 또는 SATA 연결 SSD 드라이브로 구성될 수 있으며, PCIe 플래시 카드는 일반적으로 SSD 드라이브보다 성능이 우수하다.

VVol 성능은 스토리지 하드웨어 벤더마다 크게 다르므로 선택한 스토리지 하드웨어가 예상하는 VVol 성능을 제공하는지 확인한다.

개선 정도는 스토리지 하드웨어에 따라 다르지만 VAAI는 스토리지 확장성을 향상시키고, 여러 유형의 스토리지 작업에 대한 스토리지 지연 시간을 줄일 수 있으며, 스토리지 작업에 대한 ESXi 호스트 CPU 활용률을 낮출 수 있으며, 스토리지 네트워크 트래픽을 줄일 수 있다.

SAN에서 VAAI는 다음과 같은 기능을 제공한다.

블록 제로화("Write Same"라고도 함)는 eager-zeroed 씩 디스크의 생성 속도를 높이고, lazy-zeroed 씩 디스크와 씬 디스크에서 처음 쓰기 성능을 향상시킬 수 있다.

Dead space reclamation(UNMAP 명령 사용)를 통해 호스트는 더 이상 사용되지 않는 블록을 스토리지로 전송할 수 있다. 어레이 측에서 씬 프로비저닝된 LUN에서는 스토리지 어레이 하드웨어가 더 이상 필요하지 않은 블록을 재사용할 수 있다.

이 맥락에서 "씬 프로비저닝"은 스토리지 어레이의 LUN을 말하며, "Virtual Disk Types"에 설명되어 있는 씬 프로비저닝 VMDK와 구별된다.

NAS 기기에서 VAAI는 다음과 같은 기능을 제공한다.

NAS 네이티브 스냅샷 디스크를 사용하여 가상 머신 스냅샷을 처음 생성하는 것은 VMware redo 로그로 스냅샷을 생성하는 것보다 느리다. 이러한 성능 영향을 줄이려면 NAS 네이티브 스냅샷을 사용하여 가상 시스템의 스냅샷을 생성하는 동안 가상 시스템에서 과도한 쓰기 I/O 로드를 방지할 것을 권장한다.
마찬가지로 NAS 네이티브 스냅샷을 사용하여 연결된 클론을 생성하는 것은 redo 로그를 사용하는 동일한 작업보다 약간 느릴 수 있다.

VAAI에 대한 자세한 내용은 VMware vSphere Storage API - Array Integration(VAAI)을 참조한다(vSphere 5.1용으로 작성되었지만 대부분의 컨텐츠는 vSphere 6.7에 적용됨). ESXi에서 VAAI를 사용하는 방법을 구성하는 방법에 대한 자세한 내용은 "ESXi Storage Consideration"을 참조하기 바란다.

그러나 VLAN과 VPN은 초과 구독은 제거하지 않지만 대역폭을 특정 트래픽에 우선하거나 비례적으로 할당할 수 있는 방법을 제공하는 QoS(네트워크 서비스 품질) 기능을 사용할 수 있도록 허용한다. 이 문제에 대한 다른 접근 방법은 "Network I/O Control(NetIOC)"를 참조.

이렇게 손실된 네트워크 패킷을 복구하면 성능이 크게 저하된다. 데이터가 삭제되었는지 확인하는 데 걸리는 시간 외에도, 재전송은 새로운 거래에 사용될 수 있는 네트워크 대역폭을 사용한다.

예를 들어, 전체 대역폭 잠재력을 공급하기 위해 단일 포트 32Gb/s 파이버 채널 HBA 카드는 최소 PCIe 2세대 x8 또는 PCIe 3세대 x4 슬롯(각 방향에서 최대 32Gb/s의 순 최대치가 가능한)에 설치해야 하며 이중 포트 32Gb/s 파이버 채널 HBA 카드는 최소 PCIe 3세대 x8 슬롯 이상에 설치해야 한다(각 방향에서 최대 64Gb/s의 순 최대치가 가능).

이러한 고성능 카드는 일반적으로 느린 PCIe 슬롯에서도 작동하지만 최대 처리량은 슬롯의 가용 대역폭에 의해 제한될 수 있다. 이는 블록 크기가 큰 I/O를 많이 사용하는 워크로드에 가장 적합하며, 이 카드들이 가장 높은 처리량을 개발하는 경향이 있기 때문이다.

1. Hardware for Use with VMware vSphere

하드웨어 BIOS 설정(Hardware BIOS Settings)

서버의 기본 하드웨어 BIOS 설정이 최적의 성능을 위해 항상 최선의 선택은 아닐 수 있다. 이 절에는 특히 새 서버를 처음 구성할 때 확인할 수 있는 BIOS 설정이 나열되어 있다.

일반 BIOS 설정

BIOS를 업데이트한 다음, 새 BIOS 옵션을 사용할 수 있게 되거나 이전 옵션의 설정이 변경된 경우 BIOS 설정을 다시 방문한다.

하드웨어 지원 가상화 기능을 변경한 후에는 변경 사항을 적용하기 전에 일부 시스템의 전원을 완전히 꺼야 할 수 있다. 자세한 내용은 http://communities.vmware.com/docs/DOC-8978을 참조하기 바란다.

전원 관리 BIOS 설정

VMware ESXi는 소프트웨어에서 호스트를 완전히 사용하지 않을 때 전력을 절약할 수 있는 모든 호스트 전원 관리 기능을 포함하고 있다("ESXi의 호스트 전원 관리" 참조). 하드웨어에서 제공하는 전원 관리 기능을 ESXi에서 가장 유연하게 사용(또는 사용하지 않음)할 수 있도록 BIOS 설정을 구성한 다음 ESXi 내에서 전원 관리를 선택하는 것이 좋다.

그러나 I/O 지연 시간에 매우 민감한 소수의 멀티스레드 워크로드에 대해 C-states는 성능을 저하시킬 수 있다. 이러한 경우 BIOS에서 사용하지 않도록 설정하여 더 나은 성능을 얻을 수 있다.

C1E와 심층 C-상태 구현은 서로 다른 프로세서 벤더와 세대마다 다를 수 있기 때문에, 결과는 달라질 수 있다.

 

 

 

2. ESXi and Virtual Machines

2. ESXi and Virtual Machines

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

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

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

 

2. ESXi and Virtual Machines

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"을 참조하십시오.

 

2. ESXi and Virtual Machines

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을 참조하기 바란다.

 

2. ESXi and Virtual Machines

ESXi 스토리지 고려사항

하위 절은 ESXi의 스토리지 고려 사항에 대한 지침을 제공한다.

vSphere 플래시 읽기 캐시(vFRC)

vFRC(vSphere Flash Read Cache)를 사용하면 ESXi 호스트(vSphere Flash Infrastructure layer)의 플래시 스토리지 리소스를 가상 시스템 I/O 요청의 읽기 캐슁에 사용할 수 있다. 이는 액세스 지역성을 나타내는 워크로드의 성능을 획기적으로 향상시킬 수 있다. 이 절에서는 vFRC를 사용하여 최상의 성능을 얻는 방법을 설명한다.

캐시 파일은 vMotion 성능에 영향을 줄 수도 있다. 자세한 내용은 "VMware vMotion 권장 사항"을 참조.

최적의 캐시 및 블록 크기를 결정하는 방법에 대한 지침을 포함하여 vFRC에 대한 자세한 내용은 VMware vSphere 5.5의 vSphere Flash Read Cache 성능을 참조한다(vFRC를 vSphere 5.5에서 구체적으로 설명함에도 불구하고 이 문서는 vSphere 6.7의 vFRC와 관련이 있다).

VMware vStorage APIs for Array Integration(VAAI)

최상의 스토리지 성능을 위해 VAAI 지원 스토리지 하드웨어를 사용하는 것을 고려한다. VAAI("하드웨어 스토리지 고려 사항")의 성능 향상은 VDI 환경(VAAI가 부팅 스톰 및 데스크톱 워크로드 성능을 개선할 수 있는 경우), 대규모 데이터 센터(VAAI가 대량 가상 시스템 프로비저닝 및 씬 프로비저닝 가상 디스크의 성능을 개선할 수 있는 경우), 기타 대규모 배치에서 특히 두드러질 수 있다.

하드웨어에서 VAAI를 지원하고 사용 중인지 확인하려면 VMware KB 문서 1021976의 지침을 따르십시오. VAAI를 사용하지 않는 경우 스토리지 하드웨어 벤더에 문의하여 VAAI 지원에 펌웨어 업그레이드가 필요한지 확인한다.

LUN 액세스 방법

RDM에 대한 자세한 내용은 vSphere 스토리지를 참조하십시오.

가상 디스크 모드

독립 디스크(independent disk)는 가상 시스템 스냅샷에 참여하지 않는다. 즉, 디스크 상태는 스냅샷 상태와 독립적이므로 스냅샷 생성, 통합 또는 복구는 디스크에 영향을 미치지 않는다.

이들 모드의 특징은 다음과 같다.

가상 디스크 유형

ESXi에서 여러 가상 디스크 유형을 지원한다.

"VMware Virtual Volumes (VVols, VVoles)"에서 설명하는 VMware Virtual Volumes를 사용하면 어레이 자체가 필요에 따라 자동으로 제로화(zeroing)가 조정되므로 VVols에 대해 "eager" 대 "laze" 제로화을 지정할 필요가 없으며, 방법이 없다.

VAAI 지원 SAN 스토리지("하드웨어 스토리지 고려 사항"에서 설명)를 사용하면 제로화 작업을 스토리지 어레이로 오프로드하여 빠르게 비워지는 씩 디스크 생성 속도를 높일 수 있다.

빠르게 비워지는 씩 디스크의 성능 이점은 독립적인 영구 가상 디스크 또는 스냅샷이 없는 종속 가상 디스크에만 해당된다. 독립적인 비영구 가상 디스크 또는 스냅샷이 있는 종속 가상 디스크는 씬 프로비저닝된 디스크와 같은 성능을 발휘한다.

VAAI 지원 SAN 또는 NAS 스토리지를 사용하면 제로화 작업을 스토리지 어레이로 오프로드하여 느리게 비워지는 씩 디스크 쓰기 성능을 개선할 수 있다.

VAAI 지원 SAN 스토리지를 사용하면 파일 잠금 기능을 개선하고 제로화 작업을 스토리지 어레이로 오프로드하여 씬 프로비저닝된 디스크의 최초 쓰기 성능을 개선할 수 있다.

세 가지 유형의 가상 디스크 모두 vSphere Client를 사용하여 생성할 수 있다(가상 시스템 오른쪽 클릭, Edit Settings 선택, Virtual Hardware 탭 선택, ADD NEW DEVICE 클릭, Hard Disk 선택, New Hard disk 줄 확장, disk type  선택).

vmkfstools를 사용하여 vSphere CLI(vSphere Command-Line Interface)에서 가상 디스크를 생성할 수도 있다. 자세한 내용은 vSphere Command-Line Interface Reference 및 vmkfstools man 페이지를 참조한다.

이러한 가상 디스크 유형 중 일부는 하드웨어 벤더와 하드웨어가 VAAI를 지원하는지 여부에 따라 NFS 볼륨에서 가상 디스크를 생성할 때 사용할 수 없을 수 있다.

자동 공간 회수(UNMAP)

VMFS6 데이터스토어(vSphere 6.5 이상에서 지원)에서 vSphere는 씬 프로비저닝된 디스크에 대해 자동 공간 회수(reclamation)(즉, UNMAP)를 수행할 수 있다. vSphere 6.5는 UNMAP 우선 순위를 설정할 수 있도록 허용하며, vSphere 6.7은 UNMAP 속도를 설정하는 기능을 추가한다. 이러한 옵션을 사용하면 빠른 어레이(특히 All-Flash 어레이에 유용함)에서 스토리지 공간을 훨씬 더 빠르게 회수할 수 있으며, UNMAP 작업의 안정되지 않은 버스트(특히 느린 어레이에 유용함)를 수행함으로써 발생할 수 있는 성능 영향을 제한할 수 있다.

vSphere Client는 UNMAP에 대해 제한된 구성 옵션을 제공한다. 전체 옵션의 경우 esxcli 명령을 사용하십시오.
UNMAP에 사용할 수 있는 구성 옵션과 사용 방법에 대한 자세한 내용은 https://docs.vmware.com 에서 "Storage Space Reclamation"를 검색한다.

VMFS5 및 이전 파일 시스템은 사용 가능한 공간을 자동으로 매핑 해제하지 않지만 esxcli storage vmfs unmap 명령을 사용하여 수동으로 공간을 회수할 수 있다. 이 명령을 사용할 때는 많은 Unmap 요청을 한 번에 보낼 수 있다는 점에 유의한다. 이 동작은 작업 중에 일부 자원을 잠글 수 있다. 자세한 내용은 VMware KB 문서 2057513을 참조기 바란다.

파티션 정렬

파일 시스템 파티션의 정렬은 성능에 영향을 미칠 수 있다. VMware는 VMFS 파티션에 대해 다음과 같은 사항을 권장한다:

64KB 경계를 따라 정렬된 이전 버전의 ESX/ESXi를 사용하여 VMFS3 파티션을 생성한 경우 파일 시스템을 VMFS5로 업그레이드하면 64KB 정렬이 유지된다. 파티션을 삭제하고 ESXi 5.0 이상 호스트와 함께 vSphere Client를 사용하여 다시 생성하면 1MB 정렬을 얻을 수 있다.
기존 VMFS3 또는 VMFS5 볼륨은 VMFS6으로 직접 변환할 수 없다. 대신 처음부터 VMFS6 볼륨을 생성하고 Storage vMotion을 사용하여 가상 시스템을 새 볼륨으로 마이그레이션해야 한다.

SAN 다중 경로 지정

SAN 경로 정책은 스토리지 성능에 상당한 영향을 미칠 수 있다. 일반적으로 ESXi에서 특정 어레이에 대해 기본적으로 사용하는 경로 정책이 최선의 선택일 것이다. 기본이 아닌 경로 정책을 선택하는 경우 벤더가 해당 어레이에서 테스트하고 지원하는 정책 중에서 선택하는 것을 권장한다.

이 섹션에서는 SAN 경로 정책의 주제에 대한 간략한 개요를 제공한다.

ALUA(아래 설명)를 지원하는 일부 Active-Passive 스토리지 어레이에서 ESXi는 고정 경로 정책을 사용할 수 있다. 그러나 SAN 벤더가 특별히 지원하는 어레이에서만 사용하는 것이 좋다. 대부분의 경우 라운드 로빈(Round Robin)이 액티브/패시브 어레이에 더 좋고 안전한 선택이다.

이건 조금 찾아봐야할 것 같음. 라운드 로빈은 액티브/액티브 어레이에서 더 좋은 선택이 아닐런지?

모든 스토리지 어레이가 라운드 로빈 경로 정책을 지원하는 것은 아니다. 지원되지 않거나 바람직하지 않은 경로 정책으로 전환하면 LUN에 대한 연결 문제가 발생하거나 스토리지 운영 중단이 발생할 수 있다. 어레이 설명서를 확인하거나 스토리지 벤더와 함께 라운드 로빈을 지원하거나 어레이 및 구성에 권장되는지 확인하기 바란다.

자세한 내용은 VMware SAN 구성 가이드 및 VMware KB 문서 1011340을 참조하기 바란다.

스토리지 I/O 리소스 할당

VMware vSphere는 스토리지 I/O 리소스를 동적으로 할당하는 메커니즘을 제공하여 I/O 리소스에 대한 경합이 있는 최대 로딩 기간 중에도 중요 워크로드의 성능을 유지할 수 있도록 지원한다. 이 할당은 개별 호스트에서 사용할 수 있는 스토리지 리소스("VMware vSphere Storage I/O Control"에서 설명) 또는 전체 데이터스토어의 리소스에서 수행할 수 있다.

ESXi 호스트에서 사용할 수 있는 스토리지 I/O 리소스는 디스크 공유 또는 제한을 설정하여 해당 호스트의 가상 디스크에 할당할 수 있다.

공유 또는 제한을 설정하려면 vSphere Client에서 가상 시스템을 마우스 오른쪽 버튼으로 클릭하고 Edit Settings을 선택하고, Virtual Hardware 탭을 선택하고, 하드 디스크 1(또는 구성할 하드 디스크 1)을 확장한 다음 Share 또는 Limis - IOP를 원하는 값으로 설정한다.

iSCSI 및 NFS 권장 사항

NVMe 권장 사항

PCIe 카드의 플래시 스토리지는 초기에는 SCSI 또는 SATA 인터페이스와 프로토콜을 사용했으며, 종종 기본 SSD 디바이스보다 훨씬 적은 수준으로 성능을 제한했다. 일부 최신 PCIe 플래시 디바이스는 NVMe(Non-Volatile Memory Express) 프로토콜을 사용하여 잠재적으로 훨씬 더 높은 성능을 제공할 수 있다.

vSphere는 "게스트 운영 체제 스토리지 고려 사항"에서 설명한 가상 NVMe(vNVMe)도 지원한다.

NVMe 성능 고려 사항:

vSphere 가상 시스템 암호화 권장 사항

vSphere 6.5에 도입된 가상 시스템 암호화는 디스크 파일(.vmdk), 스냅샷 파일(.vmsn), NVRAM 파일(.nvram), 스왑 파일(.vswp), 구성 파일 부분(.vmx)을 암호화할 수 있다. 암호화 및 암호 해독은 CPU에 의해 수행되므로 CPU 비용이 발생한다. 가능하면 vSphere는 AES-NI 프로세서 명령 집합 확장(많은 최신 프로세서에서 지원)을 사용하여 CPU 비용을 절감한다.

이 항목에 대한 자세한 내용은 VMware vSphere Virtual Machine Encryption Performance 백서를 참조하기 바란다.

일반적인 ESXi 스토리지 권장 사항

스토리지 어레이의 LUN 수와 이러한 LUN에 가상 시스템을 분산하는 방식이 성능에 영향을 미칠 수 있다:

스토리지 지연 시간에 민감한 워크로드 실행

기본적으로 ESXi 스토리지 스택은 낮은 CPU 비용으로 높은 스토리지 처리량을 제공하도록 구성되어 있다. 이 기본 구성은 더 나은 확장성과 더 높은 통합 비율을 제공하지만, 잠재적으로 더 높은 스토리지 지연 시간을 초래한다. 따라서 스토리지 지연 시간에 매우 민감한 워크로드의 이점은 다음과 같다.

스토리지 지연 시간에 민감한 워크로드를 실행하는 방법에 대한 자세한 내용은 Best Practices for Performance Tuning of Latency-Sensitive Workloads in vSphere VMs에 있고, 주로 네트워크 지연 시간에 민감한 워크로드를 처리하는 데 도움이 될 수 있다.

 

2. ESXi and Virtual Machines

ESXi 네트워킹 고려사항

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

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

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에 할당할 수 있다.

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를 사용한다.
이 기능은 특정 워크로드의 네트워크 성능을 크게 향상시킬 수 있다. 이러한 워크로드에는 다음이 포함된다.

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

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

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

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

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로 대체됨).

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

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 오버헤드가 증가할 가능성이 있기 때문에 이 기능은 기본적으로 사용하지 않도록 설정되어 있다.

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

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

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

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

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

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을 위한 모범 사례를 참조하십시오.

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

호스트-와이드 성능 조정

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

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

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

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

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

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

3. Guest Operating Systems

3. Guest Operating Systems

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

지원되지 않는 게스트 운영 체제에는 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를 사용하여 최상의 성능을 얻으려면 다음 사항을 고려하십시오.

가상 시스템의 성능 측정

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

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

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

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

"사이드 채널 취약점(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 노드 크기가 있다. 예를 들어, 일부 12코어 프로세서에는 프로세서당 2개의 6코어 NUMA 노드가 있다.

예를 들어, 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 설정한다.

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" 섹션을 참조하십시오.

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

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

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

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

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

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

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

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

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

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

가상 네트워크 어댑터 유형

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

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

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을 참조하기 바란다.

가상 네트워크 어댑터 선택

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

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

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

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

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

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

4. Virtual Infrastructure Management

4. Virtual Infrastructure Management

일반 리소스 관리

ESXi는 그 안에서 실행되는 가상 시스템에 대한 CPU 및 메모리 리소스 할당을 구성하고 조정하는 몇 가지 메커니즘을 제공한다. 리소스 관리 구성은 가상 시스템 성능에 상당한 영향을 미칠 수 있다.

이 섹션에는 최적의 성능을 위해 VMware에서 권장하는 리소스 관리 방식 및 구성이 나열되어 있다.

4. Virtual Infrastructure Management

VMware vCenter

이 섹션에는 최적의 성능을 위해 권장되는 VMware vCenter 사례 및 구성이 나열되어 있다. 또한 vCenter를 통해 제어되거나 액세스되는 몇 가지 기능도 포함한다.

VMware vCenter 데이터베이스 고려 사항

vCenter Server는 인벤토리 항목 및 성능 통계 데이터에 대한 구성 정보를 저장하는 데이터베이스에 크게 의존한다. 또한 경보, 이벤트 및 태스크에 대한 데이터도 저장한다. 이 데이터베이스가 vCenter Server의 안정성 및 성능에 중요하므로 이 섹션에서 설명하는 데이터베이스 사례를 권장한다.

VMware vCenter 데이터베이스 네트워크 및 스토리지 고려 사항

VMware vCenter 데이터베이스 구성 및 유지 관리

<vpxd>
 <odbc>
  <maxConnections>xxx</maxConnections>
 </odbc>
</vpxd> 
(xxx는 풀의 크기).

vCenter 풀 크기를 변경한 경우 데이터베이스의 최대 허용 연결 수를 늘리는 것도 고려해야 한다.

vPostgres 데이터베이스를 사용할 때 상위 N 기능을 사용하지 않도록 설정하는 옵션은 없다(배포 중에 내장형 데이터베이스 옵션을 선택한 경우 vCenter Server에서 사용된다).

나중에 Top N을 다시 실행하려면 모든 데이터베이스 세션이 지워지고 데이터베이스가 정상 상태로 돌아갈 때까지 기다린 다음 작업을 다시 실행한다.

특정 데이터베이스 공급업체에 대한 권장 사항

이 하위섹션은 데이터베이스별 권장사항을 설명한다.

PostgreSQL(vPostgres) 데이터베이스 권장 사항

PostgreSQL(vPostgres) 데이터베이스를 사용하는 경우(배포 중에 내장형 데이터베이스 옵션을 선택하는 경우 vCenter Server에서 사용됨), 많은 최적화가 자동으로 수행된다. 그러나 이 섹션의 포인트는 vCenter Server 성능을 향상시킬 수 있다.

많은 vCenter Server Appliance 구성 작업은 vCenter Server Appliance 관리 인터페이스를 사용하여 수행할 수 있다. 이 인터페이스는 웹 브라우저를 사용하여 어플라이언스의 포트 5480(https://<appliance-IP-address>:5480)에 액세스한 다음 루트로 로그인(vCenter Server Appliance를 배포할 때 설정한 암호 사용)할 수 있다.

Microsoft SQL Server 데이터베이스 권장 사항

Microsoft SQL Server 데이터베이스를 사용하는 경우 다음 사항이 vCenter Server 성능을 향상시킬 수 있다.

Oracle 데이터베이스 권장 사항

Oracle 데이터베이스를 사용하는 경우 다음 사항이 vCenter Server 성능을 향상시킬 수 있다.

4. Virtual Infrastructure Management

VMware vSphere Management

VMware vSphere 환경은 일반적으로 VMware vSphere® Client 또는 VMware vSphere Web Services SDK를 통해 관리되며, 연결된 vSphere Client 또는 vSphere Web Services SDK Client의 수가 많으면 vCenter Server의 성능에 영향을 미칠 수 있다. vSphere 6.7의 구성 최대값에 지정된 최대값을 초과하는 것은 지원되지 않는다. 효과가 있는 것처럼 보이더라도, 그렇게 하는 것은 vCenter Server 성능에 훨씬 더 영향을 미칠 가능성이 있다.

vSphere Client

이 섹션은 "vSphere Client"를 의미한다. 유사한 명칭의 "vSphere Web Client"는 Flex를 기반으로 하며, 더 이상 사용되지 않는다.

vSphere Client(HTML5 Client)를 사용하여 vCenter Server, ESXi 호스트 및 가상 시스템을 제어 및 구성할 수 있다. vSphere 6.7 업데이트 1을 기준으로 HTML5 Client는 Flex 클라이언트의 모든 기능을 제공하며, 우리는 모든 배포에서 HTML5 Client를 사용할 것을 강력히 권장한다.

vSphere Client 서버라고 하는 vSphere Client 백엔드는 Java 애플리케이션이다. 단순하게 vSphere Client라고 하는 vSphere Client 프런트 엔드는 Java 기반 Application Server를 가리키는 웹 브라우저에서 실행되는 HTML5 기반 클라이언트다.

vSphere Client 백엔드 성능 고려 사항

vSphere Client 백엔드는 Java 애플리케이션인 vSphere Client Server로 구성되며, vCenter Server와 크게 상호 작용한다. 따라서 이 두 모듈은 모두 vSphere Client 백엔드 성능에 영향을 미친다. 이 하위 섹션에서는 vSphere Client 백엔드에서 최상의 성능을 얻는 방법을 설명한다.

vSphere 6.5부터 인벤토리 서비스는 허가, 역할 및 권한에 대한 논리를 포함하는 경량 서비스인 vpxd-svcs로 대체되었다.

JVM의 최대 힙 크기를 다음과 같이 결정할 수 있다.

vSphere Client 서버에 할당된 메모리 양이 부족하면 메모리를 늘리면 성능이 크게 향상될 수 있다.

vSphere Client Server에 할당된 메모리를 늘리는 가장 간단한 방법은 실행 중인 시스템에 대해 프로비저닝된 총 메모리 양을 증가시킨 다음 시스템을 재부팅하는 것이다. 부팅 시 동적 메모리 알고리즘은 vSphere Client Server를 포함하여 다양한 서비스에 할당된 메모리 양을 자동으로 재구성한다.

총 메모리를 늘리지 않으려는 경우 또는 동적 메모리 알고리즘이 사용자 환경에 적합하지 않은 경우 vSphere Client Server의 최대 힙 크기를 수동으로 변경할 수 있다. 그러나 이는 운영 체제뿐만 아니라 다른 서비스에서 사용할 수 있는 메모리 양에도 영향을 미친다는 점에 유의한다.

수동으로 vSphere Client Server 최대 힙 크기를 변경하려면:

최대 힙 크기를 변경한 후 다음과 같이 변경 사항을 적용하려면 vSphere Client 서비스를 다시 시작한다.

Advanced 옵션 이름 설명 기본값
live.updates.enabled Recent Tasks에서 라이브 새로 고침을 사용할지 여부. true
live.updates.alarms.enabled Alarms 보기에서 라이브 새로 고침을 사용할지 여부. true
live.updates.navtree.enabled 네 가지 유형의 인벤토리 트리(Hosts and Clusters, VMs and Templates, Storage, Networking)에서 라이브 새로 고침을 사용할지 여부. true
live.updates.lists.enabled 목록에서 라이브 새로 고침을 사용할지 여부. true
live.updates.objectstate.enabled 현재 개체의 Summary 탭에서 라이브 새로 고침을 사용할지 여부. 이 작업은 각 Summary 탭에 표시된 각 속성("중요 속성"이라고 함)에 대해서만 수행되는 것이 아니라, 각 유형의 속성("중요 속성"이라고 함)에 대해 대략적으로 해당 개체의 아이콘과 상태를 결정하는 속성이라고 설명할 수 있다. true
session.timeout 사용자가 자동으로 로그아웃되기 전까지의 시간(분). 120
alarms.refresh.rate 경보 목록의 자동 새로 고침 간격(초)
10~600 사이여야 한다.
-1 값은 알람의 자동 새로 고침을 비활성화한다.
60
dataservice.timeoutSeconds 데이터 어댑터가 응답하지 않을 경우 UI에 오류가 표시되기 전의 시간(초) 120
dataservice.connectionTimeoutSeconds 데이터 서비스 연결이 손실된 경우 UI에 오류가 표시되기 전의 시간(초) 10
sso.pending.password.expiration.notification.days UI에 알림이 표시되는 SSO 암호 만료 전 일 수. 30

vSphere Client 프런트 엔드 성능 고려 사항

vSphere Client 프런트엔드는 사용자 시스템의 웹 브라우저에서 실행되는 HTML5 기반 애플리케이션이다. 이 하위 섹션에서는 vSphere Client 프런트엔드에서 최상의 성능을 얻는 방법을 설명한다.

대기 시간이 짧은 연결을 설정할 수 없는 경우, 다른 옵션은 vSphere Client 백엔드 근처에 가상 시스템 또는 물리적 시스템을 배치하고(시스템이 백엔드에 연결되는 지연 시간이 낮음) vSphere Client 프런트엔드를 실행하여 RDP와 같은 원격 프로토콜로 원격으로 액세스하는 것이다. 

vSphere Web Services SDK 클라이언트

VMware vSphere Web Services SDK는 vSphere 환경을 효율적으로 관리하는 방법이 될 수 있다.

VMware vSphere API 및 지원되는 SDK 라이브러리에 대한 자세한 내용은 vSphere API 및 SDK 설명서를 참조하십시오.

모범적 프로그래밍 관행의 예는 VMware 커뮤니티 샘플 코드 페이지(http://communities.vmware.com/community/vmtn/developer/codecentral)에서 코드 샘플을 참조하십시오.

SDK를 사용하여 개별 호스트의 정보를 집계하여 클러스터 성능 데이터를 가져오려면 vCenter Cluster Performance Tool Fling(https://labs.vmware.com/flings/vcenter-cluster-performance-tool))을 참조하십시오.

 

4. Virtual Infrastructure Management

VMware vMotion과 Storage vMotion

이 섹션에서는 vMotion™, Storage vMotion 및 크로스 호스트 Storage vMotion에 대한 성능 모범 사례를 제공한다.

VMware vMotion 권장 사항

vMotion에 적용되는 성능 권장 사항:

VMware Storage vMotion 권장 사항

Storage vMotion에 적용되는 성능 권장 사항:

VMware Cross-Host Storage vMotion 권장 사항

Cross-Host Storage vMotion을 사용하면 가상 시스템을 호스트와 데이터스토어 간에 동시에 이동할 수 있다. Cross-Host Storage vMotion에 적용되는 성능 권장 사항:

블록 크기가 1MB가 아닌 VMFS 데이터스토어를 VMFS 5.x로 인플레이스 업그레이드할 경우 블록 크기는 변경되지 않는다. 따라서 이 상황에서는 1MB 블록 크기의 성능 이점을 얻기 위해 새 VMFS 5.x 데이터스토어를 생성해야 한다.

vSphere 6.0 이전에는 NFC이 관리 네트워크("프로비저닝 네트워크"라고도 함)만 사용할 수 있었다. vSphere 6.0을 시작으로, NFC는 여전히 기본적으로 관리 네트워크를 사용하지만, 선택적으로 NFC 전용 네트워크를 통해 라우팅될 수 있다. 이를 통해 NFC 트래픽이 관리 트래픽과 분리되어 네트워크 프로비저닝에 더 많은 유연성을 부여할 수 있다.
어쨌든, 우리는 NFC이 최소 1Gb/s의 네트워크 대역폭을 제공하도록 권고한다.

 

4. Virtual Infrastructure Management

VMware Distributed Resource Scheduler (DRS)

이 섹션에는 최적의 성능을 위해 VMware에서 권장하는 DRS(Distributed Resource Scheduler) 사례 및 구성이 나열되어 있다.

DRS 일반

DRS 클러스터 구성 설정

DRS 클러스터 크기 조정 및 리소스 설정

DRS 성능 조정

마이그레이션 임계값은 반대 상황의 경우 더 보수적인 수준으로 설정해야 한다.

가장 보수적인 임계값을 선택한 경우 DRS는 로드 밸런싱을 수행하지 않으며, 선호도 또는 반선호도 규칙과 같은 하드 제약 조건을 충족하거나 유지 보수 또는 대기 모드로 전환되는 호스트에서 가상 시스템을 제거하기 위해 취해야 하는 이동 권장 사항만 적용할 것이다.

이러한 옵션은 vSphere Client에서 사용할 수 있다(클러스터 선택, Configure 탭 클릭, Services 확장, vSphere DRS 선택, Edit 버튼 클릭, Additional Options 탭 클릭).

이러한 옵션에 대한 자세한 내용은 vSphere 6.5 DRS Performance을 참조한다(vSphere 6.5에서 DRS를 구체적으로 다루지만 이 백서는 vSphere 6.7의 DRS와도 관련이 있음).

특정 환경에 "로드 밸런싱된" 클러스터를 달성하는 것이 중요한 경우 몇 가지 규칙을 완화하거나 마이그레이션 임계값을 조정할 수 있다.

반면에 모든 가상 시스템이 권한이 있는 리소스의 100%를 받고 있다면 클러스터가 약간 불균형한 것이 허용될 수 있다.

이를 위해서는 vRealize Operations 버전 6.4 이상이 필요하다. 자세한 내용은 https://blogs.vmware.com/management/2016/11/david-davis-vrealize-operations-post-34-new-predictiv e-drs-vrealize-operations-6-4.html 을 참조한다.

 

4. Virtual Infrastructure Management

VMware Distributed Power Management (DPM)

VMware Distributed Power Management(DPM)은 클러스터 내 호스트의 활용률이 낮을 때 전력을 절약한다. 이 작업은 가상 시스템을 클러스터의 호스트 하위 집합에 통합한 다음 나머지 호스트를 대기 모드로 전환하여 수행한다. DPM은 클러스터에 있는 가상 시스템의 요구 사항을 충족하기 위해 충분한 호스트 용량을 전원이 켜진 상태로 유지한다. 수요가 증가하면 DPM은 추가 호스트의 전원을 켜고 가상 시스템을 해당 호스트로 마이그레이션하여 전원이 켜진 호스트 간에 클러스터의 로드가 균형을 유지하도록 한다.

DPM은 가상 머신의 복합 수요가 시간에 따라 크게 변화하는 클러스터(예: 낮 동안 전체 수요가 더 높고 밤에 훨씬 더 낮은 클러스터)에 가장 적합하다. 전체 클러스터 용량 대비 수요가 지속적으로 높은 경우 DPM은 전원을 절약하기 위해 호스트를 대기 모드로 전환할 기회가 거의 없다.

DPM은 DRS를 사용하기 때문에 대부분의 DRS 모범 사례("VMware Distributed Resource Scheduler(DRS)"에 설명됨)도 DPM과 관련이 있다.

DPM은 전원을 절약하기 위해 호스트의 전원을 끄지만, 매우 다른 절전 기술인 호스트 전원 관리를 사용하여 전원이 켜져 있는 동안 개별 ESXi 호스트의 전원 소비를 줄일 수 있다. 이것은 "ESXi의 호스트 전원 관리"에서 설명한다.
DPM과 호스트 전원 관리는 최상의 전력 절약을 위해 함께 사용될 수 있다.

DPM 구성 및 작동 모드

DPM은 호스트 전원 관리 정책을 보완한다("ESXi의 호스트 전원 관리" 참조). DPM은 활용도가 낮은 호스트를 대기 모드로 전환하여 클러스터 규모에서 전력을 절약함으로써 유휴 전력 소비를 없앤다. 호스트 수준의 전원 관리 정책을 통해 전원이 켜진 상태로 유지되는 클러스터의 호스트를 효율적으로 사용할 수 있다. DPM과 호스트 전원 관리를 함께 사용하면 두 솔루션 중 하나를 단독으로 사용할 때 얻을 수 있는 것보다 더 큰 절전 효과를 얻을 수 있다.

DPM 알고리즘 조정

사전 예방적으로 DPM 스케줄링 및 실행

마찬가지로 vCenter Server 또는 vCenter vpxd 서비스를 다시 시작하면 해당 vCenter Server에서 관리하는 모든 대기 ESXi 호스트의 전원이 켜진다.

이를 위해서는 vRealize Operations 버전 6.4 이상이 필요하다. 자세한 내용은 https://blogs.vmware.com/management/2016/11/david-davis-vrealize-operations-post-34-new-predictiv e-drs-vrealize-operations-6-4.html을 참조한다.

VMware High Availability(HA)와 함께 DPM 사용

4. Virtual Infrastructure Management

VMware vSphere Storage I/O Control

VMware vSphere® Storage I/O Control은 데이터스토어에 액세스하는 다양한 가상 머신 간에 전체 데이터스토어의 리소스를 원하는 대로 할당할 수 있는 기능이다.

개별 ESXi 호스트가 수신하는 스토리지 I/O 리소스를 할당하는 방법을 제어하려면(데이터스토어의 전체 I/O 리소스 할당을 제외한) "스토리지 I/O 리소스 할당"을 참조한다.

Storage I/O Control을 사용하지 않도록 설정한 경우(기본값), 데이터스토어에 액세스하는 각 호스트는 해당 호스트에서 들어오는 데이터스토어의 총 I/O 워크로드 비율에 해당하는 데이터스토어 리소스의 일부를 얻는다.

Storage I/O Control을 사용하도록 설정한 경우에도 Storage I/O Control이 트리거될 때까지 아무런 작업도 수행되지 않으며, 이는 데이터스토어 정체 현상이 감지될 때 자동으로 발생한다. Storage I/O Control은 트리거 임계값을 조정하여 실행 중인 데이터 센터 환경에 맞게 조정한다.

데이터스토어의 I/O 리소스는 다음 설정에 따라 할당할 수 있다:

Storage I/O Control을 사용하도록 설정하려면 네비게이터 창의 vSphere Client에서 Storage 탭을 선택하고 데이터스토어를 선택한 다음 Configure 탭을 선택하고 General을 선택한 다음 Datastore Capabilities 오른쪽에 있는 EDIT... 버튼을 클릭하고 Enable Storage I/O Control and statistics collection 확인란을 선택한 다음 확인을 누르십시오.

Storage I/O Control 성능(특히 SSD 스토리지의 경우)에 대한 자세한 내용은 Performance Implications of Storage I/O-Enabled SSD Datastores in VMware vSphere 6.5을 참조한다(특히 vSphere 6.5를 다루기는 하지만 이 백서는 vSphere 6.7과도 관련이 있음).

 

4. Virtual Infrastructure Management

VMware Storage Distributed Resource Scheduler (Storage DRS)

Storage Distributed Resource Scheduler(DRS)는 데이터스토어 클러스터 내의 데이터스토어 간에 I/O 로드 밸런싱 및 공간 밸런싱을 제공할 뿐 아니라 공간 부족을 방지해 준다. 이로 인해 스토리지 성능 병목 현상이 발생하지 않거나 발생할 경우 이를 해결할 수 있다.

이 섹션에는 최적의 성능을 위해 VMware에서 권장하는 Storage DRS 사용 사례 및 구성이 나열되어 있다.

데이터스토어 클러스터의 I/O 리소스를 늘리기 위해 데이터스토어를 추가할 때 변경 내용이 동일한 기본 물리적 디스크에 액세스할 수 있는 추가 방법을 만드는 것이 아니라 실제로 리소스를 추가하는지 확인하십시오.

 

4. Virtual Infrastructure Management

VMware vSphere High Availability

VMware vSphere® High Availability(HA)는 가상 머신 내의 호스트, 가상 머신 또는 애플리케이션을 모니터링한 다음 장애가 감지될 경우 대체 호스트에서 가상 머신을 재시작하여 가상 머신의 다운타임을 최소화한다.

VMware High Availability 일반

HA에 대한 자세한 내용은 vSphere Availability을 참조한다.

Virtual Machine Component Protection (VMCP)

이 기능을 사용하도록 설정하는 방법을 포함하여 VMCP에 대한 자세한 내용은 ESXi 6.7 및 vCenter Server 6.7용 vSphere Availability 가이드를 참조한다.

 

 

4. Virtual Infrastructure Management

VMware Fault Tolerance

VMware Fault Tolerance(FT)는 서버 장애 발생 시 가상 머신을 지속적으로 사용할 수 있도록 지원한다.

FT는 HA를 사용하기 때문에 대부분의 HA 모범 사례("VMware vSphere High Availability"에서 설명함)도 FT와 관련이 있다.

가상 시스템에서 FT를 사용하도록 설정한 경우 해당 가상 시스템을 FT 기본(primary) 가상 시스템 또는 기본 가상 시스템이라고 한다. 이러한 각 FT 기본 가상 시스템은 FT 보조(secondary) 가상 시스템 또는 보조 가상 시스템과 쌍을 이룬다. 기본 및 보조의 역할은 동적이다. 즉, 페일오버가 있을 때 가상 시스템이 역할을 교환할 수 있다.

예를 들어 보조가 실행되고 있는 호스트에 FT 로깅 대역폭을 포화시키는 다른 많은 보조가 있지만 기본이 실행 중인 호스트에 FT 가상 시스템이 하나만 있는 경우, 보조의 리소스 부족을 수용하기 위해 기본이 느려질 수 있다. 다음 권장 사항은 이러한 상황을 피하는 데 도움이 된다:

 

4. Virtual Infrastructure Management

VMware vSphere Update Manager

VMware vSphere Update Manager는 VMware vSphere에 패치 관리 프레임워크를 제공한다. VMware ESXi 호스트, VMware Tools 및 가상 하드웨어 등에 패치, 업데이트 및 업그레이드를 적용하는 데 사용할 수 있다.

여기에 제시된 자료 외에도 vSphere Update Manager 성능에 대한 자세한 내용은 VMware vSphere Update Manager Performance and Best Practices를 참조하십시오.

윈도우에 배포된 Update Manager

윈도우즈에서 vCenter Server를 배포하는 경우 Update Manager는 vCenter Server와 다른 가상 시스템에서 실행되어야 하며, Update Manager는 vCenter Server와 데이터베이스를 공유하거나 고유한 데이터베이스를 가지도록 구성할 수 있다. 다음과 같은 권장 사항이 이러한 윈도우즈 배포에 적용된다.

리눅스에 배포된(vCenter Server Appliance) Update Manager

vCenter Server Appliance(vCSA) 배포는 Update Manager와 함께 Linux 호스트와 데이터베이스를 공유한다. Update Manager 서비스 updatemgr은 어플라이언스가 시작되면 기본적으로 사용하도록 설정되고 시작되며, 다음 권장 사항은 이러한 Linux 배포에 적용된다.

공유 리소스에도 불구하고 Update Manager의 Linux 배포는 윈도우즈 배포와 동일한 최대 구성을 지원한다.

Update Manager 일반 권장 사항

가상 하드웨어를 업그레이드하기 전에 VMware Tools가 최신 상태여야 하므로 Update Manager는 가상 하드웨어를 업그레이드하기 전에 VMware Tools를 업그레이드해야 할 수 있다. 이러한 경우 가상 시스템의 전원이 이미 켜져 있는 경우 프로세스가 더 빠르다.

Update Manager Quick Boot 옵션

ESXi 6.7의 새로운 기능인 Update Manager는 호환되는 하드웨어에 대한 빠른 부팅 옵션을 제공한다. 이 옵션을 사용하면 펌웨어 및 디바이스 초기화를 수행하지 않고도 ESXi를 재부팅하여 시간을 절약할 수 있다. 이 기능을 사용할 수 있는 하드웨어에서는 Update Manager UI에 옵션이 표시된다.

시스템이 빠른 부팅과 호환되는지 확인하려면 ESXi 호스트의 셸에서 다음 명령을 실행한다 : /usr/lib/vmware/loadesx/bin/loadESXCheckCompat.py

Quick Boot에 대한 자세한 내용은 VMware KB 문서 52477을 참조한다.

Update Manager 클러스터 업데이트 적용

Update Manager 대역폭 조정

 

4. Virtual Infrastructure Management

VMware vCenter Single Sign-On Server

VMware vCenter Single Sign-On Server는 vSphere 관리 스택 전반에서 사용자에게 단일 로그인 액세스를 제공한다. 최상의 성능을 얻으려면 이 섹션의 권장 사항을 따른다.

4. Virtual Infrastructure Management

VMware vSphere Content Library

VMware vSphere Content Library는 vSphere 관리자가 가상 시스템 템플릿, vApp, ISO 이미지 및 스크립트를 쉽게 관리할 수 있는 방법을 제공한다. 최상의 성능을 얻으려면 이 섹션의 권장 사항을 따르십시오.

 

4. Virtual Infrastructure Management

VMware vSAN

VMware vSAN을 통해 ESXi 호스트에 직접 연결된 스토리지 리소스를 분산 스토리지에 사용하고 여러 ESXi 호스트에서 액세스할 수 있다. 최상의 성능을 얻으려면 이 섹션의 권장 사항을 따르십시오.

vSAN 성능에 대한 자세한 내용은 vSAN 6.6 Performance Improvements 백서를 참조한다.

하이브리드 대 올-플래시 vSAN

vSAN 구현은 "하이브리드" 또는 올-플래시일 수 있다:

하이브리드 vSAN 구축은 매우 빠르지만 올-플래시 구축은 여전히 더 빠르다. 또한 올-플래시 vSAN은 RAID-5, RAID-6, 중복제거 및 압축을 지원한다. 이러한 기능은 스토리지 효율성을 향상시킴으로써 하이브리드 및 올-플래시 vSAN 간의 효과적인 비용 차이를 줄일 수 있다.

vSAN 하드웨어 선택 및 레이아웃

하이브리드 vSAN을 위한 하드웨어 선택 및 레이아웃

하이브리드 vSAN에서 모든 쓰기는 캐싱 계층을 구성하는 SSD로 먼저 이동하고 vSAN 읽기 캐시 적중(이상적으로 읽기 중 많은 부분을 차지하는)도 해당 계층에서 온다.

따라서 캐싱 계층(SSD)과 용량 계층(HDD) 비율이 하이브리드 vSAN 성능에 큰 영향을 미친다. SSD 대 HDD 비율이 높을수록 일반적으로 성능이 향상되지만 비용은 더 높다.

올-플래시 vSAN을 위한 하드웨어 선택 및 레이아웃

올-플래시 vSAN에서 모든 vSAN 쓰기는 먼저 캐싱 계층 SSD로 이동한 다음 용량 계층 SSD로 디스테이징되며, 읽기는 용량 계층 SSD에서 직접 전송된다(캐싱 계층 SSD에서 제공되는 아직 디스테이징되지 않은 데이터 읽기 제외).

캐싱 계층 SSD의 성능은 All-Flash vSAN의 전반적인 성능에서 중요한 요소다. 캐싱 계층에 고성능 클래스 NVMe 드라이브와 같은 고급 SSD를 사용하면 특히 용량 계층이 저성능 SSD를 사용하더라도 대규모 I/O 워크로드의 경우 성능이 크게 향상될 수 있다.

vSAN을 위한 하드웨어 선택 및 레이아웃 일반

vSAN 네트워크 고려 사항

vSAN 구성 및 사용

대부분의 경우 이러한 옵션은 리소스 사용과 성능 사이의 균형을 허용한다. 이것들은 아래 참조된 문서에 더 자세히 설명되어 있다.

vSAN 암호화

 

4. Virtual Infrastructure Management

VMware Virtual Volumes (VVols)

VMware Virtual Volumes(VVolumes)는 VMware 소프트웨어와 SAN 또는 NAS 스토리지 어레이 간의 통신을 사용하여 가상 머신 스토리지 정책을 보다 세부적으로 제어할 수 있다.

이 섹션의 권장 사항 외에도 각 벤더마다 권장 사항 또는 모범 사례가 있을 수 있으므로 스토리지 벤더의 설명서를 읽어 보는 것도 좋은 방법이다.

VVol 하드웨어 고려 사항

VASA 제공자가 가상 시스템에서 실행되는 경우:
- VVol 스토리지로 마이그레이션하지 않도록 주의한다.
- vSphere HA를 보호하기 위해 vSphere HA를 사용하는 것을 고려한다("VMware vSphere High Availability" 참조).
- 적절한 백업 계획을 구현한다.

VVol 워크로드 성능

VVol 워크로드는 관리 워크로드와 I/O 워크로드의 두 가지 주요 범주로 나뉜다.

VVol 관리 운영 성능

VVol 관리 작업에 적용되는 성능 권장 사항:

VVol I/O 작동 성능

VVol I/O 작업에 적용되는 성능 권장 사항:

VVol 구성 권장 사항