以下の手順を実行して、Sun Cluster のアップグレードを終了します。Solaris 10 OS では、すべての手順は大域ゾーンからのみ実行してください。 最初に、アップグレードにより新しいバージョンを受け取るすべてのリソースタイプを登録します。2 番目にリソースが使用する新しいバージョンのリソースタイプを使用する該当リソースを変更します。3 番目に、リソースを再度有効にします。最後に、リソースグループをオンラインに戻します。
「Sun Cluster 3.2 ソフトウェアのアップグレードを確認する」の手順が完了したことを確認します。
共通エージェントコンテナ のセキュリティファイルをすべてのクラスタにコピーします。
この手順により、すべてのクラスタノード上で共通エージェントコンテナのセキュリティファイルが同一であり、コピーされたファイルが正しいファイル許可を保持していることが保証されます。
各ノードで、Sun Java Web Console エージェントを停止します。
phys-schost# /usr/sbin/smcwebserver stop |
各ノードで、セキュリティーファイルエージェントを停止します。
phys-schost# /usr/sbin/cacaoadm stop |
1 つのノードで、/etc/cacao/instances/default/ ディレクトリに移動します。
phys-schost-1# cd /etc/cacao/instances/default/ |
/etc/cacao/SUNWcacao/security/ ディレクトリの tar ファイルを作成します。
phys-schost-1# tar cf /tmp/SECURITY.tar security |
/tmp/SECURITY.tar ファイルを、その他の各クラスタノードにコピーします。
/tmp/SECURITY.tar ファイルのコピー先である各ノードで、セキュリティファイルを抽出します。
すでに /etc/cacao/instances/default/ ディレクトリにあるセキュリティファイルは、上書きされます。
phys-schost-2# cd /etc/cacao/instances/default/ phys-schost-2# tar xf /tmp/SECURITY.tar |
クラスタの各ノードから /tmp/SECURITY.tar ファイルを削除します。
セキュリティリスクを回避するため、tar ファイルの各コピーは削除する必要があります。
phys-schost-1# rm /tmp/SECURITY.tar phys-schost-2# rm /tmp/SECURITY.tar |
各ノードで、セキュリティーファイルエージェントを起動します。
phys-schost# /usr/sbin/cacaoadm start |
各ノードで、Sun Java Web Console エージェントを起動します。
phys-schost# /usr/sbin/smcwebserver start |
製品メディアで提供されていないデータサービスをアップグレードした場合、それらのデータサービスの新しいリソースタイプを登録します。
Sun Cluster HA for SAP liveCache を Sun Cluster 3.0 または 3.1 バージョンから Sun Cluster 3.2 バージョンにアップグレードした場合は、/opt/SUNWsclc/livecache/bin/lccluster 構成ファイルを変更してください。
liveCache リソースをホストするノードでスーパーユーザーになります。
新しい /opt/SUNWsclc/livecache/bin/lccluster ファイルを /sapdb/LC_NAME/db/sap/ ディレクトリにコピーします。
データサービスの以前の構成からすでにある lccluster ファイルを上書きします。
この /sapdb/LC_NAME/db/sap/lccluster ファイルを、『Sun Cluster Data Service for SAP liveCache Guide for Solaris OS』の「How to Register and Configure Sun Cluster HA for SAP liveCache」で説明されているように構成します。
Solaris OS のアップグレードを行い、使用中の構成で Solaris ボリュームマネージャー ソフトウェアに二重列メディエータを使用している場合、メディエータ構成を復元します。
メディエータホストの追加先のディスクセットの所有権を持つノードを指定します。
phys-schost# metaset -s setname |
ディスクセット名を指定します。
ディスクセットをマスターしているか、マスターする予定のノードで、スーパーユーザーになります。
どのノードも所有権を持っていない場合は、ディスクセットの所有権を取得します。
phys-schost# cldevicegroup switch -n node devicegroup |
ディスクセットの主となるノードの名前を指定します。
ディスクセットの名前を指定します。
メディエータを再作成します。
phys-schost# metaset -s setname -a -m mediator-host-list |
ディスクセットに追加します。
追加するノードの名前をディスクセットのメディエータホストとして指定します。
メディエータを使用するクラスタ内の各ディスクセットに対して、上記の手順を繰り返します。
リソースを新しいリソースタイプバージョンに移行します。
すべてのリソースを Sun Cluster 3.2 リソースタイプバージョンに移行する必要があります。
Sun Cluster HA for SAP Web Application Server の場合、J2EE エンジンリソース、Web アプリケーションサーバコンポーネントのリソース、またはその両方を使用している場合は、リソースを削除して、新しい Web アプリケーションサーバコンポーネントのリソースでもう一度作成する必要があります。新しいWeb アプリケーションサーバコンポーネントのリソースの変更には、J2EE 機能の統合が含まれます。詳細は、『Sun Cluster Data Service for SAP Web Application Server Guide for Solaris OS』を参照してください。
コマンド行を使用する手順を含む『Sun Cluster データサービスの計画と管理 (Solaris OS 版)』の「リソースタイプの更新」を参照してください。代わりに、clsetup ユーティリティの「リソースグループ」メニューを使用して同じ作業を実行することもできます。このプロセスには、次の作業が含まれます。
新しいリソースタイプの登録。
該当リソースの新しいバージョンのリソースタイプへの移行。
『Sun Cluster 3.2 ご使用にあたって (Solaris OS 版)』で指定されたリソースタイプの拡張プロパティーの変更。
Sun Cluster 3.2 リリースでは、Retry_interval プロパティーなどの一部の拡張プロパティー用に新しいデフォルト値が導入されています。この変更は、これらのプロパティーのデフォルト値を使用する既存のリソースの動作に影響します。以前のリソースのデフォルト値が必要な場合は、移行したリソースを変更して、プロパティーを以前のデフォルト値に設定してください。
クラスタで Sun Cluster HA for Sun Java System Application Server EE (HADB) データサービスを実行していて、デュアルパーティションアップグレードを開始する前に HADB データベースを停止した場合は、リソースを再び有効にして、データベースを起動します。
phys-schost# clresource enable hadb-resource phys-schost# hadbm start database-name |
詳細は、hadbm(1m) のマニュアルページを参照してください。
Solaris 10 OS にアップグレードして、Apache httpd.conf ファイルがクラスタファイルシステムにある場合は、Apache 制御スクリプトの HTTPD エントリがまだその位置を指していることを確認します。
/usr/apache/bin/apchectl ファイルの HTTPD エントリを表示します。
次の例は、/global クラスタファイルシステムにある httpd.conf ファイルを示しています。
phys-schost# cat /usr/apache/bin/apchectl | grep HTTPD=/usr HTTPD="/usr/apache/bin/httpd -f /global/web/conf/httpd.conf" |
ファイルに正しい HTTPD エントリが表示されない場合は、ファイルを更新してください。
phys-schost# vi /usr/apache/bin/apchectl #HTTPD=/usr/apache/bin/httpd HTTPD="/usr/apache/bin/httpd -f /global/web/conf/httpd.conf" |
任意のノードから clsetup ユーティリティーを開始します。
phys-schost# clsetup |
clsetup のメインメニューが表示されます。
すべての無効リソースを再度有効にします。
リソースグループのオプションに対応する番号を入力し、Return キーを押します。
リソースグループメニューが表示されます。
「リソースを有効化または無効化」というオプションに対応する番号を入力し、Return キーを押します。
有効にするリソースを選択し、プロンプトの指示に従います。
無効な各リソースで手順 c を繰り返します。
すべてのリソースが再び有効になったら、 q を入力して「リソースグループメニュー」に戻ります。
各リソースグループをオンラインに戻します。
この手順には、非大域ゾーンのリソースグループをオンラインにする手順も含まれます。
すべてのリソースグループがオンラインに戻ったら、clsetup ユーティリティーを終了します。
q を入力して各サブメニューを取り消すか、Ctrl-C を押してください。
アップグレードする前に、監視対象のすべてのディスクパスにエラーが発生した場合の自動ノード再起動を有効にした場合、この機能がまだ有効になっていることを確認します。
また、初めて自動再起動を設定する場合もこの作業を実行します。
自動再起動機能が有効になっているか無効になっているかを確認します。
phys-schost# clnode show |
自動リブート機能を有効にします。
phys-schost# clnode set -p reboot_on_path_failure=enabled |
設定するプロパティーを指定します。
クラスタ内の異なるノードから 1 つ以上のディスクにアクセスできる場合、監視されているすべてのディスクパスで障害が発生するとノードが再起動するように指定します。
ディスクパスの障害発生時の自動リブートが有効になっていることを確認します。
phys-schost# clnode show === Cluster Nodes === Node Name: node … reboot_on_path_failure: enabled … |
(省略可能) あとで参考にするために、ディスクのパーティション分割情報をとっておきます。
phys-schost# prtvtoc /dev/rdsk/cNtXdYsZ > filename |
このファイルをクラスタ外の場所に保存します。ディスク構成を変更する場合は、このコマンドをもう一度実行して、変更した構成をキャプチャします。ディスクに障害が発生し、交換が必要な場合は、この上方を使用してディスクパーティション構成を復元できます。詳細は、prtvtoc(1M) のマニュアルページを参照してください。
(省略可能) クラスタ構成のバックアップを取ります。
クラスタ構成のバックアップを保存しておけば、クラスタ構成の回復がより簡単になります。
詳細は、『Sun Cluster のシステム管理 (Solaris OS 版)』の「クラスタ構成をバックアップする」を参照してください。
リソースタイプの移行障害 - 通常、新しいリソースタイプへのリソースの移行は、リソースがオフラインのときに行います。しかし、一部のリソースはリソースタイプの移行を成功させるためにオンラインにする必要があります。この理由によってリソースタイプの移行が失敗すると、次のようなエラーメッセージが表示されます。
phys-schost - Resource depends on a SUNW.HAStoragePlus type resource that is not online anywhere. (C189917) VALIDATE on resource nfsrs, resource group rg, exited with non-zero exit status. (C720144) Validation of resource nfsrs in resource group rg on node phys-schost failed.
リソースがオフラインであるためにリソースタイプの移行が失敗する場合は、clsetup ユーティリティーを使用して、リソースをもう一度有効にしてから、関連リソースグループをオンラインにしてください。その後、リソースの移行手順を繰り返します。
Java バイナリ位置の変更 - 共有コンポーネントのアップグレード中に Java バイナリの位置が変更された場合、cacaoadm start または smcwebserver start コマンドを実行しようとすると、次のようなエラーが表示される場合があります。
# /opt/SUNWcacao/bin/cacaoadm startNo suitable Java runtime found. Java 1.4.2_03 or higher is required.Jan 3 17:10:26 ppups3 cacao: No suitable Java runtime found. Java 1.4.2_03 or higher is required.Cannot locate all the dependencies
# smcwebserver start/usr/sbin/smcwebserver: /usr/jdk/jdk1.5.0_04/bin/java: not found
これらのエラーは、開始コマンドが Java バイナリの現在の位置を特定できないために生成されています。JAVA_HOME プロパティーはまだ前のバージョンの Java があったディレクトリを指していますが、前のバージョンはアップグレード中に削除されました。
この問題を修正するには、次の構成ファイルの JAVA_HOME の設定を現在の Java ディレクトリを使用するように変更します。
/etc/webconsole/console/config.properties/etc/opt/SUNWcacao/cacao.properties
SPARC ベースのシステムで、Sun Management Center を使用してクラスタを監視している場合は、「SPARC: Sun Management Center 用に Sun Cluster モジュールソフトウェアをアップグレードする 」に進んでください。
Sun Cluster Geographic Edition 3.2 ソフトウェアをインストールするか、アップグレードを完了する場合は、『Sun Cluster Geographic Edition のインストール』を参照してください。
それ以外の場合、クラスタのアップグレードは完了です。