クラスタ・ソフトは基本的にハードウエア障害への対処策と考えるべきだが，アプリケーションやミドルウエアの死活もさまざまな方法で検出できる。監視スクリプトを作り込んでクラスタ・ソフトと連携させれば，アプリケーションなどの稼働状態を多角的に監視できる。
その半面，「何をアプリケーション障害とみなすかが問題になる」（DeNA茂岩氏）。障害原因が複雑なアプリケーション，ミドルウエアに対して，Standbyへの切り替え条件を詳細に設定しようとすると意外に難しい。切り替え条件に漏れが生じるかもしれないし，アプリケーションなどの想定外の動作により判断を誤るかもしれない。
クラスタ・ソフトが自動的に対処できる障害の範囲は，ハードウエア障害と，アプリケーション障害の一部がボーダーライン上になる。クラスタ・ソフトの守備範囲外の障害に対しては，運用でカバーする必要がある。
プロセス監視を切り替えに利用
 図4●クラスタ・ソフトで切り替えに利用する内容 ハートビートを利用するほか，データベースのプロセス死活監視をサーバーの切り替えやプロセスの再起動に利用している [画像のクリックで拡大表示] |
 図5●XML DBの監視から切り替えまでの手順（ムラウチの例） XML DBにアクセスする監視用のURLを用意。そこに定期的にアクセスして稼働状況を監視する。XML DBにアクセスできない状態にもかかわらずStandbyに切り替わらない場合は，状況に応じて手動で切り替える [画像のクリックで拡大表示] |
今回取材した企業では，DBの死活をプロセス監視でチェックし，プロセスがメモリー上になければ自動的にStandbyへ切り替える企業が多い（図4[拡大表示]）。ps（Process Status）コマンドなどを使えば比較的容易に実装できるほか，「プロセスがメモリー上にない＝アプリケーション停止」であるため判断が確実だからである＊4。
アプリケーションの障害時に，クラスタ・ソフトが試みる復旧策は2つある。一つは，Activeサーバー上でアプリケーションの再起動を試みること。もう一つは，サーバーをStandbyに切り替えることだ。
アプリケーションの障害時にサーバーを切り替えるかどうかは，業務要件に依存する。例えば住友林業や楽天証券は，業務アプリケーションの障害ではサーバーを切り替えず，アプリケーションの再起動を試みる。「業務アプリケーションの障害はサーバーのほんの一部での障害」（住友林業情報システム 運用管理部 課長 金児英和氏）という判断である。アプリケーションが再起動しない場合でもサーバーの切り替えはせず，アプリケーションの不具合を修正するなどの対策を講じる。
DB障害については，「同一サーバーで再起動しても再度障害になる恐れがあるのでサーバーを切り替える」（ムラウチ 橋本氏）というユーザーが多い。「RDBMSの再起動に失敗したら，改めてStandby側でRDBMSを起動する必要がある。その分だけDBサーバーのダウンタイムが長引いてしまう」（同氏）。
しきい値設定が難しい応答監視
プロセス死活監視のほか，ミドルウエアやアプリケーションからの応答の有無も，クラスタ・ソフトで監視可能だ。これらを使えば，メモリー上に存在していても応答がない「中途半端な状態で停止しているプロセス」を検出できる。例えば，RDBMSのプロセスは稼働しているが，SQL文への応答が返らないような状況を指す。
ただし，アプリケーションやミドルウエアからの応答が途絶えたことを理由にサーバーを切り替える場合，十分な注意が必要である。「タイムアウトのしきい値を長くすれば障害検出が遅れ，短いと誤検知につながる」（シーエーシー 鹿谷氏）からだ。
応答が返らないという状況は，アプリケーションが本当にダウンしている場合以外にも起こる。Webサイトに想定外のアクセスが集中した場合や負荷の高い処理の実行中にサーバーが過負荷状態になった場合である。さらに，「ActiveとStandbyの間でのクラスタ・ソフトによる状態監視が阻害されれば，どのような局面でも誤検知は起こり得る」（NTTデータ ビジネス開発事業本部 システム方式技術ビジネスユニット 第二システム方式技術担当 シニアエキスパート 持田直穂氏）。
手動で切り替える判断基準を決める
このため，「何秒間応答がなければ無条件に障害とみなす」という機械的な判別が困難な場合には，サーバーの切り替えをクラスタ・ソフトに任せるべきではない。結局のところ，「障害の都度，目で見てStandbyに切り替えるべきかどうかを判断する」（DeNA 茂岩氏）というのが現実解になる。
その際，「切り替えるべきかどうかの判断基準」「切り替える際の作業手順」という2つの要素が明確でなければならない。
まず，運用担当者がStandby機に切り替えてよいのかどうか，判断に迷わないよう，「何を障害とみなすかは事前に決めておくべき」（シーエーシー 鹿谷氏）である。
例えばDeNAでは，Standbyに切り替える際の判断基準を以下のように決めている。まず，ハードウエアの障害なのか，共有リソース，DBソフトの問題なのかをログから判定する。その結果，「ハードウエア障害ならば単純にStandbyに切り替える。DBソフトに障害が起こった場合は，障害の内容次第で切り替えるかどうかを判断する。Standbyに切り替えても，問題が再発することがあるからだ。例えば，ディスク上のデータが破損するなどの障害ならば，バックアップからデータを復旧する対策に当たる」（茂岩氏）。
ムラウチでは，図5[拡大表示]のような判断基準を用意した。XML DBの稼働状況を細かく調べ，動作異常が障害によるものか過負荷によるものかを判別している。過負荷でないことが判明すれば，手動でStandbyに切り替える。
手順を決めて2次災害を防ぐ
次に，うまく切り替わらないときの切り替え手順を明確にしておく。このような万一の状況下では，運用担当者のあせりによるオペレーション・ミスによって「2次災害につながることがある」とNEC IT基盤システム開発事業部（IT基盤方式技術センター）コンサルティングマネージャーの松友進一郎氏は語る。
ムラウチの運用手順は次のように決められている。まず(1)Activeが動いている状態ならば，クラスタ・ソフトに切り替えコマンドを入力する。(2)それで切り替わらなければActiveをシャットダウンする（最悪の場合，電源を切断）。(3)Standbyのクラスタ・ソフトからXML DBソフトを起動。(4)それでも切り替わらなければ，Standbyを再起動し，クラスタ・ソフトを外してXML DBソフトを起動する――。
DeNAも同様で，「ハード障害で切り替わらない場合はActiveサーバーを止める。DB障害の場合はOracleをシャットダウンし，クラスタ・ソフトの切り替えコマンドでStandbyに切り替える」（茂岩氏）。
クラスタ・ソフトを外す手順も用意
クラスタ・ソフト自体に異常が起こる可能性もあるので，クラスタ・ソフトを切り離してStandbyを起動する運用手順も準備する必要がある。
クラスタ・ソフトは，アプリケーションを監視下に置くために，クラスタ・ソフトからアプリケーションを起動する仕組みになっている。サーバーを手動で切り替える場合，「よほどのことがない限り，Standby側のクラスタ・ソフトからアプリケーションを起動できる」（DeNA 茂岩氏）。
ただし，「よほどのこと」が起きてしまったら，「クラスタ・ソフトを外して，Standbyを立ち上げる場合がある」（NTTデータ 持田氏）。クラスタ・ソフトの外し方はクラスタ・ソフトによって異なるため，あらかじめ確認しておきたい。例えばSun Clusterでは，OSのブート時に特定のパラメータを付加して起動しないとクラスタ・ソフトが動き始める。
なお，切り替えが必要かどうかの判断作業や切り替え作業の手順は，できる限り定期的に“練習”しておくべきだ。「避難訓練と同じで，何年もやらないと手順を忘れてしまう」（DeNA 茂岩氏）。
