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

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

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

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

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

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

注 -

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

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

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

開発環境を設定する方法

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

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

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

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 がリソースグループをオンラインにするときは、次のような順番になります。

ネットワークアドレスを取り付けます。
データサービスの 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 メソッドを使用するか、または両方を使用するかを決定するには、サーバーとクライアントの要件と動作を考慮に入れる必要があります。

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

サーバー側で 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 データベースが利用できない間、リソースグループが複数のノード間でやりとりを無限に繰り返す可能性があります。