test

Sun Cluster 2.2 API 開発ガイド

第 3 章 HA データサービスの作成と検証についての注意事項

この章では、新しいHA データサービスの作成と検証についての注意事項を説明します。

概要

この章では、次の方法について説明します。

使用するメソッドの決定

この節では、start_net、stop_net、abort_net のメソッドを使用するときの注意事項を、start、stop、abort のメソッドと比較しながら説明します。

start_net、stop_net、abort_net を呼び出した時点で論理ネットワークアドレスが使用可能になるように構成されているため、一般的に、データサービスを開始、停止、または中止するには、これらのメソッド を使用する方が簡単です。

データサービスを起動、停止、中止するには、データサービスの管理ユーティリティやライブラリを何度も呼び出す必要があります。データサービスの管理ユーティリティやライブラリの中には、クライアントサーバーネットワークインタフェースを使用して管理を行うものもあります。つまり、管理ユーティリティはサーバーデーモンを呼び出すため、管理ユーティリティやライブラリを使用するには、論理ネットワークアドレスが使用可能な状態である必要があります。

まず、再起動、テイクオーバー、スイッチオーバーの後でネットワークインタフェースまたはデータサービスのどちらが先にオンラインになるのかによって、クライアントソフトウェアの応答が異なるかどうかを考えます。メソッドは、何回も再試行を行い、続けるものを使用します。たとえば、最小限の再試行だけを行い、すぐにデータサービスポートが利用できないと判断するようなクライアント実装では、ネットワークインタフェースが構成される前にデータサービスが起動していなければなりません。このような状況では、start_net メソッドよりも、start メソッドを使用します。

stop メソッドまたは abort メソッドを使用する場合、論理ネットワークアドレスが休止に構成された時点では、データサービスはまだ使用可能のままです。つまり、stop メソッドと abort メソッドが呼び出されるのは、論理ネットワークアドレスが休止に構成された後だけです。

したがって、ネットワーク上のクライアントは常にデータサービスの TCP または UDP のサービスポート (つまり、その RPC プログラム番号) を利用できるという状況が生まれます (ただし、論理ホストネットワークアドレスも応答していない場合を除く)。この状況が重要になるのは、TCP または UDP のサービスポート (つまり、RPC プログラム番号) が応答していない場合で、論理ホストのネットワークアドレスが応答しているときに、それを検出したクライアントコードの動作が著しく異なる場合だけです。たとえば、このような状況では、クライアントは早くから再試行をやめてしまう可能性があります。つまり、「ICMP ポートが到達不能」や「プログラムが登録されていない」などの明示的なエラーパケットをサーバーホストから受信すると、クライアントコードは再試行を行わず、異なるコードパスを選択します。

クライアント実装がこのような状況に依存するかどうかを判断するには、クライアントとデータサービスのクライアントサーバーネットワークプロトコルを熟知していなければなりません。

キープアライブの使用

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

注 -

他にも、キープアライブ機構を持つ接続指向の製品があります。

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

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

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

TCP キープアライブ機構は必ずしもすべての場合に完全ではないため、クライアントアプリケーションは、可能であれば、TCP キープアライブ機構に加えて、独自の定期的なキープアライブをアプリケーションレベルで行うべきです。通常、アプリケーションレベルのキープアライブでは、クライアントサーバープロトコルがヌル操作、あるいは少なくとも効果的な読み取り専用操作 (状態操作など) をサポートすることが必要です。

HA データサービスの検証

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

論理ホストが物理ホスト間を移動するあらゆる場面において、HA データサービスが適切に動作するかどうかを検証します。たとえば、システムに障害が発生したときや、haswitch(1M) コマンドや scadm(1M) stopnode コマンドを使用したときなどです。このような事態が発生した後でも、クライアントマシンがサービスを受け続けることができるかどうかを検証します。

メソッドの呼び出し回数への非依存性を検証します。この検証では、論理ホストのマニュアルモードを有効にし、物理ホストには論理ホストの haswitch(1M) を行わずに、1 つの物理ホストを繰り返し中止および再接続します。ホストを中止するときは、再接続したホストでクラスタ再構成が完了するまで待ちます。ホストを再接続してクラスタを再接続すると、クラスタ再構成が行われます。しかし、再構成中には、論理ホストは物理ホスト間を移動しないことに注意してください。

呼び出し回数への非依存性を検証するもう一つの方法は、各メソッドを一時的に、元のメソッドを 2 回呼び出す短いシェルスクリプトに変更します。

データサービスが abort メソッドと abort_net メソッドを適切に実装しているかどうかを検証するには、1 つの物理ホストを Sun Cluster から見ると異常であるが、完全には障害が発生していない状態にします。すると、Sun Cluster は最終手段のパスを使用し、この物理ホストをシステムから取り外そうとします。具体的には、まず、この物理ホストにすべての論理ホストの switch(1M) を実行します。次に、ホストが異常に見えるように、このホストに接続されているすべてのパブリックネットワーク接続のプラグを外します。すると、Sun Cluster ネットワーク障害監視機能に問題があったことが認識され、最終手段のパスを使用し、この物理ホストをクラスタから取り外そうとします。

データサービス間の依存性の調整

あるクライアントサーバーデータサービスが、クライアントからの要求を満たすために、別のクライアントサーバーデータサービスに要求を行うことがあります。このように、データサービス A が自分のサービスを提供するために、データサービス B にそのサービスを提供してもらう場合、データサービス A はデータサービス B に依存していると言います。

Sun Cluster で依存性のあるデータサービスを実現するには、hareg(1M) プログラムを -d スイッチ付きで呼び出します。依存性は、Sun Cluster がデータサービスを開始および停止する順番に影響を与えます。詳細は、hareg(1M) のマニュアルページを参照してください。

まず、データサービスに依存性があるかどうか、および、hareg(1M) に適切な -d スイッチが提供されているかどうかを調べます。Sun Cluster は提供されている -d スイッチが適切であるかどうかを検査しません。

次に、-d スイッチを使用するか、あるいは、-d スイッチを使用せずに、HA データサービスの独自のコード内で他のデータサービスの利用可能性についてポーリングするかどうかを決定します。他のデータサービスの start メソッドが非同期である可能性があるため (つまり、データサービスを起動するが、データサービスが実際にクライアントに利用できるようになるまで待たずに、start メソッドまたは start_net メソッドから戻ってしまう可能性があるため)、いずれにせよ、ポーリングが必要な場合もあります。データベースの回復時間は時間がかかることが多いため、通常、データベースサービスはこの動作を示します。

別のバックエンドデータサービスを使用する依存性のあるデータサービス

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

Sun Cluster 環境では、HA-DBMS for ORACLE7 を使用すると、バックエンド Oracle データベースを高可用性にすることができます。次に、アポイントメントカレンダーデーモンを開始または停止する簡単なメソッドを作成します。すると、このアポイントメントカレンダーデータサービスを、別の Sun Cluster データサービス (HA-DBMS for ORACLE7) に依存するデータサービスとして Sun Cluster に登録できます。この依存性を指定するには、hareg(1M) に -d オプションを指定します。

Oracle 用の start メソッドはデータベース回復を起動するだけで、回復が完了するのを待たない可能性があります。したがって、このカレンダーデータサービスデーモンは、一度起動すると、Oracle データベースが利用可能になるまで待つようにポーリングしなければなりません。