アップグレードの完了
この節では、Sun Cluster 3.2 ソフトウェアのすべてのアップグレード方法の完了について説明します。
Sun Cluster 3.2 ソフトウェアのアップグレードを確認する
以下の手順を実行して、クラスタが Sun Cluster 3.2 ソフトウェアに正しくアップグレードされたことを確認します。Solaris 10 OS では、すべての手順は大域ゾーンからのみ実行してください。
注 –
この手順では、長い形式の Sun Cluster コマンドを紹介します。ほとんどのコマンドには、短い形式もあります。これらのコマンドは、コマンド名の形式以外は同一です。コマンドの一覧および短い形式については、『Sun Cluster のシステム管理 (Solaris OS 版)』の付録 A「Sun Cluster オブジェクト指向コマンド」を参照してください。
始める前に
アップグレードするすべてのクラスタノードで、すべてのアップグレード手順が完了していることを確認します。
-
各ノードで、スーパーユーザーになります。
-
アップグレードした各ノードで、Sun Cluster ソフトウェアのインストールレベルを表示します。
phys-schost# clnode show-rev -v
出力の最初の行は、どのバージョンの Sun Cluster ソフトウェアでノードが動作しているかを示します。このバージョンはアップグレードするバージョンと一致していなければなりません。
-
任意のノードから、アップグレードしたクラスタノードがすべてクラスタモード (Online) で動作していることを確認します。
phys-schost# clnode status
-
SPARC: Solaris 8 から Solaris 9 ソフトウェアにアップグレードした場合は、ストレージ構成の整合性を確認してください。
-
各ノード上で、次のコマンドを実行して、ストレージ構成の整合性を確認します。
phys-schost# cldevice check
注意 – 構成がこの整合性検査を通過するまで、手順 bに進まないでください。この検査を通らないと、デバイスの識別でエラーが生じ、データの破損を引き起こす可能性があります。
次の表は、cldevice check コマンドからの出力と、必要な対処がある場合は、その対処を示しています。
メッセージの例
アクション
device id for 'phys-schost-1:/dev/rdsk/c1t3d0' does not match physical device's id, device may have been replaced
「不完全なアップグレードからの回復」に進んで、適切な修復手順を実行してください。
device id for 'phys-schost-1:/dev/rdsk/c0t0d0' needs to be updated, run cldevice repair to update
なしこのデバイス ID は手順 b で更新します。
出力メッセージなし
なし
詳細については、cldevice(1CL) のマニュアルページを参照してください。
-
各ノードで、Sun Cluster ストレージデータベースを Solaris 9 デバイス ID に移行します。
phys-schost# cldevice repair
-
各ノード上で、次のコマンドを実行して、ストレージデータベースの Solaris 9 への移行が成功したことを確認します。
phys-schost# cldevice check
-
cldevice コマンドでメッセージが表示された場合は、手順 a に戻って、ストレージ構成またはストレージデータベースにさらに修正を加えます。
-
cldevice コマンドでメッセージが表示されなければ、デバイス ID への移行に成功しています。すべてのクラスタノードでデバイス ID の移行が確認されたら、「Sun Cluster 3.2 ソフトウェアへのアップグレードを終了する」に進みます。
-
-
例 8–2 Sun Cluster 3.2 ソフトウェアへのアップグレードの確認
次の例は、2 ノードクラスタの Sun Cluster 3.2 ソフトウェアへのアップグレードを確認するために使用するコマンドを示しています。クラスタノード名は、phys-schost-1 と phys-schost-2 です。
phys-schost# clnode show-rev -v 3.2 … phys-schost# clnode status === Cluster Nodes === --- Node Status --- Node Name Status --------- ------ phys-schost-1 Online phys-schost-2 Online |
次の手順
「Sun Cluster 3.2 ソフトウェアへのアップグレードを終了する」に進みます。
Sun Cluster 3.2 ソフトウェアへのアップグレードを終了する
以下の手順を実行して、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
- -s setname
-
ディスクセット名を指定します。
-
ディスクセットをマスターしているか、マスターする予定のノードで、スーパーユーザーになります。
-
どのノードも所有権を持っていない場合は、ディスクセットの所有権を取得します。
phys-schost# cldevicegroup switch -n node devicegroup
- node
-
ディスクセットの主となるノードの名前を指定します。
- devicegroup
-
ディスクセットの名前を指定します。
-
メディエータを再作成します。
phys-schost# metaset -s setname -a -m mediator-host-list
- -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
- -p
-
設定するプロパティーを指定します。
- reboot_on_path_failure=enable
-
クラスタ内の異なるノードから 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 のインストール』を参照してください。
それ以外の場合、クラスタのアップグレードは完了です。
- © 2010, Oracle Corporation and/or its affiliates