業務運用中に障害など不測の事態が発生し、アプリケーションサーバがシステムダウンを起こした場合、サーバが復旧するまで業務を再開することができないため、長時間、業務が停止してしまいます。
また、非同期アプリケーション連携実行基盤では、メッセージの格納域としてキューを使用していますが、このキューはイベントサービス、およびノーティフィケーションサービスが提供しているイベントチャネルを利用しています。業務運用中に障害など不測の事態が発生し、イベントサービスおよびノーティフィケーションサービスが動作するアプリケーションサーバがシステムダウンを起こしてイベントチャネルが使用できなくなると、イベントチャネルに関連する業務も停止してしまいます。
このような場合に備えて、クラスタ形態の1つである1:1運用待機モデルでクラスタ構成の環境を設計しておくことで、業務が停止する時間を短く抑えることができ、業務に対する影響を最小限に留めることができます。
クラスタ形態の1:1運用待機モデルは、運用サーバ1台に対して、1台の待機サーバを用意し、運用サーバにトラブルが発生した場合に待機サーバへ切り替えて業務を続行します。
以下に、使用クラスタシステムにPRIMECLUSTERの1:1運用待機、データベースシステムを組み合わせた場合の例を示します。
データベース資源を共用ディスクに設定することにより、切り替え時にデータの引継ぎを行います。Interstageのネーミングサービス、インタフェースリポジトリはローカルディスクに設定します。
ポイント
非同期アプリケーション連携実行基盤の場合は、不揮発のイベントチャネルも共用ディスクに設定します。
1:1運用待機の構成図
アプリケーション連携実行基盤に関連するサーバは、すべてクラスタ化することが可能です。一方で、常時運用の必要性が低いものについては、クラスタ化せずにコストを抑えることも可能です。
以下に、アプリケーション連携実行基盤の観点から、クラスタ化の優先度が高いものを順に示します。業務の観点では、この優先順位は変わる可能性もあります。業務での要件に応じて、どのサーバをクラスタ化するかを決定してください。
イベントチャネルを運用するサーバ（非同期アプリケーション連携実行基盤の場合）
サーバアプリケーションを運用するサーバ
業務処理開始アプリケーションまたはクライアントアプリケーションを運用するサーバ
業務用データベースを運用するサーバ
フロー定義DBを運用するサーバ（非同期アプリケーション連携実行基盤の場合）
メッセージトラッキングDBを運用するサーバ（非同期アプリケーション連携実行基盤の場合）
ポイント
高信頼性ログサーバ機能をクラスタ構成にする場合の詳細については、“Interstage Business Application Server 運用ガイド（高信頼性ログ編）”を参照してください。
