Sun Cluster 3.1 10/03 ご使用にあたって

既知の問題点とバグ

次に示す既知の問題とバグは、Sun Cluster 3.1 10/03 リリースの処理に影響を与えます。最新情報については、http://docs.sun.com に挙げられているオンラインの『 Sun Cluster 3.1 10/03 Release Notes Supplement』を参照してください。

不正な `largefile` 状態 (4419214)

問題の概要:/etc/mnttab ファイルに、グローバルにマウントされている VxFS ファイルシステムの最新の largefile 状態が示されない。

回避方法: fsadm コマンドを使用し、(/etc/mnttab エントリではなく) ファイルシステムの largefile 状態を確認してください。

ノードが qfe パスを呼び出せない (4526883)

問題の概要:qfe アダプタを終端としたプライベートインターコネクトのトランスポートパスがオンラインにならない場合がある。

回避方法: 以下の作業を行なってください。

scstat -W を実行し、エラーの起きたアダプタを確認します。すべてのトランスポートパスが表示され、エラーの起きたアダプタが faulted 状態または waiting 状態にあるパス終端の 1 つとして示されます。
scsetup を実行し、そのアダプタに接続されているケーブルをすべてクラスタ構成から削除します。
scsetup をもう一度使用して、そのアダプタをクラスタ構成から削除します。
アダプタとケーブルを追加し直します。
パスが表示されるか確認します。問題が継続する場合は、手順 1 から 5 の作業を数回繰り返してください。
パスが表示されるか確認します。問題がまだ継続する場合は、エラーの起きたアダプタを使用してノードを再起動します。ノードを再起動する前に、残りのクラスタがノードを再起動しても生き残れるだけの十分な定足数を持っていることを確認します。

スパースファイルのホール (欠落ブロック) に対する書き込み処理のあと、ファイルブロックが更新されない (4607142)

問題の概要:スパースファイル内でブロック割り当てのための書き込み処理を行なったあと、ファイルのブロックカウントがクラスタノード全体で矛盾した状態になる場合がある。クラスタノード全体におけるこのブロック不整合は、UFS (または VxFS 3.4) でレイヤー化されたクラスタファイルシステムの場合には 30 秒ほどで解決される。

回避方法: inode を更新するファイルメタデータ処理 (修正など) では、st_blocks 値と同期をとる必要があります。これは、後続のメタデータ処理で st_blocks 値の一貫性を維持するためです。

ネットワーク障害の発生時に、データサービスの開始および終了を正常に行えない (4644289)

問題の概要:Sun Cluster HA for Oracle データサービスは、データベースの起動および終了に su コマンドを使用する。クラスタノードのパブリックネットワークに障害が発生すると、ネットワークサービスが使用不能になることがある。

回避方法: Solaris 9 の場合、ネットワーク障害の発生時にデータサービスの開始および終了が正常に行われるように、/etc/nsswitch.conf ファイルの内容を変更します。

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

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

上記のエントリを追加すると、su(1M) コマンドは NIS/NIS+ ネームサービスを参照しなくなります。

クラスタファイルシステムのマウント解除が失敗する (4656624)

問題の概要:fuser コマンドによってどのノードにもユーザーは存在しないと報告される場合でも、クラスタファイルシステムのマウント解除が失敗することがある。

回避方法: そのファイルシステムに対する非同期入出力がすべて完了したあとでマウント解除の操作をもう一度行なってください。

Sun Cluster HA–Siebel が Siebel コンポーネントの監視に失敗する (4722288)

問題の概要:Sun Cluster HA-Siebel エージェントが個々の Siebel コンポーネントを監視しない。Siebel コンポーネントの障害が検出された場合、syslog には警告メッセージしか記録されない。

回避方法: コマンド scswitch -R -h node-g resource_group を使用し、コンポーネントがオフラインになっている Siebel サーバーリソースグループを再起動してください。

新しく追加したノード上で Oracle RAC インスタンスを使用できない (4723575)

問題の概要:新しく追加したノードに Sun Cluster の RAC サポートをインストールすると、Oracle RAC インスタンスを使用できなくなる。

回避方法: Oracle RAC サポートを実行しているクラスタにノードを追加した後も Oracle RAC データベースを引き続き使用したい場合は、特別なインストール手順を実行します。以下の例では、ノード 1、2、および 3 で Oracle RAC を実行しながら、3 ノードクラスタから 4 ノードクラスタへ移行する方法を示します。

新しいノード (ノード 4) に Sun Cluster ソフトウェアをインストールします。

注:この時点では、まだ RAC サポートパッケージをインストールしません。
新しいノードを再起動してクラスタに結合します。
新しいノードをクラスタに結合したなら、Oracle RAC データベースを実行中のいずれか 1 つのノード (この例ではノード 1) で、Oracle RAC データベースを停止します。
このノード (ノード 1) を再起動します。
ノード (ノード 1) が回復したなら、このノード上で Oracle データベースを起動し、データベースサービスを再開します。
データベースの負荷を単一のノードで処理できる場合は、残りのノード (ノード 2 および 3) 上のデータベースを停止して、これらのノードを再起動します。データベースの負荷をサポートするために複数のノードが必要な場合は、手順 3 から 5 のように 1 つずつノードの再起動を行います。
すべてのノードの再起動が完了したなら、新しいノード上に Oracle RAC サポートパッケージをインストールします。

`remove` スクリプトが `SUNW.gds` リソースタイプの登録解除に失敗する (4727699)

問題の概要:remove スクリプトが SUNW.gds リソースタイプの登録解除に失敗し、次のメッセージを表示する。

Resource type has been un-registered already.

回避方法: remove スクリプトを使用したあとで、SUNW.gds の登録を手動で解除してください。あるいは、scsetup コマンドか SunPlex Manager を使用することもできます。

Solaris の `shutdown` コマンドを使用するとノードパニックが起きることがある (4745648)

問題の概要:Solaris の shutdown コマンドまたはこのコマンドに類似したコマンド (uadmin など) を使用してクラスタノードを停止すると、ノードパニックが起きて次のメッセージが表示されることがある。

CMM: Shutdown timer expired. Halting.

回避方法: Sun のサービス担当者に連絡してサポートを受けてください。このパニックは、停止するノードによって管理されていたサービスをクラスタ内のほかのノードに安全に引き継がせるために必要なものです。

プライベートインターコネクトに `ce` アダプタを使用する場合、パスがタイムアウトする (4746175)

問題の概要:プライベートインターコネクトに ce アダプタを使用するクラスタでは、1 つ以上のクラスタノードが 5 個以上のプロセッサを搭載していると、パスのタイムアウトとそれに引き続くノードパニックが発生する場合がある。

回避方法: ce ドライバに ce_taskq_disable パラメータを設定する必要があります。すべてのクラスタノード上の /etc/system ファイルに set ce:ce_taskq_disable=1 という行を追加し、続いてそれらのクラスタノードを再起動してください。これによりハートビート (およびその他のパケット) が常に割り込みコンテキストで配布され、パスのタイムアウトと後続のノードパニックが防止されます。クラスタノードを再起動する間は、定足数に関連するメッセージに注意してください。

`scrgadm` により、NIC 上への別のサブネットの IP アドレスの配置が拒否される (4751406)

問題の概要:scrgadm は、IPMP (NAFO) グループのサブネットとは別のサブネットに所属する論理ホスト名/共有アドレスのホスティングを許可しない。

回避方法: 次の形式の scrgadm コマンドを使用します。

scrgadm -a -j <resource> -t <resource_type> -g <resource_group> -x HostnameList=<logical_hostname> -x NetIfList=<nafogroup>@<nodeid>.

NetIfList には、ノード名ではなくノード ID を指定します。

フェイルオーバーが失敗するとエラーが発生する (4766781)

問題の概要:ファイルシステムのフェイルオーバーまたはスイッチオーバーが失敗すると、そのファイルシステムがエラー状態になることがある。

回避方法: ファイルシステムのマウントを解除して、マウントし直します。

スイッチオーバーが進行している間に再起動を行うと、その後ノードがハングアップする (4806621)

問題の概要:ノードがクラスタに追加される際にデバイスグループのスイッチオーバーが進行していると、追加されるノードとスイッチオーバー処理がハングアップする可能性がある。また、デバイスサービスに対するアクセスも停止する。この状況は、ノードが 3 つ以上存在し、デバイス上にマウントされたファイルシステムのタイプが VxFS であるというクラスタで発生しやすい。

回避方法: この状況を防止するには、ノードがクラスタに追加される間にデバイスグループのスイッチオーバーを開始しないようにしてください。この状況が発生した場合は、デバイスグループに対するアクセスを復旧させるためにすべてのクラスタノードを再起動する必要があります。

既存の DNS 構成が提供されない場合、DNS ウィザードが正常に動作しない (4839993)

問題の概要:SunPlex Manager には、クラスタ上で高可用性 DNS サービスを設定するデータサービスインストールウィザードが付属している。ユーザーが既存の DNS 構成 (named.conf ファイルなど) を指定しないと、ウィザードは既存のネットワークおよびネームサービス構成を自動検出して、有効な DNS 構成を生成しようとする。ところが、ネットワーク環境によってはこの処理が行われず、ウィザードがエラーメッセージなしでエラー状態になる。

回避方法: SunPlex Manager DNS データサービスインストールウィザードでプロンプトが表示されたなら、既存の有効な named.conf ファイルを指定してください。クラスタ上で高可用性 DNS を手動構成することもできます。この場合は、文書化された DNS データサービスの手順に従ってください。

Oracle サービスのインストールに SunPlex Manager を使用できない (4843605)

問題の概要:SunPlex Manager には、Oracle バイナリのインストールおよび構成、ならびにクラスタ構成の作成によってクラスタ上に高可用性 Oracle サービスを設定するデータサービスインストールウィザードが付属している。しかし、このウィザードは現在機能していない。このため、ユーザーのソフトウェア構成によって、さまざまなエラーが発生する。

回避方法: クラスタ上での Oracle データサービスのインストールおよび構成は、手動で行います。手順は、Sun Cluster のマニュアルに記載されています。

停止または再起動に失敗する (4844784)

問題の概要:ノードの停止や再起動時に、ノードがハングして、停止または再起動のプロセスを完了できなくなることがある。システムは次のメッセージを発行してハングする。 Failfast: Halting because all userland daemons all have died.

回避方法: ノードの停止または再起動の前に次のコマンドを実行します。 psradm -f -a :

ノードを停止する場合:

# scswitch -S -h <node>
# psradm -f -a
# shutdown -g0 -y -i0

ノードを再起動する場合:

# scswitch -S -h <node>
# psradm -f -a
# shutdown -g0 -y -i6

注 –

まれに、上記の回避方法では問題を解決できないことがあります。

ノードの再起動 (4862321)

問題の概要:Sun Cluster 3.x を実行している大規模なシステムでは、ノード停止コマンド shutdown -g0 -y -i6 で再起動が行われず、OK プロンプトに続いて Failfast: Halting because all userland daemons have died というメッセージが表示されることがある。

回避方法: 次に示す回避方法のどれか 1 つを選択してください。

ノードを停止し、ok プロンプトに続いて boot と入力します。

ノードの停止前に failfasts を無効にします。

# /usr/cluster/lib/sc/cmm_ctl -f

# shutdown -g0 -y -i6

ノードが再起動したなら failfasts を有効にします。

# /usr/cluster/lib/sc/cmm_ctl -f

または、システムを停止する前に、次の mdb コマンドを使用して failfast_panic_delay タイムアウト値を大きくします。

(echo 'cl_comm`conf+8/W 0t600000' ;

echo 'cl_comm`conf+c/W 0t600000') | mdb -kw

この例では、タイムアウト値が 600000 ミリ秒 (10 分) に設定されます。

ノードの停止後も Oracle DLM プロセスが終了しない (4891227)

問題の概要:停止時に Oracle DLM プロセスが終了せず、/var をマウント解除できなくなることがある。

回避方法: 次に示す回避方法のどちらかを選択します。

/var パーティションを分割しない

init や shutdown ではなく reboot/halt を使用する

負荷の高いシステムで、Oracle リスナープローブがタイムアウトになる (4900140)

問題の概要:負荷の高いシステムでは、Oracle リスナープローブがタイムアウトになり、Oracle リスナーの再起動が行われることがある。

回避方法: 負荷の高いシステムでは、リソースの Thorough_probe_interval プロパティの値を大きくして、Oracle リスナーのリソースプローブのタイムアウトを防ぎます。

プローブのタイムアウトは、次のようにして計算します。

Thorough_probe_interval が 20 秒より大きい場合は 10 秒

Thorough_probe_interval が 120 秒より大きい場合は 60 秒

その他の場合は Thorough_probe_interval/2

リソースグループプロパティ `RG_system` の更新後、ノードパニックが発生する (4902066)

問題の概要:RG_system リソースグループプロパティの値を TRUE に設定すると、リソースグループとそのリソースがクラスタインフラストラクチャのサポートに使用され、ユーザーデータサービスは実装されない。RG_system の値が TRUE の場合、RGM は、システム管理者が誤ってリソースグループやそのリソースをオフラインにしたり、これらのプロパティの変更を防止する。場合によっては、RG_system プロパティの値を TRUE にしてリソースグループプロパティを変更しようとするとノードパニックが発生することがある。

回避方法: RG_system リソースグループプロパティの値は変更しないでください。

`passwd` の `nsswitch.conf` 要件により、`nis` が使用不能になる (4904975)

問題の概要:liveCache リソースのマスターになることができるノードでは、パブリックネットの停止時に su コマンドがハングすることがある。

回避方法: liveCache リソースのマスターになることができる各ノードで、/etc/nsswitch.conf ファイルに次の変更を加えることをお勧めします。この変更により、パブリックネットの停止時も、su コマンドがハングしなくなります。

passwd: files nis [TRYAGAIN=0]

Oracle/Apache 用データサービスインストールウィザードでは Solaris 9 以上がサポートされない (4906470)

問題の概要:Apache、Oracle 用の SunPlex Manager データサービスインストールウィザードは、Solaris 9 以上をサポートしない。

回避方法: Sun Cluster のマニュアルを参考に、クラスタ上に Oracle を手動でインストールします。Solaris 9 以上に Apache をインストールする場合は、インストールウィザードを実行する前に、Solaris Apache パッケージ SUNWapchr および SUNWapchu を手動で追加します。

デフォルトドメインが設定されていないとインストールが失敗する (4913925)

問題の概要:インストールおよび構成時にクラスタにノードを追加すると、次のような「RPC 認証」エラーが発生することがある。

“RPC authentication error”
“Not authorized to communicate with <sponsor-node>”
“Cluster name verification failed”

このエラーは、ノードが NIS/NIS+ を使用する構成になっていない場合、特にファイル /etc/defaultdomain が存在しない場合に発生する。

回避方法: ドメイン名が設定されていない (/etc/defaultdomain ファイルが見つからない) ときは、インストールを続行する前に domainname(1M) コマンドを実行して、クラスタに接続しているすべてのノード上でドメイン名を設定します。たとえば、# domainname xxx のように入力します。