ESXi 스토리지 고려사항

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

vSphere 플래시 읽기 캐시(vFRC)

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

  • vSphere Flash Infrastructure 계층에 적합한 플래시 하드웨어를 선택한다("하드웨어 스토리지 고려 사항" 참조).
  • ESXi 호스트에 vSphere Flash Infrastructure 계층 생성(기본적으로 생성되지 않는다)
  • 가상 디스크를 생성할 때 해당 옵션을 선택하거나 나중에 사용하도록 설정하여 vFRC를 사용하도록 설정한다. (vFRC는 기본적으로 사용하도록 설정되지 않는다)
  • 캐시 크기를 적절하게 구성한다. 캐시는 활성 작업 세트를 유지할 수 있을 정도로 충분히 크지만 그리 크지 않은 것이 이상적이다. 필요 이상으로 큰 캐시를 구성하면 다른 vFRC 사용 가상 시스템이나 호스트 스왑 캐시에 플래시 공간을 사용할 수 없게 되어 성능이 저하될 수 있다. 가상 머신의 vMotion을 느리게 할 수도 있다.

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

  • 캐시 블록 크기를 적절하게 구성한다. 이는 일반적으로 워크로드의 I/O 크기와 일치해야 한다.

최적의 캐시 및 블록 크기를 결정하는 방법에 대한 지침을 포함하여 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가 대량 가상 시스템 프로비저닝 및 씬 프로비저닝 가상 디스크의 성능을 개선할 수 있는 경우), 기타 대규모 배치에서 특히 두드러질 수 있다.

  • SAN 스토리지 하드웨어가 VAAI를 지원하는 경우 ESXi는 이러한 기능을 자동으로 인식하고 사용할 수 있다.
  • NAS 스토리지 하드웨어가 VAAI를 지원하는 경우 ESXi는 벤더별 플러그인이 있는 경우에만 이러한 기능을 자동으로 인식하고 사용할 수 있다.

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

LUN 액세스 방법

  • ESXi에서는 RDM(원시 디바이스 매핑)을 지원하므로 원시 SCSI 디스크 또는 LUN을 VMFS 파일로 관리하고 액세스할 수 있다. RDM은 VMFS 볼륨의 특수 파일로 원시 디바이스의 프록시 역할을 한다. RDM 파일에는 물리적 디바이스에 대한 디스크 액세스를 관리하고 리디렉션하는 데 사용되는 메타데이터가 포함되어 있다. 대부분의 가상 디스크 스토리지에는 일반 VMFS가 권장되지만 경우에 따라 원시 디스크가 바람직할 수 있다.
    가상 호환성 모드 또는 물리적 호환성 모드에서 RDM을 사용할 수 있다.
  • 가상 모드는 매핑된 디바이스의 전체 가상화를 지정하여 게스트 운영 체제가 RDM을 VMFS 볼륨의 다른 가상 디스크 파일과 비슷하게 처리할 수 있도록 하고 VMware redo 로그를 사용하여 RDM의 스냅샷을 만들 수 있도록 허용한다.
  • 물리적 모드는 매핑된 디바이스의 SCSI 가상화를 최소화하여 가상 시스템에서 실행 중인 SAN 관리 소프트웨어 또는 기타 SCSI 대상 기반 소프트웨어에 대해 최대의 유연성을 허용한다.

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

가상 디스크 모드

  • ESXi는 세 가지 가상 디스크 모드를 지원함: 독립적인 지속성, 독립적인 비지속성 및 종속성.

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

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

  • 독립적인 영구(Independent persistent) – 이 모드에서는 변경사항이 디스크에 끈질기게 기록되어 최상의 성능을 제공한다.
  • 독립적인 비영구(Independent nonpersistent) – 이 모드에서는 디스크 쓰기가 redo 로그에 추가된다. 재실행 로그는 가상 시스템의 전원을 끄거나 스냅샷으로 되돌릴 때 지워져 디스크의 변경 내용이 모두 삭제된다. 가상 시스템이 독립적인 비영구 모드 디스크에서 읽을 때 ESXi는 먼저 redo 로그를 확인하고(재실행 로그에 포함된 디스크 블록의 디렉토리를 확인함) 관련 블록이 나열된 경우 해당 정보를 읽는다. 그렇지 않으면 가상 시스템의 기본 디스크로 읽기가 이동된다. 가상 시스템의 파일 시스템의 변경 내용을 추적하고 변경 내용을 커밋하거나 이전 시점으로 되돌릴 수 있는 이러한 redo 로그 때문에 독립적인 영구 모드 디스크만큼 성능이 높지 않을 수 있다.
  • 종속(Dependent) – 이 모드에서는 스냅샷이 생성된 경우 전원 주기 사이에 지속되는 redo 로그에 디스크 쓰기가 추가된다. 따라서 위에서 설명한 독립형 비영구 모드 디스크와 마찬가지로 종속형 모드 디스크 성능은 독립형 영구 모드 디스크만큼 높지 않을 수 있다. 그러나 스냅샷이 생성되지 않은 경우 종속 디스크는 독립 디스크만큼 빠르다.

가상 디스크 유형

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

  • 씩 프로비저닝(Thick provisioned) – 씩 가상 디스크는 더 빠르게 비워지(earger zeroed)는 것과 느리게 비워지(lazy-zeroed)는 두 가지 유형으로 나뉜다.

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

  • 빠르게 비워지는(Eager zeroed) – 빠르게 비워지는 씩 디스크는 생성 시에 모든 공간이 할당되고 비워진다. 이렇게 하면 디스크를 만드는 데 걸리는 시간이 늘어나지만 각 블록에 처음 쓰는 경우에도 최상의 성능을 발휘하게 된다.

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

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

  • Lazy zeroed - 느리게 비워지는 씩 디스크는 생성 시에 모든 공간이 할당되지만, 각 블록은 첫 번째 쓰기에만 영점 처리된다. 이렇게 되면 생성 시간은 짧아지지만 블록을 처음 쓸 때는 성능이 저하된다. 그러나 후속 쓰기는 빠르게 비워지는 씩 디스크와 같은 성능을 갖는다.

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

  • 씬 프로비저닝(Thin provisioned) - 씬 프로비저닝된 가상 디스크에 필요한 공간은 생성 시와는 달리 첫 번째 쓰기에 따라 할당되고 영점 처리된다. 쓰기되지 않은 파일 블록에 처음 쓰는 동안에는 I/O 비용이 더 높지만, 이후 쓰기 시 씬 프로비저닝된 디스크는 빠르게 비워지는 씩 디스크와 동일한 성능을 갖는다.

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 파티션에 대해 다음과 같은 사항을 권장한다:

  • 다른 디스크 기반 파일 시스템과 마찬가지로 VMFS 파일 시스템도 파티션이 정렬되지 않은 경우 성능 저하를 겪는다. ESXi 5.0부터는 VMFS3, VMFS5 또는 VMFS6 파티션을 1MB 경계에 따라 자동으로 정렬하므로 vSphere Client를 사용하여 VMFS 파티션을 생성하면 이 문제가 발생하지 않는다.

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

  • VMFS 파티션을 수동으로 정렬하려면 파티션 시작 블록 주소에 대한 스토리지 벤더의 권장 사항을 확인한다. 스토리지 벤더가 특별히 권장하지 않는 경우 시작 블록 주소로 8KB의 배수를 사용한다.
  • 정렬을 수행하기 전에 정렬되지 않은 VMFS 파티션이 특정 워크로드에 미치는 성능 영향을 주의 깊게 평가하기 바란다. 정렬의 개선 정도는 워크로드 및 어레이 유형에 따라 크게 달라진다. 자세한 내용은 어레이 벤더의 정렬 권장 사항을 참조하기 바란다.

SAN 다중 경로 지정

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

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

  • 대부분의 Active-Passive 스토리지 어레이의 경우 ESXi는 기본적으로 가장 최근에 사용한(MRU) 경로 정책을 사용한다. 액티브/패시브 스토리지 어레이에 대해 고정 경로 정책을 사용하는 것은 권장하지 않으며, 이는 LUN 액세스 속도를 저하시키는 빈번하고 빠른 경로 전환(종종 "경로 스레싱(path-thrashing)"이라고 함)을 초래할 수 있기 때문이다. ESXi가 MRU로 기본 설정되는 어레이의 성능을 최적화하려면 라운드 로빈 경로 정책(아래 설명)을 고려한다.

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

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

  • 대부분의 Active-Active 스토리지 어레이의 경우 ESXi는 기본적으로 고정 경로 정책을 사용한다. 이 정책을 사용할 때 서로 다른 스토리지 컨트롤러를 통해 각 LUN에 대한 기본 경로를 지정하여 스토리지 어레이에 대한 대역폭 활용도를 극대화할 수 있다. 이러한 어레이의 성능을 최적화하기 위해 라운드 로빈 경로 정책(아래 설명)도 고려할 수 있다.
  • ESXi는 일부 환경에서 스토리지 성능을 향상시킬 수 있는 라운드 로빈 경로 정책을 사용할 수 있다. 라운드 로빈 정책은 모든 활성 경로를 통해 I/O 요청을 순환시켜 로드 밸런싱을 제공하며, 각 경로를 통해 고정(그러나 구성 가능한) 수의 I/O 요청을 차례로 전송한다

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

  • ESXi는 타사 PSP(경로 선택 플러그인)도 지원한다. 어떤 경우에는 어레이의 특정 기능이나 설계 지식을 활용함으로써 특정 어레이에 최고의 성능을 제공할 수 있다.
    스토리지 어레이가 ALUA(Asymmetric Logical Unit Access)를 지원하는 경우 어레이에서 이 기능을 사용하도록 설정하면 일부 환경에서 스토리지 성능이 향상될 수 있다. ESXi에서 자동으로 감지되는 ALUA는 어레이 자체가 경로를 "Active Optimized"로 지정할 수 있도록 한다. ALUA를 라운드 로빈 경로 정책과 결합하면 ESXi는 기본적으로 Active Optimized 경로를 통해 I/O 요청을 순환시킨다.

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

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

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

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

  • 각 가상 디스크에 사용할 수 있는 데이터스토어의 I/O 리소스의 비율은 공유(share)를 사용하여 제어할 수 있다. 각 가상 디스크는 해당 가상 디스크의 공유와 동일한 데이터스토어 대역폭의 비율을 해당 호스트에 있는 모든 가상 디스크의 공유의 합으로 나눈다.
  • 각 가상 디스크에서 사용할 수 있는 최대 스토리지 I/O 리소스는 제한(Limit)을 사용하여 설정할 수 있다. IOPS(초당 입출력 작업 수)로 설정된 이러한 제한은 특정 워크로드에 대한 엄격한 격리 및 제어를 제공하는 데 사용될 수 있다. 기본적으로 무제한으로 설정되어 있다.

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

iSCSI 및 NFS 권장 사항

  • 가능한 경우 클라이언트와 서버 간에 iSCSI와 NFS에 대한 독립적인 네트워크 연결을 생성하는 것이 좋다.
    독립적인 연결이 실용적이지 않은 경우 VLAN을 사용하여 iSCSI 및 NFS 트래픽을 다른 네트워크 트래픽과 분리하는 것을 고려하기 바란다.
  • 소규모 iSCSI 및 NFS 구축은 1Gb/s 이더넷 링크에서 잘 수행되지만, 대부분의 구축은 10Gb/s 이상의 링크에서 가장 잘 수행될 것이다. NFS 구축에서는 링크 집계(link aggregation)를 사용하여 더 많은 대역폭을 제공할 수도 있다.
  • 가능하면 점보 프레임 사용을 고려한다.

NVMe 권장 사항

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

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

NVMe 성능 고려 사항:

  • 처리량을 최대화하려면 ESXi 호스트에서 고성능 플러그인(HPP)을 사용하도록 설정하십시오(HPP에 대한 자세한 내용은 vSphere Storage for vSphere 6.7에서 "고성능 플러그인"을 검색하기 바란다).
  • NVMe 디바이스는 고도로 병렬화되어 있으며, 최대 처리량은 일반적으로 여러 가상 디스크 및/또는 여러 가상 시스템을 지원할 때 달성된다.
    NVMe의 높은 처리량은 그에 상응하는 높은 CPU 로드를 생성한다. 따라서 NVMe 장치는 소켓당 코어 수가 많은 하드웨어 구성(최소 8개 이상)과 다중 소켓(최소 2개 이상)에 더 적합하다. 높은 CPU 주파수도 바람직하다.
  • 게스트 가상 시스템에서 사용하는 가상 스토리지 어댑터를 적절하게 선택해야 한다. 이러한 어댑터는 일반적으로 PVSCSI 또는 새로운 vNVMe 가상 어댑터 중 하나가 될 것이다. (자세한 내용은 "게스트 운영 체제 스토리지 고려 사항"을 참조하기 바란다.)

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

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

  • 가상 시스템 암호화의 리소스 오버헤드는 주로 CPU 활용도에 있다. 그러므로 충분한 CPU 리소스로, 일반적인 배포는 성능에 큰 영향을 미치지 않을 것이다. 그러나 충분한 CPU 리소스를 사용할 수 없는 경우(예를 들어, 더 빠른 스토리지 디바이스에 높은 IOPS를 유발하는 워크로드) 암호화를 활성화하면 성능에 영향을 미치기 시작할 수 있다.
  • VM 암호화로 인한 추가 CPU 활용도를 크게 최소화하려면 AES-NI를 지원하는 프로세서("AES-NI 지원" 참조)를 선택한다. 특히 AES-NI 구현이 더욱 최적화된 최신 프로세서 버전 중 하나를 선택한다.
  • BIOS에서 AES-NI가 사용하도록 설정되어 있는지 확인한다. 경우에 따라 AES-NI 지원을 위해 BIOS 업그레이드가 필요할 수 있다.
  • 암호화는 호스트에서 이루어지기 때문에 스토리지 디바이스는 암호화된 데이터만 볼 수 있다. 따라서 중복제거 또는 압축과 같은 일부 스토리지 장치의 특수 기능은 비효율적이거나 그 이점을 충분히 제공하지 못할 수 있다.(스토리지 수준에서 수행되는 암호화 옵션의 경우, 따라서 중복제거와 압축을 허용하려면 "VMware vSAN"을 참조하십시오.)

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

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

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

  • 각 LUN에 더 적은 가상 시스템을 프로비저닝하면 ESXi 서버가 어레이에 더 많은 I/O 요청을 동시에 제공할 수 있다. 이는 모든 어레이 리소스의 완전한 활용을 보장하고 어레이가 I/O를 최적화할 수 있는 더 많은 기회를 제공함으로써 성능을 개선할 수 있는 잠재력을 가지고 있다.
  • 반면에 너무 많은 LUN을 프로비저닝하는 경우, 특히 많은 ESXi 서버가 단일 어레이에 연결되어 있는 경우 ESXi 호스트가 너무 많은 I/O 요청을 동시에 보내 어레이 대기열을 채우고 어레이가 QFULL/BUSY 오류를 반환할 수 있다. 이는 거부된 I/O 요청을 재시도해야 하므로 성능이 저하될 수 있다.
  • I/O 지연 시간 통계는 디바이스 지연 시간, 커널에서 소요된 시간 및 게스트 운영 체제에서 볼 수 있는 지연 시간을 보고하는 esxtop(또는 resxtop)을 사용하여 모니터링할 수 있다.

  •  

    스토리지 디바이스의 평균 지연 시간이 너무 높지 않은지 확인한다. 이 지연 시간은 GAVG/cmd 메트릭을 통해 esxtop(또는 resxtop)에서 확인할 수 있다. 이 메트릭의 적절한 상위 값은 스토리지 하위 시스템에 따라 달라진다. Storage I/O Control("VMware vSphere Storage I/O Control" 내용)을 사용하는 경우 Storage I/O Control 설정을 가이드로 사용할 수 있다. GAVG/cmd 값은 Storage I/O Control 설정보다 훨씬 낮아야 한다. 기본 Storage I/O Control 설정은 30 ms이지만, 매우 빠른 스토리지(예: SSD)가 있는 경우 해당 값을 줄였을 수 있다. 평균 대기 시간에 대한 자세한 내용은 VMware KB 문서 1008205를 참조하기 바란다.

    VMFS 볼륨당 최대 미결 디스크 요청 수를 조정할 수 있으므로 해당 볼륨을 사용하는 가상 시스템 간의 대역폭을 균등화할 수 있다. 자세한 내용은 VMware KB 문서 1268을 참조하기 바란다.

  • QFULL/BUSY 오류가 자주 발생하는 경우 대기열 크기 조절을 사용하도록 설정하고 구성하면 스토리지 성능이 향상될 수 있다. 이 기능은 QFULL/BUSY 오류가 발생하여 어레이에서 반환되는 명령 수를 크게 줄일 수 있다. 특정 LUN 또는 스토리지 어레이 포트에 액세스하는 시스템에서 대기열 크기 조절을 사용하도록 설정한 경우 해당 LUN 또는 스토리지 어레이 포트에 액세스하는 모든 시스템(ESXi 호스트와 다른 시스템 모두)은 적응형 대기열 깊이 알고리즘을 사용해야 한다. QFULL/BUSY 오류와 이 기능에 대한 자세한 내용은 VMware KB 문서 1008113을 참조하기 바란다.

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

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

  • 호스트 전원 관리 설정 조정:
    최신 서버 하드웨어의 일부 전원 관리 기능은 스토리지 지연 시간을 증가시킬 수 있다. 다음과 같이 비활성화한다.
  • ESXi 호스트 전원 정책을 최대 성능("ESXi의 호스트 전원 관리"에서 설명한 대로 최대 성능으로 설정하거나 BIOS에서 전원 관리를 사용하지 않도록 설정하거나("전원 관리 BIOS 설정"에서 설명한 대로). 이것은 물론 전력 소비를 증가시키는 경향이 있다.
  • BIOS에서 C1E 및 기타 C-상태를 사용하지 않는다("전원 관리 BIOS 설정"에서 설명함). 이것 역시 전력 소비를 증가시키는 경향이 있다.
  • BIOS에서 Turbo Boost 활성화("일반 BIOS 설정"에서 설명).
  • 가상 시스템에서 LSILogic vHBA 또는 PVSCSI vHBA(하드웨어 버전 11 이상)를 사용하는 경우 reqCallThreshold 값을 조정할 수 있다.
  • reqCallThreshold 값이 낮을수록 I/O 요청이 vHBA 대기열에 남아 있을 가능성이 적다. 예를 들어 reqCallThreshold를 1로 설정하면 vHBA 대기열에 I/O 요청이 하나만 있을 때 I/O가 하위 계층으로 발송된다는 것을 의미한다. (기본 reqCallThreshold 값은 8임)
    reqCallThreshold 값을 줄이면 일반적으로 CPU 사용량이 증가한다. 또한 가상 디스크의 최대 처리량을 줄일 수 있는 잠재력이 있다.

    ReqCallThreshold 값을 조정하는 방법에는 두 가지가 있다.

  • 다음 명령을 실행하여 시스템의 모든 vHBA 값을 변경한다.
    esxcfg-advcfg -s x /Disk/ReqCallThreshold(여기서 x는 원하는 reqCallThreshold 값임).

  • 특정 vHBA에 대해 다음을 추가하여 시스템 전체 구성 재정의:
    scsiY.reqCallThreshold = X 를 .vmx 파일에 설정(여기서 Y는 대상 SCSI 번호, X는 원하는 rqCallThreshold 값).

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