自動フェイルオーバーの失敗は、「故障検知」の失敗と、「処理の引き継ぎ」の失敗に分けられる。
故障検知では、本番系の故障をいかに検知できるかがポイント。ここでつまづいたのが、2008年9月の新幹線の「自動進路制御装置（PRC）」に関する障害である。
PRCは独自開発のアプリケーションでクラスタリングソフト相当の機能を実装。ハードウエアに故障が発生するとOSのドライバーが検知してサーバーの処理を中断し、この独自開発のアプリケーションがハートビート信号を遮断する仕組みだ。
障害の引き金は本番系サーバーが内蔵するハードディスク（HDD）の異常だ。起動/終了時にだけ発するはずの通知データを出し続ける異常状態になり、HDDへアクセスできなくなったのだ。
ところがOSのドライバーは、HDDの異常を「故障」ではなく「警報」と解釈した。ハートビート信号は送信され続けた。その結果、フェイルオーバー処理は発動されず、システムが利用できない状態に陥った。
JR東日本はシステム障害後、OSのドライバーを修正。同事象を故障と判断するようにした。さらにリモートから本番系を強制的にシャットダウンする機能を追加。他の事象でも、故障時のフェイルオーバーが発動しない場合、強制シャットダウンにより自動フェイルオーバーを実行できるようにした。
タイムアウトで処理中止
故障を検知したのに、切り替え処理で失敗したケースが、2012年2月の東証のシステム障害だ。
株式売買システムである「arrowhead」の中の「情報配信システム」は3台のサーバーで1セット、計8セットで構成する。3台のサーバーは平時は銘柄を分担して株価情報などを配信しているが、1台が故障すると残りの2台が処理を引き継ぐ三重化の仕組みだ（図1）。
障害の引き金は1台のサーバーのメモリーコントローラー故障。クラスタリングソフトは故障を検知し、このサーバーの処理を残りの2台に引き継がせようとした。しかし、引き継ぎ処理は途中で停止してしまった。
arrowheadが搭載するクラスタリングソフトは故障を検知すると、まず故障したサーバーに停止命令を出す。シャットダウンが正常に完了したことを確認し、ハートビート信号は途絶える。ところが、シャットダウンは停止命令から20秒以内に完了しなければならない。それ以上時間がかかった場合はタイムアウトとなり、自動の引き継ぎ処理を中止する。
2月の障害では、故障したサーバーがシャットダウンに20秒以上を要した。オペレーターに確認を促すメッセージを出力したが、オペレーターは自動引き継ぎが成功したと誤認。その結果、フェイルオーバーに失敗したのである。
