ローリング・アップグレードは,クラスタの稼働中にクラスタのソフトウェアをアップグレードする方法です。システムへのパッチの適用は,一種のアップグレードであり,この手順を使って実行できます。「ローリング・パッチ」という表現は,ローリング・アップグレードの手順でパッチを適用することを表すときによく使われます。この章では全般的に,ローリング・パッチとローリング・アップデートは同じ意味で使用しています。
ローリング・アップデートでは,クラスタ・メンバを一度に 1 つずつアップグレードして運用に戻し,複数のバージョンのベース・オペレーティング・システム,クラスタ,および各国語サポート (WLS) ソフトウェアが混在する環境を透過的に管理します。サービスにアクセスするクライアントからは,ローリング・アップグレードを実行していることがわかりません。
ローリング・アップグレードには段階と呼ばれる一連の手順があり,各段階を必ず一定の順序で実行する必要があります。ローリング・アップグレードを制御するコマンドが,この順序どおりに実行します。
ローリング・アップグレードの実行手順は,新しいオペレーティング・システム,あるいは新しいバージョンの TruCluster にアップグレードする目的でシステムにパッチを適用する場合と同じです。主な違いは,ローリング・パッチの場合はインストール段階で dupatch ユーティリティを使用するのに対し,ローリング・アップグレードの場合は installupdate ユーティリティを使用する点です。
この章の内容は,『クラスタ・インストレーション・ガイド』 マニュアルの「ローリング・アップグレード」の章と同じものです。1 つのマニュアルでパッチ・オプションの見直しができるように,利便性を考えてここで取り上げています。
この章の前半では,ローリング・アップグレードの実行,ローリング・アップグレードのステータス表示,およびローリング・アップグレードにおける段階の取り消し (複数段階可) について説明します。ローリング・アップグレードがどのように働くかについては,4-1-7 項 「ローリング・アップグレードのコマンド」およびそれに続く項で説明します。
この章で説明する内容は次のとおりです。
図 4-1 「ローリング・アップグレード作業の流れ」 は,Version 5.1B クラスタで開始するローリング・アップグレードの実行に必要な作業と段階を簡単なフロー・チャートにまとめたものです。
4-1-1 ローリング・アップグレードでサポートされている作業 |
 |
ローリング・アップグレードで行うことができる作業は,クラスタで現在実行しているベース・オペレーティング・システムとクラスタ・ソフトウェアのバージョンによって異なります。この章では主に,TruCluster software Version 5.1B クラスタで開始するローリング・アップグレードについて説明します。ただし,TruCluster software Version 5.1A からVersion 5.1B へローリング・アップグレードする準備をされている方のために,2 つのバージョンの間にあるローリング・アップグレードの違いについても示していきます。
ローリング・アップグレードで行うことができる基本的な作業は,次のとおりです。
クラスタの Tru64 UNIX ベース・オペレーティング・システムと TruCluster software のアップグレード。このタイプのローリング・アップグレードでは,インストールされているバージョンを次のバージョンへアップグレードします。
ベース・オペレーティング・システムとクラスタ・ソフトウェアをローリング・アップグレードする際は,あるバージョンからすぐ次のバージョンへローリングできるだけです。バージョンをスキップすることはできません。
クラスタで現在使用している Tru64 UNIX ベース・オペレーティング・システムと TruCluster softwareのパッチ。
NHD (New Hardware Delivery) キットのインストール (クラスタで TruCluster software Version 5.1A 以降が動作していることが必要)。
パッチ・キットまたは NHD キットによるローリングでは,ベース・オペレーティング・システムおよびクラスタ・ソフトウェアの新リリースによるローリングと同じ手順を使用します。違いは,インストール段階で実行するコマンドです。
ベース・オペレーティング・システムおよびクラスタ・ソフトウェアをアップグレードする場合は,インストール段階で installupdate コマンドを使用します。
パッチ・キットをロールする場合は,インストール段階で dupatch を実行します。インストール段階で,複数のパッチ・キットをロールするために dupatch を複数回実行することができます。
クラスタのノーロール・パッチを実行する場合は,clu_upgrade コマンドは実行せずに,dupatch コマンドをマルチユーザ・モードで起動しているクラスタ・メンバから実行します。
ノーロール・パッチはパッチを迅速に適用し,リブートの数を減らすことができます。ノーロール・パッチは 1 回の操作でクラスタにパッチをあてることができます。ただし,操作を完了するにはクラスタ全体をリブートする必要があるため,クラスタはその間利用することができません。
NHD キットをインストールするには,インストール段階で nhd_install を実行します。
この章では,ローリング・アップグレードという用語を,ソフトウェア・キットのロール手順全体を表す用語として使用しています。
図 4-1 「ローリング・アップグレード作業の流れ」 に示すように,1 回のローリング・アップグレードで複数の作業を行うことができます。
クラスタで Version 5.1A または Version 5.1B が動作している場合は,ローリング・アップグレードとして,表 4-1 「Version 5.1A および Version 5.1B で行えるローリング・アップグレード作業」 に示す作業を行うことができます。
表 4-1 Version 5.1A および Version 5.1B で行えるローリング・アップグレード作業
Version 5.1A から Version 5.1B へのアップデート・インストレーション Version 5.1B から次のリリースへのアップデート・インストレーション |
Version 5.1A パッチの適用 Version 5.1B パッチの適用 |
Version 5.1A クラスタへの NHD (New Hardware Delivery) キットのインストール
Version 5.1B クラスタへの NHD キットのインストール |
ベース・オペレーティング・システムおよびクラスタ・ソフトウェアのVersion 5.1A から Version 5.1B へのアップデート・インストレーションと,その後に行う Version 5.1B パッチの適用 ベース・オペレーティング・システムおよびクラスタ・ソフトウェアの Version 5.1B から次のリリースへのアップデート・インストレーションと,その後に行う次のリリースのパッチの適用[1] |
Version 5.1A のクラスタへの NHD インストレーションと,その後に行う Version 5.1A パッチの適用 Version 5.1B のクラスタへの NHD インストレーションと,その後に行う Version 5.1B パッチの適用 |
Version 5.1A からVersion 5.1B へのアップデート・インストレーションと,その後に行う Version 5.1B への NHD キットのインストレーション ベース・オペレーティング・システムとクラスタ・ソフトウェアのVersion 5.1B から次のリリースへのアップデート・インストレーションと,その後に行う次のリリースへの NHD キットのインストレーション[2] |
Version 5.1A から Version 5.1B へのアップデート・インストレーションと,その後に行う Version 5.1Bへの NHD キットのインストレーション,およびその後に行うVersion 5.1B パッチの適用 Version 5.1B から次のリリースへのアップデート・インストレーションと,その後に行う次のリリースへの NHD キットのインストレーション,およびその後に行う次のリリースのパッチの適用[2] |
4-1-2 ローリング・アップグレードでサポートされていない作業 |
 |
ローリング・アップグレード中に実行できない作業,または実行しないことを推奨する作業のリストを以下に示します。
/var/adm/update ディレクトリにあるファイルは削除も変更もしないでください。このディレクトリにあるファイルは,ロール処理にとって非常に重要です。削除するとローリング・アップグレードが失敗するおそれがあります。
インストール段階では,installupdate コマンドより先に dupatch コマンドを実行することはできません。ローリング・アップグレードを実行する前に現在のソフトウェアにパッチをあてるには,ローリング・アップグレード操作を 2 回 (現在のソフトウェアに対するパッチを 1 回とアップデート・インストレーションを 1 回) 実行する必要があります。
ベース・オペレーティング・システムとクラスタ・ソフトウェアをローリング・アップグレードする際は,バージョンをスキップできません。あるバージョンからすぐ次のバージョンへのローリングができるだけです。
以下のサブセットの追加または削除の際に,/usr/sbin/setld コマンドを使用しないでください。
ベース・オペレーティング・システム・サブセット (名前の先頭に OSF が付くもの)
TruCluster Server サブセット (名前の先頭に TCR が付くもの)
Worldwide Language Support (WLS) サブセット (名前の先頭に IOS が付くもの)
ロール中にこれらのサブセットを追加または削除すると,タグ付きファイルが一致しなくなります。
ロール中にレイヤード・プロダクトをインストールしないでください。
最初にロールするメンバに製品の新バージョンをインストールできること,および複数のバージョンが混在するクラスタでレイヤード・プロダクトが動作できることが,レイヤード・プロダクトのドキュメントに特記されていない場合は,新しいレイヤード・プロダクトまたは現在インストールされているレイヤード・プロダクトの新バージョンをローリング・アップグレード中にインストールしないでください。
レイヤード・プロダクトおよびローリング・アップグレードについての詳細は 4-1-11 項 「ローリング・アップグレードとレイヤード・プロダクト」を参照してください。
4-1-3 ローリング・アップグレードの手順 |
 |
この項の手順では,特に明記しない限りコマンドはマルチユーザ・モードで実行します。各段階の手順は,それぞれの対応する項で詳しく説明します。ローリング・アップグレードを実行する場合は,その前に 4-1-8 項 「ローリング・アップグレードの各段階」で各段階の詳しい説明を参照されることをお勧めします。
ローリング・アップグレードの段階の中には,他の段階よりも時間のかかるものがあります。表 4-2 「ローリング・アップグレードの各段階における所要時間」 に,各段階を完了するまでのおおよその所要時間をまとめています。
表 4-2 ローリング・アップグレードの各段階における所要時間
段階 | 所要時間 |
---|
準備 | プログラム制御ではない。 |
セットアップ | 45~120分。[1] |
プリ・インストール | 15~30 分。[1] |
インストール | 単一システムで installupdate,dupatch,nhd_install またはこれらのコマンドの有効な組み合わせを実行する時間。 |
ポスト・インストール | 1 分未満。 |
ロール (1 メンバあたり) | パッチ :5 分未満。 アップデート・インストレーション :メンバの追加にかかる時間とほぼ同じ。[2] |
スイッチ | 1 分未満。 |
クリーンアップ | 30~90 分。[1] |
以下の手順で,TruCluster software Version 5.1A クラスタをVersion 5.1B にアップグレードします。すでにVersion 5.1B になっているクラスタをアップグレードする場合も同じです。
ローリング・アップグレードを実行するために,次のようにクラスタを準備します (4-1-8-1 項 「準備段階」)。
先行メンバ (最初にロールするメンバ) として使用するクラスタ・メンバを選択します。この手順の例では,memberid が 2 のメンバを先行メンバとして使用します。メンバのホスト名は,provolone です。
クラスタのバックアップを取ります。
インストール段階でアップデート・インストレーションを実行する場合は,クラスタにインストールされている表 4-6 「ブロッキング・レイヤード・プロダクト」 のブロッキング・レイヤード・プロダクトを削除します。
任意のクラスタ・メンバで次のように clu_upgrade -v check setup lead_memberid コマンドを実行し,クラスタをアップグレードする準備ができているかどうかを確認します。たとえば,次のようになります。
# clu_upgrade -v check setup 2 |
ファイル・システムにより多くの空き容量が必要な場合は,addvol などの AdvFS Utilities を使用して,必要に応じてドメインにボリュームを追加します。必要なディスク・スペースについては,4-1-8-1 項 「準備段階」を参照してください。AdvFS ドメインの管理方法については,Tru64 UNIX 『AdvFS Administration』を参照してください
各システムのファームウェアが新しいソフトウェアをサポートしていることを確認します。必要があれば,ローリング・アップグレードを開始する前にファームウェアをアップデートします。
セットアップ段階を実行します (4-1-8-2 項 「セットアップ段階」)。
次の例のように,任意のメンバで clu_upgrade setup lead_memberid コマンドを実行します。たとえば,次のようになります。
clu_upgrade コマンドで表示されるメニューを 4-1-8-2 項 「セットアップ段階」 に示します。
セットアップ段階が完了すると,clu_upgrade はプロンプトを表示して,先行メンバ以外の全クラスタ・メンバのリブートを求めます。
先行メンバ以外のすべてのクラスタ・メンバを一度に 1 つずつリブートします。これらのメンバがリブートされるか停止されるまで,プリ・インストール段階を開始しないでください。
プリ・インストール段階を実行します (4-1-8-3 項 「プリ・インストール段階」)。
先行メンバで,次のコマンドを実行します。
現在のクラスタがバージョン 5.1A 以降である場合は,preinstall コマンドを実行するときに,セットアップ段階で作成されたタグ付きファイルがあるかどうかを,必要に応じて確認することができます。
セットアップ段階を完了したばかりで,タグ付きファイルを削除するような操作をまだ行っていない場合は,このテストを省略してもかまいません。
セットアップ段階を完了してから時間が経過して,どうすべきかがよくわからなくなった場合は,preinstall を実行して,タグ付きファイルが正しいかどうかをテストしてください。
インストール段階を実行します (4-1-8-4 項 「インストール段階」)。
dupatch コマンドを使ったパッチ・キットのインストール手順については,第3章 「パッチのインストールおよび削除手順」を参照してください。
installupdate コマンドの使用に関する詳細については,Tru64 UNIX 『インストレーション・ガイド』を参照してください。
nhd_install コマンドの使用方法については,NHD キットに添付されている Tru64 UNIX『New Hardware Delivery Release Notes and Installation Instructions』を参照してください。
インストールするソフトウェアが,シングルユーザ・モードでインストレーション・コマンドを実行しなければならないソフトウェアである場合は,次のようにして,システムを停止した後,シングルユーザ・モードでブートします。
# shutdown -h now
>>> boot -fl s
|
システムがシングルユーザ・モードになったら,次のコマンドを実行します。
# init s
# bcheckrc
# lmf reset |
installupdate,dupatch,または nhd_install を実行します。
複数のパッチ・キットをロールするには,1 回のインストール段階で dupatch コマンドを複数回実行します。ただし,パッチ処理が完了して,クラスタの使用中に問題が発生した場合,問題を特定することが難しくなる場合がありますので注意してください。
installupdate コマンドの前に dupatch コマンドを実行することはできません。ローリング・アップグレードを実行する前に現在のソフトウェアにパッチをあてるには,ローリング・アップグレード操作を 2 回 (現在のソフトウェアに対するパッチを 1 回とアップデート・インストレーションを 1 回) 実行する必要があります。
(オプション) 新しいカスタム・カーネルを使用して先行メンバを最終的にリブートしてから他のメンバをロールするまでの間に,次のテストを手動で実行することもできます。
ロール済みの先行メンバから共用ルート (/) ファイル・システムをサービスできることを確認します。
次のように cfsmgr コマンドを使用し,その時点でルート・ファイル・システムをサービスしているクラスタ・メンバを調べます。たとえば,次のようになります。
# cfsmgr -v -a server /
Domain or filesystem name = /
Server Name = polishham
Server Status : OK |
次のコマンドを実行して,ルート (/)・ファイル・システムを先行メンバに再配置します。たとえば,次のようになります。
# cfsmgr -h polishham -r -a SERVER=provolone / |
先行メンバからクライアントにアプリケーションをサービスできることを確認します。クラスタからクライアントへサービスするすべての重要なアプリケーションを先行メンバからサービスできることも確認します。
テストする内容と方法を決定します。次の例のように,ロールを続行する前に重要なアプリケーションをすべて検査して,先行メンバからクライアントにこれらのアプリケーションが正しくサービスされることを確認することをお勧めします。たとえば,次のようになります。
CAA サービスを先行メンバに手動で再配置します。たとえば,cluster_lockd という名前のアプリケーション・リソースを先行メンバ provolone に再配置するには,次のようにします。
# caa_relocate cluster_lockd -c provolone |
次のように,省略時のクラスタ別名に対する選択優先順位属性 selp を一時的に変更して,先行メンバがその別名宛てに送信された要求をすべてサービスするように強制します。たとえば,次のようになります。
# cluamgr -a alias=DEFAULTALIAS,selp=100 |
この操作で,省略時のクラスタ別名に宛てられた接続要求とパケットは,先行メンバが最終的にすべて受信するようになります。
他のメンバまたは他のクライアントから telnet や ftp などのサービスを使用して,先行メンバで別名宛の通信が処理されることを確認します。クラスタで提供する重要なサービスにクライアントからアクセスできるかどうかを検査します。
問題がない場合は,先行メンバで別名の属性を元の値に再設定します。
ポスト・インストール段階を実行します (4-1-8-5 項 「ポスト・インストール段階」)。
先行メンバで次のコマンドを実行します。
# clu_upgrade postinstall |
ロール段階を実行します (4-1-8-6 項 「ロール段階」)。
ロール前のクラスタ・メンバをロールします。[1]
ロールされていないメンバの数 (クォーラム・ディスクが構成されている場合はクォーラム・ディスクも含む) がクラスタ・クォーラムを維持するのに十分な場合,複数のメンバを同時にロールすることができます (並列ロール)。
メンバをロールするには,以下の手順を実行します。
次のようにして,メンバ・システムを停止させた後シングルユーザ・モードでブートします。たとえば,次のようになります。
# shutdown -h now
>>> boot -fl s |
システムがシングルユーザ・モードになったら,次のコマンドを実行します。
# init s
# bcheckrc
# lmf reset |
メンバをロールします。
並列ロールを実行する場合,clu_upgrade roll コマンドの -f オプションを使います。このオプションをつけると,許可の入力を求めることなく自動的にメンバをリブートします。ロール・コマンドは,メンバをロールすることによってクォーラムが失われないことを確認します。ロールの結果クォーラムが失われると判断した場合,メンバはロールされず,エラー・メッセージが表示されます。現在ロール中のメンバの 1 つがクラスタに戻り,クォーラム・ボートが利用可能になると,メンバをロールすることができます。
ロールが進むと,メンバはリブート可能になります。-f オプションを使うと,プロンプトが表示されずに自動的にリブートされます。-f オプションを使わない場合,clu_upgrade はプロンプトを表示し,この時点でリブートを行うかどうかについて質問してきます。リブート前に特に調べたいことがなければ,yes と入力します(yes と入力してから実際にリブートが行われるまで 30 秒程度かかることがあります)。
ロール段階を完了するのに必要な時間を短縮するには,並列ロールを実行します。たとえば,クォーラム・ディスクのある 8 メンバで構成されるクラスタでは,先行メンバをロールした後,4 メンバを同時にロールすることができます。
メンバでロール段階を開始します(先行メンバはインストール段階ですでにロールされています。先行メンバについてはロール段階は実行しません)。
以下のようなメッセージが表示されたら,次のメンバについてロール段階を開始します。
*** Info ***
You may now begin the roll of another cluster member. |
以下のような内容で始まるメッセージが表示されたら,メンバ・ボートに占める現在ロール中のメンバ数に起因する可能性があります。
*** Info ***
The current quorum conditions indicate that beginning
a roll of another member at this time may result in
the loss of quorum.
|
この場合,以下の選択肢があります。メンバがロール段階を完了するまで待ってから次のメンバに対してロールを開始する。
メンバ・ボートに含まれないロールされていないメンバが存在する場合は,そのメンバに対してロール段階を開始する。
クラスタのすべてのメンバがロールされるまで,ロールを続けます。それぞれのロール段階について,開始できることを示すメッセージが表示されてから,ロール段階を開始します。
最後のメンバをロールすると,以下のようなメッセージが表示されます。
*** Info ***
This is the last member requiring a roll. |
スイッチ段階を実行します (4-1-8-7 項 「スイッチ段階」)。
すべてのメンバをロールした後,任意のメンバで switch コマンドを実行します。
クラスタ・メンバを一度に 1 つずつリブートします。
クリーンアップ段階を実行します (4-1-8-8 項 「クリーンアップ段階」)。
任意のメンバで次のコマンドを実行し,クラスタのタグ付き (.Old..) を削除して,アップグレードを完了します。
4-1-4 ローリング・アップグレード中にインストールされたパッチの削除 |
 |
以降の項では,ローリング・アップグレード中にパッチを削除または再インストールする場合に認識しておくべき重要事項を説明します。
4-1-4-1 ポスト・インストール段階で停止して CSP または ERP を取り消す
ERP または CSP を TruCluster システムに適用する際,すべてのクラスタ・メンバ上でパッチをロールする前に,まずポスト・インストール段階で停止してパッチのテストを行うことをお勧めします。
これにより,問題がある場合にクラスタへのさらなる影響を減らすことができます。ローリング・パッチの手法を使用した ERP/CSP のインストールは,非常に簡単です。問題が生じるのは,パッチの削除の場合です。
ここでは, 2 つのメンバからなる TruCluster システム上でこの作業を行う手順とコマンドの概要を説明します。
以下の手順では,ノーロールではなく,(clu_upgrade を使用した) ローリング・パッチの手法を使用して ERP/CSP がインストールされていると想定しています。ノーロールの手法を使用してインストールされた ERP や CSP,あるいは単一メンバの TruCluster システム上にインストールされた ERP/CSP は該当しません。
パッチをインストールする前に,TruCluster システムの次のファイル・システムの最新のバックアップと,関連するディスクのディスクラベルを必ず保存してください。さらに,sys_check -all コマンドを使用して,システム構成情報を書き留めておいてください。
/ = cluster_root#root すべてのメンバによって共有
/usr = cluster_usr#usr すべてのメンバによって共有
/var = cluster_var#var すべてのメンバによって共有
/cluster/members/member1/boot_partition = root1_domain#root
Member1 メンバ固有のルート・ファイル・システム
/cluster/members/member1/boot_partition = root2_domain#root
Member2 メンバ固有のルート・ファイル・システム
手順の概要 :
Server 1 (先行メンバ) にログインしているときに,ポスト・インストール段階の undo を実行します。
# clu_upgrade undo postinstall |
SERVER1 (先行メンバ) をシャットダウンし,シングルユーザ・モードでブートして dupatch パッチ削除プログラムを実行します。シングルユーザ・レベルにシャットダウンするのではなく,システムを一度シャットダウンしてからシングルユーザ・モードでブートしてください。
# shutdown -h now
P00>> boot -fl s
Entering Single-User Mode |
以下のコマンドを SERVER1 上で実行します。
# init s
# bcheckrc
# lmf reset |
dupatch による削除手順を実行します。Patch Kit 4 以前のキットを実行しているシステムの場合,SERVER1 (先行メンバ) はシングルユーザ・モードでなければなりません。Patch Kit 5 以降のキットを実行しているシステムの場合は,この手順をマルチユーザ・モードで実行できます。CSP パッチのあるディレクトリに移動し,dupatch を実行します。
 |
SERVER1 上で dupatch を実行し,メイン・メニューから 「Patch Kit Deletion」を選択します。
# ./dupatch
Main Menu:
---------
1) Patch Kit Installation
2) Patch Kit Deletion
3) Patch Kit Documentation
4) Patch Tracking
5) Patch Baseline Analysis/Adjustment
h) Help on Command Line Interface
q) Quit
Enter your choice: 2 |
このときにパッチ固有情報 (Special Instructions) が表示されても無視してください。これは ERP と CSP には該当しません。ただし,削除する ERP/CSP に特有の特別な指示がある場合は,『ERP/CSP Patch Release Notes』を参照してください。
パッチ固有情報が表示された後,次のメニューが表示されます。
1) Patches for Tru64 UNIX V5.1B
2) Patches for TruCluster Server V5.1B |
CSP/ERP がベース・オペレーティング・システム・パッチの場合は 1 を,パッチが TruCluster に固有の場合は 2 を選択してください。プロンプトが表示されたら,名前とコメントを入力します。
オペレーティング・システムまたは TruCluster パッチ (最後のメニューでの選択による) の長いリストが表示されたら,そのリストからパッチを特定して選択します。
パッチが削除され,必要な場合は新しいカーネルが構築されます。
リブートするかを尋ねるプロンプトが表示されたら yes を選択します。プロンプトが表示されない場合は,手動でシステムをリブートします。
dupatch が完了し,先行メンバがリブートされたら,
インストール段階の取り消しを実行します。
SERVER2 (Member2,または先行メンバ以外のメンバ) 上で clu_upgrade undo install コマンドを実行します。dupatch を使用するよう警告されますが,これはすでに完了しているので,yes を選択します。タグ付きファイルが復元されますが,これには数分かかる場合があります (たとえば,EVA5000 SAN ストレージを使用した ES45 上で 20 分)。
# clu_upgrade undo install |
先行メンバをマルチユーザ・モードでブートし,プリ・インストール段階の取り消しを実行します。
# clu_upgrade undo preinstall |
セットアップ段階を取り消します。これを行うには,まずその他のメンバ (Member 2 (SERVER2) など) 上のタグ付きファイルを無効にする必要があります。
clu_upgrade プロセスのステータスを確認し,先行メンバ以外のメンバがタグ付きファイル上で実行されている場合は,以下のコマンドを実行してタグ付きファイルを無効にします。このとき,先行メンバ以外のメンバは,タグ付きファイル上で実行されている必要があります。
# clu_upgrade tagged disable 2 |
プロセスを完了するには,タグ付きファイルが無効とされているメンバ (この例では Member 2 (SERVER2)) をリブートします。
先行メンバ (SERVER1) でセットアップ段階の取り消しを実行し,パッチの削除を完了します。この作業は完了するまで10 分程度かかります。
これでクラスタは,clu_upgrade によるパッチ・インストールが取り消されます。
4-1-4-2 バージョン・スイッチ済みパッチの削除に関する注意
バージョン・スイッチ済みパッチをクラスタから削除する場合は,以前のローリング・アップグレードで正常にインストールされたバージョン・スイッチ済みパッチを削除しないでください。
このような状況は,同じバージョン・スイッチ済みパッチが複数のパッチ・サブセット内に存在する場合に発生します。ロール段階では新しいパッチと古いパッチの両方を削除できますが,バージョン・スイッチ済みパッチについては直前にインストールされた新しいパッチのみが正常に削除できます。
古いバージョン・スイッチ済みパッチを正常に削除するには,ドキュメントに記載されたそのパッチ固有の手順に従う必要があります。通常,このような場合は,ローリング・アップグレードを開始してパッチを削除する前に何らかのプログラムを実行する必要があります。
古いバージョン・スイッチ済みパッチを誤って削除すると,ほとんどの場合スイッチ段階でローリング・アップグレードに失敗します。この状況を解決するには,インストール段階とそれ以前の段階をすべて取り消すことにより,アップグレードを取り消します。次に,元のパッチ・キットから元のバージョン・スイッチ済みパッチを再インストールします。
4-1-4-3 スイッチ段階の前に削除する場合の手順
clu_upgrade switch コマンドを実行するまでの間に,ローリング・アップグレード中にインストールしたパッチ・キットを削除できます。このためには,インストール段階に戻り,dupatch コマンドをもう一度実行して,メイン・メニューから Patch Deletion を選択します。dupatch によるパッチの削除については,3-8 項 「パッチの削除」を参照してください。
手順は次のとおりです。
3-8 項 「パッチの削除」 の説明に従って,パッチ・キットを削除します。
clu_upgrade undo install コマンドを実行します。
パッチ・キットまたは NHD キットをインストールするときには clu_upgrade install コマンドを実行する必要はありませんが,パッチ・キットの削除やインストール段階の取り消しを行う場合は clu_upgrade undo install コマンドを実行する必要があります。clu_upgrade undo install を実行した後,4-1-6 項 「各段階の取り消し」 の説明に従って段階の取り消しを続行することができます。
4-1-4-4 スイッチ段階の後で削除する場合の手順
clu_upgrade switch コマンドを実行した後でパッチを削除するには,現在のローリング・アップグレードの手順を最後まで実行した後,同じ手順をもう一度最初 (セットアップ段階) から実行する必要があります。
インストール段階を実行する場合は,3-3-1 項 「シングルユーザ・モードからのパッチのインストール」の手順 1~6 に従って,システムをシングルユーザ・モードに移行する必要があります。dupatch を再度実行する (手順 7) 場合は,メイン・メニューから Patch Deletion を選択します。dupatch によるパッチの削除については,3-8 項 「パッチの削除」を参照してください。
バージョン・スイッチを使用するパッチは,clu_upgrade コマンドを実行した後でも削除できます。バージョン・スイッチを使用するパッチを削除するには,次のようにします。
現在のローリング・アップグレードの手順を最後まで実行します。
パッチのリリース・ノートに記述されている操作手順に従って,バージョン・スイッチを使用するパッチを取り消します。パッチを取り消す手順の最後で,クラスタ全体をシャットダウンする必要があります。
ローリング・アップグレードの手順をもう一度最初 (セットアップ段階) から実行します。dupatch を再度実行する場合は,メイン・メニューから Patch Deletion を選択します。
バージョン・スイッチを使用するパッチを見分けるには,grep コマンドを使用します。たとえば,C シェルでは次のようにします。
# grep -l PATCH_REQUIRES_VERSION_SWITCH=\"Y\" /usr/.smdb./*PAT*.ctrl
|
バージョン・スイッチについては,4-1-10 項 「バージョン・スイッチ」を参照してください。
4-1-5 ローリング・アップグレードのステータス表示 |
 |
clu_upgrade コマンドでは,ローリング・アップグレードのステータスを表示するための次のようなオプションを提供しています。ステータス・コマンドは,いつでも実行することができます。
ローリング・アップグレードの全体的なステータスを表示するには,次のコマンドを実行します。clu_upgrade -v または clu_upgrade -v status
各段階を実行できるかどうかを判断するには,次のコマンドを実行します。clu_upgrade check [stage] stage の値を指定しない場合,clu_upgrade では,次の段階を実行できるかどうかが検査されます。
各段階が処理中であるかまたは完了しているかを確認するには,次のコマンドを実行します。clu_upgrade started stage または clu_upgrade completed stage
メンバがロール済みかどうかを確認するには,次のコマンドを実行します。clu_upgrade check roll memberid.
レイヤード・プロダクトに対してタグ付きファイルが作成されているかどうかを確認するには,次のコマンドを実行します。clu_upgrade tagged check [prod_code [prod_code ...]] 製品コードを指定しないと,クラスタ内のすべてのタグ付きファイルが検査されます。
4-1-6 各段階の取り消し |
 |
clu_upgrade undo コマンドでは,スイッチ段階を完了していないローリング・アップグレードを取り消すことができます。スイッチ段階とクリーンアップ段階を除いて,どの段階でも取り消すことができます。段階の取り消しは正しい順序で行わなければなりません。たとえば,プリ・インストール段階を完了した後でローリング・アップグレードを取り消す場合は,プリ・インストール段階を取り消してから,セットアップ段階を取り消します。
段階を取り消すには,取り消す段階を指定して undo コマンドを実行します。clu_upgrade コマンドでは,指定した段階が取り消し可能であるかどうかを確認します。段階を取り消すための条件については,表 4-3 「各段階の取り消し」 を参照してください。
表 4-3 各段階の取り消し
取り消す段階 | コマンド | コメント |
---|
セットアップ | clu_upgrade undo setup | このコマンドは,先行メンバで実行する。また,セットアップ段階を取り消す場合は,どのメンバもタグ付きファイルを使用して実行できない。 セットアップ段階を取り消す前に,clu_upgrade -v status コマンドを実行し,タグ付きファイルを使用して実行しているメンバを検索する。次に,clu_upgrade tagged disable memberid コマンドを実行して,これらのメンバのタグ付きファイルを無効にする(タグ付きファイルとその操作に使用するコマンドについては,4-1-9 項 「タグ付きファイル」 を参照)。 タグ付きファイルを使用して実行中のメンバがない場合は,先行メンバで clu_upgrade undo setup コマンドを実行する。 |
プリ・インストール | clu_upgrade undo preinstall |
このコマンドは,先行メンバで実行する。 |
インストール | clu_upgrade undo install | このコマンドは,先行メンバ以外のメンバで実行する。 先行メンバを停止し,この先行メンバのブート・ディスクにアクセスできるメンバで clu_upgrade undo install コマンドを実行する。コマンドが完了した後で,先行メンバをブートする。 インストール段階でパッチ・キットまたは個別のパッチをインストールした場合は,clu_upgrade undo install コマンドを実行する前に dupatch を実行してパッチ・キットを削除する必要がある。ローリング・アップグレード中にパッチ・キットを削除する手順については,4-1-4 項 「ローリング・アップグレード中にインストールされたパッチの削除」 で説明している。 |
ポスト・インストール | clu_upgrade undo postinstall | このコマンドは,先行メンバで実行する。 |
ロール | clu_upgrade undo roll memberid | このコマンドはロール段階を取り消すメンバ以外のメンバで実行できる。 ロール段階を取り消すメンバを停止する。停止したメンバのブート・ディスクにアクセスできる他のメンバで clu_upgrade undo roll memberid コマンドを実行する。コマンドが完了した後で,停止したメンバをブートする。これらの操作により,メンバでタグ付きファイルが使用される。 |
4-1-7 ローリング・アップグレードのコマンド |
 |
ローリング・アップグレード全体の流れは,clu_upgrade(8) で説明されている clu_upgrade コマンドを使用して制御します。このコマンドを使用すれば,正しい順序で各段階を実行することができます。インストール段階では,installupdate,dupatch,および nhd_install のうちの 1 つまたは複数を使用して,ソフトウェアのロードとインストールを実行することができます。これらのコマンドはローリング・アップグレードに対応しています。つまり,ローリング・アップグレードのインストール段階とロール段階でどの動作が許可されているかを判断できるようになっています。
ローリング・アップグレードを開始すると,クラスタは以前のリリースからソフトウェアを実行します。ローリング・アップグレードの最初の部分では,以前からクラスタにインストールされている clu_upgrade コマンドを実行します。ローリング・アップグレード中に新しいバージョンがインストールされた場合,コマンドのバージョンの違いにより画面表示や動作が多少異なることがあります。
インストールするキットにアップグレード・コマンドの新しいバージョンが含まれていた場合にローリング・アップグレードのどの段階でその新バージョンが使用できるようになるかを,以下の 2 つの表に示します。[2]
表 4-4 Version 5.1A からローリング・アップグレードする場合の段階と clu_upgrade のバージョンとの対応
段階 | Version 5.1A | 次のリリース[1] | 説明 |
---|
準備 | X | | 現在インストールされている (旧) バージョンの clu_upgrade が常に実行される。 |
セットアップ | X | | この段階では,現在インストールされている (旧) バージョンの clu_upgrade が常に実行される。 アップデート・インストレーションを実行する場合は,clu_upgrade の新バージョンが TruCluster software・キットから読み取られて /usr/sbin/clu_upgrade にインストールされ,旧バージョンと交換される。この交換はタグ付きファイルを作成する前に行われるため,それ以降のローリング・アップグレードでは,どのメンバもすべて新しい clu_upgrade を使用することになる。 |
プリ・インストール | | X | ローリング・アップグレードでアップデート・インストレーションを行う場合は,どのメンバも,セットアップ段階の途中でインストールされた新しいバージョンの clu_upgrade を使用する (それ以外の場合は,どのメンバも現バージョンの clu_upgrade を継続して使用する)。 |
インストール | | X | ローリング・アップグレードでアップデート・インストレーションを行う場合は,どのメンバも,セットアップ段階の途中でインストールされた新バージョンの clu_upgrade を使用する。 アップデート・インストレーションの途中で,installupdate が新バージョンのものに置き換えられる。 パッチ・キットを適用すると,常に最新バージョンの dupatch がインストールされる。 パッチ・キットに新しいバージョンの clu_upgrade が含まれている場合にそのパッチを適用すると,新バージョンがインストールされ,どのクラスタ・メンバもすべてポスト・インストール段階で新バージョンを使用する。 |
ポスト・インストール | | X | セットアップ段階またはインストール段階のいずれかで新しいバージョンの clu_upgrade がインストールされた場合は,どのメンバもすべて新バージョンを使用する。 |
ロール | | X | セットアップ段階またはインストール段階のいずれかで新しいバージョンの clu_upgrade がインストールされた場合は,どのメンバもすべて新バージョンを使用する。 |
スイッチ | | X | セットアップ段階またはインストール段階のいずれかで新しいバージョンの clu_upgrade がインストールされた場合は,どのメンバもすべて新バージョンを使用する。 |
クリーンアップ | | X | セットアップ段階またはインストール段階のいずれかで新しいバージョンの clu_upgrade がインストールされた場合は,どのメンバもすべて新バージョンを使用する。 |
表 4-5 Version 5.1B からローリング・アップグレードする場合の段階と clu_upgrade のバージョンとの対応
段階 | Version 5.1B | 次のリリース[1] | 説明 |
---|
準備 | X | | 現在インストールされている (旧) バージョンの clu_upgrade が常に実行される。 |
セットアップ | X | | この段階では,現在インストールされている (旧) バージョンの clu_upgrade が常に実行される。 アップデート・インストレーションを実行する場合は,clu_upgrade の新バージョンが TruCluster software・キットから読み取られて /usr/sbin/clu_upgrade にインストールされ,旧バージョンと交換される。この交換はタグ付きファイルを作成する前に行われるため,それ以降のローリング・アップグレードでは,どのメンバもすべて新しい clu_upgrade を使用することになる。 |
プリ・インストール | | X | ローリング・アップグレードでアップデート・インストレーションを行う場合は,どのメンバも,セットアップ段階の途中でインストールされた新しいバージョンの clu_upgrade を使用する (それ以外の場合は,どのメンバも現バージョンの clu_upgrade を継続して使用する)。 |
インストール | | X | ローリング・アップグレードでアップデート・インストレーションを行う場合は,どのメンバも,セットアップ段階の途中でインストールされた新バージョンの clu_upgrade を使用する。 アップデート・インストレーションの途中で,installupdate が新バージョンのものに置き換えられる。 パッチ・キットを適用すると,常に最新バージョンの dupatch がインストールされる。 パッチ・キットに新しいバージョンの clu_upgrade が含まれている場合にそのパッチを適用すると,新バージョンがインストールされ,どのクラスタ・メンバもすべてポスト・インストール段階で新バージョンを使用する。 |
ポスト・インストール | | X | セットアップ段階またはインストール段階のいずれかで新しいバージョンの clu_upgrade がインストールされた場合は,どのメンバもすべて新バージョンを使用する。 |
ロール | | X | セットアップ段階またはインストール段階のいずれかで新しいバージョンの clu_upgrade がインストールされた場合は,どのメンバもすべて新バージョンを使用する。 |
スイッチ | | X | セットアップ段階またはインストール段階のいずれかで新しいバージョンの clu_upgrade がインストールされた場合は,どのメンバもすべて新バージョンを使用する。 |
クリーンアップ | | X | セットアップ段階またはインストール段階のいずれかで新しいバージョンの clu_upgrade がインストールされた場合は,どのメンバもすべて新バージョンを使用する。 |
4-1-8 ローリング・アップグレードの各段階 |
 |
この項では,ローリング・アップグレードの各段階について説明します。
準備段階では,クラスタの重要なデータをすべてバックアップし,クラスタをロールする準備ができているかどうかを検査します。ローリング・アップグレードの開始前に,次の操作を行います。
最初にロールするメンバを,1 つ選択します。このメンバを先行メンバと呼びます。先行メンバは,ルート (/),/usr,/var,および i18n (使用されている場合) ファイル・システムに対して直接アクセスできる必要があります。
先行メンバで重要なアプリケーションを実行できることを確認します。これらのアプリケーションをテストできるのは,インストール段階でこのメンバをアップデートしてから他のメンバをロールするまでの間です。問題が発生した場合は,次へ進む前にこのメンバで問題を解決します。問題を解決できない場合は,ローリング・アップグレードを取り消して,クラスタをロール前の状態に戻します((ローリング・アップグレードの各段階を取り消す方法については,4-1-6 項 「各段階の取り消し」を参照)。
クラスタ単位のルート (/),/usr,および /var ファイル・システム,およびこれらのファイル・システムに含まれるメンバ固有のファイルすべてのバックアップを取ってください。クラスタに独立した i18n ファイル・システムが含まれている場合は,このファイル・システムのバックアップもとります。また,他にも重要なユーザ・データやアプリケーション・データを格納したファイル・システムがある場合は,そのファイル・システムのバックアップもとってください。
インストール段階で installupdate コマンドを実行する場合は,表 4-6 「ブロッキング・レイヤード・プロダクト」 に示す,クラスタにインストールされているブロッキング・レイヤード・プロダクトを削除します。
clu_upgrade -v check setup lead_memberid を実行し,次の内容を確認します。
すべてのメンバで同じバージョンのオペレーティング・システムとクラスタ・ソフトウェアを実行していること
タグ付きファイルを使用して実行されているメンバがないこと
各システムのファームウェアが新しいソフトウェアをサポートしていることを確認します。必要があれば,ローリング・アップグレードを開始する前にファームウェアをアップデートします。
クラスタにはオペレーティング・システムとクラスタ・ソフトウェアが 2 組あるため,ローリング・アップグレード中でもクラスタを運用することができます(共用構成ファイルは 1 つだけなので,あるメンバで加えられた変更を他のメンバからも確認することができます)。この方法では,同じクラスタで同時に 2 種類のバージョンのベース・オペレーティング・システムを実行することができます。ただし,クラスタ単位のルート (/),/usr,および /var ファイル・システムに,また,各国語サポート (WLS) サブセットの独立したドメインがある場合は i18n ファイル・システムに,それぞれ必要な空きディスク容量があるかどうかをアップグレード前に確認する必要があります。
ローリング・アップグレードを実行するには,次の空きディスク容量が必要です。
ルート (/) ファイル・システムつまり cluster_root#root に 50 パーセント以上の空き容量。
/usr ファイル・システムつまり cluster_usr#usr に 50 パーセント以上の空き容量。
/var ファイル・システムつまり cluster_var#var に 50 パーセント以上の空き容量があり,さらに,オペレーティング・システムをアップデートする場合は,新バージョンのベース・オペレーティング・システムのサブセットを格納するために別途 425 MB が必要。
WLS サブセットの独立した i18nドメインがある場合は,そのドメインに 50 パーセント以上の空き容量。
メンバ・ブート・パーティションにはタグ付きファイルは置かれない。ただし,プログラムがカーネルをブート・パーティションに移動する場合に空き容量が必要になることがあるので, 各メンバのブート・パーティションには最低 50 MB の空き容量の確保を推奨。
パッチ・キットをインストールする場合は,パッチ・キットに添付されている『Patch Summary and Release Notes』を参照し,このパッチ・キットのインストールに必要な空きディスク容量を確認する。NHD キットをインストールする場合は,NHD キットに添付されている『 New Hardware Delivery Release Notes and Installation Instructions』を参照し,このパッチ・キットのインストールに必要な空きディスク容量を確認する。
ファイル・システムにより多くの空き容量が必要な場合は,addvol などの AdvFS Utilities を使用して,必要に応じてドメインにボリュームを追加します。AdvFS ドメインの管理方法については,Tru64 UNIX 『AdvFS Administration』を参照してください(AdvFS Utilities は別ライセンスが必要)。クラスタ単位のルート (/) ドメインは拡張することができます。
セットアップ段階では,clu_upgrade check setup コマンドを実行してタグ付きファイルを作成し,クラスタをロールする準備をします。
clu_upgrade setup lead_memberid コマンドでは,次のタスクが実行されます。
ローリング・アップグレードのログ・ファイル /cluster/admin/clu_upgrade.log が作成される。
4-1-8-1 項 「準備段階」の -v check setup テストが実行される。
アップデート・インストレーション,パッチ・キットのインストール,NHD キットのインストール,またはその組み合わせのうち何を実行するかを確認するためのプロンプトが表示される。TruCluster software Version 5.1B の clu_upgrade コマンドが表示するメニューの例を次に示す。
What type of rolling upgrade will be performed?
Selection Type of Upgrade
---------------------------------------------------------------
1 An upgrade using the installupdate command
2 A patch using the dupatch command
3 A new hardware delivery using the nhd_install command
4 All of the above
5 None of the above
6 Help
7 Display all options again
---------------------------------------------------------------
Enter your Choices (for example, 1 2 2-3): |
アップデート・インストレーションを指定すると,関連キットがディスクにコピーされる。
アップデート・インストレーションを実行する場合は,クラスタ・キットが /var/adm/update/TruClusterKit にコピーされ,installupdate コマンドがインストール段階でそのキットを使用できるようになる(installupdate コマンドはインストール段階でオペレーティング・システム・キットを /var/adm/update/OSKit にコピーする)。clu_upgradeコマンドは,TruCluster software・キットの場所を絶対パス名で指定するためのプロンプトを表示する。TruCluster softwareVersion 5.1B クラスタでアップデート・インストレーションを含むローリング・アップグレードを実行する場合は,clu_upgrade setup コマンドを実行する前に,TruCluster software・キットをマウントすること。
Version 5.1B クラスタで NHD インストレーションを実行する場合は,nhd_install コマンドを使用して NHD キットを /var/adm/update/NHDKit にコピーする。
OSF (ベース),TCR (クラスタ),および IOS (各国語サポート) 製品に対して必要なタグ付きファイル・セットが作成される。
先行メンバを除くすべてのメンバで sysconfigtab 変数が rolls_ver_lookup=1 に設定される。rolls_ver_lookup=1 に設定したメンバでは,タグ付きファイルが使われる。この結果,他のメンバが .Old.. ファイルを使って動作している間に,先行メンバを現在のリリースからアップグレードすることができる。
先行メンバ以外のすべてのクラスタ・メンバをリブートするためのプロンプトが表示される。setup コマンドが完了した後で,クラスタがクォーラムを保持できるようにこれらのメンバを一度に 1 つずつリブートする。その場合,複数のバージョンが混在するクラスタ内でタグ付きファイルを使用するメンバごとにリブートする必要がある。リブートが完了すると,先行メンバ以外のすべてのメンバがタグ付きファイルを使用して実行される。
プリ・インストール段階の目的は,クラスタの先行メンバで installupdate,dupatch,および nhd_install コマンドを実行する準備ができているかどうかを確認することです。
clu_upgrade preinstall コマンドでは,次のタスクが実行されます。
このコマンドが先行メンバで実行されていること,実行中の先行メンバがタグ付きファイルを使用していないこと,および実行中の他のメンバがタグ付きファイルを使用していることが確認される。
必要に応じて,タグ付きファイルが存在すること,タグ付きファイルが製品のインベントリ・ファイルに一致すること,および各タグ付きファイルの AdvFS プロパティが正しく設定されていることが確認される(この処理には,やや時間がかかるが,セットアップ段階でタグ付きファイルを作成する操作よりは早く終了する。各段階の所要時間については,表 4-2 「ローリング・アップグレードの各段階における所要時間」 を参照)。
先行メンバ固有のファイルのバックアップ・コピーがディスク上に作成される。
現在のクラスタが TruCluster software Version 5.1B または Version 5.1Aで動作している場合は,表 4-1 「Version 5.1A および Version 5.1B で行えるローリング・アップグレード作業」 に示す作業を単独または組み合わせて実行することがきます。
インストール段階は,clu_upgrade preinstall コマンドが完了してから clu_upgrade postinstall コマンドを実行する直前までを指します。
installupdate コマンドまたは nhd_install コマンドを実行するには,先行メンバをシングルユーザ・モードに設定する必要があります。また,dupatch コマンドを実行する場合もシングルユーザ・モードに設定することをお勧めします。システムをシングルユーザ・モードに設定する場合は,システムを停止してから,シングルユーザ・モードでリブートします。
シングルユーザ・モードに設定されたシステムで,init s,bcheckrc,および lmf reset コマンドを実行してから installupdate,dupatch,または nhd_install コマンドを実行します。
ポスト・インストール段階では,先行メンバでアップデート・インストレーション,パッチ,または NHD インストレーションが完了したことを確認します。アップデート・インストレーションを実行した場合は,先行メンバが新しいバージョンのベース・オペレーティング・システムにアップグレードされたことを clu_upgrade postinstall コマンドで確認します。
インストール段階では先行メンバをアップグレードしましたが,他のメンバはロール段階でアップグレードします。
多くのクラスタ構成では,複数のメンバを並列でロールし,クラスタ・アップグレードに必要な時間を短縮することができます。並列的にロールできるメンバの数は,ロールされていないメンバ (クォーラム・ディスクが構成されている場合は,クォーラム・ディスクを含む) がクォーラムを維持するのに十分なボートを持つ必要があるという要件によってのみ制限されます。並列ロールは,先行メンバがロールされた後にだけ実行することができます。
clu_upgrade roll コマンドでは,次のタスクが実行されます。
メンバが先行メンバでないこと,メンバがロール前であること,およびメンバがシングルユーザ・モードであることが確認される。メンバをロールすることにより,クォーラムが失われないことが確認される。
リブート時にロールを実行するための it(8) スクリプトがセットアップされる。
メンバがリブートされる。ブート中に it スクリプトによりメンバがロールされ,カスタマイズされたカーネルが作成される。そのカーネルで,リブートされる。
すべてのメンバをロールし終える前にあるメンバがダウンして修復もリブートもできない場合は,クラスタのロールを完了させるために,そのメンバを削除しなければなりません。ただし,1 つのメンバを除いてすべてのメンバのロールが完了しているという状態で,ロールの完了していないそのメンバがロール段階でリブートする前にダウンした場合は,そのメンバを削除してから他のクラスタ・メンバをリブートする必要があります。clu_upgrade はリブート中も動作して,クラスタに現在あるメンバの数に対してロールされたメンバがどれだけあるかを追跡します。clu_upgrade は,それら 2 つの値が同じになると,ロール段階が完了したものとしてマークします。そのため,1 つのメンバを除いてすべてのメンバをロールした場合,ロールされていないメンバを削除して他のメンバをリブートすることにより,ロール段階が完了し,ローリング・アップグレードが継続できます。
スイッチ段階では,ソフトウェアのアクティブ・バージョンを新バージョンに設定します。その結果,ローリング・アップグレード中に無効にしておいた新機能が有効になります(アクティブなバージョンと新バージョンについての説明は,4-1-10 項 「バージョン・スイッチ」を参照してください)。
clu_upgrade switch コマンドでは,次のタスクが実行されます。
すべてのメンバのロールが完了したこと,すべてのメンバで同じバージョンのオペレーティング・システムとクラスタ・ソフトウェアが実行されていること,およびタグ付きファイルを使用して実行されているメンバがないことが確認される。
各メンバの sysconfigtab ファイルと実行中のカーネルに新しいバージョンの ID が設定される。
すべてのクラスタ・メンバでアクティブ・バージョンが新バージョンに設定される。
クリーンアップ段階では,タグ付き (.Old..) ファイルをクラスタから削除して,アップグレードを完了します。
clu_upgrade clean コマンドでは,次のタスクが実行されます。
スイッチ段階が完了したこと,すべてのメンバで同じバージョンのオペレーティング・システムとクラスタ・ソフトウェアが実行されていること,およびタグ付きファイルを使用して実行されているメンバがないことが確認される。
clu_upgrade コマンドで作成したディスク上のバックアップ・アーカイブが削除される。
ディレクトリが存在する場合,/var/adm/update/TruClusterKit,/var/adm/update/OSKit,および /var/adm/update/NHDKit が再帰的に削除される。
アップデート・インストレーションを実行した場合,アップデート管理ユーティリティ (updadmin) を実行して,アップデート・インストレーション中に保存されたファイルを管理するためのオプションが表示される。
このアップグレードに対するアーカイブ・ディレクトリ (/cluster/admin/clu_upgrade/history/release_version) が作成され,clu_upgrade.log ファイルがこのアーカイブ・ディレクトリに格納される。
4-1-9 タグ付きファイル |
 |
ローリング・アップグレードでは,一度に 1 つのクラスタ・メンバのソフトウェアがアップデートされます。ロール中にクラスタで 2 つのバージョンのソフトウェアを動作させるには,セットアップ段階で clu_upgrade を実行し,タグ付きファイルを作成します。
タグ付きファイルは,現在のファイルをコピーして,元のファイル名の先頭に .Old.. を追加してその名前にするとともに,AdvFS プロパティ (DEC_VERSION_TAG) を設定したファイルです。たとえば,vdump コマンドのタグ付きファイルの名前は,/sbin/.Old..vdump となります。タグ付きファイルは,元のファイルと同じファイル・システムに作成されるため,ローリング・アップグレードを開始する前に,十分なディスク容量があることを確認する必要があります。
メンバがタグ付きファイルを使用して実行されるかどうかは,そのメンバの sysconfigtab rolls_ver_lookup 変数によって制御されます。タグ付きファイルを使ってメンバを実行する必要がある場合は,この値が 1 に設定されます。タグ付きファイルを使わずにメンバを実行する必要がある場合は,この値が 0 に設定されます。
メンバの sysconfigtab rolls_ver_lookup 属性を 1 に設定すると,パス名を特定する場合に,指定したファイルと対応する .Old..filename というファイル名のコピーがあるかどうか,およびこのコピーに DEC_VERSION_TAG プロパティが設定されているかどうかを調べます。両方の条件が満たされると,要求したファイル操作が透過的に変更され,.Old..filename ファイルが使用されます。たとえば,ロールが完了していないメンバで vdump コマンドを実行すると,/sbin/.Old..vdump が実行され,ロール済みのメンバで実行すると,/sbin/vdump が実行されます。先行メンバ (最初にロールするメンバ) だけは,タグ付きファイルを使用して実行されません。
 |
 |  |
 |
 | 注意: ディレクトリに対するファイル・システム操作では,このタグ付きファイルの制約を受けることはありません。たとえば,ローリング・アップグレード中にクラスタ・メンバのディレクトリで ls を実行すると,両方のバージョンのファイルがリストされます。ただし,ローリング・アップグレードを完了する前のメンバと完了した後のメンバでは,ls -ail コマンドを実行した場合の出力が異なります。以下の例は,ls -ail コマンドを,ロールされていないメンバで最初に実行した後,ロールされたメンバで実行した例です(awk ユーティリティは,各ファイルの i ノード,サイズ,タイム・スタンプ (月日),およびファイル名だけを出力するために使用しています)。 次に示す出力は,タグ付きファイルを使用して動作しているロール前のクラスタ・メンバで ls コマンドを実行した場合のものです。タグ付きファイルとタグの付いていないファイルは同一です (i ノード,サイズ,タイム・スタンプが同じ)。このメンバで hostname コマンドを実行すると,タグの付いている方 (i ノード 3643) が実行されます。 # cd /sbin
# ls -ail hostname .Old..hostname ls .Old..ls init .Old..init |\
awk '{printf("%d\t%d\t%s %s\t%s\n",$1,$6,$7,$8,$10)}`
3643 16416 Aug 24 .Old..hostname
3648 395600 Aug 24 .Old..init
3756 624320 Aug 24 .Old..ls
3643 16416 Aug 24 hostname
3648 395600 Aug 24 init
3756 624320 Aug 24 ls |
次に示す出力は,ロールした後にタグ付きファイルを使用しないで動作しているクラスタ・メンバで ls コマンドを実行した場合のものです。タグ付きファイルとタグの付いていないファイルは異なります (i ノード,サイズ,タイム・スタンプが異なる)。このメンバで hostname コマンドを実行すると,タグの付いていない方 (i ノード 1370) が実行されます。 # cd /sbin
# ls -ail hostname .Old..hostname ls .Old..ls init .Old..init |\
awk '{printf("%d\t%d\t%s %s\t%s\n",$1,$6,$7,$8,$10)}`
3643 16416 Aug 24 .Old..hostname
3648 395600 Aug 24 .Old..init
3756 624320 Aug 24 .Old..ls
1187 16528 Mar 12 hostname
1370 429280 Mar 12 init
1273 792640 Mar 12 ls |
|
 |
 |  |
 |
セットアップ段階でタグ付きファイルを作成した後は,ロールしたメンバから tar のような管理タスクを実行することをお勧めします。先行メンバでは,タグ付きファイルを実行しないので常にコマンドを実行できます。
セットアップ段階で自動的にタグ付きファイルが作成されるファイルを判断する規則は,次のとおりです。
タグ付きファイルは,製品コードのインベントリ・ファイルに対して作成されます。製品コードには,ベース・オペレーティング・システム (OSF),TruCluster software (TCR),および Worldwide Language Support (IOS) があります。各製品のサブセットには,3 文字の製品コードから始まる名前が指定されています。たとえば,TruCluster software のサブセット名は,TCRBASE510,TCRMAN510,TCRMIGRATE510 のように,先頭に TruCluster software を示す 3 文字の製品コードが付きます。
省略時の設定では,他のレイヤード・プロダクトに関連するファイルに対してはタグ付きファイルを作成しません。タグ付きファイルは,ローリング・アップグレード中にタグ付きファイルをサポートするように変更されたレイヤード・プロダクトだけに対して作成されます。
clu_upgrade コマンドには,タグ付きファイルを操作するためのさまざまな tagged コマンド・オプション (check,add,remove,enable,および disable) を指定することができます。タグ付きファイルを操作する場合は,次の点に注意してください。
通常,ローリング・アップグレード中にタグ付きファイルを手動で追加したり,削除したりする必要はありません。clu_upgrade コマンドでは,必要に応じて tagged コマンドが呼び出され,タグ付きファイルの作成と削除が制御されます。
clu_upgrade tagged コマンドを実行する場合, check,add,remove コマンドは,先行メンバのように,タグ付きファイルを使用しないで動作しているメンバで実行してください。disable および enable コマンドはどのメンバでも実行できます。
タグ付きファイルに関する check,add,または remove 操作の指定は,製品全体を表す製品コードを対象とします。clu_upgrade tagged コマンドは,指定した製品のすべてのインベントリ・ファイルを対象にします。たとえば,次のコマンドを実行すると,TCR カーネル・レイヤード・プロダクト (TruCluster software のサブセット) に対して作成されたすべてのタグ付きファイルが正しいかどうかが確認されます。
# clu_upgrade tagged check TCR |
あるファイルの .Old.. バージョンを誤って削除した場合,そのファイルをもう一度作成するには,レイヤード・プロダクト全体のタグ付きファイルを作成する必要があります。たとえば,vdump コマンドは OSF 製品の一部である OSFADVFSxxx サブセットに含まれています。/sbin/.Old..vdump を誤って削除すると,次のコマンドを実行して,レイヤード・プロダクト全体のタグ付きファイルを再作成する必要があります。
# clu_upgrade tagged add OSF |
enable コマンドと disable コマンドは,クラスタ・メンバごとにタグ付きファイルを使用可能または使用不能にする場合に実行します。通常,ローリング・アップグレード中には,enable コマンドまたは disable コマンドを使用する必要はありません。
disable コマンドは,セットアップ段階を取り消す場合に便利です。セットアップ段階を取り消す場合は,どのメンバもタグ付きファイルを使用して実行できないため,disable コマンドで,現在タグ付きファイルを使用して実行されているクラスタ・メンバのタグ付きファイルを無効にします。たとえば,ID が 3 のメンバのタグ付きファイルを無効にするには,コマンドを次のように指定します。
# clu_upgrade tagged disable 3 |
enable コマンドは,disable コマンドを誤って実行した場合に使用します。
4-1-10 バージョン・スイッチ |
 |
バージョン・スイッチは,アクティブ・バージョンのオペレーティング・システムから新しいバージョンのオペレーティング・システムへの移行を管理する場合に使用します。アクティブ・バージョンとは,現在使用中のバージョンを指します。クラスタでバージョン・スイッチを使用する目的は,すべてのメンバがアップデートされるまで,本質的に互換性がない新機能を導入しないようにするためです。たとえば,新バージョンでカーネル構造が変更されており,現在の構造と互換性がない場合,通常は,すべてのクラスタ・メンバがその新構造をサポートするバージョンにアップデートされるまで,クラスタ・メンバで新構造を使用しません。
ローリング・アップグレードの開始時には,どのメンバでもアクティブ・バージョンは新バージョンと同じです。ローリング・アップグレードが進むにつれて各メンバで新バージョンがアップデートされます。すべてのメンバでローリング・アップグレードが終了した後のスイッチ段階で,すべてのメンバのアクティブ・バージョンが新バージョンに設定されます。アップグレードが完了すると,再びすべてのメンバのアクティブ・バージョンが新バージョンと同じになります。次の簡単な例に,アクティブ・バージョン 1 と新バージョン 2 を使用して,ローリング・アップグレードの過程でバージョンが変わる様子を示します。
All members at start of roll: active (1) = new (1)
Each member after its roll: active (1) != new (2)
All members after switch stage: active (2) = new (2) |
バージョンの移行を管理するには,clu_upgrade コマンドに versw コマンド (versw(8) を参照) を指定します。clu_upgrade コマンドを使用して,各メンバをロールするときにバージョン・スイッチのすべてのアクティビティを管理します。すべてのメンバをロールした後のスイッチ段階で,次のコマンドを実行して新しいソフトウェアへの移行を完了させます。
4-1-11 ローリング・アップグレードとレイヤード・プロダクト |
 |
ここでは,レイヤード・プロダクトとローリング・アップグレードの相互作用を次の項に分けて説明します。
clu_upgrade setup コマンドは,クラスタでオペレーティング・システムをローリング・アップグレードするための準備を行います。clu_upgrade setup コマンドを実行してから最初のメンバを新しいバージョンにロールするまでの間は,setld コマンドを用いてクラスタにソフトウェアをロードしないでください。clu_upgrade setup コマンドを実行してからクラスタ・メンバを新しいバージョンにロールするまでの間にソフトウェアをインストールすると,新しいファイルは clu_upgrade setup で処理されなくなります。その結果,最初のクラスタ・メンバをロールする際に,その新しいファイルが上書きされてしまいます。
ソフトウェアをロードしなければならない場合は,次のような方法で行ってください。
少なくとも 1 つのメンバがロールされるまで待つ。
ロールされたメンバでソフトウェアをインストールする。
4-1-11-2 ブロッキング・レイヤード・プロダクト
ブロッキング・レイヤード・プロダクトは,installupdate コマンドによるアップデート操作を妨げる製品です。installupdate コマンドを実行するローリング・アップグレードの開始前にクラスタからブロッキング・レイヤード・プロダクトを削除する必要があります。クラスタにパッチをあてるため,または NHD キットをインストールするためだけにローリング・アップグレードを実行する場合は,ブロッキング・レイヤード・プロダクトを削除する必要はありません。
表 4-6 「ブロッキング・レイヤード・プロダクト」 は,このリリースのブロッキング・レイヤード・プロダクトをまとめたものです。
表 4-6 ブロッキング・レイヤード・プロダクト
製品コード | 説明 |
---|
3X0 | Open3D |
4DT | Open3D |
ATM | Atom Advanced Developers Kit |
DCE | Distributed Computing Environment |
DNA | DECnet |
DTA | Developer's Toolkit (プログラム分析ツール) |
DTC | Developer's Toolkit (C コンパイラ) |
MME | マルチメディア・サービス |
O3D | Open 3D |
PRX | PanoramiX Advanced Developers Kit |
4-1-12 ローリング・アップグレードと RIS |
 |
ローリング・アップグレードのインストール段階を実行する場合,CD-ROM またはリモート・インストレーション・サービス (RIS) サーバからベース・オペレーティング・システムのサブセットをロードすることができます。
RIS を使用するには,先行メンバおよび省略時のクラスタ別名の両方を RIS サーバに登録する必要があります。オペレーティング・システム・ソフトウェアの登録では,各ホスト名のハードウェア・アドレスが必要です。そのため,省略時のクラスタ別名を RIS サーバに登録するには,省略時のクラスタ別名に対するハードウェア・アドレスを生成する必要があります(RIS サーバの /etc/bootptab ファイルまたは /var/adm/ris/clients/risdb ファイルにすでに登録されているアドレスは受け付けられません)。
クラスタでクラスタ別名の仮想 MAC (vMAC) 機能を使用する場合は,省略時のクラスタ別名のハードウェア・アドレスとしてその仮想ハードウェア・アドレスを RIS サーバに登録します。クラスタで vMAC 機能を使用しない場合は,『クラスタ管理ガイド』の「vMAC」の項で説明するアルゴリズムを使用し,省略時のクラスタ別名に対するハードウェア・アドレスを手動で生成することもできます。
vMAC アドレスは,接頭文字 (省略時では AA:01) と,別名に対する 16 進数形式の IP アドレスで構成されます。たとえば,省略時のクラスタ別名が deli で,この IP アドレスが 16.140.112.209 である場合,省略時のクラスタ別名に対する vMAC アドレスは AA:01:10:8C:70:D1 で表されます。アドレスの作成方法は,次のとおりです。
Default vMAC prefix: AA:01
Cluster Alias IP Address: 16.140.112.209
IP address in hex. format: 10.8C.70.D1
vMAC for this alias: AA:01:10:8C:70:D1 |
8 つの 16 進数で構成される任意の文字列を vMAC の省略時の接頭文字 (AA:01) に追加して,ハードウェア・アドレスを作成することもできます (例 AA:01:00:00:00:00)。このアドレスが RIS サーバからサービスされる領域内で一意であることを確認してください。クラスタが複数ある場合に次の別名を追加するには,16 進数の任意の文字列の値を大きくしてください(vMAC アルゴリズムを使用すると,ネットワーク内で一意のアドレスを作成できる可能性が高いので便利です)。