クラスタ導入の注意点
クラスタシステムは、大変複雑なシステムです。クラスタシステムを構築するには、クラスタソフトウェアだけでなく、上位のアプリケーションソフトやミドルウェアのソフトウェアの設定方法も熟知している必要があります。技術的な難易度が非常に高いのです。また、どのようなシステムを作るのかという設計の部分も非常に重要です。クラスタソフトウェアは、設計者が予期していない問題までカバーしてくれる訳ではないからです。
ここでは、クラスタ構築を行う場合の注意点について解説します。
クラスタの基本知識を知りたい！という方へ
単一障害点(Single Point of Failure)
クラスタシステムを設計する時に確認しておくべきことは、単一障害点(Single Point of Failure)を作らないようにすることです。
この図は、一般的なWEB-DB構成のサーバを二重化した例です。WWWサーバも、DBサーバも、二重化されています。しかし、よく見ると、Switchや共有ディスクは二重化されていません。そのため、Switchや共有ディスクが故障した場合には、システム全体が止まってしまいます。
このように、故障するとシステムが停止してしまう箇所のことを、単一障害点と呼びます。クラスタシステムを構成する場合には、このような単一障害点を作らないように設計する必要があります。
関連情報
クラスタ監視項目
クラスタシステムは、クラスタ用のソフトウェアをインストールしさえすれば、有効に動作する訳ではありません。障害が発生した場合には、その障害を検知し、システムを切り替えるという動作を自分で設定する必要があるからです。
例えば、ネットワークのインタフェースが壊れたら、通信ができなくなります。これを検知しようと思ったら、どこかと通信ができることを常に監視しておく必要があります。
そのため、クラスタシステムの設計時に、発生する可能性がある問題をリストアップしておく必要があります。そして、それを検知するための仕組みを導入するのです。この考慮が足りないと、どんなに高いハードウェアを使っても、実際に問題が発生した時に切り替わらない可能性があります。
「設計時に考慮していた問題にしか対応できない」ということを、肝に命じておく必要があるのです。
IPアドレスのフェールオーバー
アクティブ・スタンバイ型のクラスタシステムは、2台のコンピュータで動作します。通常は、アクティブサーバと呼ばれる稼働系のシステムでサービスを提供し、障害が発生した場合には、スタンバイサーバと呼ばれる待機系のシステムに処理を切り替えます。
一般的に、サーバの切り替えは、サービス用のIPアドレスの切り替えで行います。
このIPアドレスの切り替え方法には、VRRP、Gratutious ARPなど、いくつかの種類があります。しかし、どの切り替え方法を使った場合でも、IPアドレスを切り替えるためには、待機系サーバと稼働系サーバが同一のネットワークに所属している必要があります。ネットワーク機器の設定や配置の方法により適切に切り替わらない場合があるため、注意が必要です。
スプリットブレイン
アクティブ・スタンバイ型のクラスタで、2台のサーバの間の調整が上手くいかず、2台ともが自分が稼働系のサーバだとして動作してしまう現象を、スプリットブレインと呼びます。
スプリットブレインの状態になると、様々な致命的な問題が引き起こされます。まず、2つのサーバが同じIPアドレスを名乗ります。そのため、相手によって違うサーバに接続する可能性があります。ファイルサーバ、データベースサーバ、メールサーバなど、データを蓄積するサーバの場合には、2つのサーバが管理しているデータに差ができてしまいます。復旧する時にも、どちらの変更を有効にするのか、難しい判断をしなければならなくなります。
共有ハードディスクを使っている場合には、さらに深刻です。2つのサーバがディスクをマウントしてしまうと、ファイルシステムが破壊され、二度とデータが読めなくなってしまうかもしれません。その他にも、ログが混乱したり、データベース上のデータが不整合を起こしたりと、非常に深刻な状況になる可能性があります。
スプリットブレインは、サーバ間の通信不良によって引き起こされる可能性があります。ネットワーク障害だけでなく、配線ミスなどの人為的ミスでも起きます。
スプリットブレインの対策としては、いくつかの方法があります。例えば、STONITHやFenceなどの機能を使って、元の稼働系サーバを強制的にリセットしてからフェールオーバーするなどの仕組みを導入します。また、共有ハードディスクを二重にマウントできないようにする仕組みを導入するということもできます。
スプリットブレインの対策は、ある程度は設計時から見込んでおく必要があります。例えば、通信ラインを多重化したり、運用マニュアルを整備して、人為的ミスを減らしたりということです。
重要なデータを管理するサーバの場合には、どのようにスプリットブレインの対策を行うのか、あらかじめ考えておく必要があるのです。
HAクラスタの限界
クラスタシステムは、決して万能ではありません。過度な期待は禁物です。手間をかけてクラスタシステムを導入したとしても、絶対に大丈夫だとは言いきれないのです。特に次のようなことは念頭に置いておく必要があります。
設計時に予期した問題にしか対処できない
クラスタシステムは、設計時に考慮した機能しか発揮できません。例えば、ハードディスクが完全に停止してしまい、Linuxカーネルが完全に停止してしまったような場合には、障害を検知して切り替わるかもしれません。しかし、ハードディスクが極端に遅くなったり、突然書き込みができなくなったりした場合のことは、通常はあまり考慮されていません。しかし、ハードディスクへの書き込みが遅いことが障害である、とあらかじめ想定できていれば、適切な監視を導入することができます。
このように、設計時に、どのような障害を想定するのかということがとても大切です。また、実際に障害が発生して停止してしまった場合には、原因をきちんと突き止め、それにあった監視を導入することで、クラスタシステムを改善していく必要があります。
人為的ミスは防げない
人的なオペレーションミスをクラスタシステムで防ぐことはできません。むしろ、システムが複雑で、運用上の注意点も多くなるため、人為的なミスは発生し易くなります。ネットワークの構成変更をしていた時に、クラスタシステムをスプリットブレインにしてしまったというようなミスを耳にすることは少なくありません。
運用マニュアルを整備するなど、人為的ミスが発生しにくい環境を作るように、十分に配慮する必要があります。
テストを綿密に行う
クラスタシステムの導入にあたって、設計の次に重要なのがテストです。クラスタシステムは、様々なソフトウェアを組み合わせて作成した、大変複雑なシステムです。想定した障害が実際に発生した場合に、どのような動作になるのかを必ずテストしておきましょう。
きちんと切り替わるのは、あらかじめテストを行った状況が発生した場合だけだと考えるのが適切です。確認もしていないのに、ソフトウェアを設定しただけで上手く動くということを期待すべきではありません。
仮想サーバ上での運用
最近は、クラスタシステムを仮想サーバ上に構築するというケースを見かけるようになりました。もちろん、条件さえ整えば、仮想サーバ上でも高可用性を実現することは十分に可能です。しかし、仮想サーバの場合には、いくつかの注意が必要です。
仮想サーバのマイグレーション機能とは異なる
最近の仮想プラットフォームには、サーバが故障した時に別のサーバにサービスを移動するマイグレーション機能を装備したものも多くなっています。しかし、このマイグレーション機能と、クラスタの機能とは同じではありません。
通常、マイグレーション機能は、OSの動作状況だけを管理しています。そのため、アプリケーションの稼働状況は管理されません。通常のクラスタソフトウェアで実現できる機能の一部分しか実現できていないのです。
リソース不足に注意
クラスタシステムでは、様々な管理や監視のプロセスが動作します。そのため、思ったよりも多くのハードウェアリソースを要求します。仮想システムから割り当てられるリソースが少ないと、監視が失敗したり、ハードウェアモニタが起動してしまったりして、障害と判断されることがあります。
こうした障害は、クラスタシステムとしてはリソース不足を障害と検知している正常な状態です。そのため、クラスタシステムをいくら調べても原因を特定することができません。
クラスタシステムを仮想サーバ上で動作させる場合には、十分なリソースが割り当てられているかを、仮想システム側のモニタ機能などで常に管理する必要があります。
構築業者の選び方
重要なシステムをクラスタ化する場合には、よほど腕に自信がなければ、専門の業者に任せることをお勧めします。
クラスタシステムは、大変複雑なシステムで、注意事項も非常に多く存在します。OS、ネットワーク、ミドルウェアなど、様々な知識も要求されます。また、設計やテストを網羅的に行うことが非常に重要です。実際に運用の経験がある人にしか分からないことも多く存在します。
そのため、クラスタシステムを構築するには、かなりの専門性が必要なのです。
実際に構築する業者を選ぶ場合には、必ずクラスタシステムの構築経験を確認することをお勧めします。また、設計、テスト、運用マニュアルの作成などの工程は必須です。これらの作業が、請負内容に含まれていることを必ず確認しましょう。