管理の手引き


トラブルシューティング

以下の表には、起こり得る問題、その推定原因、 および解決するために取ることのできるアクションが示されています。

表 61. Sun Cluster 2.2 での高可用性のトラブルシューティング
症状 考えられる原因 アクション
論理ホストのファイル・システムをマウントできない 論理ホストのファイル・システムは通常、 論理ホストのフェールオーバー時にマウントおよびアンマウントされます。 フェールオーバーのときに、 論理ホストのファイル・システムの下に活動状態のプロセスまたはオープン・ファイルがあってはなりません。 まれに、強制終了できないプロセスが、 その現行作業ディレクトリーを論理ホストのファイル・システムの下に保持していることがあります。 プロセスがマウント・ポイントの下にあるかどうかを知るには、 fuser(1m) か、 GNU ユーティリティー lsof を使用します。 論理ホストのファイル・システムをマウントできない場合、 エラー・メッセージが出されます。a システムをリブートするか、 または論理ホストのファイル・システムを別の名前にして再作成してください。 これを行うことにより、 凍結したプロセスをディレクトリーの下に残すことができ (強制終了ができないため)、 マウントができるようになります。 b
db2start または db2stop のタイムアウトが機能しない SIGALRM シグナルがブロック化システム呼び出しから出されない場合があります。 代わりに、 SA_RESTART フラグが sigaction() を使用して設定されたかのように、 このシステム呼び出しが再始動されます。 これにより、DB2 HA エージェントのタイムアウトは無視され、 エージェント・メソッドはハングし、 ハングした db2start または db2stop コマンドから回復されません。 Solaris 2.6 用の必要なパッチ105210-17 (またはそれ以降) を適用してください。
インスタンスにログインするとハングする これが起きる理由はたくさんありますが、 最も一般的な理由には、 NFS の問題および /usr/sbin/quota プログラムが関係します。 NFS マウントを検査してそれが良好な状態であることを確認してください。 また、インスタンス所有者が所有する割り当て量のプロセスも確認してください。 システム管理者の判断により、 割り当て量プログラムを /bin/true へのシンボリック・リンクに変更すると、 この問題を解決できる可能性があります。 ただし、これは推奨されている解決方法ではありません。
EEE インスタンスをセットアップしたが、始動しない hadb2_setup コマンドが、 ポートを /etc/services ファイルに追加しません。 管理者が手作業で追加すると予期されています。 エラー・メッセージが戻されます。c /etc/services ファイルで適切なポートを指定したことを確認してください。
START_NET メソッドが DB2 を開始できない
障害モニターをオフにして、 インスタンスがフェールオーバーされていないことを確認してください。 インスタンス所有者としてログインして、 DB2 を手作業で開始してください。

  1. hadb2tab 構成ファイルで適切なインスタンス・タイプが指定されていることを確認します。 たとえば、 EE 管理インスタンス用の db2nodes.cfg ファイルがあると、問題が起こります。 HA エージェント・メソッドは、この問題から回復することができません。
  2. .rhosts ファイルが存在し、 その中に有効な項目があることを確認します。
  3. HA-NFS ファイル・システムが、 クラスター内の全マシンのルート許可によって共用されていることを確認します。
  4. カーネル・パラメーターを検査し、 正しいことを確認します。
  5. /etc/services ファイルにインスタンスの項目が含まれることを確認します。
インスタンスが 1 つのマシンでしか機能しない
  • インスタンスの uid 数値が、 クラスター内の各マシンで同じでない可能性があります。
  • カーネル・パラメーターが、 クラスター内の各マシンで有効でない可能性があります。
  • hadb2tab ファイルが、 クラスター内の各マシンで同じでない可能性があります。
  • 論理ホストの vfstab ファイルのような別の構成ファイルが、 クラスター内の各マシンで同じでない可能性があります。

これらの原因のどれも当てはまらないと思われる場合、 インスタンス所有者としてログインを試みて、 DB2 を手作業で開始してください。 EE インスタンスの場合、 インスタンスをホストしている論理ホストが現行のマシンによってホストされていれば、 これはうまくいくはずです。 EEE インスタンスの場合、 データベース区画をホストできるクラスター内のどのマシンからも、 これはうまくいくはずです。
su -<instance> -c "db2start" が機能しない
  • インスタンスの .profile が、 su に適していない可能性があります。
  • Bourne シェル (/bin/sh) に関する既知の問題があります。 このシェルでは、su コマンドは手作業では機能しますが、 HA エージェントを介しては機能しません。

  • ルートとして、 このコマンドを手作業で実行して機能することを確かめてから、 HA エージェントを介して再試行してください。
  • 必要であれば、 Korn シェル (/bin/ksh) に切り替えてください。

EEE インスタンスが開始しないのに、 ホーム・ディレクトリーはマウントされている HA-NFS ディレクトリーが「ルート」許可と一緒にクラスター内のマシンにエクスポートされなかった可能性があります。 DB2 と HA エージェントの両方で、 適切に実行されるにはこれが必要です。 これをテストするには、 インスタンス所有者のホーム・ディレクトリーの下に、 (ルートとして) ファイルを作成してください。
EEE インスタンスのディレクトリーにアクセスしようとすると、 「不良な NFS ファイル・ハンドル」エラーが戻される インスタンス所有者のホーム・ディレクトリーの下にプロセスがまだ残っている可能性があります。 インスタンス所有者のホーム・ディレクトリーをアンマウントし、 HA エージェントがそれを再マウントできるようにしてください。 HA エージェントが再マウントするのは、 hadb2 サービスがオフになり、 再びオンになった場合です (hadb2_setup コマンドhadb2_setup コマンドにある -s スイッチの説明を参照してください)。
制御メソッドが SC2.2 を介して正常に実行されない hadb2 サービスが Sun Cluster に登録されていないか、 それがオンになっていない可能性があります。 制御メソッドがコマンド行から通常どおり実行されているように見える場合は、 SYSLOG ファイルを検査して、問題を説明するのに役立つエラー・メッセージを探してください。 hadb2 サービスが Sun Cluster ソフトウェアに登録されており、 それがオンになっていることを確認してください。

手動によるメソッドの実行は、 問題のデバッグに役立ちます。d

制御メソッドは、ルートとして実行し、 適切なコマンド行引き数を渡す必要があります。 論理ホストのリストがヌルの場合、 引き数は "" として渡されます。 ブランク・スペースの区切り文字がない二重引用符は、 ブランクの引き数を表します。 以下はその例です。

 hadb2_startnet log0,log1 "" 600

最初の引き数 log0,log1 は、 論理ホスト log0 および log1 が現行のマシンによってホストされていることを、 hadb2_startnet メソッドに知らせます。 2 つ目の引き数はヌルで、 これはクラスター内のほかのマシンでホストされている論理ホストが存在しない (すべてが現行のマシンにある) ことを、 hadb2_startnet メソッドに知らせます。 3 つめの引き数は、 SC2.2 が 600 秒後にタイムアウトになることをメソッドに知らせます。

ユーザー・スクリプトが実行されない ユーザー・スクリプトは、 それが適切なディレクトリーにあり、 実行可能である場合にのみ実行できます。 所有権と属性を検査してください。 それでもスクリプトが実行できない場合は、 IBM サービスに連絡してください。 実行できないスクリプトのディレクトリー・リストと、 スクリプトを実行できなければならなかったフェールオーバーまたはクラスター構成の SYSLOG 出力を転送してください。
/etc/syslog.conf で指定したファイルに情報を記録できない
touch(1) を使用して、 /etc/syslog.conf ファイルで指定したファイルを作成してから、 SYSLOG デーモンを再始動してください。

a 論理ホストのファイル・システムをマウントできないときに出されるエラー・メッセージは、 以下のようなものです。

Aug 17 11:14:01 rash ID[SUNWcluster.loghost.1170]: importing data1
Aug 17 11:14:06 rash ID[SUNWcluster.scnfs.3040]: mount -F ufs -o ""
     /dev/vx/dsk/data1/data1-stat /log1 failed.
Aug 17 11:14:07 rash ID[SUNWcluster.ccd.ccdd.5304]: error freeze cmd =
     /opt/SUNWcluster/bin/loghost_sync
CCDSYNC_POST_ADDU LOGHOST_CM:log1:rash /etc/opt/SUNWcluster/conf/ccd.database
     2 "0 1" 1 error code = 1

b たとえば、以下の通りです。

   scadmin@rash(218)# ps -fe | egrep db2
   db2ee 1984 1 0 0:01 <defunct>
 
   Solution:
 
      scadmin@rash(229)# cd /
      scadmin@rash(230)# mv /log1 /log1.bkp
      scadmin@rash(231)# mkdir /log1

c エラー・メッセージは以下のようなものです。

   SQL6030N START or STOP DATABASE MANAGER failed. Reason code "13".

d たとえば、 hadb2_startnet メソッドが libdb2.so.1 を見付けられないが、 Sun Cluster を介して通常どおり実行される場合、 エラーは報告されません。 このメソッドを手作業で実行すると、 以下のような結果が出されます。

   scadmin@crackle(213)# hadb2_startnet '''log0,log1' 600
   ld.so.1: hadb2_startnet: fatal: libdb2.so.1: open failed:
      No such file or directory
   Killed


[ ページのトップ | 前ページ | 次ページ | 目次 | 索引 ]