この章では、Sun Cluster システムのハードウェアやソフトウェアに関連する主な概念を説明します。ユーザーは、Sun Cluster システムを使用する前にこれらの概念を理解しておく必要があります。
この章で説明する内容は次のとおりです。
クラスタとは、1 つまたは複数のノードの集合をいい、それらのノードはその集合に排他的に属します。Solaris 10 OS 上で実行されるクラスタの種類には、グローバルクラスタとゾーンクラスタがあります。Solaris 10 OS より前にリリースされたいずれかのバージョンの Solaris OS 上で実行されるクラスタでは、ノードとは、クラスタメンバーを構成するが定足数デバイスではない物理マシンをいいます。Solaris 10 OS 上で実行されるクラスタでは、ノードの概念が変更されています。ノードとは、クラスタに関連付けられている Solaris のゾーンです。この環境では、Solaris ホスト (または単にホスト) とは、Solaris OS およびそのプロセスを実行する、次のハードウェア/ソフトウェア構成のいずれかを指します。
仮想マシンまたはハードウェアドメインとして構成されていない、「ベアメタル」物理マシン
Sun Logical Domains (LDoms) のゲストドメイン
Sun Logical Domains (LDoms) の I/O ドメイン
ハードウェアドメイン
Solaris 10 環境では、投票ノードとは、定足数投票、つまりクラスタのメンバーシップ投票の、総数の票を構成するゾーンです。この総数により、そのクラスタが処理を継続するのに十分な票を持っているかどうかが決定されます。非投票ノードとは、定足数投票、つまりクラスタのメンバーシップ投票の、総数を構成しないゾーンです。
クラスタ環境では、すべてのノードがインターコネクトによって接続され、単一のエンティティーとして動作するので、可用性と性能が向上します。
Solaris 10 環境では、グローバルクラスタは、1 つまたは複数のグローバルクラスタ投票ノード、およびオプションで 0 個以上のグローバルクラスタ非投票ノードから構成されるクラスタです。
グローバルクラスタには、オプションで solaris8、solaris9、lx (linux)、またはネイティブブランドの非大域ゾーンを含めることができます。これらはノードではなく、高可用性のコンテナ (リソース) です。
グローバルクラスタ投票ノードとは、グローバルクラスタ内のネイティブブランドの大域ゾーンで、定足数投票、つまりクラスタのメンバーシップ投票の、総数の票を構成します。この総数により、そのクラスタが処理を継続するのに十分な票を持っているかどうかが決定されます。グローバルクラスタ非投票ノードとは、グローバルクラスタ内のネイティブブランドの非大域ゾーンで、定足数投票、つまりクラスタのメンバーシップ投票の、総数の票を構成しません。
Solaris 10 環境では、ゾーンクラスタは、1 つまたは複数のクラスタブランドの投票ノードのみから構成されるクラスタです。ゾーンクラスタは、グローバルクラスタに依存しており、したがって、グローバルクラスタを必要とします。グローバルクラスタはゾーンクラスタを含みません。ゾーンクラスタを構成するには、グローバルクラスタが必要です。ゾーンクラスタは 1 つのマシン上に最大で 1 つのゾーンクラスタノードを持ちます。
ゾーンクラスタノードは、同一マシン上のグローバルクラスタ投票ノードが処理を継続している間にかぎり、処理を継続できます。あるマシン上のグローバルクラスタ投票ノードに障害が発生すると、そのマシン上のすべてのゾーンクラスタノードにも同様に障害が発生します。
Sun Cluster ソフトウェアは、ハードウェア構成に応じて、1 つのクラスタで 1 - 16 個の Solaris ホストを使用できます。使用しているハードウェア構成でサポートされる Solaris ホストの数については、ご購入先にお問い合わせください。
1 つのクラスタ内の Solaris ホストは、通常、1 つ以上のディスクに接続されます。ディスクに接続されていない Solaris ホストは、クラスタファイルシステムを使用して多重ホストディスクにアクセスします。並列データベース構成の下にある各 Solaris ホストは、一部またはすべてのディスクに同時にアクセスします。
クラスタ内のすべてのノードは、別のノードがいつクラスタに結合されたか、またはクラスタから切り離されたかを認識します。さらに、クラスタ内のすべてのノードは、ローカルに実行されているリソースだけでなく、他のクラスタノードで実行されているリソースも認識します。
同じクラスタ内の各 Solaris ホストの処理、メモリー、および入出力機能を同等にして、フェイルオーバー発生時にパフォーマンスが著しく低下しないようにする必要があります。フェイルオーバーの可能性があるため、各ホストには、ノードの障害時にもサービスレベル合意を満たせる十分な容量を持たせる必要があります。
この節では、ゾーンクラスタの主要な機能および利点について説明します。
ゾーンクラスタを使用することで、次のような機能および利点が得られます。
アプリケーションの障害分離 – あるゾーンクラスタでアプリケーションに障害が発生しても、その他のゾーンクラスタのアプリケーションには影響しません。たとえば、あるゾーンクラスタのノードが起動、停止、または再起動しても、その他のゾーンクラスタは影響を受けません。
セキュリティー – あるゾーンクラスタノードにログインしているアプリケーションまたはユーザーは、グローバルクラスタまたはその他のゾーンクラスタの要素を参照したり変更したりすることはできません。ゾーンクラスタには、そのゾーンクラスタの一部として明示的に構成されるファイルシステム、ZFS データセット、ネットワークリソースなどの要素のみが含まれます。ゾーンクラスタ内のフェイルオーバーアプリケーションは、ゾーンクラスタ内のあるノードから、同一ゾーンクラスタ内の別のノードにのみ、フェイルオーバーまたはスイッチオーバーすることができます。スケーラブルなアプリケーションのインスタンスはすべて、同一のゾーンクラスタ内でのみ実行されます。ゾーンクラスタは、アプリケーションがエスケープできないセキュリティーコンテナです。
リソース管理 – Solaris のリソース管理制御の全機能を、ゾーンクラスタに対して適用できます。したがって、ゾーンクラスタ内のあるノード上に存在するすべてのアプリケーションを、ゾーンレベルで制御できます。これにより、ゾーンクラスタノードで利用できるリソースを、より効率的に管理できます。たとえば、1 つのゾーンクラスタ内に 1 つのアプリケーションを配置して、CPU の数を減らすことができます。こうすることで、CPU ごとのライセンス料金を削減できます。
委任管理 – ゾーンクラスタ内のアプリケーションを管理する権限を、そのゾーンクラスタで処理を行っている管理者に委任できます。ゾーンクラスタは、グローバルクラスタやその他のゾーンクラスタとは独立して機能します。大域ゾーンの管理者は、ゾーンクラスタ内のクラスタ間の依存関係やアフィニティーの設定、およびアプリケーションの管理を行うことができます。
単純化されたクラスタ – ゾーンクラスタ内で行う必要があるのは、アプリケーションおよびそのアプリケーションが使用するリソースの管理のみです。大域ゾーンの管理者は、ゾーンクラスタの内部および外部でコマンドを実行することにより、いつでもゾーンクラスタを作成、管理および削除できます。これらの操作は、グローバルクラスタやその他のゾーンクラスタには影響しません。
クラスタインターコネクトは、クラスタ内の Solaris ホスト間でクラスタプライベート通信やデータサービス通信を転送する物理的なデバイス構成です。
冗長なインターコネクトの 1 つに障害が発生しても、操作は残りのインターコネクトを使って続けられます。そのため、システム管理者は、その間に障害を分離し、通信を修復することができます。Sun Cluster ソフトウェアは障害を検知し、修復し、修復されたインターコネクト経由の通信を自動的に再始動します。
詳細については、「クラスタインターコネクトコンポーネント」を参照してください。
クラスタメンバーシップモニター (CMM) は、クラスタインターコネクトを使ってメッセージを交換し、次の処理を行う一連の分散エージェントです。
すべてのノード (定足数) で一貫したメンバーシップの表示を行います。
メンバーシップの変更に応じて同期のとれた再構成を行います。
クラスタのパーティション分割を処理します。
障害のあるノードを、障害が修復されるまでクラスタから除外することによって、すべてのクラスタメンバー間の完全な接続を維持します。
CMM の主な機能はクラスタメンバーシップを確立することですが、そのためには、クラスタに逐次参加するノード群に関してクラスタ全体が合意していなければなりません。CMM は、1 つまたは複数のノード間での通信の途絶など、各ノードにおけるクラスタステータスの大きな変化を検知します。CMM は、トランスポートカーネルモジュールを使ってハートビートを生成し、トランスポート媒体を通してそれをクラスタのほかのノードに伝送します。定義されたタイムアウト時間内にノードからハートビートが送られてこないと、CMM は、そのノードに障害が発生したものとみなし、クラスタの再構成を通してクラスタメンバーシップの再設定を試みます。
CMM は、クラスタメンバーシップを確定し、データの整合性を確保するために、次の処理を行います。
クラスタへのノードの参加、またはクラスタからのノードの脱退など、クラスタメンバーシップの変更を把握します。
異常のあるノードを、クラスタから切り離された状態に保ちます。
異常のあるノードを、それが修復されるまで非アクティブの状態に保ちます。
クラスタそのものがノードのサブセットに分割されないように防止します。
クラスタ自身が複数の異なるクラスタに分割されないようにする方法についての詳細は、「split-brain と amnesia」を参照してください。
クラスタ構成レポジトリ (Cluster Configuration Repository、CCR) は、クラスタの構成や状態に関する情報を格納するための、クラスタ全体に有効なプライベート分散データベースです。構成データを破損しないために、個々のノードは、クラスタリソースの現在の状態を知っている必要があります。この CCR のおかげで、すべてのノードが、一貫性のあるクラスタ像を持つことができます。CCR は、エラーや復旧の情況が発生したり、クラスタの一般的なステータスに変化があると更新されます。
CCR 構造には、次のような情報が含まれています。
クラスタ名とノード名
クラスタトランスポート構成
Solaris Volume Manager ディスクセットや Veritas ディスクグループの名前
個々のディスクグループをマスターできるノードのリスト
データサービスの操作に関するパラメータ値
データサービスコールバックメソッドへのパス
DID デバイス構成
クラスタの現在のステータス
定足数デバイスとは、複数のノードによって共有される共有ストレージデバイスまたは定足数サーバーで、定足数を確立するために使用される票を構成します。クラスタは、票の定足数が満たされた場合にのみ動作可能です。定足数デバイスは、クラスタが独立したノードの集合にパーティション分割されたときに、どちらのノード集合が新しいクラスタを構成するかを確定するために使用されます。
クラスタノードと定足数デバイスはどちらも、定足数を確立するために投票します。デフォルトにより、クラスタノードは、起動してクラスタメンバーになると、定足数投票数 (quorum vote count) を 1 つ獲得します。ノードは、ノードのインストール中や管理者がノードを保守状態にした時には、投票数は 0 になります。
定足数デバイスは、デバイスへのノード接続の数に基づいて投票数を獲得します。定足数デバイスは、設定されると、最大投票数 N-1 を獲得します。この場合、N は、定足数デバイスへ接続された投票数を示します。たとえば、2 つのノードに接続された、投票数がゼロ以外の定足数デバイスの投票数は 1 (2-1) になります。
Sun Cluster システムでは、アプリケーションそのものや、ファイルシステム、ネットワークインタフェースを監視することによって、ユーザーとデータ間の「パス」にあるすべてのコンポーネントの高い可用性を保ちます。
Sun Cluster ソフトウェアは、ノードを素早く検知し、そのノードと同等のリソースを備えたサーバーを作成します。Sun Cluster ソフトウェアのおかげで、障害のあるノードの影響を受けないリソースはこの復旧中も引き続き使用され、障害のあるノードのリソースは復旧すると同時に再び使用可能になります。
Sun Cluster の各データサービスには、データサービスを定期的に検査してその状態を判断するフォルトモニターがあります。フォルトモニターは、アプリケーションデーモンが動作しているかどうかや、クライアントにサービスが提供されているかどうかを検証します。探索によって得られた情報をもとに、デーモンの再起動やフェイルオーバーの実行などの事前に定義された処置が開始されます。
Sun Cluster ソフトウェアは、ディスクパス監視 (DPM) がサポートします。DPM は、二次ディスクパスの障害を報告することによって、フェイルオーバーやスイッチオーバーの全体的な信頼性を高めます。ディスクパスの監視には 2 つの方法があります。1 つめの方法は cldevice コマンドを使用する方法です。このコマンドを使用すると、クラスタ内のディスクパスの状態を監視、監視解除、または表示できます。コマンド行オプションについての詳細は、cldevice(1CL) のマニュアルページを参照してください。
2 つめの方法は、Sun Cluster Manager の GUI (Graphical User Interface) を使用してクラスタ内のディスクパスを監視する方法です。Sun Cluster Manager では、監視されているディスクパスがトポロジで表示されます。このトポロジビューは 10 分ごとに更新され、失敗した ping の数が表示されます。
クラスタの各 Solaris ホストは、そのクラスタのほかのホストの構成とは異なる、独自の IP ネットワークマルチパス 構成を持ちます。IP ネットワークマルチパス は、次のネットワークの通信障害を監視します。
ネットワークアダプタの送信/受信パスがパケットの伝送を停止した。
ネットワークアダプタとリンクとの接続がダウンしている。
Ethernet スイッチ上のポートがパケットを送受信しない。
グループ内の物理インタフェースがシステムの起動時に存在しない。
Sun Cluster ソフトウェアは、定足数デバイスの監視をサポートしています。クラスタ内の各ノードは周期的に、ローカルノードと構成されている各定足数デバイスとが正常に連携しているかどうかをテストします。構成されている定足数デバイスとは、そのローカルノードに対する構成パスを持ち、かつ保守モードでないデバイスをいいます。このテストでは、定足数デバイスの定足数キーの読み込みを試みます。
Sun Cluster システムは、以前は正常だった定足数デバイスが障害を起こしているのを発見すると、自動的にその定足数デバイスを異常としてマーク付けします。以前は異常だった定足数デバイスが正常に戻っているのを発見すると、自動的にその定足数デバイスを正常としてマーク付けし、その定足数デバイスに適切な定足数情報を配置します。
Sun Cluster システムは、定足数デバイスが正常かどうかのステータスが変更された場合にレポートを生成します。ノードを再構成するとき、異常な定足数デバイスはメンバーシップの票を構成できません。したがって、そのクラスタは処理を継続できない可能性があります。
Sun Cluster システムはデータ破損を防ぎ、データの完全性を保とうとします。それぞれのクラスタノードはデータとリソースを共有していますので、クラスタが、同時にアクティブである複数のパーティションに分割されることがあってはなりません。CMM は、必ず 1 つのクラスタだけが使用可能であることを保証します。
クラスタのパーティション分割によって起こる問題に、split-brain と amnesia の 2 つがあります。split-brain が起こるのは、Solaris ホスト間のクラスタインターコネクトが失われてクラスタがサブクラスタにパーティション分割され、それぞれのサブクラスタがそれを唯一のパーティションであると認識する場合です。ほかのサブクラスタの存在を認識していないサブクラスタは、ネットワークアドレスの重複やデータ破損など、共有リソースの対立を引き起こすおそれがあります。
amnesia は、すべてのノードがそのクラスタ内で不安定なグループの状態になっている場合に起こります。たとえば、ノード A とノード B からなる 2 ノードクラスタがあるとします。ノード A が停止すると、CCR の構成データはノード B のものだけが更新され、ノード A のものは更新されません。この後でノード B が停止し、ノード A が再起動されると、ノード A は CCR の古い内容に基づいて動作することになります。この状態を amnesia と呼びます。この状態になると、クラスタは、古い構成情報で実行されることがあります。
split-brain と amnesia の問題は、各ノードに 1 票を与え、過半数の投票がないとクラスタが動作しないようにすることで防止できます。過半数の投票を得たパーティションは「定足数 (quorum)」を獲得し、アクティブになります。この過半数の投票メカニズムは、クラスタのノード数が 2 を超える場合には有効です。しかし、2 ノードクラスタでは過半数が 2 であるため、このようなクラスタがパーティション分割されると、パーティションは外部からの投票で定足数を獲得します。この外部からの投票は、定足数デバイスによって行われます。定足数デバイスは、2 つのノードで共有されている任意のディスクにすることができます。
表 2–1に、Sun Cluster ソフトウェアが定足数を使用して split-brain と anmesia を回避する様子を示します。
表 2–1 クラスタ定足数、および split-brain と amnesia の問題
問題 |
定足数による解決策 |
---|---|
split brain |
過半数の投票を獲得したパーティション (サブクラスタ) だけをクラスタとして実行できるようにする (過半数を獲得できるパーティションは 1 つのみ)。ノードが定足数を獲得できないと、ノードはパニックになります。 |
amnesia |
起動されたクラスタには、最新のクラスタメンバーシップのメンバーであった (したがって、最新の構成データを持つ) ノードが少なくとも 1 つあることを保証する。 |
split brain が発生すると、一部のノードが通信できなくなるため、個々のノードまたは一部のノードが個々のクラスタまたは一部のクラスタを形成しようとします。各部分、つまりパーティションは、多重ホストディスクに対して単独のアクセスと所有権を持つものと誤って認識します。しかし、複数のノードがディスクに書き込もうとすると、データ破損を招くおそれがあります。
ノードは、ほかのノードとの接続を失うと、通信が可能なノードとクラスタを形成しようとします。そうしたノードの集合が定足数を得られない場合、Sun Cluster ソフトウェアはそのノードを停止して、ディスクから「フェンシング」します。つまり、そのノードがディスクにアクセスできないようにします。現在のメンバーノードだけが、ディスクへのアクセス権を持つため、データの完全性が保たれます。
フェンシングは、選択したディスクまたはすべてのディスクに対して無効にすることができます。
不適切な状況でフェンシングを無効にすると、アプリケーションのフェイルオーバー時にデータが破損する危険性が高くなります。フェンシングの無効化を検討する場合には、データ破損の可能性を十分に調査してください。共有ストレージデバイスで SCSI プロトコルがサポートされていない場合 (Serial Advanced Technology Attachment (SATA) ディスクなど)、またはクラスタのストレージにクラスタ外部にあるホストからのアクセスを許可する場合に、フェンシングを無効にします。
フェイルファーストの目的は、正常な処理を継続できない、正常でないコンポーネントを停止することです。Sun Cluster ソフトウェアは、さまざまな異常な状態を検出するための、多くのフェイルファーストメカニズムを備えています。
Sun Cluster システムは、グローバルクラスタ投票ノードでクリティカルな障害を検出すると、強制的にその Solaris ホストをシャットダウンします。
その他の種類のノード (グローバルクラスタ非投票ノード、ゾーンクラスタノードなど) にクリティカルな障害を検出した場合は、そのノードを再起動します。
Sun Cluster ソフトウェアは、クラスタに属するノードを監視します。通信やノードの障害により、クラスタのノード数は変わります。クラスタが十分な投票数を維持できない場合、Sun Cluster ソフトウェアはそのノードの集合を停止します。
Sun Cluster ソフトウェアは、多数のクリティカルなクラスタ固有デーモンを維持管理します。デーモンには、グローバルクラスタ投票ノードをサポートするものや、その他の種類のノードをサポートするものがあります。デーモンは、そのデーモンがサポートするノードにとってクリティカルです。サポートするノードは、デーモンが実行されているノードによって異なります。たとえば、大域ゾーンの一部のデーモンは、非大域ゾーンをサポートします。このため、これらのデーモンは、大域ゾーンよりもむしろ非大域ゾーンにとってクリティカルになります。
クラスタファイルシステムでは、クラスタのすべてのファイルがすべてのノードから同じように認識され、アクセス可能になります。それと同様に、Sun Cluster ソフトウェアの下では、クラスタのすべてのデバイスがクラスタ全体から認識され、アクセス可能になります。つまり、どのノードからでも入出力サブシステムを通してクラスタのどのデバイスにもアクセスできます。デバイスが物理的にどこに接続されているかは関係ありません。このアクセスをグローバルデバイスアクセスと呼びます。
Sun Cluster システムでは、クラスタの任意のデバイスに任意のノードから高い可用性をもってクラスタレベルでアクセスできるようにするために、グローバルデバイスを使用します。
通常、ノードからグローバルデバイスにアクセスできないことがあると、Sun Cluster ソフトウェアは、そのデバイスへのパスを別のパスに切り替え、アクセスをそのパスに振り向けます。グローバルデバイスでは、この変更は簡単です。どのパスを使用する場合でも、デバイスには同じ名前が使用されるからです。リモートデバイスへのアクセスは、同じ名前を持つローカルデバイスの場合と同じように行われます。さらに、クラスタのグローバルデバイスにアクセスする API は、ローカルのデバイスにアクセスする API と同じです。
Sun Cluster グローバルデバイスには、ディスク、CD-ROM、テープが含まれます。ただし、サポートされるマルチポートのグローバルデバイスはディスクだけです。つまり、CD-ROM とテープは、現在可用性の高いデバイスではありません。各サーバーのローカルディスクも多重ポート化されていないため、可用性の高いデバイスではありません。
クラスタは、クラスタ内の各ディスク、CD-ROM、テープデバイスに一意の ID を割り当てます。この割り当てによって、クラスタ内の任意のノードから各デバイスに対して一貫したアクセスが可能になります。
Sun Cluster ソフトウェアは、デバイス ID (DID) ドライバと呼ばれるコンストラクトを通してグローバルデバイスを管理します。このドライバを使用して、多重ホストディスク、テープドライブ、CD-ROM を含め、クラスタ内のあらゆるデバイスに一意の ID を自動的に割り当てます。
DID ドライバは、クラスタのグローバルデバイスアクセス機能の重要な部分です。DID ドライバは、クラスタのすべてのノードを検査し、一意のディスクデバイスからなるリストを構築します。さらに、DID ドライバは、一意のメジャー番号とマイナー番号を各デバイスに割り当てます。この数字は、クラスタのすべてのノードで一貫性をもって管理されます。グローバルデバイスへのアクセスは、従来の Solaris DID と替わって DID ドライバによって割り当てられた 一意の DID を使って行われます。
このような方法をとることで、Solaris Volume Manager など、ディスクにアクセスするアプリケーションが何であれ、クラスタ全体で一貫性のあるパスが使用されます。多重ホストディスクの場合は、この一貫性がとりわけ重要です。各デバイスのローカルのメジャー番号とマイナー番号はノードによって異なる可能性があるからです。さらに、これらの数字は、Solaris デバイスの命名規約も同様に変更する可能性があります。
Sun Cluster ソフトウェアはローカルデバイスも管理します。このようなデバイスは、サービスを実行していてクラスタに物理的に接続されている Solaris ホストでのみアクセス可能です。ローカルデバイスは、性能の点でグローバルデバイスよりも有利です。ローカルデバイスでは、状態情報を複数のホストに同時に複製する必要がないからです。デバイスのドメインに障害が発生すると、そのデバイスにはアクセスできなくなります。ただし、そのデバイスを複数のホストで共有できる場合を除きます。
デバイスグループは、ボリュームマネージャーのディスクグループを「グローバル」デバイスにします。デバイスグループは、使用しているディスクに対してマルチパスと多重ホストをサポートするからです。多重ホストディスクに物理的に接続された各クラスタの Solaris ホストは、デバイスグループへのパスを提供します。
Sun Cluster システムで Sun Cluster ソフトウェアを使用している多重ホストディスクを制御するには、多重ホストディスクをデバイスグループとして登録します。この登録によって、Sun Cluster システムは、どのノードがどのボリュームマネージャーディスクグループへのパスを持っているかを知ることができます。Sun Cluster ソフトウェアは、クラスタ内のディスクデバイスやテープデバイスごとに、raw デバイスグループを作成します。これらのクラスタデバイスグループは、ユーザーがクラスタファイルシステムをマウントするか、raw データベースファイルにアクセスすることによって、これらのデバイスグループにグローバルデバイスとしてアクセスするまで、オフライン状態に置かれます。
データサービスは、Sun Cluster 構成の下でアプリケーションを変更なしで実行できるようにする、ソフトウェアと構成ファイルの組み合わせです。Sun Cluster 構成の下で動作するアプリケーションは、リソースグループマネージャー (Resource Group Manager、RGM) の制御下にある 1 つのリソースです。データサービスを使えば、Sun Java System Web Server や Oracle データベースなどのアプリケーションをクラスタで (単一のサーバーではなく) 実行するように構成できます。
データサービスのソフトウェアは、アプリケーションに対して次の操作を行う Sun Cluster 管理メソッドを実装しています。
アプリケーションの起動
アプリケーションの停止
アプリケーションの障害の監視とこの障害からの復旧
データサービスの構成ファイルは、RGM にとってアプリケーションを意味するリソースのプロパティーを定義したものです。
クラスタのフェイルオーバーデータサービスやスケーラブルデータサービスの処理は RGM によって制御されます。RGM は、クラスタメンバーシップの変更に応じて選択されたクラスタのノードでデータサービスの起動や停止を行います。データサービスアプリケーションは、RGM を通してクラスタフレームワークを利用できます。
RGM はデータサービスをリソースとして制御します。これらの実装は Sun によって提供されるか、開発者によって作成されます。後者の場合には、汎用的なデータサービステンプレートや、データサービス開発ライブラリ API (Data Service Development Library API、DSDL API)、リソース管理 API (Resource Management API、RMAPI) が使用されます。クラスタ管理者は、リソースグループと呼ばれる入れ物 (コンテナ) の中でリソースの作成や管理を行います。リソースやリソースグループの状態は、RGM や管理者のアクションによってオンラインやオフラインにされます。
リソースタイプとは、あるアプリケーションをクラスタに説明するプロパティーの集まりのことです。この集合には、クラスタのノードでアプリケーションをどのように起動、停止、監視するかを示す情報が含まれています。さらに、リソースタイプには、アプリケーションをクラスタで使用するために必要なアプリケーション固有のプロパティーも含まれています。Sun Cluster データサービスには、いくつかのリソースタイプが事前に定義されています。たとえば、Sun Cluster HA for Oracle のリソースタイプは SUNW.oracle-server、Sun Cluster HA for Apache のリソースタイプ SUNW.apache です。
リソースとは、クラスタ規模で定義したリソースタイプのインスタンスのことです。リソースタイプを使用すると、アプリケーションの複数のインスタンスをクラスタにインストールできます。ユーザーがリソースを初期化すると、RGM は、アプリケーション固有のプロパティーに値を割り当てます。リソースは、リソースタイプのレベルにあるすべてのプロパティーを継承します。
データサービスは、いくつかのタイプのリソースを使用します。たとえば、Apache Web Server や Sun Java System Web Server などのアプリケーションは、それらが依存するネットワークアドレス (論理ホスト名と共有アドレス) を使用します。アプリケーションとネットワークリソースは RGM が管理する基本単位です。
RGM は、複数のリソースをリソースグループという 1 つの単位として扱うことができるようにします。リソースグループとは、関連する (あるいは、相互に依存する) リソースの集合のことです。たとえば、SUNW.LogicalHostname リソースタイプから派生したリソースは、Oracle データベースリソースタイプから派生したリソースと同じリソースグループに置かれることがあります。リソースグループ上でフェイルオーバーまたはスイッチオーバーが開始されると、リソースグループは 1 つの単位として移行されます。
データサービスを使用すると、アプリケーションは可用性の高いものやスケーラブルなサービスになります。クラスタで単一の障害が発生した場合、大幅なアプリケーションの中断を回避できます。
データサービスを構成する際には、次のデータサービスのタイプから 1 つを選択する必要があります。
フェイルオーバーデータサービス
スケーラブルデータサービス
パラレルデータサービス
フェイルオーバーとは、クラスタがアプリケーションを障害のある稼動系から、指定の冗長化された待機系に自動的に再配置するプロセスのことをいいます。フェイルオーバーアプリケーションには、次の特徴があります。
クラスタの 1 つのノードだけに実行の資格があります。
クラスタで動作していることを意識させません。
クラスタフレームワークに基づいて HA を達成します。
フォルトモニターは、エラーを検出すると、データサービスの構成に従って、同じノードでそのインスタンスを再起動しようとするか、別のノードでそのインスタンスを起動 (フェイルオーバー) しようとします。フェイルオーバーサービスは、アプリケーションインスタンスリソースとネットワークリソース (論理ホスト名) のコンテナである、フェイルオーバーリソースグループを使用します。論理ホスト名とは、1 つのノードに構成して、後で自動的に元のノードや別のノードに構成できる IP アドレスのことです。
サービスが一時的に中断されるため、クライアントは、フェイルオーバーの完了後にサービスに再接続しなければならない場合があります。しかし、クライアントは、サービスの提供元である物理サーバーが変更したことを意識しません。
スケーラブルデータサービスでは、複数のアプリケーションインスタンスが複数のノードで同時に動作します。スケーラブルサービスは、2 つのリソースグループを使用します。スケーラブルリソースグループにはアプリケーションリソースが、フェイルオーバーリソースグループには、スケーラブルサービスが依存するネットワークリソース (共有アドレス) がそれぞれ含まれています。スケーラブルリソースグループは、複数のノードでオンラインにできるため、サービスの複数のインスタンスを同時に実行できます。共有アドレスのホストとなるフェイルオーバーリソースグループは、一度に 1 つのノードでしかオンラインにできません。スケーラブルサービスをホストとするすべてのノードは、サービスをホストするための同じ共有アドレスを使用します。
クラスタは、同一のネットワークインタフェース (グローバルインタフェース) を通してサービス要求を受け取ります。これらの要求は、事前に定義されたいくつかのアルゴリズムの 1 つに基づいてノードに分配されます (アルゴリズムは負荷均衡ポリシーによって設定される)。クラスタは、負荷均衡ポリシーを使用し、いくつかのノード間でサービス負荷均衡をとることができます。
Sun Cluster システムは、パラレルデータベースを使用することによってクラスタのすべてのノードでアプリケーションを並列で実行できるようにする環境を提供します。Sun Cluster Support for Oracle Real Application Clusters は、インストールされている場合、Oracle Real Application Clusters を Sun Cluster ノードで実行できるようにするパッケージ群です。さらに、このデータサービスでは、Sun Cluster コマンドを使って Sun Cluster Support for Oracle Real Application Clusters を管理できます。
パラレルアプリケーションはクラスタ環境で動作するように考えられたものです。したがって、このようなアプリケーションは、複数のノードから同時マスターされます。Oracle Real Application Clusters 環境では、複数の Oracle インスタンスが協力して同じ共有データベースへのアクセス権を提供します。Oracle クライアントは、任意のインスタンスを使用してデータベースにアクセスできます。したがって、1 つまたは複数のインスタンスで障害が発生しても、クライアントは残りのインスタンスに接続することによって、引き続きデータベースにアクセスできます。
システムリソースは、CPU 使用率、メモリーの使用量、スワップの使用量、およびディスクとネットワークのスループットに関係します。
Sun Cluster ソフトウェアを使用すると、ノード、ディスク、ネットワークインタフェース、Sun Cluster のリソースグループ、Solaris ゾーンなどのオブジェクトタイプにより特定のシステムリソースがどれだけ使用されているかを監視できます。システムリソースの使用状況の監視は、リソース管理ポリシーの一部とすることができます。また、Sun Cluster では、あるリソースグループに割り当てられた CPU を制御し、リソースグループが実行されるプロセッサセットのサイズを制御できます。
Sun Cluster ソフトウェアを通してシステムリソースの使用状況を監視することにより、特定のシステムリソースを使用するサービスがどのように実行されているかを反映するデータを収集したり、リソースのボトルネックや過負荷などを見つけたりすることができ、これによって問題に事前に対処し、ワークロードをより効率的に管理することができます。システムリソースの使用状況に関するデータは、どのハードウェアリソースが十分に利用されておらず、どのアプリケーションが大量のリソースを使用しているかを判別するのに役立ちます。このデータに基づき、必要なリソースを備えたノードにアプリケーションを割り当てたり、フェイルオーバー先にするノードを選択したりできます。この統合により、ハードウェアリソースとソフトウェアリソースの使用方法を最適化できます。
あるデータの値がシステムリソースにとってクリティカルであると考えられる場合に、この値のしきい値を設定できます。しきい値を設定する際には、しきい値に重要度を割り当てることにより、このしきい値のクリティカル度の選択も行います。しきい値を超えると、Sun Cluster はそのしきい値の重要度を、ユーザーが選択した重要度に変更します。データ収集およびしきい値の構成についての詳細は、『Sun Cluster のシステム管理 (Solaris OS 版)』の第 9 章「CPU 使用率の制御の構成」を参照してください。
クラスタ上で動作する各アプリケーションおよびサービスには、それぞれ固有の CPU の要件があります。表 2–2 に、Solaris オペレーティングシステムのさまざまなバージョンで利用可能な CPU 制御操作を示します。
表 2–2 CPU の制御
Solaris のバージョン |
ゾーン |
制御 |
---|---|---|
Solaris 9 オペレーティングシステム |
該当なし |
CPU の配分の割り当て |
Solaris 10 オペレーティングシステム |
大域 |
CPU の配分の割り当て |
Solaris 10 オペレーティングシステム |
非大域 |
CPU の配分の割り当て CPU の数の割り当て 専用のプロセッサセットの作成 |
CPU の配分を行う場合、クラスタ上のデフォルトのスケジューラを Fair Share Scheduler (FSS) にする必要があります。
非大域ゾーンで専用のプロセッサセットのリソースグループに割り当てられた CPU を制御すると、CPU をもっとも厳密に制御できます。これは、あるリソースグループ向けに CPU を予約した場合、この CPU はほかのリソースグループからは使用できないためです。CPU 制御の構成については、『Sun Cluster のシステム管理 (Solaris OS 版)』の第 9 章「CPU 使用率の制御の構成」を参照してください。
システムリソースデータと CPU の帰属を視覚化する方法には、コマンド行を使用する方法と Sun Cluster Manager グラフィカルユーザーインタフェースを使用する方法の 2 つがあります。コマンドからの出力は、ユーザーが要求する監視データの表形式の表現になります。Sun Cluster Manager を使用すると、データをグラフィック形式で視覚化できます。監視することを選択したシステムリソースは、ユーザーが視覚化できるデータを決定します。