test

Sun Cluster 2.2 のシステム管理

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

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

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

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

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

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

Sun Cluster HA for NFS の障害検証

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

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

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

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

これらの 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 自体から統計情報を抽出します。

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

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 ポート) でメールサーバーまたはメッセージサーバーの状態を検査します。

障害検証は、これらのテストはすべてについて、検証タイムアウトの間、サーバーからの応答文字列を待ちます。上記の 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) を使用して最初の設定時に指定されたものです。

ローカル検証は、

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 デーモンに対する 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) を呼び出してスイッチオーバーを開始します。セントラルインスタンスはスイッチオーバーが発生する前に停止し、スイッチオーバーが終了した後に遠隔ノード上で再起動します。

SAP 障害検証に対する LOG_DB_WARNING メッセージの表示

Sun Cluste HA for SAP の障害検証がデータベースに接続できないときに警告メッセージを表示するかどうかは、Sun Cluste HA for SAP のパラメータ LOG_DB_WARNING で指定します。LOG_DB_WARNING が y に設定されている場合、障害検証がデータベースに接続できないと、メッセージが local0 機能に warning レベルでログされます。デフォルトで syslogd(1M) デーモンは、これらのメッセージを /dev/console または /var/adm/messages に表示しません。これらのメッセージを表示するには、/etc/syslog.conf ファイルを変更して、優先度が local0.warning のメッセージを表示する必要があります。たとえば、次のようにします。


...
*.err;kern.notice;auth.notice;local0.warning /dev/console
*.err;kern.debug;daemon.notice;mail.crit;local0.warning /var/adm/messages
...

ファイルを変更した後に syslogd(1M) を再起動する必要があります。詳細は、syslog.conf(1M) と syslogd(1M) のマニュアルページを参照してください。