벤치마크 결과

5분

이제 앞 단원에서 설명한 성능 팁을 확인하기 위해 벤치마크 결과를 살펴봅니다. 특히 SPEC SFS 벤치마크 제품군을 사용하여 다중 스레드를 생성하고 EDA 프로덕션과 유사한 워크로드를 시뮬레이션하는 데 중점을 둡니다. 또한 몇 가지 성능 사례를 검사하기 위해 FIO 결과를 보여 드립니다.

두 벤치마크 도구 개요

SPEC SFS 제품군은 EDA를 위한 표준 업계 벤치마크입니다. 일반적인 EDA 워크로드는 기능적 및 물리적 단계로 구성됩니다. 기능적 단계는 대부분 임의 I/O 및 파일 시스템 메타데이터 작업의 기반이 됩니다. 물리적 단계는 큰 블록 순차적 읽기 및 쓰기의 기반이 됩니다.

FIO는 일관된 임의 또는 순차 읽기/쓰기 로드를 생성하여 IOPS 및 스토리지 대상 처리량을 벤치마크할 수 있는 I/O 도구입니다.

Azure NetApp Files의 볼륨 형식

Azure NetApp Files는 클라우드 데이터 스토리지에 프로비전할 수 있는 두 가지 형식의 볼륨, 즉 일반 볼륨과 대량 볼륨을 제공합니다. 다음 표에서는 두 볼륨 형식 간의 주요 차이점 중 일부를 강조 표시합니다. 워크로드에 적합한 볼륨 형식을 선택할 때 이 표를 지침으로 사용합니다.

제한	일반 볼륨	대용량
최소 용량	100GiB	50TiB
최대 생산 능력	100TiB	500TiB
최소 지원 서비스 수준	Standard	Standard
관찰된 최대 처리량	4,500MiB/s	10,240MiB/초
관찰된 최대 읽기 IOPS	~200,000	~700,000
관찰된 최대 쓰기 IOPS	~135,000	~474,000

일반 볼륨에 대한 SPEC EDA 도구의 벤치마크 결과

이 섹션의 그래프는 I/O 및 대기 시간 곡선을 보여 줍니다. 그래프에서는 다음 성능 사례의 몇 가지 조합을 살펴봅니다.

nocto,actimeo=600
sysctl tuned
nconnect=16

이전 세 가지 사례가 모두 적용되면 초당 I/O 작업은 증가하며 여전히 짧은 대기 시간(1밀리초 미만)을 유지합니다.

세 가지 사례가 모두 적용된 경우 IO 증가에도 여전히 짧은 대기 시간을 유지하는 SPEC EDA 결과를 보여 주는 다이어그램

다음 그래프는 이러한 형식의 워크로드에 대해 NFSv3이 NFSv4.1보다 더 나은 성능을 발휘함을 보여 줍니다.

NFS 버전 4.1보다 NFS 버전 3의 성능이 더 뛰어남을 보여주는 SPEC EDA 결과를 표시하는 다이어그램.

다음 그래프에서는 다른 설정보다 rsize=wsize=262144(256 K)의 성능이 훨씬 향상됨을 보여 줍니다.

rsize 및 wsize 값을 비교하는 SPEC EDA 결과를 보여 주는 다이어그램

대용량에 대한 SPEC EDA 도구의 벤치마크 결과

성능 임계값 테스트는 다음 구성으로 SPEC SFS 벤치마크를 사용하여 단일 대용량 볼륨에서 수행되었습니다.

구성 유형	설정
운영 체제	RHEL 9.3 / RHEL 8.7
인스턴스 유형	D16s_v5
인스턴트 수	10
탑재 옵션	nocto,actimeo=600,hard,rsize=262144,wsize=262144,vers=3,tcp,noatime,nconnect=8

테스트에서는 SPEC SFS 벤치마크를 사용하여 대용량 볼륨의 성능 기능을 Azure NetApp Files의 일반 볼륨과 비교했습니다.

시나리오	2ms의 I/O 속도	2ms에서 MiB/초
일반 볼륨 1개	39,601	692
대용량 볼륨 1개	652,260	10,030

대용량의 대기 시간과 처리량을 비교하는 다이어그램

일반 볼륨에 대한 FIO 도구의 벤치마크 결과

다음 FIO 명령은 각각 IOPS 및 처리량을 벤치마크합니다.

// FIO commands to benchmark IOPS:
// 8K Random Reads
fio --name=8krandomreads --rw=randread --direct=1 --ioengine=libaio --bs=8k --numjobs=4 --iodepth=128 --size=4G --runtime=600 --group_reporting
// 8K Random Writes
fio --name=8krandomwrites --rw=randwrite --direct=1 --ioengine=libaio --bs=8k --numjobs=4 --iodepth=128 --size=4G --runtime=600 --group_reporting

// FIO commands to benchmark throughput:
// 64K Sequential Reads
fio --name=64kseqreads --rw=read --direct=1 --ioengine=libaio --bs=64k --numjobs=4 --iodepth=128 --size=4G --runtime=600 --group_reporting
// 64K Sequential Writes
fio --name=64kseqwrites --rw=write --direct=1 --ioengine=libaio --bs=64k --numjobs=4 --iodepth=128 --size=4G --runtime=600 --group_reporting

다음 두 그래프는 nocto,actimeo=600, nconnect=16, sysctl이 튜닝될 때 Azure NetApp Files가 더 높은 IOPS 및 처리량을 획득할 수 있음을 보여 줍니다.

더 높은 IOPS의 FIO 결과를 보여 주는 다이어그램

더 높은 처리량의 FIO 결과를 보여 주는 다이어그램

대용량에 대한 FIO 도구의 벤치마크 결과

이 섹션에서는 FIO 벤치마크를 사용하여 단일 대용량 볼륨의 성능 임계값을 설명합니다. 테스트는 다음 구성으로 실행되었습니다.

구성 요소	구성
Azure VM 크기	E32s_v5
Azure VM 송신 대역폭 제한	2000MiB/초(2GiB/초)
운영 체제	RHEL 8.4
대용량 크기	101TiB Ultra(10,240MiB/s 처리량)
탑재 옵션	hard,rsize=65536,wsize=65536,vers=3 참고: 262144와 65536을 모두 사용하면 비슷한 성능 결과를 얻었습니다.

256KiB 순차 워크로드(MiB/s)

그래프는 256KiB 순차 워크로드와 1TiB 작업 집합을 나타냅니다. 이는 단일 Azure NetApp Files 대용량 볼륨이 약 8,518MiB/s 순수 순차 쓰기와 9,970MiB/s 순수 순차 읽기 사이를 처리할 수 있음을 보여 줍니다.

8KiB 임의 워크로드(IOPS)

그래프는 8KiB 임의 워크로드와 1TiB 작업 집합을 나타냅니다. 그래프는 Azure NetApp Files 대용량 볼륨이 약 474,000개의 순수 임의 쓰기와 약 709,000개의 순수 임의 읽기를 처리할 수 있음을 보여 줍니다.