İş yükü depolama performansını test etmek için DISKSPD kullanma

Makale
11/23/2024

Şunlar için geçerlidir: Azure Stack HCI, sürüm 22H2 ve 21H2; Windows Server 2022, Windows Server 2019

Önemli

Azure Stack HCI artık Azure Yerel'in bir parçasıdır. Ürün belgelerini yeniden adlandırma işlemi devam ediyor. Ancak Azure Stack HCI'nin eski sürümleri, örneğin 22H2, Azure Stack HCI'ye başvurmaya devam eder ve ad değişikliğini yansıtmaz. Daha fazla bilgi edinin.

Bu konu, iş yükü depolama performansını test etmek için DISKSPD'nin nasıl kullanılacağına ilişkin rehberlik sağlar. Ayarlanmış, kullanılmaya hazır bir Azure Stack HCI kümeniz var. Harika, ama ister gecikme süresi, ister aktarım hızı, isterse IOPS olsun taahhüt edilen performans ölçümlerini elde edip etmeyeceğinizi nasıl bilebilirsiniz? İşte bu noktada DISKSPD'ye geçmek isteyebilirsiniz. Bu konuyu okuduktan sonra DISKSPD'yi çalıştırmayı, parametrelerin bir alt kümesini anlamayı, çıkışı yorumlamayı ve iş yükü depolama performansını etkileyen değişkenleri genel olarak anlamayı öğreneceksiniz.

DISKSPD nedir?

DISKSPD, mikro karşılaştırma için bir G/Ç oluşturma, komut satırı aracıdır. Harika, tüm bu terimler ne anlama geliyor? Azure Stack HCI kümesi veya fiziksel sunucu ayarlayan herkesin bir nedeni vardır. Bir web barındırma ortamı ayarlamak veya çalışanlar için sanal masaüstleri çalıştırmak olabilir. Gerçek dünya kullanım örneği her ne olursa olsun, gerçek uygulamanızı dağıtmadan önce bir testin benzetimini yapmak isteyebilirsiniz. Ancak uygulamanızı gerçek bir senaryoda test etme genellikle zordur; diskSPD burada devreye girer.

DISKSPD, kendi yapay iş yüklerinizi oluşturmak ve dağıtımdan önce uygulamanızı test etmek için özelleştirebileceğiniz bir araçtır. Aracın en güzel özelliği, gerçek iş yükünüze benzeyen belirli bir senaryo oluşturmak için parametreleri yapılandırma ve ayarlama özgürlüğü vermesidir. DISKSPD, dağıtımdan önce sisteminizin neler yapabildiğine dair size bir bakış sağlayabilir. DiskSPD, temel olarak bir dizi okuma ve yazma işlemi gerçekleştirir.

Artık DISKSPD'nin ne olduğunu biliyorsunuz, ancak ne zaman kullanmalısınız? DISKSPD karmaşık iş yüklerini öykünmede zorlanıyor. Ancak, iş yükünüz tek iş parçacıklı bir dosya kopyasıyla yakın bir şekilde yakın değilse ve kabul edilebilir temel sonuçlar üreten basit bir araca ihtiyacınız olduğunda DISKSPD harikadır.

Hızlı başlangıç: DISKSPD'yi yükleme ve çalıştırma

DISKSPD'yi yüklemek ve çalıştırmak için PowerShell'i yönetim bilgisayarınızda yönetici olarak açın ve aşağıdaki adımları izleyin:

DISKSPD aracının ZIP dosyasını indirmek ve genişletmek için aşağıdaki komutları çalıştırın:

# 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 dizinini ortam değişkeninize $PATH eklemek için aşağıdaki komutu çalıştırın:

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

Aşağıdaki PowerShell komutuyla DISKSPD'yi çalıştırın. Köşeli ayraçları uygun ayarlarınızla değiştirin.
```
diskspd [INSERT_SET_OF_PARAMETERS] [INSERT_CSV_PATH_FOR_TEST_FILE] > [INSERT_OUTPUT_FILE.txt]
```
Aşağıda çalıştırabileceğiniz bir örnek komut verilmişti:
```
diskspd -t2 -o32 -b4k -r4k -w0 -d120 -Sh -D -L -c5G C:\ClusterStorage\test01\targetfile\IO.dat > test01.txt
```
Not

Bir test dosyanız yoksa, oluşturmak için -c parametresini kullanın. Bu parametreyi kullanıyorsanız, yolunuzu tanımlarken test dosyası adını eklediğinizden emin olun. Örneğin: [INSERT_CSV_PATH_FOR_TEST_FILE] = C:\ClusterStorage\CSV01\IO.dat. Örnek komutta, IO.dat test dosyası adı ve test01.txt DISKSPD çıkış dosyası adıdır.

Anahtar parametreleri belirtme

Bu çok basitti, değil mi? Ne yazık ki, bundan daha fazlası var. Yaptığımız şeyi paketten çıkaralım. İlk olarak, birlikte kullanabileceğiniz çeşitli parametreler vardır ve bu parametreler belirli olabilir. Ancak aşağıdaki temel parametre kümesini kullandık:

Not

DISKSPD parametreleri büyük/küçük harfe duyarlıdır.

-t2: Bu, hedef/test dosyası başına iş parçacığı sayısını gösterir. Bu sayı genellikle CPU çekirdeği sayısına bağlıdır. Bu durumda, tüm CPU çekirdeklerini strese almak için iki iş parçacığı kullanılmıştır.

-o32: Bu, iş parçacığı başına hedef başına bekleyen G/Ç isteklerinin sayısını gösterir. Bu, kuyruk derinliği olarak da bilinir ve bu durumda CPU'ya vurgu yapmak için 32 kullanılmıştır.

-b4K: Blok boyutunu bayt, KiB, MiB veya GiB cinsinden gösterir. Bu durumda, rastgele G/Ç testinin benzetimini yapmak için 4K blok boyutu kullanılmıştır.

-r4K: Bu, belirtilen boyuta hizalanmış rastgele G/Ç'yi bayt, KiB, MiB, Gib veya blok cinsinden gösterir (-s parametresini geçersiz kılar). Blok boyutuyla düzgün hizalamak için ortak 4K bayt boyutu kullanıldı.

-w0: Yazma istekleri olan işlemlerin yüzdesini belirtir (-w0, %100 okuma ile eşdeğerdir). Bu durumda, basit bir test amacıyla %0 yazma kullanılmıştır.

-d120: Bu, bekleme veya ısınma dahil olmak üzere testin süresini belirtir. Varsayılan değer 10 saniyedir, ancak ciddi iş yükleri için en az 60 saniye kullanmanızı öneririz. Bu durumda aykırı değerleri en aza indirmek için 120 saniye kullanılmıştır.

-Suw: Yazılım ve donanım yazma önbelleğini devre dışı bırakır (-Sh ile eşdeğerdir).

-D: Standart sapma gibi IOPS istatistiklerini milisaniyelik aralıklarla (iş parçacığı başına, hedef başına) yakalar.

-L: Gecikme istatistiklerini ölçer.

-c5g: Testte kullanılan örnek dosya boyutunu ayarlar. Bayt, KiB, MiB, GiB veya blok olarak ayarlanabilir. Bu durumda 5 GB hedef dosyası kullanılmıştır.

Parametrelerin tam listesi için GitHub deposuna bakın.

Ortamı anlama

Performans büyük ölçüde ortamınıza bağlıdır. Peki, ortamımız nedir? Belirtimimiz, depolama havuzu ve Depolama Alanları Doğrudan (S2D) içeren bir Azure Stack HCI kümesi içerir. Daha açık belirtmek gerekirse, beş VM vardır: DC, node1, node2, node3 ve yönetim düğümü. Kümenin kendisi, üç yönlü yansıtılmış dayanıklılık yapısına sahip üç düğümlü bir kümedir. Bu nedenle, üç veri kopyası korunur. Kümedeki her "düğüm", en fazla IOPS sınırı 1920 olan bir Standard_B2ms VM'dir. Her düğümde, maksimum IOPS sınırı 5000 olan dört premium P30 SSD sürücüsü vardır. Son olarak, her SSD sürücüsü 1 TB belleğe sahiptir.

Test dosyasını Küme Paylaşılan Birimi'nin (CSV) sürücü havuzunun tamamını kullanmak için sağladığı birleşik ad alanı (C:\ClusteredStorage) altında oluşturursunuz.

Not

Örnek ortamda Hyper-V veya iç içe sanallaştırma yapısı yoktur .

Göreceğiniz gibi, VM'de veya sürücü sınırında IOPS veya bant genişliği tavanını bağımsız olarak tutturmak tamamen mümkündür. Bu nedenle, sanal makinenizin boyutunu ve sürücü türünü anlamanız önemlidir çünkü her ikisi de maksimum IOPS sınırına ve bant genişliği tavana sahiptir. Bu bilgiler performans sorunlarını bulmanıza ve performans sonuçlarınızı anlamanıza yardımcı olur. İş yükünüz için uygun olabilecek boyut hakkında daha fazla bilgi edinmek için aşağıdaki kaynaklara bakın:

Çıktıyı anlama

Parametreleri ve ortamı anlamanıza yardımcı olacak şekilde çıktıyı yorumlamaya hazırsınız. İlk olarak, önceki testin amacı gecikme süresine bakı olmadan IOPS'yi maksimuma çıkarmaktı. Bu şekilde Azure'da yapay IOPS sınırına ulaşıp ulaşmayabileceğinizi görsel olarak görebilirsiniz. Toplam IOPS'yi grafik olarak görselleştirmek istiyorsanız Windows Yönetim Merkezi'ni veya Görev Yöneticisi'ni kullanın.

Aşağıdaki diyagramda DISKSPD işleminin örnek ortamımızda nasıl göründüğü gösterilmektedir. Koordinatör olmayan bir düğümden 1 MiB yazma işleminin bir örneğini gösterir. Üç yönlü dayanıklılık yapısı, koordinatör olmayan bir düğümden gelen işlemle birlikte iki ağ atlamasına yol açar ve performansı düşürür. Koordinatör düğümünü merak ediyorsanız endişelenmeyin! Dikkate alınacak şeyler bölümünde bu konuda bilgi edineceksiniz. Kırmızı kareler VM'yi temsil eder ve performans sorunlarını yönlendirir.

Artık görsel bir anlayış edindiğinize göre, .txt dosya çıkışının dört ana bölümünü inceleyelim:

Giriş ayarları

Bu bölümde çalıştırdığınız komut, giriş parametreleri ve test çalıştırması hakkında ek ayrıntılar açıklanmaktadır.
CPU kullanım ayrıntıları

Bu bölümde test süresi, iş parçacığı sayısı, kullanılabilir işlemci sayısı ve test sırasında her CPU çekirdeğinin ortalama kullanımı gibi bilgiler vurgulanır. Bu durumda yaklaşık %4,67 kullanım ortalaması elde eden iki CPU çekirdeği vardır.
Toplam G/Ç

Bu bölümde üç alt bölüm vardır. İlk bölümde hem okuma hem de yazma işlemleri de dahil olmak üzere genel performans verileri vurgulanır. İkinci ve üçüncü bölümler okuma ve yazma işlemlerini ayrı kategorilere ayırır.

Bu örnekte toplam G/Ç sayısının 120 saniyelik süre boyunca 234408 olduğunu görebilirsiniz. Bu nedenle, IOPS = 234408 /120 = 1953.30. Ortalama gecikme süresi 32,763 milisaniye ve aktarım hızı 7,63 MiB/sn'dir. Önceki bilgilerden, 1953.30 IOPS'nin Standard_B2ms VM'miz için 1920 IOPS sınırlamasının yakınında olduğunu biliyoruz. İnanmıyor musun? Bu testi kuyruk derinliğini artırma gibi farklı parametreler kullanarak yeniden çalıştırırsanız sonuçların yine de bu sayıda eşlendiğini görürsünüz.

Son üç sütunda IOPS'nin standart sapması 17,72 (-D parametresinden), 20,994 milisaniyedeki gecikme süresinin standart sapması (-L parametresinden) ve dosya yolu gösterilir.

Sonuçlardan küme yapılandırmasının korkunç olduğunu hızla belirleyebilirsiniz. 5000 SSD sınırlaması öncesinde VM sınırlaması olan 1920'ye denk geldiğini görebilirsiniz. VM yerine SSD ile sınırlıysanız, test dosyasını birden çok sürücüye yayarak 20000 IOPS'den (4 sürücü * 5000) yararlanabilirdiniz.

Sonunda, belirli iş yükünüz için hangi değerlerin kabul edilebilir olduğunu belirlemeniz gerekir. Aşağıdaki şekilde, dengeleri dikkate almanıza yardımcı olacak bazı önemli ilişkiler gösterilmektedir:

Şekildeki ikinci ilişki önemlidir ve bazen Little Yasası olarak da adlandırılır. Yasa, süreç davranışını yöneten üç özellik olduğu ve diğer ikisini ve dolayısıyla sürecin tamamını etkilemek için yalnızca birini değiştirmeniz gerektiği fikrini ortaya atıyor. Sisteminizin performansından memnun değilseniz, bunu etkilemek için üç özgürlük boyutuna sahip olursunuz. Little Yasası, örneğimizde IOPS'nin "aktarım hızı" (saniye başına giriş çıkış işlemleri), gecikme süresinin "kuyruk süresi" ve kuyruk derinliğinin de "envanter" olduğunu belirler.
Gecikme süresi yüzdebirlik analizi

Bu son bölümde, en düşük değerden maksimum değere kadar depolama performansının işlem türü başına yüzdebirlik gecikme süreleri ayrıntılı olarak açıklanmıştır.

Bu bölüm, IOPS'nizin "kalitesini" belirlediğinden önemlidir. G/Ç işlemlerinin kaçının belirli bir gecikme süresi değerine ulaşabildiği ortaya çıkar. Bu yüzdebirlik için kabul edilebilir gecikme süresine karar vermek size kalmış.

Dahası, "dokuzlar" dokuz sayısını ifade eder. Örneğin, "3-dokuz" 99. yüzdebirlik değere eşdeğerdir. Dokuz sayısı, bu yüzdebirlik dilimde kaç G/Ç işleminin çalıştırıldığını gösterir. Sonunda, gecikme süresi değerlerini ciddiye almanın artık anlamlı olmadığı bir noktaya ulaşırsınız. Bu durumda gecikme değerlerinin "4-dokuz" sonrasında sabit kaldığını görebilirsiniz. Bu noktada gecikme süresi değeri, 234408 işlemlerinden yalnızca bir G/Ç işlemine dayanır.

Dikkate alınacak noktalar

ARTıK DISKSPD kullanmaya başladığınıza göre, gerçek dünya test sonuçlarını almak için göz önünde bulundurmanız gereken birkaç şey vardır. Bunlar arasında ayarladığınız parametrelere, depolama alanı durumu ve değişkenlerine, CSV sahipliğine ve DISKSPD ile dosya kopyalama arasındaki farka çok dikkat etmek yer alır.

DISKSPD ile gerçek dünya karşılaştırması

DISKSPD'nin yapay testi, gerçek iş yükünüz için nispeten karşılaştırılabilir sonuçlar verir. Ancak, ayarladığınız parametrelere ve bunların gerçek senaryonuzla eşleşip eşleşmediğine dikkat etmeniz gerekir. Yapay iş yüklerinin dağıtım sırasında uygulamanızın gerçek iş yükünü hiçbir zaman mükemmel bir şekilde temsil etmeyeceğini anlamak önemlidir.

Hazırlık

DISKSPD testi çalıştırmadan önce önerilen birkaç eylem vardır. Bunlar depolama alanının durumunu doğrulamayı, başka bir programın teste müdahale etmemesi için kaynak kullanımınızı denetlemeyi ve ek veri toplamak istiyorsanız performans yöneticisini hazırlamayı içerir. Ancak, bu konunun amacı DISKSPD'yi hızlı bir şekilde çalıştırmak olduğundan, bu eylemlerin ayrıntılarına dalmaz. Daha fazla bilgi edinmek için bkz. Windows Server'da Yapay İş Yüklerini Kullanarak Depolama Alanları Performansını Test Etme.

Performansı etkileyen değişkenler

Depolama performansı hassas bir şeydir. Başka bir deyişle, performansı etkileyebilecek birçok değişken vardır. Bu nedenle, beklentilerinizle tutarsız bir sayıyla karşılaşabilirsiniz. Aşağıda, kapsamlı bir liste olmasa da performansı etkileyen bazı değişkenler vurgulanır:

Ağ bant genişliği
Dayanıklılık seçimi
Depolama diski yapılandırması: NVME, SSD, HDD
G/Ç arabelleği
Önbellek
RAID yapılandırması
Ağ atlamaları
Sabit sürücü iş mili hızları

CSV sahipliği

Düğüm, birim sahibi veya koordinatör düğümü olarak bilinir (koordinatör olmayan düğüm, belirli bir birime sahip olmayan düğüm olabilir). Her standart birime bir düğüm atanır ve diğer düğümler ağ atlamaları aracılığıyla bu standart birime erişebilir ve bu da performansın daha yavaş olmasına (daha yüksek gecikme süresi) neden olur.

Benzer şekilde, Küme Paylaşılan Biriminin (CSV) de bir "sahibi" vardır. Ancak CSV, sistemi her yeniden başlattığınızda (RDP) gezinip sahipliği değiştireceği için "dinamiktir". Sonuç olarak, DISKSPD'nin CSV'nin sahibi olan koordinatör düğümünden çalıştırıldığını onaylamak önemlidir. Aksi takdirde CSV sahipliğini el ile değiştirmeniz gerekebilir.

CSV sahipliğini onaylamak için:

Aşağıdaki PowerShell komutunu çalıştırarak sahipliği denetleyin:
```
 Get-ClusterSharedVolume
```
CSV sahipliği yanlışsa (örneğin, Node1'desiniz ancak CSV'nin sahibi Node2'dir) aşağıdaki PowerShell komutunu çalıştırarak CSV'yi doğru düğüme taşıyın:
```
 Get-ClusterSharedVolume <INSERT_CSV_NAME> | Move-ClusterSharedVolume <INSERT _NODE_NAME>
```

Dosya kopyalama ve DISKSPD karşılaştırması

Bazı kişiler, büyük bir dosyayı kopyalayıp yapıştırarak ve bu işlemin ne kadar sürdüğünü ölçerek "depolama performansını test sınayabileceklerine" inanıyor. Bu yaklaşımın arkasındaki temel neden büyük olasılıkla basit ve hızlı olmasıdır. Fikir, belirli bir iş yükünü test etme açısından yanlış değildir, ancak bu yöntemi "depolama performansını test etme" olarak kategorilere ayırmak zordur.

Gerçek dünya hedefiniz dosya kopyalama performansını test etmekse, bu yöntemi kullanmak için son derece geçerli bir neden olabilir. Ancak, amacınız depolama performansını ölçmekse bu yöntemi kullanmamanızı öneririz. Dosya kopyalama işlemini, dosya hizmetlerine özgü farklı bir "parametre" kümesi (kuyruk, paralelleştirme vb.) kullanmak olarak düşünebilirsiniz.

Aşağıdaki kısa özette, depolama performansını ölçmek için dosya kopyalama kullanmanın neden aradığınız sonuçları sağlayamayabilir olduğu açıklanmaktadır:

Dosya kopyaları iyileştirilmeyebilir, Biri iç, diğeri dış olmak üzere iki paralellik düzeyi oluşur. Dahili olarak, dosya kopyası uzak bir hedefe gidiyorsa CopyFileEx altyapısı bazı paralelleştirmeler uygular. Dışarıdan, CopyFileEx altyapısını çağırmanın farklı yolları vardır. Örneğin, Dosya Gezgini kopyaları tek iş parçacıklı, ancak Robocopy çok iş parçacıklı. Bu nedenlerden dolayı, testin sonuçlarının aradığınız şey olup olmadığını anlamak önemlidir.
Her kopyanın iki tarafı vardır. Bir dosyayı kopyalayıp yapıştırdığınızda, iki disk kullanıyor olabilirsiniz: kaynak disk ve hedef disk. Biri diğerinden daha yavaşsa, temelde yavaş diskin performansını ölçersiniz. Kaynak, hedef ve kopyalama altyapısı arasındaki iletişimin performansı benzersiz şekillerde etkileyebileceği başka durumlar da vardır.

Daha fazla bilgi edinmek için bkz . Depolama performansını ölçmek için dosya kopyalamayı kullanma.

Denemeler ve yaygın iş yükleri

Bu bölüm diğer birkaç örnek, deneme ve iş yükü türünü içerir.

Koordinatör düğümünü onaylama

Daha önce de belirtildiği gibi, şu anda test ettiğiniz VM CSV'ye sahip değilse, düğüm CSV'ye sahip olduğunda test etmek yerine bir performans düşüşü (IOPS, aktarım hızı ve gecikme süresi) görürsünüz. Bunun nedeni, her G/Ç işlemi gerçekleştirdiğinizde sistemin bu işlemi gerçekleştirmek için koordinatör düğümüne bir ağ atlama işlemi gerçekleştirmesidir.

Üç düğümlü, üç yönlü yansıtmalı bir durum için yazma işlemleri her zaman bir ağ atlama yapar çünkü üç düğümdeki tüm sürücülerde veri depolaması gerekir. Bu nedenle, yazma işlemleri ne olursa olsun bir ağ atlama yapar. Ancak farklı bir dayanıklılık yapısı kullanırsanız bu durum değişebilir.

Bir örnek aşağıda verilmiştir:

Yerel düğümde çalışıyor: diskspd.exe -t4 -o32 -b4k -r4k -w0 -Sh -D -L C:\ClusterStorage\test01\targetfile\IO.dat
Yerel olmayan düğümde çalışıyor: diskspd.exe -t4 -o32 -b4k -r4k -w0 -Sh -D -L C:\ClusterStorage\test01\targetfile\IO.dat

Bu örnekten aşağıdaki şekilde elde edilen sonuçlarda gecikme süresinin azaldığını, IOPS'nin arttığını ve koordinatör düğümü CSV'ye sahip olduğunda aktarım hızının arttığını açıkça görebilirsiniz.

Çevrimiçi İşlem İşleme (OLTP) iş yükü

Çevrimiçi İşlem İşleme (OLTP) iş yükü sorguları (Güncelleştirme, Ekleme, Silme) işlem odaklı görevlere odaklanır. OlTP, Çevrimiçi Analitik İşleme (OLAP) ile karşılaştırıldığında depolama gecikme süresine bağlıdır. Her işlem çok az G/Ç sağladığından, saniye başına kaç işlem yapabileceğinizi önemsersiniz.

Rastgele, küçük G/Ç performansına odaklanmak için OLTP iş yükü testi tasarlayabilirsiniz. Bu testlerde, kabul edilebilir gecikme sürelerini korurken aktarım hızını ne kadar ileri gönderebileceğinize odaklanın.

Bu iş yükü testi için temel tasarım seçimi en azından şunları içermelidir:

8 KB blok boyutu => SQL Server'ın veri dosyaları için kullandığı sayfa boyutuna benzer
%70 Okuma, %30 Yazma => tipik OLTP davranışına benzer

Çevrimiçi Analitik İşleme (OLAP) iş yükü

OLAP iş yükleri veri alma ve çözümlemeye odaklanarak kullanıcıların çok boyutlu verileri ayıklamak için karmaşık sorgular gerçekleştirmesine olanak sağlar. OLTP'nin aksine, bu iş yükleri depolama gecikmesine duyarlı değildir. Bant genişliğine fazla önem vermeden birçok işlemi kuyruğa alma işlemini vurgular. Sonuç olarak, OLAP iş yükleri genellikle daha uzun işleme süreleriyle sonuçlanır.

Sıralı, büyük G/Ç performansına odaklanmak için bir OLAP iş yükü testi tasarlayabilirsiniz. Bu testler için IOPS sayısı yerine saniyede işlenen veri hacmine odaklanın. Gecikme süresi gereksinimleri de daha az önemlidir, ancak bu özneldir.