test

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

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

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

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

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

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

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

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

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

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

HA データサービスの検証

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

クラスタ内のすべてのノード上ではなく、単一ノード上の非大域ゾーン内で、HA データサービスを検証します。データサービスが非大域ゾーン内で想定どおりに動作していると判断した場合は、次にクラスタ全体で検証を実行できます。ノード上の非大域ゾーン内で動作している 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 データベースが利用できない間、タイムアウトまたは非ゼロ終了状態により、リソースグループが複数のノードまたはゾーン間でやりとりを無限に繰り返す可能性があります。