メインコンテンツまでスキップ

FAQ : ADR FS/ADR エンジン /BRE パフォーマンスの問題

Views:
76
Visibility:
Public
Votes:
0
Category:
data-ontap-8
Specialty:
perf
Last Updated:

すべてのとおり  

環境

Block Replication Engine ( BRE ;ブロックレプリケーションエンジン)

回答

ブロックレプリケーションエンジンのパフォーマンスの問題を 3 つにまとめています。 :

SnapMirror やボリューム移動などの Data ONTAP 製品では、 Block Replication Engine ( BRE )を使用してソースからデスティネーションにデータを転送します。場合によっては、製品が期待どおりに動作していないことがあります。これは、設定の問題、クライアントの問題、または転送エンジンを含むソフトウェアモジュールのいずれかのバグなど、さまざまな原因が考えられます。この記事では、パフォーマンス低下の原因となる可能性のある要因をいくつか紹介し、優先順位を付けるためのツールを紹介します。この記事では BRE に焦点を当てていますが、ここで説明する多くの要因は LRSE にも当てはまります。

BRE のパフォーマンスに影響する要因: :

次に、転送エンジンのパフォーマンスに影響を与える可能性のある多くの要因をいくつか示します。

  • システムに既存の負荷がかかっています
  • システム上のクライアントの負荷
  • 同時に試行された転送数 / ボリューム移動数
  • 転送のタイプ:初期化または更新。これは、ボリューム移動のベースラインフェーズまたは更新フェーズに対応します。
  • ストレージシステムのタイプ、ディスクのタイプ、アグリゲート内のディスク数、アグリゲート内のボリューム数などのシステム構成

これらの要因は、 SnapMirror 関係のソース、デスティネーション、またはボリュームの移動に適用されることがあります。

また、ネットワーク帯域幅が飽和していない理由をユーザが尋ねることもできます。これは、転送エンジンがネットワーク帯域幅によってボトルネックになっていないためです。ボトルネックは通常、ソースストレージシステムまたはデスティネーションストレージシステムにあります。(ネットワークがボトルネックになり、飽和状態になった場合、ユーザは関係に対してネットワーク圧縮を有効にできます。

上記の要因については、以下で詳しく説明します。

システムの既存の負荷:

ブロックレプリケーションエンジンは、ソースアグリゲートからブロックを読み取り、ネットワーク経由でデスティネーションアグリゲートに送信し、デスティネーションアグリゲートに書き込みます。これには、適切な処理を行うために予備の CPU サイクルが必要です。SnapMirror では同じ転送エンジンも使用されるため、 SnapMirror パフォーマンス実行のデータを使用して CPU 使用率を確認できます。たとえば、 FAS6280 では、 1 回の転送でソースとデスティネーションの使用可能な CPU の 25% が消費され、 8 回の同時転送でソースの CPU の 50% が消費され、デスティネーションの CPU の 55% が消費されます。そのため、システム上の既存の負荷が、ボリュームの移動や SnapMirror などの BRE クライアントの進捗に大きく影響する可能性があります。SnapMirror 転送またはボリューム移動を実行する前に、コントローラの CPU 使用率を 50% 未満に抑えることを推奨します。TR-4075 は、ボリュームのベストプラクティスと最適化のための DataMotion のボリューム移動のベストプラクティスガイドです

Data ONTAP の内部負荷:

クライアントトラフィックに直接関係しない Data ONTAP 内部トラフィックも、 TE パフォーマンスの低下を引き起こす可能性があります。

次に、この例をいくつか示します。

  • スキャナトラフィック:内部スキャナトラフィックによってシステム負荷が生成され、 CPU 負荷が増加して、転送エンジンで使用可能な CPU の量が減少することがあります。また、転送エンジンのスロットリングメカニズムが開始され、パフォーマンスがさらに低下する可能性もあります。
  • システム Kahuna の使用:ストレージシステムが Kahuna にかなりの時間を費やしている場合、他のシステムプロセスは実行できません。したがって、全体的な CPU 使用率が低いにもかかわらず、 Kahuna の使用率が高い場合でも、 TE ワークロードには実行するための十分な CPU サイクルがない可能性があります。これにより、そのシステムで実現可能な TE スループットが低下します。

クライアントの負荷:

SnapMirror とボリュームの移動は、バックグラウンドジョブとみなされます。基盤となる転送エンジンは、クライアントのワークロードが存在する環境でバックオフします。転送エンジンは、ノードスコープの読み取りおよび書き込みトークンプールを維持します。これらのトークンは、転送エンジンによって(すべての転送にわたって) WAFL に送信できる同時メッセージの数を制限します。システムは、 WAFL に送信された 1 秒あたりの処理数と、 WAFL で処理されるまでのメッセージの平均待機時間を追跡します(これは、 TE 自体から送信された処理を除く、 AFL に送信されたすべての処理に適用されます)。これらの 2 つの値が事前定義されたしきい値を超えると、 Transfer Engine は使用可能なトークンの数を減らし、クライアントが使用できるスループットを効率的に削減します( SnapMirror とボリュームの移動の両方)。たとえば、 FAS6280 上の clustered Data ONTAP 8.2 では、 8 つの同時転送で、アンロードされたシステムの総スループットが 1134 MB/ 秒になります。ソースノードに 60K のクライアント IOPS がある場合は 289MB/ 秒、 IOPS が 75K に達すると 206MB/ 秒、 IOPS が 120K に達すると 76MB/ 秒になりますこれらの IOPS レベルは、 SnapMirror トラフィックがない場合は 66.5% 、 75.8% 、 86.5% 、 SnapMirror トラフィックの場合は 75.6% 、 81.3% 、 86.5% の CPU 使用率に対応しています。したがって、システム上のクライアントの負荷は、 SnapMirror とボリュームの移動によって達成されるスループットに大きな影響を与える可能性があります。

このスロットリングメカニズムの副次的な効果は、内部の非レプリケーション WAFL トラフィックが存在する場合でも、転送エンジンがバックオフすることです。これは、ノードで大量のスキャナアクティビティが発生している場合に特に当てはまります。これにより、 SnapMirror とボリューム移動の両方のスループットが低下することがあります。

注: BRE スロットリングは CPU レイヤでのみ測定し、ディスクレイヤでは測定しません。ソースアグリゲートまたはデスティネーションアグリゲートがビジー状態の場合、パフォーマンスが低下します。ピーク時以外の利用率またはクライアントの遅延が原因でない可能性がある場合は、転送を実行することを推奨します。

同時転送数:

達成される総スループットは、同時転送の数によって異なります。転送エンジンの場合、 Data ONTAP 8.2 では、 FAS6280 (大容量ファイル)での単一転送のスループットは 546 MB/ 秒です。これは、 8 つの同時転送で約 926 MB/ 秒になります。逆に、 8 つの SnapMirror 転送(またはボリュームの移動)を同時に開始すると、それぞれが最大 118 MB/ 秒のスループットを達成します。したがって、アグリゲートのスループットが高い場合でも、大量の転送を同時に開始すると、個々の転送のスループットは、一度に 1 回の転送を実行するよりも低くなります。

SnapMirror は、ボリュームの移動と同様に、転送エンジンのもう 1 つのクライアントです。同じノード上で SnapMirror とともにボリュームを移動すると、個々の転送速度が低下することがあります。また、ボリュームの移動と SnapMirror で同じアグリゲート上のボリュームを使用している場合は、この影響が顕著になります。劣化は上記のようなものになります。

転送のフェーズ / タイプ:

SnapMirror には、初期化と更新の 2 つのフェーズがあります。同様に、ボリューム移動はベースライン転送を実行し、その後に複数のアップデート転送を実行します。通常、ベースライン転送の転送速度は更新転送よりも高くなります。たとえば、 FAS6280 では、 1 つのストリームベースライン転送で 546 MB/ 秒の転送レートを達成できますが、アップデート転送では 275 MB/ 秒の転送レートを達成できます。そのため、ベースライン転送が完了したあとで、ボリューム移動のスループットが低下するのは正常です(予想されています)。

システム構成

システム構成は、ボリュームの移動によって達成されるスループットに大きな影響を与える可能性があります。考慮すべき要素は次のとおりです。

  • アグリゲート内のディスク数:アグリゲートに十分なディスクがない場合、そのアグリゲートへの読み取りおよび書き込みアクセスが遅くなります。(アグリゲートへの推奨ディスク数に関するドキュメントはありますか。)
  • 同じアグリゲート上に大量のボリュームがあると、特定のボリュームへのアクセスが遅くなることがあります。この問題は、特定のボリュームが高い変更率を認識していなくても、同じアグリゲート内の他のボリュームが認識されている場合にも発生することがあります。
  • アグリゲート内のディスクに障害が発生すると、アグリゲート全体へのアクセスが遅くなる可能性があります。
  • SATA ディスクの応答時間は SAS ディスクの応答時間よりも長くなります。場合によっては、 SATA ディスクの応答時間が SAS ディスクの応答時間の 2 倍になることがあります。これは、ボリューム移動のパフォーマンスに大きな影響を与える可能性があります。
  • ノード上のクライアントトラフィックは、問題のボリュームに転送されていなくても、転送エンジンがオフに戻ることがあります。これは、内部バックオフアルゴリズムが(ノード上にファイルシステムが 1 つしかないため)ノードレベルで統計情報を監視し、ボリュームレベルやアグリゲートレベルでは監視しないためです。
  • 古くなったファイルシステムや断片化されたファイルシステムでは、ファイルシステムからの読み取りや書き込みにかかる時間が長くなることがあります。これは、読み取りチェーンの長さと書き込みチェーンの長さを調べることで、統計から確認できます。断片化されたファイルシステムでは、通常、読み取りと書き込みのチェーンの長さが短くなります。
  • WAN と LAN の比較WAN 経由でデータをレプリケートする場合、 LAN 経由でデータをレプリケートする場合と比べてスループットが低下することがあります。その理由の一部は、ラウンドトリップ遅延が長くなり、パケット損失率が高くなり、 WAN で使用可能な帯域幅が減少することです。たとえば、 Data ONTAP 8.2 で、 8 つの同時 SnapMirror 初期化転送を実行している場合、 FAS6280 では、往復遅延が 50 ミリ秒の OC-12 リンク( 622 Mbps )を介して、合計で 73 Mbps のスループットが達成されます。LAN 上の対応するスループットは 926 Mbps です。

パフォーマンスラボで得られた結果は、 SAS ディスクを使用して「理想的な」状況で得られます。このセットアップにはディスクのボトルネックはありません。クライアントトラフィックの影響を具体的に測定するテスト以外に、パフォーマンスの実行時にノード上にクライアントトラフィックが存在しません。そのため、特定のセットアップのパフォーマンスが、ラボで見たスループットと一致しない場合があります。

BRE パフォーマンスの向上:

特に、 TE のパフォーマンスを向上させる方法については、次のセクションで説明します。

  • クライアントの負荷が低く、内部スキャナのトラフィックが少ない時間帯に転送をスケジュールします。これにより、 TE の内部バックオフメカニズムがアクティブになりません。ただし、必要な RPO を考慮する必要があります。
  • システムのサイズを正しく設定します。CPU ワークロードを実行するために十分な CPU ヘッドルームが必要です(理想的には 50% の CPU ヘッドルーム)。また、プラットフォームがサポートできる最大スループットも考慮してください。変更率と、レプリケーションが機能するまでの時間は、この時間より短くする必要があります。「システム構成」の項で説明したように、システムを適切に構成して、可能な最大スループットを実現する必要があります。セットアップの詳細について[1]は、『 SnapMirror Configuration and Best Practices Guide for Clustered Data ONTAP 8.2 』を参照してください。
  • ファイルシステムが古いか断片化されている場合は、デフラグを実行します。

    :これにより、スキャナトラフィックが増加し、実際にはスキャナの実行中に TE スループットが低下する可能性があります。

    Kahuna の使用率が高くなったり、 TE がバックオフになったりしている場合は、スキャナの速度を下げます。
    注意:これは、 NGS の監督下で、特定の問題を軽減するための一時的な措置としてのみ実行する必要があります。
  • 転送エンジンのパフォーマンスを向上させるもう 1 つの方法は、クライアントのスループットを制限することです。たとえば、クライアントのスループットが原因でレプリケーションが過度にオフになっている場合に、重要なレプリケーションワークロードに対して実行できます。クライアントのスループットを制限する手順については、『 clustered Data ONTAP 8.2 System Administration Guide for Cluster Administrators 』の「 Anaging System Performance Using Storage QoS 」の項を参照してください。

  • レプリケーショントラフィックが WAN を経由する場合は、これらの SnapMirror ポリシーに対してネットワーク圧縮を有効にできます。ネットワーク圧縮は、ネットワークがボトルネックになっているときにスループットを向上させるのに役立ちます。この機能は、 Data ONTAP 8.3 以降で使用できるようになる予定です。

データの収集とデバッグ:

volmove slowness の問題の根本原因を特定するには、システムから perfstat データを取得します。perfstat は、外部ソースから次の形式で実行できます。

 perfstat8 --verbose --time 5 --nodes=<node names> 

これにより統計情報が収集され、ローカルファイルに保存されます。perfstat --help詳細については、コマンドを実行してください。

perfstat の statit セクションには、次の情報が含まれています。

  • CPU 使用率と Kahuna CPU 使用率。
  • ディスク使用率、ディスク応答時間、およびディスクの読み取りと書き込みのチェーン長。

「 Stopwatch counters 」セクションには、転送エンジンのパフォーマンスに関する次のヒストグラムが含まれています。

  • writer_throttled:ライターがスロットルされた回数と、その時間。
  • physdiff_throttled:送信者がスロットルされた回数、およびその期間。これは、転送エンジン内の Z バックオフです。ネットワークスロットルは含まれません。
  • buffer_read_wait_token:送信者が physdiff トークンを待ってから WAFL に読み取りメッセージを送信できるまでの時間。
  • buffer_wafl_read_blocks:送信側で一連のブロック(プラットフォームによって 16 または 32 )を読み取るのにかかる時間。

repl_counters 統計コマンドを確認して、調整されているトークンの割合を特定してください。

perfstat のデータとカウンタは、システムが正常に動作しているか(速度が遅い)、システムに他の問題があるかを示します。

関連するカウンタの一部を任意の時点statistics showで取得するには、次のコマンドを実行します。

statistics show -object repl_stopwatches -instance *throttled -raw
statistics show -object repl_stopwatches -instance buffer_read_wait_tokens -raw
statistics show -object repl_stopwatches -instance writer_data_waiting -raw
statistics show -object repl_stopwatches -instance buffer_wafl_read_blocks -raw

これらのカウンタは、システムがスロットルされている場合はそれぞれ、ソース上の読み取りトークンのヒストグラム、デスティネーション上の書き込みトークンのヒストグラム、ソース上のコンテナファイルの読み取り遅延のヒストグラムを示します。