Linux용 Azure NetApp Files 일반 볼륨 성능 벤치마크
이 문서에서는 Azure NetApp Files가 일반 볼륨을 사용하여 Linux용으로 제공하는 성능 벤치마크에 대해 설명합니다.
전체 파일 스트리밍 워크로드(스케일 아웃 벤치마크 테스트)
스케일 아웃 테스트의 목적은 동시 워크로드를 동일한 볼륨으로 생성하는 클라이언트 수를 스케일 아웃(또는 증가)할 때 Azure NetApp File 볼륨의 성능을 표시하는 것입니다. 이러한 테스트는 일반적으로 볼륨을 성능 제한의 가장자리로 푸시할 수 있으며 미디어 렌더링, AI/ML 및 대규모 컴퓨팅 팜을 활용하여 작업을 수행하는 다른 워크로드와 같은 워크로드를 나타냅니다.
높은 I/OP 스케일 아웃 벤치마크 구성
이러한 벤치마크는 다음을 사용했습니다.
- Ultra 성능 계층을 사용하는 1TiB 데이터 세트가 있는 단일 Azure NetApp Files 100TiB 일반 볼륨
- FIO(randrepeat=0 설정 및 설정 안 함)
- 4-KiB 및 8KiB 블록 크기
- RHEL 9.3을 실행하는 6개 D32s_v5 가상 머신
- NFSv3
- 수동 QoS
- 탑재 옵션: rw,nconnect=8,hard,rsize=262144,wsize=262144,vers=3,tcp,bg
높은 처리량 스케일 아웃 벤치마크 구성
이러한 벤치마크는 다음을 사용했습니다.
- Ultra 성능 계층 FIO를 사용하는 1TiB 데이터 세트가 있는 단일 Azure NetApp Files 일반 볼륨(randrepeat=0 설정 및 설정 안 함)
- FIO(randrepeat=0 설정 및 설정 안 함)
- 64KiB 및 256KiB 블록 크기
- RHEL 9.3을 실행하는 6개 D32s_v5 가상 머신
- NFSv3
- 수동 QoS
- 탑재 옵션: rw,nconnect=8,hard,rsize=262144,wsize=262144,vers=3,tcp,bg
병렬 네트워크 연결(nconnect) 벤치마크 구성
이러한 벤치마크는 다음을 사용했습니다.
- Ultra 성능 계층을 사용하는 1TiB 데이터 세트가 있는 단일 Azure NetApp Files 일반 볼륨
- FIO(randrepeat=0 설정 및 설정 안 함)
- 4-KiB 및 64-KiB wsize/rsize
- RHEL 9.3을 실행하는 단일 D32s_v4 가상 머신
- NFSv3 포함 및 제외
nconnect - 탑재 옵션: rw,nconnect=8,hard,rsize=262144,wsize=262144,vers=3,tcp,bg
벤치마크 테스트 강화
강화 테스트의 목적은 단일 클라이언트의 여러 TCP 연결에서 동시 워크로드를 생성하는 작업 수를 동일한 볼륨(예: )으로 nconnect확장(또는 증가)할 때 Azure NetApp 파일 볼륨의 성능을 표시하는 것입니다.
클라이언트가 충분한 IO 또는 네트워크 처리량을 생성할 수 없으므로 이러한 워크로드가 없으면 nconnect볼륨의 최대 성능 제한을 밀어낼 수 없습니다. 이러한 테스트는 일반적으로 미디어 렌더링, 데이터베이스, AI/ML 및 일반 파일 공유와 같은 워크로드에서 단일 사용자의 환경을 나타냅니다.
높은 I/OP 스케일 아웃 벤치마크
다음 벤치마크는 다음을 사용하여 높은 I/OP 워크로드를 사용하는 Azure NetApp Files에 대해 달성된 성능을 보여 줍니다.
- 32개 클라이언트
- 4-KiB 및 8KiB 임의 읽기 및 쓰기
- 1TiB 데이터 세트
- 읽기/쓰기 비율:100%:0%, 90%:10%, 80%:20% 등
- 관련된 파일 시스템 캐싱 사용 및 사용 안 됨(FIO에서 사용
randrepeat=0)
자세한 내용은 테스트 방법론을 참조 하세요.
결과: 4KiB, 임의, 클라이언트 캐싱 포함
이 벤치마크에서 FIO는 데이터를 임의로 지정할 수 있는 randrepeat 옵션 없이 실행되었습니다. 따라서 결정되지 않은 양의 캐싱이 실행되었습니다. 이 구성은 전체 IO 스택을 활용하면서 캐싱하지 않고 테스트가 실행되는 것보다 전반적인 성능 수치가 약간 향상됩니다.
다음 그래프에서 테스트는 이 벤치마크 동안 약 130,000개의 순수 임의 4KiB 쓰기와 약 460,000개의 순수 임의 4KiB 읽기 사이에서 처리할 수 있는 Azure NetApp Files 일반 볼륨을 보여 줍니다. 각 실행에 대해 10% 조정된 워크로드에 대한 읽기-쓰기 조합입니다.
읽기-쓰기 I/OP 혼합이 쓰기가 많은 쪽으로 증가하면 총 I/OPS가 감소합니다.
결과: 4KiB, 임의, 클라이언트 캐싱 제외
이 벤치마크에서는 데이터를 임의로 설정하는 설정 randrepeat=0 으로 FIO를 실행하여 성능에 대한 캐싱 영향을 줄였습니다. 이로 인해 쓰기 I/OPS가 약 8% 감소하고 읽기 I/OPS가 약 17% 감소했지만 스토리지에서 실제로 수행할 수 있는 작업을 더 많이 나타내는 성능 수치가 표시됩니다.
다음 그래프에서 테스트는 Azure NetApp Files 일반 볼륨이 약 120,000개의 순수 임의 4KiB 쓰기와 약 388,000개의 순수 임의 4KiB 읽기 사이에서 처리할 수 있는 것을 보여줍니다. 각 실행에 대해 25% 조정된 워크로드에 대한 읽기-쓰기 조합입니다.
읽기-쓰기 I/OP 혼합이 쓰기가 많은 쪽으로 증가하면 총 I/OPS가 감소합니다.
결과: 8KiB, 임의, 클라이언트 캐싱 제외
읽기 및 쓰기 크기가 클수록 각 작업에서 더 많은 데이터를 보낼 수 있으므로 총 I/OPS 수가 줄어듭니다. 8KiB 읽기 및 쓰기 크기는 대부분의 최신 애플리케이션에서 사용하는 것을 보다 정확하게 시뮬레이션하는 데 사용되었습니다. 예를 들어 많은 EDA 애플리케이션은 8KiB 읽기 및 쓰기를 사용합니다.
이 벤치마크에서 FIO는 데이터를 임의로 실행 randrepeat=0 하여 클라이언트 캐싱 영향을 줄였습니다. 다음 그래프에서 테스트는 Azure NetApp Files 일반 볼륨이 약 111,000개의 순수 임의 8KiB 쓰기와 약 293,000개의 순수 임의 8KiB 읽기 사이에서 처리할 수 있음을 보여 줍니다. 각 실행에 대해 25% 조정된 워크로드에 대한 읽기-쓰기 조합입니다.
읽기-쓰기 I/OP 혼합이 쓰기가 많은 쪽으로 증가하면 총 I/OPS가 감소합니다.
나란히 비교
캐싱이 성능 벤치마크 테스트에 영향을 줄 수 있는 방법을 설명하기 위해 다음 그래프는 캐싱 메커니즘을 사용 및 사용하지 않고 4-KiB 테스트에 대한 총 I/OPS를 보여 줍니다. 표시된 것처럼 캐싱은 I/OPS의 상당히 일관된 추세에 약간의 성능 향상을 제공합니다.
특정 오프셋, 스트리밍 임의 읽기/쓰기 워크로드: 병렬 네트워크 연결을 사용한 확장 테스트(nconnect)
다음 테스트는 4KiB 임의 워크로드 및 1TiB 데이터 세트가 있는 단일 클라이언트를 사용하는 높은 I/OP 벤치마크를 보여 줍니다. 생성된 워크로드 조합은 매번 다른 I/O 깊이를 사용합니다. 단일 클라이언트 워크로드 nconnect 의 성능을 향상시키기 위해 탑재 옵션은 탑재 옵션이 없는 nconnect 클라이언트 탑재에 비해 병렬 처리를 개선하는 데 사용되었습니다.
스토리지에 대한 단일 경로만 제공하는 표준 TCP 연결을 사용하는 경우 탑재가 탑재 지점당 더 많은 TCP 연결(예: 사용 nconnect)을 활용할 수 있는 경우보다 초당 전송되는 총 작업이 적습니다. 사용하는 nconnect경우 작업의 총 대기 시간은 일반적으로 더 낮습니다. 이러한 테스트는 의도적으로 캐싱을 방지하기 위해 실행됩니다 randrepeat=0 . 이 옵션에 대한 자세한 내용은 테스트 방법론을 참조 하세요.
결과: 4KiB, 임의, 포함 및 제외 nconnect, 캐싱 제외
다음 그래프는 사용 nconnect시 표시되는 성능 향상을 강조 표시하기 위한 4-KiB 읽기 및 쓰기 nconnect 비교를 보여 줍니다. 전체 I/OPS가 높고 대기 시간이 짧습니다.
높은 처리량 벤치마크
다음 벤치마크는 처리량 워크로드가 높은 Azure NetApp Files에 대해 달성된 성능을 보여 줍니다.
높은 처리량 워크로드는 본질적으로 더 순차적이며 낮은 메타데이터로 읽기/쓰기가 많은 경우가 많습니다. 처리량은 일반적으로 I/OPS보다 더 중요합니다. 이러한 워크로드는 일반적으로 더 큰 읽기/쓰기 크기(64K에서 256K까지)를 활용하며, 이는 더 큰 페이로드가 처리되는 데 자연스럽게 더 오래 걸리기 때문에 더 작은 읽기/쓰기 크기보다 더 높은 대기 시간을 생성합니다.
높은 처리량 워크로드의 예는 다음과 같습니다.
- 미디어 리포지토리
- 고성능 컴퓨팅
- AI/ML/LLP
다음 테스트는 64KiB 및 256KiB 순차 워크로드와 1TiB 데이터 세트를 모두 사용하는 높은 처리량 벤치마크를 보여 줍니다. 생성된 워크로드 조합은 한 번에 설정된 백분율을 감소시키고 다양한 읽기/쓰기 비율(예: 100%:0%, 90%:10%, 80%:20% 등)을 사용할 때 예상할 수 있는 것을 보여 줍니다.
결과: 64KiB 순차 I/O, 캐싱 포함
이 벤치마크에서 FIO는 캐시를 더 적극적으로 채우는 루프 논리를 사용하여 실행되었으므로 확정되지 않은 양의 캐싱이 결과에 영향을 미쳤습니다. 이로 인해 캐싱 없이 테스트가 실행되는 것보다 전반적인 성능 수치가 약간 향상됩니다.
아래 그래프에서 테스트는 Azure NetApp Files 일반 볼륨이 약 4,500MiB/s 순수 순차 64KiB 읽기와 약 1,600MiB/s 순수 순차 64-KiB 쓰기 사이에서 처리할 수 있음을 보여 줍니다. 워크로드에 대한 읽기-쓰기 조합은 각 실행에 대해 10% 조정되었습니다.
결과: 64KiB 순차 I/O, 캐싱 제외
이 벤치마크에서 FIO는 캐시를 덜 적극적으로 채우는 루핑 논리를 사용하여 실행했습니다. 클라이언트 캐싱은 결과에 영향을 주지 않았습니다. 이 구성은 쓰기 성능 번호를 약간 향상하지만 캐싱 없이 테스트보다 읽기 수가 낮습니다.
다음 그래프에서 테스트는 Azure NetApp Files 일반 볼륨이 약 3,600MiB/s 순수 순차 64KiB 읽기와 약 2,400MiB/s 순수 순차 64KiB 쓰기 사이에서 처리할 수 있음을 보여 줍니다. 테스트 중에 50/50 조합은 순수 순차 읽기 워크로드와 동등한 총 처리량을 보여주었습니다.
워크로드에 대한 읽기-쓰기 조합은 각 실행에 대해 25% 조정되었습니다.
결과: 256KiB 순차 I/O, 캐싱 제외
이 벤치마크에서 FIO는 캐시를 덜 적극적으로 채우는 루프 논리를 사용하여 실행되었으므로 캐싱이 결과에 영향을 주지 않았습니다. 이 구성은 64KiB 테스트보다 쓰기 성능 수치가 약간 낮지만 캐싱 없이 실행되는 동일한 64KiB 테스트보다 읽기 수가 높습니다.
아래 그래프에서 테스트는 Azure NetApp Files 일반 볼륨이 약 3,500MiB/s 순수 순차 256KiB 읽기와 약 2,500MiB/s 순수 순차 256KiB 쓰기 사이에서 처리할 수 있음을 보여줍니다. 테스트 중에 50/50 혼합으로 총 처리량이 순차적 읽기 워크로드보다 높은 것으로 나타났습니다.
워크로드에 대한 읽기-쓰기 조합은 각 실행에 대해 25% 증가하여 조정되었습니다.
나란히 비교
캐싱이 성능 벤치마크 테스트에 어떤 영향을 줄 수 있는지 더 잘 보여주기 위해 다음 그래프는 캐싱 메커니즘을 사용 및 사용하지 않고 64KiB 테스트에 대한 총 MiB/s를 보여 줍니다. 캐싱은 일반적으로 쓰기보다 읽기가 더 향상되므로 총 MiB/s에 대한 초기 약간의 성능 향상을 제공합니다. 읽기/쓰기 혼합이 변경되면 캐싱이 없는 총 처리량이 클라이언트 캐싱을 활용하는 결과를 초과합니다.
병렬 네트워크 연결(nconnect)
다음 테스트는 64KiB 임의 워크로드 및 1TiB 데이터 세트가 있는 단일 클라이언트를 사용하는 높은 I/OP 벤치마크를 보여 줍니다. 생성된 워크로드 조합은 매번 다른 I/O 깊이를 사용합니다. 단일 클라이언트 워크로드 nconnect 의 성능을 향상시키기 위해 탑재 옵션은 탑재 옵션을 사용하지 nconnect 않은 클라이언트 탑재에 비해 병렬 처리를 향상하기 위해 활용되었습니다. 이러한 테스트는 캐싱이 제외된 상태에서만 실행되었습니다.
결과: 64KiB, 순차, 캐싱 제외, 포함 및 제외 nconnect
다음 결과는 작업 병렬화(nconnect)를 사용 및 사용하지 않고 단일 클라이언트의 NFSv3 탑재에서 4-KiB 청크를 읽고 쓸 때의 강화 테스트 결과를 보여 줍니다. 그래프는 I/O 깊이가 증가함에 따라 I/OPS도 증가한다는 것을 보여줍니다. 그러나 스토리지에 대한 단일 경로만 제공하는 표준 TCP 연결을 사용하는 경우 탑재가 탑재 지점당 더 많은 TCP 연결을 활용할 수 있는 경우보다 초당 전송되는 총 작업이 적습니다. 또한 작업을 사용하는 nconnect경우 작업의 총 대기 시간은 일반적으로 낮습니다.
병렬 비교(사용 및 제외 nconnect)
다음 그래프는 사용 nconnect시 표시되는 성능 향상을 강조 표시하기 위해 64KiB 순차적 읽기 및 쓰기 nconnect 를 나란히 비교하는 방법을 보여 줍니다. 전체 처리량이 높고 대기 시간이 짧습니다.
