高可用性とは、システムを現実的な範囲でできる限り継続的に利用できるようにすることを目的とした一つの設計方法論です。システム障害やシステム保守といったダウンタイムの原因を極力排除し、実際に発生してしまったダウンタイムイベントの検出とそこからの回復にかかる時間を最小限に抑えることを意図しています。より高度な可用性を実現するために、具体的には、ダウンタイムイベントの検出とそこからの回復を迅速に行う自動化された処理方法が必要となります。
Sentinelは、さまざまなサービスに依存しながらさまざまなサービスを提供する、複合的な多層アプリケーションです。また、複数の外部サードパーティシステムとも連動して、データ収集、データ共有、およびインシデント修正を行います。たいていの高可用性ソリューションでは高可用性を持たせるサービスとそれに依存するサービスとの間の依存関係を実装者が宣言できますが、それもクラスタ上で実行するサービスに対してのみ可能です。イベントソースなどのSentinel外部のシステムは、組織が必要とする可用性に合わせて別個に構成する必要があり、フェールオーバーなどのためにSentinelが一時的に利用不能になった場合でも状況を適切に処理できるように設定されている必要があります。アクセス権限が厳しく制限されている場合(たとえばサードパーティシステムとSentinelとの間でのデータ送受信に認証済みセッションを使用する場合など)、どのクラスタノードからでもセッションを受け入れ、どのクラスタノードに対してもセッションを開始できるようにサードパーティシステムを設定する必要があります(そのためにはSentinelを仮想IPで設定する必要があります)。NetIQは、弊社製品と管轄対象外サードパーティシステムとの間のいかなるレベルの高可用性についても保証しておりません。
すべての高可用性クラスタには、ノードに障害が起きた場合でもアプリケーションデータを別のノードにすばやく移動できるような、何らかの形式の共有ストレージが必要です。ストレージそのものが高可用性を備えていなければならず、これは通常ファイバチャネルネットワークを使用してクラスタノードに接続するストレージエリアネットワーク(SAN)の技術を採用することによって実現されます。他のシステムはNAS(Network Attached Storage)、iSCSI、または共有ストレージのリモートマウントを可能にするその他のテクノロジを使用します。共有ストレージの最も重要な要件は、クラスタが障害の発生したクラスタノードから新しいクラスタノードへストレージをきちんと移動できるということです。
メモ:iSCSIの場合は、ハードウェアがサポートする最大のメッセージ転送単位(MTU)を使用してください。MTUを大きくすることで、ストレージのパフォーマンスが向上します。ストレージへの接続のレイテンシまたは帯域幅、あるいはその両方が推奨値より遅い場合は、Sentinelで問題が生じる可能性があります。
Sentinelで共有ストレージを利用する場合に、使用可能な2つの基本的な方法があります。ひとつは、アプリケーションバイナリ、設定、イベントデータなどすべてのコンポーネントを共有ストレージに置くという方法です。フェールオーバーになると、ストレージはプライマリノードからアンマウントされてバックアップノードに移動します。これで、共有ストレージから全体のアプリケーションと設定が読み込まれます。もう一つは、イベントデータを共有ストレージに保管し、アプリケーションバイナリと設定は各クラスタノードに配置するという方法です。フェールオーバーになると、イベントデータのみがバックアップノードに移動します。
どちらの方法にも長所と短所がありますが、2番目の方法では、Sentinelインストール環境で標準FHS準拠のインストールパスを使用でき、RPMパッケージの検証、ダウンタイムを最小限にするウォームパッチや再設定を行うことが可能です。
iSCSI共有ストレージを使用し、アプリケーションバイナリと設定を各クラスタノードに配置するクラスタのインストールプロセスを、サンプルとして説明していきます。
高可用性環境の重要な要素は、高可用であるべきリソースとそれに依存するリソースを監視するための、信頼できる安定した方法を確立することです。SLE HAEはリソースエージェントというコンポーネントを使用してそのような監視を実行します。リソースエージェントの役目は、各リソースの状況を知らせ、そのリソースを(要求に応じて)開始および停止することです。
リソースエージェントは監視対象のリソース状況を信頼できる情報として提供して、不要なダウンタイムが発生しないようにする必要があります。誤検出(リソースに障害が発生したと思われたが、実際には自力で回復したという場合など)によって実際には行う必要のないサービスマイグレーション(および関連するダウンタイム)が始まったり、検出漏れ(リソースは機能しているとリソースエージェントが報告したが、そのリソースは実際には正常に動作していないという場合など)によってサービスを適正に利用できなくなったりすることがあります。一方、サービスに対して外部監視を行うことは非常に難しいでしょう。たとえば、Webサービスポートは1つの単純なpingには応答するかもしれませんが、実際のクエリが発行されたときに正しいデータを提供できるとは限りません。多くの場合、本当に正確な測定値を取得するには、サービス自体に自己診断機能を組み込む必要があります。
このソリューションでは、主要なハードウェア、オペレーティングシステム、またはSentinelシステム障害を監視することができる、基本OCFリソースエージェントがSentinelに装備されます。現時点では、Sentinelの外部監視機能はIPポート試験に基づいており、これには読み取りに誤検出や検出漏れの可能性があります。弊社では、このコンポーネントの正確性を改善するために、時間をかけてSentinelおよびリソースエージェントの両方を改良することを計画しています。
HAクラスタ内では、クリティカルサービスを常時監視しており、障害発生時には別のノードでそのサービスが自動的に再起動するようになっています。しかし、この自動化によって問題が生じる可能性もあります。たとえば、プライマリノードで何らかの通信の問題が発生し、そのノード上で実行中のサービスが一見ダウンしているようでも、実際には実行が継続され、データを共有ストレージに書き込んでいるという場合です。このような場合に、バックアップノードで新たにサービスのセットが開始されると、容易にデータ破損が発生しかねません。
そうならないように、クラスタではフェンシングという方法が採用されています。これは、スプリットブレイン検出(SBD)およびSTONITH(Shoot The Other Node In The Head)を含むさまざまな技術の総称です。この主な目的は、共有ストレージにおけるデータ破損を防ぐことにあります。