Hitachi

Cosminexus V11 アプリケーションサーバ 機能解説 運用/監視/連携編


19.3.2 リカバリ処理の流れ

クラスタ構成の実行系と,リカバリ専用サーバである1台の待機系で稼働します。実行系の複数のアプリケーションサーバのうち一つでも障害が発生すると,クラスタソフトウェアで障害を検出し,待機系であるリカバリ専用サーバに切り替えられます。待機系では,ダウンした実行系のアプリケーションサーバのトランザクションを決着します。

リカバリ処理の流れについて次の図に示します。

図19‒2 リカバリ処理の流れ

[図データ]

  1. リカバリ専用サーバのクラスタソフトウェアが障害を検知します。

    実行系のアプリケーションサーバCで障害が発生し,ダウンすると,待機系のリカバリ専用サーバのクラスタソフトウェアはアプリケーションサーバCのダウンを検知します。

  2. リカバリ専用サーバのクラスタソフトウェアで系切り替えを実施します。

    待機系のリカバリ専用サーバに切り替えます。このとき,共有ディスク装置の切り替え,共有ディスク装置のマウント,および仮想ホストのIPアドレスの設定をします。

  3. リカバリ専用サーバをロックします。

    リカバリ専用サーバでは,順次,リカバリ処理を実施します。このため,リカバリ処理を実施する前に,リカバリ専用サーバをロックします。

  4. リカバリ専用サーバのクラスタソフトウェアでリカバリコマンドを実行し,リカバリ専用サーバのアプリケーションサーバをリカバリモードで起動します。

  5. ダウンしたアプリケーションサーバCで仕掛かり中だったトランザクションのリカバリ処理を,リカバリ専用サーバで実施します。

    リカバリ専用サーバでは,トランザクションのリカバリ処理だけが実施されます。リカバリ処理終了後,リカバリ専用サーバのアプリケーションサーバは終了します。

  6. リカバリ専用サーバのロックを解除します。

  7. リカバリ専用サーバのクラスタソフトウェアでアプリケーションサーバ終了後の処理を実施します。

    共有ディスク装置の切り替え,共有ディスク装置のアンマウント,および仮想ホストのIPアドレスの削除をします。

ほかの実行系のアプリケーションサーバに障害が発生している場合は,リカバリ処理をします。なお,実行系のアプリケーションサーバAおよびBについては,アプリケーションサーバCのダウンの影響を受けず,アプリケーション処理を実行します。

注意事項
  • 複数の実行系で障害が発生し,アプリケーションサーバがダウンした場合は,リカバリ専用サーバ(待機系)では,排他で順次リカバリ処理をします。

  • リカバリ専用サーバでのリカバリ処理中は,リカバリ専用サーバのサービスポートが閉塞されるため,処理の受け付けはされません。

  • リカバリ専用サーバでは,リカバリ処理が終了しない場合に備えて,タイムアウト監視が実施されます。

  • データベースのダウンによってタイムアウトした場合は,手動でリカバリ処理をしてください。詳細については,マニュアル「アプリケーションサーバ 機能解説 保守/移行編」の「2.5.8 N:1リカバリシステムでトラブルが発生した場合」を参照してください。

  • リカバリ専用サーバがダウンした場合などの二重障害については,対応していません。