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

FAQ : SnapMirror レプリケーションエンジンの BRE/LRSEs のパフォーマンスの問題

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

すべてのとおり  

環境

  • Block Replication Engine ( BRE ;ブロックレプリケーションエンジン)
  • ストレージ効率を維持した状態での論理レプリケーション( LRSE)
  • SnapMirror
  • ボリューム移動

回答

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

SnapMirror やボリューム移動などの Data ONTAP 製品では、 BRE を使用してソースからデスティネーションにデータを転送します。場合によっては、製品が期待どおりに動作していないことがあります。これには、次のようなさまざまな原因が考えられます。

  • 設定の問題
  • クライアントの問題
  • または、転送エンジンを含むソフトウェアモジュールのいずれかのバグ。

この記事では、パフォーマンス低下の原因となる可能性のある要因をいくつか紹介し、優先順位を付けるためのツールを紹介します。この記事では BRE に焦点を当てていますが、ここで説明する多くの要因は LRSE にも当てはまります。

 

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

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

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

注: これらの要素は次の場合に適用されます。

  • SnapMirror とボリューム移動の両方に対応しています
  • ソースとデスティネーションの両方

さらに、 SnapMirror または vol move のパフォーマンスが低いときに、ネットワーク帯域幅が飽和状態にならないのはなぜですか。

これは、 BRE がネットワーク帯域幅のボトルネックにならないためです。ボトルネックは通常、ソースストレージシステムまたはデスティネーションストレージシステムにあります。

:ネットワークがボトルネックで飽和状態になった場合、ユーザは関係に対してネットワーク圧縮を有効にできます。



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

システムの既存の負荷:

BRE の機能

  • BRE はソースアグリゲートからブロックを読み取ります
  • 次に、ネットワーク経由でデスティネーションアグリゲートにデータを送信します
  • 最後に、をデスティネーションアグリゲートに書き込みます。

これには、適切な処理を行うために予備の CPU サイクルが必要です。したがって、システム上の既存の負荷は、 BRE のクライアントの進捗に大きく影響する可能性があります。SnapMirror 転送またはボリューム移動を実行する前に、コントローラの CPU 使用率を 50% 未満に抑えることを推奨します。 

 

Data ONTAP の内部負荷:

クライアントトラフィックに直接関連しない Data ONTAP 内部トラフィックは、 BRE パフォーマンスで原因の低下が発生する可能性もあります。

例:

  • スキャナトラフィック:
    • 内部スキャナトラフィックは、システム負荷および原因 CPU 負荷を生成して増加させることができるため、転送エンジンで使用できる CPU の量を減らすことができます。また、転送エンジンのスロットリングメカニズムが開始され、パフォーマンスがさらに低下する可能性もあります。

 

クライアントの負荷:

SnapMirror とボリュームの移動は、バックグラウンドジョブとみなされます。基盤となる転送エンジンは、クライアントのワークロードが存在する環境でバックオフします。転送エンジンは、ノードスコープの読み取りおよび書き込みトークンプールを維持します。これらのトークンは、転送エンジンによって(すべての転送にわたって) WAFL に送信できる同時メッセージの数を制限します。システムは、 WAFL に送信された 1 秒あたりの処理数と、 WAFL で処理されるまでのメッセージの平均待機時間を追跡します(これは、 TE 自体から送信された処理を除く、 AFL に送信されたすべての処理に適用されます)。これらの 2 つの値が事前定義されたしきい値を超えると、 Transfer Engine は使用可能なトークンの数を減らし、クライアントが使用できるスループットを効率的に削減します( SnapMirror とボリュームの移動の両方)。

例:FAS6280 の clustered Data ONTAP 8.2 です 

同時転送数 クライアント IOPS SnapMirror / ボリューム移動のスループット CPU 利用率: SnapMirror / ボリューム移動転送なし CPU 利用率: SnapMirror/Vol 移動転送
8 -- 1134MB/s -- 50%
8 60 、 000 / 秒  289MB/ 秒 66.5% 75.6%
8 75K/s 206MB/ 秒 75.8% 81.3%
8 120K/s 76MB/s 86.5% 86.5%

メモ

  • システム上のクライアント負荷は、 SnapMirror およびボリューム移動によって達成されるスループットに大きく影響する可能性があります。
  • このスロットリングメカニズムには、内部の非レプリケーション WAFL トラフィックが存在する場合でも、 TE がバックオフになるという側面があります。これは、ノードで大量のスキャナアクティビティが発生している場合に特に当てはまります。これにより、 SnapMirror とボリューム移動の両方のスループットが低下することがあります。
  • BRE スロットリングは CPU レイヤでのみ測定し、ディスクレイヤでは測定しません。ソースアグリゲートまたはデスティネーションアグリゲートがビジー状態の場合、パフォーマンスが低下します。ピーク時以外の利用率またはクライアントの遅延が原因でない可能性がある場合は、転送を実行することを推奨します。

 

同時転送数:

達成される総スループットは、同時転送の数によって異なります。

例:アンロードした FAS6280 の clustered Data ONTAP 8.2 (大容量ファイル)

同時転送数 転送あたりのスループット 総スループット
1 546MB/ 秒 546MB/ 秒
8 118MB / 秒 926MB/s

注:

  • 同時に多数の転送を開始する場合、アグリゲートのスループットが高くても、個々の転送のスループットは一度に 1 回だけ実行する場合よりも低くなります。
  • 同じノード上で SnapMirror とともにボリュームを移動すると、個々の転送速度が低下することがあります。また、ボリュームの移動と SnapMirror で同じアグリゲート上のボリュームを使用している場合は、この影響が顕著になります。

 

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

SnapMirror には 2 つのフェーズがあり、初期化フェーズの転送速度は通常、更新フェーズよりも高くなります。

  • 初期化
  • 更新 

同様に、ボリューム移動はベースライン転送を実行し、その後に複数のアップデート転送を実行します。通常、ベースライン転送の転送速度は更新転送よりも高くなります。例:アンロードした FAS6280 の clustered Data ONTAP

  • 1 つのストリームベースライン転送で 546 MB/s の転送速度を達成できます。
  • 更新転送の転送速度は 275 MB/ 秒ですが

そのため、ベースライン転送が完了したあとで、ボリューム移動のスループットが低下するのは正常です(予想されています)。

 

システム構成

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

  • アグリゲート内のディスク数:アグリゲートに十分なディスクがない場合、そのアグリゲートへの読み取りおよび書き込みアクセスが遅くなります。 
  • 同じアグリゲート上に大量のボリュームがあると、特定のボリュームへのアクセスが遅くなることがあります。この問題は、特定のボリュームが高い変更率を認識していなくても、同じアグリゲート内の他のボリュームが認識されている場合にも発生することがあります。
  • アグリゲート内のディスクに障害が発生すると、アグリゲート全体へのアクセスが遅くなる可能性があります。
  • SATA ディスクの応答時間は SAS ディスクの応答時間よりも長くなります。場合によっては、 SATA ディスクの応答時間が SAS ディスクの応答時間の 2 倍になることがあります。これは、ボリューム移動のパフォーマンスに大きな影響を与える可能性があります。
  • ノード上のクライアントトラフィックは、問題のボリュームに転送されていなくても、転送エンジンがオフに戻ることがあります。これは、内部バックオフアルゴリズムがノードレベルで統計情報を監視するためです。
  • 古くなったファイルシステムや断片化されたファイルシステムでは、ファイルシステムからの読み取りや書き込みにかかる時間が長くなることがあります。statitこれは、 read-chain-length および write-chain-length を調べることで確認できます。断片化されたファイルシステムでは、通常、読み取りと書き込みのチェーンの長さが短くなります。
  • WAN と LAN の比較WAN 経由でデータをレプリケートする場合、 LAN 経由でデータをレプリケートする場合と比べてスループットが低下することがあります。次のような理由が考えられます。
    • 往復遅延時間の延長
    • パケット損失率が高くなります
    • WAN で使用可能な帯域幅の削減。

例:無負荷の FAS6280 上の clustered Data ONTAP 8.2 で、 8 つの SnapMirror 同時初期化転送を使用している場合

  • 8 つの同時転送の合計スループットは、 OC-12 WAN リンク( 622 Mbps )で 73MB/s です。
  • 同時転送の合計スループットは、 LAN で 926MB/s です

注:

  • パフォーマンスラボで得られた結果は、 SAS ディスクを使用して「理想的な」状況で得られます。このセットアップにはディスクのボトルネックはありません。
  • パフォーマンスの実行が完了しても、ノード上にクライアントトラフィックは発生しません。
  • そのため、特定のセットアップのパフォーマンスが、ラボで見たスループットと一致しない場合があります。

 

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

TE のパフォーマンスを改善する方法、特に次の項で説明します。

  • クライアントの負荷が低く、内部スキャナのトラフィックが少ない時間帯に転送をスケジュールします。
    • これにより、 TE の内部バックオフメカニズムがアクティブになりません。ただし、必要な RPO を考慮する必要があります。
  • システムのサイズを正しく設定します。
    • CPU ワークロードを実行するために十分な CPU ヘッドルームが必要です(理想的には 50% の CPU ヘッドルーム)。
    • プラットフォームでサポート可能な最大スループット。
    • 変更率
    • レプリケーションの動作にかかる時間は、この時間より短くする必要があります。
    • 「システム構成」の項で説明したように、システムを適切に構成して、可能な最大スループットを実現する必要があります。セットアップの詳細について[1]は、『 SnapMirror Configuration and Best Practices Guide for Clustered Data ONTAP 8.2 』を参照してください。
  • ファイルシステムが古いか断片化されている場合は、デフラグを実行します。
    :これにより、スキャナトラフィックが増加し、実際にはスキャナの実行中に TE スループットが低下する可能性があります。
  • 転送エンジンのパフォーマンスを向上させるもう 1 つの方法は、クライアントのスループットを制限することです。たとえば、クライアントのスループットが原因でレプリケーションが過度にオフになっている場合に、重要なレプリケーションワークロードに対して実行できます。クライアントのスループットを制限する手順については、『 clustered Data ONTAP 8.2 System Administration Guide for Cluster Administrators 』の「 Anaging System Performance Using Storage QoS 」の項を参照してください。
  • レプリケーショントラフィックが WAN を経由する場合は、これらの SnapMirror ポリシーに対してネットワーク圧縮を有効にできます。ネットワーク圧縮は、ネットワークがボトルネックになっているときにスループットを向上させるのに役立ちます。