Azure NetApp Files의 Azure VMware Solution 데이터베이스 성능 고려 사항
이 문서에서는 Azure NetApp Files와 함께 사용할 때 Azure VMware Solution 데이터 저장소 디자인 및 크기 조정에 대한 성능 고려 사항을 제공합니다. 이 콘텐츠는 가상화 관리자, 클라우드 설계자 또는 스토리지 설계자에게 적용됩니다.
이 문서에 설명된 고려 사항은 최적화된 비용 효율성으로 애플리케이션에서 최고 수준의 성능을 달성하는 데 도움이 됩니다.
Azure NetApp Files는 Azure VMware Solution에 대해 즉시 확장 가능하고 고성능이며 매우 안정적인 스토리지 서비스를 제공합니다. 테스트에는 Azure VMware Solution과 Azure NetApp Files 간의 다양한 구성이 포함되었습니다. 이 테스트는 4개의 Azure VMware Solution/ESXi 호스트와 단일 Azure NetApp Files 용량 풀을 사용하여 10,500MiB/s 이상 및 초당 585,000개 이상의 IOPS(입력/출력 작업)를 구동할 수 있었습니다.
Azure NetApp Files를 사용하여 Azure VMware Solution의 스토리지 성능 향상
한 서비스 수준에서 잠재적으로 더 큰 여러 개의 데이터 저장소를 프로비전하면 성능이 향상되는 동시에 비용이 적게 들 수 있습니다. 그 이유는 Azure VMware Solution 호스트에서 여러 데이터 저장소로 여러 TCP 스트림에 부하를 분산하기 때문입니다. Azure VMware Solution TCO Estimator용 Azure NetApp Files 데이터 저장소를 사용하여 RVTools 보고서를 업로드하거나 수동 평균 VM 크기 조정을 입력하여 잠재적 비용 절감을 계산할 수 있습니다.
데이터 저장소를 구성하는 방법을 결정할 때 관리 관점에서 가장 쉬운 솔루션은 단일 Azure NetApp Files 데이터 저장소를 만들고, 탑재하고, 모든 VM을 배치하는 것입니다. 이 전략은 더 많은 처리량 또는 IOPS가 필요할 때까지 많은 상황에서 잘 작동합니다. 다른 경계를 식별하기 위해 테스트에서는 가상 워크로드 생성기인 fio
프로그램을 사용하여 이러한 각 시나리오에 대한 워크로드의 범위를 평가했습니다. 이 분석을 통해 Azure NetApp Files 볼륨을 데이터 저장소로 프로비전하여 성능을 최대화하고 비용을 최적화하는 방법을 결정할 수 있습니다.
시작하기 전에
Azure NetApp Files 성능 데이터에 대해서는 다음을 참조하세요.
Azure NetApp Files: 클라우드 스토리지를 최대한 활용
Azure VMware Solution 호스트에서는 섹션 6(튜닝 옵션)에서 참조된 Linux 테스트에서 사용하는
nconnect=1
것과 비슷한 NFS 데이터 저장소당 단일 네트워크 연결이 설정됩니다. 이 사실은 Azure VMware Solution이 여러 데이터 저장소에서 성능의 크기를 조정하는 방법을 이해하는 데 중요합니다.Azure VMware Solution에 대한 Azure NetApp Files 데이터 저장소 성능 벤치마크
테스트 방법론
이 섹션에서는 테스트에 사용되는 방법론에 대해 설명합니다.
테스트 시나리오 및 반복
이 테스트는 각 순차 및 임의 IO(입출력)에 대한 읽기 작업과 쓰기 작업을 모두 포함하는 "네 모서리" 방법론을 따릅니다. 테스트의 변수에는 일대다 Azure VMware Solution 호스트, Azure NetApp Files 데이터 저장소, VM(호스트당) 및 VM당 VM 디스크(VMDK)가 포함됩니다. 지정된 시나리오에 대한 최대 처리량 및 IOPS를 찾기 위해 다음과 같은 확장 데이터 요소가 선택되었습니다.
- 단일 VM에 대해 각각 자체 데이터 저장소에 있는 VMDK 확장.
- 단일 Azure NetApp Files 데이터 저장소의 호스트당 VM 수 확장.
- 각각 하나의 VM이 단일 Azure NetApp Files 데이터 저장소를 공유하는 Azure VMware Solution 호스트의 수를 조정합니다.
- 각각 하나의 VMDK를 사용하여 Azure VMware Solution 호스트에 동일하게 분산된 Azure NetApp Files 데이터 저장소의 수를 조정합니다.
소규모 및 대규모 블록 작업을 모두 테스트하고 순차 및 임의 워크로드를 반복하면 컴퓨팅, 스토리지 및 네트워크 스택의 모든 구성 요소를 "에지"로 테스트할 수 있습니다. 블록 크기 및 임의 추출로 네 모서리를 커버하기 위해 다음과 같은 일반적인 조합이 사용됩니다.
- 64KB 순차 테스트
- 대용량 파일 스트리밍 워크로드는 일반적으로 큰 블록 크기로 읽고 쓰며 기본 MSSQL 익스텐트 크기입니다.
- 큰 블록 테스트는 일반적으로 가장 높은 처리량(MiB/s)을 생성합니다.
- 8KB 임의 테스트
- 이 설정은 Microsoft, Oracle, PostgreSQL의 소프트웨어를 포함한 데이터베이스 소프트웨어에 일반적으로 사용되는 블록 크기입니다.
- 작은 블록 테스트는 일반적으로 가장 많은 수의 IOPS를 생성합니다.
참고 항목
이 문서에서는 Azure NetApp Files의 테스트만 다룹니다. Azure VMware Solution에 포함된 vSAN 스토리지는 다루지 않습니다.
환경 세부 정보
이 문서의 결과는 다음과 같은 환경 구성을 사용하여 얻었습니다.
- Azure VMware Solution 호스트:
- 크기: AV36
- 호스트 개수: 4
- VMware ESXi 버전 7u3
- Azure VMware Solution 프라이빗 클라우드 연결: FastPath를 사용한 UltraPerformance 게이트웨이
- 게스트 VM:
- 운영 체제: Ubuntu 20.04
- CPU/메모리: vCPU/64GB 메모리 16개
- Azure VMware Solution vSAN 데이터 저장소에서 16GB OS 디스크가 있는 가상 LSI SAS SCSI 컨트롤러
- 테스트 VMDK용 Paravirtual SCSI 컨트롤러
- LVM/디스크 구성:
- 디스크당 하나의 물리적 볼륨
- 물리적 볼륨당 하나의 볼륨 그룹
- 볼륨 그룹당 하나의 논리 파티션
- 논리 파티션당 하나의 XFS 파일 시스템
- Azure NetApp Files 프로토콜에 대한 Azure VMware Solution: NFS 버전 3
- 워크로드 생성기:
fio
버전 3.16 - Fio 스크립트:
fio-parser
검사 결과
이 섹션에서는 수행된 테스트의 결과를 설명합니다.
단일 VM 확장
Azure VMware Solution 가상 머신에서 데이터 저장소 제공 스토리지를 구성하는 경우 파일 시스템 레이아웃의 영향을 고려해야 합니다. 여러 데이터 저장소에 분산된 여러 VMDK를 구성하면 사용 가능한 대역폭이 가장 높습니다. 단일 데이터 저장소에 배치된 일대다 VMDK를 구성하면 백업 및 DR 작업과 관련하여 가장 간단하지만 성능이 저하됩니다. 이 문서에 제공된 경험적 데이터는 의사 결정에 도움이 됩니다.
성능을 최대화하려면 여러 VMDK에서 단일 VM을 확장하고 해당 VMDK를 여러 데이터 저장소에 걸쳐 배치하는 것이 일반적입니다. 하나 또는 두 개의 VMDK가 있는 단일 VM은 지정된 Azure VMware Solution 호스트에 대한 단일 TCP 연결을 통해 탑재되므로 하나의 NFS 데이터 저장소로 제한될 수 있습니다.
예를 들어 엔지니어는 데이터베이스 로그에 대한 VMDK를 프로비전한 다음 데이터베이스 파일에 대한 일대다 VMDK를 프로비전하는 경우가 많습니다. 여러 VMDK를 사용하는 경우 두 가지 옵션이 있습니다. 첫 번째 옵션은 각 VDMK를 개별 파일 시스템으로 사용하는 것입니다. 두 번째 옵션은 LVM, MSSQL 파일 그룹 또는 Oracle ASM과 같은 스토리지 관리 유틸리티를 사용하여 VMDK 전체에 걸쳐 스트라이프하는 방법으로 IO의 균형을 맞추는 것입니다. VMDK를 개별 파일 시스템으로 사용하는 경우 여러 데이터 저장소에 걸쳐 워크로드를 배포하려면 수동 작업이 필요하고 번거로울 수 있습니다. 스토리지 관리 유틸리티를 사용하여 VMDK 전체에 걸쳐 파일을 분산하면 워크로드 확장성을 사용할 수 있습니다.
여러 디스크에 걸쳐 볼륨을 스트라이프하는 경우 백업 소프트웨어 또는 재해 복구 소프트웨어가 여러 가상 디스크를 동시에 백업하도록 지원하는지 확인합니다. 개별 쓰기가 여러 디스크에 걸쳐 스트라이프되므로 파일 시스템에서 스냅샷 또는 백업 작업 중에 디스크가 "고정"되도록 해야 합니다. 대부분의 최신 파일 시스템에는 백업 소프트웨어가 활용할 수 있는 고정 또는 스냅샷 작업(예: xfs
(xfs_freeze
))과 NTFS(볼륨 섀도 복사본)가 포함됩니다.
더 많은 가상 디스크가 추가될 때 단일 Azure VMware Solution VM이 얼마나 잘 확장되는지 이해하기 위해 1개, 2개, 4개 및 8개의 데이터 저장소(각각 단일 VMDK 포함)로 테스트를 수행했습니다. 다음 다이어그램은 IOPS가 평균 약 73,040개인 단일 디스크를 보여 줍니다(100% 쓰기/0% 읽기에서 0% 쓰기/100% 읽기로 확장). 이 테스트를 2개의 드라이브로 늘리면 성능이 75.8% 증가하여 IOPS가 128,420개가 되었습니다. 드라이브를 4개로 늘리면 테스트된 크기의 단일 VM이 푸시할 수 있는 결과가 감소하기 시작했습니다. 관찰된 최고 IOPS는 147,000개의 IOPS, 100% 임의 읽기였습니다.
단일 호스트 확장 - 단일 데이터 저장소
단일 호스트에서 단일 데이터 저장소로 IO를 구동하는 VM 수를 늘리기 위한 확장이 제대로 수행되지 않습니다. 이 사실은 단일 네트워크 흐름 때문입니다. 지정된 워크로드에 대해 최대 성능에 도달하는 경우, 이는 단일 TCP 연결을 통해 호스트의 단일 NFS 데이터 저장소로 가는 길에 사용되는 단일 큐의 결과인 경우가 많습니다. 8KB 블록 크기를 사용하면 단일 VMDK가 있는 1개의 VM에서 총 16개의 VMDK(VM당 4개, 모두 단일 데이터 저장소에 있음)가 있는 4개의 VM으로 조정할 때 총 IOPS가 3%~16% 증가했습니다.
큰 블록 워크로드의 블록 크기를 늘리면(64KB로) 비슷한 결과가 발생했으며, 최대 2,148MiB/s(단일 VM, 단일 VMDK) 및 2138MiB/s(VM 4개, VMDK 16개)에 도달했습니다.
단일 호스트 확장 – 여러 데이터 저장소
단일 Azure VMware Solution 호스트의 컨텍스트에서 단일 데이터 저장소를 통해 VM에서 약 76,000 IOPS를 구동할 수 있었고, 두 데이터 저장소에 워크로드를 분산하면 총 처리량이 평균 76% 증가했습니다. 2개의 데이터 저장소를 4개로 늘리면 다음 다이어그램과 같이 163% 증가했습니다(데이터 저장소 1개 이상, 2개에서 4개로 49% 증가). 여전히 성능이 향상되었지만 8개 이상의 데이터 저장소를 초과하여 증가하면 효과가 감소하는 것으로 나타났습니다.
여러 호스트 확장 – 단일 데이터 저장소
2000MiB/s 이상의 순차적 64KB 처리량을 생성한 단일 호스트의 단일 데이터 저장소입니다. 4개 호스트 모두에 동일한 워크로드를 분산하면 135%라는 최고의 증가율을 나타내며 5,000MiB/s 이상을 구동했습니다. 이 결과는 단일 Azure NetApp Files 볼륨 처리량 성능의 상한을 나타낼 수 있습니다.
블록 크기를 64KB에서 8KB로 줄이고 동일한 반복을 다시 실행하면 다음 다이어그램과 같이 4개의 VM이 195,000개의 IOPS를 생성했습니다. 네트워크 흐름 수가 증가하므로 호스트 수와 데이터 저장소 수가 모두 증가함에 따라 성능이 확장됩니다. 네트워크 흐름 수는 호스트 요소 곱하기 데이터 저장소이므로, 호스트 수를 데이터 저장소 수로 곱하여 확장하는 방식으로 성능이 향상됩니다.
여러 호스트 확장 – 여러 데이터 저장소
4개의 호스트에 분산된 4개의 VM이 있는 단일 데이터 저장소가 순차적 64KB IO의 5,000MiB/s 이상을 생성했습니다. 더 까다로운 워크로드의 경우 각 VM이 전용 데이터 저장소로 이동되어 다음 다이어그램과 같이 총 10,500MiB/s 이상을 생성합니다.
소규모 블록 임의 워크로드의 경우 단일 데이터 저장소가 195,000개의 임의 8KB IOPS를 생성했습니다. 4개의 데이터 저장소로 확장하면 530,000개 이상의 임의 8K IOPS를 생성했습니다.
의미 및 권장 사항
이 섹션에서는 여러 데이터 저장소에 VM을 분산하면 상당한 성능 이점이 있는 이유를 설명합니다.
테스트 결과에 표시된 것처럼 Azure NetApp Files의 성능 기능은 풍부합니다.
- 테스트 결과 데이터 저장소 하나가 4개의 호스트 구성에서 64KB IOPS(모든 쓰기%/읽기% 테스트의 평균)로 평균 최대 148,980 8KB IOPS 또는 최대 4147MiB/s를 구동할 수 있습니다.
- 하나의 데이터 저장소에 하나의 VM –
- 최대 75K 8KB IOPS 또는 최대 1,700MiB/s 이상이 필요할 수 있는 개별 VM이 있는 경우 여러 VMDK에 파일 시스템을 분산하여 VM 스토리지 성능을 조정합니다.
- 여러 데이터 저장소에 하나의 VM – 8개의 데이터 저장소에 단일 VM이 걸쳐 있는 경우 64KB 블록 크기로 최대 147,000 8KB IOPS 또는 최대 2786MiB/s를 달성했습니다.
- 하나의 호스트 - Azure NetApp Files 데이터 저장소가 4개 이상 있고 호스트당 최소 4개의 VM을 사용하는 경우 각 호스트는 평균 최대 198,060 8KB IOPS 또는 최대 2351MiB/s를 지원할 수 있었습니다. 따라서 최대치, 잠재적 버스팅, 성능에 충분한 데이터 저장소 프로비전과 관리 및 비용의 복잡성 간에 균형을 맞출 수 있습니다.
권장 사항
단일 데이터 저장소의 성능 역량이 부족한 경우 VM을 여러 데이터 저장소에 분산하여 더 확장합니다. 많은 경우 단순성이 가장 좋지만, 성능과 확장성 때문에 제한적으로 복잡성이 추가되는 것이 용인될 수 있습니다.
4개의 Azure NetApp Files 데이터 저장소는 대규모 순차 IO를 위해 최대 10GBps의 사용 가능한 대역폭을 제공하거나 최대 500K 8K 임의 IOPS를 구동할 수 있는 기능을 제공합니다. 하나의 데이터 저장소로도 많은 성능 요구 사항에 충분할 수 있지만, 최상의 성능을 위해 최소 4개의 데이터 저장소로 시작합니다.
세분화된 성능 조정을 위해 Windows 및 Linux 게스트 운영 체제 모두 여러 디스크에 걸쳐 스트라이프를 허용합니다. 따라서 여러 데이터 저장소에 분산된 여러 VMDK에 걸쳐 파일 시스템을 스트라이프해야 합니다. 그러나 애플리케이션 스냅샷 일관성이 문제고 LVM 또는 스토리지 공간으로 해결할 수 없는 경우 게스트 운영 체제에서 Azure NetApp Files를 탑재하거나 애플리케이션 수준 확장을 조사하는 것이 좋습니다. 그 밖에도 Azure에는 많은 훌륭한 옵션이 있습니다.
여러 디스크에 걸쳐 볼륨을 스트라이프하는 경우 백업 소프트웨어 또는 재해 복구 소프트웨어가 여러 가상 디스크를 동시에 백업하도록 지원하는지 확인합니다. 개별 쓰기가 여러 디스크에 걸쳐 스트라이프되므로 파일 시스템에서 스냅샷 또는 백업 작업 중에 디스크가 "고정"되도록 해야 합니다. 대부분의 최신 파일 시스템에는 백업 소프트웨어가 활용할 수 있는 고정 또는 스냅샷 작업(예: xfs(xfs_freeze))과 NTFS(볼륨 섀도 복사본)가 포함됩니다.
Azure NetApp Files는 할당된 용량(데이터 저장소) 이외의 용량 풀에서 프로비전된 용량에 대해 청구하므로 4x20TB 데이터 저장소 또는 20x4TB 데이터 저장소에 대해 동일한 요금을 지불합니다. 필요한 경우 Azure API/콘솔을 통해 동적으로 주문형 데이터 저장소의 용량과 성능을 조정할 수 있습니다.
예를 들어 회계 연도가 끝날 무렵 표준 데이터 저장소에서 더 많은 스토리지 성능이 필요하다는 것을 알게 되는 경우. 이 데이터 저장소의 서비스 수준을 한 달 동안 늘려 해당 데이터 저장소의 모든 VM은 더 많은 성능을 사용할 수 있는 반면, 다른 데이터 저장소는 더 낮은 서비스 수준에서 유지하도록 할 수 있습니다. 각 AVS 호스트에 대한 각 데이터 저장소 간의 더 많은 TCP 연결에 워크로드를 분산하여 비용을 절감할 뿐만 아니라 더 큰 성능을 얻을 수 있습니다.
vCenter Server 또는 Azure API/콘솔을 통해 데이터 저장소 메트릭을 모니터링할 수 있습니다. vCenter Server에서 데이터 저장소에서 스토리지 IO 컨트롤 메트릭 컬렉션을 사용하도록 설정하는 한 성능/고급 차트에서 데이터 저장소의 집계 평균 IOPS를 모니터링할 수 있습니다. 특히, Azure API 및 콘솔에서 WriteIops
, ReadIops
, ReadThroughput
, WriteThroughput
에 대한 메트릭을 표시하여 데이터 저장소 수준에서 워크로드를 측정할 수 있습니다. Azure 메트릭을 사용하면 작업으로 경고 규칙을 설정하여 Azure 함수, 웹후크 또는 기타 작업을 통해 자동으로 데이터 저장소의 크기를 조정할 수 있습니다.