test

Sun Cluster の概要 (Solaris OS 版)

第 2 章 Sun Cluster の主要な概念

この章では、Sun Cluster システムのハードウェアやソフトウェアに関連する主な概念を説明します。ユーザーは、Sun Cluster システムを使用する前にこれらの概念を理解しておく必要があります。

この章で説明する内容は次のとおりです。

クラスタ、ノード、およびホスト

クラスタとは、1 つまたは複数のノードの集合をいい、それらのノードはその集合に排他的に属します。Solaris 10 OS 上で実行されるクラスタの種類には、グローバルクラスタとゾーンクラスタがあります。Solaris 10 OS より前にリリースされたいずれかのバージョンの Solaris OS 上で実行されるクラスタでは、ノードとは、クラスタメンバーを構成するが定足数デバイスではない物理マシンをいいます。Solaris 10 OS 上で実行されるクラスタでは、ノードの概念が変更されています。ノードとは、クラスタに関連付けられている Solaris のゾーンです。この環境では、Solaris ホスト (または単にホスト) とは、Solaris OS およびそのプロセスを実行する、次のハードウェア/ソフトウェア構成のいずれかを指します。

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 ホストの処理、メモリー、および入出力機能を同等にして、フェイルオーバー発生時にパフォーマンスが著しく低下しないようにする必要があります。フェイルオーバーの可能性があるため、各ホストには、ノードの障害時にもサービスレベル合意を満たせる十分な容量を持たせる必要があります。

ゾーンクラスタ

この節では、ゾーンクラスタの主要な機能および利点について説明します。

ゾーンクラスタの機能および利点

ゾーンクラスタを使用することで、次のような機能および利点が得られます。

クラスタインターコネクト

クラスタインターコネクトは、クラスタ内の Solaris ホスト間でクラスタプライベート通信やデータサービス通信を転送する物理的なデバイス構成です。

冗長なインターコネクトの 1 つに障害が発生しても、操作は残りのインターコネクトを使って続けられます。そのため、システム管理者は、その間に障害を分離し、通信を修復することができます。Sun Cluster ソフトウェアは障害を検知し、修復し、修復されたインターコネクト経由の通信を自動的に再始動します。

詳細については、「クラスタインターコネクトコンポーネント」を参照してください。

クラスタメンバーシップ

クラスタメンバーシップモニター (CMM) は、クラスタインターコネクトを使ってメッセージを交換し、次の処理を行う一連の分散エージェントです。

CMM の主な機能はクラスタメンバーシップを確立することですが、そのためには、クラスタに逐次参加するノード群に関してクラスタ全体が合意していなければなりません。CMM は、1 つまたは複数のノード間での通信の途絶など、各ノードにおけるクラスタステータスの大きな変化を検知します。CMM は、トランスポートカーネルモジュールを使ってハートビートを生成し、トランスポート媒体を通してそれをクラスタのほかのノードに伝送します。定義されたタイムアウト時間内にノードからハートビートが送られてこないと、CMM は、そのノードに障害が発生したものとみなし、クラスタの再構成を通してクラスタメンバーシップの再設定を試みます。

CMM は、クラスタメンバーシップを確定し、データの整合性を確保するために、次の処理を行います。

クラスタ自身が複数の異なるクラスタに分割されないようにする方法についての詳細は、「split-brain と amnesia」を参照してください。

クラスタ構成レポジトリ

クラスタ構成レポジトリ (Cluster Configuration Repository、CCR) は、クラスタの構成や状態に関する情報を格納するための、クラスタ全体に有効なプライベート分散データベースです。構成データを破損しないために、個々のノードは、クラスタリソースの現在の状態を知っている必要があります。この CCR のおかげで、すべてのノードが、一貫性のあるクラスタ像を持つことができます。CCR は、エラーや復旧の情況が発生したり、クラスタの一般的なステータスに変化があると更新されます。

CCR 構造には、次のような情報が含まれています。

定足数デバイス

定足数デバイスとは、複数のノードによって共有される共有ストレージデバイスまたは定足数サーバーで、定足数を確立するために使用される票を構成します。クラスタは、票の定足数が満たされた場合にのみ動作可能です。定足数デバイスは、クラスタが独立したノードの集合にパーティション分割されたときに、どちらのノード集合が新しいクラスタを構成するかを確定するために使用されます。

クラスタノードと定足数デバイスはどちらも、定足数を確立するために投票します。デフォルトにより、クラスタノードは、起動してクラスタメンバーになると、定足数投票数 (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 の数が表示されます。

IP マルチパス監視

クラスタの各 Solaris ホストは、そのクラスタのほかのホストの構成とは異なる、独自の IP ネットワークマルチパス 構成を持ちます。IP ネットワークマルチパス は、次のネットワークの通信障害を監視します。

定足数デバイス監視

Sun Cluster ソフトウェアは、定足数デバイスの監視をサポートしています。クラスタ内の各ノードは周期的に、ローカルノードと構成されている各定足数デバイスとが正常に連携しているかどうかをテストします。構成されている定足数デバイスとは、そのローカルノードに対する構成パスを持ち、かつ保守モードでないデバイスをいいます。このテストでは、定足数デバイスの定足数キーの読み込みを試みます。

Sun Cluster システムは、以前は正常だった定足数デバイスが障害を起こしているのを発見すると、自動的にその定足数デバイスを異常としてマーク付けします。以前は異常だった定足数デバイスが正常に戻っているのを発見すると、自動的にその定足数デバイスを正常としてマーク付けし、その定足数デバイスに適切な定足数情報を配置します。

Sun Cluster システムは、定足数デバイスが正常かどうかのステータスが変更された場合にレポートを生成します。ノードを再構成するとき、異常な定足数デバイスはメンバーシップの票を構成できません。したがって、そのクラスタは処理を継続できない可能性があります。

データの完全性

Sun Cluster システムはデータ破損を防ぎ、データの完全性を保とうとします。それぞれのクラスタノードはデータとリソースを共有していますので、クラスタが、同時にアクティブである複数のパーティションに分割されることがあってはなりません。CMM は、必ず 1 つのクラスタだけが使用可能であることを保証します。

split-brain と amnesia

クラスタのパーティション分割によって起こる問題に、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 でグローバルデバイスを使用する方法

通常、ノードからグローバルデバイスにアクセスできないことがあると、Sun Cluster ソフトウェアは、そのデバイスへのパスを別のパスに切り替え、アクセスをそのパスに振り向けます。グローバルデバイスでは、この変更は簡単です。どのパスを使用する場合でも、デバイスには同じ名前が使用されるからです。リモートデバイスへのアクセスは、同じ名前を持つローカルデバイスの場合と同じように行われます。さらに、クラスタのグローバルデバイスにアクセスする API は、ローカルのデバイスにアクセスする API と同じです。

Sun Cluster グローバルデバイスには、ディスク、CD-ROM、テープが含まれます。ただし、サポートされるマルチポートのグローバルデバイスはディスクだけです。つまり、CD-ROM とテープは、現在可用性の高いデバイスではありません。各サーバーのローカルディスクも多重ポート化されていないため、可用性の高いデバイスではありません。

クラスタは、クラスタ内の各ディスク、CD-ROM、テープデバイスに一意の ID を割り当てます。この割り当てによって、クラスタ内の任意のノードから各デバイスに対して一貫したアクセスが可能になります。

デバイス 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 つのノードに構成して、後で自動的に元のノードや別のノードに構成できる 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 の制御

クラスタ上で動作する各アプリケーションおよびサービスには、それぞれ固有の 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 を使用すると、データをグラフィック形式で視覚化できます。監視することを選択したシステムリソースは、ユーザーが視覚化できるデータを決定します。