Hitachi

高信頼化システム監視機能 HAモニタ パブリッククラウド編


4.2.1 業務ディスクの管理

マニュアル高信頼化システム監視機能 HAモニタ Linux(R)(x86)編の「共有ディスクの管理」を参照してください。

AWS環境下およびAzure環境下では,業務ディスクをレプリケーションする構成の場合,加えて次の制御も実施します。

〈この項の構成〉

(1) 基本的な制御

HAモニタは,OSのコマンドによってボリュームグループ単位で接続・切り離しをします。HAモニタがボリュームグループに接続することで,レプリケーションソフトによって業務ディスクがプライマリに昇格します。HAモニタがボリュームグループを切り離すことで,レプリケーションソフトによって業務ディスクがセカンダリに降格します。

(2) レプリケーションパス障害時の制御

系切り替えができる状態でレプリケーションパスが障害になった場合,セカンダリ側(待機系)の業務ディスクが更新できなくなります。また,待機サーバを起動したときにレプリケーションパスが障害だった場合も,セカンダリ側(待機系)の業務ディスクは更新されません。セカンダリ側(待機系)の業務ディスクが更新されていない状態だと,実行系に障害が発生し,系切り替えをしたときに,古いデータを参照した状態で業務を続行することになります。

これを防止するため,HAモニタで次の作業を実施します。

マルチスタンバイ機能を使用しない場合

セカンダリ側のHAモニタで次のコマンドを実行して,セカンダリ側の業務ディスクがプライマリに昇格することを抑止します。

drbdsetup outdate /dev/drbdX

drbdsetupコマンドの実行によって,レプリケーションパスの障害時に系切り替えをした場合でも,セカンダリ側の業務ディスクがプライマリに昇格できないため,古いデータを参照して業務を続行することを防止できます。セカンダリ側の業務ディスクがプライマリに昇格するのを抑止したあと,プライマリ側でI/Oを継続します。

レプリケーションパス障害時の制御の流れについて,次の図に示します。

図4‒1 レプリケーションパス障害時の制御の流れ

[図データ]

プライマリ昇格抑止に失敗した場合は,メッセージKAMN771-Eを出力し,待機サーバを停止させます。プライマリ昇格抑止をしたあとに,レプリケーションパスが回復した場合には,レプリケーションソフトによって再同期が実施され,プライマリ昇格抑止が自動的に解除されます。なお,再同期中に系障害による系切り替えが発生した場合,セカンダリ側は業務ディスクステータスが最新になっていないため,プライマリ昇格はできず,古いデータを参照して業務を継続することはありません。

レプリケーションパスと監視パスが同時に障害になった場合,待機系に連絡できずプライマリ昇格抑止設定ができません。そのため,実行系が待機系をリセットして,その後の系切り替えが発生しないようにします。ただし,リセット優先系の設定などによって実行系がリセットされて系切り替えをする場合もあります。DRBD用のシェルスクリプト群を展開している場合は,standbyresetオペランドの指定に関係なく待機系がリセットされます。詳細は,マニュアル高信頼化システム監視機能 HAモニタ Linux(R)(x86)編の「両系が障害を同時に検出した場合の系切り替え」を参照してください。

マルチスタンバイ機能を使用する場合

レプリケーションパスが切断したセカンダリの系で,メッセージKAMN771-Eを出力して待機サーバを停止します。レプリケーションパスを回復させたあと,待機サーバを再起動してください。

レプリケーションパスと監視パスが同時に障害になった場合は,リセット優先度に従って動作します。詳細は,マニュアル高信頼化システム監視機能 HAモニタ Linux(R)(x86)編の「複数の待機系がある場合の系のリセット」を参照してください。実行系がリセットされた場合は,系切り替えをします。レプリケーションパスが切断したセカンダリの系がリセットされた場合は,リセットされた系以外で業務を継続します。