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

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

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

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

管理インタフェース

任意のユーザーインタフェースを使用して、SunPlex のインストール、構成、管理を行うことができます。システム管理作業は、SunPlex Manager グラフィックユーザーインタフェース (GUI) かコマンド行インタフェースから行います。コマンド行インタフェースでは、特定のインストール作業や構成作業を容易にする scinstall や scsetup などのユーティリティが使用できます。SunPlex システムには、Sun Management Center の一部として実行され、特定のクラスタ作業に GUI を提供するモジュールもあります。管理インタフェースの詳細については、『Sun Cluster 3.1 のシステム管理』の概要を説明している章を参照してください。

クラスタ内の時間

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

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

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

高可用性フレームワーク

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

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

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

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

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

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

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

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

• クラスタパーティション分割を処理します (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^TM 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 ソフトウェアフレームワークの制御下になければなりません。まず、ボリューム管理ソフトウェアのディスクグループ (Solaris Volume Manager ディスクセットまたは VERITAS Volume Manager ディスクグループ) を多重ホストディスクに作成します。次に、ボリューム管理ソフトウェアのディスクグループをディスクデバイスグループとして登録します。ディスクデバイスグループは、広域デバイスの一種です。さらに、Sun Cluster ソフトウェアは、個々のディスクデバイスやテープデバイスごとに raw ディスクデバイスグループを自動的に作成します。ただし、これらのクラスタデバイスグループは、広域デバイスとしてアクセスされるまではオフラインの状態になっています。

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

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

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

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

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

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

多重ポートディスクデバイスグループ

ここでは、多重ポートディスク構成において性能と可用性をバランスよく実現するディスクデバイスグループのプロパティについて説明します。 Sun Cluster ソフトウェアには、多重ポートディスク構成を設定するための 2 つのプロパティ preferenced と numsecondaries があります。preferenced プロパティを使用すると、フェイルオーバーの発生時に各ノードがどの順で制御を取得するかを制御できます。numsecondaries プロパティは、特定のデバイスグループに対する二次ノードの数を設定します。

高可用性サービスでは、主ノードが停止し、主ノードになる資格のある二次ノードがもはや存在しないときに、停止とみなされます。 サービスのフェイルオーバーが発生したときに、preferenced プロパティが true であった場合、ノードはノードリストの順番に従って、二次ノードを選択します。デバイスサービスの設定は、scsetup(1M) ユーティリティで動的に変更できます。従属サービスプロバイダ (広域ファイルシステムなど) に対応する設定には、デバイスサービスの設定が適用されます。

主ノードは、正常な運用時に二次ノードのチェックポイントをとります。 多重ポートディスク構成では、二次ノードのチェックポイントをとるたびに、クラスタの性能の低下やメモリーのオーハーヘッドの増加が発生します。このようなチェックポイントによる性能の低下やオーバーヘッドの増加を最小限に抑えるためにスペアノードのサポートが実装されています。ディスクデバイスグループには、デフォルトで 1 つの主ノードと 1 つの二次ノードがあります。使用可能な残りのプロバイダノードはスペア状態でオンラインになります。フェイルオーバーが発生すると、二次ノードが主ノードになり、ノードリスト上で最も優先度の高いノードが二次ノードになります。

望ましい二次ノードの数には、1 から、デバイスグループにある動作可能な非主プロバイダノードの数までの任意の整数を設定できます。

Solaris ボリューム管理ソフトウェアを使用する場合は、ディスクデバイスグループを作成後にのみ numsecondaries プロパティにデフォルト以外の数を設定することができます。

デバイスサービスのためのデフォルトの望ましい二次ノード数は 1 です。望ましい数とは、複製フレームワークによって維持される二次プロバイダの実際の数です。ただし、動作可能な非主プロバイダの数が望ましい数よりも小さい場合を除きます。構成に対してノードの追加や切り離しを行う場合には、 numsecondaries プロパティを変更してからノードリストを十分に確認する必要があります。ノードリストと望ましい二次ノード数を正しく保つことは、構成された二次ノード数と、フレームワークによって与えられる実際の数の不一致を防ぐ上で有効です。構成に対してノードの追加や切り離しを行う場合は、VxVM ディスクデバイスグループの scconf(1M) コマンドか Solaris Volume Manager デバイスグループの metaset(1M) コマンドと、preferenced および numsecondaries プロパティの設定を使用します。ディスクデバイスグループのプロパティを変更する手順については、『 Sun Cluster 3.1 のシステム管理』の「広域デバイスとクラスタファイルシステムの管理」を参照してください。

広域名前空間

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

通常、ボリューム管理ソフトウェアの名前空間は、Solaris Volume Manager の場合は、/dev/md/diskset/dsk (および rdsk) ディレクトリに、VxVM の場合は、/dev/vx/dsk/ disk-group ディレクトリと /dev/vx/rdsk/disk-group ディレクトリにそれぞれ配置されています。これらの名前空間は、クラスタ全体にインポートされた Solaris Volume Manager の各ディスクセットと 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 システムでは、すべての多重ホストディスクがディスクデバイスグループとして構成されています。これは、Solaris Volume Manager ディスクセット、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.1 ソフトウェアのインストール』と『 Sun Cluster 3.1 のシステム管理』を参照してください。

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

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

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

  ---

  注 –

  クラスタファイルシステムはファイルを読み取るときにファイルのアクセス時間を更新しません。

  ---

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

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

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

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

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

HAStoragePlus リソースタイプ

HAStoragePlus リソースタイプは、UFS や VxFS などの広域的ではないファイルシステム構成を高可用対応にするように設計されています。HAStoragePlus は、ローカルファイルシステムを Sun Cluster 環境に統合してそのファイルシステムを高可用対応にする場合に使用します。 HAStoragePlus は、Sun Cluster でローカルファイルシステムのフェイルオーバーを行うための付加的なファイルシステム機能 (チェック、マウント、強制的なマウント解除など) を提供します。フェイルオーバーを行うには、アフィニティスイッチオーバーが有効になった広域ディスクグループ上にローカルファイルシステムが存在していなければなりません。

HAStoragePlusリソースタイプの使用方法については、『Sun Cluster 3.1 データサービスのインストールと構成』の個々のデータサービスの章か、第 14 章「データサービスリソースの管理」の「高可用性ローカルファイルシステムを有効にする」を参照してください。

HAStoragePlus は、リソースと、そのリソースが依存しているディスクデバイスグループを同時に起動するためにも使用できます。詳細については、リソース、リソースグループ、リソースタイプを参照してください。

Syncdir マウントオプション

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

VxFS には、UFS 用の syncdir マウントオプションに相当するマウントオプションはありません。VxFS の動作は syncdir マウントオプションを指定しない場合の UFS と同じです。

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

ディスクパスの監視

現在のリリースの Sun Cluster ソフトウェアはディスクパスの監視 (Disk-Path Monitoring: DPM) をサポートします。この節では、DPM、DPM デーモン、およびディスクパスを監視するときに使用する管理ツールについての概念的な情報を説明します。ディスクパスの状態を監視、監視解除、および表示する手順については、『 Sun Cluster 3.1 10/03 のシステム管理』を参照してください。

Sun Cluster 3.1 5/03 software より前にリリースされたバージョンが動作しているノードは DPM をサポートしません。 ローリングアップグレードの進行中には、DPM コマンドを使用することはできません。すべてのノードのアップグレードが完了した後、DPM コマンドを使用するには、そのノードがオンラインである必要があります。

概要

DPM は、二次ディスクパスの可用性を監視することによって、フェイルオーバーおよびスイッチオーバーの全体的な信頼性を向上させます。リソースを切り替える前には、scdpm コマンドを使用して、そのリソースが使用しているディスクパスの可用性を確認します。scdpm コマンドのオプションを使用すると、クラスタ内の単一またはすべてのノードへのディスクパスを監視できます。コマンド行オプションの詳細については、scdpm(1M)のマニュアルページを参照してください。

DPM コンポーネントは SUNWscu パッケージからインストールされます。SUNWscu パッケージは標準の Sun Cluster インストール手順でインストールされます。インストールインタフェースの詳細については、scinstall(1M) のマニュアルページを参照してください。次の表に、DPM コンポーネントのデフォルトのインストール場所を示します。

マルチスレッド化された DPM デーモンは各ノード上で動作します。DPM デーモン (scdpmd) はノードの起動時に rc.d スクリプトによって起動されます。問題が発生した場合、DPM デーモンは pmfd によって管理され、自動的に再起動されます。次のリストに、scdpmd が初期起動時にどのように動作するかを説明します。

起動時、各ディスクパスの状態は UNKNOWN に初期化されます。

1. DPM は、以前の状態ファイルまたは CCR データベースから、ディスクパスとノード名の情報を収集します。CCR の詳細については、クラスタ構成レポジトリ (CCR)を参照してください。DPM デーモンの起動後、指定したファイルから監視すべきディスクのリストを読み取るように DPM デーモンに指示できます。

2. DPM デーモンは通信インタフェースを初期化して、デーモンの外部にあるコンポーネント (コマンド行インタフェースなど) からの要求に応えます。

3. DPM デーモンは scsi_inquiry コマンドを使用して、監視リストにある各ディスクパスに 10 分ごとに ping を送信します。各エントリはロックされるため、通信インタフェースは監視中のエントリの内容にアクセスできなくなります。

4. DPM デーモンは UNIX の syslogd(1M) 機構を通じて、ディスクパスの新しい状態を Sun Cluster Event Framework に通知および記録します。

DPM デーモンに関連するすべてのエラーは pmfd(1M) によって報告されます。API のすべての関数は、成功時に 0 を戻し、失敗時に -1 を戻します。

DPM デーモンは、MPxIO、HDLM、PowerPath などのマルチパスドライバを通じて論理パスの可用性を監視します。このようなマルチパスドライバは物理パスの障害を DPM デーモンから隠すため、DPM デーモンはマルチパスドライバが管理する物理パスを監視できません。

ディスクパスの監視

この節では、クラスタ内のディスクパスを監視するための 2 つの方法について説明します。1 つめの方法は scdpm コマンドを使用する方法です。scdpm コマンドを使用すると、クラスタ内のディスクパスの状態を監視、監視解除、または表示できます。また、scdpm コマンドは障害が発生したディスクのリストを表示したり、1 つのファイルからディスクパスを監視するときにも使用できます。

2 つめの方法は、SunPlex Manager の GUI (Graphical User Interface) を使用してクラスタ内のディスクパスを監視する方法です。SunPlex Manager は、クラスタ内の監視しているディスクをトポロジビューで表示します。このトポロジビューは 10 分ごとに更新され、失敗した ping の数が表示されます。SunPlex Manager の GUI が報告する情報と scdpm(1M) コマンドを組み合わせて使用すると、ディスクパスを管理できます。SunPlex Manager については、『Sun Cluster 3.1 10/03 のシステム管理』の「グラフィカルユーザーインタフェースによる Sun Cluster の管理」を参照してください。

scdpm コマンドによるディスクパスの監視

scdpm(1M) コマンドが提供する DPM 管理コマンドを使用すると、次の作業を行うことができます。

• 新しいディスクパスの監視

• ディスクパスの監視解除

• CCR データベースからの構成データの再読み込み

• 指定したファイルからの監視または監視解除すべきディスクの読み取り

• クラスタ内の 1 つまたはすべてのディスクパスの状態の報告

• あるノードからアクセスできるすべてのディスクパスの印刷

任意のアクティブなノードから、ディスクパス引数を付けて scdpm(1M) コマンドを発行することによって、そのクラスタ上で DPM 管理作業を実行できます。ディスクパス引数は常に、ノード名とディスク名から構成されます。ノード名は必須ではなく、指定しない場合はデフォルトで all が使用されます。次の表に、ディスクパスの命名規約を示します。

広域ディスクパス名はクラスタを通じて一貫しているため、広域ディスクパス名の使用を強くお勧めします。UNIX ディスクパス名はクラスタを通じて一貫性がありません。あるディスクの UNIX ディスクパス名はクラスタノード間で異なる場合があります。たとえば、 ディスクパス名があるノードでは c1t0d0 となっており、別のノードでは c2t0d0 となっている可能性があります。UNIX ディスクパス名を使用する場合は、scdidadm -L コマンドを使用して UNIX ディスクパス名を広域ディスクパス名にマッピングしてから、DPM コマンドを実行してください。scdidadm(1M) のマニュアルページも参照してください。

SunPlex Manager によるディスクパスの監視

SunPlex Manager を使用すると、次のような DPM の基本的な管理作業を実行できます。

• ディスクパスの監視

• ディスクパスの監視解除

• クラスタ内のすべてのディスクパスの状態の表示

SunPlex Manager を使用してディスクパスを管理する手順については、SunPlex Manager のオンラインヘルプを参照してください。

定足数と定足数デバイス

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

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

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

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

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

定足数投票数

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

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

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

定足数デバイスは、現在接続されている少なくとも 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.1 ソフトウェアのインストール』の計画に関する章を参照してください。

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

障害による影響の防止

クラスタの主要な問題は、クラスタがパーティション分割される (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 には、独自の内部ボリューム管理ソフトウェアコンポーネントはありませんが、次のボリューム管理ソフトウェアに依存しています。

• Solaris Volume Manager

• VERITAS Volume Manager

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

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

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

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

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

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

データサービス

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

• 開始

• 停止

• 監視と訂正手段の実行

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

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

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

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

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

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

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

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

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

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

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

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

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

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

データサービスメソッド

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

クラスタネットワーキングの主な目的は、データサービスにスケーラビリティを提 供することにあります。 スケーラビリティとは、サービスに提供される負荷が増えたときに、新しいノードがクラスタに追加されて新しいサーバーインスタンスが実行されるために、データサービスがこの増加した負荷に対して一定の応答時間を維持できるということを示します。このようなサービスをスケーラブルデータサービスと呼びます。スケーラブルデータサービスの例としては、Web サービスがあります。通常、スケーラブルデータサービスはいくつかのインスタンスからなり、それぞれがクラスタの異なるノードで実行されます。これらのインスタンスはリモートクライアントから見ると 1 つのサービスとして動作し、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 が設定されます。

  ウェイト設定したポリシーは、一定の割合のクライアントトラフィックを特定ノードに送るためのものです。たとえば、X=「ウエイト」、A=「すべてのアクティブノードの合計ウエイト」であるとします。アクティブノードでは、新しい接続数の合計の約 X/A がこのアクティブノードに送られると予測できます。 ただし、この場合接続数の合計が十分に大きな数であるとします。このポリシーは、個々の要求には対応しません。

  このポリシーは、ラウンドロビンではないことに注意してください。ラウンドロビンポリシーでは、クライアントからの各要求が、最初の要求はノード 1、2 番目の要求はノード 2 といったように常に異なるノードに送られます。

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

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

フェイルバック設定

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

データサービスAPI とデータサービス開発ライブラリ API

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

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

• データサービス API

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

• 汎用データサービス

『Sun Cluster 3.1 データサービスのインストールと構成』は、SunPlex システムで提供されるデータサービスをインストール、構成する方法を説明しています。 『Sun Cluster 3.1 データサービス開発ガイド』には、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 つのタイプのアドレスがサポートされます。さらに、プライベートホスト名に対する gethostbyname(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 や Sun ONE Web Server などのアプリケーションは、それらのアプリケーションが依存するネットワークアドレス (論理ホスト名と共有アドレス) を使用します。アプリケーションとネットワークリソースは、RGM が管理する基本ユニットを形成します。

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

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

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

SUNW.HAStorage および HAStoragePlus リソースタイプは、リソースと、そのリソースが依存しているディスクデバイスグループの起動を同期させるために使用します。この同期をとることで、データサービスの起動前にクラスタファイルシステムのマウントポイント、広域デバイス、およびデバイスグループ名のパスが利用可能になります。詳細は、『Sun Cluster 3.1 データサービスのインストールと構成』の「リソースグループとディスクデバイスグループ間の起動の同期」を参照してください。HAStoragePlus は Sun Cluster 3.0 5/02 で追加されたリソースタイプであり、ローカルファイルシステムを高可用対応にする新たな機能を備えています。この機能の詳細については、HAStoragePlus リソースタイプを参照してください。

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

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

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

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

RGM は「リソース」と「リソースグループ」に作用します。リソースやリソースグループは、 RGM のアクションに従ってオンラインになったり、オフラインになります。リソースやリソースグループに適用される状態や設定値の詳細は、リソースおよびリソースグループの状態と設定値を参照してください。RGM 制御の下でリソース管理プロジェクトを起動する方法については、リソース、リソースグループ、リソースタイプを参照してください。

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

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

• managed (管理) または unmanaged (非管理) - クラスタ全体に適用されるこの設定値は、リソースグループだけに使用されます。リソースグループは RGM によって管理されます。リソースグループを 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.1 データサービスのインストールと構成』の付録を参照してください。

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

データサービスプロジェクトの構成

RGM を使ってデータサービスをオンラインにするときに、これを特定の Solaris プロジェクト名の下で起動することができます。そのためには、データサービスを構成するときに、RGM によって管理されるリソースまたはリソースグループと Solaris プロジェクト ID を対応付ける必要があります。リソースまたはリソースグループとプロジェクト ID を対応付けることによって、ユーザーは、Solaris 環境で提供される高度なコントロールを使ってクラスタ内の負荷や使用量を管理できるようになります。

この構成を行うためには、Sun Cluster ソフトウェアの最新リリースと Solaris 9 が必要です。

ノードを他のアプリケーションと共有している場合には、クラスタ環境で Solaris 管理機能を使用することによって、最も重要なアプリケーションに高い優先度を与えることができます。ノードを複数のアプリケーションで共有する例としては、サービスを統合した場合や、アプリケーションのフェイルオーバーが起った場合があります。ここで述べる管理機能を使用すれば、優先度の低いアプリケーションが CPU 時間などのシステムサプライを過度に使用するのを防止し、重要なアプリケーションの性能を高めることができます。

この機能に関連する Solaris のマニュアルでは、CPU 時間、プロセス、タスクや、これに類するコンポーネントを「リソース」と呼んでいます。一方、Sun Cluster のマニュアルでは、RGM の制御下にあるエンティティを「リソース」と呼んでいます。ここでは、RGM の制御下にある Sun Cluster エンティティを「リソース」と呼び、CPU 時間やプロセス、タスクなどを「サプライ」と呼びます。

以下の説明は、プロセスを指定した Solaris 9 の project(4) で起動するようにデータサービスを構成する方法を概念的に述べたものです。さらに、以下の説明では、Solaris 環境の管理機能を使用するために必要なフェイルオーバーのシナリオやヒントについて述べます。管理機能の概念や手順については、『Solaris 9 System Administrator Collection.』の『Solaris のシステム管理 (資源管理とネットワークサービス)』を参照してください。

クラスタ内で Solaris 管理機能を使用できるようにリソースやリソースグループを構成するための手順は次のようになります。

1. アプリケーションをリソースの一部として構成します。

2. リソースをリソースグループの一部として構成します。

3. リソースグループのすべてのリソースを有効にします。

4. リソースグループを管理可能にします。

5. リソースグループに対する Solaris プロジェクトを作成します。

6. ステップ 5 で作成したプロジェクトとリソースグループ名を対応付けるために標準プロパティを構成します。

7. リソースグループをオンラインにします。

標準の Resource_project_name または RG_project_name プロパティを使って Solaris プロジェクト ID とリソースまたはリソースグループを対応付ける場合には、scrgadm(1M) コマンドに -y オプションを指定する必要があります。続いて、プロパティの値にリソースまたはリソースグループを設定します。プロパティの定義については、『 Sun Cluster 3.1 データサービスのインストールと構』の「標準プロパティ」を参照してください。 プロパティの説明については、 r_properties(5) と rg_properties(5) を参照してください。

指定するプロジェクト名はプロジェクトデータベース (/etc/project) に存在するものでなければなりません。さらに、指定するプロジェクトのメンバーとして root ユーザーが設定されていなければなりません。プロジェクト名データベースの概要については、『Solaris 9 System Administrator Collection』の『 Solaris のシステム管理 (資源管理とネットワークサービス)』の「プロジェクトとタスク」を参照してください。プロジェクトファイルの構文については、project(4) を参照してください。

RGM は、リソースまたはリソースグループをオンラインにする際に、関連するプロセスをこのプロジェクト名の下で起動します。

リソースまたはリソースグループとプロジェクトを対応付けることはいつでもできます。ただし、新しいプロジェクト名を有効にするためには、RGM を使ってプロジェクトのリソースやリソースグループをオフラインにしてから再びオンラインに戻す必要があります。

リソースやリソースグループをプロジェクト名の下で起動すれば、次の機能を構成することによってクラスタ全体のシステムサプライを管理できます。

• 拡張アカウンティング – 使用量をタスクやプロセス単位で記録できるため柔軟性が増します。拡張アカウンティングでは、使用状況の履歴を調べ、将来の作業負荷の容量要件を算定できます。

• 制御 – システムサプライの使用を制約する機構を提供します。これにより、プロセス、タスク、およびプロジェクトが特定のシステムサプライを大量に消費することを防止できます。

• フェアシェアスケジューリング (FSS) – それぞれの作業負荷に割り当てる CPU 時間を作業負荷の重要性に基づいて制御できます。作業負荷の重要性は、各作業負荷に割り当てる、CPU 時間のシェア数として表されます。FSS をデフォルトのスケジューラとして設定するためのコマンド行インタフェースについては、dispadmin(1M) のマニュアルページを参照してください。さらに、priocntl(1)、ps(1)、FSS(7) のマニュアルページも参照してください。

• プール – アプリケーションの必要性に応じて対話型アプリケーション用に仕切りを使用することができます。プールを使用すれば、サーバーを仕切り分けすることができ、同じサーバーで異なるソフトウェアアプリケーションをサポートできます。プールを使用すると、アプリケーションごとの応答が予測しやすくなります。

プロジェクト構成に応じた要件の決定

Sun Cluster 環境で Solaris での制御を使用してデータサービスを構成する場合は、スイッチオーバーやフェイルオーバーの際にリソースの制御や管理をどのように行うかを決める必要があります。まず、新しいプロジェクトを構成する前にクラスタ内の依存関係を明確にします。たとえば、リソースやリソースグループはディスクデバイスグループに依存しています。次に、scrgadm(1M) で設定された nodelist、 failback、maximum_primaries、desired_primaries リソースグループプロパティを使って、使用するリソースグループのノードリスト優先度を確認します。リソースグループとディスクデバイスグループの間におけるノードリスト依存関係の簡単な説明については、『 Sun Cluster 3.1 データサービスのインストールと構』の「リソースグループとディスクデバイスグループの関連性」を参照してください。プロパティの詳しい説明については、rg_properties(5) のマニュアルページを参照してください。

scrgadm(1M) や scsetup(1M) で構成された preferenced および failback プロパティを使って、ディスクデバイスグループのノードリスト優先度を判別します。この手順については、『 Sun Cluster 3.1 10/03 のシステム管理』の「ディスクデバイスグループの管理」の「ディスクデバイスのプロパティを変更する」を参照してください。ノード構成の概念やフェイルオーバーおよびスケーラブルデータサービスの動作については、SunPlex システムハードウェアコンポーネントを参照してください。

すべてのクラスタノードを同じように構成すると、主ノードと二次ノードに対して同じ使用限度が割り当てられます。 各プロジェクトの構成パラメータは、すべてのノードの構成ファイルに定義されているすべてのアプリケーションに対して同じである必要はありません。特定のアプリケーションに対応するすべてのプロジェクトは、少なくとも、そのアプリケーションのすべての潜在的マスターにあるプロジェクトデータベースからアクセス可能でなければなりません。たとえば、アプリケーション 1 は phys-schost-1 によってマスターされているが、phys-schost-2 や phys-schost-3 にスイッチオーバーまたはフェイルオーバーされる可能性があるとします。アプリケーション 1 に対応付けられたプロジェクトは、これら 3 つのノード (phys-schost-1、phys-schost-2、phys-schost-3) 上でアクセス可能でなければなりません。

プロジェクトデータベース情報は、ローカルの /etc/project データベースファイルに格納することも、NIS マップや LDAP ディレクトリサーバー に格納することもできます。

Solaris 環境では、使用パラメータの柔軟な構成が可能です。Sun Cluster によって課せられる制約はほとんどありません。 どのような構成を選択するかはサイトの必要性によって異なります。システムの構成を始める前に、次の各項の一般的な指針を参考にしてください。

プロセス当たりの仮想メモリー制限の設定

仮想メモリーの制限をプロセス単位で制御する場合は、process.max-address-space コントロールを使用します。process.max-address-space 値の設定方法については、rctladm(1M) のマニュアルページを参照してください。

Sun Cluster で制御機能を使用する場合は、アプリケーションの不要なフェイルオーバーが発生したり、アプリケーションの「ピンポン」現象が発生するのを防止するためにメモリー制限を適切に設定する必要があります。そのためには、一般に次の点に注意する必要があります。

• メモリー制限をあまり低く設定しない。

  アプリケーションは、そのメモリーが限界に達すると、フェイルオーバーを起こすことがあります。データベースアプリケーションにとってこの指針は特に重要です。その仮想メモリーが限界を超えると予期しない結果になることがあるからです。

• 主ノードと二次ノードに同じメモリー制限を設定しない。

  同じメモリー制限を設定すると、アプリケーションのメモリーが限度に達し、アプリケーションが、同じメモリー制限をもつ二次ノードにフェイルオーバーされたときに「ピンポン」現象を引き起こすおそれがあります。そのため、二次ノードのメモリー制限には、主ノードよりもわずかに大きな値を設定します。異なるメモリー制限を設定することによって「ピンポン」現象の発生を防ぎ、管理者はその間にパラメータを適切に変更することができます。

• 負荷均衡を達成する目的でリソース管理メモリー制限を使用する。

  たとえば、メモリー制限を使用すれば、アプリケーションが誤って過度のスワップ領域を使用することを防止できます。

フェイルオーバーシナリオ

管理パラメータを適切に構成すれば、プロジェクト構成 (/etc/project) 内の割り当ては、通常のクラスタ操作でも、スイッチオーバーやフェイルオーバーの状況でも正常に機能します。

以下の各項ではシナリオ例を説明します。

• 最初の「2 つのアプリケーションを供う 2 ノードクラスタ」と「3 つのアプリケーションを供う 2 ノードクラスタ」の項では、すべてのノードが関係するフェイルオーバーシナリオを説明します。

• 「リソースグループだけのフェイルオーバー」の項では、アプリケーションだけのフェイルオーバー操作について説明します。

クラスタ環境では、アプリケーションはリソースの一部として構成され、リソースはリソースグループ (RG) の一部として構成されます。障害が発生すると、対応付けられたアプリケーションと共にリソースグループが別のノードにフェイルオーバーされます。以下の例では、リソースは明示的に示されていません。各リソースには、1 つのアプリケーションが構成されているものとします。

フェイルオーバーは、RGM に設定されているノードリスト内の優先順位に従って行われます。

以下の例は次のように構成されています。

• アプリケーション 1 (App-1) はリソースグループ RG-1 に構成されています。

• アプリケーション 2 (App-2) はリソースグループ RG-2 に構成されています。

• アプリケーション 3 (App-3) はリソースグループ RG-3 に構成されています。

フェイルオーバーが起こると、各アプリケーションに割り当てられる CPU 時間の割合が変化します。ただし、割り当てられているシェアの数はそのままです。この割合は、そのノードで動作しているアプリケーションの数と、アクティブな各アプリケーションに割り当てられているシェアの数によって異なります。

これらのシナリオでは、次のように構成が行われているものとします。

• すべてのアプリケーションが共通のプロジェクトの下に構成されています。

• 各リソースには 1 つのアプリケーションがあります。

• すべてのノードにおいて、アクティブなプロセスはこれらのアプリケーションだけです。

• プロジェクトデータベースは、クラスタの各ノードで同一に構成されています。

2 つのアプリケーションを供う 2 ノードクラスタ

2 ノードクラスタに 2 つのアプリケーションを構成することによって、それぞれの物理ホスト (phys-schost-1、 phys-schost-2) を 1 つのアプリケーションのデフォルトマスターにすることができます。一方の物理ホストは、他方の物理ホストの二次ノードになります。アプリケーション 1 とアプリケーション 2 に関連付けられているすべてのプロジェクトは、両ノードのプロジェクトデータベースファイルに存在していなければなりません。クラスタが正常に動作している間、各アプリケーションはそれぞれのデフォルトマスターで動作し、管理機能によってすべての CPU 時間を割り当てられます。

フェイルオーバーかスイッチオーバーが起ると、これらのアプリケーションは同じノードで動作し、構成ファイルの設定に従ってシェアを割り当てられます。たとえば、 /etc/project ファイルに次のエントリが指定されていると、アプリケーション 1 に 4 シェアが、アプリケーション 2 に 1 シェアがそれぞれ割り当てられます。

Prj_1:100:project for App-1:root::project.cpu-shares=(privileged,4,none)
Prj_2:101:project for App-2:root::project.cpu-shares=(privileged,1,none)

次の図は、この構成の正常時の動作とフェイルオーバー時の動作を表しています。割り当てられているシェアの数は変わりません。ただし、各アプリケーションに与えられる CPU 時間の割合は、CPU 時間を要求する各プロセスに割り当てられているシェア数によって異なります。

3 つのアプリケーションを供う 2 ノードクラスタ

3 つのアプリケーションが動作する 2 ノードクラスタでは、1 つの物理ホスト (phys-schost-1) を 1 つのアプリケーションのデフォルトマスターとして構成し、もう 1 つの物理ホスト (phys-schost-2) を他の 2 つのアプリケーションのデフォルトマスターとして構成できます。各ノードには、次のサンプルプロジェクトデータベースファイルがあるものとします。フェイルオーバーやスイッチオーバーが起っても、プロジェクトデータベースファイルが変更されることはありません。

Prj_1:103:project for App-1:root::project.cpu-shares=(privileged,5,none)
Prj_2:104:project for App_2:root::project.cpu-shares=(privileged,3,none) 
Prj_3:105:project for App_3:root::project.cpu-shares=(privileged,2,none)  

クラスタが正常に動作している間、アプリケーション 1 には、そのデフォルトマスター phys-schost-1 で 5 シェアが割り当てられます。このノードで CPU 時間を要求するアプリケーションはこのアプリケーションだけであるため、この数は 100 パーセントの CPU 時間と同じことです。アプリケーション 2 と 3 には、それぞれのデフォルトマスターである phys-schost-2 で 3 シェアと 2 シェアが割り当てられます。したがって、正常な動作では、アプリケーション 2 に CPU 時間の 60 パーセントが、アプリケーション 3 に CPU 時間の 40 パーセントがそれぞれ割り当てられます。

フェイルオーバーかスイッチオーバーが起り、アプリケーション 1 が phys-schost-2 に切り替えられても、3 つのアプリケーションの各シェアは変わりません。ただし、割り当てられる CPU リソースの割合はプロジェクトデータベースファイルに従って変更されます。

• 5 シェアをもつアプリケーション 1 には CPU の 50 パーセントが割り当てられます。

• 3 シェアをもつアプリケーション 2 には CPU の 30 パーセントが割り当てられます。

• 2 シェアをもつアプリケーション 3 には CPU の 20 パーセントが割り当てられます。

次の図は、この構成の正常な動作とフェイルオーバー動作を示しています。

リソースグループだけのフェイルオーバー

複数のリソースグループが同じデフォルトマスターに属している構成では、1 つのリソースグループ (および、それに関連付けられたアプリケーション) が 二次ノードにフェイルオーバーされたり、スイッチオーバーされることがあります。その間、クラスタのデフォルトマスターは動作を続けます。

フェイルオーバーの際、フェイルオーバーされるアプリケーションには、二次ノード上の構成ファイルの指定に従ってリソースが割り当てられます。この例の場合、主ノードと二次ノードのプロジェクトデータベースファイルの構成は同じです。

次のサンプル構成ファイルでは、アプリケーション 1 に 1 シェア、アプリケーション 2 に 2 シェア、アプリケーション 3 に 2 シェアがそれぞれ割り当てられています。

Prj_1:106:project for App_1:root::project.cpu-shares=(privileged,1,none)
Prj_2:107:project for App_2:root::project.cpu-shares=(privileged,2,none)
Prj_3:108:project for App_3:root::project.cpu-shares=(privileged,2,none)
 

以下の図は、この構成の正常時の動作とフェイルオーバー時の動作を表しています。ここでは、アプリケーション 2 が動作する RG-2 が phys-schost-2 にフェイルオーバーされます。割り当てられているシェアの数は変わりません。ただし、各アプリケーションに与えられる CPU 時間の割合は、CPU 時間を要求する各アプリケーションに割り当てられているシェア数によって異なります。

パブリックネットワークアダプタと IP ネットワークマルチパス

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

パブリックネットワークアダプタを監視したり、障害の発生時に IP アドレスをあるアダプタから別のアダプタにフェイルオーバーする基本的な機構は、Sun Cluster で動作する Solaris インターネットプロトコル (IP) ソフトウェアが提供します。各クラスタノードには独自の IP ネットワークマルチパス構成があり、これは他のクラスタノードと異なります。

パブリックネットワークアダプタは、IP マルチパスグループ (マルチパスグループ) として編成されます。 各マルチパスグループには、1 つまたは複数のパブリックネットワークアダプタがあります。マルチパスグループの各アダプタはアクティブにすることができます。あるいは、スタンバイインタフェースを構成し、フェイルオーバーが起こるまでそれらを非アクティブにしておくことができます。in.mpathd マルチパスデーモンは、テスト IP アドレスを使って障害や修復を検出します。マルチパスデーモンによってアダプタの 1 つに障害が発生したことが検出されると、フェイルオーバーが行われます。すべてのネットワークアクセスは、障害のあるアダプタからマルチパスグループの別の正常なアダプタにフェイルオーバーされます。これによって、そのノードのパブリックネットワーク接続が維持されます。デーモンは、スタンバイインタフェースが構成されていれば、このスタンバイインタフェースを選択します。そうでない場合、in.mpathd は、最も小さい IP アドレス番号を持つインタフェースを選択します。フェイルオーバーはアダプタインタフェースレベルで行われるため、フェイルオーバー時の一時的な短い遅れを除き、TCP など高レベルの接続への影響はありません。IP アドレスのフェイルオーバーが正常に終了すると、自動的に ARP ブロードキャストが送信されます。したがって、遠隔クライアントへの接続は維持されます。

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

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

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

IP ネットワークマルチパスが Solaris にどのように実装されているかについては、クラスタにインストールされている Solaris オペレーティング環境のマニュアルを参照してください。

動的再構成のサポート

Sun Cluster 3.1 による動的再構成 (DR: Dynamic Reconfiguration) ソフトウェア機能のサポートは段階的に開発されています。この節では、Sun Cluster 3.1 による DR 機能のサポートの概念と考慮事項について説明します。

Solaris の DR 機能の説明で述べられているすべての必要条件、手順、制限は Sun Cluster の DR サポートにも適用されます (オペレーティング環境の休止操作を除く)。したがって、Sun Cluster ソフトウェアで DR 機能を使用する前に、必ず、Solaris の DR 機能についての説明を参照してください。特に、DR Detach 操作中に、ネットワークに接続されていない入出力デバイスに影響する問題について確認してください。『Sun Enterprise 10000 Dynamic Reconfiguration ユーザーマニュアル』と『Sun Enterprise 10000 Dynamic Reconfiguration リファレンスマニュアル』が、http://docs.sun.com で参照できます。

動的再構成の概要

DR 機能では、システムハードウェアの切り離しなどの操作をシステムの稼動中に行うことができます。 DR プロセスの目的は、システムを停止したり、クラスタの可用性を中断したりせずにシステム操作を継続できるようにすることです。

DR はボードレベルで機能します。したがって、DR 操作は、ボードのすべてのコンポーネントに影響を及ぼします。ボードには、CPU やメモリー、ディスクドライブやテープドライブ、ネットワーク接続の周辺機器インタフェースなど、複数のコンポーネントが取り付けられています。

アクティブなコンポーネントを含むボードを切り離すと、システムエラーになります。DR サブシステムは、ボードを切り離す前に、他のサブシステム (Sun Cluster など) に問い合わせてボード上のコンポーネントが使用されているかを判別します。ボードが使用中であることがわかると、DR のボード切り離し操作は行われません。したがって、DR のボード切り離し操作はいつ行ってもかまいません。DR サブシステムが、アクティブなコンポーネントを含むボードに対する操作を拒否するからです。

同様に、DR のボード追加操作も常に安全です。新たに追加されたボードの CPU とメモリーは、システムによって自動的にサービス状態になります。ただし、そのボードのコンポーネントを使用するには、クラスタを手動で構成する必要があります。

DR サブシステムにはいくつかのレベルがあります。下位のレベルがエラーを報告すると、上位のレベルもエラーを報告します。 しかし、下位のレベルがエラーを特定しても、上位のレベルが「原因不明のエラー (Unknown Error)」と報告することがあります。この上位レベルのエラーは無視してください。

次の各項では、デバイスタイプごとに DR の注意事項を説明します。

CPU デバイスに関する DR クラスタリングの考慮点

Sun Cluster ソフトウェアは、CPU デバイスが存在するために DR のボード切り離し操作を拒否することはありません。

DR のボード追加操作が正常に終わると、追加されたボードの CPU デバイスは自動的にシステム操作に組み込まれます。

メモリーに関する DR クラスタリングの考慮点

DR では、メモリーを 2 種類に分けて考える必要があります。これらの違いはその使用方法だけであり、実際のハードウェアは同じものです。

オペレーティングシステムが使用するメモリーは、カーネルメモリーケージと呼ばれます。Sun Cluster ソフトウェアは、カーネルメモリーケージを含むボードに対するボード切り離し操作をサポートしていないため、このような操作を拒否します。DR のボード切り離し操作がカーネルメモリーケージ以外のメモリーに関連するものである場合、Sun Cluster はこの操作を拒否しません。

メモリーに関連する DR のボード追加操作が正常に終わると、追加されたボードのメモリーは自動的にシステム操作に組み込まれます。

ディスクドライブやテープドライブに関連する DR クラスタリングの考慮点

Sun Cluster は、主ノードのアクティブなドライブに対する DR のボード切り離し操作を拒否します。DR のボード切り離し操作を実行できるのは、主ノードのアクティブでないドライブや二次ノードのドライブの場合だけです。 DR 操作が終了すると、クラスタのデータアクセスが前と同じように続けられます。

Sun Cluster は、定足数デバイスの使用に影響を与える DR 操作を拒否します。定足数デバイスの考慮事項と、定足数デバイスに対する DR 操作の実行手順については、定足数デバイスに関連する DR クラスタリングの考慮点を参照してください。

詳細な手順については、『Sun Cluster 3.1 のシステム管理』を参照してください。

定足数デバイスに関連する DR クラスタリングの考慮点

DR のボード切り離し操作が、定足数デバイスとして構成されているデバイスへのインタフェースを含むボードに関連する場合、Sun Cluster はこの操作を拒否し、この操作によって影響を受ける定足数デバイスを特定します。定足数デバイスとしてのデバイスに対して DR のボード切り離し操作を行う場合は、まずそのデバイスを無効にする必要があります。

詳細な手順については、『Sun Cluster 3.1 のシステム管理』を参照してください。

クラスタインターコネクトに関連する DR クラスタリングの考慮点

DR のボード切り離し操作が、アクティブなクラスタインターコネクトインタフェースを含むボードに関連する場合、Sun Cluster はこの操作を拒否し、この操作によって影響を受けるインタフェースを特定します。DR 操作を行うためには、Sun Cluster 管理ツールを使ってアクティブなインタフェースを無効にする必要があります (下記の注意も参照)。

詳細な手順については、『Sun Cluster 3.1 のシステム管理』を参照してください。

Sun Cluster の個々のクラスタノードには、他のすべてのクラスタノードに対する有効なパスが、少なくとも 1 つは存在していなければなりません。したがって、個々のクラスタノードへの最後のパスをサポートするプライベートインターコネクトインタフェースを無効にしないでください。

パブリックネットワークインタフェースに関連する DR クラスタリングの考慮点

DR のボード切り離し操作が、アクティブなパブリックネットワークインタフェースを含むボードに関連する場合、Sun Cluster はこの操作を拒否し、この操作によって影響を受けるインタフェースを特定します。アクティブなネットワークインタフェースが存在するボードを切り離す場合は、まず、if_mpadm(1M) コマンドを使って、そのインタフェース上のすべてのトラフィックを同じマルチパスグループの正常な他のインタフェースに切り替える必要があります。

無効にしたネットワークアダプタ上で DR 削除操作を実行している間に残りのネットワークアダプタに障害が発生した場合、可用性に影響が生じます。これは、DR 操作の間は、残りのネットワークアダプタのフェイルオーバー先が存在しないためです。

パブリックネットワークインタフェースに対して DR 切り離し操作を行うための手順については、『Sun Cluster 3.1 のシステム管理』を参照してください。