Storage Best practices

많은 SQL Server 성능 문제의 원인은 부적절한 스토리지 구성에서 찾을 수 있습니다. SQL Server 워크로드는 일반적으로 I/O 집약적이며, 스토리지 하위 시스템이 잘못 구성되면 I/O 지연 시간이 증가하고 SQL Server의 성능이 크게 저하될 수 있습니다.

파티션 정렬

파일 시스템 파티션 정렬은 데이터베이스 워크로드에 대한 잘 알려진 스토리지 모범 사례입니다. 물리적 머신과 VMFS 파티션 모두에서 파티션을 정렬하면 정렬되지 않은 I/O로 인한 I/O 성능 저하를 방지할 수 있습니다. 파티션이 정렬되지 않으면 추가 I/O 작업이 발생하여 레이턴시 및 처리량에 불이익이 발생합니다. vSphere 5.0 이상에서는 1MB 경계를 따라 VMFS5 파티션이 자동으로 정렬됩니다. 64KB 경계를 따라 정렬된 이전 버전의 vSphere를 사용하여 VMFS3 파티션을 생성한 후 해당 파일 시스템을 VMFS5로 업그레이드하는 경우 64KB 정렬이 유지됩니다. 이러한 VMFS 볼륨은 다시 포맷해야 합니다. 1MB 정렬은 vSphere Web Client를 사용하여 VMFS 볼륨을 생성한 경우에만 수행할 수 있습니다.

이는 모범 사례로 간주됩니다:

• VMware vCenter™ 웹 클라이언트를 사용하여 VMFS 파티션을 생성합니다. 기본적으로 정렬됩니다.
• Windows Server 2008부터는 디스크가 1MB 경계에 자동으로 정렬됩니다. 필요한 경우 I/O 워크로드가 많은 경우 diskpart 명령을 사용하여 데이터 디스크를 정렬합니다.
• 하드웨어에 대한 정렬 권장 사항은 스토리지 공급업체에 문의하세요.

자세한 내용은 vSphere 6.5의 성능 모범 사례 백서(https://www.vmware.com/techpapers/2017/Perf_Best_Practices_vSphere65.html)를 참조하십시오.

VMDK 파일 레이아웃

VMFS에서 실행할 때 가상 머신 디스크 파일은 씬, zeroed thick, eagerzeroedthick의 세 가지 형식으로 배포할 수 있습니다. 씬 프로비저닝된 디스크는 디스크가 쓰여질 때 디스크 공간이 할당되고 제로화되는 100% 온디맨드 스토리지를 지원합니다. zeroed thick 디스크 스토리지는 미리 할당되지만 디스크를 처음 쓸 때 하이퍼바이저에 의해 블록이 제로화됩니다. zeroed thick 디스크는 프로비저닝 시간 동안 디스크가 초기화될 때 사전 할당되고 제로화됩니다. 런타임에 디스크를 제로화하는 데 추가 비용이 들지 않습니다.

씬 및 씩 옵션 모두 지연 제로화 기법을 사용하므로 디스크를 처음 쓰는 동안 성능 오버헤드 비용이 발생하지만 디스크 파일을 더 빠르게 생성할 수 있습니다. SQL Server 구성 및 워크로드 유형에 따라 성능 차이가 클 수 있습니다.

대부분의 경우 기본 스토리지 시스템이 “Zeroing File Blocks” 프리미티브가 활성화된 상태에서 VAAI(vSphere Storage APIs - Array Integration)를 통해 활성화된 경우 이 기능이 스토리지 하드웨어 수준에서 제로화 작업을 처리하므로 씩 프로비저닝된 씩 또는 씬을 사용하는 경우 성능 차이가 발생하지 않습니다. 또한 씬 프로비저닝된 디스크의 경우 기본 기능인 “Atomic Test & Set(ATS)“이 활성화된 VAAI는 파일 잠금 기능도 오프로드하여 새 블록 쓰기 성능을 향상시킵니다. 이제 대부분의 스토리지 시스템은 vSphere Storage APIs - Array Integration 기본 요소[64]를 지원합니다.

모든 플래시 어레이는 100% 씬 프로비저닝 메커니즘을 활용하여 온디맨드 스토리지를 사용할 수 있습니다. 그러나 vSphere에서는 특정 디스크 유형, 특히 이러한 디스크가 여러 VM 간에 공유되는 경우(상시 장애 조치 클러스터링 인스턴스 구성에서와 같이)에는 EagerZeroedThick vmdk를 사용해야 합니다. 가능하면 관리 효율성, 표준화 및 성능을 위해 Microsoft SQL Server 인스턴스의 트랜잭션 로그, TempDB 및 데이터 파일 볼륨에 사용되는 vmdk를 EagerZeroedThick으로 포맷할 것을 권장합니다.

장치 분리로 최적화

SQL Server 파일은 다음 표와 같이 다양한 디스크 액세스 패턴을 가지고 있습니다.

표 3. 일반적인 SQL Server 디스크 액세스 패턴

티어 1 미션 크리티컬 SQL Server를 배포할 때 SQL Server 바이너리, 데이터, 트랜잭션 로그, TempDB 파일을 별도의 저장 장치에 배치하면 유연성을 극대화하고 처리량과 성능을 크게 개선할 수 있습니다. SQL Server는 매우 다른 I/O 패턴으로 데이터 및 트랜잭션 로그 파일에 액세스합니다. 데이터 파일 액세스는 대부분 무작위로 이루어지는 반면, 트랜잭션 로그 파일 액세스는 대부분 순차적으로 이루어집니다. 스피닝 디스크 미디어로 구축된 기존 스토리지는 무작위 읽기 및 쓰기 액세스를 위해 디스크 헤드를 재배치해야 합니다. 따라서 순차적 데이터 액세스가 무작위 데이터 액세스보다 훨씬 더 효율적입니다. 랜덤 액세스 패턴이 다른 파일을 순차 액세스 패턴과 비교하여 분리하면 디스크 헤드 이동을 최소화할 수 있으므로 스토리지 성능을 최적화할 수 있습니다.

vSphere 6.7부터 vSphere는 PVSCSI(VMware Paravirtualized SCSI) 어댑터당 최대 64개의 SCSI 타겟을 지원하므로 VM당 최대 256개의 VMDK와 ESXi 호스트당 최대 4096개의 경로를 보유할 수 있습니다. vSphere 8에서는 PVSCSI 컨트롤러를 지원하는 데 필요한 드라이버가 최신 버전의 Windows OS에 기본 제공되므로 더 이상 이전과 같이 Windows OS 볼륨에 이전 LSI Logic SAS 컨트롤러를 사용할 필요가 없습니다. 관리자는 가능한 모든 4개의 PVSCSI 컨트롤러를 사용하여 할당된 디스크를 VM에 분산시킴으로써 PVSCSI의 우수한 성능 기능과 증가된 용량을 모두 활용하여 SQL Server 스토리지 I/O 요구 사항을 최적화할 수 있습니다.

다음 지침을 따르면 최상의 성능을 달성하는 데 도움이 될 수 있습니다:

• SQL Server 데이터(시스템 및 사용자), 트랜잭션 로그, 백업 파일을 가급적 별도의 데이터스토어에 별도의 VMDK에 배치합니다. SQL Server 바이너리는 일반적으로 OS VMDK에 설치됩니다. SQL Server 설치 파일을 데이터 및 트랜잭션 로그에서 분리하면 백업, 관리 및 문제 해결에 더 나은 유연성을 제공합니다.
• 성능 요구 사항이 다른 모든 요구 사항보다 우선하는 가장 중요한 데이터베이스의 경우, VMDK와 LUN 간의 1:1 매핑을 유지하세요. 이렇게 하면 워크로드 격리가 향상되고 데이터스토어 수준에서 스토리지 경합이 발생할 가능성을 방지할 수 있습니다. 물론 기본 물리적 디스크 구성이 I/O 및 레이턴시 요구 사항도 수용해야 합니다. 관리 효율성이 우려되는 경우, 기본 물리적 디바이스가 모든 VMDK의 집계된 I/O 요구 사항을 수용할 수 있는지 확인하면서 유사한 I/O 특성을 가진 VMDK와 SQL Server 파일을 공통 LUN에 그룹화합니다.
• 기본 스토리지의 경우, 해당되는 경우 RAID 10은 사용자 데이터, 트랜잭션 로그 파일 및 TempDB에 대해 최상의 성능과 가용성을 제공할 수 있습니다.

하위 티어 SQL Server 워크로드의 경우 다음을 고려하십시오:

• VMFS에 여러 개의 하위 티어 SQL Server 시스템을 배포하면 템플릿 복제, 스냅샷, 스토리지 통합을 보다 쉽게 관리 및 운영할 수 있습니다.
• VMFS의 성능 관리. VMFS에 있는 모든 VM의 총 IOPS 요구 사항은 기본 물리적 디스크의 IOPS 성능을 초과하지 않아야 합니다.
• 사전 정의된 규칙에 따라 데이터스토어 간 자동 로드 밸런싱을 위해 vSphere Storage DRS™(SDRS)를 사용하여 공간을 제공하고 I/O 병목 현상을 방지합니다. VM을 이동하는 동안 성능 저하를 방지하려면 사용량이 많지 않은 시간에 SDRS 호출을 예약하는 것이 좋습니다.[65]

스토리지 컨트롤러 사용

데이터 및 로그 VMDK를 위한 가상 SCSI 컨트롤러로 VMware PVSCSI(Paravirtualized SCSI) 컨트롤러를 활용합니다. PVSCSI 컨트롤러는 vSphere의 I/O 집약적인 애플리케이션을 위한 최적의 SCSI 컨트롤러로, LSI Logic SAS 컨트롤러에 비해 더 높은 I/O 속도를 제공할 뿐만 아니라 CPU 소비도 낮춥니다. 또한 PVSCSI 어댑터는 더 높은 대기열 깊이를 제공하여 가상화된 워크로드에 대한 I/O 대역폭을 증가시킵니다. 자세한 내용은 OS 구성 섹션을 참조하십시오.

여러 PVSCSI 어댑터 사용. VM당 최대 4개의 어댑터를 구성하는 것이 지원됩니다. OS, 데이터 및 트랜잭션 로그를 별도의 vSCSI 어댑터에 배치하면 여러 대상 디바이스에 부하를 분산하고 운영 체제 수준에서 더 많은 대기열을 허용하여 I/O를 최적화할 수 있습니다. 컨트롤러 간에 디스크를 균등하게 분배하는 것을 고려하십시오. vSphere는 컨트롤러당 최대 64개의 디스크를 지원합니다[66].

vSphere 6.5에서는 새로운 유형의 가상 컨트롤러인 vNVMe[67]가 도입되었습니다. 이후 vSphere가 릴리스될 때마다 여러 차례 성능이 크게 향상되었습니다. NVMe 컨트롤러는 특히 올플래시 스토리지 또는 퍼시스턴트 메모리의 낮은 레이턴시 SSD 드라이브와 함께 사용하면 성능을 개선하고 I/O 처리 오버헤드를 줄일 수 있습니다. 프로덕션 데이터베이스의 대표 사본을 사용하여 구성을 테스트하여 이 변경 사항이 도움이 되는지 확인해 보십시오. 가상 하드웨어 14 이상은 vNVMe 컨트롤러를 구현하는 데 강력히 권장됩니다.

스냅샷 사용

VM 스냅샷은 특정 시점의 가상 머신의 상태와 데이터를 보존합니다.[68] 스냅샷이 생성되면 가상 머신의 전원 상태와 가상 디스크를 포함한 모든 디바이스의 상태가 저장됩니다. 스냅샷 생성 후 가상 디스크의 변경 사항을 추적하기 위해 디스크의 블록 레벨 변경 사항에 대한 지속적인 기록을 포함하는 특수 “델타” 파일이 사용됩니다[69]. 스냅샷은 백업 소프트웨어 또는 인프라스트럭처 관리자와 DBA가 변경 사항(예: SQL Server 애플리케이션 업그레이드 또는 패치 설치)을 구현하기 전에 가상 머신의 상태를 보존하기 위해 널리 사용됩니다.

그림 61. 스냅샷 만들기 옵션

다음은 SQL Server 인스턴스를 호스팅하는 VM에서 스냅샷을 생성할 때 고려해야 할 몇 가지 모범 사례와 고려 사항입니다:

1. 오프라인 스냅샷(스냅샷을 생성할 때 VM의 전원이 꺼져 있음)은 특별한 고려 사항 없이 사용할 수 있습니다.
2. 온라인 스냅샷(VM의 전원이 켜져 있고 게스트 OS가 실행 중)을 만들어야 하는 경우:

• “가상 머신의 메모리 스냅샷” 옵션은 VM을 중단시킬 수 있으므로 사용하지 않는 것이 좋습니다[70]. 인메모리 데이터 손실로 인한 데이터 손실을 방지하기 위해 SQL Server 메커니즘을 활용합니다.
• 디스크 일관성 스냅샷이 생성되도록 하려면 “게스트 파일 시스템 대기” 옵션을 사용하세요. 특별 참고 사항:
  • VMware Tools가 설치되어 있지 않거나 작동하지 않는 경우 디스크 상태가 일관되지 않을 수 있으므로 온라인 스냅샷을 생성하지 않는 것이 좋습니다.
  • 스냅샷을 생성하기 전에 Windows OS에서 VSS 서비스 상태를 확인하는 것이 좋습니다.
• 디스크 작업 횟수가 많은 SQL Server 인스턴스의 경우 스냅샷 작업(온라인 스냅샷 생성, 온라인 스냅샷 제거)에 시간이 오래 걸릴 수 있으며 잠재적으로 성능 문제를 일으킬 수 있습니다[71]. 사용량이 많지 않은 시간대에 스냅샷 작업을 사용하거나, 오프라인 스냅샷 생성/제거를 사용하거나, 스토리지 어레이 수준의 스냅샷 통합과 함께 vVol 기술을 사용하는 것을 고려하십시오.

3. 스냅샷에서 SQL Server를 호스팅하는 VM을 72시간 이상 실행하지 마십시오[72].
4. 스냅샷은 백업을 대체할 수 없습니다. 델타 디스크 파일에는 변경 사항에 대한 참조만 포함되며 변경 사항 자체는 포함되지 않습니다.
5. 성능 향상을 위해 VMFS6 및 SEsparce 스냅샷을 사용하는 것을 고려하십시오.

vSAN OSA(Original Storage Architecture)[73]

vSAN은 하이퍼 컨버지드 인프라를 위한 VMware 소프트웨어 정의 스토리지 솔루션으로, x86 서버에서 긴밀하게 통합된 컴퓨팅, 네트워킹 및 공유 스토리지를 제공하는 소프트웨어 중심 아키텍처입니다. vSAN은 고성능, 고탄력성 공유 스토리지를 제공합니다. vSphere와 마찬가지로 vSAN은 사용자에게 다양한 하드웨어 옵션 중에서 선택할 수 있는 유연성과 제어 기능을 제공하며 다양한 IT 워크로드 및 사용 사례에 맞게 쉽게 배포 및 관리할 수 있습니다.

그림 62. VMware vSAN의 기존 스토리지 아키텍처

vSAN은 하이브리드 또는 올플래시 스토리지로 구성할 수 있습니다. 하이브리드 디스크 아키텍처에서 vSAN 하이브리드는 성능을 위해 플래시 기반 디바이스를 활용하고 용량을 위해 자기 디스크를 활용합니다. 올플래시 vSAN 아키텍처에서 vSAN은 쓰기 버퍼와 영구 스토리지 모두에 플래시 기반 디바이스(PCIe SSD 또는 SAS/SATA SSD)를 사용할 수 있습니다. 올플래시 아키텍처에서는 읽기 캐시를 사용할 수 없거나 필요하지 않습니다. vSAN은 중앙 집중식으로 관리되는 애플리케이션 중심 스토리지 서비스 및 기능을 제공하기 위해 SPBM 기능을 활용하는 분산형 오브젝트 스토리지 시스템입니다. 관리자는 용량, 성능, 가용성과 같은 스토리지 속성을 VMDK 단위로 정책으로 지정할 수 있습니다. 이 정책은 시스템을 동적으로 자체 조정하고 로드 밸런싱하여 각 VM이 적절한 수준의 리소스를 보유하도록 합니다.

하이브리드 vSAN에 SQL Server가 포함된 VM을 배포할 때는 다음 사항을 고려하십시오:

• 비즈니스 요구 사항에 맞게 vSAN 노드 구축 - vSAN은 소프트웨어 솔루션입니다. 따라서 고객은 자신의 특정 요구 사항에 맞게 사용자 지정한 vSAN 노드를 “처음부터” 설계할 수 있습니다. 이 경우 비즈니스 요구 사항에 맞는 적절한 하드웨어 구성 요소를 사용하는 것이 필수적입니다.

• 용량 계획 - 시스템 처리량을 늘리려면 여러 디스크 그룹을 사용하는 것이 좋으며 초기 단계에서 구현하는 것이 가장 좋습니다.

• 성능 계획 - OLTP 애플리케이션의 I/O 액세스를 수용하기 위해 캐싱 계층에 충분한 공간을 확보하는 것이 중요합니다. 일반적으로 각 호스트의 캐싱 계층으로 SSD를 전체 스토리지 용량의 10% 이상 사용하는 것이 좋습니다. 그러나 대부분 임의의 I/O 액세스 패턴에 대해 고성능이 필요한 경우에는 SSD 크기를 작업 세트의 최소 2배로 설정할 것을 권장합니다.

• SQL Server 미션 크리티컬 사용자 데이터베이스의 경우 다음 권장 사항을 사용하여 SSD 크기를 설계하십시오:

  • 활성 사용자 데이터베이스를 캐시하기 위한 SSD 크기. TPC-E와 유사한 OLTP의 I/O 액세스 패턴은 작고(8KB가 지배적), 무작위적이며 읽기 집약적입니다. 보조 워크로드의 읽기 전용 워크로드 및 로그 강화 워크로드를 지원하려면 기본 및 보조 데이터베이스의 두 배 크기를 사용하는 것이 좋습니다. 예를 들어 100GB 사용자 데이터베이스의 경우 2 x 2 x 100GB SSD 크기를 설계합니다.
  • 설계된 IOPS를 지원할 수 있는 적절한 SSD 클래스를 선택합니다. 읽기 집약적인 OLTP 워크로드의 경우 SSD의 지원되는 IOPS는 SSD 등급에 따라 달라집니다. 잘 조정된 TPC-E와 같은 워크로드의 경우 쓰기 비율이 10%일 수 있습니다.

• 가용성을 계획하세요. 장애 발생 시 클러스터가 자동으로 문제를 해결할 수 있도록 3개 이상의 호스트와 추가 용량을 설계하세요. SQL Server 미션 크리티컬 사용자 데이터베이스의 경우 상시 켜짐을 활성화하여 상시 켜짐이 동기식 모드일 때 데이터베이스를 고가용성 상태로 전환합니다. FTT를 1보다 크게 설정하면 vSAN 디스크에 대한 쓰기 복사본이 더 많아집니다. 특별한 데이터 보호가 필요하지 않는 한 FTT=1은 AlwaysOn을 사용하도록 설정한 대부분의 미션 크리티컬 SQL Server 데이터베이스를 충족할 수 있습니다.

• 적절한 SPBM 설정. vSAN SPBM은 VM별로 가용성, 용량 및 성능 정책을 설정할 수 있습니다:

• 오브젝트 공간 예약을 설정합니다. 100%로 설정합니다. 용량은 vSAN 데이터스토어에서 예약됩니다.

• 오브젝트당 디스크 스트라이프 수. 오브젝트당 디스크 스트라이프 수를 스트라이프 너비라고도 합니다. 스토리지 개체의 복제본이 분산되는 최소 용량 디바이스 수를 정의하는 vSAN 정책의 설정입니다. vSAN은 개체당 최대 12개의 스트라이프를 생성할 수 있습니다. 스트라이핑은 가상 머신이 OLTP 데이터베이스와 같은 I/O 집약적인 애플리케이션을 실행하는 경우 성능에 도움이 될 수 있습니다. SQL Server OLTP 워크로드를 위한 하이브리드 vSAN 환경을 설계할 때는 단순히 스트라이프 폭을 늘리는 것보다 더 많은 백업 HDD와 함께 여러 SSD를 활용하는 것이 더 중요합니다. 다음 조건을 고려하십시오:

  • 더 많은 SSD로 더 많은 디스크 그룹을 구성할 수 있는 경우 가상 디스크의 스트라이프 폭 번호를 크게 설정하면 데이터 파일을 여러 디스크 그룹으로 분산하여 디스크 성능을 향상시킬 수 있습니다.
  • 스트라이프 너비 숫자가 클수록 255GB보다 큰 가상 디스크를 더 많은 디스크 구성 요소로 분할할 수 있습니다. 그러나 vSAN은 증가된 디스크 구성 요소가 여러 디스크 그룹에 분산되어 각 구성 요소가 하나의 HDD 디스크에 저장된다는 것을 보장할 수 없습니다. 동일한 VMDK의 여러 디스크 구성 요소가 동일한 디스크 그룹에 있는 경우 증가된 구성 요소 수는 해당 가상 디스크의 SSD가 아닌 더 많은 백업된 HDD에만 분산되므로 스트라이프 폭을 늘려도 스테이징 해제 성능 문제가 없는 한 성능이 향상되지 않을 수 있습니다.

• 데이터베이스 크기에 따라 VMware는 하나의 VM에 여러 개의 VMDK를 사용할 것을 권장합니다. 여러 VMDK를 사용하면 데이터베이스 구성 요소가 vSAN 클러스터의 디스크 그룹에 분산됩니다.

• 올플래시 vSAN에서 TPC-E와 같은 읽기 집약적인 OLTP 데이터베이스의 경우 테이블 및 인덱스를 비롯한 데이터에서 가장 많은 공간이 필요하며 트랜잭션 로그에 필요한 공간은 데이터 크기에 비해 작은 경우가 많습니다. VMware는 SQL Server의 데이터 및 트랜잭션 로그용 가상 디스크에 대해 별도의 vSAN 정책을 사용할 것을 권장합니다. 데이터의 경우 VMware는 공간 사용량을 2배에서 1.33배로 줄이기 위해 RAID 5를 사용할 것을 권장합니다. TPC-E와 유사한 워크로드를 테스트한 결과 RAID 5 구성이 우수한 디스크 성능을 달성하는 것으로 확인되었습니다. 트랜잭션 로그를 위한 가상 디스크와 관련하여 VMware는 RAID 1을 사용할 것을 권장합니다.

• VMware는 다양한 스트라이프 폭을 사용하여 올플래시 vSAN에 미치는 성능 영향을 측정했습니다. 요약하면, 기본적으로 클러스터에서 데이터를 분산하여 리소스를 더 잘 활용하는 하나의 데이터베이스에 여러 개의 가상 디스크를 활용한 결과, 스트라이프 폭을 추가해도 TPC-E와 같은 성능은 뚜렷한 개선이나 저하가 없었습니다. VMware는 올플래시 vSAN에서 200GB 데이터베이스에 대해 다양한 스트라이프 폭(1~6, 12)을 테스트한 결과 다음과 같은 결과를 확인했습니다:

  • TPS, 트랜잭션 시간 및 응답 시간은 모든 구성에서 비슷했습니다.
  • 가상 디스크 레이턴시는 모든 테스트 구성에서 2밀리초 미만이었습니다.

• VMware는 디스크 개체를 여러 구성 요소로 분할하여 개체 구성 요소를 다른 디스크 그룹의 더 많은 디스크에 배포하기 위해 필요에 따라 스트라이프 너비를 설정할 것을 제안합니다. 일부 상황에서는 대규모 가상 디스크에 이 설정이 필요할 수 있습니다.

• 데이터베이스 복원 작업에 서비스 품질 사용. vSAN 6.2에는 오브젝트가 사용할 수 있는 IOPS 수를 제한하는 정책을 설정하는 QoS 기능이 도입되었습니다. 이 솔루션의 순차적 I/O 우세 데이터베이스 복원 작업에서 QoS 기능이 검증되었습니다. IOPS를 제한하면 동시 데이터베이스 복원 작업의 전체 지속 시간에 영향을 미칩니다. 데이터베이스 유지 관리와 같이 I/O 집약적인 작업과 성능 경합이 있는 동일한 vSAN의 다른 애플리케이션은 QoS의 이점을 누릴 수 있습니다.

• vSAN 6.7은 WSFC(Windows Server 장애 조치 클러스터)[74]를 지원하도록 vSAN iSCSI 서비스의 유연성을 확장합니다.

• vSAN 6.7 Update 3은 vSAN native for SQL Server를 사용하여 노출된 공유 대상 스토리지 위치를 통해 Windows SQL Server Failover Clusters Instances (FCI)에 대한 지원을 확장합니다[75].

vSAN ESA(Express Storage Architecture)[76]

vSAN 8.0은 새로운 수준의 효율성, 확장성 및 성능을 모두 갖춘 데이터를 처리하고 저장하도록 설계된 vSAN의 선택적 대체 아키텍처로 ESA(Express Storage Architecture)를 도입했습니다. 이 선택적 아키텍처는 최신 하드웨어의 모든 기능을 활용하도록 최적화되어 있으며 클러스터를 생성할 때 vSAN ESA를 선택할 수 있습니다.

vSAN 8 ESA는 디스크 그룹, 개별 캐싱 및 용량 계층의 개념을 뛰어넘어 사용자가 vSAN용 스토리지 디바이스를 호스트의 스토리지 풀에 추가하여 모든 디바이스가 vSAN의 용량에 기여하는 “스토리지 풀"로 클레임할 수 있도록 발전했습니다. 이렇게 하면 드라이브의 서비스 가용성과 데이터 가용성 관리가 개선되고 비용을 절감할 수 있습니다.

그림 63. VMware vSAN Express 스토리지 아키텍처

vSAN Express 스토리지 아키텍처는 최신 세대의 하드웨어로 전환하는 고객에게 이상적인 반면, vSAN 기존 아키텍처는 클러스터를 최신 버전으로 업그레이드할 때 기존 하드웨어를 가장 효과적으로 활용할 수 있는 좋은 방법입니다. vSAN Express Storage Architecture에 SQL Server가 포함된 VM을 배포할 때는 다음 측면을 고려하십시오:

• 삭제 코딩 - Express 스토리지 아키텍처는 RAID-1 미러링의 성능으로 RAID-5/6 삭제 코딩의 공간 효율성을 제공합니다. SQL Server 데이터 파일, 트랜잭션 로그 및 TempDB 파일에 대해서도 용량과 성능의 절충점을 고려해야 하는 경우 Express 스토리지 아키텍처를 권장합니다.

• 공간 효율성(압축) - 용량에 민감한 SQL Server 데이터베이스의 경우, Express 스토리지 아키텍처는 압축 전용 기능인 Original 스토리지 아키텍처에 비해 더 나은 압축률을 달성합니다. 또한 더 작은 단위의 SQL Server 가상 디스크에 대한 정책 기반 데이터 압축도 가능합니다.

• 스냅샷 - 익스프레스 스토리지 아키텍처는 새로운 기본 확장형 스냅샷 기능을 통해 매우 빠르고 일관된 성능을 제공합니다. 이를 통해 성능 오버헤드를 최소화하면서 SQL Server 가상 머신을 위한 가상 머신 기반 스냅샷 백업 솔루션을 구현할 수 있습니다.

• 올플래시 어레이 사용 시 고려 사항 올플래시 스토리지는 일반적으로 성능 때문에 기업 데이터 센터에서 점점 더 인기를 얻고 있지만, 최신 세대의 올플래시 스토리지는 다음과 같은 이점도 제공합니다:

• 씬 프로비저닝, 인라인 데이터 중복 제거, 인라인 데이터 압축과 같은 내장형 데이터 서비스를 통해 강력한 데이터 절감률을 제공합니다.

• 기존 RAID 방법론을 대체하는 플래시 최적화 데이터 보호는 데이터베이스 서버 사이징 및 용량 계획 작업을 간소화하는 동시에 보호 오버헤드와 성능 저하를 최소화할 수 있습니다.

• VSS 통합을 통해 공간 효율적인 복제본을 즉시 생성하여 SQL Server의 효율성과 운영 민첩성을 크게 향상시키고 로컬 데이터 보호에 사용할 수 있습니다.

성능 측면에서 볼 때, 부하가 높을 때에도 밀리초 미만의 레이턴시를 일관되게 유지하고 공유 환경에서 선형적으로 확장할 수 있는 기능으로 인해 올플래시 어레이에 대한 관심이 점점 더 높아지고 있습니다. EMC에서 수행한 XtremIO 기반 SQL Server에 대한 연구에서 EMC는 듀얼 X-Brick XtremIO 클러스터에서 8개의 SQL Server 워크로드를 실행했습니다. 각 OLTP 유사 워크로드는 주식 거래 애플리케이션을 시뮬레이션하고 90%의 읽기 및 10%의 쓰기로 구성된 일반적인 SQL Server 온라인 트랜잭션 워크로드의 I/O 활동을 생성합니다. SQL Server 인스턴스 수가 1, 2, 4, 8개로 증가함에 따라 총 집계된 IOPS는 각각 22K, 45K, 95K, 182K로 증가하지만 레이턴시는 약 500µs의 일관된 레이턴시를 유지합니다.

그림 64. 통합 SQL Server를 사용한 XtremIO 성능

이 연구에 대한 자세한 내용은 EMC XtremIO에서 SQL Server를 실행하기 위한 모범 사례 문서(http://www.emc.com/collateral/white-paper/h14583-wp-best-practice-sql-server-xtremio.pdf)를 참조하십시오.

올플래시 어레이에서 SQL Server를 설계할 때는 기존 스토리지 시스템과 다른 스토리지 및 파일 레이아웃에 대해 고려해야 할 사항이 있습니다. 이 섹션에서는 올플래시 스토리지 설계의 두 가지 측면에 대해 설명합니다:

• RAID 구성
• SQL Server 파일 분리

레이드 구성

올플래시 어레이에 SQL Server 를 구축할 때 기존의 RAID 구성 고려 사항은 더 이상 적합하지 않으며, 각 공급업체마다 고려해야 할 고유한 최적화 기술이 있습니다. XtremIO 를 예로 들면, XtremIO 시스템은 아키텍처의 일부로 “자가 복구” 이중 패리티 RAID 를 내장하고 있습니다. XDP(XtremIO Data Protection)는 플래시 미디어별 특성을 활용하도록 설계되었으므로 특정 RAID 구성이 필요하지 않습니다.

파일 분리

I/O 집약적인 트랜잭션 SQL Server 워크로드에 대한 매우 일반적인 스토리지 I/O 최적화 전략은 다양한 I/O 파일 유형(TempDB, 데이터 및 로그)을 어레이 수준에서 가능한 한 많은 여러 볼륨, 디스크, LUN, 심지어 물리적 디스크 그룹으로 논리적으로 분리하는 것입니다. 이러한 과거 권장 사항의 주된 근거는 레이턴시를 줄이고 응답성을 향상하며 관리, 문제 해결 및 장애 격리를 보다 쉽게 하기 위해 다양한 I/O 유형을 병렬로 구성해야 한다는 것입니다.

올플래시 스토리지 어레이는 이 권장 사항과 다른 차원을 도입합니다. 올플래시 어레이는 일반적으로 움직이는 부품이 없는 솔리드 스테이트 디스크(SSD)를 활용하므로 기존 디스크 서브시스템과 관련된 성능 비효율을 경험하지 않습니다. 최신 SSD 기반 어레이의 최적화된 데이터 저장 및 검색 알고리즘은 물리적 스토리지 장치에서 특정 데이터 블록의 물리적 위치를 기존 스토리지 어레이에 비해 덜 신경 쓰게 만듭니다. 올플래시 어레이에서 SQL Server 데이터, 트랜잭션 로그 및 TempDB 파일에 대해 서로 다른 LUN 또는 디스크 그룹을 할당해도 이러한 최신 어레이에서 성능에 큰 차이가 발생하지 않습니다.

그럼에도 불구하고 VMware는 기업 규정에서 명시적으로 금지하지 않는 한 고객이 올플래시 스토리지 어레이를 사용하는 경우에도 vSphere의 트랜잭션이 많은 SQL Server 가상 머신에 할당된 TempDB 볼륨에 대한 가상 디스크를 분리할 것을 권장합니다. TempDB는 SQL Server 인스턴스 내의 모든 데이터베이스에서 공유되는 글로벌 리소스입니다. SQL Server 인스턴스가 시작될 때마다 다시 생성되는 임시 작업 공간입니다. TempDB 디스크를 다른 디스크 유형(데이터 또는 로그)과 분리하면 고객은 이러한 사용 사례에 필요하지 않은 TempDB 파일을 포함하지 않고도 데이터 서비스(예: 복제, 재해 복구 및 스냅샷)를 데이터베이스 및 트랜잭션 로그 볼륨에 적용할 수 있습니다.

올플래시 어레이에서 미션 크리티컬 SQL 서버를 위한 스토리지 레이아웃을 최적으로 설계하기 위한 추가 고려 사항은 스토리지 벤더마다 다릅니다. VMware는 고객이 디스크 배치 결정을 내릴 때 스토리지 공급업체에 문의하여 최상의 지침을 얻을 것을 권장합니다.