サーバクラスタ設計における盲点（１）

＊この記事は著者の経験則に基づく内容であり、一般的に公開されている内容とは異なる可能性があります＊

僕はインフラSEとしてさまざまな機器・ソフトを使って１００台近くのサーバクラスタの設計～構築～運用サポートを行ってきた。

これだけのシステムを数年間運用サポートすると、実に様々な障害に遭遇し、その中にはクラスタが有効に働かないケースも多々発生した。

もともと障害を想定してクラスタ構成を組むわけなので、クラスタが有効に働かないケースというのは、考慮不足による設計の不備である。

ここではその考慮不足を招きやすい事象と対策についてまとめておく。

ここで想定するサーバクラスタとは下図のような一般的なActive-Standby型のサーバクラスタになります。

（ケース１）内蔵RAIDボードの障害

一般的にクラスタを構成する各サーバに内蔵されたディスクにOSとアプリケーションをインストールし、共有ディスクにデータを格納するケースがほとんどだと思う。

このようなケースでActive側の内蔵RAIDボードが壊れてしまう状態を想像してほしい。突然内蔵ディスクに全くアクセスできなくなる状態だ。

実はこの状態、ほとんどのサーバクラスタ環境でフェイルオーバーが発生しない（厳密には対処できるように設定されていない）

各ノードで発生する事象は以下を見てほしい。

■Activeノードで起こる現象

アプリケーションは外部からのリクエストを処理をするために内蔵ディスクのコマンドやライブラリを呼び出したり、OSはログを格納しようと内蔵ディスクにアクセスするタイミングで、この異常を検知することになる。

当然アプリケーションは動かなくなってしてしまう（停止するわけではない）。クラスタも異常を検知して、あらかじめ定義された動作に従いアプリの再起動を試みるが、当然呼び出すべきコマンド群（プロセスの停止や、アプリケーションを停止するコマンド）が入っている内蔵ディスクが参照できないので、何もできなくなってしまう。

最終的に全てのクラスタ配下のリソースを強制解放するコマンドも内蔵ディスクなため、アプリケーションの強制終了すらできなくなってしまい、リソース（仮想IP、プロセス、共有ディスク）を中途半端に保有したままになってしまう。

■Standbyノードで起こる現象

Active側で異常が発生していることは検知できる。しかしStandby側でアプリを強制起動しようにも、Active側では停止不能なアプリが中途半端な状態で動いている。

仮に強制起動をかけて、共有ディスクの所有権を強制的に確保しアプリの起動を試みても、仮想IPをActiveノードが保持しているので、クラスタは依存関係に従いリソースを起動するプロセスで、仮想IPの割り当てがエラーを起こし、アプリケーションを起動することができなくなってしまう。

この状態は非常に危険で、アプリケーションによってはメモリ上だけで一部のデータを処理できてしまう場合がある（しかも共有ディスクへの書き込みは行える）。最終的にはデータ不整合が発生する可能性が高く、復旧に多大な労力を払うことになる（最悪、顧客から賠償という話にも）

この状態は人手のオペレーションがなければ復旧することができないが、普及するのは簡単。Activeノードを電源ボタン長押しで強制OFFし、Standbyノードでクラスタリソースの再起動を実行してやればよい。

この現象は今までで４回経験した。原因はRAIDボードファームのバグ、497日問題によるRAIDボード再起動、RAIDボードの故障、マザーの不具合によるバスエラー。

問題点は２つ

１．内蔵ディスクが参照できなくなるという事態に対して、OSやクラスタソフトが対処できていない。

２．内蔵RAIDボードが単一障害点（SPOF）になっている。

１への対処

このような状態になった時にOSがパニックを起こして停止すればいいので、このような設定をOSかクラスタソフトへ予め行っておく（設定方法は環境によって異なるので、提供元に確認してほしい）

２への対処

最も簡単なのが、SANブート構成にしてしまう事。２つのFCボードからストレージへアクセスするようにすれば簡単に経路を冗長化できる。

もう一つはサーバ内に複数のSCSIボードを取り付け、それぞれのボードにディスクを接続し、この二つをOSからソフトミラーしてやること（昔の商用UNIXマシンはほとんどこの構造になっていた）

１、２どちらかへ対処することで、ほとんど対応できるのでサーバクラスタを行う場合は必ず対処しておこう。

参考
RAID５構成の内蔵ディスクのディスク障害時の動作について

（続く予定）