問題の概要: この問題が生じるのは、元のディスクがルートでカプセル化され、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 |
このメッセージは無害なので、無視しても問題ありません。
フレームワークパッケージとデータサービスパッケージの両方用にスクリプトを実行したあと、ノードをクラスタモードで起動します。
問題の概要: ノードが既存のクラスタノードと同じパッチを持っていることを確認せずに 新しいクラスタノードを追加すると、クラスタノードにパニックが発生する可能性があります。
対処方法: ノードをクラスタに追加する前に、新しいノードが既存のクラスタノードと同じレベルに最初にパッチ適用されていることを確認します。これを行わないと、クラスタノードにパニックが発生する可能性があります。