gmlinktolerance 機能は、svctask chcluster CLI コマンドまたは SAN ボリューム・コントローラー・コンソールを使用して設定できます。
gmlinktolerance 機能は、1 次 SAN ボリューム・コントローラー・クラスターが、2 次クラスターからの低速応答時間を許容する秒数を表します。
低速応答が指定された許容度を超えると、1920 エラーがログに記録され、1 つ以上のグローバル・ミラー関係が自動的に停止されます。
これにより、1 次サイトでのアプリケーション・ホストを保護します。
通常操作の間は、グローバル・ミラー機能が非同期複製を使用しているため、アプリケーション・ホストへの応答時間に生じる影響は最小です。
しかし、グローバル・ミラー操作に対して、2 次クラスターからの応答時間の悪化が長時間生じると、入出力操作は 1 次クラスターのキューに入れられるようになります。
この結果、アプリケーション・ホストへの応答時間が長くなります。
この状態で、gmlinktolerance 機能はグローバル・ミラー関係を停止し、アプリケーション・ホストの応答時間は正常に戻ります。
1920 エラーが発生した後は、エラーの原因を修正し、グローバル・ミラー関係を再開するまでは、グローバル・ミラーの補助 VDisk は整合同期化済み (consistent_synchronized) 状態ではなくなります。
このため、クラスターをモニターして、この状態が発生していないかどうか必ず追跡してください。
gmlinktolerance 機能は、gmlinktolerance 値を 0 (ゼロ) に設定して使用不可にできます。
しかし、gmlinktolerance を使用不可にすると、アプリケーションに対する応答時間の増大を防ぐことができません。
以下の環境では、gmlinktolerance 機能を使用不可にするのが適切な場合があります。
- SAN コンポーネントからのパフォーマンスの低下が予想される SAN 保守ウィンドウの間、アプリケーション・ホストに対するグローバル・ミラー VDisk からの応答時間が長くなっても許容される場合。
- アプリケーション・ホストへの応答時間が長くなっても許容される期間に、gmlinktolerance 機能によってグローバル・ミラー関係が停止することが予想されるとき。
例えば、バックエンド・ストレージに負荷をかけるように構成された入出力生成プログラムの使用をテストしている場合は、gmlinktolerance 機能が長い待ち時間を検出して、グローバル・ミラー関係を停止することもあります。
テスト・ホストへの応答時間が長くなっても構わない場合には、gmlinktolerance を使用不可にすれば、グローバル・ミラー関係の停止を防ぐことができます。
1920 エラーの診断および修正
1920 エラーは、1 つ以上の SAN コンポーネントが、アプリケーション・ホストが必要とするパフォーマンスを提供できないことを示しています。
これは、一時的な場合もあれば (例えば、保守アクティビティーの結果)、永続的な場合もあります (例えば、ハードウェア障害または予期しないホスト入出力のワークロードの結果)。
1920 エラーが発生する場合は、SAN パフォーマンス分析ツール (IBM® Tivoli® Storage Productivity Center など) をセットアップし、そのツールが正しく構成され、問題発生時に統計をモニターすることを確認してください。SAN パフォーマンス分析ツールを、使用可能な最小の統計収集間隔に設定します。
IBM Tivoli Storage Productivity Center の場合、最小間隔は 5 分です。
発生した 1920 エラーが複数の場合は、一番古いエラーの原因を最初に診断します。
以下の質問は、エラーの原因の判別に役立ちます。
- エラーのとき、保守を行っていましたか。
これには、ストレージ・コントローラーの物理ディスクの取り替え、ストレージ・コントローラーのファームウェアのアップグレード、
または、いずれかの SAN ボリューム・コントローラー・クラスターでのコードのアップグレードが含まれることがあります。
保守手順の完了まで待ってから、グローバル・ミラー関係を再開する必要があります。
システムがまだ満足できるパフォーマンスの安定状態に戻っていないため、保守手順の完了まで待って、以後の 1920 エラーを回避する必要があります。
- ソース・システムかターゲット・システムのどちらかに、未修正エラーがありましたか。ある場合、それらのエラーを分析して、1920 エラーの原因であった可能性について調べてください。特に、関係で使用されている VDisk または MDisk に関連しているかどうか、またはターゲット・システムのパフォーマンス低下の原因であったかどうかを調べてください。グローバル・ミラー関係を再開する前に、このエラーを必ず修正してください。
- 長距離リンクが過負荷ですか。
リンクが、短期間ピークのグローバル・ミラー・ワークロードに耐えられない場合は、1920 エラーが発生する可能性があります。
以下の確認を行って、長距離リンクが過負荷かどうかを判別します。
- グローバル・ミラー関係の停止までの、グローバル・ミラー補助 VDisk の書き込みスループットの合計を調べます。
これがリンク帯域幅にほぼ等しい場合は、リンクが過負荷である可能性があります。
これは、アプリケーション・ホストの入出力操作、またはホスト入出力およびバックグラウンド (同期) コピー・アクティビティーの組み合わせが原因であることがあります。
- グローバル・ミラー関係の停止までの、グローバル・ミラー・ソース VDisk の書き込みスループットの合計を調べます。
これは、アプリケーション・ホストによって行われている入出力操作を表しています。
これらの操作がリンク帯域幅に近づいている場合は、
リンクの帯域幅をアップグレードするか、アプリケーションが実行しようとしている入出力操作を減らすか、
またはグローバル・ミラーを使用してコピーする VDisk を減らします。
補助ディスクに対する入出力操作がソース VDisk より著しく多い場合は、高水準のバックグラウンド・コピーが行われています。
グローバル・ミラー協力関係のバックグラウンド・コピー速度パラメーターを減らし、
合計アプリケーション入出力帯域幅およびバックグラウンド・コピー速度をリンクの能力範囲内にします。
- グローバル・ミラー関係の停止後の、合計グローバル・ミラー・ソース VDisk の書き込みスループットを調べます。
関係が停止したときに書き込みスループットが 30% 以上増加する場合は、アプリケーション・ホストは、リンクの能力を超える入出力操作を行おうとしています。
グローバル・ミラー関係がアクティブの際は、過負荷リンクによって、アプリケーション・ホストへの応答時間が増えることになり、それによって、達成できるスループットは減らされます。
グローバル・ミラー関係の停止後、アプリケーション・ホストに対する応答時間が減少します。
この場合は、リンク帯域幅を増加させるか、アプリケーション・ホストの入出力速度を減少させるか、あるいはグローバル・ミラーを使用してコピーされる VDisk を少なくする必要があります。
- 2 次クラスターのストレージ・コントローラーは過負荷ですか。
ストレージ・コントローラー上の 1 つ以上の MDisk が SAN ボリューム・コントローラー・クラスターに提供するサービスが低速の場合は、そのためにアプリケーション入出力操作がアプリケーション・ホストの必要とする速度で進行できなければ、1920 エラーが発生します。
バックエンド・ストレージ・コントローラーの要件が守られていた場合は、コントローラー・パフォーマンスの低下が、エラーの原因であった可能性があります。
IBM Tivoli Storage Productivity Centerを使用して、2 次クラスターの MDisk ごとに、バックエンドの書き込み応答時間を取得します。
個々の MDisk の応答時間が 50 ms 以上の突然の増加を示しているか、応答時間が 100 ms を超えている場合は、問題を示しています。
以下の確認を行って、ストレージ・コントローラーが過負荷かどうかを判別します。
- ストレージ・コントローラーを確認して、メディア・エラー、物理ディスクの障害などのエラー条件、または RAID アレイ再ビルドのような関連アクティビティーを調べます。
エラーがある場合は、問題を修正してから、グローバル・ミラー関係を再開します。
- エラーがない場合は、必要レベルのアプリケーション・ホストの入出力操作を 2 次コントローラーが処理できるか否かを判別します。
RAID アレイへの物理ディスクの追加、アレイの RAID レベルの変更、コントローラーのキャッシュ設定値の変更とキャッシュ・バッテリーが確実に作動可能であることの確認、
あるいはその他のコントローラー固有の構成パラメーターの変更によって、コントローラーのパフォーマンスを改善することが可能な場合があります。
- 1 次クラスターのストレージ・コントローラーは過負荷ですか。
2 次バックエンド・ストレージの場合と同じステップを使用して、1 次バックエンド・ストレージのパフォーマンスを分析します。
パフォーマンスが悪い場合は、アプリケーション・ホストが行える入出力操作の量を制限します。
グローバル・ミラー関係が影響を受けていない場合でも、1 次サイトでのバックエンド・ストレージをモニターします。
悪いパフォーマンスが長く続く場合は、1920 エラーが発生し、グローバル・ミラー関係は停止します。
- いずれかの SAN ボリューム・コントローラー・クラスターが過負荷ですか。
IBM Tivoli Storage Productivity Centerを使用して、ポートからローカル・ノードへの送信応答時間と、ポートからローカル・ノードへの送信キュー時間を取得します。
いずれかのクラスターのこれらの 2 つの統計の合計が 1 ミリ秒を上回っている場合は、SAN ボリューム・コントローラーに極めて高い入出力の負荷がかかっています。
SAN ボリューム・コントローラー・ノードの CPU 使用状況も確認します。
この数値が 50% を上回っている場合も、問題の原因となっている可能性があります。
いずれの場合も、IBM サービス担当員に連絡をとって、支援を依頼します。
1 つのノードの CPU 使用状況が、同じ入出力グループ内のほかのノードに比べてはるかに高い場合は、同じ入出力グループ内に異なるタイプのノード・ハードウェアが混在していることが原因となっていることがあります。
例えば、SAN ボリューム・コントローラー 2145-8G4と同じ入出力グループ内に SAN ボリューム・コントローラー 2145-8F4 が存在する場合です。
このような場合は、IBM サービス担当員に連絡してください。
- 2 次クラスターで、FlashCopy® 操作が準備済み状態ですか。グローバル・ミラーの補助 VDisk が FlashCopy マッピングのソースであり、そのマッピングの準備済み状態の時間が延長されている場合は、キャッシュが使用不可であるためにそれらの VDisk へのパフォーマンスが影響を受ける可能性があります。FlashCopy マッピングを開始して、キャッシュを使用可能にし、グローバル・ミラーの入出力操作のパフォーマンスを改善します。