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

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

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

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

管理インタフェース

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

クラスタ内の時間

クラスタ内のすべてのノード間の時刻は同期をとる必要があります。クラスタノードの時刻と外部の時刻ソースの同期をとるかどうかは、クラスタの操作にとって重要ではありません。SunPlex システムは、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 U1 ソフトウェアのインストール』を参照してください。

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

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

高可用性フレームワーク

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

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

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

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

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

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

• すべてのノード (定足数/quorum) で一貫したメンバーシップの表示を行う

• メンバーシップの変更に応じて、登録されたコールバックを使用して同期化された再構成を行う

• クラスタパーティション分割を処理する (split-brain と amnesia)

• すべてのクラスタメンバー間での完全な接続を保証する

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

クラスタメンバーシップ

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

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

• クラスタへのノードの結合、またはクラスタからのノードの切り離しなど、クラスタメンバーシップの変更を考慮する

• 障害のあるノードがクラスタから切り離されるように保証する

• 障害のあるノードが、修復されるまでクラスタの外部におかれるように保証する

• クラスタそのものがノードのサブセットに分割されないように防止する

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

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

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

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

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

フェイルファースト機構

CMM は、ノードに重大な問題が発生したことを検出すると、クラスタフレームワークに依頼して、そのノードを強制的に (パニック) 状態にし、クラスタメンバーシップから除きます。この機構を「フェイルファースト」といいます。フェイルファーストでは、ノードは次の 2 つの方法で停止します。

• クラスタから切り離されたノードが定足数なしに再び新しいクラスタを起動しようとすると、ノードは共有ディスクへのアクセスを制限されます。フェイルファーストのこの機能については、「障害による影響の防止」を参照してください。

• クラスタ固有の 1 つまたは複数のデーモン (clexecd、rpc.pmfd、rgmd、rpc.ed) が停止すると、CMM はそれを検出し、ノードを強制的に停止 (パニック) 状態にします。

panic[cpu0]/thread=40e60: Failfast: Aborting because "pmfd" died 35 seconds ago.
409b8 cl_runtime:__0FZsc_syslog_msg_log_no_argsPviTCPCcTB+48 (70f900, 30, 70df54, 407acc, 0)
%l0-7: 1006c80 000000a 000000a 10093bc 406d3c80 7110340 0000000 4001 fbf0

停止したノードは、再起動を行ってクラスタに再び結合しようとするか、OpenBoot PROM (OBP) プロンプトの状態に留まることができます。どちらのアクションをとるかは、OBP の auto-boot? パラメータの設定に依存します。

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

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

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

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

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

広域デバイス

SunPlex システムは、広域デバイスを使用して、デバイスが物理的に接続されている場所に関係なく、任意のノードからクラスタ内のすべてのデバイスに対して、クラスタ全体の可用性の高いアクセスを可能にします。通常、広域デバイスへのアクセスを提供しているときにノードに障害が発生すると、Sun Cluster ソフトウェアはそのデバイスへの別のパスを自動的に検出して、そのパスにアクセスを切り替えます。SunPlex 広域デバイスには、ディスク、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) によって更新、管理します。詳細については、それぞれのマニュアルページを参照してください。

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

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

この登録によって、SunPlex システムは、どのノードがどのボリュームマネージャディスクグループへのパスをもっているかを知ることができます。この時点でそのボリュームマネージャデバイスグループは、クラスタ内で広域アクセスが可能になります。あるディスクデバイスグループが複数のノードから書き込みができる (制御できる) 場合は、そのディスクデバイスグループに格納されるデータは、高度な可用性を有することになります。高度な可用性を備えたディスクデバイスグループには、クラスタファイルシステムを格納できます。

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

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

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

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

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

広域名前空間

広域デバイスを有効にする 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 ディスクグループのディレクトリからなります。これらの各ディレクトリには、そのディスクセットまたはディスクグループ内の各メタデバイスまたはボリュームのデバイスノードが入っています。

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

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

• 各ノードの独立性が高く、デバイス管理モデルをほとんど変更しなくてすむ。

• デバイスを選択的に広域にできる。

• Sun の製品以外のリンクジェネレータが引き続き動作する。

• ローカルデバイス名を指定すると、その広域名を取得するために簡単なマッピングが提供される。

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

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

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

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

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

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

広域デバイスには、mount -g を使用して広域に、または mount を使用してローカルにファイルシステムをマウントできます。

プログラムは、同じファイル名 (たとえば、/global/foo) によって、クラスタ内のすべてのノードからクラスタファイルシステムのファイルにアクセスできます。

クラスタファイルシステムは、すべてのクラスタメンバーにマウントされます。クラスタファイルシステムをクラスタメンバーのサブセットにマウントすることはできません。

クラスタファイルシステムは、特定のファイルシステムタイプではありません。つまり、クライアントは、UFS など、実際に使用するファイルシステムしか認識できません。

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

SunPlex システムでは、すべての多重ホストディスクがディスクデバイスグループとして構成されています。これは、Solstice DiskSuite ディスクセット、VxVM ディスクグループ、またはソフトウェアベースのボリューム管理ソフトウェアの制御下にない個々のディスクが該当します。

クラスタファイルシステムを高可用性にするには、使用するディスクストレージが複数のノードに接続されていなければなりません。したがって、クラスタファイルシステム内のローカルファイルシステム (ノードのローカルディスクに格納されているファイルシステム) は、高可用性ではありません。

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

• 手作業によるマウント- mount コマンドと -g または -o global マウントオプションを使用し、コマンド行からクラスタファイルシステムをマウントします。次に例を示します。

  # mount -g /dev/global/dsk/d0s0 /global/oracle/data

• 自動マウント- global マウントオプションによって /etc/vfstab ファイルにエントリを作成します。さらに、すべてのノードの /global ディレクトリ下にマウントポイントを作成します。ディレクトリ /global を推奨しますが、他の場所でも構いません。次に、/etc/vfstab ファイルの、クラスタファイルシステムを示す行の例を示します。

  /dev/md/oracle/dsk/d1 /dev/md/oracle/rdsk/d1 /global/oracle/ data ufs 2 yes global,logging

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

クラスタファイルシステムの機能

クラスタファイルシステムには、次の機能があります。

• ファイルのアクセス場所が透過的になります。プロセスはファイルがシステム内のどこに置かれていても開くことができ、また、すべてのノード上のプロセスが同じパス名を使用してファイルを見つけられます。

• 一貫したプロトコルを使用して、ファイルが複数のノードから同時にアクセスされている場合でも、UNIX ファイルアクセス方式を維持します。

• 拡張キャッシュ機能とゼロコピーバルク入出力移動機能により、ファイルデータを効率的に移動することができます。

• クラスタファイルシステムには、fcntl (2) インタフェースに基づく、高度な可用性を備えたアドバイザリファイルロッキング機能があります。複数のクラスタノードで動作するアプリケーションは、クラスタファイルシステムのファイルに対してアドバイザリファイルロッキング機能を使用することによって、データへのアクセスを同期化することができます。ファイルロックを所有するノードがクラスタから切り離されたり、ファイルロックを所有するアプリケーションが異常停止すると、それらのロックはただちに解放されます。

• 障害が発生した場合でも、データへの連続したアクセスが可能です。アプリケーションは、ディスクへのパスが有効である限り、障害による影響を受けません。この保証は、raw ディスクアクセスとすべてのファイルシステム操作で維持されます。

• クラスタシステムファイルは、実際のファイルシステムおよびボリューム管理ソフトウェアに依存していません。クラスタシステムファイルは、サポートされているディスク上のファイルシステムすべてを広域にします。

syncdir マウントオプション

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

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

定足数と定足数デバイス

クラスタノードではデータやリソースが共有されているため、クラスタが、同時にアクティブな複数のパーティションに分割されてはなりません。CMM では、クラスタインターコネクトがパーティション分割されていても、ある時点で動作するクラスタは常に 1 つだけです。

クラスタのパーティション分割によって起こる問題に split-brain と amnesia があります。split-brain の問題は、ノード間のインターコネクトが失われ、クラスタが複数のサブクラスタにパーティション分割されたときに発生します。この場合、個々のパーティションはそれ自体が唯一のパーティションであるとみなしますが、その原因は、クラスタノード間の通信が阻害されたことにあります。amnesia の問題は、停止したクラスタが、停止時よりも古いクラスタデータに基づいて再起動されたときに発生します。たとえば、フレームワークデータの複数のバージョンがディスクに格納されている状態で、クラスタが新たに起動されたときに最新バージョンが使用できないと、このような問題が起こる可能性があります。

split-brain と amnesia の問題は、各ノードに 1 票を与え、過半数の投票がないとクラスタが動作しないようにすることで防止できます。過半数の投票を得たパーティションは「定足数 (quorum)」を獲得し、アクティブになります。この過半数投票の仕組みは、クラスタに 3 つ以上のノードがある限り正しく機能します。しかし、2 ノードクラスタでは過半数が 2 であるため、このようなクラスタがパーティション分割されると、外部からの投票がない限り、どちらのパーティションも定足数を獲得することはできません。この外部からの投票は、「定足数デバイス (quorum device)」によって行われます。定足数デバイスは、2 つのノード間で共有されているディスクであれば、何でもかまいません。定足数デバイスとして使用されるディスクには、ユーザーデータを格納できます。

表 3-3 に、Sun Cluster ソフトウェアが定足数を使って split-brain や amnesia の問題を防止する方法を示します。

定足数アルゴリズムは動的に動作します。クラスタイベントによってその計算が発生した場合、計算結果はクラスタの存続期間中、変化し続けます。

定足数投票数

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

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

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

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

定足数の構成

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

• 2 ノードクラスタ - 2 ノードクラスタを形成するには、定足数投票数 (quorum vote count) が 2 つ必要です。これらの 2 つの投票数は、2 つのクラスタノード、または 1 つのノードと 1 つの定足数デバイスのどちらかによるものです。ただし、2 ノードクラスタでは、一方のノードに障害が発生したときに単一ノードで処理を続行できるように、1 つの定足数デバイスが構成されなければなりません。

• 3 ノード以上のクラスタ - ディスク格納装置へのアクセスを共有するすべてのノードペア間に、定足数デバイスを指定する必要があります。たとえば、図 3-3 のような 3 ノードクラスタを想定します。この場合、ノード A とノード B が同じディスク格納装置へのアクセスを共有し、ノード B とノード C は別のディスク格納装置へのアクセスを共有します。この構成では、合計 5 つの投票数があります。3 つはノードによるもの、2 つはノード間で共有される定足数デバイスによるものです。クラスタを形成するには、過半数の投票数 (この場合は 3 つ) を必要とします。定足数デバイスを、ディスク格納装置へのアクセスを共有するすべてのノードペア間に指定することは、Sun Cluster ソフトウェアでは必要とされておらず、また実行もされません。しかし、N+1 構成が 2 ノード構成になり、両方のディスク格納装置へアクセスするノードに障害が発生すると、必要な投票数を提供します。すべてのペア間で定足数デバイスを構成すると、残りのノードはクラスタとして動作を継続することができます。

  これらの構成の例については、図 3-3 を参照してください。

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

定足数のガイドライン

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

• 同じ共有ディスク格納装置に接続されたすべてのノード間で定足数デバイスを確立します。共有格納装置内に 1 つのディスクを定足数デバイスとして追加し、いずれかのノードに障害が生じたときに、他のノードが定足数を維持して、共有格納装置上のディスクデバイスグループをマスターできるようにします。

• 定足数デバイスは少なくとも 2 つのノードに接続する必要があります。

• 定足数デバイスとして、二重ポート定足数デバイスとして使用される、任意の SCSI-2 または SCSI-3 ディスクが使用できます。3 つ以上のノードに接続されたディスクは、ディスクが定足数デバイスとして使用されるかどうかに関係なく、SCSI-3 持続的グループ予約 (PGR) をサポートしなければなりません。詳細については、『Sun Cluster 3.0 U1 ソフトウェアのインストール』の計画に関する章を参照してください。

• 定足数デバイスとしてユーザーデータを含むディスクを使用できます。

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

障害による影響の防止

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

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

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

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

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

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

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

障害の影響を防止するフェイルファースト機構

異常のあるノードが再起動され、共有ストレージに書き込むのを防ぐクラスタフレームワークの機構をフェイルファーストといいます。

クラスタのメンバーである各ノードでは、定足数ディスクを含むアクセス可能な個々のディスクに対し ioctl (MHIOCENFAILFAST) が連続的に有効にされます。この ioctl は特定のディスクドライバに対する命令です。ディスクが他のノードによって予約されているためにそのディスクにアクセスできないと、ノードは自らをパニックさせる (強制的に停止する) ことができます。

MHIOCENFAILFAST ioctl が有効になっていると、ドライバは、ノードからそのディスクに対して出されるすべての読み取りや書き込みからのエラーに、 Reservation_Conflict エラーコードが含まれていないか検査します。ioctl はバックグラウンドでディスクに対して周期的にテスト操作を行い、Reservation_Conflict がないか検査します。Reservation_Conflict が返されると、フォアグラウンドとバックグラウンドのコントロールフローパスが両方ともパニックを発生します。

SCSI-2 ディスクの場合、予約は永続的ではないため、ノードが再起動されると無効になります。Persistent Group Reservation (PGR) の SCSI-3 ディスクでは、予約情報はそのディスクに格納されるため、ノードが再起動されても有効です。フェイルファースト機構は、SCSI-2 ディスクでも SCSI-3 ディスクでも同じように機能します。

定足数を獲得できるパーティションに属していないノードが、クラスタ内の他のノードとの接続を失うと、そのノードは別のノードによってクラスタから強制的に切り離されます。定足数を獲得できるパーティションのノードによって予約されている共有ディスクに、定足数をもたないノードからアクセスすると、ノードは予約衝突のエラーを受け取り、フェイルファースト機構に基づいてパニックを発生します。

パニックを発生したノードは、再起動を行ってクラスタに再び結合しようとするか、OpenBoot PROM (OBP) プロンプトの状態に留まることができます。どちらのアクションをとるかは、OBP の auto-boot? パラメータの設定に依存します。

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

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

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

• Solstice DiskSuite

• VERITAS Volume Manager

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

• ノード障害のフェイルオーバー処理

• 異なるノードからの多重パスサポート

• ディスクデバイスグループへの遠隔からの透過アクセス

クラスタの制御下にあるボリューム管理オブジェクトは、ディスクデバイスグループになります。ボリューム管理ソフトウェアの詳細については、使用するボリューム管理ソフトウェアのマニュアルを参照してください。

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

データサービス

「データサービス」という用語は、Oracle や iPlanet Web Server など、クラスタ (単一のサーバーではなく) で動作するように構成された Sun 以外のアプリケーションを意味します。データサービスは、アプリケーションと専用の Sun Cluster 構成ファイル、および、アプリケーションの以下の操作を制御する Sun Cluster 管理メソッドからなります。

• 起動

• 停止

• 監視と訂正手段の実行

図 3-4に、単一のアプリケーションサーバーで動作するアプリケーション (単一サーバーモデル) と、クラスタで動作する同じアプリケーション (クラスタサーバーモデル) との比較を示します。ユーザーから見れば、この 2 つの構成には何の違いもありません。しかし、クラスタ化されたアプリケーションでは、処理が速くなる可能性があるだけでなく、可用性が高まります。

図 3-4 標準的なクライアントサーバー構成とクラスタ化されたクライアントサーバー構成

単一モデルでは、特定のパブリックネットワークインタフェース (ホスト名) を介してサーバーにアクセスするようにアプリケーションを設定します。ホスト名は、この物理サーバーに関係付けられています

クラスタサーバーモデルのパブリックネットワークインタフェースは「論理ホスト名」か「共有アドレス」です。論理ホスト名と共有アドレスを指す用語として「ネットワークリソース」が使用されます。

一部のデータサービスでは、ネットワークインタフェースとして論理ホスト名か共有アドレスのいずれか (入れ替え不可能) を指定する必要があります。しかし、別のデータサービスでは、論理ホスト名や共有アドレスをどちらでも指定することができます。どのようなタイプのインタフェースを指定する必要があるかについては、各データサービスのインストールや構成の資料を参照してください。

ネットワークリソースは、特定の物理サーバーと関連付けられているわけではありません。ネットワークリソースは、ある物理サーバーから別の物理サーバーに移すことができます。

ネットワークリソースは、当初、1 つのノード (一次ノード) に関連付けられています。しかし、一次ノードに障害が発生すると、ネットワークリソース (およびアプリケーションリソース) は、別のクラスタノード (二次ノード) にフェイルオーバーされます。ネットワークリソースがフェイルオーバーされても、アプリケーションリソースは、短時間の遅れの後に二次ノードで動作を続けます。

図 3-5 に、単一サーバーモデルとクラスタサーバーモデルとの比較を示します。クラスタサーバーモデルのネットワークリソース (この例では論理ホスト名) は、 複数のクラスタノード間を移動できます。アプリケーションは、特定のサーバーに関連付けられたホスト名として、この論理ホスト名を使用するように設定されます。

図 3-5 固定ホスト名と論理ホスト名

共有アドレスも最初は 1 つのノードに関連付けられています。このノードを広域インタフェースノード (GIN) といいます。共有アドレスは、クラスタへの唯一のネットワークインタフェースとして使用されます。これを「広域インタフェース」といいます。

論理ホスト名モデルとスケーラブルサービスモデルの違いは、スケーラブルサービスモデルでは、各ノードのループバックインタフェースにも共有アドレスがアクティブに設定される点です。この設定では、データサービスの複数のインスタンスをいくつかのノードで同時にアクティブにすることができます。「スケーラブルサービス」という用語は、クラスタノードを追加してアプリケーションの CPU パワーを強化すれば、性能が向上することを意味します。

GIN に障害が発生した場合には、共有アドレスを、同じアプリケーションのインスタンスが動作している別のノードに移すことができます (これによって、このノードが新しい GIN になる)。または、共有アドレスを、このアプリケーションを実行していない別のクラスタノードにフェイルオーバーすることができます。

図 3-6 に、単一サーバー構成とクラスタ化されたスケーラブルサービス構成との比較を示します。スケーラブルサービス構成では、共有アドレスがすべてのノードに設定されています。フェイルオーバーデータサービスに論理ホスト名が使用される場合と同じように、アプリケーションは、特定のサーバーに関連付けられたホスト名の代わりにこの共有アドレスを使用するように設定されます。

図 3-6 固定ホスト名と共有アドレス

データサービスメソッド

Sun Cluster ソフトウェアでは、リソースグループマネージャー (RGM) の制御下で動作する一連のサービス管理メソッドが提供されます。RGM は、これらのメソッドを使用し、クラスタノードで動作するアプリケーションの起動や停止、監視を行います。これらのメソッドとクラスタフレームワークソフトウェアおよび多重ホストディスクにより、アプリケーションは、フェイルオーバーデータサービスやスケーラブルデータサービスとして機能します。

さらに、RGM は、アプリケーションのインスタンスやネットワークリソース (論理ホスト名と共有アドレス) といったクラスタのリソースを管理します。

Sun Cluster ソフトウェアが提供するメソッドの他に、SunPlex システムからも API やいくつかのデータサービス開発ツールが提供されます。これらのツールを使用すれば、アプリケーションプログラマは、独自のデータサービスメソッドを開発し、他のアプリケーションを高可用性データサービスとして Sun Cluster ソフトウェアの下で実行できます。

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

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

RGM は「リソース」と「リソースグループ」に作用します。リソースやリソースグループは、RGM のアクションに従ってオンランになったり、オフラインになったりします。リソースやリソースグループに適用される状態や設定値の詳細は、「リソースおよびリソースグループの状態と設定値」を参照してください。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• スケーラブルサービスに対するネットワークインフラストラクチャのサポート

• 負荷均衡

• ネットワーキングおよびデータサービスに対するサポート (リソースグループマネージャーを使用)

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

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

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

負荷均衡ポリシー

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

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

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

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

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

• weighted - 負荷は指定されたウェイト値に従って各種のノードに分配されます。このポリシーは Load_balancing_weights プロパティに設定された LB_WEIGHTED の値を使用して設定されます。ウェイトがノードについて明示的に設定されていない場合は、デフォルトで 1 が設定されます。

  このポリシーは、ラウンドロビンではないことに注意してください。ラウンドロビンポリシーでは、クライアントからの各要求が、最初の要求はノード 1、2 番目の要求はノード 2 といったように常に異なるノードに送られます。ウェイトを設定したポリシーは、一定の割合のクライアントトラフィックが、特定ノードに送られるようにするものです。このポリシーは、個々の要求には対応しません。

• sticky - このポリシーでは、ポートの集合が、アプリケーションリソースの構成時に認識されます。このポリシーは、Load_balancing_policy リソースプロパティの LB_STICKY の値を使用して設定されます。

• sticky-wild - このポリシーは、通常の sticky ポリシーの上位セットです。IP アドレスによって識別されるスケーラブルサービスでは、ポートはサーバーによって割り当てられます (したがって前もって認識されません)。ポートは変更されることがあります。このポリシーは、Load_balancing_policy リソースプロパティの LB_STICKY_WILD の値を使用して設定されます。

フェイルバック設定

リソースグループは、ノードからノードへ処理を継続します。このようなリソースグループの移行が起こると、それまでの二次ノードが新しい主ノードになります。元の主ノードがオンラインに復帰したときにどのようなアクションを取るか (つまり、元の主ノードを再び主ノードに戻す (フェイルバックする) か、現在の主ノードをそのまま継続するか) は、フェイルバックの設定値で決まります。この選択は、リソースグループのプロパティ Failback で設定します。

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

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

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

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

サンが提供する構成ファイルや管理メソッドのテンプレートを使用することで、さまざまなアプリケーションをクラスタ内でフェイルオーバーサービスやスケーラブルサービスとして実行できます。フェイルオーバーサービスやスケーラブルサービスとして実行するアプリケーションがサンから提供されていない場合は、API や DSET API を使用して、フェイルオーバーサービスやスケーラブルサービスとして動作するようにアプリケーションを設定できます。

アプリケーションがフェイルオーバーサービスを使用できるかどうかを判断するための基準があります。個々の基準は、アプリケーションで使用できる API について説明している SunPlex のマニュアルに記載されています。.

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

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

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

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

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

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

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

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

データサービス API と DSDL API

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

• SunPlex システムの一部として提供されるデータサービス

• データサービス API

• DSDL API (データサービス開発ライブラリ API)

• 汎用データサービス

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

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

クラスタインターコネクトによるデータサービストラフィックの送受信

クラスタには、ノード間を結ぶ複数のネットワーク接続が必要です。クラスタインターコネクトは、これらの接続から構成されています。クラスタ化ソフトウェアは、可用性や性能を高めるために複数のインターコネクトを使用します。ファイルシステムのデータやスケーラブルサービスのデータなどの内部トラフィックでは、メッセージが、すべての使用可能なインターコネクト上にラウンドロビン方式でストライプ化されます。

クラスタインターコネクトは、ノード間の通信の可用性を高めるためにアプリケーションから使用することもできます。たとえば、分散アプリケーションでは、個々のコンポーネントが異なるノードで動作することがあり、その場合には、ノード間の通信が必要になります。パブリック伝送の代わりにクラスタインターコネクトを使用することで、個別のリンクに障害が発生しても、接続を続けることができます。

ノード間の通信にクラスタインターコネクトを使用するには、クラスタのインストール時に設定したプライベートホスト名をアプリケーションで使用する必要があります。たとえば、ノード 1 のプライベートホスト名が clusternode1_priv である場合、クラスタインターコネクトを経由してノード 1 と通信するときにこの名前を使用する必要があります。この名前を使用して開かれた TCP ソケットは、クラスタインターコネクトを経由するように経路指定され、ネットワークに障害が発生した場合でも、この TCP ソケットは透過的に再度経路指定されます。

複数のプライベートホスト名がインストール時に設定されているため、クラスタインターコネクトでは、その時点で選択した任意の名前を使用できます。実際の名前は、scha_cluster_get(3HA) に scha_privatelink_hostname_node 引数を指定することによって取得できます。

クラスタインターコネクトをアプリケーションレベルで使用する場合には、個々のノードペア間の通信に 1 つのインターコネクトが使用されます。ただし、可能であれば、別のノードペアには別のインターコネクトが使用されます。たとえば、3 つのノードで動作するアプリケーションが、クラスタインターコネクト経由で通信しているとします。この場合、たとえば、ノード 1 とノード 2 の通信にはインタフェース hme0 が、ノード 1 とノード 3 の通信にはインタフェース qfe1 がそれぞれ使用されます。つまり、アプリケーションによる 2 ノード間の通信は 1 つのインターコネクトに制限されますが、内部のクラスタ通信はすべてのインターコネクト上にストライプ化されます。

インターコネクトはアプリケーションと内部のクラスタトラフィックによって共有されるため、アプリケーションから使用できる帯域幅の量は、他のクラスタトラフィックに使用される帯域幅の量に左右されます。インターコネクトに障害が発生すると、内部トラフィックは残りのインターコネクト上にラウンドロビン方式で分散されますが、障害が発生したインターコネクト上のアプリケーションは動作しているインターコネクトに切り替えられます。

クラスタインターコネクトでは、2 つのタイプのアドレスがサポートされます。さらに、プライベートホスト名に対する gethgethostbyname(3N) では、通常 2 つの IP アドレスが返されます。最初のアドレスを「論理 pairwise アドレス」と呼び、2 番目のアドレスを「論理 pernode アドレス」と呼びます。

個々のノードペアには、異なる論理 pairwise アドレスが割り当てられます。この小規模な論理ネットワークでは、接続のフェイルオーバーがサポートされます。さらに、各ノードには、固定した pernode アドレスが割り当てられます。つまり、clusternode1-priv の論理 pairwise アドレスはノードごとに異なりますが、clusternode1-priv の論理 pernode アドレスは各ノードで同じです。ただし、個々のノードが pairwise アドレスを自分で持っているわけではないため、ノード 1 に gethostbyname(clusternode1-priv) を実行しても、論理 pernode アドレスだけが返されます

アプリケーションがクラスタインターコネクト経由の接続を受け入れ、セキュリティの目的で IP アドレスを検査する場合には、gethostbyname から返される最初の IP アドレスだけでなく、すべての IP アドレスを検査する必要があります。

アプリケーション全体にわたって一貫した IP アドレスが必要な場合は、クライアント側でもサーバー側でもその pernode アドレスにバインドするようにアプリケーションを設定します。これによって、すべての接続にこの pernode アドレスが使用されます。

リソース、リソースグループ、リソースタイプ

データサービスは、数種類のリソースを使用します。つまり、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 U1 データサービスのインストールと構成』を参照してください。

リソースおよびリソースグループの状態と設定値

リソースやリソースグループの値は管理者によって静的に設定されるため、これらの設定値を変更するには管理上の作業が必要です。RGM では、リソースグループの「状態」が動的に変更されます。次に、このような設定値と状態について説明します。

• managed (管理) または unmanaged (非管理) - クラスタ全体に適用されるこの設定値は、リソースグループだけに使用されます。リソースグループは RGM によって管理されます。リソースグループを管理または非管理にするには、scrgadm(1M) コマンドを使用します。これらの設定値は、クラスタ再構成では変更されません。

  新たに作成したリソースグループの状態は非管理になっています。このグループのいずれかのリソースをアクティブにするためには、リソースグループの状態が管理になっていなければなりません。

  スケーラブル Web サーバーなど、ある種のデータサービスでは、ネットワークリソースの起動前や停止後に、あるアクションが必要です。このアクションには、initialization (INIT) と finish (FINI) データサービスメソッドを使用します。INIT メソッドが動作するためには、リソースが置かれているリソースグループが管理状態になっていなければなりません。

  リソースグループを非管理から管理の状態に変更すると、そのグループに対して登録されている INIT メソッドがグループの各リソースに対して実行されます。

  リソースグループを管理から非管理の状態に変更すると、登録されている FINI メソッドが呼び出され、クリーンアップが行われます。

  INIT や FINI メソッドは、一般にスケーラブルサービスのネットワークリソースに対して使用されますが、これらのメソッドは、アプリケーションによって行われない任意の初期設定やクリーンアップにも使用できます。

• enabled (有効) または disabled (無効) - クラスタ全体に適用されるこの設定値は、リソースだけに使用されます。リソースを有効または無効にするには、scrgadm(1M) コマンドを使用します。これらの設定値は、クラスタ再構成では変更されません。

  リソースの通常の設定では、リソースは有効にされ、システムでアクティブに動作しています。

  何らかの理由であるリソースをすべてのクラスタノードで使用不能にする場合は、そのリソースを無効にします。無効にされたリソースは、一般的な使用には提供されません。

• online (オンライン) または offline (オフライン) - 動的に変更可能なこの状態は、リソースとリソースグループに適用されます。

  これらの状態は、スイッチオーバーやフェイルオーバーで行われるクラスタ再構成手順でクラスタの状態が変わるのに伴って変化します。さらに、これらの状態は、管理アクションによって変更することもできます。リソースやリソースグループをオンラインまたはオフライン状態に変更するには、scswitch(1M) を使用します。

  フェイルオーバーリソースまたはリソースグループは、オンラインにできるのはどの時点でも 1 つのノードだけです。スケーラブルリソースまたはリソースグループは、あるノードではオンラインにし、他のノードではオフラインにすることができます。スイッチオーバーやフェイルオーバーでは、リソースグループやリソースグループに属するリソースは、あるノードでオフラインにされてから、別のノードでオンラインにされます。

  あるリソースグループがオフラインであるなら、そのすべてのリソースもオフラインです。あるリソースグループがオンラインであるなら、有効にされているそのすべてのリソースもオンラインです。

  リソースグループにはいくつかのリソースを持つことができますが、リソース間には相互依存関係があります。したがって、これらのリソースをオンラインまたはオフラインにするときには、特定の順序で行う必要があります。リソースをオンラインまたはオフラインにするためにメソッドが必要とする時間は、リソースによって異なります。リソースの相互依存関係と起動や停止時間の違いにより、クラスタの再構成では、同じリソースグループのリソースでもオンラインやオフラインの状態が異なることがあります。

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

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

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

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

パブリックネットワーク管理 (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 U1 データサービスのインストールと構成』を参照してください。

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 U1 のシステム管理』のパブリックネットワークパラメータの変更手順を参照してください。

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

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