次に示す既知の問題とバグは、Sun Cluster 3.2 リリースの処理に影響を与えます。バグおよび問題は次のカテゴリに分類しています。
問題の概要: -clnode remove --force コマンドはメタセットからノードを削除するべきですが、できません。『Sun Cluster のシステム管理 (Solaris OS 版)』 には、クラスタからノードを削除するための手順が記載されています。これらの手順は、clnode remove を実行する前に、 metaset コマンドを実行して Solaris ボリュームマネージャーディスクセットを削除する方法を説明しています。
対処方法: 手順に従わなかった場合は、通常の方法で CCR から無効なノードデータをクリアしなければならない場合があります。アクティブなクラスタノードから、 metaset コマンドを使用して Solaris ボリュームマネージャーディスクセットからノードをクリアします。続いて clnode clear --force obsolete_nodename を実行します。
問題の概要: Solaris 10 End User ソフトウェアグループの SUNWCuser を使用してインストールされたクラスタで、scsnapshot コマンドを実行すると、次のエラーが表示されて失敗する場合があります。
# scsnapshot -o … /usr/cluster/bin/scsnapshot[228]: /usr/perl5/5.6.1/bin/perl: not found |
対処方法: 次のいずれかを行います。
Solaris Entire Distribution ソフトウェアグループをインストールする。
Perl パッケージ SUNWpl5u、SUNWpl5v、SUNWpl5p をインストールする。
問題の概要: 共有アドレスリソースの Auxnodelist プロパティーは、共有アドレスリソースの作成時には使用できません。これは、この共有アドレスネットワークリソースに依存するスケーラブルリソースの作成時に、検証エラーと SEGV を引き起こします。スケーラブルリソースの検証エラーメッセージは次の形式です。
Method methodname (scalable svc) on resource resourcename stopped or terminated due to receipt of signal 11 |
また、ssm_wrapper からコアファイルが生成されます。ユーザーは Auxnodelist プロパティーを設定できないため、共有アドレスをホストできてもプライマリとしては機能しないクラスタノードを識別できません。
対処方法: あるノード上で、Auxnodelist プロパティーを指定せずに共有アドレスリソースを再度作成します。続いてスケーラブルリソースの作成コマンドを再度実行し、ネットワークリソースとしてユーザーが再度作成した共有アドレスリソースを使用します。
問題の概要: 定足数サーバーコマンド clquorumserver は、次の再起動用の起動メカニズムの状態を正しく設定しません。
対処方法: 次の作業を実行して定足数サーバーソフトウェアを起動または停止します。
quorumserver サービスの状態を表示します。
# svcs -a | grep quorumserver |
サービスが無効である場合、出力は次のような形式になります。
disabled 3:33:45 svc:/system/cluster/quorumserver:default |
定足数サーバーソフトウェアを起動します。
quorumserver サービスが disabled の場合、svcadm enable コマンドを使用します。
# svcadm enable svc:/system/cluster/quorumserver:default |
quorumserver サービスが online の場合、clquorumserver コマンドを使用します。
# clquorumserver start + |
quorumserver サービスを無効にします。
# svcadm disable svc:/system/cluster/quorumserver:default |
定足数サーバーソフトウェアを起動します。
# clquorumserver start + |
/etc/rc2.d/.S99quorumserver ファイルを /etc/rc2.d/S99quorumserver に名前変更します。
# mv /etc/rc2.d/.S99quorumserver /etc/rc2.d/S99quorumserver |
定足数サーバーソフトウェアを停止します。
# clquorumserver stop + |
定足数サーバーソフトウェアを起動します。
# mv /etc/rc2.d/S99quorumserver /etc/rc2.d/.S99quorumserver |
問題の概要: Sun Cluster HA for Application Server でノードエージェント (NA) リソースを作成する場合、DAS リソースに対する依存関係が設定されていなくてもリソースは作成されます。NA リソースを起動するには、DAS リソースがオンラインになっている必要があるため、依存関係が設定されていない場合、コマンドはエラーになる必要があります。
対処方法: NA リソースの作成時には、DAS リソースに対するリソースの依存関係を必ず設定してください。
問題の概要: HA MySQL パッチは、mysql_config ファイル内に MYSQL_DATADIR という新しい変数を追加します。この新しい変数は、MySQL 構成ファイルの my.conf ファイルが保存されているディレクトリを指す必要があります。変数が正しく構成されていない場合、mysql_register でのデータベースの準備に失敗します。
対処方法: MYSQL_DATADIR 変数が、MySQL 構成ファイルの my.conf が保存されているディレクトリを指すようにします。
問題の概要: InfiniBand がクラスタトランスポートとして使用され、アダプタごとに 2 つのポートを持つ各ノード上に 2 つのアダプタがあり、さらに合計 2 つのスイッチがある場合、scinstall ユーティリティーのアダプタ自動検出は、同じアダプタを使用する 2 つのトランスポートパスを提示する可能性があります。
対処方法: 各ノード上でトランスポートアダプタを手動で指定します。
問題の概要: IPv6 スケーラブルサービスパケットの転送に必要な、インターコネクト上の IPv6 の plumb はデフォルトでは有効になっていません。ifconfig コマンドを使用する際に確認される IPv6 インタフェースは、デフォルトではインターコネクトアダプタ上で plumb されません。
対処方法: 手動で IPv6 スケーラブルサービスサポートを有効にします。
IPv6 サービスを実行するためにすべてのクラスタノードを準備したことを確認します。この作業には、ネットワークインタフェース、サーバー/クライアントアプリケーションソフトウェア、ネームサービス、およびルーティングインフラストラクチャーの適切な構成が含まれます。適切に構成しないと、ネットワークアプリケーションの予期せぬ障害が発生する場合があります。詳細は、IPv6 サービスに関する Solaris システム管理のマニュアルを参照してください。
各ノード上で次のエントリを /etc/system ファイルに追加します。
set cl_comm:ifk_disable_v6=0 |
各ノード上で、インターコネクトアダプタに対する IPv6 の plumb を有効にします。
# /usr/cluster/lib/sc/config_ipv6 |
config_ipv6 ユーティリティーは、リンクローカルアドレスを持つすべてのクラスタインターコネクトアダプタ上で IPv6 インタフェースを起動します。このユーティリティーは、インターコネクト上での IPv6 スケーラブルサービスパケットの適切な転送を有効にします。
また、各クラスタノードを再起動して構成の変更を有効にすることもできます。
問題の概要: 直接接続トランスポートを使用している XML ファイルを使用して clnode add コマンドが試行された場合、コマンドはケーブル情報を誤って解釈し、間違った構成情報を追加します。その結果、接続しているノードはクラスタに接続できません。
対処方法: クラスタトランスポートが直接接続されている場合は、scinstall コマンドを使用してノードをクラスタに追加します。
問題の概要: scinstall コマンドは /etc/nsswitch.conf ファイルを更新して、hosts および netmasks データベースの cluster エントリを追加します。この変更は、大域ゾーンの /net/nsswitch.conf ファイルを更新します。ただし、非大域ゾーンの作成およびインストール時には、非大域ゾーンは元の /etc/nsswitch.conf ファイルのコピーを受け取ります。非大域ゾーン上の /etc/nsswitch.conf ファイルには、hosts および netmasks データベースの cluster エントリはありません。getXbyY クエリーを使用して非大域ゾーン内部からクラスタ固有のプライベートホスト名および IP アドレスを解決する試みは、すべて失敗します。
対処方法: 非大域ゾーンの /etc/nsswitch.conf ファイルで、hosts および netmasks データベースの cluster エントリを手動で更新します。これによって、クラスタ固有のプライベートホスト名と IP アドレスの解決は、非大域ゾーン内でも使用できるようになります。
問題の概要: 定足数サーバー管理プログラム (clquorumserver など) 用に翻訳されたメッセージは、コアのローカライズパッケージの一部として提供されています。その結果、定足数サーバーのメッセー ジが英語で表示されます。定足数サーバーのローカライズパッケージは、本来コアローカライズパッケージとは別に提供され、定足数サーバーシステムにインストールする必要があります。
対処方法: 定足数サーバーソフトウェアがインストールされているホストに、次のパッケージをインストールします。
SUNWcsc (簡体中国語)
SUNWdsc (ドイツ語)
SUNWesc (スペイン語)
SUNWfsc (フランス語)
SUNWhsc (繁体中国語)
SUNWjsc (日本語)
SUNWksc (韓国語)
定足数サーバーで日本語のマニュアルページが必要である場合は、SUNWjscman (日本語マニュアルページ) パッケージをインストールします。
問題の概要: Sun Cluster 3.2 インストーラは、ソフトウェアの Sun Cluster 3.2 簡体中国語バージョンをインストールする際に、スワップ不足に関する警告メッセージを表示します。システム要件の確認画面で、インストーラは 0.0K バイトのサイズの正しくないスワップサイズを表示します。
対処方法: スワップサイズがシステム要件より大きい場合は、この問題を無視してもかまいません。C、つまり英語ロケールの SC 3.2 インストーラをインストールに使用できます。C ロケールではスワップサイズを正確に確認します。
問題の概要: 実行時リンク環境に /sapmnt/SAPSID/exe パスが含まれていない場合、cleanipc は失敗します。
対処方法: Solaris ルートユーザーとして、/sapmnt/SAPSID/exe パスを ld.config ファイルのデフォルトライブラリに追加します。
32 ビットアプリケーション向けに実行時リンク環境のデフォルトライブラリパスを構成するには、次のコマンドを入力します。
# crle -u -l /sapmnt/SAPSID/exe |
64 ビットアプリケーション向けに実行時リンク環境のデフォルトライブラリパスを構成するには、次のコマンドを入力します。
# crle -64 -u -l /sapmnt/SAPSID/exe |
問題の概要: クラスタ停止の実行時に、ノードの 1 つが UCMMD よりもわずかに早くクラスタから離脱した場合、1 つまたは複数のノード上で UCMMD は再構成に移行する可能性があります。このような場合、UCMMD がリターンステップを実行しようとする間に、シャットダウンによりノード上で rpc.md コマンドが停止します。リターンステップでは、metaclust コマンドは RPC タイムアウトになり、rpc.mdcommd プロセスが見つからないため、エラーによりステップを終了します。このエラーが原因で UCMMD はノードを中止し、ノードがパニックになる場合があります。
対処方法: この問題は無視してもかまいません。ノードがバックアップを起動した場合、以前の再構成でエラーが発生したこととは関係なく、Sun Cluster ソフトウェアはこの状態を検出し、UCMMD の起動を許可します。
問題の概要: Sun Cluster リソース検証は、論理ホスト名または共有アドレスリソースの作成時には、netiflist プロパティーの IPMP グループのホスト名を受け付けません。
対処方法: 論理ホスト名および共有アドレスリソースの作成時に IPMP グループ名を指定する場合は、ノード名の代わりにノード ID を使用してください。
問題の概要: この問題が生じるのは、元のディスクがルートでカプセル化され、Solaris 9 8/03 OS 上の VxVM 3.5 から Solaris 10 6/06 OS 上の VxVM 5.0 へのライブアップグレートが試行された場合です。vxlufinish スクリプトは次のエラーを表示して失敗します。
#./vslufinish -u 5.10 VERITAS Volume Manager VxVM 5.0 Live Upgrade finish on the Solairs release <5.10> Enter the name of the alternate root diskgroup: altrootdg ld.so.1: vxparms: fatal: libvxscsi.so: open failed: No such file or directory ld.so.1: vxparms: fatal: libvxscsi.so: open failed: No such file or directory Killed ld.so.1: ugettxt: fatal: libvxscsi.so: open failed: No such file or directory ERROR:vxlufinish Failed: /altroot.5.10/usr/lib/vxvm/bin/vxencap -d -C 10176 -c -p 5555 -g -g altrootdg rootdisk=c0t1d0s2 Please install, if 5.0 or higher version of VxVM is not installed on alternate bootdisk. |
対処方法: 代わりに、標準アップグレード、またはデュアルパーティションアップグレード方式を使用します。
今後 VxVM 5.0 用の Sun Cluster 3.2 ライブアップグレードが利用可能になるかどうかについては、Sun のサポートまたはご購入先にお問い合わせください。
問題の概要: ライブアップグレード時に lucreate および luupgrade コマンドが、/global/.devices/node@N エントリに対応する代替ブート環境内の DID 名の変更に失敗します。
対処方法: ライブアップグレードを開始する前に、各クラスタノードで次の手順を実行します。
スーパーユーザーとしてログインします。
/etc/vfstab ファイルをバックアップします。
# cp /etc/vfstab /etc/vfstab.old |
/etc/vfstab ファイルを編集するために開きます。
/global/.device/node@N に対応する行を見つけます。
グローバルデバイスエントリを編集します。
DID 名を物理名に変更します。
/dev/did/{r}dsk/dYsZ を /dev/{r}dsk/cNtXdYs Z に変更します。
global をエントリから削除します。
次の例は、物理デバイス名に変更され、global エントリが削除された、/global/.devices/node@s に対応する DID デバイス d3s3 の名前を示しています。
Original: /dev/did/dsk/d3s3 /dev/did/rdsk/d3s3 /global/.devices/node@2 ufs 2 no global Changed: dev/dsk/c0t0d0s3 /dev/rdsk/c0t0d0s3 /global/.devices/node@2 ufs 2 no - |
すべてのクラスタノードで /etc/vfstab ファイルが変更されたら、クラスタのライブアップグレードを実行しますが、アップグレードされた代替ブート環境から再起動する前に中止します。
アップグレードされていない現在のブート環境の各ノードで、元の /etc/vfstab ファイルを復元します。
# cp /etc/vstab.old /etc/vfstab |
代替ブート環境で、/etc/vfstab ファイルを開いて編集します。
/global/.devices/node@N に対応する行を見つけ、エントリ末尾のダッシュ (-) を global という単語で置き換えます。
/dev/dsk/cNtXdYsZ /dev/rdsk/cNtXdYsZ /global/.devices/node@N ufs 2 no global |
アップグレードされた代替ブート環境からノードを再起動します。
/etc/vfstab ファイル内の DID 名は、自動的に置き換えられます。
問題の概要: この問題は、Sun Cluster ライブアップグレード時に VERITAS Volume Manager (VxVM) をアップグレードする際に見られます。vxlustart スクリプトは、前のバージョンから Solaris OS と VxVM をアップグレードするために使用されます。スクリプトは次のようなエラーメッセージを表示して失敗します。
# ./vxlustart -u 5.10 -d c0t1d0 -s OSimage VERITAS Volume Manager VxVM 5.0. Live Upgrade is now upgrading from 5.9 to <5.10> … ERROR: Unable to copy file systems from boot environment <sorce.8876> to BE <dest.8876>. ERROR: Unable to populate file systems on boot environment <dest.8876>. ERROR: Cannot make file systems for boot environment <dest.8876>. ERROR: vxlustart: Failed: lucreate -c sorce.8876 -C /dev/dsk/c0t0d0s2 -m -:/dev/dsk/c0t1d0s1:swap -m /:/dev/dsk/c0t1d0s0:ufs -m /globaldevices:/dev/dsk/c0t1d0s3:ufs -m /mc_metadb:/dev/dsk/c0t1d0s7:ufs -m /space:/dev/dsk/c0t1d0s4:ufs -n dest.8876 |
対処方法: クラスタを VxVM 5.0 にアップグレードする場合は、標準アップグレードまたはデュアルパーティションアップグレード方式を使用します。
今後 VxVM 5.0 用の Sun Cluster 3.2 ライブアップグレードが利用可能になるかどうかについては、Sun のサポートまたはご購入先にお問い合わせください。
問題の概要: VERITAS Volume Manager (VxVM) を実行するクラスタでは、ルートディスクがカプセル化されている場合、次のいずれかのソフトウェアの標準アップグレードまたはデュアルパーティションアップグレードは失敗します。
Solaris OS の異なるバージョンへのアップグレード
VxVM のアップグレード
Sun Cluster ソフトウェアのアップグレード
クラスタノードはパニックになり、アップグレード後は起動できなくなります。これは、アップグレード時に VxVM により行われるメジャー番号またはマイナー番号の変更が原因です。
対処方法: アップグレードを開始する前にルートディスクのカプセル化を解除します。
上記の手順に正しく従わない場合、アップグレード中のすべてのノード上で予期せぬ深刻な問題が生じる場合があります。また、ルートディスクのカプセル化解除とカプセル化は、自動的に (毎回) ノードの追加の再起動の原因となるため、アップグレード時の必要な再起動の回数が多くなります。
問題の概要: Solaris 9 版の Sun Cluster Version 3.1 から Solaris 10 版の Sun Cluster Version 3.2 へライブアップグレードしたあと、クラスタソフトウェアでゾーンを正しく使用できません。問題は、Sun Cluster パッケージ用に pspool データが作成されないことです。このため、SUNWsczu のような、非大域ゾーンに伝播されるべきパッケージが正しく伝播されません。
対処方法: Sun Cluster パッケージが scinstall -R コマンドを使ってアップグレードされてから、クラスタがクラスタモードにブートされるまでの間に、後述のスクリプトを 2 回実行します。
Sun Cluster フレームワークパッケージ用に 1 回
Sun Cluster データサービスパッケージ用に 1 回
次のいずれかの方法で、このスクリプトを準備して実行します。
Sun Cluster フレームワークパッケージ用の変数を設定し、スクリプトを実行します。次に、データサービスパッケージ用の PATHNAME 変数を変更し、スクリプトを再実行します。
フレームワークパッケージ用に設定された変数を持つスクリプトと、データサービスパッケージ用に設定された変数を持つスクリプトを作成します。次に、両方のスクリプトを実行します。
スーパーユーザーとしてログインします。
次の内容のスクリプトを作成します。
#!/bin/ksh typeset PLATFORM=${PLATFORM:-`uname -p`} typeset PATHNAME=${PATHNAME:-/cdrom/cdrom0/Solaris_${PLATFORM}/Product/sun_cluster/Solaris_10/Packages} typeset BASEDIR=${BASEDIR:-/} cd $PATHNAME for i in * do if pkginfo -R ${BASEDIR} $i >/dev/null 2>&1 then mkdir -p ${BASEDIR}/var/sadm/pkg/$i/save/pspool pkgadd -d . -R ${BASEDIR} -s ${BASEDIR}/var/sadm/pkg/$i/save/pspool $i fi done
変数 PLATFORM、PATHNAME、および BASEDIR を設定します。
これらの変数を環境変数として設定するか、または直接スクリプト内の値を変更します。
プラットフォームの名前です。たとえば、sparc や x86 です。デフォルトで、PLATFORM 変数は uname -p コマンドの出力に設定されます。
Sun Cluster フレームワークまたはデータサービスパッケージをインストールできるデバイスへのパスです。この値は、pkgadd コマンドの -d オプションに対応します。
たとえば、Sun Cluster フレームワークパッケージの場合、この値は次のような形式になります。
/cdrom/cdrom0/Solaris_${PLATFORM}/Product/sun_cluster/Solaris_10/Packages |
データサービスパッケージの場合、この値は次のような形式になります。
/cdrom/cdrom0/Solaris_${PLATFORM}/Product/sun_cluster_agents/Solaris_10/Packages |
ルートパスとして使用し、pkgadd コマンドの -R オプションに対応する、ディレクトリのフルパス名です。ライブアップグレードの場合は、この値を、scinstall コマンドの -R オプションで使用されるルートパスに設定します。デフォルトで、BASEDIR 変数は、ルート (/) ファイルシステムに設定されます。
Sun Cluster フレームワークパッケージ用に 1 回、データサービスパッケージ用に 1 回、スクリプトを実行します。
スクリプトの実行後、各パッケージのコマンドプロンプトに次のメッセージが表示されます。
Transferring pkgname package instance |
パッケージ用の pspool ディレクトリがすでに存在する場合、またはスクリプトが同じパッケージセット用に 2 回実行された場合、次のエラーがコマンドプロンプトに表示されます。
Transferring pkgname package instance pkgadd: ERROR: unable to complete package transfer - identical version of pkgname already exists on destination device |
このメッセージは無害なので、無視しても問題ありません。
フレームワークパッケージとデータサービスパッケージの両方用にスクリプトを実行したあと、ノードをクラスタモードで起動します。
問題の概要: ノードが既存のクラスタノードと同じパッチを持っていることを確認せずに 新しいクラスタノードを追加すると、クラスタノードにパニックが発生する可能性があります。
対処方法: ノードをクラスタに追加する前に、新しいノードが既存のクラスタノードと同じレベルに最初にパッチ適用されていることを確認します。これを行わないと、クラスタノードにパニックが発生する可能性があります。