この章では、データサービスを開発するための詳細な方法について説明します。
この章の内容は、次のとおりです。
データサービスを作成するための最初の手順では、ターゲットアプリケーションが高可用性またはスケーラビリティを備えるための要件を満たしているかどうかを判定します。すべての要件を満たしていない場合は、要件を満たすようにアプリケーションのソースコードを変更します。
次に、アプリケーションが高可用性またはスケーラビリティを備えるための要件を要約します。要件についてのより詳細な情報が必要な場合、あるいは、アプリケーションのソースコードを変更する必要がある場合は、付録 B 「データサービスのコード例」を参照してください。
スケーラブルサービスを実現するためには、次に示す高可用性の要件をすべて満たしている必要があり、さらに追加の要件も満さなければなりません。
Sun Cluster 環境では、ネットワーク対応 (クライアントサーバーモデル) とネットワーク非対応 (クライアントレス) のアプリケーションはどちらも、高可用性またはスケーラビリティを備えることが可能です。ただし、タイムシェアリング環境では、アプリケーションは サーバー上で動作し、telnet または rlogin 経由でアクセスされるため、Sun Cluster は可用性を強化することはできません。
アプリケーションはクラッシュに対する耐障害性 (クラッシュトレラント) を備えていなければなりません。つまり、ノードが予期せぬ停止状態になった後、アプリケーションは再起動時に必要なディスクデータを復元できなければなりません。さらに、クラッシュ後の復元時間にも制限が課せられます。ディスクを復元し、アプリケーションを再起動できる能力は、データの整合性に関わる問題であるため、クラッシュトレラントであることは、アプリケーションが高可用性を備えるための前提条件となります。データサービスは接続を復元できる必要はありません。
アプリケーションは、自身が動作するノードの物理的なホスト名に依存してはなりません。詳細については、「ホスト名」を参照してください。
アプリケーションは、複数の IP アドレスが構成されている環境で正しく動作する必要があります。たとえば、ノードが複数のパブリックネットワーク上に存在する多重ホームホスト環境や、単一のハードウェアインタフェース上に複数の論理インタフェースが構成されているノードが存在する環境で正しく動作しなければなりません。
高可用性を備えるには、アプリケーションデータはクラスタファイルシステム内に格納されている必要があります。「多重ホストデータ」を参照してください。
アプリケーションがデータの格納先を示すのに固定されたパス名を使用している場合、アプリケーションのソースコードを変更しなくても、そのパスをクラスタファイルシステム内の場所を指すシンボリックリンクに変更できる場合もあります。詳細については、「多重ホストデータを配置するためのシンボリックリンクの使用」を参照してください。
アプリケーションのバイナリとライブラリは、ローカルの各ノードまたはクラスタファイルシステムのどちらにも格納できます。クラスタファイルシステム上に格納する利点は、1 箇所にインストールするだけで済む点です。欠点としては、アプリケーションが RGM の制御下で動作している間はバイナリファイルが使用中になるので、ローリングアップグレードの問題が生じることが挙げられます。
初回の照会がタイムアウトした場合、クライアントは自動的に照会を再試行できる必要があります。アプリケーションとプロトコルがすでに単一サーバーのクラッシュと再起動に対応できている場合、関連するリソースグループのフェイルオーバーまたはスイッチオーバーにも対応できる必要があります。詳細については、「クライアントの再試行」を参照してください。
アプリケーションは、クラスタファイルシステム内で UNIX ドメインソケットまたは名前付きパイプを使用してはなりません。
さらに、スケーラブルサービスは、次の要件も満たしている必要があります。
アプリケーションは、複数のインスタンスを実行でき、すべてのインスタンスがクラスタファイルシステム内の同じアプリケーションデータを処理できる必要があります。
アプリケーションは、複数のノードからの同時アクセスに対してデータの整合性を保証する必要があります。
アプリケーションは、クラスタファイルシステムのように、広域的に使用可能な機構を備えたロック機能を実装している必要があります。
スケーラブルサービスの場合、アプリケーションの特性により負荷均衡ポリシーが決定されます。たとえば、負荷均衡ポリシー LB_WEIGHTED は、任意のインスタンスがクライアントの要求に応答できるポリシーですが、クライアント接続にサーバー上のメモリー内キャッシュを使用するアプリケーションには適用されません。この場合、特定のクライアントのトラフィックをアプリケーションの 1 つのインスタンスに制限する負荷均衡ポリシーを指定する必要があります。負荷均衡ポリシー LB_STICKY と LB_STICKY_WILD は、クライアントからのすべての要求を同じアプリケーションインスタンスに繰り返して送信します。この場合、アプリケーションはメモリー内キャッシュを使用できます。異なるクライアントから複数の要求が送信された場合、RGM はサービスの複数のインスタンスに要求を分配します。スケーラブルデータサービスに対応した負荷均衡ポリシーを設定する方法については、「スケーラブルリソースの実装」を参照してください。
Sun Cluster 開発者サポートパッケージ (SUNWscdev) は、データサービスメソッドのコーディング用に 2 種類のインタフェースセットを提供します。
RMAPI (Resource Management API (リソース管理 API)) - 低レベルのルーチンセット (libscha.so ライブラリとして実装されている)
DSDL (Data Service Development Library (データサービス開発ライブラリ)) - RMAPI の機能をカプセル化および拡張する、より高いレベルの関数セット (libdsdev.so ライブラリとして実装されている)
また、Sun Cluster 開発者サポートパッケージには、データサービスの作成を自動化するツールである SunPlex Agent Builder も含まれています。
C 言語または Korn シェル (Ksh) のどちらでコーディングするかを決定します。DSDL は C 言語用のインタフェース以外は提供しないため、Ksh でコーディングする場合は DSDL を使用できません。
Agent Builder を使用すると、必要な情報を入力するだけで、データサービスを生成できます。これには、ソースコードと実行可能コード、RTR ファイル、およびパッケージが含まれます。
生成されたデータサービスをカスタマイズする必要がある場合は、生成されたソースファイルに DSDL コードを追加できます。Agent Builder は、ソースファイル内において独自のコードを追加できる場所にコメント文を埋め込みます。
ターゲットアプリケーションをサポートするために、さらにコードをカスタマイズする必要がある場合は、既存のソースコードに RMAPI 関数を追加できます。
実際には、データサービスを作成する方法はいくつもあります。実際には、データサービスを作成する方法はいくつもあります。たとえば、Agent Builder によって生成されたコード内の特定の場所に独自のコードを追加する代わりに、生成されたメソッドの 1 つや生成された監視プログラムを DSDL や RMAPI 関数を使って最初から作成したプログラムで完全に置き換えることもできます。しかし、使用する方法に関わらず、ほとんどの場合、Agent Builder を使用して開発作業を開始することが重要です。次に、その理由を示します。
Agent Builder が生成するコードは本質的に汎用であり、数多くのデータサービスでテストされています。
Agent Builder は、RTR ファイル、make ファイル、リソースのパッケージなど、データサービス用のサポートファイルを作成します。データサービスのコードをまったく使用しない場合でも、このようなサポートファイルを使用することによって、かなりの作業を節約できます。
生成されたコードは変更できます。
RMAPI は C 言語用の関数セットとスクリプト用のコマンドセットを提供しますが、DSDL は C 言語用の関数インタフェースだけしか提供しません。つまり、DSDL は ksh コマンドを提供しないので、Agent Builder で ksh 出力を指定した場合、生成されるソースコードは RMAPI を呼び出します。
データサービスの開発を始める前に、Sun Cluster 開発パッケージ (SUNWscdev) をインストールして、Sun Cluster のヘッダーファイルやライブラリファイルにアクセスできるようにする必要があります。このパッケージがすでにすべてのクラスタノード上にインストールされている場合でも、通常は、クラスタノード上にはない独立した (つまり、クラスタノード以外の) 開発マシンで開発を行います。このような場合、pkgadd(1M) を使用して、SUNWscdev パッケージを開発マシンにインストールする必要があります。
コードをコンパイルおよびリンクするとき、ヘッダーファイルとライブラリファイルを識別するオプションを設定する必要があります。(クラスタノード以外の) 開発マシンで開発が終了すると、完成したデータサービスをクラスタに転送して、実行および検証できます。
必ず、開発バージョンの Solaris 8 (またはそれ以降) を使用してください。
この節では、次の手順を使用します。
Sun Cluster 開発パッケージ (SUNWscdev) をインストールして、適切なコンパイラオプションとリンカーオプションを設定します。
データサービスをクラスタに転送します。
この手順では、SUNWscdev パッケージをインストールして、コンパイラオプションとリンカーオプションをデータサービス開発用に設定する方法について説明します。
CD-ROM のあるディレクトリに移動します。
cd appropriate_CD-ROM_directory |
SUNWscdev パッケージを現在のディレクトリにインストールします。
pkgadd -d . SUNWscdev |
makefile に、データサービスのコードが使用する include ファイルとライブラリファイルを示すコンパイラオプションとリンカーオプションを指定します。
-I オプションは、Sun Cluster のヘッダファイルを指定します。-L オプションは、開発システム上にあるコンパイル時ライブラリの検索パスを指定します。
# Makefile for sample data service ... -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 テンプレート バージョン 1.0 # smpl 用の登録情報とリソース # # ▼注: キーワードには大文字と小文字の区別がないため、 # 大文字小文字の使い方は自由である。 # 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 にはこの制限はありません)。一方、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- これらのプロパティは Agent Builder によって自動的に宣言されますが、フェイルオーバーリソースタイプでは使用されません。
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 = 30; 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(1M) コマンド、グラフィカル管理コマンド、またはグラフィカル管理インタフェースを使用して、ある種のリソースプロパティを設定することができます。ただし、scrgadm はクラスタの再構築時に (つまり、RGM がメソッドを呼び出した時点で) エラー終了するため、どのようなコールバックメソッドからも scrgadm を呼び出さないようにします。
一般に、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 (成功) のエラー状態で終了し、ローカルノード上でリソースとそのモニターのすべての活動を正常に停止するべきです。
この節では、START メソッドと STOP メソッドを使用するか、または、PRENET_START メソッドと POSTNET_STOP メソッドを使用するかを決定するときのいくつかの注意事項について説明します。どちらのメソッドが適切かを決定するには、クライアントおよびデータサービスのクライアントサーバー型ネットワークプロトコルについて十分に理解している必要があります。
ネットワークアドレスリソースを使用するサービスでは、論理ホスト名のアドレス構成から始まる順番で、起動手順または停止手順を行う必要があります。コールバックメソッドの PRENET_START と POSTNET_STOP を使用してリソースタイプを実装すると、同じリソースグループ内のネットワークアドレスが「起動」に構成される前、または「停止」に構成された後に、特別な起動アクションまたは停止アクションを行います。
RGM は、データサービスの PRENET_START メソッドを呼び出す前に、ネットワークアドレスを取り付ける (plumb、ただし起動には構成しない) メソッドを呼び出します。RGM は、データサービスの POSTNET_STOP メソッドを呼び出した後に、ネットワークアドレスを取り外す (unplumb) メソッドを呼び出します。RGM がリソースグループをオンラインにするときは、次のような順番になります。
ネットワークアドレスを取り付けます。
データサービスの PRENET_START メソッドを呼び出します (もしあれば)。
ネットワークアドレスを「起動」に構成します。
データサービスの START メソッドを呼び出します (もしあれば)。
RGM がリソースグループをオフラインにするときは、逆の順番になります。
データサービスの STOP メソッドを呼び出します (もしあれば)。
ネットワークアドレスを「停止」に構成します。
データサービスの POSTNET_STOP メソッドを呼び出します (もしあれば)。
ネットワークアドレスを取り外します。
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 メソッドを使用するか、または両方を使用するかを決定するには、サーバーとクライアントの要件と動作を考慮に入れる必要があります。
RGM は、3 つの任意のメソッド INIT、FINI、BOOT を使用し、リソース上で初期化と終了コードを実行できます。リソースを管理下に置くとき (リソースが属しているリソースグループを管理していない状態から管理している状態に切り替えるとき、または、すでに管理されているリソースグループでリソースを作成するとき)、RGM は INIT メソッドを呼び出して、一度だけリソースの初期化を実行します。
リソースを管理下から外すとき (リソースが属しているリソースグループを管理していない状態に切り替えるとき、または、すでに管理されているリソースグループからリソースを削除するとき)、RGM は FINI を呼び出して、リソースをクリーンアップします。クリーンアップは呼び出し回数に依存しない必要があります。つまり、すでにクリーンアップが行われている場合、FINI は 0 (成功) で終了する必要があります。
RGM は、新たにクラスタに結合した、つまり、起動または再起動されたノード上で、BOOT メソッドを呼び出します。
BOOT メソッドは、通常、INIT と同じ初期化を実行します。この初期化は呼び出し回数に依存しない必要があります。つまり、ローカルノード上ですでにリソースが初期化されている場合、BOOT と INIT は 0 (成功) で終了する必要があります。
通常、モニターは、リソース上で定期的に障害検証を実行し、検証したリソースが正しく動作しているかどうかを検出するように実装します。障害検証が失敗した場合、モニターは、ローカルで再起動するか、RMAPI 関数 scha_control (3HA) または DSDL 関数 scds_fm_action(3HA) を呼び出して、影響を受けるリソースグループのフェイルオーバーを要求できます。
また、リソースの性能を監視して、性能を調節または報告できます。可能であれば、リソースタイプに固有な障害モニターを作成することを推奨します。このような障害モニターを作成しなくても、リソースタイプは Sun Cluster により基本的なクラスタの監視が行われます。Sun Cluster は、ホストハードウェアの障害、ホストのオペレーティングシステムの全体的な障害、およびパブリックネットワーク上で通信できるホストの障害を検出します。
RGM は、 リソースモニターを直接呼び出すことはありませんが、リソース用のモニターを自動的に起動する準備を整えます。リソースをオフラインにするとき、RGM は、リソース自体を停止する前に、MONITOR_STOP メソッドを呼び出して、ローカルノード上でリソースのモニターを停止します。リソースをオンラインにするとき、RGM は、リソース自体を起動した後に、MONITOR_START メソッドを呼び出します。
RMAPI の scha_control(3HA) 関数と (scds_fm_action を呼び出す) DSDL の scha_control(3HA) 関数を使用すると、リソースモニターは異なるノードへのリソースグループのフェイルオーバーを要求できます。MONITOR_CHECK が定義されている場合、scha_control は妥当性検査の 1 つとして MONITOR_CHECK を呼び出して、リソースが属するリソースグループをマスターするのに要求されたノードが十分信頼できるかどうかを判断します。MONITOR_CHECK が「このノードは信頼できない」と報告した場合、あるいは、メソッドがタイムアウトした場合、RGM はフェイルオーバー要求に適する別のノードを探します。すべてのノードで MONITOR_CHECK が失敗した場合、フェイルオーバーは取り消されます。
リソースモニターは、モニターから見たリソースの状態を反映するように Status と Status_msg プロパティを設定します。これらのプロパティを設定するには、RMAPI の scha_resource_setstatus(1HA) コマンドまたは同 (3HA) 関数、あるいは DSDL の scds_fm_action(3HA) 関数を使用します。
Status と Status_msg はリソースモニターに固有な使用方法ですが、これらのプロパティは任意のプログラムで設定できます。
RMAPI を使って障害モニターを実装する例については、75 ページの「障害モニターの定義」を参照してください。DSDL を使って障害モニターを実装する例については、111 ページの「SUNW.xfnts 障害モニター」を参照してください。Sun が提供するデータサービスに組み込まれている障害モニターについては、『 Sun Cluster 3.0 12/01 データサービスのインストールと構成』を参照してください。
状態メッセージを他のクラスタメッセージと同じログファイルに記録する場合は、scha_cluster_getlogfacility 関数を使用して、クラスタメッセージを記録するために使用されている機能番号を取得します。
この機能番号を通常の Solaris syslog 関数で使用して、状態メッセージをクラスタログに書き込みます。または、scha_cluster_get(1HA)(3HA) 汎用インタフェースからでも、クラスタログ機能情報にアクセスできます。
Resource Management API と DSDL には、リソースモニターやリソース制御コールバックを実装するためのプロセス管理機能が備わっています。RMAPI は次の機能を定義します (これらのコマンドとプログラムの詳細については、各マニュアルページを参照してください)。
プロセス監視機能 pmfadm(1M) と rpc.pmfd(1M) - プロセス監視機能 (PMF) は、プロセスとその子孫プロセスを監視し、停止した場合は再起動する方法を提供します。この機能は、pmfadm(1M) コマンド (監視するプロセスを起動および制御する) と rpc.pmfd(1M) デーモンからなります。
halockrun(1M) - ファイルロックを保持したまま、子プログラムを実行するプログラム。このコマンドはシェルスクリプトで使用すると便利です。
hatimerun(1M) - タイムアウト制御下で、子プログラムを実行するプログラム。このコマンドはシェルスクリプトで使用すると便利です。
DSDL は、hatimerun 機能を実装するための scds_hatimerun(3HA) 関数を提供します。
DSDL は、PMF 機能を実装するための scds_pmf_*(3HA) 関数セットを提供します。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 iPlanet Web Server や HA-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(1M) コマンドと SunPlex Manager は、スケーラブルサービスに必要なリソースとグループを自動的に設定する機能を提供します。
Load_balancing_policy - リソースの負荷均衡ポリシーを指定します。このポリシーは RTR ファイルに明示的に設定しても、デフォルトの LB_WEIGHTED を使用してもかまいません。どちらの場合でも、クラスタ管理者はリソースを作成するときに値を変更できます (RTR ファイルで Load_balancing_policy を 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 3.0 12/01 の概念』を参照してください。
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 操作、または、少なくとも効率的な読み取り専用操作 (状態操作など) をサポートする必要があります。
この節では、高可用性環境における実装を検証する方法について説明します。この検証は一例であり、完全ではないことに注意してください。実際に稼働させるマシンに影響を与えないように、検証時は、検証用の 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 データベースが利用できない間、リソースグループが複数のノード間でやりとりを無限に繰り返す可能性があります。