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

아티클
11/23/2024

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

Important

Azure Stack HCI는 이제 Azure Local의 일부입니다. 제품 설명서 이름 바꾸기가 진행 중입니다. 그러나 이전 버전의 Azure Stack HCI(예: 22H2)는 Azure Stack HCI를 계속 참조하며 이름 변경 내용이 반영되지 않습니다. 자세히 알아보기.

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

DISKSPD란?

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

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

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

빠른 시작: DISKSPD 설치 및 실행

DISKSPD를 설치하고 실행하려면 관리 PC에서 관리자 권한으로 PowerShell을 열고 다음 단계를 수행합니다.

DISKSPD 도구에 대한 ZIP 파일을 다운로드하고 확장하려면 다음 명령을 실행합니다.

# Define the ZIP URL and the full path to save the file, including the filename
$zipName = "DiskSpd.zip"
$zipPath = "C:\DISKSPD"
$zipFullName = Join-Path $zipPath $zipName
$zipUrl = "https://github.com/microsoft/diskspd/releases/latest/download/" +$zipName

# Ensure the target directory exists, if not then create
if (-Not (Test-Path $zipPath)) {
New-Item -Path $zipPath -ItemType Directory | Out-Null
}
# Download and expand the ZIP file
Invoke-RestMethod -Uri $zipUrl -OutFile $zipFullName
Expand-Archive -Path $zipFullName -DestinationPath $zipPath

DISKSPD 디렉터리를 환경 변수에 추가하려면 다음 명령을 실행합니다 $PATH .

$diskspdPath = Join-Path $zipPath $env:PROCESSOR_ARCHITECTURE
if ($env:path -split ';' -notcontains $diskspdPath) {
$env:path += ";" + $diskspdPath
}

다음 PowerShell 명령을 사용하여 DISKSPD를 실행합니다. 대괄호를 적절한 설정으로 대체합니다.
```
diskspd [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 요청 수를 나타냅니다. 이를 큐 깊이라고도 하며, 이 경우 32개가 CPU를 강조하는 데 사용되었습니다.

-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(저장소 공간 Direct)가 있는 Azure Stack HCI 클러스터가 포함됩니다. 더 구체적으로 말하자면 DC, node1, node2, node3 및 관리 노드의 5개 VM이 있습니다. 클러스터 자체는 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-9s" 이후에도 일정하게 유지됩니다. 이 시점에서 대기 시간 값은 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.exe -t4 -o32 -b4k -r4k -w0 -Sh -D -L C:\ClusterStorage\test01\targetfile\IO.dat
비로컬 노드에서 실행: diskspd.exe -t4 -o32 -b4k -r4k -w0 -Sh -D -L C:\ClusterStorage\test01\targetfile\IO.dat

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

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

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

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

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

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

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

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

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