Sun Cluster 3.0 5/02 ご使用にあたって

既知の問題

すでに次の問題が Sun Cluster 3.0 5/02 リリースの動作に影響することが判明しています。最新情報については、http://docs.sun.com にあるオンラインの『Sun Cluster 3.0 5/02 Release Notes Supplement』を参照してください。

バグ ID 4490386

問題の概要:クラスタ内で Sun Enterprise 10000 サーバーを使用しているとき、ある構成で入出力カードを使用すると、これらのサーバーでパニックが発生する。

回避方法:クラスタ内にある Sun Enterprise 10000 サーバーの SBus 入出力ボードのスロット 0 には、UDWIS 入出力カードを設置しないでください。

バグ ID 4501655

問題の概要:ロックしようとしているデバイスがグローバルデバイス (/dev/global/rdsk/d4s0 など) であるとき、レコードロックが別のノードで機能しない。

任意の特定のノード上でプログラムを複数回バックグラウンドで実行するとき、レコードロックは機能しているように見える。プログラムの最初のコピーがデバイスの一部をロックした後、プログラムの他のコピーはデバイスがロック解除されるまでブロック待機するはずである。しかし、プログラムが異なるノードから実行された場合、そのプログラムはデバイスがロック解除されるまでブロック待機せずに、さらにデバイスをロックし続ける。

回避方法:回避方法はありません。

バグ ID 4504311

問題の概要:Sun Cluster 構成を Solaris 8 10/01 ソフトウェアにアップグレードするとき (Sun Cluster 3.0 12/01 へのアップグレードに必要)、Apache アプリケーションの起動スクリプトと停止スクリプトが復元される。Apache データサービス (Sun Cluster HA for Apache) がすでにクラスタ上に存在し、デフォルトの構成で構成されている場合 (つまり、/etc/apache/httpd.conf ファイルが存在し、/etc/rc3.d/S50apache ファイルが存在しない場合)、Apache アプリケーションは Sun Cluster HA for Apache データサービスとは無関係に独自に起動する。したがって、Apache アプリケーションがすでに動作しているため、Apache データサービスが起動しない。

回避方法:各ノード上で次の手順を実行します。

アップグレードのためにノードを停止する前に、次のリンクがすでに存在しているかどうかを確認し、存在している場合は、ファイル名に大文字の K または S が含まれているかどうかを確認します。
/etc/rc0.d/K16apache /etc/rc1.d/K16apache /etc/rc2.d/K16apache /etc/rc3.d/S50apache /etc/rcS.d/K16apache
これらのリンクがすでに存在しており、ファイル名に大文字の K または S が含まれている場合は、何もする必要はありません。そうでない場合は、ノードを Solaris 8 10/01 ソフトウェアにアップグレードした後に次の手順を実行します。

ノードを Solaris 8 10/01 ソフトウェアにアップグレードした後、ノードを再起動する前に、復元された Apache のリンク名を変更します (たとえば、ファイル名を小文字の k や s にします) 。

# mv /a/etc/rc0.d/K16apache /a/etc/rc0.d/k16apache
# mv /a/etc/rc1.d/K16apache /a/etc/rc1.d/k16apache
# mv /a/etc/rc2.d/K16apache /a/etc/rc2.d/k16apache
# mv /a/etc/rc3.d/S50apache /a/etc/rc3.d/s50apache
# mv /a/etc/rcS.d/K16apache /a/etc/rcS.d/k16apache

バグ ID 4511699

問題の概要: Sun Cluster HA for NFS では、/etc/nsswitch.conf ファイルの hosts 検索エントリに files [SUCCESS=return] が設定されている必要があり、さらに、すべてのクラスタのプライベート IP アドレスが、すべてのクラスタノード上にある /etc/inet/hosts ファイルに存在する必要がある。

そうでない場合、パブリックネットワークに障害が発生したときに、Sun Cluster HA for NFS は正しくフェイルオーバーできない。

回避方法:クラスタの各ノードで次の作業を実行します。

/etc/nsswitch.conf ファイルの hosts エントリを変更して、ローカルで名前を解決できたときには即座に成功を戻して、NIS や DNS に問い合わせないようにします。
hosts: cluster files [SUCCESS=return] nis dns

すべてのクラスタのプライベート IP アドレス用のエントリを /etc/inet/hosts ファイルに追加します。

追加する必要がある IP アドレスは、/etc/nsswitch.conf ファイルと /etc/inet/hosts ファイルにある物理プライベートインタフェース上に plumb されている IP アドレスだけです。論理 IP アドレスはすでに、クラスタの nsswitch ライブラリで解決可能です。

物理プライベート IP アドレスのリストを表示するには、次のコマンドを任意のクラスタノード上で実行します。

% grep ip_address /etc/cluster/ccr/infrastructure

このリスト内の各 IP アドレスは、一意な (ドメイン内にある他のどのドメイン名とも衝突しない) ホスト名に割り当てられている必要があります。

注 -

Sun Cluster ソフトウェアでは、HA IP アドレス (LogicalHostname/SharedAddresses) がすべてのクラスタノード上にある /etc/inet/hosts ファイルに存在する必要があり、さらに、files が nis または dns よりも前に存在する必要があります。このバグのために追加された条件としては、[SUCCESS=return] を files の後に指定する必要があり、さらに、すべてのクラスタのプライベート IP アドレスを /etc/inet/hosts ファイルに指定する必要があります。

バグ ID 4526883

問題の概要:非常にまれだが、qfe アダプタで終了するプライベートインターコネクト転送パスが起動に失敗する。

回避方法:次の手順を実行します。

障害に関わったアダプタを確認します。

scstat -W を使用すると、当該アダプタに関わるすべての転送パスは「faulted (障害発生)」または「waiting (待機中)」のどちらか 1 つの状態であるパスエンドポイントとして表示されます。

scsetup(1M) を使用して、当該アダプタに接続されているすべてのケーブルをクラスタ構成から削除します。

scsetup をもう一度使用して、当該アダプタをクラスタ構成から削除します。

アダプタとケーブルをクラスタ構成に追加し直します。

上記手順で問題が解決できたかどうか、そして、パスを起動できるかどうかを確認します。

ケーブルとアダプタを (クラスタ構成から) 削除して追加し直しても問題が解決しなかった場合、上記手順を数回繰り返してみます。これでも問題が解決できなかった場合、問題のアダプタを持つノードを再起動します。ノードが起動すると、問題が解決していることもあります。ノードを再起動する前に、残りのクラスタがノードを再起動しても生き残れるだけの十分な定足数を持っていることを確認します。

バグ ID 4620185

問題の概要:rpc.pmfd デーモンが、signal 処理の結果として新しいプロセスをフォークするプロセスを監視する場合、pmfadm -k tag signal を使用すると、無限ループになる可能性がある。この無限ループは、pmfadm(1M) が tag のプロセスツリー内のすべてのプロセスを強制終了しようとするが、(以前のプロセスを強制終了した結果として) 新たにフォークされたプロセスが上記プロセスツリーに追加されるために発生する。

注 -

このバグは、pmfadm -s tag signal では発生しない。

回避方法:pmfadm -k の代わりに、pmfadm -s tag signal を使用します。pmfadm の -s オプションでは、-k オプションのような状況は発生しません。

バグ ID 4629536

問題の概要:forcedirectio マウントオプションと mmap(2) 関数を同時に使用すると、データが破壊されて、システムがハングまたはパニックする可能性がある。

回避方法:次の制限について、確認してください。

ファイルシステムをマウントし直すときは、 directio マウントオプションを指定してはなりません。
directio ioctl を使用して、directio マウントオプションを単一ファイルに設定してはなりません。

directio を使用する必要がある場合、ファイルシステム全体を directio オプションでマウントします。

バグ ID 4634409

問題の概要:同じデバイスを異なるマウントポイントにマウントしようとすると、ほとんどの場合、システムはこのエラーを受け取り、2 回目のマウントは失敗する。しかし、非常にまれだが、システムはこのエラーを受け取ることができず、両方のマウントを許可することがある。これは、次の 4 つの条件すべてが真の場合のみに発生する。

2 つのマウントが同時に実行される。
同じデバイスがマウントされる。
(同じ) デバイスが 2 つの異なるマウントポイントにマウントされる。
1 つのマウントがグローバルで、もう 1 つのマウントがローカルである。

回避方法:クラスタ上のファイルシステムをマウントするとき、システム管理者は十分に注意してください。

バグ ID 4638586

問題の概要:scconf(1M) コマンドは VxVM ディスクグループにマイナー番号を割り当て直さないことがあり、「device is already in use in another device group」というエラーを戻すことがある。

回避方法:次の手順を実行して、新しいマイナー番号をディスクグループに割り当てます。

すでに使用されているマイナー番号を調べます。

次の出力で、使用中のマイナー番号とメジャー番号を調べます。

% ls -l /dev/vx/rdsk/*/*
 
crw-------   1 root     root     210,107000 Mar 11 18:18 /dev/vx/rdsk/fix/vol-01
crw-------   1 root     root     210,88000 Mar 15 16:31 /dev/vx/rdsk/iidg/vol-01
crw-------   1 root     root     210,88001 Mar 15 16:32 /dev/vx/rdsk/iidg/vol-02
crw-------   1 root     root     210,88002 Mar 15 16:33 /dev/vx/rdsk/iidg/vol-03
crw-------   1 root     root     210,88003 Mar 15 16:49 /dev/vx/rdsk/iidg/vol-04
crw-------   1 root     root     210,13000 Mar 18 16:09 /dev/vx/rdsk/sndrdg/vol-01
crw-------   1 root     root     210,13001 Mar 18 16:08 /dev/vx/rdsk/sndrdg/vol-02

新しいディスクグループのベースとなるマイナー番号として、使用されていない 1000 の倍数を選択します。

使用されていないマイナー番号を問題のディスクグループに割り当てます。

vxdg コマンドのマイナー番号再割り当てオプションを使用します。

失敗した scconf コマンドをやり直します。

バグ ID 4644289

問題の概要:Solaris 9 では、パブリックネットワークに障害が発生したとき、外部ネームサービスが利用できないと、Sun Cluster HA for Oracle データサービスの停止メソッドがタイムアウトすることがある。Sun Cluster HA for Oracle データサービスは su(1M) ユーザーコマンドを使用して、データベースを起動および停止する。

回避方法:oracle_server または oracle_listener リソースの主ノードになることができる各ノード上で、/etc/nsswitch.conf ファイルを編集して、次のような passwd、group、publickey、および project データベース用のエントリを追加します。

passwd:       files
group:        files
publickey:    files
project:      files

この変更によって、su(1M) コマンドは NIS/NIS+ ネームサービスを参照せず、ネットワークに障害が発生したとき、データサービスは正しく起動および停止できるようになります。

バグ ID 4648767

問題の概要:sendfile(3EXT) を使用すると、ノードがパニックする。

回避方法:この問題を回避する唯一の方法は、sendfile を使用しないことです。

バグ ID 4651392

問題の概要:Solaris 9 では、クラスタノードがシャットダウンの途中で次のメッセージを出してパニックすることがある。

CMM: Shutdown timer expired. Halting

回避方法:この問題を回避する方法はありません。このノードのパニックは他に副作用を持たないので、比較的危険がないバグとして扱うことができます。

バグ ID 4653151

問題の概要:FilesystemMountPoints 拡張プロパティに指定されたファイルシステムのマウントポイントの順番が /etc/vfstab ファイルに指定された順番と同じでない場合、HAStoragePlus リソースが作成できない。

回避方法:FilesystemMountPoints 拡張プロパティに指定されたマウントポイントの順番が /etc/vfstab ファイルに指定された順番と一致することを確認します。たとえば、/etc/vfstab ファイルに /a、/b、および /c という順番でファイルシステムのエントリが指定されている場合、FilesystemMountPoints において、「/a,/b,/c」、「/a,/b」、「/a,/c」という順番は一致しますが、「/a,/c,/b」という順番は一致しません。

バグ ID 4653788

問題の概要: Failover_enabled 拡張プロパティが FALSE に設定されている場合、本来、リソースモニターがリソースグループをフェイルオーバーすることを防ぐことを意味する。

しかし、リソースモニターがリソースを再起動しようとする場合、START または STOP メソッドが失敗またはタイムアウトすると、Failover_enabled の設定に関わらず、リソースモニターはギブオーバーしようとする。

回避方法:この問題を回避する方法はありません。

バグ ID 4655194

問題の概要:デバイスグループのスイッチオーバーコマンド (scswitch -D device-group) が発行された場合、ローカルにマウントされた VxFS 上のデバイスグループにある Solstice DiskSuite ソフトパーティションがエラーになることがある。

Solstice DiskSuite は内部的にミラー再同期操作を実行するが、これにかなりの時間がかかることがある。ミラー再同期は冗長性を低下させる。このとき、VxFS が報告するエラーによってモニター/アプリケーション入出力エラーとなり、アプリケーションが再起動する。

回避方法:HAStoragePlus に構成されているどの Solstice DiskSuite デバイスグループにおいても、デバイスグループを手動でスイッチオーバーしてはなりません。その代わりに、リソースグループをスイッチオーバーすると、結果として、デバイスは問題なくスイッチオーバーされます。

あるいは、ローカルにマウントされた VxFS ファイルシステムを VxVM ディスクグループ上に構成します。

バグ ID 4656367

問題の概要:いくつかのエラーメッセージが Sun Cluster 3.0 5/02 CD-ROM に含まれていない。

回避方法:このようなエラーメッセージは「新しいエラーメッセージ」に記載されています。

バグ ID 4656391

問題の概要:Sun Cluster のグローバル Solstice DiskSuite/VxVM デバイスグループ上にあるファイルシステムの fsck(1M) は、主ノード以外のノード (二次ノード) から実行すると失敗する。この現象は Solaris 9 で観察されたが、初期の Solaris リリースでも現れる可能性はある。

回避方法:fsck コマンドは主ノードだけから呼び出します。

バグ ID 4656531

問題の概要:複数のリスナーリソースが同じリスナー名でリスナーを起動するように構成されている場合、Sun Cluster HA for Oracle リスナーリソースは正しく動作しない。

回避方法:クラスタ上で動作している複数のリスナーに同じリスナー名を使用してはなりません。

バグ ID 4657088

問題の概要:Sun Cluster 3.0 下にある VxVM ディスクグループからプレックスを関連付け解除/切断すると、クラスタノードは次のエラーメッセージを出してパニックする。

  panic[cpu2]/thread=30002901460: BAD TRAP: type=31 rp=2a101b1d200 addr=40  
  mmu_fsr=0 occurred in module "vxfs" due to a NULL pointer dereference

回避方法:プレックスを関連付け解除/切断する前に、対応するファイルシステムをマウント解除します。

バグ ID 4657833

問題の概要:リソースグループプロパティ auto_start_on_new_cluster が false に設定されているとき、フェイルオーバーが発生しない。

回避方法:クラスタ全体が再起動するたびに、auto_start_on_new_cluster プロパティが false に設定されているリソースグループごとに、auto_start_on_new_cluster プロパティを true に設定して、その後、auto_start_on_new_cluster プロパティを false に設定し直します。

# scrgadm -c -g rgname -y auto_start_on_new_cluster=true
# scrgadm -c -g rgname -y auto_start_on_new_cluster=false

バグ ID 4659042

問題の概要:グローバルにマウントされた VxFS ファイルシステムの場合、/etc/mnttab ファイルシステムはグローバルオプションを表示しないことがある。

回避方法:あるファイルシステム用の /etc/mnttab エントリがクラスタのすべてのノード上にある場合、そのファイルシステムがグローバルにマウントされていることを意味します。

バグ ID 4659091

問題の概要:グローバルにマウントされたファイルシステムをマウントし直すとき、/etc/mnttab が更新されない。

回避方法:回避方法はありません。

バグ ID 4660479

問題の概要:Sun Cluster HA for NFS を HAStoragePlus と一緒に使用するとき、フェイルオーバーおよびスイッチオーバー中、ブロックしているロックが回復しない。結果として、Sun Cluster HA for NFS は lockd を再起動できず、nfs_postnet_stop メソッドが失敗し、クラスタノードがクラッシュする。

回避方法:HAStoragePlus では Sun Cluster HA for NFS を使用してはなりません。クラスタファイルシステムではこの問題は発生しないので、Sun Cluster HA for NFS をクラスタファイルシステム上に構成すると、この問題を回避できます。

バグ ID 4660521

問題の概要:あるノード上で HTTP サーバーが強制終了されたとき、当該ノード上で PID ファイルが残る。HTTP サーバーは次回起動されるとき、PID ファイルが存在しているかどうかをチェックし、その PID を持つプロセスが動作しているかどうかをチェックする (kill -0)。PID は再利用されるので、最後の HTTP サーバーの PID と同じ PID を持つ別のプロセスが存在する可能性がある。すると、HTTP サーバーが起動に失敗する。

回避方法:HTTP サーバーが次のようなエラーで起動に失敗した場合、HTTP サーバー用の PID ファイルを手動で削除すると、正常に再起動できます。

Mar 27 17:47:58 ppups4 uxwdog[939]: could not log PID to PidLog 
/app/iws/https-schost-5.example.com/logs/pid, server already running (No such file or directory)

バグ ID 4662264

問題の概要:VxFS のような VERITAS 製品を Sun Cluster ソフトウェアと一緒に使用するときにパニックを回避するには、デフォルトのスレッドスタックサイズを増やす必要がある。

回避方法:スタックサイズを増やすには、/etc/system ファイルに次の行を追加します。

set lwp_default_stksize=0x6000
set svc_default_stksize 0x8000

svc_default_stksize エントリは NFS 操作のために必要です。

VERITAS パッケージをインストールした後、VERITAS が同様な文を /etc/system ファイルに追加していないことを確認します。追加していた場合、2 つの文のうち高い方の値を持つ文を残します。

バグ ID 4663876

問題の概要:ノード整列リストを持つ 3 ノード以上のデバイスグループでは、整列リストの最後でないノードを削除しようとすると、scconf はノードリストについての情報を一部しか表示しない。

回避方法:

この問題を回避するには、ノードリスト内の最後にあるノードから 1 つずつ削除していき、目的のノードを削除します。その後、目的以外のノードをデバイスグループに追加し直します。
このバグに遭遇してしまったクラスタの状態を修復するには、次の手順を使用します。
1. デバイスグループを使用しているサービス (ファイルシステムやデータサービス) をすべて停止します。
2. scsetup(1m) を使用して、デバイスグループをクラスタのメモリーから登録解除 (削除) します。注:デバイスグループ自身はそのままにしておきます。
3. scsetup(1m) を使用して、デバイスグループを (新しいデバイスグループであるかのように) 登録し直して、正しいノードリストを追加します。
削除したノードをデバイスグループに追加し直すとき、有効なノードを含む整列リストを明示的に指定します。

バグ ID 4664510

問題の概要:Sun StorEdge T3 Array の 1 つの電源を切断して scshutdown を実行した後、両方のノードを再起動すると、クラスタが動作していない状態になる。

回避方法:複製の片方が失われた場合、次の手順を実行します。

クラスタがクラスタモードであることを確認します。

強制的にディスクセットをインポートします。
# metaset -s set-name -f -C take

壊れた複製を削除します。

# metadb -s set-name -fd /dev/did/dsk/dNsX

ディスクセットを解放します。
# metaset -s set-name -C release
これでファイルシステムはマウントおよび使用できます。しかし、複製の冗長性は復元されていません。複製のもう片方が失われた場合、ミラーを正常な状態に復元する方法はありません。

上記修復手順を適用した後、データベースを作成し直します。