test

Sun Cluster 3.0 の概念

第 3 章 重要な概念 - 管理とアプリケーション開発

この章では、Sun Cluster 構成のソフトウェアコンポーネントに関連する重要な概念について説明します。次のトピックについて述べます。

クラスタ管理とアプリケーション開発

この情報は、主に、Sun Cluster API および SDK を使用するシステム管理者とアプリケーション開発者を対象としています。クラスタシステムの管理者にとっては、この情報は、クラスタソフトウェアのインストール、構成、管理についての予備知識となります。アプリケーション開発者は、この情報を使用して、作業を行うクラスタ環境を理解できます。

次の図は、クラスタ管理の概念がクラスタの構造にどのように対応するかを示しています。

図 3-1 Sun Cluster ソフトウェアの構造

Graphic

管理インタフェース

任意のユーザーインタフェースを使用し、Sun Cluster および Sun Cluster データサービスをインストール、構成、管理できます。システム管理作業は、コマンド行インタフェースで行えます。コマンド行インタフェースには、構成作業を簡略化するユーティリティがあります。Sun Cluster には、Sun Management Center の一部として実行される、特定のクラスタ作業に GUI を提供するモジュールもあります。管理インタフェースの詳細については、『Sun Cluster 3.0 のシステム管理』の概要を説明する章を参照してください。

クラスタ内の時間

クラスタ内のすべてのノード間の時刻は同期をとる必要があります。クラスタノードの時刻と外部の時刻ソースの同期をとるかどうかは、クラスタの操作にとって重要ではありません。Sun Cluster は、Network Time Protocol (NTP) を使用して、ノード間のクロックの同期をとっています。

通常、システムクロックが数分の 1 秒程度変更されても問題は起こりません。しかし、システムクロックと時刻の起点の同期をとるために、date(1)、rdate(1M)、xntpdate(1M) を (対話形式または cron スクリプト内で) アクティブクラスタに対して実行すると、これよりも大幅に時刻変更が可能です。この強制的な変更は、ファイル修正時刻の表示に問題が生じたり、NTP サービスに混乱が生じる場合があります。

Solaris オペレーティング環境を各クラスタノードにインストールする場合は、ノードのデフォルトの時刻と日付の設定を変更できます。通常は、工場出荷時のデフォルト値を使用します。

scinstall(1M) を使用して Sun Cluster をインストールする場合、インストールプロセスの手順の 1 つとして、クラスタの NTP を構成します。Sun Cluster は、テンプレートファイル ntp.cluster を提供します (インストールされたクラスタノードの /etc/inet/ntp.cluster を参照)。これは、1 つのノードを優先ノードにし、すべてのクラスタノード間で対等関係を確立します。ノードは、そのプライベートホスト名によって識別され、時刻の同期化はクラスタインターコネクト全体で発生します。NTP のクラスタを構成する方法については、『Sun Cluster 3.0 ソフトウェアのインストール』を参照してください。

また、クラスタの外部に 1 つまたは複数の NTP サーバーを設定し、ntp.conf ファイルを変更してその構成を反映させることもできます。

通常の操作では、クラスタの時刻を調整する必要はありません。ただし Solaris オペレーティング環境をインストールしたときに時刻が正しく設定されておらず、変更する必要がある場合は、『Sun Cluster 3.0 ソフトウェアのインストール』を参照してください。

高可用性フレームワーク

Sun Cluster では、ネットワークインタフェース、アプリケーションそのもの、ファイルシステム、および多重ホストディスクなど、ユーザーとデータ間のパスにおけるすべてのコンポーネントの可用性が高くなっています。一般に、クラスタコンポーネントは、システムで単一 (ソフトウェアまたはハードウェア) の障害が発生しても稼働し続けられる場合は可用性が高くなります。

次の表は、Sun Cluster コンポーネントの障害の種類 (ハードウェアとソフトウェアの両方) と、高可用性フレームワークに組み込まれた回復の種類を示しています。

表 3-1 Sun Cluster の障害の検出と回復のレベル

障害が発生したクラスタリソース 

ソフトウェアの回復 

ハードウェアの回復 

データサービス 

HA API、HA フレームワーク 

なし 

パブリックネットワークアダプタ 

ネットワークアダプタのフェイルオーバー (NAFO) 

複数のパブリックネットワークアダプタカード 

クラスタファイルシステム 

主複製と二次複製 

多重ホストディスク 

ミラー化された多重ホストディスク 

ボリューム管理 (Solstice DiskSuite および VERITAS Volume Manager) 

ハードウェア RAID-5 (Sun StorEdge A3x00 など) 

広域デバイス 

主複製と二次複製 

デバイス、クラスタトランスポート接続点への多重パス 

プライベートネットワーク 

HA トランスポートソフトウェア 

ハードウェアから独立した多重プライベートネットワーク 

ノード 

CMM、failfast ドライバ 

複数ノード 

Sun Cluster の高可用性フレームワークは、ノードの障害を素早く検出して、クラスタ内の残りのノードにあるフレームワークリソース用に新しい同等のサーバーを作成します。すべてのフレームワークリソースが使用できなくなるときはありません。障害が発生したノードによって影響を受けないフレームワークリソースは、回復中も完全に使用できます。さらに、障害が発生したノードのフレームワークリソースは、回復されると同時に使用可能になります。回復されたフレームワークリソースは、他のすべてのフレームワークリソースが回復するまで待機する必要はありません。

最も可用性の高いフレームワークリソースは、リソースを使用してアプリケーション (データサービス) に透過的に回復されます。フレームワークリソースのアクセス方式は、ノードの障害時にも完全に維持されます。アプリケーションは、フレームワークリソースサーバーが別のノードに移動したことを認識できないだけです。単一ノードの障害は、別ノードからのディスクに対する代替ハードウェアパスが存在するかぎり、ファイル、デバイス、およびディスクボリュームを使用する残りのノード上のプログラムに対して完全に透過的です。この例としては、複数ノードへのポートを持つ多重ホストディスクの使用があります。

クラスタメンバーシップモニター

クラスタメンバーシップモニター (CMM) は、エージェントの分散型セットであり、クラスタメンバーごとに 1 つあります。これらのエージェントは、クラスタインターコネクトによってメッセージを交換して、次のことを行います。

Sun Cluster の前のリリースとは異なり、CMM は完全にカーネルで実行されます。

クラスタメンバーシップ

CMM の主な機能は、特定の時刻にクラスタに属するノードの集合に対して、クラスタ全体の同意を確立することです。Sun Cluster は、この制約をクラスタメンバーシップと呼びます。

クラスタメンバーシップを決定して、最終的にデータの完全性を保証するために、CMM は次のことを行います。

クラスタが複数の独立したクラスタに分割されないように防止する方法については、「定足数と定足数デバイス」を参照してください。

クラスタメンバーシップモニターの再構成

データが破壊から保護されるように保証するには、すべてのノードが、クラスタメンバーシップに対して一定の同意に達していなければなりません。必要であれば、CMM は、障害に応じてクラスタサービス (アプリケーション) のクラスタ再構成を調整します。

CMM は、クラスタのトランスポート層から、他のノードへの接続に関する情報を受け取ります。CMM は、クラスタインターコネクトを使用して、再構成中に状態情報を交換します。

CMM は、クラスタメンバーシップの変更を検出すると、クラスタの同期化構成を実行します。これにより、クラスタリソースは、クラスタの新しいメンバーシップに基づいて再分配されます。

クラスタ構成レポジトリ (CCR)

クラスタ構成レポジトリ (CCR) は、クラスタの構成と状態に関する情報を保存するための、プライベートなクラスタ全体のデータベースです。CCR は分散データベースです。各ノードは、このデータベースの完全なコピーを維持します。CCR は、すべてのノードで、クラスタ全体の一貫した表示が行われるように保証します。データの破壊を避けるために、各ノードは、クラスタリソースの現在の状態を知る必要があります。

CCR は、可用性の高いサービスとしてカーネルに実装されます。

CCR は、更新に 2 フェーズのコミットアルゴリズムを使用します。更新はすべてのクラスタメンバーで正常に終了しなければなりません。そうしないと、その更新はロールバックされます。CCR はクラスタインターコネクトを使用して、分散更新を適用します。

注意 - 注意 -

CCR はテキストファイルから構成されますが、CCR ファイルは決して手作業で編集しないでください。各ファイルには、一貫性を保証するための検査合計レコードが含まれます。CCR ファイルを手作業で更新すると、ノードまたはクラスタ全体の機能が停止する可能性があります。

CCR は、CMM に依存して、定足数 (quorum) が確立された場合にのみクラスタが実行されるように保証します。CCR は、クラスタ全体のデータの一貫性を確認し、必要に応じて回復を実行し、データへの更新を容易にします。

広域デバイス

Sun Cluster は、広域デバイスを使用して、デバイスが物理的に接続されている場所に関係なく、任意のノードからクラスタ内のすべてのデバイスに対して、クラスタ全体の可用性の高いアクセスを可能にします。通常、広域デバイスへのアクセスを提供しているときにノードに障害が発生すると、Sun Cluster はそのデバイスへの別のパスを自動的に検出して、そのパスにアクセスを切り替えます。Sun Cluster 広域デバイスには、ディスク、CD-ROM、テープが含まれます。ディスクは、唯一サポートされている多重ポート広域デバイスです。つまり、CD-ROM とテープは、現在可用性の高いデバイスではありません。各サーバーのローカルディスクも多重ポート化されていないため、可用性の高いデバイスではありません。

クラスタは、クラスタ内の各ディスク、CD-ROM、テープデバイスに一意の ID を自動的に割り当てます。この割り当てによって、クラスタ内の任意のノードから各デバイスに対して一貫したアクセスが可能になります。広域デバイス名前空間は、/dev/global ディレクトリにあります。詳細については、「広域名前空間」を参照してください。

多重ポート広域デバイスは、1 つのデバイスに対して複数のパスを提供します。多重ホストディスクの場合、ディスクは複数のノードがホストとなるディスクデバイスグループの一部であるため、多重ホストディスクの可用性は高くなります。

デバイス ID (DID)

Sun Cluster は、デバイス ID (DID) 擬似ドライバと呼ばれる構造によって広域デバイスを管理します。このドライバは、多重ホストディスク、テープドライブ、CD-ROM を含むクラスタ内のすべてのデバイスに対して、一意の ID を自動的に割り当てるために使用されます。

デバイス ID (DID) 擬似ドライバは、クラスタの広域デバイスアクセス機能の重要な部分です。DID ドライバは、クラスタのすべてのノードを探索して、一意のディスクデバイスのリストを作成し、それぞれに対して、クラスタのすべてのノードで一貫した一意のメジャー番号およびマイナー番号を割り当てます。広域デバイスへのアクセスは、ディスクを示す c0t0d0 などの従来の Solaris デバイス ID ではなく、DID ドライバによって割り当てられた一意のデバイス ID を利用して行われます。

この方法により、ディスクデバイスを利用するすべてのアプリケーション (ボリューム管理ソフトウェアまたは raw デバイスを使用するアプリケーション) が、一貫したパスを使用してデバイスにアクセスできます。各デバイスのローカルメジャー番号およびマイナー番号はノードによって異なり、Solaris デバイス命名規則も変更する可能性があるため、この一貫性は、多重ホストディスクにとって特に重要です。たとえば、ノード 1 は多重ホストディスクを c1t2d0 と表示し、同じディスクをノード 2 は c3t2d0 と表示する場合があります。DID ドライバは、そのノードが代わりに使用する d10 などの広域名を割り当てて、各ノードに対して多重ホストディスクとの一貫したマッピングを与えます。

デバイス ID は、scdidadm(1M) および scgdevs(1M) によって更新、管理します。詳細については、それぞれのマニュアルページを参照してください。

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

Sun Cluster では、すべての多重ホストディスクが、Sun Cluster フレームワークの制御のもとになければなりません。まず、ボリューム管理ソフトウェアのディスクグループ (Solstice DiskSuite ディスクセットか、VERITAS Volume Manager ディスクグループのどちらか) を多重ホストディスクに作成します。次に、ボリューム管理ソフトウェアのディスクグループを Sun Clusterのディスクデバイスグループとして登録します。ディスクデバイスグループは、広域デバイスの一種です。さらに、Sun Cluster は、個々のディスクすべてをディスクデバイスグループとして割り当てます。

注 -

ディスクデバイスグループは、リソースグループとは別のものです。あるノードが 1 つのリソースグループ (データサービスプロセスのグループを表す) をマスターする一方で、別のノードが、データサービスによってアクセスされるディスクグループをマスターできます。ただし、最も良い方法は、特定のアプリケーションのデータを保存するディスクデバイスグループと、アプリケーションのリソース (アプリケーションデーモン) を同じノードに含むリソースグループを維持することです。ディスクデバイスグループとリソースグループの関連付けの詳細については、『Sun Cluster 3.0 データサービスのインストールと構成』の概要を示す章を参照してください。

ディスクデバイスグループでは、ボリューム管理ソフトウェアのディスクグループは実際に使用するディスクに対してマルチパスサポートを提供するため、広域になります。多重ホストディスクに物理的に接続された各クラスタノードは、ディスクデバイスグループへのパスを提供します。

注 -

広域デバイスは、複数のクラスタノードがホストとなるデバイスグループの一部である場合、可用性が高くなります。

ディスクデバイスフェイルオーバー

ディスク格納装置は複数のノードに接続されるため、現在デバイスグループをマスターしているノードに障害が生じた場合、その格納装置にあるすべてのディスクデバイスグループには、代替パスによってアクセスできます。デバイスグループをマスターするノードの障害は、回復と一貫性の検査を実行するために要する時間を除けば、デバイスグループへのアクセスに影響しません。この時間中、デバイスグループが使用可能になるまで、すべての要求は (アプリケーションには透過的に) 阻止されます。

図 3-2 ディスクデバイスグループのフェイルオーバー

Graphic

広域名前空間

広域デバイスを有効にする Sun Cluster の機構は、広域名前空間です。広域名前空間には、ボリューム管理ソフトウェアの名前空間とともに、/dev/global/ 階層が含まれます。広域名前空間は、多重ホストディスクとローカルディスクの両方 (および CD-ROM やテープなどの他のクラスタデバイスすべて) を反映して、多重ホストディスクへの複数のフェイルオーバーパスを提供します。多重ホストディスクに物理的に接続された各ノードは、クラスタ内のすべてのノードの記憶装置に対するパスを提供します。

通常、ボリューム管理ソフトウェアの名前空間は、Solstice DiskSuite の場合、/dev/md/diskset/dsk および /dev/md/diskset/rdsk ディレクトリにあります。また、VxVM の場合は、/dev/vx/dsk/disk-group および /dev/vx/rdsk/disk-group の各ディレクトリにあります。これらの名前空間は、それぞれクラスタを介してインポートされた各 Solstice DiskSuite ディスクセットと各 VxVM ディスクグループのディレクトリからなります。これらの各ディレクトリには、そのディスクセットまたはディスクグループ内の各メタデバイスまたはボリュームのデバイスノードが入っています。

Sun Cluster では、ローカルのボリューム管理ソフトウェアの名前空間の各デバイスノードが、/global/.devices/node@nodeID ファイルシステム内のデバイスノードに対するシンボリックリンクによって置き換えられています。ここで、nodeID は、クラスタ内のノードを表す整数になります。Sun Cluster は、その標準的な場所に引き続きシンボリックリンクとしてボリューム管理ソフトウェアデバイスも表示します。広域名前空間と標準ボリューム管理ソフトウェア名前空間の両方を任意のクラスタノードから使用できます。

広域名前空間には、次の利点があります。

ローカル名前空間と広域名前空間の例

次の表は、多重ホストディスク c0t0d0s0 でのローカル名前空間と広域名前空間のマッピングを示しています。

表 3-2 ローカル名前空間と広域名前空間のマッピング

コンポーネント/パス 

ローカルノード名前空間 

広域名前空間 

Solaris 論理名 

/dev/dsk/c0t0d0s0

/global/.devices/node@ID/dev/dsk/c0t0d0s0

DID 名 

/dev/did/dsk/d0s0

/global/.devices/node@ID/dev/did/dsk/d0s0

Solstice DiskSuite 

/dev/md/diskset/dsk/d0

/global/.devices/node@ID/dev/md/diskset/dsk/d0

VERITAS Volume Manager 

/dev/vx/dsk/disk-group/v0

/global/.devices/node@ID/dev/vx/dsk/disk-group/v0

広域名前空間はインストール時に自動的に生成されて、再構成再起動のたびに更新されます。広域名前空間は、scgdevs(1M) コマンドを実行することでも生成できます。

クラスタファイルシステム

クラスタファイルシステムは、1 つのノード上のカーネル、配下のファイルシステムおよびディスクへの物理接続を持つノードで実行されるボリューム管理ソフトウェアとの間のプロキシです。

クラスタファイルシステムは、1 つまたは複数のノードへの物理接続を持つ広域デバイス (ディスク、テープ、CD-ROM) に依存しています。広域デバイスは、ノードが記憶装置への物理接続を持つかどうかに関係なく、同じファイル名 (たとえば、/dev/global/) によってクラスタ内のすべてのノードからアクセスできます。広域デバイスは通常のデバイスと同様に使用できます。つまり、newfs または mkfs、あるいはこの両方を使用し、ファイルシステムを作成できます。

広域デバイスには、mount -g を使用して広域に、または mount を使用してローカルにファイルシステムをマウントできます。プログラムは、同じファイル名 (たとえば、/global/foo) によって、クラスタ内のすべてのノードからクラスタファイルシステムのファイルにアクセスできます。クラスタファイルシステムは、すべてのクラスタメンバーにマウントされます。クラスタファイルシステムをクラスタメンバーのサブセットにマウントすることはできません。

クラスタファイルシステムの使用法

Sun Cluster では、すべての多重ホストディスクがディスクデバイスグループとして構成されています。これは、Solstice DiskSuite ディスクセット、VxVM ディスクグループ、またはソフトウェアベースのボリューム管理ソフトウェアの制御下にない個々のディスクが該当します。また、ローカルディスクも、パスが各ノードから各ローカルディスクにつながるという点で、ディスクデバイスグループとして構成されています。この設定では、すべてのノードからディスク上のデータを利用できるとは限りません。データは、ディスク上のファイルシステムがクラスタファイルシステムとして広域にマウントされた場合にのみ、すべてのノードに利用可能になります。

クラスタファイルシステムに組み込まれたローカルファイルシステムには、ディスク記憶装置への単一の接続だけがあります。ディスク記憶装置への物理接続を持つノードに障害が生じると、他のノードからクラスタファイルシステムへのアクセスが不可能になります。また、他のノードから直接アクセスできない単一ノードにローカルファイルシステムを置くこともできます。

HA データサービスは、サービス用のデータが、クラスタファイルシステム内のディスクデバイスグループに保存されるように設定されています。この設定にはいくつかの利点があります。まず、データの可用性が高くなります。つまり、ディスクは多重ホスト化されているため、現在の主ノードからのパスに障害が発生した場合、アクセスは同じディスクへの直接アクセスを持つ別のノードに切り替えられます。次に、データはクラスタファイルシステムにあるため、任意のクラスタノードから直接表示できます。現在ディスクデバイスグループをマスターしているノードにログインしてデータを表示する必要はありません。

プロキシファイルシステム (PXFS)

クラスタファイルシステムは、プロキシファイルシステム (PXFS) に基づいています。これには、次の機能があります。

PXFS は、明確なファイルシステム形式ではありません。つまり、クライアントには、実際のファイルシステム (たとえば UFS) が表示されます。

クラスタファイルシステムの独立性

クラスタファイルシステムは、実際のファイルシステムおよびボリューム管理ソフトウェアに依存していません。現在、クラスタファイルシステムは、Solstice DiskSuite または VERITAS Volume Manager のどちらかを使用して、UFS で作成できます。

通常のファイルシステムと同様、クラスタファイルシステムは 2 つの方法でマウントできます。

注 -

Sun Cluster には、クラスタファイルシステムの命名ポリシーはありませんが、/global/disk-device-group など、同じディレクトリのもとにすべてのクラスタファイルシステムのマウントポイントを作成すると、管理が簡単になります。詳細については、『Sun Cluster 3.0 ソフトウェアのインストール』および『Sun Cluster 3.0 のシステム管理』を参照してください。

syncdir マウントオプション

クラスタファイルシステムには、syncdir マウントオプションを使用できますが、syncdir を指定しない方がパフォーマンスは向上します。syncdir を指定すると、POSIX 準拠の書き込みが保証されます。指定しないと、UFS ファイルシステムの場合と同じ動作となります。たとえば、syncdir を指定しないと、場合によっては、ファイルを閉じるまでスペース不足条件を検出できません。syncdir (および POSIX 動作) を指定すると、スペース不足条件は書き込み動作中に検出されます。syncdir を指定しないことで生じる問題はほとんどないため、このオプションを指定しないで、パフォーマンスを向上させることを推奨します。

広域デバイスとクラスタファイルシステムについては、「ファイルシステムに関する FAQ」を参照してください。

定足数と定足数デバイス

クラスタノードはデータとリソースを共有するため、クラスタはデータとリソースの完全性を維持するための手順に従う必要があります。あるノードがメンバーシップに関するクラスタの規則に合致しない場合、クラスタは、そのノードがクラスタに属するのを禁止する必要があります。

Sun Cluster では、クラスタへのノードの結合を判断する機構を定足数 (quorum) と呼びます。Sun Cluster は、多数決のアルゴリズムを使用して定足数を実装します。クラスタノードと定足数デバイス は、どちらも複数のノード間で共有されるディスクであり、定足数を確立するために投票 (vote) します。定足数デバイスにはユーザーデータを含むことができます。

定足数アルゴリズムは動的に動作します。クラスタイベントによってその計算が発生した場合、計算結果はクラスタの存続期間中、変化し続けます。定足数は、split-brain と amnesia という 2 つのクラスタの問題を防止します。どちらも、一貫性のないデータがクライアントに提示される原因となる可能性があります。次の表は、これらの 2 つの問題と、定足数によるその解決方法を説明しています。

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

問題 

説明 

定足数による解決策 

split brain 

ノード間のクラスタインターコネクトが失われてクラスタがサブクラスタに分割され、それぞれが唯一のパーティションであると誤って認識した場合に発生する 

過半数の投票があるパーティション (サブクラスタ) だけが、クラスタとして実行できるようにする (1 つのパーティションだけが、このような過半数によって存在できる) 

amnesia 

停止時よりも古いクラスタデータを使用して、停止後にクラスタが再起動すると発生する 

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

定足数投票数

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

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

定足数デバイスは、クラスタのインストール中、または『Sun Cluster 3.0 のシステム管理』で説明している手順を使用して後で構成します。

注 -

定足数デバイスは、現在接続されている少なくとも 1 つのノードがクラスタメンバーである場合にのみ、投票数を獲得します。また、クラスタの起動中、定足数デバイスは、現在接続されている少なくとも 1 つのノードが起動中で、その停止時に最も最近起動されたクラスタのメンバーであった場合にのみ投票数を獲得します。

定足数の構成

定足数 (quorum) の構成は、クラスタ内のノードの数によって異なります。

図 3-3 定足数デバイス構成の例

Graphic

定足数のガイドライン

定足数デバイスを設定するときは、次のガイドラインを使用してください。

ヒント -

ノードの集合間で複数の定足数デバイスを構成してください。異なる格納装置から複数のディスクを使用して、奇数の定足数デバイスをノードの各集合間で構成してください。これにより、個々の定足数デバイスの障害から保護できます。

障害による影響の防止

クラスタの主要な問題は、クラスタがパーティション分割される (sprit-brain と呼ばれる) 原因となる障害です。この障害が発生すると、一部のノードが通信できなくなるため、個々のノードまたはノードの一部が、個々のクラスタまたはクラスタの一部を形成しようとします。各部分、つまりパーティションは、多重ホストディスクに対して単独のアクセスと所有権を持つものと誤って認識します。複数のノードがディスクに書き込もうとすると、データが破壊される可能性があります。

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

ディスクデバイスサービスは、多重ホストディスクを使用するサービスに対して、フェイルオーバー機能を提供します。現在、ディスクデバイスグループの主ノード (所有者) として機能しているクラスタメンバーに障害が発生するか、またはこのメンバーに到達できなくなると、新しい主ノードが選択されて、ディスクデバイスグループへのアクセスが可能になり、わずかな割り込みだけで処理が続行されます。このプロセス中、古い主ノードは、新しい主ノードが起動される前に、デバイスへのアクセスを放棄しなければなりません。ただし、あるメンバーがクラスタから切り離されて到達不能になると、クラスタはそのノードに対して、主ノードであったデバイスを解放するように通知できません。したがって、存続するメンバーが、障害の発生したメンバーから広域デバイスを制御してアクセスできるようにする手段が必要です。

Sun Cluster は、SCSI ディスク予約を使用して、障害による影響の防止機能を実装します。SCSI 予約を使用すると、障害が発生したノードは、多重ホストディスクによって阻止されて、これらのディスクへのアクセスが防止されます。

SCSI-2 ディスク予約は、ある形式の予約をサポートしています。これは、ディスクに接続されたすべてのノードへのアクセスを付与するか (予約が設定されていない場合)、または単一ノード (予約を保持するノード) へのアクセスを制限するものです。

クラスタメンバーは、別のノードがクラスタインターコネクトを介して通信していないことを検出すると、障害による影響の防止手順を開始して、そのノードが共有ディスクへアクセスするのを防止します。この障害による影響の防止機能が実行される場合、通常、阻止されるノードは、そのコンソールに「reservation conflict」(予約の衝突) というメッセージを表示して停止します。

予約の衝突は、ノードがクラスタメンバーではなくなったことが検出された後で、SCSI 予約がこのノードと他のノードの間で共有されるすべてのディスクに対して設定されると発生します。阻止されるノードは阻止されていることを認識しない場合があり、共有ディスクのどれかにアクセスしようとして、予約を検出して停止します。

ボリューム管理ソフトウェア

Sun Cluster は、ボリューム管理ソフトウェアを使用して、ミラーとホットスペアディスクによりデータの可用性を向上させ、ディスクの障害と交換を処理します。

Sun Cluster には、独自の内部ボリューム管理ソフトウェアコンポーネントはありませんが、次のボリューム管理ソフトウェアに依存しています。

クラスタ内のボリューム管理ソフトウェアは、次のものに対するサポートを提供しています。

Sun Cluster でボリューム管理ソフトウェアを設定する場合は、ボリューム管理ソフトウェアのディスクグループのラッパーである Sun Cluster ディスクデバイスとして、多重ホストディスクを構成します。このデバイスは、Solstice DiskSuite ディスクセットまたは VxVM ディスクグループのどちらかにできます。

データサービスに使用されるディスクグループをミラー化用に構成して、クラスタ内でのディスクの可用性を高める必要があります。

メタデバイスまたはプレックスを、raw デバイス (データベースアプリケーション) として、または UFS ファイルシステムの保持用に使用できます。

ボリューム管理オブジェクトのメタデバイスとボリュームは、クラスタの制御下に置かれるため、ディスクデバイスグループになります。たとえば、Solstice DiskSuite では、 (metaset(1M) コマンドを使用して) クラスタにディスクセットを作成すると、同じ名前の対応するディスクデバイスグループが作成されます。さらに、そのディスクセットにメタデバイスを作成すると、それらは広域デバイスになります。したがって、ディスクセットはディスクデバイス (DID デバイス) と、セット内のデバイスすべてのポート先であるホストの集合になります。クラスタ内のすべてのディスクセットを、セット内の複数のホストによって作成して、HA を実現する必要があります。同様の状態は、VERITAS Volume Manager を使用した場合にも発生します。各ボリューム管理ソフトウェアの設定の詳細については、『Sun Cluster 3.0 ソフトウェアのインストール』の付録を参照してください。

ディスクセットまたはディスクグループを計画する場合の重要な考慮事項として、その関連ディスクデバイスグループが、クラスタ内のアプリケーションリソース (データ) にどのように関連付けられているかを理解する必要があります。詳細は、『Sun Cluster 3.0 ソフトウェアのインストール』と『Sun Cluster 3.0 データサービスのインストールと構成』を参照してください。

データサービス

データサービスという用語は、単一サーバーではなくクラスタでの実行用に構成されたアプリケーション (Apache Web Server など) を表します。データサービスには、アプリケーションソフトウェアと、そのアプリケーションの起動、停止、監視を行う Sun Cluster ソフトウェアが含まれます。

Sun Cluster には、クラスタ内のアプリケーションを制御して監視するために使用されるデータサービス方式があります。これらの方式は、クラスタノード上のアプリケーションの起動、停止、および監視にこれらの方式を使用する、リソースグループマネージャー (RGM) の制御のもとで実行されます。これらの方式を、クラスタフレームワークソフトウェアおよび多重ホストディスクとともに使用すると、アプリケーションは可用性の高いデータサービスになります。可用性の高いデータサービスとなったアプリケーションは、クラスタ内で単一の障害が発生した後で起こる深刻なアプリケーション割り込みを防止できます。障害は、ノード、インタフェースコンポーネント、またはアプリケーションそのものに対して発生する可能性があります。

RGM は、アプリケーションとネットワークリソース (論理ホスト名と共有アドレス) のインスタンスを含め、クラスタ内のリソースも管理します。

Sun Cluster には、アプリケーションプログラマが、他のアプリケーションを可用性の高いデータサービスとして Sun Cluster で実行するのに必要なデータサービス方式を開発するための API とデータサービス開発ツールもあります。

リソースグループマネージャー (RGM)

Sun Cluster は、アプリケーションの可用性を高めるか、またはスケーラブルにするための環境を提供します。RGM は、リソースに対して作用します。リソースは、次のいずれかを行える論理コンポーネントです。

RGM は、データサービス (アプリケーション) を、リソースタイプの実装によって管理されるリソースとして制御します。これらの実装は、Sun によって提供されるか、開発者によって、汎用データサービステンプレート、DSDL API (データサービス開発ライブラリ API)、Sun Cluster RMAPI (リソース管理 API) のどれかを使用して作成されます。クラスタ管理者は、リソースグループと呼ばれるコンテナにリソースを作成して管理します。これは、フェイルオーバーとスイッチオーバーの基本ユニットになります。RGM は、クラスタメンバーシップの変更に応じて、指定ノードのリソースグループを停止および開始します。

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

データサービスが実行されているノード (主ノード) に障害が発生すると、サービスは、ユーザーによる介入なしで別の作業ノードに移行します。フェイルオーバーサービスは、アプリケーションインスタンスリソースとネットワークリソース (論理ホスト名) のコンテナである、フェイルオーバーリソースグループを利用します。論理ホスト名とは、1 つのノードに構成して、後で自動的に元のノードや別のノードに構成できる IP アドレスのことです。

フェイルオーバーデータサービスでは、アプリケーションインスタンスは単一ノードでのみ実行されます。フォルトモニターは、エラーを検出すると、データサービスの構成に従って、同じノードでそのインスタンスを再起動しようとするか、別のノードでそのインスタンスを起動 (フェイルオーバー) しようとします。

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

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

サービス要求は、単一ネットワークインタフェース (広域インタフェース、または GIF) を介してクラスタに入り、負荷均衡ポリシーによって設定されたいくつかの定義済みアルゴリズムの 1 つに基づいてノードに分配されます。クラスタは、負荷均衡ポリシーを使用して、いくつかのノード間でサービス負荷の均衡をとることができます。他の共有アドレスをホストしている別のノード上に、複数の GIF が存在する可能性があります。

スケーラブルサービスの場合、アプリケーションインスタンスはいくつかのノードで同時に実行されます。広域インタフェースのホストとなるノードに障害が発生すると、広域インタフェースは別のノードで処理を続行します。アプリケーションインスタンスの実行に失敗した場合、そのインスタンスは同じノードで再起動しようとします。

アプリケーションインスタンスを同じノードで再起動できず、別の未使用のノードがサービスを実行するように構成されている場合、サービスはその未使用ノードで処理を続行します。あるいは、残りのノードで実行し続けて、サービススループットを低下させることになります。

注 -

各アプリケーションインスタンスの TCP 状態は、GIF ノードではなく、インスタンスを持つノードで維持されます。したがって、GIF ノードに障害が発生しても接続には影響しません。

図 3-4 は、フェイルオーバーおよびスケーラブルの各リソースグループの例と、スケーラブルサービスでそれらの間に存在する依存関係を示しています。この例は、3 つのリソースグループを示しています。フェイルオーバーリソースグループには、可用性の高い DNS のアプリケーションリソースと、可用性の高い DNS および可用性の高い Apache Web Server の両方によって使用されるネットワークリソースが含まれます。スケーラブルリソースグループには、Apache Web Server のアプリケーションインスタンスだけが含まれます。リソースグループの依存関係は、スケーラブルリソースグループとフェイルオーバーリソースグループの間に存在し (実線)、Apache アプリケーションリソースはすべて、共有アドレスであるネットワークリソース schost-2 に依存する (破線) ことに注意してください。

図 3-4 フェイルオーバーリソースグループとスケーラブルリソースグループの例

Graphic

スケーラブルサービスの構造

クラスタネットワーキングの主な目的は、データサービスにスケーラビリティを提供することにあります。スケーラビリティとは、サービスに提供される負荷が増えたときに、新しいノードがクラスタに追加されて新しいサーバーインスタンスが実行されるために、データサービスがこの増加した負荷に対して一定の応答時間を維持できるということを示します。スケーラブルデータサービスの例としては、Web サービスがあります。通常、スケーラブルデータサービスはいくつかのインスタンスからなり、それぞれがクラスタの異なるノードで実行されます。これらのインスタンスはともに、そのサービスの遠隔クライアントの観点から見て 1 つのサービスとして動作し、サービスの機能を実現します。たとえば、いくつかのノードで実行されるいくつかの httpd デーモンからなるスケーラブル Web サービスがあります。どの httpd デーモンもクライアント要求に対応できます。要求に対応するデーモンは、負荷均衡ポリシーによって決められます。クライアントへの応答は、その要求にサービスを提供する特定のデーモンではなく、サービスによるもののようにみえるため、単一サービスの外観が維持されます。

スケーラブルサービスは、次のものからなります。

次の図は、スケーラブルサービスの構造を示しています。

図 3-5 スケーラブルサービスの構造

Graphic

広域インタフェースのホストではないノード (プロキシノード) には、そのループバックインタフェースでホストされる共有アドレスがあります。GIF に入るパケットは、構成可能な負荷均衡ポリシーに基づいて、他のクラスタノードに分配されます。次に、構成できる負荷均衡ポリシーについて説明します。

負荷均衡ポリシー

負荷均衡は、スケーラブルサービスのパフォーマンスを応答時間とスループットの両方の点で向上させます。

スケーラブルデータサービスには、pure と sticky の 2 つのクラスがあります。pure サービスとは、そのいずれかのインスタンスがクライアント要求に応答できるサービスをいいます。sticky サービスとは、クライアントが同じインスタンスに要求を送るサービスをいいます。これらの要求は、別のインスタンスには変更されません。

pure サービスは、ウェイト設定した (weighted) 負荷均衡ポリシーを使用します。この負荷均衡ポリシーのもとでは、クライアント要求は、デフォルトで、クラスタ内のサーバーインスタンスに一律に分配されます。たとえば、3 ノードクラスタでは、各ノードに 1 のウェイトがあるものと想定します。各ノードは、そのサービスに代わって、クライアントからの要求の 3 分の 1 のサービスを提供します。ウェイトは、scrgadm(1M) コマンドインタフェースを使用し、管理者がいつでも変更できます。

sticky サービスには、ordinary sticky と wildcard sticky の 2 種類があります。sticky サービスを使用すると、内部状態メモリーを共有でき (アプリケーションセッション状態)、複数の TCP 接続でアプリケーションレベルの同時セッションが可能です。

ordinary sticky サービスを使用すると、クライアントは、複数の同時 TCP 接続で状態を共有できます。単一ポートを待機しているそのサーバーインスタンスという点で、そのクライアントは sticky であると呼ばれます。クライアントは、インスタンスが起動していてアクセス可能であり、負荷分散ポリシーがサーバーのオンライン時に変更されていなければ、すべての要求が同じサーバーのインスタンスに送られることを保証されます。

たとえば、クライアント上の Web ブラウザは、3 つの異なる TCP 接続を使用して、ポート 80 にある 共有 IP アドレスに接続しますが、これらの接続はサービスでキャッシュされたセッション情報を交換します。

sticky ポリシーを一般化すると、同じインスタンスの背後でセッション情報を交換する複数のスケーラブルサービスにまで及びます。これらのサービスが同じインスタンスの背後でセッション情報を交換する場合、同じノードで異なるポートと通信する複数のサーバーインスタンスという点で、そのクライアントは sticky であると呼ばれます。

たとえば、電子商取引サイトの顧客は、ポート 80 の HTTP を使用して買い物をしますが、購入した製品の支払いをクレジットカードで行うためには、ポート 443 で SSL に切り替えて機密データを送ります。

wildcard sticky サービスは、動的に割り当てられたポート番号を使用しますが、クライアント要求がやはり同じノードに送られるものと想定します。クライアントは、同じ IP アドレスという点で、ポートに対して sticky wildcard です。

このポリシーの例としては、受動モード FTP があります。クライアントは、ポート 21 の FTP サーバーに接続して、動的ポート範囲のリスナーポートサーバーに接続するよう、そのサーバーによって通知されます。この IP アドレスに対する要求はすべて、サーバーが制御情報によってクライアントに通知した、同じノードに転送されます。

これらの各 sticky ポリシーでは、ウェイト設定した (weighted) 負荷均衡ポリシーがデフォルトで有効であるため、クライアントの最初の要求は、負荷均衡によって指定されたインスタンスにリダイレクトされます。インスタンスが実行されているノードとクライアントが関係を確立すると、そのノードがアクセス可能で、負荷分散ポリシーが変更されない限り、今後の要求はそのインスタンスに送られます。

次に、各負荷均衡ポリシーの詳細について説明します。

フェイルバック設定

リソースグループは、ノードからノードへ処理を継続します。リソースグループが処理を別のノードに継続する場合、以前実行していたノードがクラスタに戻ってから、元のノードにフェイルバックするように指定できます。このオプションは、Failback リソースグループプロパティによって設定できます。

特定のインスタンスでは、たとえば、リソースグループをホストする元のノードに障害が生じて繰り返し再起動する場合、フェイルバックを設定すると、リソースグループの可用性が低下することがあります。

データサービス障害モニター

Sun Cluster の各データサービスには、データサービスを定期的に探索してその状態を判断する障害モニターがあります。障害モニターは、アプリケーションデーモンが実行されていて、クライアントにサービスが提供されていることを確認します。探索によって得られた情報をもとに、デーモンの再起動やフェイルオーバーの実行などの事前に定義された処置が開始されます。

新しいデータサービスの開発

Sun は、各種のアプリケーションを可用性の高いデータサービスとしてクラスタ内で動作させるためのソフトウェアを提供しています。可用性の高いデータサービスとして実行したいアプリケーションが、現在 Sun から提供されていない場合は、API または DSDL API を使用して、各自のアプリケーションを可用性の高いデータサービスとして実行するように構成できます。データサービスには、フェイルオーバーとスケーラブルの 2 つの種類があります。アプリケーションがどちらのデータサービスを使用できるのかを判断するための基準があります。個々の基準は、アプリケーションで使用できる API について説明している Sun Cluster のマニュアルに記載されています。

次に、各自のサービスがスケーラブルデータサービスの構造を利用できるかどうかを知るために役立つガイドラインをいくつか示します。スケーラブルサービスの一般的な情報については、「スケーラブルデータサービス」を参照してください。

次のガイドラインを満たす新しいサービスは、スケーラブルサービスを利用できます。既存のサービスがこれらのガイドラインに従っていない場合は、そのサービスがガイドラインに準拠するように、一部を書き直さなければならない場合があります。

スケーラブルデータサービスには、以下の特性があります。まず、このようなサービスは、1 つまたは複数のサーバーインスタンスからなります。各インスタンスは、クラスタの異なるノードで実行されます。同じサービスの複数のインスタンスを、同じノードで実行することはできません。

次に、サービスが外部論理データ格納を使用する場合は、この格納に対する複数のサーバーインスタンスからの同時アクセスの同期をとって、更新が失われたり、変更中のデータを読み取ったりすることを避ける必要があります。この格納をメモリー内部の状態と区別するために「外部」と呼び、格納がそれ自体複製されている場合でも単一の実体として見えるため、「論理的」と呼んでいることに注意してください。また、この論理データ格納には、サーバーインスタンスが格納を更新するたびに、その更新がすぐに他のインスタンスで見られるという特性があります。

Sun Cluster は、このような外部記憶領域をそのクラスタファイルシステムと広域 raw パーティションを介して提供します。例として、サービスが外部ログファイルに新しいデータを書き込む場合や既存のデータを修正する場合を想定してください。このサービスの複数インスタンスが実行されている場合は、それぞれがこの外部ログへのアクセスを持ち、同時にこのログにアクセスできます。各インスタンスは、このログに対するアクセスの同期をとる必要があります。そうしないと、インスタンスは相互に妨害しあうことになります。サービスは、fcntl(2) および lockf(3C) によって通常の Solaris ファイルロックを使用して、必要な同期をとることができます。

このような格納のもう 1 つの例としては、可用性の高い Oracle または Oracle Parallel Server などのバックエンドデータベースが挙げられます。このようなバックエンドデータベースサーバーは、データベース照会または更新トランザクションを使用するのに内部組み込みの同期を使用するため、複数のサーバーインスタンスが独自の同期を実装する必要がありません。

現在の実現状態ではスケーラブルサービスではないサービスの例として、Sun のIMAP サーバーがあります。このサービスは格納を更新しますが、その格納はプライベートであり、複数の IMAP インスタンスがこの格納に書き込むと、更新の同期がとられないために相互に上書きし合うことになります。IMAP サーバーは、同時アクセスの同期をとるために書き直す必要があります。

最後に、インスタンスは、他のインスタンスのデータから切り離されたプライベートデータを持つ場合があることに注意してください。このようなケースでは、データはプライベートであり、そのインスタンスだけがデータを処理するため、サービスは同時アクセスの同期をとる必要はありません。この場合、このプライベートデータが広域にアクセス可能になる可能性があるため、このデータをクラスタファイルシステムのもとで保存しないように注意する必要があります。

データサービス API と DSDL API

Sun Cluster には、アプリケーションの可用性を高めるための次のものがあります。

『Sun Cluster 3.0 データサービスのインストールと構成』は、Sun Cluster によって提供されるデータサービスをインストールして構成する方法を説明しています。『Sun Cluster 3.0 データサービス開発ガイド』は、Sun Cluster フレームワークのもとで他のアプリケーションの可用性を高くする方法を説明しています。

Sun Cluster API と DSDL API を使用すると、アプリケーションプログラマは、障害モニターおよびデータサービスインスタンスを起動して停止するスクリプトを開発できます。これらのツールを使用すると、アプリケーションをフェイルオーバーまたはスケーラブルデータサービスとして設計できます。また、Sun Cluster には、アプリケーションに必要な起動および停止方式を簡単に生成して、可用性の高いデータサービスとして実行できるようにするための汎用データサービスもあります。

リソースとリソースタイプ

データサービスは、数種類のリソースを使用します。つまり、Apache Web Server や iPlanet Web Server などのアプリケーションと、それらのアプリケーションが依存するネットワークアドレス (論理ホスト名と共有アドレス) です。アプリケーションとネットワークリソースは、RGM によって管理される基本ユニットを形成します。

リソースとは、クラスタ全体で定義されたリソースタイプをインスタンス化したものです。いくつかのリソースタイプが定義されています。

データサービスはリソースタイプです。たとえば、Sun Cluster HA for Oracle はリソースタイプ SUNW.oracle であり、Sun Cluster HA for Apache はリソースタイプ SUNW.apache です。

ネットワークリソースは、SUNW.LogicalHostname または SUNW.SharedAddress リソースタイプです。これら 2 つのリソースタイプは、Sun Cluster 製品により事前に登録されています。

SUNW.HAStorage リソースタイプは、リソースとそのリソースが依存するディスクデバイスグループの起動を同期させるのに使用します。これによって、データサービスが起動する前に、クラスタファイルシステムのマウントポイントへのパス、広域デバイス、デバイスグループ名を使用できます。

RGM 管理のリソースは、リソースグループと呼ばれるグループに入れられるため、1 つのユニットとして管理できます。リソースグループは、フェイルオーバーまたはスイッチオーバーがリソースグループで開始されたときに、ユニットで移行されます。

注 -

アプリケーションリソースを含むリソースグループをオンラインにすると、アプリケーションが起動します。データサービス起動方式は、アプリケーションが起動して実行されるまで待ってから、正常に終了します。アプリケーションが起動して実行しているかどうかの判断は、データサービス障害モニターが、データサービスがクライアントにサービスを提供しているかどうかを判断するのと同じ方法で行われます。このプロセスの詳細については、『Sun Cluster 3.0 データサービスのインストールと構成』を参照してください。

リソースとリソースグループプロパティ

Sun Cluster データサービスのリソースおよびリソースグループのプロパティ値は構成できます。一連の標準的なプロパティはすべてのデータサービスに共通であり、拡張プロパティは各データサービスに特定のものです。標準プロパティおよび拡張プロパティのいくつかは、デフォルト設定によって構成されているため、これらを修正する必要はありません。それ以外のプロパティは、リソースを作成して構成するプロセスの一部として設定する必要があります。各データサービスのマニュアルでは、リソースタイプで使用されるプロパティの種類とその構成方法を指定しています。

標準プロパティは、通常特定のデータサービスに依存しないリソースおよびリソースグループプロパティを構成するために使用されます。これらの標準プロパティについては、『Sun Cluster 3.0 データサービスのインストールと構成』の付録を参照してください。

拡張プロパティは、アプリケーションバイナリの場所や構成ファイルなどの情報を提供するものです。拡張プロパティは、データサービスの構成に従って 修正する必要があります。拡張プロパティについては、『Sun Cluster 3.0 データサービスのインストールと構成』のデータサービスに関する各章を参照してください。

パブリックネットワーク管理 (PNM) とネットワークアダプタフェイルオーバー (NAFO)

クライアントは、パブリックネットワークを介してクラスタにデータ要求を行います。各クラスタノードは、パブリックネットワークアダプタを介して少なくとも 1 つのパブリックネットワークに接続されています。

Sun Cluster パブリックネットワーク管理 (PNM) ソフトウェアは、パブリックネットワークアダプタを監視して、障害が検出されたときにアダプタからアダプタへ IP アドレスの処理を継続するための基本機構を提供します。各クラスタノードには独自の PNM 構成があり、これは他のクラスタノードと異なることもあります。

パブリックネットワークアダプタは、ネットワークアダプタフェイルオーバーグループ (NAFO グループ) の中に構成されています。各 NAFO グループには、1 つまたは複数のパブリックネットワークアダプタがあります。特定の NAFO グループで一度にアクティブにできるのは 1 つのアダプタだけですが、同じグループ内の多くのアダプタは、アクティブアダプタの PNM デーモンによって障害が検出された場合のアダプタフェイルオーバーに使用されるバックアップアダプタとして機能します。フェイルオーバーでは、アクティブアダプタに関連するIP アドレスがバックアップアダプタに移動するため、ノードのパブリックネットワーク接続が維持されます。フェイルオーバーは、アダプタインタフェースレベルで発生するため、フェイルオーバー中に一時的にわずかな遅延がみられる以外、TCP などのこれよりも高いレベルの接続は影響されません。

注 -

TCP の構成回復特性が原因で、正常なフェイルオーバーの後、セグメントのいくつかがフェイルオーバー中に失われて、TCP の混雑制御機構をアクティブ化するために、TCP エンドポイントではさらに遅延が生じる可能性があります。

NAFO グループには、論理ホスト名と共有アドレスリソースの構築ブロックがあります。scrgadm(1M) コマンドは、必要に応じて NAF グループを自動的に作成します。論理ホスト名と共有アドレスリソースとは別に NAFO グループを作成して、クラスタノードのパブリックネットワーク接続を監視する必要もあります。ノード上の同じ NAFO グループが、任意の数の論理ホスト名、または共有アドレスリソースのホストとなることができます。論理ホスト名と共有アドレスリソースの詳細については、『Sun Cluster 3.0 データサービスのインストールと構成』を参照してください。

注 -

NAFO 機構の設計は、アダプタの障害を検出してマスクすることを目的としています。この設計は、ifconfig(1M) を使用して論理 (または共有) IP アドレスのどれかを削除した状態から回復することを目的としていません。Sun Cluster の設計では、RGM によって管理されるリソースとして論理および共有 IP アドレスとみなします。管理者が IP アドレスを追加または削除する正しい方法は、scrgadm(1M) を使用してリソースを含むリソースグループを修正するというものです。

PNM 障害検出とフェイルオーバープロセス

PNM は、正常なアダプタのパケットカウンタが、アダプタを介した通常のネットワークトラフィックによって変化するものと想定して、アクティブアダプタのパケットカウンタを定期的にチェックします。パケットカウンタがしばらくの間変化しない場合、PNM は ping シーケンスに入って、トラフィックを強制的にアクティブアダプタに送ります。PNM は、各シーケンスの最後でパケットカウンタに変化がないかを検査し、ping シーケンスが何度か繰り返された後でもパケットカウンタに変化がない場合は、アダプタの障害を宣言します。これらのイベントは、バックアップアダプタがあれば、それへのフェイルオーバーを引き起こします。

入力および出力パケットカウンタはいずれも PNM によって監視され、どちらかまたは両方にしばらくの間変化がない場合は、ping シーケンスが開始されます。

ping シーケンスは、ALL_ROUTER マルチキャストアドレス (224.0.0.2)、ALL_HOST マルチキャストアドレス (224.0.0.1)、およびローカルサブネットブロードキャストアドレスの ping からなります。

ping は、コストの低いもの順という方法で構成されているため、コストのかかる ping は、コストの低い ping が成功した場合は実行されません。また、ping はアダプタでのトラフィックを生成するための方法としてのみ使用されます。その終了状態は、アダプタが機能しているか障害が発生しているかの判断には関係ありません。

inactive_time、ping_timeout、repeat_test、slow_network の 4 つの調整可能なパラメータがこのアルゴリズムにあります。これらのパラメータによって、フォルト検出の速度と正確さを調整できます。パラメータの詳細とその変更方法については、『Sun Cluster 3.0 のシステム管理』のパブリックネットワークパラメータの変更手順を参照してください。

NAFO グループのアクティブアダプタで障害が検出された後で、バックアップアダプタが使用できない場合、そのグループは停止と宣言されますが、そのバックアップアダプタのすべてのテストは続行します。また、バックアップアダプタが使用可能な場合は、そのバックアップアダプタに対してフェイルオーバーが発生します。論理アドレスとその関連フラグはバックアップアダプタに転送されて、障害の発生したアクティブアダプタは停止して切り離された状態に (unplumbed) なります。

IP アドレスのフェイルオーバーが正常に終了すると、自動的に ARP が送信されます。したがって、遠隔クライアントへの接続は維持されます。