test

Sun Cluster データサービス開発ガイド (Solaris OS 版)

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

この章では、アプリケーションの可用性とスケーラビリティーを高める方法を解説し、データサービスの開発に関する詳細な情報について説明します。

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

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

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

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

注 –

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

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

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

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

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

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

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

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

  2. Agent Builder を使用すると、必要な情報を指定するだけで、データサービスを生成できます。これには、ソースコードと実行可能コード、RTR ファイル、およびパッケージが含まれます。

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

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

実際には、データサービスを作成する方法はいくつもあります。たとえば、Agent Builder が生成したコード内の特定の場所に独自のコードを追加するのではなく、生成されたメソッド全体を書き換えたり、生成された監視プログラムを DSDL または RMAPI 関数を使って最初から作成し直したりできます。

しかし、使用する方法に関わらず、ほとんどの場合は Agent Builder を使って開発作業を開始することをお勧めします。次に、その理由を示します。

注 –

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

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

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

注 –

開発マシンでは、必ず Solaris 9 OS または Solaris 10 OS の Developer Distribution または Entire Distribution ソフトウェアグループを使用してください。

コードをコンパイルおよびリンクするとき、ヘッダーファイルとライブラリファイルを識別するオプションを設定する必要があります。

注 –

互換モードでコンパイルされた C++ コードと標準モードでコンパイルされた C++ コードを Solaris オペレーティングシステム製品や Sun Cluster 製品で併用することはできません。

したがって、Sun Cluster で使用する C++ ベースのデータサービスを作成する場合は、そのデータサービスを次のようにコンパイルする必要があります。

クラスタノード以外で開発が終了すると、完成したデータサービスをクラスタに転送して、検証を行うことができます。

この節の手順では、次の作業を完了する方法を説明します。

Procedure開発環境の設定方法

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

  1. スーパーユーザーになるか、RBAC 承認 solaris.cluster.modify を提供する役割になります。

  2. 使用する CD-ROM ディレクトリにディレクトリを変更します。


    # cd cd-rom-directory

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


    # pkgadd -d . SUNWscdev

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

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

    # Makefile for sample data service
...

-I /usr/cluster/include

-L /usr/cluster/lib

-R /usr/cluster/lib
...

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

開発マシン上でデータサービスが完成した場合、データサービスをクラスタに転送して検証する必要があります。転送中のエラーの可能性を減らすため、データサービスのコードと RTR ファイルをパッケージに結合します。そして、サービスを実行する Solaris ホストにそのパッケージをインストールします。

注 –

Agent Builder は、このパッケージを自動的に作成します。

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

Sun Cluster は、データサービスの静的な構成を定義するために使用する、リソースタイププロパティーおよびリソースプロパティーのセットを提供します。リソースタイププロパティーでは、リソースのタイプ、そのバージョン、API のバージョンと同時に、各コールバックメソッドへのパスも指定します。すべてのリソースタイププロパティーのリストについては、「資源タイプのプロパティー」を参照してください。

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

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

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

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

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

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

注 –

リソースタイププロパティー Installed_nodes は、クラスタ管理者のみが構成できます。RTR ファイルでは Installed_nodes を宣言できません。

リソースタイプ宣言の構文は次のようになります。

property-name = value;
注 –

リソースグループ、リソース、およびリソースタイプのプロパティー名は大文字と小文字が区別されません。プロパティー名を指定する際には、大文字と小文字を任意に組み合わせることができます。

次に、サンプルのデータサービス (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 を使用する場合、リソースタイプを定義する企業の略号にします。リソースタイプ名はクラスタ内で一意である必要があります。

注 –

便宜上、リソースタイプ名 (vendoridApplicationname) はパッケージ名として使用されます。Solaris 9 OS 以降では、ベンダー ID とアプリケーション名の両方を合わせて 10 文字以上を指定できます。

一方、Agent Builder はどの場合でもリソースタイプ名からパッケージ名を系統だてて生成します。つまり、Agent Builder は 9 文字の制限を適用します。

RT_description

リソースタイプの簡潔な説明です。

RT_version

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

API_version

API のバージョンです。たとえば、API_version = 2 は、データサービスを Sun Cluster 3.0 以降の任意のバージョンの Sun Cluster にインストールできることを示します。API_version = 7 は、データサービスを Sun Cluster 3.2 以降の任意のバージョンの Sun Cluster にインストールできることを示します。ただし、API_version = 7 は、Sun Cluster 3.2 よりも前にリリースされたバージョンの Sun Cluster にはデータサービスをインストールできないことも示します。このプロパティーについては、「資源タイプのプロパティー」の API_version の項目で詳しく説明しています。

Failover = TRUE

データサービスが、複数のノード上で同時にオンラインにできるリソースグループ上では実行できないことを示します。つまり、この宣言はフェイルオーバーデータサービスを指定しています。このプロパティーについては、「資源タイプのプロパティー」の Failover のエントリで詳しく説明しています。

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 ファイルを正しく構成するために、次の条件を満たしていることを確認します。

ゾーンクラスタのリソースタイプは、RTR ファイルを /usr/cluster/lib/rgm/rtreg/ ディレクトリに置くことで登録することもできます。このディレクトリ内の RTR ファイルで宣言したリソースタイププロパティーをクラスタ管理者が構成することはできません。

/opt/cluster/lib/rgm/rtreg/ ディレクトリ内の RTR ファイルで定義されたリソースタイプは、グローバルクラスタ専用として使用されます。

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

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

{
    attribute = value;
    attribute = value;
             .
             .
             .
    attribute = value;
}

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

RGM メソッドコールバックがタイムアウトすると、メソッドのプロセスツリーが、SIGTERM シグナルではなく、SIGABRT シグナルによって消去されます。その結果、プロセスグループのすべてのメンバーが、メソッドがタイムアウトを超過したノード上の /var/cluster/core ディレクトリまたは /var/cluster/core ディレクトリのサブディレクトリにコアダンプファイルを生成します。このコアダンプファイルは、メソッドがタイムアウトを超過した理由を判定できるように生成されます。

注 –

新しいプロセスグループを作成するデータサービスメソッドを書かないでください。データサービスメソッドで新しいプロセスグループを作成する必要がある場合は、SIGTERM および SIGABRT シグナルのシグナルハンドラを書きます。また、シグナルハンドラは、プロセスを終了する前に、単数または複数の子プロセスグループに SIGTERM または SIGABRT シグナルを転送する必要があります。これらのシグナルのシグナルハンドラを書くと、使用するメソッドによって生成されるすべてのプロセスが、正しく終了される可能性が高まります。

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

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

...

# Resource property declarations appear as a list of bracketed
# entries after the resource type declarations. The property 
# name declaration must be the first attribute after the open
# curly bracket of a resource property entry.
#
# Set minimum and default for method timeouts.
{
        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 秒です。「リソースプロパティーの属性」にリソースプロパティー属性のリストを示します。

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

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

# The number of retries to be done within a certain period before concluding
# that the application cannot be successfully started on this node.
{
        PROPERTY = Retry_count;
        MAX=10;
        DEFAULT=2;
        TUNABLE = ANYTIME; 
}

# Set Retry_interval as a multiple of 60 since it is converted from seconds
# to minutes, rounding up. For example, a value of 50 (seconds)
# is converted to 1 minute. Use this property to time the number of
# retries (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 = ANYTIME;
        DEFAULT = ;
}

これらのリソースプロパティー宣言には、TUNABLE 属性が含まれています。この属性は、この属性が関連付けられているプロパティーの値をクラスタ管理者が変更できる場合を制限します。たとえば値 AT_CREATION は、クラスタ管理者が値を指定できるのはリソースの作成時だけであり、あとでは値を変更できないことを示します。

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

Failover_mode

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

Thorough_probe_interval, Retry_count, and Retry_interval

障害モニターで使用します。Tunable は ANYTIME に等しいため、障害モニターが適切に機能していない場合、クラスタ管理者はいつでも調整できます。

Network_resources_used

このリソースが依存関係を持っている論理ホスト名または共有アドレスリソースのリスト。このリストには、プロパティー Resource_dependencies、Resource_dependencies_weak、Resource_dependencies_restart、または Resource_dependencies_offline_restart に現れるすべてのネットワークアドレスリソースが含まれます。

RTR ファイルに Scalable プロパティーが宣言されている場合、RGM は自動的にこのプロパティーを作成します。Scalable プロパティーが RTR ファイルで宣言されていない場合、Network_resources_used は RTR ファイルで明示的に宣言されていないかぎり使用できません。

ユーザーが Network_resources_used プロパティーに値を割り当てていない場合、その値は、リソース依存関係のプロパティーの設定に基づいて、RGM によって自動的に更新されます。このプロパティーを直接設定する必要はありません。その代わりに、Resource_dependencies、Resource_dependencies_offline_restart、Resource_dependencies_restart、または Resource_dependencies_weak プロパティーを設定します。

旧リリースの Sun Cluster ソフトウェアとの互換性を維持するために、Network_resources_used プロパティーの値を直接に設定することもできます。ユーザーが Network_resources_used プロパティーの値を直接設定した場合は、Network_resources_used プロパティーの値がリソース依存関係のプロパティーの設定に基づいて更新されることはありません。リソース名を Network_resources_used プロパティーに追加すると、そのリソース名は自動的に Resource_dependencies プロパティーにも追加されます。この依存関係を削除する唯一の方法は、Network_resources_used プロパティーからその依存関係を削除することです。ネットワークリソースの依存関係が元々 Resource_dependencies プロパティーに追加されたものなのか Network_resources_used プロパティーに追加されたものなのかがわからない場合は、両方のプロパティーから依存関係を削除します。

Scalable

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

Load_balancing_policy and Load_balancing_weights

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

Port_list

アプリケーションが待機するポートのリストです。Agent Builder がこのプロパティーを宣言するため、クラスタ管理者はデータサービスを構成するとき (存在する場合) に、リソースのリストを指定できます。

拡張プロパティーの宣言

拡張プロパティーは、サンプル RTR ファイルの最後に出現します。

# Extension Properties
#

# The cluster administrator must set the value of this property to point to the 
# directory that contains the configuration files used by the application.
# For this application, smpl, specify the path of the configuration file on
# PXFS (typically named.conf).
{
        PROPERTY = Confdir_list;
        EXTENSION;
        STRINGARRAY;
        TUNABLE = AT_CREATION;
        DESCRIPTION = "The Configuration Directory Path(s)";
}

# The following two properties control restart of the fault monitor.
{
        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.";
}
# Time out value in seconds for the probe.
{
        PROPERTY = Probe_timeout;
        EXTENSION;
        INT;
        DEFAULT = 120;
        TUNABLE = ANYTIME;
        DESCRIPTION = "Time out value for the probe (seconds)";
}

# Child process monitoring level for PMF (-C option of pmfadm).
# Default of -1 means to not use the -C option of pmfadm.
# A value of 0 or greater indicates the desired level of child-process.
# monitoring.
{
        PROPERTY = Child_mon_level;
        EXTENSION;
        INT;
        DEFAULT = -1;
        TUNABLE = ANYTIME;
        DESCRIPTION = “Child monitoring level for PMF";
}
# User added code -- BEGIN VVVVVVVVVVVV
# User added code -- END   ^^^^^^^^^^^^

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

Confdir_list

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

Monitor_retry_count, Monitor_retry_interval, and 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 関数が存在しないため、プロパティー機構を使用して、データサービスの動的な状態情報を格納することはできません。したがって、動的な状態情報は、広域ファイルに格納するようにします。

注 –

クラスタ管理者は、 clresource コマンドを使用するか、またはグラフィカル管理コマンドまたはグラフィカル管理インタフェースを使って、特定のリソースプロパティーを設定できます。ただし、 clresource はコールバックメソッドから呼び出さないでください。 これは、クラスタの再構成時、つまり GRM がメソッドを呼び出すときに clresource がエラーになるためです。

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

一般に、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 メソッドは呼び出し回数に依存してもかまいません。

メソッドがゾーンで呼び出される仕組み

Global_zone リソースタイププロパティーは、RTR ファイルで宣言すると、リソースタイプのメソッドが大域ゾーン内で実行されるかどうかを示します。Global_zone プロパティーが TRUE に等しい場合、リソースを含むリソースグループが非大域ゾーンで動作するように構成されているときでも、メソッドは大域ゾーンで実行されます。

Global_zone が TRUE に等しいリソースが非大域ゾーン内で構成されている場合、大域ゾーン内で呼び出されるメソッドは -Z zonename オプション付きで呼び出されます。zonename オペランドは、リソースが実際に構成されている非大域ゾーンの Solaris ゾーン名を表します。このオペランドの値がメソッドに渡されます。

リソースが大域ゾーン内で構成されている場合には、-Z zonename オプションは呼び出されず、非大域ゾーン名がメソッドに渡されることはありません。

Global_zone リソースタイププロパティーの詳細は、「資源タイプのプロパティー」および rt_properties(5)のマニュアルページを参照してください。

汎用データサービス

汎用データサービス (Generic Data Service、GDS) は、単純なアプリケーションを Sun Cluster Resource Group Manager (RGM) フレームワークに組み込むことにより、単純なアプリケーションの高可用性とスケーラビリティーを実現する機構です。この機構では、アプリケーションの可用性やスケーラビリティーを高めるための一般的な方法である、データサービスのコーディングは必要ありません。

GDS モデルは、コンパイル済みのリソースタイプ SUNW.gds により、RGM フレームワークとやりとりします。詳細は、第 10 章汎用データサービスを参照してください。

アプリケーションの制御

コールバックメソッドを使用すると、RGM は基になるリソース (アプリケーション) を制御できるようになります。たとえば、ノードがクラスタに結合するとき、またはクラスタから分離するときに、コールバックメソッドを使用することにより、RGM は影響下にあるリソースを制御できるようになります。

リソースの起動と停止

リソースタイプを実装するには、少なくとも、Start メソッドと Stop メソッドが必要です。

Start および Stop メソッドの使用

RGM は、リソースタイプのメソッドプログラムを、適切なノード上で適切な回数だけ呼び出して、リソースグループをオフラインまたはオンラインにします。たとえば、クラスタノードのクラッシュ後、RGM は、そのノードがマスターしているリソースグループを新しいノードに移動します。この場合、Start メソッドを実装することによって、(ほかにも提供されるものはありますが) 生き残ったホストノード上で各リソースを再起動するための手段を RGM に提供する必要があります。

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

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

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

RGM メソッドコールバックがタイムアウトすると、メソッドのプロセスツリーが、SIGTERM シグナルではなく、SIGABRT シグナルによって消去されます。その結果、プロセスグループのすべてのメンバーが、メソッドがタイムアウトを超過したノード上の /var/cluster/core ディレクトリまたは /var/cluster/core ディレクトリのサブディレクトリにコアダンプファイルを生成します。このコアダンプファイルは、メソッドがタイムアウトを超過した理由を判定できるように生成されます。

注 –

新しいプロセスグループを作成するデータサービスメソッドを書かないでください。データサービスメソッドで新しいプロセスグループを作成する必要がある場合は、SIGTERM および SIGABRT シグナルのシグナルハンドラを書きます。また、シグナルハンドラは、プロセスを終了する前に、単数または複数の子プロセスグループに SIGTERM または SIGABRT シグナルを転送する必要があります。これらのシグナルのシグナルハンドラを書くと、使用するメソッドによって生成されるすべてのプロセスが、正しく終了される可能性が高まります。

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() または clnode evacuate コマンドによるスイッチオーバー) のあとでネットワークアドレスとデータサービスのどちらが最初にオンラインになるかによってクライアントソフトウェアの応答が異なるかどうかを考えます。たとえば、クライアントの実装が最小限の再試行を行うだけで、データサービスのポートが利用できないと判断すると、すぐにあきらめる場合もあります。

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

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

注 –

クラスタに RPC サービスをインストールする場合、サービスはプログラム番号 100141、100142、および 100248 を使用できません。これらの番号は、Sun Cluster デーモン rgmd_receptionist 、fed、および pmfd 用に予約されています。インストールした RPC サービスがこれらのプログラム番号のいずれかを使用する場合は、RPC サービスのプログラム番号を変更します。

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

Init、Fini、Boot オプションメソッドの使用

3 つのオプションメソッドである Init、Fini、Boot を使用すると、RGM がリソースで初期化コードと終了コードを実行できるようになります。

Init メソッドの使用

次の条件のいずれかの結果としてリソースが管理下に置かれる場合、RGM は Init メソッドを実行して、1 回だけリソースの初期化を実行します。

Fini メソッドの使用

リソースが RGM によって管理されなくなったとき、RGM は Fini メソッドを実行して、そのリソースの使用後のクリーンアップを行います。Fini メソッドは、通常、Init メソッドにより実行された初期化を元に戻します。

RGM は、次の状態が発生した場合、リソースが管理されなくなったノード上で Fini を実行します。

「ノードリスト」はリソースグループの Nodelist またはリソースタイプの Installed_nodes リストのいずれかです。「ノードリスト」がリソースグループの Nodelist とリソースタイプの Installed_nodes リストのどちらを指すかは、リソースタイプの Init_nodes プロパティーの設定に依存します。Init_nodes プロパティーは RG_PRIMARIES または RT_INSTALLED_NODE に設定できます。大部分のリソースタイプでは、Init_nodes はデフォルトである RG_PRIMARIES に設定されます。この場合、Init メソッドと Fini メソッドは両方とも、リソースグループの Nodelist で指定されているノード上で実行されます。

Init メソッドが実行する初期化の種類は、次のように、ユーザーが実装した Fini メソッドが実行する必要があるクリーンアップの種類を定義します。

Fini メソッドを実装する際のガイドライン

実装する Fini メソッドは、ノード固有の構成だけをクリーンアップするのか、それともノード固有の構成とクラスタ全体にわたる構成の両方をクリーンアップするのかを判断する必要があります。

特定のノード上でのみリソースが管理されなくなった場合、Fini メソッドはノード固有のローカル構成をクリーンアップできます。しかし、ほかのノード上ではリソースは引き続き管理されているため、Fini メソッドはクラスタ全体にわたるグローバル構成をクリーンアップしてはなりません。リソースがクラスタ全体にわたって管理されなくなった場合には、Fini メソッドはノード固有の構成とグローバル構成の両方についてクリーンアップを実行できます。実装する Fini メソッドのコードは、Fini メソッドを実行するローカルのノードがリソースグループのノードリストに含まれているかどうかを判定することによって、これら 2 つの場合を区別できます。

ローカルのノードがリソースグループのノードリストに含まれている場合は、リソースが削除されようとしているか、管理されない状態に移行しようとしています。リソースはどのノード上でもアクティブでなくなっています。この場合、実装する Fini メソッドでは、ローカルノード上のノード固有の構成だけでなく、クラスタ全体にわたる構成についてもクリーンアップする必要があります。

ローカルのノードがリソースグループのノードリストに含まれていない場合は、Fini メソッドでそのローカルノード上のノード固有の構成をクリーンアップできます。しかし、Fini メソッドでクラスタ全体にわたる構成をクリーンアップしてはなりません。この場合、ほかのノード上でリソースが引き続きアクティブになっています。

また、Fini は呼び出し回数に依存しないようにコーディングする必要もあります。つまり、Fini メソッドが以前の実行でリソースをクリーンアップした場合でも、以降の Fini 呼び出しは正常に終了します。

Boot メソッドの使用

RGM は、クラスタに結合した (つまり、ブートまたはリブートしたばかりの) ノードで Boot メソッドを実行します。

Boot メソッドは、通常、Init と同じ初期化を実行します。Boot は呼び出し回数に依存しないようにコーディングする必要があります。つまり、Boot メソッドが以前の実行でリソースを初期化した場合でも、以降の Boot 呼び出しは正常に終了します。

リソースの監視

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

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

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

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

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

注 –

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

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

大域ゾーン内でのみ実行されるモニターおよびメソッドの実装

ほとんどのリソースタイプは、リソースグループのノードリストに出現するすべてのノードでメソッドを実行します。ただし、リソースグループが非大域ゾーン内 (つまりゾーンクラスタノードまたはグローバルクラスタ非投票ノードのいずれか) で構成されている場合でも、大域ゾーン内ですべてのメソッドを実行することが必要なリソースタイプもいくつかあります。これが必要となるのは、ネットワークアドレスやディスクなど、大域ゾーンからしか管理できないシステムリソースを管理しているリソースタイプの場合です。このようなリソースタイプは、リソースタイプ登録 (Resource Type Registration、RTR) ファイルの中で Global_zone プロパティーを TRUE に設定することによって識別されます。

注意 – 注意 –

信頼できる既知のソースであるリソースタイプを除いて、Global_zone プロパティーに TRUE が設定されているリソースタイプは登録しないでください。このプロパティーに TRUE を設定したリソースタイプは、ゾーン分離をすり抜け、危険があります。

Global_zone=TRUE を宣言するリソースタイプは、Global_zone_override リソースプロパティーを宣言する場合もあります。この場合、Global_zone_override プロパティーの値は、そのリソースの Global_zone プロパティーの値より優先されます。Global_zone_override プロパティーの詳細は、「リソースのプロパティー」 および r_properties(5)のマニュアルページを参照してください。

Global_zone リソースタイププロパティーが TRUE に設定されていない場合、モニターやメソッドはリソースグループのノードリストに列挙されている任意のノードで実行されます。

scha_control() および scha_resource_setstatus() 関数、そして scha_control および scha_resource_setstatus コマンドは、それらの関数やコマンドの実行元のノードで暗黙的に動作します。Global_zone リソースタイププロパティーが TRUE に等しい場合、これらの関数やコマンドは、リソースが非大域ゾーンで構成されているときに、別に呼び出される必要があります。

リソースが非大域ゾーンで構成されているときは、zonename オペランドの値が -Z オプションを通じてリソースタイプメソッドに渡されます。実装するメソッドやモニターからこれらのいずれかの関数やコマンドを呼び出す場合、正しい処理を行わないと、大域ゾーンで正しく動作しません。実装するメソッドやモニターは、リソースグループのノードリストに含まれているリソースが構成されている非大域ゾーンで動作するようにする必要があります。

実装するメソッドやモニターのコードでこれらの条件を正しく処理していることを確認するため、次の作業が行われていることをチェックしてください。

Global_zone リソースタイププロパティーが TRUE に等しいリソースが、ZONE_LOCAL の問い合わせの optag の値を指定して scha_cluster_get() を起動した場合、大域ゾーンの名前が返されます。この場合、呼び出した側のコードでは文字列 :zonename をローカルノード名に連結して、リソースが実際に構成されているゾーンを取得する必要があります。zonename は、-Z zonename コマンド行オプション内のメソッドに渡されるものと同じゾーン名です。コマンド行内に -Z オプションがない場合は、リソースグループが大域ゾーン内に構成されるので、ゾーン名をノード名に連結する必要はありません。

同様に、呼び出した側のコードで、たとえば非大域ゾーンでのリソースの状態を問い合わせる場合は、RESOURCE_STATE の optag 値ではなく RESOURCE_STATE_NODE の optag 値を指定して、scha_resource_get() を呼び出す必要があります。この場合、RESOURCE_STATE の optag 値によって、リソースが実際に構成されている非大域ゾーンでの問い合わせではなく、大域ゾーンでの問い合わせが実行されます。

DSDL 関数は、その性質上、-Z zonename オプションを処理します。したがって、scds_initialize() 関数は、リソースが実際に構成されている非大域ゾーンに対応した、該当するリソースプロパティーおよびリソースグループプロパティーを取得します。そのほかの DSDL 問い合わせは、そのノード上で暗黙的に動作します。

DSDL 関数 scds_get_zone_name() を使用すると、-Z zonename コマンド行オプションの中でメソッドに渡されたゾーンの名前を問い合わせることができます。-Z zonename が渡されていない場合には、scds_get_zone_name() 関数は NULL を返します。

次の条件がどちらも成り立つ場合、複数の Boot メソッドが大域ゾーン内で同時に実行されることがあります。

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

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

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

プロセス管理の提供

リソースモニターとリソース制御コールバックを実装するために、プロセス管理機能が RMAPI および DSDL に提供されています。RMAPI は次の機能を定義します。

プロセス監視機能 (Process Monitor Facility、PMF): pmfadm および rpc.pmfd

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

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

このコマンドとデーモンについては、pmfadm(1M) および rpc.pmfd(1M)のマニュアルページを参照してください。

halockrun

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

このコマンドについては、halockrun(1M)のマニュアルページを参照してください。

hatimerun

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

DSDL では、hatimerun コマンドの機能を実装するための scds_hatimerun() 関数が提供されています。

このコマンドについては、hatimerun(1M)のマニュアルページを参照してください。

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

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

リソースが作成されるとき、RGM は任意の Validate メソッドを呼び出します。また、クラスタ管理者がリソースまたはそのリソースのあるグループのプロパティーを更新したときにも、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 アクセス関数を使用して、アクティブなリソースに影響する可能性があるプロパティー値を読み取り、その値に従って、実行中のリソースを調節できます。

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

フェイルオーバーリソースグループには、ネットワークアドレス (組み込みリソースタイプである LogicalHostname や SharedAddress など) やフェイルオーバーリソース (フェイルオーバーデータサービス用のデータサービスアプリケーションリソースなど) があります。ネットワークアドレスリソースは、データサービスがフェイルオーバーまたはスイッチオーバーする場合に、依存しているデータサービスリソースとともに、クラスタノード間を移動します。RGM は、フェイルオーバーリソースの実装をサポートするプロパティーをいくつか提供します。

グローバルクラスタでは、フェイルオーバーリソースグループは別の Solaris ホストまたは同じ Solaris ホスト上のノードにフェイルオーバーできます。フェイルオーバーリソースグループは、この方法でゾーンクラスタにフェイルオーバーすることはできません。ただし、ホストで障害が発生すると、同一ホスト上のノードにこのリソースグループをフェイルオーバーした場合に高可用性は得られません。とはいえ、同一ホスト上のノードに対するリソースグループのフェイルオーバーは、テストまたはプロトタイプ化の際に便利な場合もあります。

ブール型の 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 リソースグループプロパティーは、グループ内におけるすべてのネットワークアドレスリソース (LogicalHostname や SharedAddress) への非ネットワークアドレスリソースの暗黙で強力な依存関係を、RGM が強制することを指定します。その結果、グループ内のネットワークアドレスが「起動」に構成されるまで、グループ内の非ネットワークアドレス (データサービス) リソースの Start メソッドは呼び出されません。Implicit_network_dependencies プロパティーのデフォルトは TRUE です。

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

スケーラブルリソースは、同時に複数のノードでオンラインになることができます。スケーラブルリソース (ネットワーク負荷分散を使用) は、グローバルクラスタ非投票ノードでも動作するように構成できます。ただし、そのようなスケーラブルリソースを実行できるのは、Solaris ホストごとに 1 つのノード内だけです。スケーラブルリソースには、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 ファイルで Scalable プロパティーを宣言した場合、RGM はそのリソースに対して、次のようなスケーラブルプロパティーのセットを自動的に作成します。

Network_resources_used

このリソースが依存関係を有する共有アドレスリソースを特定します。このリストには、プロパティー Resource_dependencies、Resource_dependencies_weak、Resource_dependencies_restart、または Resource_dependencies_offline_restart に現れるすべてのネットワークアドレスリソースが含まれます。

RTR ファイルに Scalable プロパティーが宣言されている場合、RGM は自動的にこのプロパティーを作成します。Scalable プロパティーが RTR ファイルで宣言されていない場合、Network_resources_used は RTR ファイルで明示的に宣言されていないかぎり使用できません。

ユーザーが Network_resources_used プロパティーに値を割り当てていない場合、その値は、リソース依存関係のプロパティーの設定に基づいて、RGM によって自動的に更新されます。このプロパティーを直接設定する必要はありません。その代わりに、Resource_dependencies、Resource_dependencies_offline_restart、Resource_dependencies_restart、または Resource_dependencies_weak プロパティーを設定します。

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 アドレスに接続され、送信時に使用されるポート番号とは無関係に、常に同じクラスタノードに送信されます。

LB_STICKY または LB_STICKY_WILD の Load_balancing_policy を持つスケーラブルサービスの場合、サービスがオンラインの状態で 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 は次の検査を行います。

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

この節では、データサービスの作成と検証の方法について説明します。TCP キープアライブを使用したサーバーの保護、高可用性データサービスの検証、およびリソース間の依存関係の調節などについて説明します。

TCP キープアライブを使用したサーバーの保護

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

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

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

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

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

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

HA データサービスの検証

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

HA データサービスは、クラスタ内のすべての Solaris ホスト上ではなく、1 つの Solaris ホスト上のグローバルクラスタ非投票ノードで検証します。データサービスがグローバルクラスタ非投票ノード内で想定どおりに動作していると判断した場合は、次にクラスタ全体で検証を実行できます。ホスト上のグローバルクラスタ非投票ノード内で動作している HA データサービスは、正常に動作していない場合でも、ほかのノード内またはほかのホスト上で動作しているデータサービスの動作を妨げることはないと考えられます。

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

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

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

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

リソースタイプのリソースが別のタイプのリソースに依存する場合、リソースとリソースグループを適切に構成するようにクラスタ管理者に指示する必要があります。または、これらを正しく構成するスクリプトまたはツールを提供します。

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

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

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

HA-ORACLE リソースが、アポイントメントカレンダリソースとは別のノード上で動作する必要がある場合、クラスタ管理者はこれらのリソースを 2 つのリソースグループ内に構成します。したがって、クラスタ管理者はアポイントメントカレンダリソースを HA-ORACLE リソースに依存するようにします。

クラスタ管理者は次のいずれかを実行して、リソースを依存するようにします。

カレンダデータサービスデーモンは、起動後、Oracle データベースが利用可能になるまで、ポーリングしながら待機します。この場合、通常、カレンダリソースタイプの Start メソッドは成功を戻します。ただし、Start メソッドが無限にブロックされると、そのリソースグループがビジー状態に移行します。このビジー状態になると、それ以降、リソースグループで状態の変化 (編集、フェイルオーバー、スイッチオーバーなど) が行われなくなります。カレンダリソースの Start メソッドがタイムアウトするか非ゼロ状態で終了すると、Oracle データベースが利用できない間、タイムアウトまたは非ゼロ終了状態により、リソースグループが複数のノード間でやりとりを無限に繰り返す可能性があります。