test

Sun Cluster 3.0 データサービス開発ガイド

第 2 章 RMAPI の使用方法

この章では、RMAPI (Resource Management (リソース管理) API) を使用してリソースタイプを実装するための詳細な方法について説明します。

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

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

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

リソースタイププロパティは、リソースタイプ登録 (RTR) ファイルで宣言します。RTR ファイルは、クラスタ管理者が Sun Cluster でデータサービスを登録するときの、データサービスの初期構成を定義します。Installed_nodes の例外を除いて、クラスタ管理者はリソースタイププロパティを構成できません。

注 -

表 A-1 は、リソースタイププロパティとともに、そのプロパティが任意、必須、または条件付きのどれであるかも示します。任意プロパティは、必ずしも RTR ファイルに指定する必要はありません。任意プロパティを RTR ファイルに指定しなかった場合、システムがデフォルト値を提供します。この表には、任意プロパティのデフォルト値も示します。必須プロパティを RTR ファイルに宣言しなかった場合、データサービスの登録は失敗します。条件付きプロパティを RTR ファイルに宣言しなかった場合、RGM はそのプロパティを作成しないため、クラスタ管理者は使用できません。

次に、RTR ファイルにおけるリソースタイププロパティのエントリの例を示します。


# リソースタイプの登録情報の例
Resource_type = example_RT; 
Vendor_id = SUNW;
Pkglist = SUNWxxx;
RT_Basedir = /opt/SUNWxxx;
START			=	bin/service_start;
STOP			=	bin/service_stop;
ヒント -

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

Sun Cluster はまた、Failover_mode、Thorough_probe_interval、およびメソッドタイムアウトなど、リソースの静的な構成を定義するリソースプロパティも提供します。Resource_state や Status などの動的なリソースプロパティは、管理しているリソースのアクティブな状態を反映します。リソースプロパティに加えて、リソースはそのリソースタイププロパティも継承します。表 A-2 に、リソースプロパティのリストを示します。

リソースタイププロパティと同様に、リソースプロパティも RTR ファイルに宣言します。Sun Cluster が提供するリソースプロパティ、いわゆる、システム定義プロパティの場合、特定の属性を RTR ファイルで変更できます。たとえば、Sun Cluster は、各コールバックメソッドのメソッドタイムアウトプロパティとそのデフォルト値を提供します。RTR ファイルを使用すれば、デフォルト値を変更できます。

また、RTR ファイルには、新しいリソースプロパティも指定できます。このようなプロパティのことを拡張プロパティと呼びます。拡張プロパティを指定するには、Sun Cluster が提供するプロパティ属性セットを使用します。表 A-4 に、リソースプロパティを変更および定義するための属性のリストを示します。

慣習上、RTR ファイルでは、リソースプロパティ宣言はリソースタイプ宣言の後に続きます。エントリは左中括弧で始まり、右中括弧で終わります。次に、RTR ファイルにおけるリソース宣言の例を示します。

...

 

# リソースプロパティ宣言は、リソースタイプ宣言の後にある中括弧で囲まれたエントリのリストである。

# プロパティ名宣言は、リソースプロパティエントリの左中括弧の直後にある最初の属性である必要がある。

#

# メソッドタイムアウトには、最小値とデフォルト値を設定する。

{

Property = Start_timeout;

MIN=60;

DEFAULT=300;

}

{

Property = Stop_timeout;

MIN=60;

DEFAULT=300;

}

# リソースの作成時に設定できる拡張属性

{

Property = Log_level;

Extension;

enum {OFF, TERSE, VERBOSE};

DEFAULT = TERSE;

TUNABLE = AT_CREATION;

DESCRIPTION = "Controls the detail of message logging";

}

Start_timeout と Stop_timeout はシステム定義リソースプロパティです。Sun Cluster は、すべてのタイムアウトに最小値 (1 秒) とデフォルト値 (3600 秒) を提供します。上記の例の RTR ファイルでは、最小値を 60 秒に、デフォルト値を 300 秒に変更しています。タイムアウト値には、デフォルト値を使用するか 60 秒以上の値に変更できます

注 -

条件付きシステム定義リソースプロパティをそのタイプのリソースとして使用できるようにするには、リソースタイプ登録ファイルに宣言する必要があります。つまり、宣言していない条件付きプロパティは設定または照会できません。

リソースプロパティの重要な点は、クラスタ管理者がある条件下でリソースプロパティを構成できることです。次の表に、クラスタ管理者がリソースプロパティを構成できる条件を表す TUNABLE 属性を示します。

NONE または FALSE

不可 

TRUE または ANYTIME

常時 

AT_CREATION

データサービスをクラスタに追加するとき 

WHEN_DISABLED

データサービスを無効にするとき 

プロパティの構成可能性を制限できる属性もあります。たとえば、Min 属性や Max 属性を使用すると、整数プロパティの範囲を設定できます。リソースプロパティの属性の完全なリストについては、表 A-4 を参照してください。

コールバックメソッドの使用方法

この節では、コールバックメソッドの一般的な使用方法について説明します。

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

RGM がクラスタリソースの活動を制御できるようにするために、コールバックメソッドには、そのリソースプロパティへのアクセスが必要です。API は、リソースのシステム定義プロパティや拡張プロパティにアクセスするための、シェルコマンドと C 関数の両方を提供します。

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

注 -

クラスタ管理者は、scrgadm(1M) コマンドまたは、利用可能なグラフィカル管理インタフェースを通じて、特定のリソースプロパティを設定できます。

リソースプロパティにアクセスするための C 関数は、可変引数インタフェースを持ちます。API は、操作を示す文字列値タグを定義し、可変引数リストの解釈を決定します。get アクセス関数は、初期化、最終処理、メモリー管理を行う open 関数や close 関数と共に使用します。

リソースプロパティにアクセスするには、次の 3 つの関数を一緒に使用します。

これら 3 つの関数は 1 つのマニュアルページ内で説明しています。このマニュアルページには、個々の関数名 scha_resource_open(3HA)、scha_resource_get(3HA)、 scha_resource_close(3HA) でアクセスできます。

シェルスクリプトで使用するコマンドバージョンの scha_resource_get もあります。このコマンドは、フラグ付き引数として、動作タグ、リソース名、およびそのリソースグループ名をとります。他の動作タグ用に、フラグなし引数も利用できます。このアクセスコマンドについての詳細は、scha_resource_get(1HA) のマニュアルページを参照してください。

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

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

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

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

注 -

INIT、FINI、BOOT、UPDATE メソッドも呼び出し回数に依存しない必要があります。START メソッドは呼び出し回数に依存してもかまいません。

アプリケーションの制御

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

リソースの起動と停止

リソースタイプを実装するには、少なくとも、START メソッドと STOP メソッドが必要です。RGM は、リソースタイプのメソッド関数またはプログラムを、適切なノード上で適切な回数だけ呼び出して、リソースグループをオフラインまたはオンラインにします。たとえば、クラスタノードのクラッシュ後、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 (成功) のエラー状態で終了し、ローカルノード上でリソースとそのモニターのすべての活動を正常に停止するべきです。

リソースの初期化と終了

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

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

RGM は、新たにクラスタに結合した、つまり、起動または再起動されたノード上で、BOOT メソッドを呼び出します。

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

リソースの監視

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

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

リソースをオフラインにするとき、RGM は、リソース自身を停止する前に、MONITOR_STOP メソッドを呼び出して、ローカルノード上でリソースのモニターを停止します。リソースをオンラインにするとき、RGM は、リソース自身を起動した後に、MONITOR_START メソッドを呼び出します。

Sun が提供するデータサービスに組み込まれている障害モニターについては、『Sun Cluster 3.0 データサービスのインストールと構成』を参照してください。

リソースグループのフェイルオーバーと再起動の制御

リソースモニターは API 関数 scha_control を使用して、リソースグループを他のノードにフェイルオーバーするように要求できます。妥当性検査の 1 つとして、scha_control は MONITOR_CHECK を呼び出して、検査しているノードがリソースを含むリソースグループをマスターできるかどうかを判断します。MONITOR_CHECK が、そのノードは適切ではないと報告した場合、または、メソッドがタイムアウトした場合、RGM は別のノードを探して、scha_control の要求を遂行しようとします。すべてのノード上で MONITOR_CHECK が失敗した場合、フェイルオーバーは取り消されます。

モニターをサポートするリソースプロパティ

リソースモニターには、コールバックメソッドと同様に、リソースプロパティへの一般的なアクセスが必要です。モニターが使用できるシステム定義のリソースプロパティもあります。しかし、このようなプロパティを使用するかどうかはリソースタイプの実装によって異なります。モニター関連のプロパティは次のとおりです。

このようなリソースプロパティを読み取るには、scha_resource_get(1HA)(3HA) アクセスの関数またはコマンドを使用します。

Status と Status_msg の設定

Status プロパティと Status_msg プロパティは、リソースモニターによって設定され、モニターから見たリソース状態を反映します。API は、このようなプロパティを設定するための scha_resource_setstatus 関数を提供します。詳細は、scha_resource_setstatus(3HA) と scha_resource_setstatus(1HA) のマニュアルページを参照してください。

注 -

scha_resource_setstatus はリソースモニター専用の関数ですが、任意のプログラムから呼び出すことができます。

モニターをサポートするリソースグループプロパティ

モニターが使用できるリソースグループプロパティもあります。Nodelist、Maximum_primaries、Desired_primaries、RG_state、 Resource_list、Global_resources_used です。

このようなリソースグループプロパティを読み取るには、3 種類のアクセス関数を使用します。open 関数 (scha_resourcegroup_open(3HA)) は、リソースグループのアクセスを初期化します。close 関数 (scha_resourcegroup_close(3HA)) は、アクセス関数によって割り当てられたメモリーを解放します。可変引数関数 (scha_resourcegroup_get(3HA)) は、動作タグ値によって起動され、参照引数として渡されるクライアント変数にプロパティ値を戻します。リソースグループプロパティのリストについては、表 A-3 を参照してください。

これら 3 つの関数は 1 つのマニュアルページ内で説明しています。このマニュアルページには、個々の関数名 scha_resourcegroup_open(3HA)、scha_resourcegroup_get(3HA)、 scha_resourcegroup_close(3HA) でアクセスできます。

この機能のスクリプトで使用可能なバージョンは、単一のコマンド scha_resourcegroup_get(1HA) で実装されています。

リソースグループプロパティを直接変更できるインタフェースは存在しません。しかし、scha_control を使用して行った制御要求によって、RGM がリソースグループプロパティを変更することがあります。リソースグループプロパティは、RGM または管理アクションによって変更されます。

モニターをサポートするリソースタイププロパティ

RT_basedir や Installed_nodes のように、モニターが使用できるリソースタイププロパティもあります。このようなプロパティは、たとえば、モニターを実装するプログラムの位置を指定します。

特定のリソースタイプが継承したリソースタイププロパティを読み取るには、scha_resource_get 関数を使用します。任意のリソースタイプのプロパティにアクセスするインタフェースも提供されています。すべてのリソースタイププロパティにアクセスできます。

リソースタイプのアクセスインタフェースは、リソースとリソースグループのアクセスインタフェースのパターンと同じです。open 関数と close 関数は初期化とメモリー管理を行います。可変引数関数は、タグによって決定されたアクセスをプロパティに提供します。これら 3 つの関数は 1 つのマニュアルページ内で説明しています。このマニュアルページには、個々の関数名 scha_resourcetype_open(3HA)、scha_resourcetype_get(3HA)、 scha_resourcetype_close(3HA) でアクセスできます。

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

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

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

プロセス管理の提供

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

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

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

リソースが作成されたとき、および、リソースまたはリソースグループ (リソースを含む) のプロパティが管理アクションによって更新されるとき、RGM は VALIDATE 任意メソッドを呼び出します。RGM はリソースとそのリソースグループのプロパティ値を VALIDATE メソッドに渡します。RGM は、リソースタイプの Init_nodes プロパティが示す複数のクラスタノード上で VALIDATE を呼び出します。RGM は、作成または更新が行われる前に VALIDATE を呼び出します。任意のノード上でメソッドから失敗の終了コードが戻ってくると、作成または更新は取り消されます。

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

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

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

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

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

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

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

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

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

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

ブール型リソースタイププロパティ Scalable は、リソースがスケーラブルであるか (TRUE)、そうでないか (FALSE) を識別します。Scalable プロパティが TRUE であるリソースは、スケーラブルモードであると言います。Scalable プロパティが FALSE であるリソースは、フェイルオーバーモード であると言います。

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

スケーラブルとフェイルオーバーのどちらのモードでも動作するデータサービスを作成できます。このためには、データサービスの RTR ファイルで Scalable リソースプロパティを宣言します。このリソースプロパティは、値なしで宣言しても (デフォルト値は FALSE)、明示的に値を FALSE に設定してもかまいません。デフォルトでは、このリソースはフェイルオーバーモードで動作します。クラスタ管理者が管理ユーティリティで Scalable の値を TRUE に変更すれば、このリソースをスケーラブルモードで実行できます。

クラスタ管理者は、スケーラブルサービスリソースを含むようなスケーラブルリソースグループを作成できます。スケーラブルリソースは共有アドレスリソースを利用するので、クライアントには、スケーラブルサービスの複数のインスタンスが単一のサービスに見えます。スケーラブルリソースが利用する共有アドレスリソースは、異なるフェイルオーバーリソースグループに存在する必要があります。

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

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

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

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

スケーラブルリソースが作成または更新されるとき、RGM は、さまざまなリソースプロパティの妥当性検査を行います。プロパティが正しく構成されていない場合、RGM は作成または更新を拒否します。RGM は次の検査を行います。

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

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

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

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

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

注 -

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

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

開発環境を設定する方法

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

  1. CD-ROM のあるディレクトリに移動します。


    cd CD-ROM_directory

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


    pkgadd -d . SUNWscdev

  3. 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 ファイルを一緒にパッケージに保管して、その後、クラスタのすべてのノード上でパッケージをインストールすることを推奨します。

注 -

データサービスをインストールするときは、pkgadd を使用するかどうかに関わらず、すべてのクラスタノード上にインストールする必要があります。

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

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

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

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

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

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

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

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

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

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

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

HA データサービスの検証

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

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

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

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

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

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

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

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

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

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

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