Menggunakan DISKSPD untuk menguji performa penyimpanan beban kerja

Artikel
02/26/2024

Berlaku untuk: Azure Stack HCI, versi 22H2 dan 21H2; Windows Server 2022, Windows Server 2019

Topik ini memberikan panduan tentang cara menggunakan DISKSPD untuk menguji performa penyimpanan beban kerja. Anda memiliki kluster HCI Azure Stack yang disiapkan, semua siap untuk eksekusi. Bagus, tetapi bagaimana Anda tahu jika Anda mendapatkan metrik performa yang dijanjikan, apakah itu latensi, throughput, atau IOPS? Ini adalah ketika Anda mungkin ingin beralih ke DISKSPD. Setelah membaca topik ini, Anda akan tahu cara menjalankan DISKSPD, memahami subset parameter, menafsirkan output, dan mendapatkan pemahaman umum tentang variabel yang memengaruhi performa penyimpanan beban kerja.

Apa itu DISKSPD?

DISKSPD adalah alat pembuatan I/O, baris perintah untuk micro-benchmarking. Bagus, jadi apa artinya semua istilah ini? Siapa pun yang menyiapkan kluster Azure Stack HCI atau server fisik memiliki alasannya. Bisa jadi untuk mengatur lingkungan web hosting, atau menjalankan desktop virtual untuk karyawan. Apa pun kasus penggunaan dunia nyata, Anda mungkin ingin menyimulasikan pengujian sebelum menyebarkan aplikasi Anda yang sebenarnya. Namun, menguji aplikasi Anda dalam skenario nyata sering kali sulit - di sinilah DISKSPD masuk.

DISKSPD adalah alat yang dapat Anda sesuaikan untuk membuat beban kerja sintetis Anda sendiri, dan menguji aplikasi Anda sebelum penyebaran. Hal yang keren tentang alat ini adalah memberi Anda kebebasan untuk mengonfigurasi dan men-tweak parameter untuk membuat skenario tertentu yang menyerupai beban kerja nyata Anda. DISKSPD dapat memberi Anda gambaran sekilas tentang apa yang mampu dilakukan sistem Anda sebelum penyebaran. Pada intinya, DISKSPD hanya mengeluarkan banyak operasi baca dan tulis.

Sekarang Anda tahu apa itu DISKSPD, tetapi kapan Anda harus menggunakannya? DISKSPD kesulitan meniru beban kerja yang kompleks. Tetapi DISKSPD sangat bagus saat beban kerja Anda tidak didekati dengan cermat oleh salinan file berulir tunggal, dan Anda memerlukan alat sederhana yang menghasilkan hasil dasar yang dapat diterima.

Mulai cepat: menginstal dan menjalankan DISKSPD

Tanpa basa-basi lagi, mari kita mulai:

Dari PC manajemen Anda, buka PowerShell sebagai administrator untuk terhubung ke komputer target yang ingin Anda uji menggunakan DISKSPD, lalu ketik perintah berikut dan tekan Enter.
```
Enter-PSSession -ComputerName <TARGET_COMPUTER_NAME>
```
Dalam contoh ini, kita menjalankan mesin virtual (VM) yang disebut "node1."

Untuk mengunduh alat DISKSPD, ketik perintah berikut dan tekan Enter:

$client = new-object System.Net.WebClient

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

Gunakan perintah berikut untuk membuka zip file yang diunduh:

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

Ubah direktori ke direktori DISKSPD dan temukan file yang dapat dieksekusi yang sesuai untuk sistem operasi Windows yang dijalankan komputer target.

Dalam contoh ini, kita menggunakan versi amd64.

Catatan

Anda juga dapat mengunduh alat DISKSPD langsung dari Repositori GitHub yang berisi kode sumber terbuka, dan halaman wiki yang merinci semua parameter dan spesifikasi. Di repositori, di bawah Rilis, pilih tautan untuk mengunduh file ZIP secara otomatis.

Dalam file ZIP, Anda akan melihat tiga subfolder: amd64 (sistem 64-bit), x86 (sistem 32-bit), dan ARM64 (sistem ARM). Opsi ini memungkinkan Anda menjalankan alat di setiap Windows versi klien atau server.
Jalankan DISKSPD dengan perintah PowerShell berikut. Ganti semua yang ada di dalam tanda kurung siku, termasuk tanda kurung itu sendiri dengan pengaturan yang sesuai.
```
 .\[INSERT_DISKSPD_PATH] [INSERT_SET_OF_PARAMETERS] [INSERT_CSV_PATH_FOR_TEST_FILE] > [INSERT_OUTPUT_FILE.txt]
```
Berikut adalah contoh perintah yang dapat Anda jalankan:
```
 .\diskspd -t2 -o32 -b4k -r4k -w0 -d120 -Sh -D -L -c5G C:\ClusterStorage\test01\targetfile\IO.dat > test01.txt
```
Catatan

Jika Anda tidak memiliki file pengujian, gunakan parameter -c untuk membuatnya. Jika Anda menggunakan parameter ini, pastikan untuk menyertakan nama file pengujian saat Anda menentukan jalur. Misalnya: [INSERT_CSV_PATH_FOR_TEST_FILE] = C:\ClusterStorage\CSV01\IO.dat. Dalam perintah contoh, IO.dat adalah nama file pengujian, dan test01.txt adalah nama file output DISKSPD.

Tentukan parameter utama

Nah, sederhana kan? Sayangnya, ada lebih dari itu. Mari kita membongkar apa yang kita lakukan. Pertama, ada berbagai parameter yang dapat Anda perbaiki dengan dan bisa mendapatkan spesifik. Namun, kami menggunakan kumpulan parameter dasar berikut:

Catatan

Parameter DISKSPD peka huruf besar/kecil.

-t2: Ini menunjukkan jumlah rangkaian per file target/pengujian. Angka ini sering didasarkan pada jumlah inti CPU. Dalam hal ini, dua rangkaian digunakan untuk menekankan semua inti CPU.

-o32: Menunjukkan jumlah permintaan I/O yang belum diselesaikan per target per alur. Ini juga dikenal sebagai kedalaman antrean, dan dalam hal ini, 32 digunakan untuk menekankan CPU.

-b4K: Menunjukkan ukuran blok dalam byte, KiB, MiB, atau GiB. Dalam hal ini, ukuran blok 4K digunakan untuk menyimulasikan pengujian I/O acak.

-r4K: Ini menunjukkan I/O acak yang diselaraskan dengan ukuran yang ditentukan dalam byte, KiB, MiB, Gib, atau blok (Menimpa parameter -s ). Ukuran byte 4K umum digunakan untuk menyelaraskan dengan ukuran blok dengan benar.

-w0: Menentukan persentase operasi yang merupakan permintaan tulis (-w0 setara dengan 100% baca). Dalam hal ini, 0% menulis digunakan untuk tujuan pengujian sederhana.

-d120: Ini menentukan durasi pengujian, tidak termasuk pendinginan atau pemanasan. Nilai default adalah 10 detik, tetapi kami sarankan menggunakan setidaknya 60 detik untuk beban kerja yang serius. Dalam hal ini, 120 detik digunakan untuk meminimalkan outlier.

-Suw: Nonaktifkan penembolokan penulisan perangkat lunak dan perangkat keras (setara dengan -Sh).

-D: Menangkap statistik IOPS, seperti standar deviasi, dalam interval milidetik (per rangkaian, per target).

-L: Mengukur statistik latensi.

-c5g: Mengatur ukuran file sampel yang digunakan dalam pengujian. Hal ini dapat diatur dalam byte, KiB, MiB, GiB, atau blok. Dalam hal ini, file target 5 GB digunakan.

Untuk daftar lengkap parameter, lihat Repositori GitHub.

Memahami lingkungan

Performa sangat tergantung pada lingkungan Anda. Jadi, apa lingkungan kita? Spesifikasi kami melibatkan kluster Azure Stack HCI dengan kumpulan penyimpanan dan Storage Spaces Direct (S2D). Lebih khusus lagi, ada lima VM: DC, node1, node2, node3, dan node manajemen. Kluster itu sendiri adalah kluster tiga node dengan struktur ketahanan cermin tiga arah. Oleh karena itu, tiga salinan data dipertahankan. Setiap "node" dalam kluster adalah VM Standard_B2ms dengan batas IOPS maksimum 1920. Dalam setiap node, ada empat drive SSD P30 premium dengan batas IOPS maksimum 5000. Terakhir, setiap drive SSD memiliki memori 1 TB.

Anda membuat file pengujian dengan namespace terpadu yang disediakan Cluster Shared Volume (CSV) (C:\ClusteredStorage) untuk menggunakan seluruh kumpulan drive.

Catatan

Lingkungan contoh tidak memiliki Hyper-V atau struktur virtualisasi bersarang.

Seperti yang akan Anda lihat, sangat mungkin untuk secara independen menekan IOPS atau langit-langit bandwidth di VM atau batas drive. Jadi, penting untuk memahami ukuran VM dan jenis drive Anda, karena keduanya memiliki batas IOPS maksimum dan langit-langit bandwidth. Pengetahuan ini membantu menemukan kemacetan dan memahami hasil performa Anda. Untuk mempelajari selengkapnya tentang ukuran apa yang mungkin sesuai untuk beban kerja Anda, lihat sumber daya berikut:

Memahami output

Berbekal pemahaman Anda tentang parameter dan lingkungan, Anda siap untuk menafsirkan output. Pertama, tujuan dari pengujian sebelumnya adalah untuk memaksimalkan IOPS tanpa memperhatikan latensi. Dengan cara ini, Anda dapat secara visual melihat apakah Anda mencapai batas IOPS buatan di dalam Azure. Jika Anda ingin memvisualisasikan IOPS total secara grafis, gunakan Pusat Admin Windows atau Pengelola Tugas.

Diagram berikut menunjukkan seperti apa proses DISKSPD di lingkungan contoh. Ini menunjukkan contoh operasi penulisan 1 MiB dari node non-koordinator. Struktur ketahanan tiga arah, bersama dengan operasi dari node non-koordinator, mengarah ke dua hop jaringan, menurunkan performa. Jika Anda bertanya-tanya apa itu node koordinator, jangan khawatir! Anda akan mempelajarinya di bagian Hal-hal yang perlu dipertimbangkan. Kotak merah mewakili VM dan mendorong penyempitan.

Sekarang setelah Anda memiliki pemahaman visual, mari kita periksa empat bagian utama dari output file .txt:

Pengaturan input

Bagian ini menjelaskan perintah yang Anda jalankan, parameter input, dan detail tambahan tentang eksekusi pengujian.
Detail penggunaan CPU

Bagian ini menyoroti informasi seperti waktu pengujian, jumlah rangkaian, jumlah prosesor yang tersedia, dan penggunaan rata-rata setiap inti CPU selama pengujian. Dalam hal ini, ada dua inti CPU yang rata-rata sekitar 4,67% penggunaan.
Total I/O

Bagian ini memiliki tiga subbagian. Bagian pertama menyoroti data performa keseluruhan termasuk operasi baca dan tulis. Bagian kedua dan ketiga membagi operasi baca dan tulis menjadi kategori terpisah.

Dalam contoh ini, Anda dapat melihat bahwa jumlah I/O total 234408 selama durasi 120 detik. Oleh karena itu, IOPS = 234408 /120 = 1953.30. Latensi rata-rata adalah 32,763 milidetik, dan throughputnya adalah 7,63 MiB/dtk. Dari informasi sebelumnya, kita tahu bahwa IOPS 1953.30 berada di dekat batasan IOPS 1920 untuk VM Standard_B2ms kami. Tidak percaya? Jika Anda menjalankan kembali pengujian ini menggunakan parameter yang berbeda, seperti meningkatkan kedalaman antrean, Anda akan menemukan bahwa hasilnya masih dibatasi pada nomor ini.

Tiga kolom terakhir menunjukkan standar deviasi IOPS pada 17,72 (dari parameter -D), standar deviasi latensi pada 20,994 milidetik (dari parameter -L), dan jalur file.

Dari hasilnya, Anda dapat dengan cepat menentukan bahwa konfigurasi kluster mengerikan. Anda dapat melihat bahwa itu mencapai batas VM tahun 1920 sebelum batas SSD 5000. Jika Anda dibatasi oleh SSD daripada VM, Anda bisa memanfaatkan hingga 20000 IOPS (4 drive * 5000) dengan mencakup file pengujian di beberapa drive.

Akhirnya, Anda perlu memutuskan nilai apa yang dapat diterima untuk beban kerja spesifik Anda. Angka berikut menunjukkan beberapa hubungan penting untuk membantu Anda mempertimbangkan pengorbanan:

Hubungan kedua dalam gambar itu penting, dan terkadang disebut sebagai Little’s Law. Hukum memperkenalkan gagasan bahwa ada tiga karakteristik yang mengatur perilaku proses dan bahwa Anda hanya perlu mengubah salah satu untuk memengaruhi dua lainnya, dan dengan demikian seluruh proses. Jadi, jika Anda tidak senang dengan performa sistem Anda, Anda memiliki tiga dimensi kebebasan untuk memengaruhinya. Little’s Law menyatakan bahwa dalam contoh kami, IOPS adalah "throughput" (operasi output input per detik), latensi adalah "waktu antrean", dan kedalaman antrean adalah "inventaris".
Analisis persentil latensi

Bagian terakhir ini merinci latensi persentil per jenis performa penyimpanan operasi dari nilai minimum hingga nilai maksimum.

Bagian ini penting karena menentukan "kualitas" IOPS Anda. Ini mengungkapkan berapa banyak operasi I/O yang mampu mencapai nilai latensi tertentu. Terserah Anda untuk memutuskan latensi yang dapat diterima untuk persentil tersebut.

Selain itu, "sembilan" mengacu pada jumlah sembilan. Misalnya, "3-9" setara dengan persentil ke-99. Jumlah sembilan mengekspos berapa banyak operasi I/O yang berjalan pada persentil itu. Terakhir, Anda akan mencapai titik yang tidak masuk akal lagi untuk menganggap serius nilai latensi. Dalam hal ini, Anda dapat melihat bahwa nilai latensi tetap konstan setelah "4-9." Pada titik ini, nilai latensi hanya didasarkan pada satu operasi I/O dari operasi 234408.

Hal-hal yang perlu dipertimbangkan

Sekarang setelah Anda mulai menggunakan DISKSPD, ada beberapa hal yang perlu dipertimbangkan untuk mendapatkan hasil pengujian dunia nyata. Ini termasuk memperhatikan parameter yang Anda tetapkan, kesehatan dan variabel ruang penyimpanan, kepemilikan CSV, dan perbedaan antara DISKSPD dan salinan file.

DISKSPD vs. dunia nyata

Pengujian buatan DISKSPD memberi Anda hasil yang relatif sebanding untuk beban kerja nyata Anda. Namun, Anda perlu memperhatikan parameter yang ditetapkan dan apakah cocok dengan skenario Anda yang sebenarnya. Penting untuk dipahami bahwa beban kerja sintetis tidak akan pernah mewakili beban kerja nyata aplikasi Anda dengan sempurna selama penyebaran.

Persiapan

Sebelum menjalankan pengujian DISKSPD, ada beberapa tindakan yang direkomendasikan. Ini termasuk memverifikasi kesehatan ruang penyimpanan, memeriksa penggunaan sumber daya Anda sehingga program lain tidak mengganggu pengujian, dan menyiapkan manajer performa jika Anda ingin mengumpulkan data tambahan. Namun, karena tujuan dari topik ini adalah untuk dengan cepat menjalankan DISKSPD, tindakan ini tidak diselami secara fisik. Untuk mempelajari lebih lanjut, lihat Menguji Performa Ruang Penyimpanan Menggunakan Beban Kerja Sintetis di Windows Server.

Variabel yang memengaruhi performa

Penyimpanan adalah hal yang rumit. Artinya, ada banyak variabel yang dapat memengaruhi performa. Jadi, kemungkinan Anda mungkin menemukan angka yang tidak konsisten dengan harapan Anda. Berikut ini menyoroti beberapa variabel yang memengaruhi performa, meskipun ini bukan daftar lengkap:

Bandwidth jaringan
Pilihan ketahanan
Konfigurasi disk penyimpanan: NVME, SSD, HDD
Buffer I/O
Cache
Konfigurasi RAID
Hop jaringan
Kecepatan spindel hard drive

Kepemilikan CSV

Node dikenal sebagai pemilik volume atau node koordinator (node non-koordinator akan menjadi node yang tidak memiliki volume tertentu). Setiap volume standar diberi node dan node lain dapat mengakses volume standar ini melalui hop jaringan, yang menghasilkan performa yang lebih lambat (latensi yang lebih tinggi).

Demikian pula, Cluster Shared Volume (CSV) juga memiliki "pemilik." Namun, CSV bersifat "dinamis" dalam arti bahwa ia akan melompat-lompat dan mengubah kepemilikan setiap kali Anda memulai ulang sistem (RDP). Akibatnya, penting untuk mengonfirmasi bahwa DISKSPD dijalankan dari node koordinator yang memiliki CSV. Jika tidak, Anda mungkin perlu mengubah kepemilikan CSV secara manual.

Untuk mengonfirmasi kepemilikan CSV:

Periksa kepemilikan dengan menjalankan perintah PowerShell berikut:
```
 Get-ClusterSharedVolume
```
Jika kepemilikan CSV salah (Misalnya, Anda berada di Node1 tetapi Node2 memiliki CSV), pindahkan CSV ke node yang benar dengan menjalankan perintah PowerShell berikut:
```
 Get-ClusterSharedVolume <INSERT_CSV_NAME> | Move-ClusterSharedVolume <INSERT _NODE_NAME>
```

Salinan file vs. DISKSPD

Beberapa orang percaya bahwa mereka dapat "menguji performa penyimpanan" dengan menyalin dan menempelkan file raksasa dan mengukur berapa lama proses itu berlangsung. Alasan utama di balik pendekatan ini kemungkinan besar karena sederhana dan cepat. Idenya tidak salah dalam arti pengujian beban kerja tertentu, tetapi sulit untuk mengategorikan metode ini sebagai "menguji performa penyimpanan."

Jika tujuan dunia nyata Anda adalah untuk menguji performa salinan file, ini mungkin alasan yang sangat valid untuk menggunakan metode ini. Namun, jika tujuan Anda adalah untuk mengukur performa penyimpanan, kami sarankan untuk tidak menggunakan metode ini. Anda dapat menganggap proses salinan file menggunakan serangkaian "parameter" yang berbeda (seperti antrean, paralelisasi, dan sebagainya) yang khusus untuk layanan file.

Ringkasan singkat berikut menjelaskan mengapa menggunakan salinan file untuk mengukur performa penyimpanan mungkin tidak memberikan hasil yang Anda cari:

Salinan file mungkin tidak dioptimalkan, Ada dua tingkat paralelisme yang terjadi, satu internal dan yang lainnya eksternal. Secara internal, jika salinan file menuju target jarak jauh, mesin CopyFileEx memang menerapkan beberapa paralelisasi. Secara eksternal, ada berbagai cara untuk memanggil mesin CopyFileEx. Misalnya, salinan dari File Explorer memiliki rangkaian tunggal, tetapi Robocopy memiliki multirangkaian. Untuk alasan ini, penting untuk memahami apakah implikasi dari pengujian adalah apa yang Anda cari.
Setiap salinan memiliki dua sisi. Saat Anda hanya menyalin dan menempelkan file, Anda mungkin menggunakan dua disk: disk sumber dan disk tujuan. Jika satu lebih lambat dari yang lain, Anda pada dasarnya mengukur performa disk yang lebih lambat. Ada kasus lain saat komunikasi antara sumber, tujuan, dan mesin fotokopi dapat memengaruhi performa dengan cara yang unik.

Untuk mempelajari lebih lanjut, lihat Menggunakan salinan file untuk mengukur performa penyimpanan.

Eksperimen dan beban kerja umum

Bagian ini mencakup beberapa contoh, eksperimen, dan jenis beban kerja lainnya.

Mengonfirmasi node koordinator

Seperti disebutkan sebelumnya, jika VM yang sedang Anda uji saat ini tidak memiliki CSV, Anda akan melihat penurunan performa (IOPS, throughput, dan latensi) sebagai lawan mengujinya saat node memiliki CSV. Ini karena setiap kali Anda mengeluarkan operasi I/O, sistem melakukan jaringan melompat ke node koordinator untuk melakukan operasi itu.

Untuk situasi cermin tiga simpul, tiga arah, operasi tulis selalu membuat lompatan jaringan karena perlu menyimpan data pada semua drive di tiga node. Oleh karena itu, operasi tulis membuat jaringan hop terlepas. Namun, jika Anda menggunakan struktur ketahanan yang berbeda, ini bisa berubah.

Berikut contohnya:

Berjalan pada node lokal: .\DiskSpd-2.0.21a\amd64\diskspd.exe -t4 -o32 -b4k -r4k -w0 -Sh -D -L C:\ClusterStorage\test01\targetfile\IO.dat
Berjalan pada node nonlokal: .\DiskSpd-2.0.21a\amd64\diskspd.exe -t4 -o32 -b4k -r4k -w0 -Sh -D -L C:\ClusterStorage\test01\targetfile\IO.dat

Dari contoh ini, Anda dapat dengan jelas melihat di hasil gambar berikut bahwa latensi menurun, IOPS meningkat, dan throughput meningkat ketika node koordinator memiliki CSV.

Beban kerja Pemrosesan Transaksi Online (OLTP)

Kueri beban kerja Pemrosesan Transaksional Online (OLTP) (Perbarui, Sisipkan, Hapus) fokus pada tugas yang berorientasi transaksi. Dibandingkan dengan Pemrosesan Analitik Daring (OLAP), OLTP bergantung pada latensi penyimpanan. Karena setiap operasi mengeluarkan I/O kecil, yang Anda pedulikan adalah berapa banyak operasi per detik yang dapat dipertahankan.

Anda dapat merancang pengujian beban kerja OLTP untuk fokus pada performa I/O acak dan kecil. Untuk pengujian ini, fokuslah pada seberapa jauh Anda dapat mendorong throughput sambil mempertahankan latensi yang dapat diterima.

Pilihan desain dasar untuk pengujian beban kerja ini minimal harus mencakup:

Ukuran blok 8 KB => menyerupai ukuran halaman yang digunakan SQL Server untuk file datanya
70% Baca, 30% Tulis => menyerupai perilaku OLTP umum

Beban kerja Pemrosesan Analitik Daring (OLAP)

Beban kerja OLAP berfokus pada pengambilan dan analisis data, memungkinkan pengguna melakukan kueri kompleks untuk mengekstrak data multidimensi. Bertentangan dengan OLTP, beban kerja ini tidak sensitif terhadap latensi penyimpanan. Beban kerja menekankan antrean banyak operasi tanpa peduli banyak tentang bandwidth. Akibatnya, beban kerja OLAP sering kali menghasilkan waktu pemrosesan yang lebih lama.

Anda dapat merancang pengujian beban kerja OLAP untuk fokus pada performa I/O yang berurutan dan besar. Untuk pengujian ini, fokuslah pada volume data yang diproses per detik daripada jumlah IOPS. Persyaratan latensi juga kurang penting, tetapi ini bersifat subjektif.