クラスタには以下の機能があります。
「障害発生箇所が存在しない」ハードウェア構成
クラスタには、デュアルコントローラRAIDアレイ、マルチネットワーク チャネル、冗長無停電電源装置(UPS)システムを組み込むことができるため、1つの障害によってアプリケーションのダウンタイムが発生したりデータが失われることはありません。
また、「障害発生箇所が存在しない」クラスタよりもアベイラビリティ(可用性)の低い、低価格なクラスタをセットアップすることもできます。たとえば、1つのシングルコントローラRAIDアレイと1つのイーサネットチャネルのクラスタをセットアップできます。
![]() | 注記 |
---|---|
ソフトウェアRAIDとマルチイニシエータパラレルSCSIなどの低価格な代替機能は、共有クラスタストレージと互換性がなかったり、共有クラスタストレージ上で使用するのには適していません。詳細については、項1.1を参照してください。 |
サービス設定フレームワーク
クラスタにより、容易に個別のサービスを設定して、データやアプリケーションのアベイラビリティ(可用性)を高めることができます。サービスを作成するには、サービスとサービスのプロパティ(サービス名、アプリケーション起動/停止/状態 スクリプト、ディスクパーティション、マウントポイント、およびサービスを実行するクラスタシステムなどを含む)で使用するリソースを指定します。 サービスが追加されると、 全クラスタメンバーが設定データにアクセスできる共有ストレージの クラスタ設定ファイルに クラスタ管理ソフトウェアが情報を保存します。
クラスタには、データベースアプリケーション用の使い方が簡単なフレームワークが用意されています。たとえば、データベースサービスは、アベイラビリティ(可用性)の高いデータをデータベースアプリケーションに提供します。クラスタメンバー上で実行されているアプリケーションは、ネットワークアクセスをWebサーバなどのデータベースクライアントシステムに提供します。サービスがもう一方のクラスタシステムにフェイルオーバーした場合でも、アプリケーションは共有データベースのデータに引き続きアクセスすることができます。ネットワークアクセス可能なデータベースサービスには、通常、1つのIPアドレスが割り当てられていて、クライアントに対して透過的なアクセスを維持できるようにサービスとともにフェイルオーバーされます。
クラスタサービスフレームワークは、別のアプリケーションに容易に拡張することもできます。
フェイルオーバードメイン
サービスを制限付きフェイルオーバドメイン に割り当てると、フェイルオーバー時にサービスを実行できるメンバーを 制限することができます。 (フェイルオーバードメインに含まれていないクラスタメンバー は制限付きフェイルオーバードメインに割り当てられたサービスを 起動できません) 特定のメンバーによってサービスを実行させるため、フェイルオーバードメインのメンバーを希望によって順番付けすることもできます。 (メンバーがアクティブの場合) サービスを非制限フェイルオーバードメインに割り当てると、 このサービスは任意の使用可能クラスタメンバーによって実行されます。 (利用可能なフェイルオーバードメインのメンバーがない場合)
データ整合性保証
データ整合性を保証できるように、一度に1つのメンバーだけがサービスを実行したりサービスデータにアクセスできます。 クラスタハードウェア構成で電源スイッチを使用することで、メンバーは、フェイルオーバー時にもう一方のメンバーのサービスを再起動する前に、 そのメンバーの電源のオンとオフを切り換えることができるようになります。 これにより、2つのシステムが同じデータに同時にアクセスしてデータを破損することを防止できます。あらゆる障害発生状況でデータ整合性を保証するために電源スイッチの使用をお勧めします。 Watchdogタイマーは電源コントロールオプションの1つで、サービスのフェイルオーバーが正しく行われることを保証します。
クラスタ管理ユーザーインターフェイス
クラスタ管理インターフェイスは次のような管理タスクを容易にします。: サービスの作成/起動/停止、他のメンバーへのサービス再配置、クラスタ設定の 変更(サービス/リソースの追加/削除)、クラスタメンバーやサービスの監視。
イーサネット チャネル ボンディング
他のメンバーの健康状態を監視するために、各メンバーが遠隔電源スイッチの状態を監視し(遠隔電源スイッチがある場合)、ネットワークチャンネルに heartbeat ping を配信します。イーサネット チャネル ボンディング を使用する場合は 複数のイーサネットインターフェースが1つとして作動するよう設定され、 システム間の標準的なイーサネット接続切り換えに対し、一ヶ所で発生した 障害のリスクを軽減します。
quorum (定数)情報の共有ストレージ
共有状態情報によってメンバーがアクティブであるかが分ります。 サービス状態情によってサービスが実行されているか、どのメンバーがシステムを実行しているかが分ります。 他のメンバーの状態が最新のものであるかを各メンバーが確認します。
2メンバのクラスタでは、各メンバが共有ディスクストレージにある2つの共有クラスタ パーティションにタイムスタンプとクラスタ状態情報を定期的に書き込みます。 クラスタが正しく動作することを保証できるように、メンバが起動時にプライマリと シャドーの共有クラスタパーティション両方に書き込みを行えない場合、 メンバはクラスタに組み込まれません。また、 メンバがタイムスタンプを更新していなくて、 システムへのハートビートが失敗すると、 そのメンバはクラスタから除外されます。
クラスタ構成でメンバがどのように通信するかを図2に示します。 シリアルポート経由でシステムコンソールにアクセスするのに使用するターミナルサーバは、 必須のクラスタコンポーネントではありません。
サービスのフェイルオーバー機能
ハードウェアまたはソフトウェア障害が発生すると、クラスタは適切なアクションを実行して、アプリケーションのアベイラビリティ(可用性)とデータ整合性を維持します。たとえば、メンバが完全にダウンした場合、 別のメンバ(関連付けられたフェイルオーバードメインまたはクラスタ内のメンバ)が そのサービスを再起動します。このメンバですでに実行されているサービスは継続されます。
障害が発生したメンバが再起動し、共有クラスタパーティションに書き込みを行えるようになると、そのメンバはクラスタに再度組み込まれ、サービスを実行します。サービスの構成によっては、クラスタはメンバ間でサービスの負荷を調整することができます。
手動によるサービス再配置機能
自動サービスフェイルオーバー機能に加え、一方のクラスタシステム上のサービスを正常に停止して、 それを別のシステムで再起動することができる機能を備えています。 この機能により、アプリケーションとデータのアベイラビリティ(可用性)を維持したまま、 メンバシステムで定期メンテナンスを実施することができます。
イベントロギング機能
サービスのアベイラビリティ(可用性)に影響が出る前に問題を検出して解決できるように、クラスタデーモンは標準的なLinux syslogサブシステムを使用してメッセージをログに記録します。管理者は、ログに記録されるメッセージの重要度レベルをカスタマイズできます。
アプリケーションのモニタリング
クラスタでのインフラストラクチャは、オプションでアプリケーションの状態をモニターすることもできます。この方法で、アプリケーション固有の障害が発生した場合、クラスタは自動的にアプリケーションを再起動します。アプリケーションでの障害に応じて、 このアプリケーションは当初実行されていたメンバ上で再起動を試み、 それが失敗すると別のクラスタメンバーで再起動します。 サービスにフェイルオーバードメインを割り当てることにより、 サービスを起動できるメンバを指定することができます。