第 2 章 データサービスの開発

この章では、データサービスを開発するための詳細な方法について説明します。

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

• アプリケーションの適合性の分析

• 使用するインタフェースの決定

• データサービス作成用開発環境の設定

• リソースとリソースタイププロパティの設定

• コールバックメソッドの実装

• 汎用データサービス

• アプリケーションの制御

• リソースの監視

• メッセージログのリソースへの追加

• プロセス管理の提供

• リソースへの管理サポートの提供

• フェイルオーバーリソースの実装

• スケーラブルリソースの実装

• データサービスの作成と検証

アプリケーションの適合性の分析

データサービスを作成するための最初の手順では、ターゲットアプリケーションが高可用性またはスケーラビリティを備えるための要件を満たしているかどうかを判定します。 すべての要件を満たしていない場合は、要件を満たすようにアプリケーションのソースコードを変更します。

次に、アプリケーションが高可用性またはスケーラビリティを備えるための要件を要約します。 要件に関する詳細情報を確認したい場合や、アプリケーションのソースコードを変更する必要がある場合は、付録 B 「データサービスのコード例」を参照してください。

スケーラブルサービスを実現するためには、次に示す高可用性の要件をすべて満たした上で、いくつかの追加要件も満たしている必要があります。

• Sun Cluster 環境では、ネットワーク対応 (クライアントサーバーモデル) とネットワーク非対応 (クライアントレス) のアプリケーションはどちらも、高可用性またはスケーラビリティを備えることが可能です。 ただし、タイムシェアリング環境では、アプリケーションは サーバー上で動作し、telnet または rlogin 経由でアクセスされるため、Sun Cluster は可用性を強化することはできません。

• アプリケーションはクラッシュに対する耐障害性 (クラッシュトレラント) を備えていなければなりません。 つまり、ノードが予期せぬ停止状態になった後、アプリケーションは再起動時に必要なディスクデータを復元できなければなりません。 さらに、クラッシュ後の復元時間にも制限が課せられます。 ディスクを復元し、アプリケーションを再起動できる能力は、データの整合性に関わる問題であるため、クラッシュトレラントであることは、アプリケーションが高可用性を備えるための前提条件となります。 データサービスは接続を復元できる必要はありません。

• アプリケーションは、自身が動作するノードの物理的なホスト名に依存してはなりません。 詳細については、ホスト名を参照してください。

• アプリケーションは、複数の IP アドレスが構成されている環境で正しく動作する必要があります。たとえば、ノードが複数のパブリックネットワーク上に存在する多重ホームホスト環境や、単一のハードウェアインタフェース上に複数の論理インタフェースが構成されているノードが存在する環境で正しく動作しなければなりません。

• 高可用性を備えるには、アプリケーションデータはクラスタファイルシステム内に格納されている必要があります。多重ホストデータを参照してください。

  アプリケーションがデータの格納先を示すのに固定されたパス名を使用している場合、アプリケーションのソースコードを変更しなくても、そのパスをクラスタファイルシステム内の場所を指すシンボリックリンクに変更できる場合があります。 詳細については、多重ホストデータを配置するためのシンボリックリンクの使用を参照してください。

• アプリケーションのバイナリとライブラリは、ローカルの各ノードまたはクラスタファイルシステムのどちらにも格納できます。 クラスタファイルシステム上に格納する利点は、1 箇所にインストールするだけで済む点です。 欠点としては、アプリケーションが RGM の制御下で動作している間はバイナリファイルが使用中になるので、ローリングアップグレードの問題が生じることが挙げられます。

• 初回の照会がタイムアウトした場合、クライアントは自動的に照会を再試行できる必要があります。 アプリケーションとプロトコルがすでに単一サーバーのクラッシュと再起動に対応できている場合、関連するリソースグループのフェイルオーバーまたはスイッチオーバーにも対応できる必要があります。 詳細については、クライアントの再試行を参照してください。

• アプリケーションは、クラスタファイルシステム内で UNIX ドメインソケットまたは名前付きパイプを使用してはなりません。

さらに、スケーラブルサービスは、次の要件も満たしている必要があります。

• アプリケーションは、複数のインスタンスを実行でき、すべてのインスタンスがクラスタファイルシステム内の同じアプリケーションデータを処理できる必要があります。

• アプリケーションは、複数のノードからの同時アクセスに対してデータの整合性を保証する必要があります。

• アプリケーションは、クラスタファイルシステムのように、広域的に使用可能な機構を備えたロック機能を実装している必要があります。

スケーラブルサービスの場合、アプリケーションの特性により負荷均衡ポリシーが決定されます。 たとえば、負荷均衡ポリシー LB_WEIGHTED は、任意のインスタンスがクライアントの要求に応答できるポリシーですが、クライアント接続にサーバー上のメモリー内キャッシュを使用するアプリケーションには適用されません。 この場合、特定のクライアントのトラフィックをアプリケーションの 1 つのインスタンスに制限する負荷均衡ポリシーを指定する必要があります。 負荷均衡ポリシー LB_STICKY と LB_STICKY_WILD は、クライアントからのすべての要求を同じアプリケーションインスタンスに繰り返して送信します。 この場合、アプリケーションはメモリー内キャッシュを使用できます。異なるクライアントから複数の要求が送信された場合、RGM はサービスの複数のインスタンスに要求を分配します。 スケーラブルデータサービスに対応した負荷均衡ポリシーを設定する方法については、フェイルオーバーリソースの実装を参照してください。

使用するインタフェースの決定

Sun Cluster 開発者サポートパッケージ (SUNWscdev) は、データサービスメソッドのコーディング用に 2 種類のインタフェースセットを提供します。

• Resource Management API (RMAPI) - 低レベルのルーチンセット (libscha.so ライブラリとして実装されている)

• データサービス開発ライブラリ (Data Services Development Library: DSDL) - RMAPI の機能をカプセル化し、いくつかの追加機能を提供する、より高いレベルの関数セット (libdsdev.so ライブラリとして実装されている)

Sun Cluster 開発者サポートパッケージには、データサービスの作成を自動化するツールである SunPlex Agent Builder も含まれています。

次に、データサービスを開発する際の推奨手順を示します。

1. C 言語または Korn シェルのどちらでコーディングするかを決定します。 DSDL は C 言語用のインタフェースしか提供しないため、Korn シェルでコーディングする場合は使用できません。

2. Agent Builder を実行します。必要な情報を入力するだけで、ソースコード、実行可能コード、RTR ファイル、パッケージを含むデータサービスを生成できます。

3. 生成されたデータサービスをカスタマイズする必要がある場合は、生成されたソースファイルに DSDL コードを追加できます。 Agent Builder は、ソースファイル内において独自のコードを追加できる場所にコメント文を埋め込みます。

4. ターゲットアプリケーションをサポートするために、さらにコードをカスタマイズする必要がある場合は、既存のソースコードに RMAPI 関数を追加できます。

実際には、データサービスを作成する方法はいくつもあります。 たとえば、Agent Builder によって生成されたコード内の特定の場所に独自のコードを追加する代わりに、生成されたメソッドの 1 つや生成された監視プログラムを DSDL や RMAPI 関数を使って最初から作成したプログラムで完全に置き換えることができます。 しかし、使用する方法に関わらず、ほとんどの場合は Agent Builder を使って開発作業を開始することをお勧めします。次に、その理由を示します。

• Agent Builder が生成するコードは本質的に汎用であり、多数のデータサービスでテストされています。

• Agent Builder は、RTR ファイル、make ファイル、リソースのパッケージなど、データサービス用のサポートファイルを作成します。 データサービスのコードをまったく使用しない場合でも、このようなサポートファイルを使用することによってかなりの作業を省略できます。

• 生成されたコードは変更できます。

RMAPI は C 言語用の関数セットとスクリプト用のコマンドセットを提供しますが、DSDL は C 言語用の関数インタフェースしか提供しません。 DSDL は ksh コマンドを提供しないので、Agent Builder で Korn shell (ksh) 出力を指定した場合、生成されるソースコードは RMAPI を呼び出します。

データサービス作成用開発環境の設定

データサービスの開発を始める前に、Sun Cluster 開発パッケージ (SUNWscdev) をインストールして、Sun Cluster のヘッダーファイルやライブラリファイルにアクセスできるようにする必要があります。 このパッケージがすでにすべてのクラスタノード上にインストールされている場合でも、通常は、クラスタノード上にはない独立した開発マシン、すなわちクラスタノード以外の開発マシンで開発を行います。 このような場合、pkgadd を使って、開発マシンに SUNWscdev パッケージをインストールする必要があります。

コードをコンパイルおよびリンクするとき、ヘッダーファイルとライブラリファイルを識別するオプションを設定する必要があります。 (クラスタノード以外の) 開発マシンで開発が終了すると、完成したデータサービスをクラスタに転送して、実行および検証できます。

必ず開発バージョンの Solaris 8 以上を使用してください。

この節では、次の手順を使用します。

• Sun Cluster 開発パッケージ (SUNWscdev) をインストールして、適切なコンパイラオプションとリンカーオプションを設定します。

• データサービスをクラスタに転送します。

開発環境の設定方法

SUNWscdev パッケージをインストールして、コンパイラオプションとリンカーオプションをデータサービス開発用に設定する方法について説明します。

1. スーパーユーザーになるか、あるいは同等の役割を持つ役割を宣言し、使用したい CD-ROM ディレクトリに移動します。

   # cd CD-ROM_directory

2. SUNWscdev パッケージを現在のディレクトリにインストールします。

   # pkgadd -d . SUNWscdev

3. Makefile に、データサービスのコードが使用する include ファイルとライブラリファイルを示すコンパイラオプションとリンカーオプションを指定します。

   -I オプションは、Sun Cluster のヘッダーファイルを指定します。-L オプションは、開発システム上にあるコンパイル時ライブラリの検索パスを指定します。-R オプションはクラスタの実行時リンカーの検索パスを指定します。

   # サンプルデータサービスの Makefile
   ... 
   
   -I /usr/cluster/include
   
   -L /usr/cluster/lib
   
   -R /usr/cluster/lib
   ... 

データサービスをクラスタに転送する方法

開発マシン上でデータサービスの開発が完了した場合、クラスタに転送して検証する必要があります。 この転送を行うときは、エラーが発生する可能性を減らすために、データサービスのコードと RTR ファイルを一緒にパッケージに保管して、その後、クラスタのすべてのノード上でパッケージをインストールすることを推奨します。

データサービスをインストールするときは、pkgadd を使用するかどうかに関わらず、すべてのクラスタノード上にデータサービスをインストールする必要があります。 Agent Builder は、RTR ファイルとデータサービスのコードを自動的にパッケージ化します。

リソースとリソースタイププロパティの設定

Sun Cluster は、データサービスの静的な構成を定義するためのリソースタイププロパティおよびリソースプロパティのセットを提供します。 リソースタイププロパティでは、リソースのタイプ、そのバージョン、API のバージョンと同時に、各コールバックメソッドへのパスも指定できます。 表 A–1 に、すべてのリソースタイププロパティのリストを示します。

リソースプロパティ (Failover_mode、Thorough_probe_intervalなど) やメソッドタイムアウトも、リソースの静的な構成を定義します。 動的なリソースプロパティ (Resource_state や Status など) は、管理対象のリソースの活動状況を反映します。 リソースプロパティについては、表 A–2 を参照してください。

リソースタイプおよびリソースプロパティは、データサービスの重要な要素であるリソースタイプ登録 (RTR) ファイルで宣言します。 RTR ファイルは、クラスタ管理者が Sun Cluster でデータサービスを登録するとき、データサービスの初期構成を定義します。

Agent Builder が宣言するプロパティセットはどのようなデータサービスにとっても有用かつ必須です。したがって、独自のデータサービス用の RTR ファイルを生成するときは、Agent Builder を使用することを推奨します。 たとえば、ある種のプロパティ (Resource_type など) が RTR ファイルで宣言されていない場合、データサービスの登録は失敗します。 必須ではなくても、その他のプロパティも RTR ファイルで宣言されていなければ、システム管理者はそれらのプロパティを利用することはできません。いくつかのプロパティは RTR ファイルで宣言されていなくても使用することができますが、これは RGM がそのプロパティを定義し、そのデフォルト値を提供しているためです。 このような複雑さを回避するためにも、Agent Builder を使用して、適切な RTR ファイルを生成するようにしてください。 必要であれば、Agent Builder で生成した RTR ファイルを編集して、特定の値を変更することもできます。

以降では、Agent Builder で作成した RTR ファイルの例を示します。

リソースタイププロパティの宣言

クラスタ管理者は、RTR ファイルで宣言されているリソースタイププロパティを構成することはできません。 このようなリソースタイププロパティは、リソースタイプの恒久的な構成の一部を形成します。

Installed_nodes というリソースタイププロパティは、システム管理者が構成できます。 事実、Installed_nodes はシステム管理者が構成できる唯一のリソースタイププロパティであり、RTR ファイルでは宣言できません。

次に、リソースタイプ宣言の構文を示します。

property_name = value;

RGM はプロパティ名の大文字と小文字を区別します。 Sun が提供する RTR ファイルのプロパティに対する命名規則では、名前の最初の文字が大文字で、残りが小文字です (メソッド名は例外)。 メソッド名は、プロパティ属性と同様にすべて大文字です。

次に、サンプルのデータサービス (smpl) 用の RTR ファイルにおけるリソースタイプ宣言を示します。

# Sun Cluster Data Services Builder template version 1.0
# Registration information and resources for smpl
#
#NOTE: Keywords are case insensitive, i.e., you can use
#any capitalization style you prefer.
#
Resource_type = "smpl";
Vendor_id = SUNW;
RT_description = "Sample Service on Sun Cluster";

RT_version ="1.0"; 
API_version = 2;
Failover = TRUE;

Init_nodes = RG_PRIMARIES;

RT_basedir=/opt/SUNWsmpl/bin;

Start           =    smpl_svc_start;
Stop            =    smpl_svc_stop;

Validate        =    smpl_validate;
Update          =    smpl_update;

Monitor_start   =    smpl_monitor_start;
Monitor_stop    =    smpl_monitor_stop;
Monitor_check   =    smpl_monitor_check;

RTR ファイルの最初のエントリには、Resource_type プロパティを宣言する必要があります。 宣言しないと、リソースタイプの登録は失敗します。

リソースタイプ宣言の最初のセットは、次のようなリソースタイプについての基本的な情報を提供します。

Resource_type および Vendor_id

リソースタイプの名前を提供します。 リソースタイプ名は Resource_type プロパティ(この例では「smpl」) 単独で指定できます。Vendor_id を接頭辞として使用し、 リソースタイプ(この例では「 SUNW.smpl」) との区切りにドット (.) を入力することもできます。 Vendor_id を使用する場合、リソースタイプを定義する企業の略号にします。 リソースタイプ名はクラスタ内で一意である必要があります。

---

注 –

便宜上、リソースタイプ名 (Resource_type と Vendor_id) はパッケージ名として使用されます。 パッケージ名は 9 文字に制限されているので、これら 2 つのプロパティの文字数の合計も 9 文字以内に制限することをお勧めします。RGM は 9 文字の制限を適用しません。 一方、Agent Builder はリソースタイプ名からパッケージ名を系統だてて生成します。つまり、Agent Builder は 9 文字の制限を適用します。

---

Rt_version

サンプルデータサービスのバージョンです。

API_version

API のバージョンです。 たとえば、「API_version =2」は、データサービスが Sun Cluster バージョン 3.0 の管理下で動作していることを示します。

Failover = TRUE

このデータサービスが、複数のノード上で同時にオンラインにできるリソースグループ 上では実行できないサービス、すなわちフェイルオーバーデータサービスであることを示します。 詳細については、データサービスをクラスタに転送する方法を参照してください。

Start、Stop、 Validate など

RGM によって呼び出されるコールバックメソッドプログラムのパスを提供します。 これらのパスは、 RT_basedir で指定されたディレクトリからの相対パスです。

リソースタイプ宣言の残りのセットは、次のような構成情報を提供します。

Init_nodes = RG_PRIMARIES

RGM が、データサービスをマスターできるノード上でのみ Init、Boot、Fini、Validate の各メソッドを呼び出すように指定します。 RG_PRIMARIES で指定されたノードは、データサービスがインストールされているすべてのノードのサブセットです。 この値に RT_INSTALLED_NODES を設定した場合、RGM は、データサービスがインストールされているすべてのノード上で上記メソッドを呼び出します。

RT_basedir

コールバックメソッドパスのような完全な相対パスとして、/opt/SUNWsample/bin をポイントします。

Start、Stop、 Validate など

RGM によって呼び出されるコールバックメソッドプログラムのパスを提供します。 これらのパスは、 RT_basedir で指定されたディレクトリからの相対パスです。

リソースプロパティの宣言

リソースタイププロパティと同様に、リソースプロパティも RTR ファイルで宣言します。 便宜上、リソースプロパティ宣言は RTR ファイルのリソースタイププロパティ宣言の後に行います。 リソース宣言の構文では、一連の属性と値のペアを記述して、全体を中括弧で囲みます。

{
    Attribute = Value;
    Attribute = Value;
             .
             .
             .
    Attribute = Value;
}

Sun Cluster が提供するリソースプロパティ (システム定義プロパティ) の場合、特定の属性は RTR ファイルで変更できます。 たとえば、Sun Cluster はコールバックメソッドごとにメソッドタイムアウトプロパティを定義して、そのデフォルト値を提供します。 RTR ファイルを使用すると、異なるデフォルト値を指定できます。

Sun Cluster が提供するプロパティ属性を使用することにより、RTR ファイル内に新しいリソースプロパティ (拡張プロパティ) を定義することもできます。 表 A–4 に、リソースプロパティを変更および定義するための属性を示します。 拡張プロパティ宣言は RTR ファイルのシステム定義プロパティ宣言の後に行います。

システム定義リソースプロパティの最初のセットでは、コールバックメソッドのタイムアウト値を指定します。

...

# リソースプロパティ宣言は中括弧で囲まれたリストであり、
#リソースタイププロパティ宣言の後で宣言する。
#プロパティ名宣言は、リソースプロパティエントリの左中括弧の
# 直後にある最初の属性でなければならない。
#
# メソッドタイムアウト用の最小値とデフォルト値を設定する。
{
        PROPERTY = Start_timeout;
        MIN=60;
        DEFAULT=300;
}

{
        PROPERTY = Stop_timeout;
        MIN=60;
        DEFAULT=300;
}
{
        PROPERTY = Validate_timeout;
        MIN=60;
        DEFAULT=300;
}
{
        PROPERTY = Update_timeout;
        MIN=60;
        DEFAULT=300;
}
{
        PROPERTY = Monitor_Start_timeout;
        MIN=60;
        DEFAULT=300;
}
{
        PROPERTY = Monitor_Stop_timeout;
        MIN=60;
        DEFAULT=300;
{
        PROPERTY = Monitor_Check_timeout;
        MIN=60;
        DEFAULT=300;
}

プロパティ名 (PROPERTY = value) は、各リソースプロパティ宣言における最初の属性でなけれなりません。 リソースプロパティは、RTR ファイルのプロパティ属性で定義された範囲内で構成することができます。 たとえば、各メソッドタイムアウト用のデフォルト値は 300 秒です。 システム管理者はこの値を変更できますが、指定できる最小値は (MIN 属性で指定されているように) 60 秒です。 リソースプロパティ属性の完全なリストについては、表 A–4 を参照してください。

リソースプロパティの次のセットは、データサービスにおいて特定の目的に使用されるプロパティを定義します。

{
        PROPERTY = Failover_mode;
        DEFAULT=SOFT;
        TUNABLE = ANYTIME;
}
{
        PROPERTY = Thorough_Probe_Interval;
        MIN=1;
        MAX=3600;
        DEFAULT=60;
        TUNABLE = ANYTIME;
}

# ある期限内に再試行する回数。この回数を超えると、
# 当該ノード上ではアプリケーションが起動できないと判断される。
{
        PROPERTY = Retry_Count;
        MAX=10;
        DEFAULT=2;
        TUNABLE = ANYTIME; 
}

# Retry_Interval に60 の倍数を設定する。
# この値は秒から分に変換され、切り上げられる。
# たとえば、50 秒は 1 分に変更される。このプロパティを使用して、
# 再試行回数 (Retry_Count) を指定する。
{
        PROPERTY = Retry_Interval;
        MAX=3600;
        DEFAULT=300;
        TUNABLE = ANYTIME;
}

{
        PROPERTY = Network_resources_used;
        TUNABLE = WHEN_DISABLED;
        DEFAULT = "";
}
{
        PROPERTY = Scalable;
        DEFAULT = FALSE;
        TUNABLE = AT_CREATION;
}
{
        PROPERTY = Load_balancing_policy;
        DEFAULT = LB_WEIGHTED;
        TUNABLE = AT_CREATION;
}
{
        PROPERTY = Load_balancing_weights;
        DEFAULT = "";
        TUNABLE = ANYTIME;
}
{
        PROPERTY = Port_list;
        TUNABLE = AT_CREATION;
        DEFAULT = ;
}

上記のリソースプロパティ宣言では、システム管理者が値を設定し、制限を設けることができる TUNABLE 属性が追加されています。 AT_CREATION は、システム管理者が値を指定できるのはリソースの作成時だけであり、後で変更できないことを示します。

上記のプロパティのほとんどは、特に理由がないかぎり、Agent Builder が生成するデフォルト値を使用しても問題ありません。 こうしたプロパティのあとには、次のような情報が続きます (詳細については、リソースのプロパティまたは r_properties(5) のマニュアルページを参照してください)。

Failover_mode

Start または Stop メソッドの失敗時、RGM がリソースグループを再配置するか、ノードを停止するかを指定します。

Thorough_probe_interval、Retry_count、Retry_interval

障害モニターで使用します。 障害モニターが適切に機能していない場合、システム管理者はいつでも調整できます。

Network_resources_used

データサービスで使用される論理ホスト名または共有アドレスリソースのリスト。 このプロパティは、Agent Builder によって宣言されるので、システム管理者はデータサービスを構成するとき必要に応じてリソースのリストを指定できます。

Scalable

FALSE に設定した場合、このリソースはクラスタネットワーキング (共有アドレス) 機能を使用しません。 この設定は、リソースタイプ Failover プロパティに TRUE を設定して、フェイルオーバーサービスを指定するのと同じです。 このプロパティの詳しい使用方法については、データサービスをクラスタに転送する方法および コールバックメソッドの実装を参照してください。

Load_balancing_policy、Load_balancing_weights

これらのプロパティは自動的に宣言されますが、フェイルオーバーリソースタイプでは使用されません。

Port_list

サーバーが待機するポートのリストです。 このプロパティは Agent Builder によって宣言されるので、システム管理者はデータサービスを構成するときポートのリストを指定できます。

拡張プロパティの宣言

次に、RTR ファイルの最後の例として、拡張プロパティを示します。

# 拡張プロパティ
#

# クラスタ管理者は、このプロパティに値を設定して、アプリケーション
# が使用する構成ファイルが格納されているディレクトリを指定する
# 必要がある。このアプリケーション (smpl) の場合、PXFS 上に
# ある構成ファイル (通常は named.conf) のパスを指定する。
{
        PROPERTY = Confdir_list;
        EXTENSION;
        STRINGARRAY;
        TUNABLE = AT_CREATION;
        DESCRIPTION = "The Configuration Directory Path(s)";
}

# 次の2 つのプロパティは、障害モニターの再起動を制御する。
{
        PROPERTY = Monitor_retry_count;
        EXTENSION;
        INT;
        DEFAULT = 4;
        TUNABLE = ANYTIME;
        DESCRIPTION = "Number of PMF restarts allowed for fault monitor.";
}
{
        PROPERTY = Monitor_retry_interval;
        EXTENSION;
        INT;
        DEFAULT = 2;
        TUNABLE = ANYTIME;
        DESCRIPTION = "Time window (minutes) for fault monitor restarts.";
}
# 検証用のタイムアウト値 (秒)。
{
        PROPERTY = Probe_timeout;
        EXTENSION;
        INT;
        DEFAULT = 120;
        TUNABLE = ANYTIME;
        DESCRIPTION = "Time out value for the probe (seconds)";
}

# PMF 用の子プロセス監視レベル (pmfadm の-C オプション)。
# デフォルトの -1 は、pmfadm -C オプションを使用しないこと
# を示す。
# 0 より大きな値は、目的の子プロセス監視レベルを示す。
{
        PROPERTY = Child_mon_level;
        EXTENSION;
        INT;
        DEFAULT = -1;
        TUNABLE = ANYTIME;
        DESCRIPTION = "Child monitoring level for PMF";
}
# ユーザー追加コード -- BEGIN VVVVVVVVVVVV
# ユーザー追加コード -- END   ^^^^^^^^^^^^

次に示すように、Agent Builder は、ほとんどのデータサービスにとって有用な拡張プロパティを作成します。

Confdir_list

アプリケーション構成ディレクトリへのパスを指定します。このプロパティは多くのアプリケーションにとって有用な情報です。 データサービスを構成するときに、システム管理者はこのディレクトリの場所を指定できます。

Monitor_retry_count、Monitor_retry_interval 、Probe_timeout

サーバーデーモンではなく、障害モニター自体の再起動を制御します。

Child_mon_level

PMF による監視レベルを設定します。 詳細については、pmfadm(1M) のマニュアルページを参照してください。

「ユーザー追加コード」というコメント文で囲まれた部分に、追加の拡張プロパティを作成できます。

コールバックメソッドの実装

この節では、コールバックメソッドの実装に関する一般的な情報について説明します。

リソースとリソースグループのプロパティ情報へのアクセス

一般に、コールバックメソッドはリソースのプロパティにアクセスする必要があります。 RMAPI は、リソースのシステム定義プロパティと拡張プロパティにアクセスするために、コールバックメソッドで使用できるシェルコマンドと C 関数の両方を提供します。 詳細については、scha_resource_get(1HA) と scha_resource_get(3HA) のマニュアルページを参照してください。

DSDL は、システム定義プロパティにアクセスするための C 関数セット (プロパティごとに 1 つ) と、拡張プロパティにアクセスするための関数を提供します。 詳細については、scds_property_functions(3HA) と scds_get_ext_property(3HA) のマニュアルページを参照してください。

Status と Status_msg の設定を除き、リソースプロパティを設定する API 関数が存在しないため、プロパティ機構を使用して、データサービスの動的な状態情報を格納することはできません。 したがって、動的な状態情報は、広域ファイルに格納するようにします。

クラスタ管理者は、scrgadm コマンド、グラフィカル管理コマンド、またはグラフィカル管理インタフェースを使用して、ある種のリソースプロパティを設定することができます。 ただし、scrgadm はクラスタの再構築時、すなわち RGM がメソッドを呼び出した時点でエラー終了するため、コールバックメソッドから呼び出さないようにします。

メソッドの呼び出し回数への非依存性

一般に、RGM は、同じリソース上で同じメソッドを (同じ引数で) 何回も連続して呼び出すことはありません。 ただし、Start メソッドが失敗した場合には、リソースが起動していなくても RGM はそのリソース上で Stop メソッドを呼び出すことができます。 同様に、リソースデーモンが自発的に停止している場合でも、RGM はそのリソース上で Stop メソッドを呼び出すことができます。 Monitor_start メソッドと Monitor_stop メソッドにも、同じことが当てはまります。

このような理由のため、Stop メソッドと Monitor_stop メソッドは呼び出し回数に依存しないように組み込む必要があります。 同じリソース上で、同じパラメータを指定して Stop メソッドまたは Monitor_stop メソッドを何回連続して呼び出しても、1 回だけ呼び出したときと同じ結果になります。

呼び出し回数に依存しないということは、リソースまたはモニターがすでに停止し、動作していなくても、Stop メソッドと Monitor_stop メソッドが 0 (成功) を返す必要があるということも意味します。

Init、Fini、Boot、Update の各メソッドも呼び出し回数に依存しない必要があります。 Start メソッドは呼び出し回数に依存してもかまいません。

汎用データサービス

汎用データサービス (GDS) は、単純なアプリケーションを Sun Cluster の Resource Group Manager フレームワークに組み込むことにより、スケーラビリティと高可用性を実現する機構です。 この機構では、アプリケーションを可用性の高いものにしたり、スケーラブルなものにするために通常必要になるエージェントのコーディングは必要ありません。

GDS モデルは、コンパイル済みのリソースタイプ SUNQ.gds により、RGM フレームワークとやりとりします。

詳細については、第 10 章「汎用データサービス」を参照してください。

アプリケーションの制御

RGM は、ノードがクラスタに結合されるとき、またはクラスタから切り離されるとき、コールバックメソッドを使って実際のリソース (アプリケーション) を制御できます。

リソースの起動と停止

リソースタイプを実装するには、少なくとも、Start メソッドと Stop メソッドが必要です。 RGM は、リソースタイプのメソッドプログラムを適切なノード上で適切な回数だけ呼び出して、リソースグループをオフラインまたはオンラインにします。 たとえば、クラスタノードのクラッシュ後、そのノードがマスターしているリソースグループを新しいノードに移動します。 Start メソッドを実装して、RGM が正常に動作しているホストノード上で各リソースを再起動できるようにする必要があります。

Start メソッドは、ローカルノード上でリソースが起動し、使用可能な状態になるまで終了してはいけません。 初期化に時間がかかるリソースタイプでは、その Start メソッドに、十分な長さのタイムアウト値を設定する必要があります。Start_timeout プロパティのデフォルト値と最小値は、リソースタイプ登録ファイルで設定します。

Stop メソッドは、RGM がリソースをオフラインにする状況に合わせて実装する必要があります。 たとえば、リソースグループがノード 1 上でオフラインになり、ノード 2 上でもう一度オンラインになると仮定します。リソースグループをオフラインにしている間、RGM は、そのリソースグループ内のリソース上で Stop メソッドを呼び出して、ノード 1 上のすべての活動を停止しようとします。ノード 1 上ですべてのリソースの Stop メソッドが完了したなら、RGM は、ノード 2 上でそのリソースグループを再度オンラインにします。

Stop メソッドは、ローカルノード上でリソースがすべての活動を完全に停止し完全にシャットダウンするまで終了してはいけません。 Stop メソッドは、ローカルノード上でリソース関連のすべてのプロセスを終了することでもっとも安全に実装できます。 シャットダウンに時間がかかるリソースタイプでは、その Stop メソッドに十分な長さのタイムアウト値を設定する必要があります。 Stop_timeout プロパティはリソースタイプ登録ファイルで設定します。

Stop メソッドが失敗またはタイムアウトすると、リソースグループはエラー状態になり、システム管理者の介入が必要となります。 この状態を回避するには、Stop および Monitor_stop メソッドがすべてのエラー状態から回復するようにする必要があります。 理想的には、これらのメソッドは 0 (成功) のエラー状態で終了し、ローカルノード上でリソースとそのモニターのすべての活動を正常に停止するべきです。

Start および Stop メソッドを使用するかどうかの決定

この節では、 Start メソッドと Stop メソッドを使用するか、または、Prenet_start メソッドと Postnet_stop メソッドを使用するかを決定するときのいくつかの注意事項について説明します。 どちらのメソッドを使用するのが適切かを決定するには、クライアントおよびデータサービスのクライアントサーバー型ネットワークプロトコルについて十分に理解している必要があります。

ネットワークアドレスリソースを使用するサービスでは、論理ホスト名のアドレス構成から始まる順番で、起動手順または停止手順を実行する必要があります。 コールバックメソッドの Prenet_start と Postnet_stop を使用してリソースタイプを実装すると、同じリソースグループ内のネットワークアドレスが「起動」に構成される前、または「停止」に構成されたあとに、特別な起動アクションまたは停止アクションを行います。

RGM は、データサービスの Prenet_start メソッドを呼び出す前に、ネットワークアドレスを取り付ける (plumb、ただし起動には構成しない) メソッドを呼び出します。 RGM は、データサービスの Postnet_stop メソッドを呼び出したあとに、ネットワークアドレスを取り外す (unplumb) メソッドを呼び出します。 RGM がリソースグループをオンラインにするときは、次のような順番になります。

1. ネットワークアドレスを取り付けます。

2. データサービスの Prenet_start メソッドを呼び出します (存在する場合)。

3. ネットワークアドレスを「起動」に構成します。

4. データサービスの Start メソッドを呼び出します (存在する場合)。

RGM がリソースグループをオフラインにするときは、逆の順番になります。

1. データサービスの Stop メソッドを呼び出します (存在する場合)。

2. ネットワークアドレスを「停止」に構成します。

3. データサービスの Postnet_stop メソッドを呼び出します (存在する場合)。

4. ネットワークアドレスを取り外します。

Start、Stop、Prenet_start、Postnet_stop のうち、どのメソッドを使用するかを決定するには、まずサーバー側を考えます。 データサービスアプリケーションリソースとネットワークアドレスリソースの両方を持つリソースグループをオンラインにするとき、RGM は、データサービスリソースの Start メソッドを呼び出す前に、ネットワークアドレスを「起動」に構成するメソッドを呼び出します。 したがって、データサービスを起動するときにネットワークアドレスが「起動」に構成されている必要がある場合は、Start メソッドを使用してデータサービスを起動します。

同様に、データサービスアプリケーションリソースとネットワークアドレスリソースの両方を持つリソースグループをオフラインにするとき、RGM は、データサービスリソースの Stop メソッドを呼び出したあとに、ネットワークアドレスを「停止」に構成するメソッドを呼び出します。 したがって、データサービスを停止するときにネットワークアドレスが「起動」に構成されている必要がある場合は、Stop メソッドを使用してデータサービスを停止します。

たとえば、データサービスを起動または停止するときに、データサービスの管理ユーティリティまたはライブラリを呼び出す必要がある場合もあります。 また、クライアントサーバー型ネットワークインタフェースを使用して管理を実行するような管理ユーティリティまたはライブラリを持っているデータサービスもあります。 つまり、管理ユーティリティがサーバーデーモンを呼び出すので、管理ユーティリティまたはライブラリを使用するためには、ネットワークアドレスが「起動」に構成されている必要があります。 このような場合は、Start メソッドと Stop メソッドを使用します。

データサービスが起動および停止するときにネットワークアドレスが「停止」に構成されている必要がある場合は、Prenet_start メソッドと Postnet_stop メソッドを使用して データサービスを起動および停止します。 クラスタ再構成 (SCHA_GIVEOVER 引数を指定した scha_control() または scswitch によるスイッチオーバー) のあとネットワークアドレスとデータサービスのどちらが最初にオンラインになるかによってクライアントソフトウェアの応答が異なるかどうかを考えます。 たとえば、クライアントの実装が最小限の再試行を行うだけで、データサービスのポートが利用できないと判断すると、すぐにあきらめる場合もあります。

データサービスを起動するときにネットワークアドレスが「起動」に構成されている必要がない場合、ネットワークインタフェースが「起動」に構成される前に、データサービスを起動します。 すると、ネットワークアドレスが「起動」に構成されるとすぐに、データサービスはクライアントの要求に応答できます。したがって、クライアントが再試行を停止する可能性も減ります。 このような場合は、Start ではなく、Prenet_start メソッドを使用してデータサービスを起動します。

Postnet_stop メソッドを使用した場合、ネットワークアドレスが「停止」に構成されている時点では、データサービスリソースは「起動」のままです。 Postnet_stop メソッドを呼び出すのは、ネットワークアドレスが「停止」に構成されたあとだけです。 結果として、データサービスの TCP または UDP のサービスポート (つまり、その RPC プログラム番号) は、常に、ネットワーク上のクライアントから利用できます。ただし、ネットワークアドレスが応答しない場合を除きます。

Start メソッドと Stop メソッドを使用するか、Prenet_start メソッドと Postnet_stop メソッドを使用するか、または両方を使用するかを決定するには、サーバーとクライアントの要件と動作を考慮に入れる必要があります。

Init、Fini、Boot の各メソッド

RGM は、3 つの任意のメソッド Init、Fini、Boot を使用し、リソース上で初期化と終了コードを実行できます。 リソースを管理下に置くとき (リソースが属しているリソースグループを管理していない状態から管理している状態に切り替えるとき、またはすでに管理されているリソースグループでリソースを作成するとき)、RGM は Init メソッドを呼び出して、1 回だけリソースの初期化を実行します。

リソースを管理下から外すとき (リソースが属しているリソースグループを管理していない状態に切り替えるとき、またはすでに管理されているリソースグループからリソースを削除するとき)、RGM は Fini を呼び出して、リソースをクリーンアップします。 クリーンアップは呼び出し回数に依存しない必要があります。つまり、すでにクリーンアップが行われている場合、Fini は 0 (成功) で終了する必要があります。

RGM は、新たにクラスタに結合したノード、すなわち起動または再起動したノード上で、Boot メソッドを呼び出します。

Boot メソッドは、通常、Init と同じ初期化を実行します。 この初期化は呼び出し回数に依存しない必要があります。つまり、ローカルノード上ですでにリソースが初期化されている場合、Boot と Init は 0 (成功) で終了する必要があります。

リソースの監視

通常、モニターは、リソース上で定期的に障害検証を実行し、検証したリソースが正しく動作しているかどうかを検出するように実装します。 障害検証が失敗した場合、モニターはローカルで再起動するか、RMAPI 関数 scha_control () または DSDL 関数 scds_fm_action() を呼び出して、影響を受けるリソースグループのフェイルオーバーを要求できます。

また、リソースの性能を監視して、性能を調節または報告できます。 可能であれば、リソースタイプに固有な障害モニターを作成することを推奨します。 このような障害モニターを作成しなくても、リソースタイプは Sun Cluster により基本的なクラスタの監視が行われます。 Sun Cluster は、ホストハードウェアの障害、ホストのオペレーティングシステムの全体的な障害、およびパブリックネットワーク上で通信できるホストの障害を検出します。

RGM がリソースモニターを直接呼び出すことはありませんが、RGM は自動的にリソース用のモニターを起動する準備を整えます。 リソースをオフラインにするとき、RGM は、リソース自体を停止する前に、Monitor_stop メソッドを呼び出して、ローカルノード上でリソースのモニターを停止します。 リソースをオンラインにするとき、RGM は、リソース自体を起動した後に、Monitor_start メソッドを呼び出します。

RMAPI 関数 scha_control() と scha_control() を呼び出す DSDL 関数 scds_fm_action() を使用すると、リソースモニターは異なるノードへのリソースグループのフェイルオーバーを要求できます。 Monitor_check が定義されている場合、scha_control は健全性検査の一環としてこの関数を呼び出して、リソースが属するリソースグループをマスターするのに要求されたノードが十分信頼できるかどうかを判断します。 Monitor_check が「このノードは信頼できない」と報告した場合、あるいはメソッドがタイムアウトした場合、RGM はフェイルオーバー要求に適する別のノードを探します。 すべてのノードで Monitor_check が失敗した場合、フェイルオーバーは取り消されます。

リソースモニターは、モニターから見たリソースの状態を反映するように Status と Status_msg プロパティを設定します。 これらのプロパティを設定するには、RMAPI 関数 scha_resource_setstatus() または scha_resource_setstatus コマンド、あるいは DSDL 関数 scds_fm_action() を使用します。

Status と Status_msg はリソースモニターに固有の使用方法ですが、これらのプロパティは任意のプログラムで設定できます。

RMAPI による障害モニターの実装例については、障害モニターの定義を参照してください。 DSDL による障害モニターの実装例については、SUNW.xfnts 障害モニターを参照してください。 Sun が提供するデータサービスに組み込まれている障害モニターについては、『Sun Cluster データサービスの計画と管理 (Solaris OS 版)』を参照してください。

メッセージログのリソースへの追加

状態メッセージをほかのクラスタメッセージと同じログファイルに記録する場合は、scha_cluster_getlogfacility() 関数を使用して、クラスタメッセージを記録するために使用されている機能番号を取得します。

この機能番号を通常の Solaris syslog() 関数で使用して、状態メッセージをクラスタログに書き込みます。 scha_cluster_get() 汎用インタフェースからでも、クラスタログ機能情報にアクセスできます。

プロセス管理の提供

リソースモニターとリソース制御コールバックを実装するために、プロセス管理機能が RMAPI および DSDL に提供されています。 RMAPI は次の機能を定義します。これらのコマンドとプログラムの詳細については、各マニュアルページを参照してください。

プロセス監視機能:
pmfadm および rpc.pmfd

プロセス監視機能 (Process Monitor Facility: PMF) は、プロセスとその子孫を監視し、プロセスが終了したときに再起動する手段を提供します。 この機能は、監視するプロセスを起動および制御する pmfadm コマンドと、rpc.pmfd デーモンからなります。

halockrun

ファイルロックを保持しながら子プログラムを実行するためのプログラムです。 このコマンドはシェルスクリプトで使用すると便利です。

hatimerun

タイムアウト制御下で子プログラムを実行するためのプログラムです。 このコマンドはシェルスクリプトで使用すると便利です。

DSDL は、hatimerun 機能を実装するために scds_hatimerun 関数を提供します。

DSDL は、PMF 機能を実装するための関数セット (scds_pmf_*) を提供します。 DSDL の PMF 機能の概要と、個々の関数のリストについては、PMF 関数を参照してください。

リソースへの管理サポートの提供

リソース上での管理アクションには、リソースプロパティの設定と変更があります。 このような管理アクションを行うために、API は Validate と Update というコールバックメソッドを定義しています。

リソースの作成時や、管理アクションによるリソースまたはリソースグループのプロパティの更新時、RGM は、オプションの Validate メソッドを呼び出します。 RGM は、リソースとそのリソースグループのプロパティ値を Validate メソッドに渡します。 RGM は、リソースタイプの Init_nodes プロパティが示す複数のクラスタノード上で Validate を呼び出します。Init_nodes の詳細については、リソースタイププロパティか、rt_properties(5) のマニュアルページを参照してください。 RGM は、作成または更新が行われる前に Validate を呼び出します。任意のノード上でメソッドから失敗の終了コードが戻ってくると、作成または更新は取り消されます。

RGM が Validate メソッドを呼び出すのは、管理アクションがリソースまたはグループのプロパティを変更したときだけです。RGM がプロパティを設定したときや、モニターがリソースプロパティ Status と Status_msg を設定したときではありません。

RGM は、オプションの Update メソッドを呼び出して、プロパティが変更されたことを実行中のリソースに通知します。 RGM は、管理アクションがリソースまたはそのリソースグループのプロパティの設定に成功したあとに、Update を呼び出します。 RGM は、リソースがオンラインであるノード上で、このメソッドを呼び出します。 このメソッドは、API アクセス関数を使用して、アクティブなリソースに影響する可能性があるプロパティ値を読み取り、その値に従って、実行中のリソースを調節できます。

フェイルオーバーリソースの実装

フェイルオーバーリソースグループには、ネットワークアドレス (組み込みリソースタイプである論理ホスト名や共有アドレスなど) やフェイルオーバーリソース (フェイルオーバーデータサービス用のデータサービスアプリケーションリソースなど) があります。 データサービスがフェイルオーバーするかスイッチオーバーされると、ネットワークアドレスリソースは関連するデータサービスリソースと共にクラスタノード間を移動します。 RGM は、フェイルオーバーリソースの実装をサポートするプロパティをいくつか提供します。

ブール型リソースタイププロパティ Failover を TRUE に設定し、同時に複数のノード上でオンラインになることができるリソースグループだけで構成されるようにリソースを制限します。 このプロパティのデフォルト値は FALSE です。したがって、フェイルオーバーリソースを実現するためには、RTR ファイルで TRUE として宣言する必要があります。

Scalable リソースプロパティは、リソースがクラスタ共有アドレス機能を使用するかどうかを決定します。 フェイルオーバーリソースの場合、フェイルオーバーリソースは共有アドレスを使用しないので、Scalable には FALSE を設定します。

RG_mode リソースグループプロパティを使用すると、クラスタ管理者はリソースグループがフェイルオーバーまたはスケーラブルのどちらであるかを識別できます。 RG_mode が FAILOVER の場合、RGM はリソースグループの Maximum_primaries プロパティを 1 に設定して、リソースグループが単一のノードでマスターされるように制限します。 RGM は、Failover プロパティが TRUE であるリソースを、RG_mode が SCALABLE であるリソースグループで作成することを禁止します。

Implicit_network_dependencies リソースグループプロパティは、リソースグループ内におけるネットワークアドレスリソース (論理ホスト名や共有アドレス) への非ネットワークアドレスリソースの暗黙で強力な依存関係を、RGM が強制することを指定します。 これは、リソースグループ内のネットワークアドレスが「起動」に構成されるまで、リソースグループ内の非ネットワークアドレス (データサービス) リソースが、自分の Start メソッドを呼び出さないことを意味します。 この Implicit_network_dependencies プロパティのデフォルト値は TRUE です。

スケーラブルリソースの実装

スケーラブルリソースは、同時に複数のノード上でオンラインになることができます。 スケーラブルリソースには、Sun Cluster HA for Sun Java System Web Server (以前の Sun Cluster HA for Sun ONE Web Server) や Sun Cluster HA for Apache などのデータサービスがあります。

RGM は、スケーラブルリソースの実装をサポートするプロパティをいくつか提供します。

ブール型リソースタイププロパティの Failover を FALSE に設定し、一度に複数のノードでオンラインにできるリソースグループ内でリソースが構成されるようにします。

Scalable リソースプロパティは、リソースがクラスタ共有アドレス機能を使用するかどうかを決定します。 スケーラブルサービスは共有アドレスリソースを使用するので (スケーラブルサービスの複数のインスタンスが単一のサービスであるかのようにクライアントに見せるため)、Scalable には TRUE を設定します。

RG_mode プロパティを使用すると、クラスタ管理者はリソースグループがフェイルオーバーまたはスケーラブルのどちらであるかを識別できます。 RG_mode が SCALABLE の場合、RGM は Maximum_primaries が 1 より大きな値を持つこと、つまり同時に複数のノードがグループをマスターすることを許可します。 RGM は、Failover プロパティが FALSE であるリソースが、RG_mode が SCALABLE であるリソースグループ内でインスタンス化されることを許可します。

クラスタ管理者は、スケーラブルサービスリソースが属するためのスケーラブルリソースグループを作成します。また、スケーラブルリソースが依存する共有アドレスリソースが属するためのフェイルオーバーリソースグループも別に作成します。

クラスタ管理者は、RG_dependencies リソースグループプロパティを使用して、あるノード上でリソースグループをオンラインまたはオフラインにする順番を指定します。 スケーラブルリソースとそれらが依存する共有アドレスリソースは異なるリソースグループに属するので、この順番はスケーラブルサービスにとって重要です。 スケーラブルデータサービスが起動する前に、そのネットワークアドレス (共有アドレス) リソースが構成されていることが必要です。 したがって、クラスタ管理者は、スケーラブルサービスが属するリソースグループの RG_dependencies プロパティを設定して、共有アドレスリソースが属するリソースグループを組み込む必要があります。

リソースの RTR ファイルでスケーラブルプロパティを宣言した場合、RGM はそのリソースに対して、次のようなスケーラブルプロパティのセットを自動的に作成します。

Network_resources_used

このリソースによって使用される共有アドレスリソースです。 このプロパティのデフォルト値は空の文字列です。したがって、クラスタ管理者は、リソースを作成するときに、スケーラブルサービスが使用する実際の共有アドレスのリストを指定する必要があります。 scsetup コマンドと SunPlex Manager は、スケーラブルサービスに必要なリソースとグループを自動的に設定する機能を提供します。

Load_balancing_policy

リソースの負荷均衡ポリシーを指定します。 このポリシーは RTR ファイルに明示的に設定しても、デフォルトの LB_WEIGHTED を使用してもかまいません。 どちらの場合でも、クラスタ管理者はリソースを作成するときに値を変更できます (RTR ファイルで Load_balancing_policy の Tunable を NONE または FALSE に設定していない場合)。 有効な値は次のとおりです。

LB_WEIGHTED

Load_balancing_weights プロパティで設定されているウエイトに従って、さまざまなノードに負荷が分散されます。

LB_STICKY

スケーラブルサービスの指定のクライアント (クライアントの IP アドレスで識別される) は、常に同じクラスタノードに送信されます。

LB_STICKY_WILD

ワイルドカードスティッキーサービスの IP アドレスに接続されているクライアント (クライアントの IP アドレスで識別される) は、着信しているポート番号に関わらず、常に、同じクラスタノードに送信されます。

Load_balancing_policy、LB_STICKY、LB_STICKY_WILD を持つスケーラブルなサービスの場合、サービスがオンラインの状態で Load_balancing_weights を変更すると、既存のクライアントとの関連がリセットされることがあります。 リセットされると、(同じクラスタ内にある) 今までサービスを行っていたノードとは別のノードが、後続のクライアント要求を処理します。

同様に、サービスの新しいインスタンスをクラスタ上で開始すると、既存のクライアントとの関連がリセットされることがあります。

Load_balancing_weights

個々のノードへ負荷を送信することを指定します。 形式は weight@node, weight@node です。weight は、node に分散される負荷の相対的な割り当てを示す整数です。 ノードに分散される負荷の割合は、このノードのウェイトをアクティブなインスタンスのすべてのウェイトの合計で割った値になります。 たとえば、1@1,3@2 は、ノード 1 に負荷の 1/4 が割り当てられ、ノード 2 に負荷の 3/4 が割り当てられることを意味します。

Port_list

サーバーが待機するポートです。 このプロパティのデフォルト値は空の文字列です。 ポートのリストは RTR ファイルに指定できます。 このファイルで指定しない場合、クラスタ管理者は、リソースを作成するときに、実際のポートのリストを提供する必要があります。

データサービスは、管理者がスケーラブルまたはフェイルオーバーのどちらにでも構成できるように作成できます。 このためには、データサービスの RTR ファイルにおいて、Failover リソースタイププロパティと Scalable リソースプロパティの両方を FALSE に宣言します。 Scalable プロパティは作成時に調整できるように指定します。

Failover プロパティが FALSE の場合、リソースはスケーラブルリソースグループに構成できます。 管理者はリソースを作成するときに Scalable を TRUE に変更する、すなわちスケーラブルサービスを作成することによって、共有アドレスを有効にできます。

一方、Failover が FALSE の場合でも、管理者はリソースをフェイルオーバーリソースグループに構成して、フェイルオーバーサービスを実装できます。 この場合、Scalable の値 (FALSE) は変更しません。 このような偶然性に対処するために、Scalable プロパティの Validate メソッドで妥当性を検査する必要があります。 Scalable が FALSE の場合、リソースがフェイルオーバーリソースグループに構成されていることを確認します。

スケーラブルリソースの詳細については、『Sun Cluster の概念 (Solaris OS 版)』を参照してください。

スケーラブルサービスの妥当性検査

Scalable プロパティが TRUE であるリソースが作成または更新されるたびに、RGM は、さまざまなリソースプロパティの妥当性を検査します。 プロパティが正しく構成されていない場合、RGM は作成または更新を拒否します。 RGM は次の検査を行います。

• Network_resources_used プロパティは、空の文字列であってはならず、既存の共有アドレスリソースの名前を含む必要があります。 スケーラブルリソースを含むリソースグループの Nodelist にあるすべてのノードは、指定した共有アドレスリソースの 1 つである NetIfList プロパティまたは AuxNodeList プロパティに存在する必要があります。

• スケーラブルリソースを含むリソースグループの RG_dependencies プロパティは、スケーラブルリソースの Network_resources_used プロパティに存在する、すべての共有アドレスリソースのリソースグループを含む必要があります。

• Port_list プロパティは、空の文字列であってはならず、ポートとプロトコル (tcp または udp) のペアのリストを含む必要があります。 たとえば、

  Port_list=80/tcp,40/udp

  となります。

データサービスの作成と検証

この節では、データサービスを作成および検証する方法について説明します。

キープアライブの使用方法

サーバー側で TCP キープアライブを有効にしておくと、サーバーはダウン時の (または、ネットワークで分割された) クライアントのリソースを浪費しません。 長時間稼働するようなサーバーでこのようなリソースがクリーンアップされない場合、浪費されたリソースが無制限に大きくなり、最終的にはクライアントに障害が発生して再起動します。

クライアントサーバー通信が TCP ストリームを使用する場合、クライアントとサーバーは両方とも TCP キープアライブ機構を有効にしなければなりません。 これは、非高可用性の単一サーバーの場合でも適用されます。

ほかにも、キープアライブ機構を持っている接続指向のプロトコルは存在します。

クライアント側で TCP キープアライブを有効にしておくと、ある物理ホストから別の物理ホストに論理ホストがフェイルオーバーまたはスイッチオーバーしたとき、接続の切断がクライアントに通知されます。 このようなネットワークアドレスリソースの転送 (フェイルオーバーやスイッチオーバー) が発生すると、TCP 接続が切断されます。 しかし、クライアント側で TCP キープアライブを有効にしておかなければ、接続が休止したとき、必ずしも接続の切断はクライアントに通知されません。

たとえば、クライアントが、実行に時間がかかる要求に対するサーバーからの応答を待っており、また、クライアントの要求メッセージがすでにサーバーに到着しており、TCP 層で認識されているものと想定します。 この状況では、クライアントの TCP モジュールは要求を再転送し続ける必要はないので、クライアントアプリケーションはブロックされて、要求に対する応答を待ちます。

TCP キープアライブ機構は必ずしもあらゆる限界状況に対応できるわけではないので、クライアントアプリケーションは、可能であれば、TCP キープアライブ機構に加えて、独自の定期的なキープアライブをアプリケーションレベルで実行する必要があります。 アプリケーションレベルのキープアライブ機構を使用するには、通常、クライアントサーバー型プロトコルが NULL 操作、または、少なくとも効率的な読み取り専用操作 (状態操作など) をサポートする必要があります。

HA データサービスの検証

この節では、高可用性環境におけるデータサービスの実装を検証する方法について説明します。 この検証は一例であり、完全ではないことに注意してください。 実際に稼働させるマシンに影響を与えないように、検証時は、検証用の Sun Cluster 構成にアクセスする必要があります。

リソースグループが物理ホスト間で移動するような場合を想定して、HA データサービスが適切に動作するかどうかを検証します。 たとえば、システムがクラッシュした場合や、scswitch コマンドを使用した場合です。 また、このような場合にクライアントマシンがサービスを受け続けられるかどうかも検証します。

メソッドの呼び出し回数への非依存性を検証します。 たとえば、各メソッドを一時的に、元のメソッドを 2 回以上呼び出す短いシェルスクリプトに変更します。

リソース間の依存関係の調節

あるクライアントサーバーのデータサービスが、クライアントからの要求を満たすために、別のクライアントサーバーのデータサービスに要求を行うことがあります。 このように、データサービス A が自分のサービスを提供するために、データサービス B にそのサービスを提供してもらう場合、データサービス A はデータサービス B に依存していると言います。 この要件を満たすために、Sun Cluster では、リソースグループ内でリソースの依存関係を構築できます。 依存関係は、Sun Cluster がデータサービスを起動および停止する順番に影響します。 詳細については、scrgadm(1M) のマニュアルページを参照してください。

あるリソースタイプのリソースが別のリソースタイプのリソースに依存する場合、データサービス開発者は、リソースとリソースグループを適切に構成するようにユーザーに指示するか、これらを正しく構成するスクリプトまたはツールを提供する必要があります。 依存するリソースを依存されるリソースと同じノード上で実行する必要がある場合、両方のリソースを同じリソースグループ内で構成する必要があります。

明示的なリソースの依存関係を使用するか、このような依存関係を省略して、HA データサービス独自のコードで別のデータサービスの可用性をポーリングするかを決定します。 依存するリソースと依存されるリソースが異なるノード上で動作できる場合は、これらのリソースを異なるリソースグループ内で構成します。 この場合、グループ間にはリソースの依存関係を構築できないため、ポーリングが必要です。

データサービスによっては、データを自分自身で直接格納せず、別のバックエンドデータサービスに依頼して、すべてのデータを格納してもらうものもあります。 このようなデータサービスは、すべての読み取り要求と更新要求をバックエンドデータサービスへの呼び出しに変換します。 たとえば、すべてのデータを SQL データベース (Oracle など) に格納するようなクライアントサーバー型のアポイントメントカレンダサービスの場合、 このサービスは独自のクライアントサーバー型ネットワークプロトコルを持っています。 たとえば、RPC 仕様言語 (ONC RPC など) を使用するプロトコルを定義している場合があります。

Sun Cluster 環境では、HA-ORACLE を使用してバックエンド Oracle データベースを高可用性にできます。 つまり、アポイントメントカレンダデーモンを起動および停止する簡単なメソッドを作成できます。 エンドユーザーは Sun Cluster でアポイントメントカレンダのリソースタイプを登録できます。

アポイントメントカレンダアプリケーションが Oracle データベースと同じノード上で動作する必要がある場合、エンドユーザーは、HA-ORACLE リソースと同じリソースグループ内でアポイントメントカレンダリソースを構築して、アポイントメントカレンダリソースを HA-ORACLE リソースに依存するようにします。 この依存関係を指定するには、scrgadm の Resource_dependencies プロパティを使用します。

アポイントメントカレンダリソースが HA-ORACLE リソースとは別のノード上で動作できる場合、エンドユーザーはこれらのリソースを 2 つの異なるリソースグループ内で構成します。 カレンダリソースグループのリソースグループ依存関係を、Oracle リソースグループ上で構築することもできます。 しかし、リソースグループ依存関係が有効になるのは、両方のリソースグループが同時に同じノード上で起動または停止されたときだけです。 したがって、カレンダデータサービスデーモンは、起動後、Oracle データベースが利用可能になるまで、ポーリングして待機します。 この場合、通常、カレンダリソースタイプの Start メソッドは単に成功を戻すだけです。これは、Start メソッドが無限にブロックされると、そのリソースグループがビジー状態になり、それ以降、リソースグループで状態の変化 (編集、フェイルオーバー、スイッチオーバーなど) が行われなくなるためです。 しかし、カレンダリソースの Start メソッドがタイムアウトまたは非ゼロで終了すると、Oracle データベースが利用できない間、リソースグループが複数のノード間でやりとりを無限に繰り返す可能性があります。