DISKSPD를 사용하여 워크로드 스토리지 성능 테스트

아티클
02/26/2024

적용 대상: Azure Stack HCI, 버전 22H2 및 21H2; Windows Server 2022, Windows Server 2019

이 항목에서는 DISKSPD를 사용하여 워크로드 스토리지 성능을 테스트하는 방법에 대한 지침을 제공합니다. Azure Stack HCI 클러스터가 설정되었으며 모두 사용할 준비가 되었습니다. 좋습니다. 하지만 대기 시간, 처리량 또는 IOPS에 관계없이 약속된 성능 메트릭을 얻고 있는지 어떻게 알 수 있나요? DISKSPD로 전환할 수 있는 경우입니다. 이 항목을 읽은 후 DISKSPD를 실행하고, 매개 변수의 하위 집합을 이해하고, 출력을 해석하고, 워크로드 스토리지 성능에 영향을 주는 변수를 일반적으로 이해하는 방법을 알아봅니다.

DISKSPD란?

DISKSPD는 마이크로 벤치마킹을 위한 I/O 생성 명령줄 도구입니다. 좋은, 그래서이 모든 용어는 무엇을 의미합니까? Azure Stack HCI 클러스터 또는 물리적 서버를 설정하는 사람은 누구나 이유가 있습니다. 웹 호스팅 환경을 설정하거나 직원을 위해 가상 데스크톱을 실행할 수 있습니다. 실제 사용 사례가 무엇이든 실제 애플리케이션을 배포하기 전에 테스트를 시뮬레이션하려고 할 수 있습니다. 그러나 실제 시나리오에서 애플리케이션을 테스트하는 것은 어려운 경우가 많습니다. 여기서 DISKSPD가 들어옵니다.

DISKSPD는 사용자 지정하여 사용자 고유의 가상 워크로드를 만들고 배포 전에 애플리케이션을 테스트할 수 있는 도구입니다. 도구의 멋진 점은 매개 변수를 자유롭게 구성하고 조정하여 실제 워크로드와 유사한 특정 시나리오를 만들 수 있다는 것입니다. DISKSPD를 사용하면 배포 전에 시스템에서 수행할 수 있는 기능을 엿볼 수 있습니다. DISKSPD는 핵심적으로 많은 읽기 및 쓰기 작업을 발행합니다.

이제 DISKSPD가 무엇인지 알고 있지만 언제 사용해야 하나요? DISKSPD는 복잡한 워크로드를 에뮬레이트하는 데 어려움을 겪습니다. 그러나 DISKSPD는 워크로드가 단일 스레드 파일 복사본으로 거의 근사화되지 않고 허용 가능한 기준 결과를 생성하는 간단한 도구가 필요한 경우에 좋습니다.

빠른 시작: DISKSPD 설치 및 실행

추가 ado 없이 시작하겠습니다.

관리 PC에서 관리자 권한으로 PowerShell을 열어 DISKSPD를 사용하여 테스트하려는 대상 컴퓨터에 연결한 다음, 다음 명령을 입력하고 Enter 키를 누릅니다.
```
Enter-PSSession -ComputerName <TARGET_COMPUTER_NAME>
```
이 예제에서는 "node1"이라는 VM(가상 머신)을 실행합니다.

DISKSPD 도구를 다운로드하려면 다음 명령을 입력하고 Enter 키를 누릅니다.

$client = new-object System.Net.WebClient

$client.DownloadFile("https://github.com/microsoft/diskspd/releases/latest/download/DiskSpd.zip","<ENTER_PATH>\DiskSpd-2.1.zip")

다운로드한 파일의 압축을 풀려면 다음 명령을 사용합니다.

Expand-Archive -LiteralPath <ENTERPATH>\DiskSpd-2.1.zip -DestinationPath C:\DISKSPD

디렉터리를 DISKSPD 디렉터리로 변경하고 대상 컴퓨터가 실행 중인 Windows 운영 체제에 적합한 실행 파일을 찾습니다.

이 예제에서는 amd64 버전을 사용하고 있습니다.

참고

오픈 소스 코드가 포함된 GitHub 리포지토리 와 모든 매개 변수 및 사양을 자세히 설명한 Wiki 페이지에서 DISKSPD 도구를 직접 다운로드할 수도 있습니다. 리포지토리의 릴리스에서 링크를 선택하여 ZIP 파일을 자동으로 다운로드합니다.

ZIP 파일에는 amd64(64비트 시스템), x86(32비트 시스템) 및 ARM64(ARM 시스템)의 세 가지 하위 폴더가 표시됩니다. 이러한 옵션을 사용하면 모든 Windows 클라이언트 또는 서버 버전에서 도구를 실행할 수 있습니다.
다음 PowerShell 명령을 사용하여 DISKSPD를 실행합니다. 대괄호 자체를 포함하여 대괄호 안의 모든 항목을 적절한 설정으로 바꿉니다.
```
 .\[INSERT_DISKSPD_PATH] [INSERT_SET_OF_PARAMETERS] [INSERT_CSV_PATH_FOR_TEST_FILE] > [INSERT_OUTPUT_FILE.txt]
```
다음은 실행할 수 있는 예제 명령입니다.
```
 .\diskspd -t2 -o32 -b4k -r4k -w0 -d120 -Sh -D -L -c5G C:\ClusterStorage\test01\targetfile\IO.dat > test01.txt
```
참고

테스트 파일이 없는 경우 -c 매개 변수를 사용하여 만듭니다. 이 매개 변수를 사용하는 경우 경로를 정의할 때 테스트 파일 이름을 포함해야 합니다. 예: [INSERT_CSV_PATH_FOR_TEST_FILE] = C:\ClusterStorage\CSV01\IO.dat. 예제 명령에서 IO.dat 테스트 파일 이름이고 test01.txt DISKSPD 출력 파일 이름입니다.

키 매개 변수 지정

글쎄, 그건 간단했다? 불행히도, 그보다 더 많은 것이 있습니다. 우리가 한 일을 압축 해제해 봅시다. 첫째, 다양한 매개 변수를 사용하여 땜질할 수 있으며 구체적으로 얻을 수 있습니다. 그러나 다음 기준 매개 변수 집합을 사용했습니다.

참고

DISKSPD 매개 변수는 대/소문자를 구분합니다.

-t2: 대상/테스트 파일당 스레드 수를 나타냅니다. 이 숫자는 CPU 코어 수를 기반으로 하는 경우가 많습니다. 이 경우 두 개의 스레드를 사용하여 모든 CPU 코어를 강조했습니다.

-o32: 스레드당 대상당 미해결 I/O 요청 수를 나타냅니다. 이를 큐 깊이라고도 하며, 이 경우 CPU를 강조하기 위해 32개가 사용되었습니다.

-b4K: 블록 크기(바이트, KiB, MiB 또는 GiB)를 나타냅니다. 이 경우 4K 블록 크기를 사용하여 임의 I/O 테스트를 시뮬레이션했습니다.

-r4K: 지정된 크기(바이트), KiB, MiB, Gib 또는 블록에 맞춰진 임의 I/O를 나타냅니다( -s 매개 변수 재정의). 일반적인 4K 바이트 크기는 블록 크기에 올바르게 맞추는 데 사용되었습니다.

-w0: 쓰기 요청인 작업의 백분율을 지정합니다(-w0은 100% 읽기와 동일). 이 경우 간단한 테스트를 위해 0%의 쓰기가 사용되었습니다.

-d120: 냉각 또는 워밍업을 포함하지 않고 테스트 기간을 지정합니다. 기본값은 10초이지만 심각한 워크로드에는 60초 이상을 사용하는 것이 좋습니다. 이 경우 이상값을 최소화하기 위해 120초가 사용되었습니다.

-Suw: 소프트웨어 및 하드웨어 쓰기 캐싱을 사용하지 않도록 설정합니다( -Sh에 해당).

-D: 표준 편차와 같은 IOPS 통계를 밀리초 간격(스레드당, 대상당)으로 캡처합니다.

-L: 대기 시간 통계를 측정합니다.

-c5g: 테스트에 사용되는 샘플 파일 크기를 설정합니다. 바이트, KiB, MiB, GiB 또는 블록으로 설정할 수 있습니다. 이 경우 5GB 대상 파일이 사용되었습니다.

매개 변수의 전체 목록은 GitHub 리포지토리를 참조하세요.

환경 이해

성능은 환경에 따라 크게 달라집니다. 그래서, 우리의 환경은 무엇입니까? 사양에는 스토리지 풀 및 S2D(저장소 공간 다이렉트)가 있는 Azure Stack HCI 클러스터가 포함됩니다. 더 구체적으로 말하자면, 5개의 VM, 즉 DC, node1, node2, node3 및 관리 노드가 있습니다. 클러스터 자체는 3방향 미러링된 복원력 구조를 가진 3노드 클러스터입니다. 따라서 세 개의 데이터 복사본이 유지 관리됩니다. 클러스터의 각 "노드"는 최대 IOPS 제한이 1920인 Standard_B2ms VM입니다. 각 노드 내에는 최대 IOPS 제한이 5000인 4개의 프리미엄 P30 SSD 드라이브가 있습니다. 마지막으로, 각 SSD 드라이브에는 1TB의 메모리가 있습니다.

전체 드라이브 풀을 사용하기 위해 CSV(클러스터 공유 볼륨)에서 제공하는(C:\ClusteredStorage) 통합 네임스페이스 아래에 테스트 파일을 생성합니다.

참고

예제 환경에는 Hyper-V 또는 중첩된 가상화 구조가 없습니다 .

보듯이 VM 또는 드라이브 제한에서 IOPS 또는 대역폭 최대값에 독립적으로 도달할 수 있습니다. 따라서 최대 IOPS 제한과 대역폭 최대값을 가지므로 VM 크기와 드라이브 유형을 이해하는 것이 중요합니다. 이 지식은 병목 상태를 찾고 성능 결과를 이해하는 데 도움이 됩니다. 워크로드에 적합한 크기에 대해 자세히 알아보려면 다음 리소스를 참조하세요.

출력 이해

매개 변수 및 환경에 대한 이해로 무장하면 출력을 해석할 준비가 된 것입니다. 첫째, 이전 테스트의 목표는 대기 시간과 관계없이 IOPS를 최대로 처리하는 것이었습니다. 이렇게 하면 Azure 내에서 인공 IOPS 제한에 도달했는지 여부를 시각적으로 확인할 수 있습니다. 총 IOPS를 그래픽으로 시각화하려면 Windows Admin Center 또는 작업 관리자를 사용합니다.

다음 다이어그램은 예제 환경에서 DISKSPD 프로세스의 모양을 보여 줍니다. 비코디네이터 노드의 1MiB 쓰기 작업의 예를 보여줍니다. 비 코디네이터 노드의 작업과 함께 3방향 복원력 구조는 두 개의 네트워크 홉으로 이어져 성능이 저하됩니다. 코디네이터 노드가 무엇인지 궁금하다면 걱정하지 마세요! 고려해야 할 사항 섹션에서 자세히 알아봅니다. 빨간색 사각형은 VM 및 드라이브 병목 상태를 나타냅니다.

시각적으로 이해했으므로 이제 .txt 파일 출력의 네 가지 기본 섹션을 살펴보겠습니다.

입력 설정

이 섹션에서는 실행한 명령, 입력 매개 변수 및 테스트 실행에 대한 추가 세부 정보를 설명합니다.
CPU 사용률 세부 정보

이 섹션에서는 테스트 시간, 스레드 수, 사용 가능한 프로세서 수 및 테스트 중 모든 CPU 코어의 평균 사용률과 같은 정보를 강조 표시합니다. 이 경우 평균 사용량이 약 4.67%인 두 개의 CPU 코어가 있습니다.
총 I/O

이 섹션에는 세 개의 하위 섹션이 있습니다. 첫 번째 섹션에서는 읽기 및 쓰기 작업을 포함한 전체 성능 데이터를 강조 표시합니다. 두 번째 및 세 번째 섹션에서는 읽기 및 쓰기 작업을 별도의 범주로 분할합니다.

이 예제에서는 총 I/O 수가 120초 동안 234408 것을 확인할 수 있습니다. 따라서 IOPS = 234408 /120 = 1953.30. 평균 대기 시간은 32.763밀리초였고 처리량은 7.63MiB/s였습니다. 이전 정보에서 1953.30 IOPS는 Standard_B2ms VM에 대한 1920 IOPS 제한에 근접한다는 것을 알고 있습니다. 믿지 않습니까? 큐 깊이를 높이는 등 다양한 매개 변수를 사용하여 이 테스트를 다시 실행하면 결과가 이 숫자로 제한됩니다.

마지막 세 열은 17.72(-D 매개 변수에서) IOPS의 표준 편차, 20.994밀리초(-L 매개 변수에서) 대기 시간의 표준 편차 및 파일 경로를 보여 줍니다.

결과에서 클러스터 구성이 끔찍하다는 것을 신속하게 확인할 수 있습니다. SSD 제한 5000 이전에 1920의 VM 제한에 도달했음을 확인할 수 있습니다. VM이 아닌 SSD에 의해 제한된 경우 여러 드라이브에서 테스트 파일을 확장하여 최대 20000 IOPS(4개 드라이브 * 5000)를 활용할 수 있습니다.

결국 특정 워크로드에 허용되는 값을 결정해야 합니다. 다음 그림에서는 절충을 고려하는 데 도움이 되는 몇 가지 중요한 관계를 보여 줍니다.

그림의 두 번째 관계는 중요하며 때로는 리틀의 법칙이라고도 합니다. 이 법은 프로세스 동작을 제어하는 세 가지 특성이 있으며 다른 두 가지, 따라서 전체 프로세스에 영향을 미치기 위해 하나만 변경하면된다는 생각을 도입합니다. 따라서 시스템 성능에 불만이 있다면 영향을 줄 수 있는 3차원의 자유가 있습니다. Little's Law는 이 예제에서 IOPS가 "처리량"(초당 입력 출력 작업)이고 대기 시간이 "큐 시간"이고 큐 깊이가 "인벤토리"임을 나타냅니다.
대기 시간 백분위수 분석

이 마지막 섹션에서는 스토리지 성능의 작업 유형당 백분위수 대기 시간을 최소값에서 최대값까지 자세히 설명합니다.

이 섹션은 IOPS의 "품질"을 결정하기 때문에 중요합니다. 특정 대기 시간 값을 달성할 수 있었던 I/O 작업의 수를 표시합니다. 해당 백분위수에 허용되는 대기 시간을 결정하는 것은 사용자에게 달려 있습니다.

또한 "nines"는 9의 수를 참조합니다. 예를 들어 "3-nines"는 99번째 백분위수와 같습니다. 9개 수는 해당 백분위수에서 실행된 I/O 작업 수를 표시합니다. 결국 대기 시간 값을 심각하게 사용하는 것이 더 이상 의미가 없는 지점에 도달하게 됩니다. 이 경우 대기 시간 값이 "4-9" 후에도 일정하게 유지되는 것을 볼 수 있습니다. 이 시점에서 대기 시간 값은 234408 작업 중 하나의 I/O 작업만을 기반으로 합니다.

고려할 사항

DISKSPD를 사용하기 시작했으므로 실제 테스트 결과를 얻기 위해 고려해야 할 몇 가지 사항이 있습니다. 여기에는 설정한 매개 변수, 스토리지 공간 상태 및 변수, CSV 소유권 및 DISKSPD와 파일 복사 간의 차이점에 세심한 주의를 기울이는 것이 포함됩니다.

DISKSPD 및 실제

DISKSPD의 인공 테스트는 실제 워크로드에 대해 상대적으로 비슷한 결과를 제공합니다. 그러나 설정한 매개 변수와 매개 변수가 실제 시나리오와 일치하는지 여부에 주의해야 합니다. 가상 워크로드는 배포 중에 애플리케이션의 실제 워크로드를 완벽하게 나타내지 않는다는 것을 이해하는 것이 중요합니다.

준비

DISKSPD 테스트를 실행하기 전에 몇 가지 권장 작업이 있습니다. 여기에는 스토리지 공간의 상태 확인, 다른 프로그램이 테스트를 방해하지 않도록 리소스 사용량 확인, 추가 데이터를 수집하려는 경우 성능 관리자 준비 등이 포함됩니다. 그러나 이 항목의 목표는 DISKSPD를 신속하게 실행하는 것이므로 이러한 작업의 세부 사항을 자세히 살펴보지 않습니다. 자세한 내용은 Windows Server에서 가상 워크로드를 사용하여 저장소 공간 성능 테스트를 참조하세요.

성능에 영향을 주는 변수

스토리지 성능은 섬세한 것입니다. 즉, 성능에 영향을 줄 수 있는 많은 변수가 있습니다. 따라서 예상과 일치하지 않는 숫자가 발생할 수 있습니다. 다음은 포괄적인 목록은 아니지만 성능에 영향을 주는 일부 변수를 강조 표시합니다.

네트워크 대역폭
복원력 선택
스토리지 디스크 구성: NVME, SSD, HDD
I/O 버퍼
캐시
RAID 구성
네트워크 홉
하드 드라이브 스핀들 속도

CSV 소유권

노드를 볼륨 소유자 또는 코디네이터 노드라고 합니다(비 코디네이터 노드는 특정 볼륨을 소유하지 않는 노드임). 모든 표준 볼륨에는 노드가 할당되고 다른 노드는 네트워크 홉을 통해 이 표준 볼륨에 액세스할 수 있으므로 성능이 느려집니다(대기 시간 증가).

마찬가지로 CSV(클러스터 공유 볼륨)에도 "소유자"가 있습니다. 그러나 CSV는 시스템(RDP)을 다시 시작할 때마다 홉하고 소유권을 변경한다는 점에서 "동적"입니다. 따라서 CSV를 소유하는 코디네이터 노드에서 DISKSPD가 실행되는지 확인하는 것이 중요합니다. 그렇지 않은 경우 CSV 소유권을 수동으로 변경해야 할 수 있습니다.

CSV 소유권을 확인하려면 다음을 수행합니다.

다음 PowerShell 명령을 실행하여 소유권을 확인합니다.
```
 Get-ClusterSharedVolume
```
CSV 소유권이 올바르지 않은 경우(예: Node1에 있지만 Node2는 CSV를 소유함) 다음 PowerShell 명령을 실행하여 CSV를 올바른 노드로 이동합니다.
```
 Get-ClusterSharedVolume <INSERT_CSV_NAME> | Move-ClusterSharedVolume <INSERT _NODE_NAME>
```

파일 복사와 DISKSPD 비교

어떤 사람들은 거대한 파일을 복사 및 붙여넣고 해당 프로세스에 걸리는 시간을 측정하여 "스토리지 성능을 테스트"할 수 있다고 믿습니다. 이 접근 방식의 기본 이유는 간단하고 빠르기 때문일 가능성이 높습니다. 이 아이디어는 특정 워크로드를 테스트한다는 점에서 틀리지 않지만 이 방법을 "스토리지 성능 테스트"로 분류하기는 어렵습니다.

실제 목표가 파일 복사 성능을 테스트하는 것이라면 이 메서드를 사용하는 것이 완벽하게 타당한 이유일 수 있습니다. 그러나 스토리지 성능을 측정하는 것이 목표인 경우 이 메서드를 사용하지 않는 것이 좋습니다. 파일 복사 프로세스는 파일 서비스와 관련된 다른 "매개 변수" 집합(예: 큐, 병렬 처리 등)을 사용하는 것으로 생각할 수 있습니다.

다음 짧은 요약에서는 파일 복사를 사용하여 스토리지 성능을 측정하는 데 필요한 결과를 제공하지 못하는 이유를 설명합니다.

파일 복사본이 최적화되지 않을 수 있습니다. 두 가지 수준의 병렬 처리가 발생합니다. 하나는 내부이고 다른 하나는 외부입니다. 내부적으로 파일 복사본이 원격 대상으로 향하는 경우 CopyFileEx 엔진은 일부 병렬 처리를 적용합니다. 외부에서 CopyFileEx 엔진을 호출하는 방법에는 여러 가지가 있습니다. 예를 들어 파일 탐색기 복사본은 단일 스레드이지만 Robocopy는 다중 스레드입니다. 이러한 이유로 테스트의 의미가 원하는 것인지 여부를 이해하는 것이 중요합니다.
모든 복사본에는 양면이 있습니다. 파일을 복사하여 붙여넣기만 하면 원본 디스크와 대상 디스크의 두 디스크를 사용할 수 있습니다. 다른 디스크보다 속도가 느린 경우 기본적으로 느린 디스크의 성능을 측정합니다. 원본, 대상 및 복사 엔진 간의 통신이 고유한 방식으로 성능에 영향을 줄 수 있는 다른 경우가 있습니다.

자세한 내용은 파일 복사를 사용하여 스토리지 성능 측정을 참조하세요.

실험 및 일반 워크로드

이 섹션에는 몇 가지 다른 예제, 실험 및 워크로드 유형이 포함되어 있습니다.

코디네이터 노드 확인

앞에서 설명한 것처럼 현재 테스트 중인 VM이 CSV를 소유하지 않는 경우 노드가 CSV를 소유할 때 테스트하는 것과 달리 성능 저하(IOPS, 처리량 및 대기 시간)가 표시됩니다. 이는 I/O 작업을 실행할 때마다 시스템이 코디네이터 노드에 대한 네트워크 홉을 수행하여 해당 작업을 수행하기 때문입니다.

3개 노드의 3방향 미러링 상황의 경우 쓰기 작업은 3개 노드의 모든 드라이브에 데이터를 저장해야 하므로 항상 네트워크 홉을 만듭니다. 따라서 쓰기 작업은 관계없이 네트워크 홉을 만듭니다. 그러나 다른 복원력 구조를 사용하는 경우 변경이 발생할 수 있습니다.

예를 들면 다음과 같습니다.

로컬 노드에서 실행 중: .\DiskSpd-2.0.21a\amd64\diskspd.exe -t4 -o32 -b4k -r4k -w0 -Sh -D -L C:\ClusterStorage\test01\targetfile\IO.dat
비로컬 노드에서 실행 중: .\DiskSpd-2.0.21a\amd64\diskspd.exe -t4 -o32 -b4k -r4k -w0 -Sh -D -L C:\ClusterStorage\test01\targetfile\IO.dat

이 예제에서는 코디네이터 노드가 CSV를 소유할 때 대기 시간이 감소하고, IOPS가 증가하고, 처리량이 증가했음을 다음 그림의 결과에서 명확하게 확인할 수 있습니다.

OLTP(온라인 트랜잭션 처리) 워크로드

OLTP(온라인 트랜잭션 처리) 워크로드 쿼리(업데이트, 삽입, 삭제)는 트랜잭션 지향 작업에 초점을 맞춥니다. OLAP(온라인 분석 처리)와 비교하여 OLTP는 스토리지 대기 시간에 따라 달라집니다. 각 작업에는 I/O가 거의 문제가 없으므로 유지할 수 있는 초당 작업 수입니다.

임의 작은 I/O 성능에 집중하도록 OLTP 워크로드 테스트를 디자인할 수 있습니다. 이러한 테스트의 경우 허용 가능한 대기 시간을 유지하면서 처리량을 푸시할 수 있는 정도에 집중합니다.

이 워크로드 테스트의 기본 디자인 선택은 최소한 다음을 포함해야 합니다.

8KB 블록 크기 => SQL Server 데이터 파일에 사용하는 페이지 크기와 유사합니다.
70% 읽기, 30% 쓰기 => 일반적인 OLTP 동작과 유사

OLAP(온라인 분석 처리) 워크로드

OLAP 워크로드는 데이터 검색 및 분석에 중점을 두어 사용자가 복잡한 쿼리를 수행하여 다차원 데이터를 추출할 수 있도록 합니다. OLTP와 달리 이러한 워크로드는 스토리지 대기 시간을 구분하지 않습니다. 대역폭에 대해 크게 신경 쓰지 않고 많은 작업을 큐에 대기하는 것을 강조합니다. 따라서 OLAP 워크로드는 처리 시간이 길어지는 경우가 많습니다.

순차적이고 큰 I/O 성능에 집중하도록 OLAP 워크로드 테스트를 디자인할 수 있습니다. 이러한 테스트의 경우 IOPS 수가 아닌 초당 처리되는 데이터 볼륨에 초점을 맞춥니다. 대기 시간 요구 사항도 덜 중요하지만 주관적입니다.