Sun Cluster の障害追跡

この付録では、Sun Cluster の障害追跡について説明します。

• 「障害追跡の概要」

• 「パブリックネットワークモニター (PNM)」

• 「Sun Cluster の障害検証」

• 「データサービス固有の障害検証」

この節では、Sun Cluster の障害検証の概要を説明します。この障害検証は、主に次の 3 つの方法によって行われます。

• ハートビート機構

• ネットワークの障害監視

• 特定のデータサービスの障害監視

障害監視は、問題の原因が正常なノードではなく障害ノードにあることを確認するために、妥当性検査を行います。

この付録に示された情報の一部はこの Sun Cluster リリース固有のもので、製品のバージョンアップに伴い変更される場合があります。各種の障害検証に示された時間予測は概算です。この付録は、Sun Cluster 内部についてのプログラムロジックやプログラミングインタフェースについて説明するためのものではありません。

障害追跡の概要

Sun Cluster の基本的なアーキテクチャの説明で述べたように、1 台のサーバーがダウンした場合、ほかのサーバーがテイクオーバーします。ここでは、「あるサーバーがダウンしたことを別のサーバーはどのようにして認識するのか」を説明します。

Sun Cluster は、3 つの障害検証方法を使用します。

• ハートビートと SMA リンクの監視 - これらのモニターは、プライベートリンク上で動作します。Ethernet の場合、2 つのモニター、SMA リンクモニターとクラスタメンバーシップモニターが存在します。SCI では、3 つのモニター、SMA リンクモニター、クラスタメンバーシップモニター、低レベル SCI ハートビートモニターが存在します。

• ネットワークの障害監視 - サーバーのパブリックネットワーク接続がすべて監視されます。ハードウェアまたはソフトウェア上の問題のためにパブリックネットワークを介してサーバーが通信できない場合、サーバーセット内の別のサーバーがテイクオーバーします。

• データサービス固有の障害検証 - 各 Sun Cluster データサービスは、そのデータサービス固有の障害検証を行います。この方法は、マシンとオペレーティングシステムが動作しているかという低レベルの確認だけでなく、データサービスが有用な作業を行なっているかという問題を対象とします。

2 つ目と 3 つ目の方法では、1 台のサーバーがほかのサーバーの応答を検証します。明らかな問題が検出されると、検証側サーバーは、ほかのサーバーからのテイクオーバーを強行する前に、それ自体の妥当性検査を多数行います。これらの妥当性検査では、ほかのサーバーから応答がない実際の原因が検証側サーバーにないことを確認します。これらの妥当性検査は、Sun Cluster のベースフレームワークの一部であるライブラリサブルーチン hactl(1M) によって提供されます。そのため、データサービス固有の障害検証コードは、検証側サーバーの妥当性検査を行う場合 hactl(1M) を呼び出すだけですみます。詳細は、hactl(1M) のマニュアルページを参照してください。

ハートビート機構: クラスタメンバーシップモニター

Sun Cluster は、ハートビート機構を使用します。ハートビート処理は、メモリーに固定される優先度の高いリアルタイムプロセスによって処理されます。つまり、ハートビート処理は、ページングに制約されません。この処理は、クラスタメンバーシップモニターと呼ばれます。クラスタメンバーシップモニターは、ps(1) による出力には clustd という名前で示されます。

各サーバーは、両方のプライベートリンクを介して約 2 秒に 1 度、稼動していること示すメッセージ (ハートビート) を送信します。そして、両方のプライベートリンク上で、ほかのサーバーからのハートビートメッセージを受信します。どちらかのプライベートリンク上でハートビートを受信していることは、ほかのサーバーの稼動を示す十分な証拠となります。一定の時間 (約 12 秒) ほかのサーバーからのハートビートメッセージがない場合、サーバーはそのサーバーがダウンしていると判断します。

障害の検出という視点から見ると、クラスタメンバーシップモニターのハートビート機構は防御の第一線に当たります。ハートビートが受信されないと、ハードウェアの障害とオペレーティングシステムの障害がすぐに検出されます。ハートビート機構は、すべての通信バッファーの漏出などのような顕著なオペレーティングシステム上の問題を検出することもあります。ハートビート機構は、Sun Cluster の最も高速な障害検証方法でもあります。クラスタメンバーシップモニターはリアルタイムに優先されて動作するとともに、メモリー内に固定されるため、比較的短時間のハートビートの欠如は認められます。逆に、ほかの障害検証方法では、サーバーの速度が単に非常に遅いためにそのサーバーがダウンしていると Sun Cluster で判断されることを避けなければなりません。それらの方法では、数分という比較的長時間のタイムアウトが使用され、複数の長時間タイムアウトが発生しないと Sun Cluster がテイクオーバーを行わないこともあります。

クラスタメンバーシップモニターがリアルタイムに優先されて動作し、かつメモリー内に固定されるという事実は、そのサーバーがデータサービスレベルで有用な作業を行なっていない場合でもメンバーシップモニターが活動する可能性があるという矛盾を生みます。「データサービス固有の障害検証」で説明しているように、データサービス固有の障害監視がこの問題を解決します。

検証側ノードの妥当性検査

ネットワーク障害の検証とデータサービス固有の障害検証では、各ノードは別のノードの応答を検証する必要があります。テイクオーバーを行う前に、検証側ノードは自身の基本的な妥当性検査を多数行います。これらの検査は、障害の原因が実際に検証側ノードにないことを確認するとともに、障害があると思われるサーバーからのテイクオーバーによって状況が実際に改善されるかどうかを確認します。これらの妥当性検査が行われないと、誤ったテイクオーバーが発生する可能性があります。つまり、欠陥のあるノードに、ほかのノードが応答しないことによって、その欠陥のあるノードが誤って問題のないそのサーバーをテイクオーバーすることがあります。

検証側ノードは、別のノードをテイクオーバーする前に、自身に対して次の妥当性検査を行います。

• 検証側ノードは、「パブリックネットワークモニター (PNM)」で説明しているように、パブリックネットワークを使用する自身の能力を検査します。

• 検証側ノードは、自身の HA データサービスが応答しているかも検査します。この場合、検証側ノードがすでに実行している HA データサービスはすべて検査されます。応答しないものがある場合、「検証側ノードが自身のサービスを実行できなければ、ほかのノードのサービスを実行してもよい結果は得られない」という前提によって、テイクオーバーは防止されます。また、検証側ノード自体の HA データサービスが応答に失敗した場合、検証側ノードに根本的な問題があるためにほかのノードの検証が失敗している可能性もあります。この現象を示す重要な例を挙げると、Sun Cluster HA for NFS では、ほかのノード上のファイルをロックするためには、検証側ノード自体の lockd と statd デーモンが動作していなければなりません。lockd と statd デーモンの応答検査により、検証側ノードはそれ自体のデーモンの応答失敗がほかのノードを応答していないように見せることを防止します。

パブリックネットワークモニター (PNM)

PNM コンポーネントには、主な機能が 2 つあります。

• ノード上の構成済みアダプタの状態を監視し、アダプタまたはネットワークの一般的な障害を報告する

• 主アダプタに障害が発生した場合に、ノード上のほかのバックアップアダプタに透過的にフェイルオーバーする

PNM は、ノード内のパブリックネットワークインタフェースセットについてのネットワーク統計を周期的に収集するデーモン (pnmd) として実装されています。この統計収集の結果に異常が認められた場合、pnmd は次の 3 つの場合のどれに該当するかを調べます。

• ネットワークが静止状態である

• ネットワークがダウンしている

• ネットワークインタフェースがダウンしている

続いて PNM は、同じサブネット上で対等デーモンに対して ping を実行します。応答がない場合、PNM は同じサブネット上でブロードキャスト ping を行います。続いて PNM は検索の結果を CCD に格納し、ローカル結果を CCD 内のほかのノードの結果 (これも CCD に格納される) と比較します。この比較は、ネットワークがダウンしているか、それともネットワークインタフェースに障害があるかを確認するために行われます。ネットワークインタフェースに障害があり、バックアップアダプタが構成されていることを検出すると、PNM はネットワークアダプタのフェイルオーバーを実行します。

PNM 監視の結果は、さまざまなエンティティで使用されます。PNM のネットワークアダプタフェイルオーバーコンポーネントは、監視結果を使用してアダプタフェイルオーバーが有益かどうかを判断します。たとえば、ネットワークに障害が発生している場合、アダプタフェイルオーバーは行われません。Sun Cluster HA データサービスに対応した障害モニターと、API 呼び出し hactl は、PNM 機能を使用してデータサービス障害の原因を診断します。PNM が返す情報は、データサービスを移動させるかどうかの決定、および移動後のデータサービスの位置の決定に使用されます。

アダプタ障害の検出時に PNM 機能によって書き込まれる syslog メッセージは Sun Cluster Manager によって読み込まれ、グラフィックアイコンにより GUI を介して表示されます。

PNM ユーティリティをコマンド行で実行し、ネットワークコンポーネントの状態を確認することもできます。詳細は、pnmset(1M)、pnmstat(1M)、pnmptor(1M)、pnmrtop(1M)、pnmd(1M) のマニュアルページを参照してください。

Sun Cluster の障害検証

PNM は、パブリックネットワークの状態を監視し、必要に応じてバックアップ接続に切り替えます。しかし、パブリックネットワークアクセス全体が停止した場合、PNM はデータサービスも論理ホストフェイルオーバーも提供しません。このような状況が発生した場合、PNM はアクセスの停止を報告しますが、バックアップノード間の切り替えに対処するかどうかは外部の障害検証次第です。

ボリュームマネージャとして SSVM を使用している場合、SSVM フレームワークは、論理ホストごとに定義されたネットワークアダプタフェイルオーバー (NAFO) の各バックアップグループを監視し、次の条件のどちらかが満たされる場合にバックアップノードに対するスイッチオーバーを開始する必要があります。

• パブリックネットワークが完全に停止し (すべての NAFO バックアップグループが使用できない)、バックアップノード内の 1 つ以上の NAFO グループが使用できる。

• パブリックネットワークが部分的に停止し (論理ホストに複数のサブネットが定義されており、1 つ以上の NAFO バックアップグループがまだアクティブである)、バックアップの数を超える有効でアクティブな NAFO バックアップグループがバックアップノードに存在する。

これらの条件のどちらも満たされない場合、Sun Cluster はスイッチオーバーを行いません。

ボリュームマネージャが Solstice DiskSuite の場合、パブリックネットワークが停止すると、切断されたノードはアボートし、そのノードが制御している論理ホストはバックアップノードに移動します。

Sun Cluster フレームワークは、構成に論理ホストが含まれている場合と、データサービスが「有効」状態で、かつその論理ホストに登録されている場合だけパブリックネットワークを監視します。監視されるのは、論理ホストに使用されている NAFO バックアップグループだけです。

データサービス固有の障害検証

データサービス固有の障害検証は、サーバーノードとオペレーティングシステムが動作している場合でも、データサービスレベルでの有用な作業が発生していないという混乱した状態に、ソフトウェアやハードウェアが置かれている可能性がある場合に行われます。ノードまたはオペレーティングシステムの完全な停止は、総合的なアーキテクチャにおいて、クラスタメンバーシップモニターのハートビート機構によって検出されます。しかし、データサービスが有用な作業を行なっていない場合でも、ハードビート機構が実行を継続すると判断する程度に、ノードが十分動作していることがあります。

逆に、データサービス固有の障害検証は、ノードがクラッシュしたか、クラスタハートビートメッセージの送信を停止した状態を検出する必要がありません。クラスタメンバーシップモニターはこのような状態を検出し、かつデータサービスの障害検証自体にはこれらの状態を処理するロジックはないと仮定されます。

データサービスの障害検証は、データサービスのクライアントのように動作します。マシン上で行われる障害検証は、そのマシンがエクスポートするデータサービスを監視するとともに、(さらに重要なことに) ほかのサーバーがエクスポートするデータサービスも監視します。欠陥のあるサーバーがそれ自体の欠陥を正しく検出する可能性は低いため、各サーバーは自身の監視に加えてほかのノードの監視も行います。

データサービス固有の障害検証は、クライアントのように動作するほかに、データサービスの統計情報を使用して有用な作業が行われているかどうかを検査する場合もあります。また、特定のデータサービスにきわめて重要な特定のプロセスが存在するかどうかを検査する場合もあります。

一般に、この障害検証は、1 台のサーバーにほかのサーバーをテイクオーバーさせることによって、サービスの欠如に応答します。場合によっては、テイクオーバーを行う前にまず本来のマシン上のデータサービスの再起動を試みます。短時間で再起動が何度も発生する場合は、マシンに重大な問題があることを意味します。この場合、ほかのローカル再起動が試されることなく、ただちに別のサーバーによるテイクオーバーが行われます。

Sun Cluster HA for NFS の障害検証

検証側サーバーは、ほかのサーバーの NFS サービスに対して、2 種類の周期的な検証を行います。

1. 検証側サーバーは、NFS サービスを提供する必要がある、対象ノード上のすべてのデーモンプロセス (rpcbind、mountd、nfsd、lockd、statd) に NULL RPC を送信します。

2. 検証側サーバーは、ほかのノードから NFS ファイルシステムのマウントを試み、続いてそのファイルシステムに対してファイルの読み書きを試すことによって、終端間テストを行います。この終端間テストは、そのノードが現在共有しているファイルシステムごとに行われます。マウントは手間がかかるため、ほかの検証よりも行われる頻度は少なくなります。

これらの検証のどれかが失敗すると、検証側ノードはサービスを行なっているノードからのテイクオーバーを検討します。しかし、次のような理由によりテイクオーバーをただちに実施しないこともあります。

• ローカル再起動の停止期間 - テイクオーバーを行う前に、検証側ノードは次の目的のために短時間待機します。

  • 障害ノードに、それ自体の欠陥に気付き、そのデーモンをローカルに再起動することによって問題を解決する機会を与える

  • 障害ノードに、ビジー状態から抜ける機会を与える (単に負荷が過剰になっている場合)

  待機後、検証側ノードは検証を再度試み、障害が続くかぎりテイクオーバーを検討し続けます。一般に、速度の遅いサーバーでは、基本的な検証が完全に 2 度タイムアウトしてからテイクオーバーが行われます。

• 複数のパブリックネットワーク - ほかのノードが複数のパブリックネットワーク上に存在する場合、検証側ノードはそれらのネットワークの 2 つ以上で検証を試みます。

• ロック - 一部のバックアップユーティリティは、バックアップが未変更のファイルシステムのスナップショットがとれるように、ファイルシステム上の各種の更新をロックアウトする lockfs(1M) 機能を利用します。NFS では lockfs(1M) はファイルシステムを使用不可能のように見せます (NFS クライアントに NFS server not responding と表示される)。テイクオーバーを行う前に、検証側ノードはほかのノードの照会を行い、ファイルシステムが lockfs 状態かどうかを確認し、この状態であればテイクオーバーを行いません。これは、lockfs が、バックアップを行うための通常の意図された管理作業の一部であるためです。バックアップユーティリティのすべてが lockfs を使用するわけではありません。NFS サーバーの割り込み不可を認めるものもあります。

• デーモン - lockd と statd が応答しないことは、テイクオーバーの原因にはなりません。lockd と statd デーモンは、連携して NFS ファイルのネットワークロックを提供します。これらのデーモンが応答しない場合、状況が syslog に記録されるだけでテイクオーバーは発生しません。lockd と statd は、それらの通常の作業においては、ダウンまたはパーティション分割されたクライアントが長時間 lockd と statd をハングできるように、クライアントマシンに対して RPC を実行する必要があります。このため、欠陥のあるクライアントは、サーバー上の lockd と statd に問題が起きているかのように見せる場合があります。この場合、検証側サーバーによるテイクオーバーが発生することがあれば、検証側サーバーは欠陥クライアントによって同様にハングさせられます。現在のモデルでは、欠陥のあるクライアントが不正なテイクオーバーを起こすことはありません。

これらの Sun Cluster HA for NFS 固有のテストをパスした後、テイクオーバーを行うべきかどうかを検討するプロセスは、hactl(1M) を呼び出して継続します (「検証側ノードの妥当性検査」を参照)。

検証側サーバーは、それ自体の NFS サービスも検査します。ロジックはほかのサーバーの検証に似ていますが、テイクオーバーを行うのではなく、syslog にエラーメッセージを記録し、プロセスが存在しなくなったデーモンの再起動を試みます。つまり、デーモンプロセスの再起動は、デーモンプロセスが終了したかクラッシュした場合だけ行われます。デーモンプロセスがまだ存在するが応答していないという場合は、デーモンプロセスの再起動は行われません。これは、このような状況で再起動を行うと、デーモンがどのデータ構造を更新しているかを認識せずにデーモンを停止してしまうためです。また、この 1 時間以内にローカル再起動が試みられたばかりの場合も再起動は行われません。代わりに、ほかのサーバーにテイクオーバーの検討指示が出されます (そのサーバーがそれ自体の妥当性検査をパスしている場合)。rpcbind デーモンが再起動することはありません。これは、rpcbind に登録しているプロセスに、再登録が必要であることを知らせる方法がないためです。

HA-DBMS の障害検証

Sun Cluster HA for Oracle、Sun Cluster HA for Sybase、Sun Cluster HA for Informix の各障害検証は、データベースサーバーを同じように監視します。HA-DBMS の障害検証を構成するには、ユーティリティ haoracle(1M)、hasybase(1M)、hainformix(1M) の 1 つを実行します (これらのユーティリティのオプションの詳細はマニュアルページを参照)。

ユーティリティの構成とアクティブ化が終わると、クライアントアクセスをシミュレートして、ローカルノードで 2 つのプロセスが開始され、遠隔ノードで 2 つのプロセスが開始されます。遠隔の障害検証は、ha_dbms_serv デーモンによって初期化され、hareg -y detaservicename が初期化される際に起動されます。

HA-DBMS モジュールは、2 つの方法を使用して DBMS サービスが使用できるかどうかを監視します。HA-DBMS は、まず DBMS 自体から統計情報を抽出します。

• Oracle では、V$SYSSTAT テーブルが照会されます。

• Sybase では、広域変数 @@io_busy、@@pack_received、@@pack_sent、@@total_read、 @@total_write、@@connections が照会されます。

• Informix では、SYSPROFILE テーブルが照会されます。

クライアントの作業が行われていることを統計情報が示す場合、DBMS の検証はそれ以上必要ありません。作業が行われていないことを DBMS 統計が示す場合、HA-DBMS は DBMS に対して小さなテストトランザクションを発行します。この場合、偶然にすべてのクライアントがアイドル状態であると、DBMS 統計は作業がまったく発生していないことを示します。つまり、テストトランザクションはハングしたデータベース状態と通常のアイドル状態を区別します。テストトランザクションは、アクティビティが存在しないことを統計情報が示す場合にだけ実行されるため、アクティブなデータベースにオーバーヘッドを強要することはありません。このトランザクションでは次の作業が行われます。

• HA_DBMS_REM または HA_DBMS_LOC という名前のテーブルを作成する

• 作成したテーブルに値を挿入する

• 挿入した値を更新する

• 作成したテーブルを削除する

HA-DBMS は、テイクオーバーを引き起こすコードと引き起こさないコードが示されたテーブルを使用して、DBMS が返すエラーコードを慎重に調べます。たとえば、Sun Cluster HA for Oracle では、table space full というケースはテイクオーバーを発生させません。これは、この状況を修復するには管理者が介入する必要があるためです (テイクオーバーが発生すると新しいマスターサーバーは同じ table space full 状態になります)。

一方、 could not allocate Unix semaphore のようなエラーリターンコードでは、Sun Cluster HA for Oracle はこのサーバーマシンで ORACLE をローカルに再起動しようとします。ローカル再起動が発生したばかりの場合は、代わってほかのマシンが (それ自体の妥当性検査にパスした後で) テイクオーバーします。

Sun Cluster HA for Netscape の障害検証

すべての Sun Cluster HA for Netscape データサービスの障害モニターは、データサービスインスタンスの障害監視を同じ方法で行います。これらはどれも、遠隔とローカルの障害監視という概念を使用します。

データサービスが実行されている論理ホストを現在制御しているノード上の障害モニタープロセスは、ローカル障害モニターと呼ばれます。論理ホストのマスターとなり得るノード上の障害監視プロセスは、遠隔障害モニターと呼ばれます。

Sun Cluster HA for Netscape の障害モニターは、サーバーに対して簡単なデータサービスオペレーションを周期的に行います。このオペレーションが失敗するか、あるいはタイムアウトする場合、この検証は失敗したと宣言されます。

検証が失敗した場合、ローカル障害検証はデータサービスをローカルに再起動しようと試みます。これで、通常はデータサービスが復元されます。遠隔検証は検証失敗の記録を保存しますが、何もアクションはとりません。検証が連続して 2 度失敗した場合 (データサービスの再起動が問題を解決しなかったことを示す)、遠隔検証は hactl(1M) コマンドを「テイクオーバー」モードで呼び出し、論理ホストのフェイルオーバーを開始します。Netscape データサービスの中には、検証の成功と失敗のスライド式ウィンドウアルゴリズムを使用するものがあります。このアルゴリズムでは、ウィンドウ内に事前に構成された失敗の数によって検証アクションが引き起こされます。

hadsconfig(1M) コマンドを使用して、Sun Cluster HA for Netscape 障害モニターの検証の間隔とタイムアウトの値を調整できます。障害検証の検証間隔の値を減らすと、問題が早く検出されますが、一時的な障害による誤ったフェイルオーバーが発生する可能性もあります。同様に、検証タイムアウトの値を減らすと、データサービスインスタンスに関連する問題が早く検出されますが、負荷が重いためにデータサービスが単にビジーになっている場合に誤ったテイクオーバーが発生する可能性があります。ほとんどの状況においては、これらのパラメータのデフォルト値で十分です。これらのパラメータについては、hadsconfig(1M) のマニュアルページと、『Sun Cluster 2.2 ソフトウェアのインストール』の各データサービスの構成に関する節に挙げられています。

Sun Cluster HA for DNS の障害検証

Sun Cluster HA for DNS の障害検証は、Sun Cluster HA for DNS サーバーの状態を検査するために nslookup オペレーションを実行します。このオペレーションは、Sun Cluster HA for DNS ロジカルホストのドメイン名を Sun Cluster HA for DNS サーバーから調べます。Sun Cluster HA for DNS の主サーバーがダウンしている場合は、nslookup は /etc/resolv.conf ファイルの構成にもとづいてほかのサーバーと通信する場合もあります。したがって、Sun Cluster HA for DNS の主サーバーがダウンしている場合でも、nslookup オペレーションが成功することがあります。このことを防止するため、障害検証は複製が Sun Cluster HA for DNS の主サーバーのものであるか、ほかのサーバーのものであるかを調べます。

Sun Cluster HA for Netscape HTTP の障害検証

Sun Cluster HA for Netscape HTTP の障害検証は、構成されたポート上の論理ホストアドレスで http サーバーに接続を試みることによって、http サーバーの状態を検査します。障害モニターは、nshttp サービスインスタンスの構成時に hadsconfig(1M) に指定されたポート番号を使用します。

Sun Cluster HA for Netscape News の障害検証

Sun Cluster HA for Netscape News の障害検証は、論理ホスト IP アドレスと nntp ポート番号で新しいサーバーに接続することによって、そのサーバーの状態を検査します。続いて、その新しいサーバーで NNTP date コマンドの実行を試み、指定された検証タイムアウトの間、サーバーからの応答を待ちます。

Sun Cluster HA for Netscape Mail または Message Server の障害検証

Sun Cluster HA for Netscape Mail または Message Server の障害検証は、サーバーのサービスを受ける 3 つのサービスポートすべて (SMTP、IMAP、POP3 ポート) でメールサーバーまたはメッセージサーバーの状態を検査します。

• SMTP (ポート 25) - サーバー上で SMTP「hello」メッセージを実行した後、quit コマンドを実行する

• IMAP (ポート 143) - IMAP4 CAPABILITY コマンド、IMAP4 LOGOUT コマンドの順に実行する

• POP3 (ポート 110) - quit コマンドを実行する

障害検証は、これらのテストはすべてについて、検証タイムアウトの間、サーバーからの応答文字列を待ちます。上記の 3 つのサービスポートのどれで検証が失敗しても、サーバー障害とみなされます。誤ったフェイルオーバーを避けるため、nsmail 障害検証はスライド式ウィンドウアルゴリズムを使用して、検証の失敗と成功を追跡します。スライド式ウィンドウ内の検証失敗の数が事前に構成されている数を超えた場合、遠隔検証によってテイクオーバーが開始されます。

Sun Cluster HA for Netscape LDAP の障害検証

Sun Cluster HA for Netscape LDAP の障害検証は、フェイルオーバーを開始する前にローカル再起動 (回数は変更可能) を実行できます。ローカル再起動機構は、スライド式ウィンドウアルゴリズムを使用します。つまり、そのウィンドウ内で再試行の数がなくなった場合だけフェイルオーバーが発生します。

Sun Cluster HA for Netscape LDAP の遠隔検証は、LDAP ポートに対する単純な telnet 接続を使用してサーバーの状態を検査します。LDAP ポート番号は、hadsconfig(1M) を使用して最初の設定時に指定されたものです。

ローカル検証は、

• 監視スクリプトを実行してサーバーを検証します。このスクリプトは、LDAP の一般名「monitor」を検索します。この一般名はディレクトリサーバーによって定義されたもので、監視にだけ使用されます。ローカル検証は、ldapsearch ユーティリティを使用してこのオペレーションを実行します。

• サーバーの障害を検出する際に、そのサーバーをローカルに再起動することを試みます。

• 遠隔検証が hactl(1M) コマンドを takeover モードで開始している間、ローカルノードはディレクトリサーバーインスタンスを正確に実行できないと判断し、hactl(1M) コマンドを giveup モードで開始します。論理ホストのマスターになり得るノードが複数存在する場合、遠隔検証はすべてテイクオーバーオペレーションを同時に呼び出します。しかし、テイクオーバーの後、配下のフレームワークによってディレクトリサーバー用に 1 つのマスターノードだけが選択されます。

Sun Cluster HA for Lotus の障害検証

Sun Cluster HA for Lotus の障害検証には、Lotus Domino サーバープロセスが現在動作しているノードで実行されるローカル検証と、Lotus Domino サーバーの論理ホストのマスターになり得るほかのノード上で実行される遠隔検証があります。

両方の検証とも Lotus Domino ポートに対する単純な telnet 接続を使用して、Domino サーバーの状態を検査します。接続に失敗した場合、検証は hactl(1M) コマンドを呼び出してフェイルオーバーまたはテイクオーバーを開始します。

ローカル障害検証は、フェイルオーバーを開始する前に、ローカル再起動を 3 度行えます。ローカル再起動機構は、スライド式のタイムウィンドウアルゴリズムを使用します。このアルゴリズムでは、そのウィンドウで再試行回数がなくなった場合だけ、フェイルオーバーが発生します。

Sun Cluster HA for Tivoli の障害検証

Sun Cluster HA for Tivoli の障害検証は、ローカル障害検証だけ使用します。この検証は、Tivoli オブジェクトディスパッチャ oserv デーモンが現在動作しているノードで行われます。

この障害検証は、Tivoli コマンド wping を使用して監視対象である oserv デーモンの状態を検査します。oserv デーモンの wping は、次の理由で失敗することがあります。

• 監視対象の oserv デーモンが動作していない

• クライアント oserv デーモンを監視している間に、サーバー上の oserv デーモンが停止した

• 管理ユーザーに適切な Tivoli ロール (承認) が設定されていない。Tivoli の詳細は、『Sun Cluster 2.2 ソフトウェアのインストール』を参照してください。

oserv デーモンに対する ping の実行に失敗した場合、ローカル検証は hactl(1M) コマンドを呼び出してフェイルオーバーを開始します。この障害検証は、フェイルオーバーを開始する前に、ローカル再起動を 1 度実行します。

Sun Cluster HA for SAP の障害検証

Sun Cluster HA for SAP の障害検証は、セントラルインスタンス (メッセージサーバー、エンキューサーバー、ディスパッチャ) が使用できるかどうかを監視します。この検証は、重要な SAP プロセスの存在を検査することにより、ローカルノードだけを検査します。また、SAP ユーティリティ lgtst を使用して、SAP メッセージサーバーがアクセス可能であるかも調べます。

問題が検出されると (プロセスの停止が早すぎる場合や lgtst がエラーを報告する場合など)、障害検証はまずローカルノード上で、hadsconfig(1M) を使用して構成可能な回数だけ SAP の再起動を試みます。ユーザーが構成してある再起動回数がなくなると、このインスタンスがフェイルオーバーを許可するように構成されている場合 (hadsconfig(1M) でも構成可能)、障害検証は hactl(1M) を呼び出してスイッチオーバーを開始します。セントラルインスタンスはスイッチオーバーが発生する前に停止し、スイッチオーバーが終了した後に遠隔ノード上で再起動します。