「PowerStore：ストレージ アレイのパフォーマンスを評価するための効果的な手法

注：ベンチマーキングは、PowerStoreのベスト プラクティスに従ってすべてが設定され、接続や構成の問題がない場合にのみ有効です。そうしないと、テストで無関係なデータが生成される可能性があります。

• 実際のワークロード/環境に類似した変数を使用してテストします。ほとんどのツールはシミュレーターであり、シミュレートされた実際の本番ワークロードを100%達成することはできないことに注意してください。
• ワークロードの範囲が広い場合は、ブロック長とアクセス パターンを変えて読み取り/書き込みテストを複数回繰り返すことを検討してください。
• マルチスレッドおよび非同期の操作またはテストを使用して、並列または並列のパフォーマンス機能を確認し、全体的な総スループットの可能性が発揮されるようにします。 
• ビジネスの本番ワークロードに関連する評価対象の機器の業界標準ベンチマークを検討し、レビューします。
• 空またはスペース使用率の低いファイル システムやボリュームに対するテストは避けてください。書き込みワークロードにスペースを事前に割り当てない場合は、テスト中にスペースがオンザフライで割り当てられるため、レイテンシーが発生する可能性があります。
• 読み取りI/Oは通常、ほとんどの環境でこの2つのうちの支配的なI/Oであるため、忘れずにテストしてください。テスト中は、ネットワーク インフラストラクチャのパケット/フレーム損失に注意してください。
• 多数のホストまたはクライアントを持つ一般的な環境をシミュレートするために、複数のデバイスに対してテストを行っていることを確認します。たとえば、PowerStoreでは、適切な数は16ボリュームです。ボリューム数は通常、使用されているホストまたはクライアントの数(物理または仮想)と一致します。ここで同時実行性が実現されます。

 

ベンチマーキング ツールとシミュレーター
ほとんどのツールはシミュレーターであり、実際の本番ワークロードを100%シミュレートすることはおそらくないことに注意してください。これらのベンチマーキング ツールは、特定の状況でパフォーマンスがどのようになり得るか、どのようにすべきか、またはどのようになるかについてのアイデアを得るために使用されます。Dellはこれらのツールを所有しておらず、それらに関連する可能性のあるいかなる問題に対しても責任を負いません

どのようなパフォーマンス テストでも、非同期およびマルチスレッド機能を備えたツールが使用されていることを確認します。これらのツールの例は次のとおりです。

• フレキシブルI/Oテスタ(FIO)
• IOmeter
• Vdbench(Oracleアカウントが必要)
• NFSometer(Fedora/NFS のみ)
• インテルのNASパフォーマンス チェックリスト

 

次のタイプのテストは避けてください。

• コピー&ペースト
• ドラッグ アンド ドロップ
• ディスクへの単一ファイル システムのバックアップ
• DDテスト
• Rlarge
• Wlarge(ウーラージ)
• Mkfileの
• 解凍、解凍、解凍

ほとんどのベンチマーク シナリオでは、注意すべき点がいくつかあります。このセクションは、ワークロードのサイズと特性を理解するための代替ではありません。ただし、過去のデータが不足しており、(特定のワークロードのパフォーマンスではなく)PowerStoreの機能をベンチマークするためにアプリケーションの動作を大まかに見積もる必要がある場合は、次の要因を考慮してください。

 

 

IODepth(キューの深さ)
IOdepthが低い(または十分に高くない)と、状況に応じて潜在的なスループットが制限される可能性があります。したがって、IOdepthがワークロードの同時実行要件を反映またはエミュレートするのに十分な高さであることを常に確認してください。IOdepthが小さすぎると、デバイスを最大限に活用できない可能性があります。また、IOdepthが高すぎる場合は注意してください。これにより、デバイスで大きなキューイングが発生する可能性があり、デバイスのサービス時間によっては、結果としてレスポンス タイムが長くなる可能性があります。これは、過負荷のシステムがどのようなものかを反映している可能性があります。

このテストでは、IOdepth が 1 の場合、IOdepth が 64 など、より現実的な値である場合、数値は大幅に低くなります。これはオールフラッシュアレイの場合です。したがって、この概念は極端ですが、ますます一般的になりつつある形で見られます。

IOdepth=1」では、テストの平均I/O操作毎秒(IOPS)は約~30,000です。

 

「IOdepth=64」は、テストの平均IOPSは約~107,000です。

 

 

「IOdepth=256」は、テストの平均IOPSは約~142,000です。

 

 

前述のように、ほとんどの構成では、特定のIOdepthでパフォーマンスが横ばいになります。ここではキューの深さが512で、IOPSは64.

からわずかに増加しています。IOdepth=512」では、テストの平均IOPSは約~146,000です。

 

 


非同期と同期
使用されるエンジンは大きく分けて2つあります。最も人気があり、パフォーマンスの面で圧倒的に効率的なのは「非同期I/O」です。効率性やパフォーマンスの低いタイプのエンジンは同期I/Oであり、通常はデータの整合性と保証の要件が厳しいアプリケーションで使用されます。同期I/Oは、ほぼゼロの目標リカバリー ポイント(RPO)レプリケーション テクノロジーでも見られます。パフォーマンス テストとベンチマーキングでは、ホストの観点からは、非同期とは、次のI/Oを要求するために単一のI/Oに対して確認応答が必要ないことを意味します。同期ワークロードでは、次に発行される前のI/Oに対する確認応答と、それ以降の要求されるすべてのI/Oに対する確認(ACK)が必要です。したがって、同期I/Oでは通常、キューのキューは1以下となり、リソースをフル活用することはありません。スレッド数が少ない、またはスレッド数が 1 つの同期操作を結合すると、パフォーマンスの可能性が大幅に制限される可能性があるため、非同期テストを実行していることを常に確認し、同期テストを使用している場合は、アプリケーション環境が明示的に指摘していない限り、必ず複数のスレッドを使用してください

非同期(Libaio - Linuxネイティブ非同期) = 1スレッド

 

同期(同期I/O):

 

 

スレッド数
スレッドは重要です。特に同期テスト/ワークロードでは、テストは常に複数のスレッドを使用して行う必要があります。これは、エンタープライズ アプリケーションのプロセスの動作に基づいて、ジョブ/テストの複数回の反復をシミュレートしようとするためです。複数のスレッドと並行アクティビティが組み合わさることで、システムの総スループットが達成されます。ほとんどの非同期エンジンは複数のスレッドを使用するため、スレッド数をそれほど気にする必要はありません。同期ワークロード中に十分なスレッドがないと、システムに対するロード テストの潜在的な合計スループットが大幅に制限される可能性があります。

"「マルチスレッド」とは、複数のスレッドが並行して作業を行うことを意味します。たとえば、同期ワークロードで1,000 IOPSを処理できる単一のデバイスがある場合、キューなしで1ミリ秒のレスポンス タイムを持つデバイスになります(キューがない場合、サービス タイムとレスポンス タイムは同義になります)。明らかに、レスポンス タイムが1ミリ秒のデバイスでは、1,000 IOPSよりもはるかに多くの作業を行うことができます。これは、同じワークロードの複数のスレッドまたは並列ストリームをスタックすることによって実現されます。したがって、スレッド (または「この特定のジョブを実行するもの」) を 10 に増やすと、10 ミリ秒でデバイスへの I/O を実行するスレッドが 10 個になります。個々のワークロード スレッドは依然として1ミリ秒を取得しています。つまり、各スレッドはまだ1,000 IOPSしか達成していませんが、これらの複数のスレッドによって実行されている「プロセス」または「ジョブ」全体で10,000 IOPSを取得しています

1つのスレッドでデバイスの限界を十分に満たすことができるツールとワークロードがあり、さらに必要なツールとワークロードもあります。要約すると、同期負荷をシミュレートする場合は、全体的な応答時間に影響を与えることなく、できるだけ多くのスレッド/ワーカー/ストリームが必要です。スレッド数を増やすと、プラスの効果がなくなるポイントがあります (デバイスが 100% ビジー状態になったとき)。一般に、非同期ワークロードでは、スレッド数がデフォルトで処理されます。たとえば、以下では、非同期ワークロードの 1 スレッドと 10 スレッドの違いを確認できますが、重要ではありません。この話の教訓は、非同期ワークロードでは、スレッドについてそれほど心配する必要はないということです。

ここでの1つのスレッドは、「libaio」(非同期)エンジンを使用して68,000 IOPSを達成できます。 

 

スレッド数(numjobs)を10に増やしても、IOPSは増加します。

 

同期ワークロードに関しては、これは極端なケースですが、このテストのパフォーマンスを低下させる2つの主な要因が発生する可能性があります。それは同期の性質です。 

I/O-1の送信、ACKの待機、I/O-2の送信、ACKの待機といった動作

 また、同じ目的で複数のスレッドをスタックすることはできません。 

job1= I/O-1 の送信 - job2= I/O-1 の送信 - job3 = I/O-1 の送信.....job1=get ack、I/O-2の送信 - job2=get ack、I/O-2の送信 - job3 = ackの取得、I/O-2の送信など

ダイレクト フラグ

一部のツール、特に*nixベースのツール/OSでは、「Direct I/O」のオプションが表示される場合があります。これは「非同期」エンジンで使用でき、「同期」I/Oと混同しないでください。このフラグが指定されていない一部のツールでは、ディスクに直接書き込むのではなく、サーバー キャッシュに書き込む可能性があります。ホストが行おうとしていることは、自身のキャッシュをバイパスし、ディスクに直接書き込むことです。これは、ストレージをテストする際に不可欠な要素です。「direct」フラグが設定されている場合は、技術的にはディスクに書き込んでいますが、この場合の「ディスク」は実際にはストレージキャッシュです。これは、テスト目的では許容されます。なぜなら、適切なワークロードを使用しても、実際の環境でこのワークロードがどのように動作するかをシミュレーションし、正確に模倣しているためです。本番環境の負荷も確認応答を送信する前にキャッシュにヒットするためです。(バックエンド スピンドルだけでなく、キャッシュのパフォーマンス数値が関与しているからといって、だまされたと感じないでください)。

 

帯域幅(MB/秒)対スループット(IOPS)

テストできる主な観点は 2 つあります。ネットワーキングとパフォーマンスの世界では、スループットは通常データ転送を指しますが、SAN/ブロック環境では、IOPSを表すために「スループット」を使用するのが一般的です。そのため、まずテスト対象のワークロードの特性を理解する必要があります

帯域幅(MB/秒): 帯域幅は、パイプまたはシステムに一度に(またはX間隔で、通常は「1秒あたり」)収めることができるデータの尺度です。これは、一定期間に転送したデータの量を測定していることを意味します。帯域幅とIOPSは相互に排他的ではありませんが、同じIOPS量でも帯域幅の数値を高くしたり低くしたりできます。すべてブロック長に依存します。帯域幅で速度を測定するのではなく、速度はまったく別のものであり、帯域幅には影響しますが、通常、高帯域幅のワークロードでは制御できないものであることを忘れないでください。したがって、帯域幅をテストする場合は、IOPSをテストする場合よりもI/Oあたりのデータが大きくなるように、常により大きなブロックを(無理のない範囲内で)使用してください。ブロックが大きいほど、当然処理に時間がかかります。たとえば、1 MB/秒を達成したいが、8 KBのブロック長を使用している場合は、これを達成するために約125 IOPSをプッシュする必要があります。ただし、512 KBのブロックを使用している場合は、2つのIOPSしか必要ありません
(125 IOPSを維持し、ブロック長を8 KBから512 KBに増やす場合は、64 MB/秒をプッシュすることになります

ただし、1つのI/O内にはより多くのデータがあるため、通常はそのI/Oを「パッケージ化」(検索、文字列化など)に時間がかかります。したがって、サービス時間は必然的に長くなる可能性があります。キューが小さい場合もあるため、応答時間は自然に長くなりますが、かなり近くなるはずです。レスポンス タイムは実現できる帯域幅に影響しますが、通常は、I/Oあたりのデータ量の増加の方が、そのタイプのI/Oあたりのレスポンス タイム(RT)のわずかな増加を上回ることに注意してください。レスポンス タイムが長くなるため、大きなブロックのワークロードをランダムにする必要はありません。そのため、帯域幅のワークロードはシーケンシャルになる傾向があります。大規模なブロック ワークロードにランダムな性質を導入すると、安定したデータ転送レートが常に中断され、I/Oあたりのレスポンス タイムがわずかに長くなるという影響を感じるようになります

スループット(IOPS) - スループット/IOPSは、特にランダム化が進むほど、小さめのブロックによるワークロードでは最も一般的な観点です。32 KB から 64 KB を超えるものは、大きなブロックと見なすことができます。スループットでは、上記の要素 (スレッド数、同期、非同期、キューの深さなど) が最も重要です。ここでは、X 間隔で転送できる全体的なデータ量ではなく、処理しようとしているデータを (x 間隔ごとに) 保持する個々のパッケージ (I/O 要求) の数を測定しようとしています。OLTP(銀行)などの環境では、通常、データ フットプリントが小さいため、転送可能なデータの量はあまり重要ではありません。ただし、これらの小さなデータ セットはビジー状態になる可能性があり、通常はビジー状態です。これらのデータセットには大きなスキューがあります (少量のスペースが参照されますが、積極的に一貫して変化します)。データの小さなパッケージには、通常、数値またはより小さな文字列値を持つブロックを変更/更新する要求のみが含まれているため、大きなI/Oパッケージは必要ありません。しかし、取引の性質上、また取引量が多いため、個々の需要に対応できるかを検証したいと考えています。通常、ブロックサイズが小さいほど、特定のシナリオで達成できるIOPSが大きくなります。小さなブロックのワークロードはほとんどの場合、ランダム アクセスに関連付けられていますが、小さなブロックのシーケンシャルなワークロードではさらに多くのスループットを達成できます。ただし、小さなブロックのシーケンシャル ワークロードは具体的であり、それほど一般的ではないため、これらのシナリオは、環境が必要とされる場合にのみテストしてください。