すべての 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 サーバーの状態を検査するために 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 の障害検証は、構成されたポート上の論理ホストアドレスで http サーバーに接続を試みることによって、http サーバーの状態を検査します。障害モニターは、nshttp サービスインスタンスの構成時に hadsconfig(1M) に指定されたポート番号を使用します。
Sun Cluster HA for Netscape News の障害検証は、論理ホスト IP アドレスと nntp ポート番号で新しいサーバーに接続することによって、そのサーバーの状態を検査します。続いて、その新しいサーバーで NNTP date コマンドの実行を試み、指定された検証タイムアウトの間、サーバーからの応答を待ちます。
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 の遠隔検証は、LDAP ポートに対する単純な telnet 接続を使用してサーバーの状態を検査します。LDAP ポート番号は、hadsconfig(1M) を使用して最初の設定時に指定されたものです。
ローカル検証は、
監視スクリプトを実行してサーバーを検証します。このスクリプトは、LDAP の一般名「monitor」を検索します。この一般名はディレクトリサーバーによって定義されたもので、監視にだけ使用されます。ローカル検証は、ldapsearch ユーティリティを使用してこのオペレーションを実行します。
サーバーの障害を検出する際に、そのサーバーをローカルに再起動することを試みます。
遠隔検証が hactl(1M) コマンドを takeover モードで開始している間、ローカルノードはディレクトリサーバーインスタンスを正確に実行できないと判断し、hactl(1M) コマンドを giveup モードで開始します。論理ホストのマスターになり得るノードが複数存在する場合、遠隔検証はすべてテイクオーバーオペレーションを同時に呼び出します。しかし、テイクオーバーの後、配下のフレームワークによってディレクトリサーバー用に 1 つのマスターノードだけが選択されます。