test

Sun Cluster の概要 (Solaris OS 版)

第 2 章 Sun Cluster の主要な概念

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

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

クラスタノード

クラスタノードは、Solaris ソフトウェアと Sun Cluster ソフトウェアが共に動作しているマシンです。 Sun Cluster ソフトウェアは、2 から 8 ノードのクラスタをサポートします。

クラスタノードは通常、1 つ以上のディスクに接続されます。 ディスクに接続されていないノードは、クラスタファイルシステムを使用して多重ホストディスクにアクセスします。 PDB データベース構成の下にある各ノードは、一部またはすべてのディスクに同時にアクセスします。

クラスタ内のすべてのノードは、別のノードがいつクラスタに参加したか、またはクラスタから切り離れたかを認識します。 さらに、クラスタ内のすべてのノードは、ローカルに実行されているリソースだけでなく、他のクラスタノードで実行されているリソースも認識します。

同じクラスタ内の各ノードの CPU 処理、メモリー、および入出力性能が同等で、パフォーマンスを著しく低下させることなくフェイルオーバーを行うことができることを確認してください。 フェイルオーバーの可能性があるため、各ノードには、ノードの障害時にもサービスレベル合意を満たせる十分な容量を持つ必要があります。

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

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

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

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

クラスタメンバーシップ

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

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

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

クラスタが複数の独立したクラスタに分割されないように防止する方法については、データの完全性を参照してください。

クラスタ構成レポジトリ

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

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

フォルトモニター

Sun Cluster システムでは、アプリケーションそのものや、ファイルシステム、ネットワークインタフェースを監視することによって、ユーザーとデータ間の「パス」にあるすべてのコンポーネントの高い可用性を保ちます。

Sun Cluster ソフトウェアは、ノードを素早く検知し、そのノードと同等のリソースを備えたサーバーを作成します。 Sun Cluster ソフトウェアのおかげで、障害のあるノードの影響を受けないリソースはこの復旧中も引き続き使用され、障害のあるノードのリソースは復旧すると同時に再び使用可能になります。

データサービス監視

Sun Cluster の各データサービスには、データサービスを定期的に検査してその状態を判断するフォルトモニターがあります。 フォルトモニターは、アプリケーションデーモンが動作しているかどうかや、クライアントにサービスが提供されているかどうかを検証します。 検査によって、返された情報に基づいて、デーモンの再起動やフェイルオーバーの実行など、事前定義されたアクションをとることができます。

ディスクパス監視

Sun Cluster ソフトウェアは、ディスクパス監視 (DPM) がサポートします。 DPM は、二次ディスクパスの障害を報告することによって、フェイルオーバーやスイッチオーバーの全体的な信頼性を高めます。 ディスクパスの監視には 2 つの方法があります。 1 つめの方法は scdpm コマンドを使用する方法です。 このコマンドを使用すると、クラスタ内のディスクパスの状態を監視、監視解除、または表示できます。 コマンド行オプションの詳細については、scdpm(1M)のマニュアルページを参照してください。

2 つめの方法は、SunPlex Manager の GUI (Graphical User Interface) を使用してクラスタ内のディスクパスを監視する方法です。 SunPlex Manager では、監視されているディスクパスがトポロジで表示されます。 このトポロジビューは 10 分ごとに更新され、失敗した ping の数が表示されます。

IP マルチパス監視

各クラスタノードには独自の IPMP 構成があり、これは他のクラスタノード上の構成と異なる場合があります。 IPMP は、次のネットワークの通信障害を監視します。

クォーラムデバイス

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

クラスタノードとクォーラムデバイスはどちらも、定足数を確立するために投票します。 デフォルトにより、クラスタノードは、起動してクラスタメンバーになると、定足数投票数 (quorum vote count) を 1 つ獲得します。 ノードは、ノードのインストール中や管理者がノードを保守状態にした時には、投票数は 0 になります。

クォーラムデバイスは、デバイスへのノード接続の数に基づいて投票数を獲得します。 クォーラムデバイスは、設定されると、最大投票数 N-1 を獲得します。この場合、N は、投票数がゼロ以外で、クォーラムデバイスへ接続された投票数を示します。 たとえば、2 つのノードに接続された、投票数がゼロ以外のクォーラムデバイスの投票数は 1 (2-1) になります。

データの完全性

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

クラスタのパーティション分割によって起こる問題 に split-brain と amnesia があります。 split-brain が起こるのは、ノード間のクラスタインターコネクトが失われ、クラスタがサブクラスタにパーティション分割され、各サブクラスタが唯一のパーティションであると認識する場合です。 ほかのサブクラスタの存在を認識していないサブクラスタは、ネットワークアドレスの重複やデータ破損など、共有リソースの対立を引き起こすおそれがあります。

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 や amnesia の問題を防止する方法を示します。

表 2–1 クラスタ定足数、および split-brain と amnesia の問題

問題 

定足数による解決策 

split brain 

過半数の投票を獲得したパーティション (サブクラスタ) だけをクラスタとして実行できるようにする (過半数を獲得できるパーティションは 1 つのみ)。 ノードが定足数を獲得できないと、ノードはパニックになります。  

amnesia  

起動されたクラスタには、最新のクラスタメンバーシップのメンバーであった (したがって、最新の構成データを持つ) ノードが少なくとも 1 つあることを保証する。  

ニ重障害の防止

クラスタにとって重大な問題は、クラスタがパーティション分割される (sprit-brain と呼ばれる) 原因となる障害です。 このような状態になると、一部のノードが通信できなくなるため、個々のノードまたはノードの一部が、ノード単体または一部のノードによってクラスタを形成しようとします。 各部分、つまりパーティションは、マルチホストディスクに対して単独のアクセスと所有権を持つものと誤って「認識する」ことがあります。 しかし、複数のノードがディスクに書き込もうとすると、データ破損を招くおそれがあります。

二重障害の防止機能は、ディスクへのアクセスを防止することによってノードがマルチホストディスクにアクセスすることを制限します。 障害が発生するかパーティション分割され、ノードがクラスタから切り離れると、二重障害の防止機能によって、ノードがディスクにアクセスできなくなります。 現在のメンバーノードだけが、ディスクへのアクセス権を持つため、データの完全性が保たれます。

Sun Cluster システムは、SCSI ディスクリザベーションを使用して、二重障害の防止機能を実装します。 SCSI リザベーションを使用すると、障害が発生したノードは、ディスクへのアクセスを防止されることによってマルチホストディスクへのアクセスを阻止します。

クラスタメンバーは、別のノードがクラスタインターコネクトを介して通信していないことを検出すると、二重障害の防止手順を開始して、障害のあるそのノードが共有ディスクへアクセスするのを防止します。 この二重障害の防止機能が動作すると、アクセスを阻止されたノードはパニック状態になり、そのコンソールに「reservation conflict」メッセージが表示されます。

二重障害の防止に対するフェイルファースト機構

フェイルファースト機構は、障害のノードをパニック状態にしますが、そのノードの再起動を防ぐことはしません。 パニックの後にこのノードは再起動を行ない、クラスタに再び参加しようとすることがあります。

クラスタ内の他のノードとの接続性を失ったノードが、定足数を達成可能なパーティションに参加していない場合、そのノードは別のノードによってクラスタから強制的に切り離されます。 定足数を達成可能なパーティションに参加している別のノードが、共有ディスクにリザベーションを発行します。 フェイルファースト機構の結果、定足数を満たしていないノードはパニック状態になります。

デバイス

グローバルファイルシステムでは、クラスタのすべてのファイルがすべてのノードから同じように認識され、アクセス可能になります。 それと同様に、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 や Sun Java System Directory Server など、ディスクにアクセスするアプリケーションが何であれ、クラスタ全体で一貫性のあるパスが使用されます。 多重ホストディスクの場合は、この一貫性がとりわけ重要です。各デバイスのローカルのメジャー番号とマイナー番号はノードによって異なる可能性があるからです。 さらに、これらの数字は、Solaris デバイスの命名規約も同様に変更する可能性があります。

ローカルデバイス

Sun Cluster ソフトウェアはローカルデバイスも管理します。 このようなデバイスは、サービスが動作しているノードだけでアクセスされるものであり、クラスタに物理的に接続されています。 ローカルデバイスは、性能の点でグローバルデバイスよりも有利です。ローカルデバイスでは、状態情報を複数のノードに同時に複製する必要がないからです。 デバイスのドメインに障害が発生すると、そのデバイスにはアクセスできなくなります。ただし、そのデバイスを複数のノードで共有できる場合を除きます。

ディスクデバイスグループ

ディスクデバイスグループでは、ボリュームマネージャのディスクグループが「グローバル」になります。ボリュームマネージャは、使用しているディスクに対してマルチパスとマルチホストをサポートするからです。 マルチホストディスクに物理的に接続された各クラスタノードは、ディスクデバイスグループへのパスを提供します。

Sun Cluster システムでは、マルチホストディスクをディスクデバイスグループとして登録することにより、これを Sun Cluster ソフトウェアの制御下に置くことができます。 この登録によって、Sun Cluster システムは、どのノードがどのボリュームマネージャディスクグループへのパスをもっているかを知ることができます。 Sun Cluster ソフトウェアは、クラスタ内のディスクデバイスやテープデバイスごとに、raw ディスクデバイスグループを作成します。 これらのクラスタデバイスグループは、ユーザーがグローバルファイルシステムをマウントするか、raw データベースファイルにアクセスすることによって、これらのデバイスグループをグローバルデバイスとしてアクセスするまでオフライン状態に置かれます。

データサービス

データサービスは、Sun Cluster 構成の下でアプリケーションを変更なしで実行できるようにする、ソフトウェアと構成ファイルの組み合わせです。 Sun Cluster 構成の下で動作するアプリケーションは、リソースグループマネージャ (RGM) の制御下にある 1 つのリソースです。 データサービスを使えば、Sun Java System Web Server や Oracle データベースなどのアプリケーションをクラスタで (単一のサーバーではなく) 実行するように構成できます。

データサービスのソフトウェアは、アプリケーションに対して次の操作を行う Sun Cluster 管理メソッドを実装しています。

データサービスの構成ファイルは、RGM にとってアプリケーションを意味するリソースのプロパティを定義したものです。

クラスタのフェイルオーバーデータサービスやスケーラブルデータサービスの処理は RGM によって制御されます。 RGM は、クラスタメンバーシップの変更に応じて選択されたクラスタのノードでデータサービスの起動や停止を行います。 データサービスアプリケーションは、RGM を通してクラスタフレームワークを利用できます。

RGM はデータサービスをリソースとして制御します。 これらの実装は Sun によって提供されるか、開発者によって作成されます。後者の場合には、汎用的なデータサービステンプレートや、 データサービス開発ライブラリ API (DSDL API)、リソース管理 API (RMAPI) が使用されます。 クラスタ管理者は、リソースグループと呼ばれる入れ物 (コンテナ) の中でリソースの作成や管理を行います。 リソースやリソースグループの状態は、RGM や管理者のアクションによってオンラインやオフラインにされます。

リソースタイプ

リソースタイプは、クラスタに対してアプリケーションを定義するプロパティの集合です。 この集合には、クラスタのノードでアプリケーションをどのように起動、停止、監視するかを示す情報が含まれています。 さらに、リソースタイプには、アプリケーションをクラスタで使用するために必要なアプリケーション固有のプロパティも含まれています。 Sun Cluster データサービスには、いくつかのリソースタイプが事前に定義されています。 たとえば、Sun Cluster HA for Oracle のリソースタイプは SUNW.oracle-server、Sun Cluster HA for Apache のリソースタイプ SUNW.apache です。

リソース

リソースは、クラスタ規模で定義されたリソースタイプの 1 つの実態 (インスタンス) です。 リソースタイプを使用することによって、アプリケーションの複数のインスタンスをクラスタにインストールすることが可能になります。 ユーザーがリソースを初期化すると、RGM は、アプリケーション固有のプロパティに値を割り当てます。リソースは、リソースタイプのレベルにあるすべてのプロパティを継承します。

データサービスは、いくつかのタイプのリソースを使用します。 たとえば、Apache Web Server や Sun Java System Web Server などのアプリケーションは、それらが依存するネットワークアドレス (論理ホスト名と共有アドレス) を使用します。 アプリケーションとネットワークリソースは、RGM が管理する基本ユニットを形成します。

リソースグループ

RGM が管理するリソースはリソースグループに入れられ、1 つの単位として管理されます。 1 つのリソースグループは、関連したリソースや独立したリソースからなります。 たとえば、SUNW.LogicalHostname リソースタイプから派生したリソースは、Oracle データベースリソースタイプから派生したリソースと同じリソースグループに置かれることがあります。 リソースグループ上でフェイルオーバーまたはスイッチオーバーが開始されると、リソースグループは 1 つの単位として移行されます。

データサービスの型

データサービスを使用すると、アプリケーションは可用性の高いものやスケーラブルなサービスになります。クラスタで単一の障害が発生した場合、大幅なアプリケーションの中断を回避できます。

データサービスを構成する際には、次のデータサービスの型から 1 つを選択する必要があります。

フェイルオーバーデータサービス

フェイルオーバーとは、クラスタがアプリケーションを障害のある稼動系から、指定の冗長化された待機系に自動的に再配置するプロセスのことをいいます。 フェイルオーバーアプリケーションには、次の特徴があります。

フォルトモニターは、エラーを検知すると、データサービスの構成に従って、同じノードでそのインスタンスを再起動しようとするか、別のノードでそのインスタンスを起動 (フェイルオーバー) しようとします。 フェイルオーバーサービスは、アプリケーションインスタンスリソースとネットワークリソース (論理ホスト名) のコンテナである、フェイルオーバーリソースグループを使用します。 論理ホスト名とは、1 つのノードに構成して、後で自動的に元のノードや別のノードにホストできる IP アドレスのことです。

サービスが一時的に中断されるため、クライアントは、フェイルオーバーの完了後にサービスに再接続しなければならない場合があります。 しかし、クライアントは、サービスの提供元である物理サーバーが変更したことを意識しません。

スケーラブルデータサービス

スケーラブルデータサービスでは、複数のアプリケーションインスタンスが複数のノードで同時に動作します。 スケーラブルサービスは、2 つのリソースグループを使用します。 スケーラブルリソースグループにはアプリケーションリソースが、フェイルオーバーリソースグループには、スケーラブルサービスが依存するネットワークリソース (共有アドレス) がそれぞれ含まれています。 スケーラブルリソースグループは、複数のノードでオンラインにできるため、サービスの複数のインスタンスを同時に実行できます。 共有アドレスのホストとなるフェイルオーバーリソースグループは、同時に 1 つのノードでしかオンラインにできません。 スケーラブルサービスをホストとするすべてのノードは、サービスをホストするための同じ共有アドレスを使用します。

クラスタは、同一のネットワークインタフェース (グローバルインタフェース) を通してサービス要求を受け取ります。 これらの要求は、事前に定義されたいくつかのアルゴリズムの 1 つに基づいてノードに分配されます (アルゴリズムはロードバランシングポリシーによって設定される)。 クラスタは、ロードバランシングポリシーを使用し、いくつかのノード間でサービスのロードバランシングをとることができます。

パラレルアプリケーション

Sun Cluster システムは、パラレルデータベース (PDB) を使用することによってクラスタのすべてのノードでアプリケーションを並列で実行できるようにする環境を提供します。 Sun Cluster Support for Oracle Parallel Server/Real Application Clusters は、Oracle Parallel Server/Real Application Clusters を Sun Cluster ノードで実行できるようにするパッケージ群です。 さらに、このデータサービスでは、Sun Cluster コマンドを使って Sun Cluster Support for Oracle Parallel Server/Real Application Clusters を管理できます。

パラレルアプリケーションはクラスタ環境で動作するように考えられたものです。したがって、このようなアプリケーションは、複数のノードから同時マスターされます。 Oracle Parallel Server/Real Application Clusters 環境では、複数の Oracle インスタンスが協力して同じ共有データベースにアクセスします。 Oracle クライアントは、任意のインスタンスを使用してデータベースにアクセスできます。 したがって、1 つまたは複数のインスタンスで障害が発生しても、クライアントは残りのインスタンスに接続することによって、引き続きデータベースにアクセスできます。