ローリング・アップグレードは,クラスタの稼働中にソフトウェアをアップグレードする方法です。クラスタ・メンバを一度に 1 つずつアップグレードして運用に戻し,複数のバージョンのベース・オペレーティング・システム,クラスタ,および各国語サポート (WLS) ソフトウェアが混在する環境を透過的に管理します。サービスにアクセスするクライアントからは,ローリング・アップグレードが進行中であることがわかりません。
ローリング・アップグレードでは,一連の手順を順序に沿って実行します。 この手順を段階といいます。ローリング・アップグレードを制御するコマンドはこの順序で実行する必要があります。
この章の前半では,ローリング・アップグレードの実行,ローリング・アップグレードのステータス表示,およびローリング・アップグレードにおける段階の取り消し (複数段階可) について説明します。ローリング・アップグレードがどのように働くかについては,7.6 節およびそれに続く節で説明します。
この章で説明する内容は次のとおりです。
1 つのローリング・アップグレードで実行できる作業または作業の組み合わせ (7.1 節)
ローリング・アップグレードで実行できない作業 (7.2 節)
ローリング・アップグレード方法 (7.3 節)
ローリング・アップグレードのステータス表示方法 (7.4 節)
ローリング・アップグレード段階の取り消し方法 (7.5 節)
ローリング・アップグレードで使用するコマンド (7.6 節)
ローリング・アップグレードの段階 (7.7 節)
ローリング・アップグレードをサポートする 2 つの機構 -- タグ付きファイル (7.8 節) とバージョン・スイッチ (7.9 節)
ローリング・アップグレードとレイヤード・プロダクト (7.10 節)
ローリング・アップグレードと RIS (7.11 節)
図 7-1
は,バージョン 5.1B クラスタで開始するローリング・アップグレードの実行に必要な作業と段階を簡単なフロー・チャートにまとめたものです。
図 7-1: ローリング・アップグレード作業の流れ
ローリング・アップグレードで行うことができる作業は,クラスタで現在実行しているベース・オペレーティング・システムとクラスタ・ソフトウェアのバージョンによって異なります。この章では主に,TruCluster Server バージョン 5.1B クラスタで開始するローリング・アップグレードについて説明します。ただし,TruCluster Server バージョン 5.1A からバージョン 5.1B へローリング・アップグレードする準備をされている方のために,2 つのバージョンの間にあるローリング・アップグレードの違いについても示していきます。
ローリング・アップグレードで行うことができる基本的な作業は,次のとおりです。
クラスタの Tru64 UNIX ベース・オペレーティング・システムと TruCluster Server ソフトウェアのアップグレード。このタイプのローリング・アップグレードでは,インストールされているバージョンを次のバージョンへアップグレードします。
ベース・オペレーティング・システムとクラスタ・ソフトウェアをローリング・アップグレードする際は,あるバージョンからすぐ次のバージョンへローリングできるだけです。バージョンをスキップすることはできません。実施可能なアップグレード・パスについては表 1-1 を参照してください。
注意
ローリング・アップグレードでは,クラスタで現在使用しているファイル・システムとディスクがアップデートされます。ただし,クラスタの作成に使用した Tru64 UNIX オペレーティング・システムを含むディスクはアップデートされません (
clu_create
を実行したオペレーティング・システム)。クラスタが停止した場合のように,緊急時に元のオペレーティング・システムをブートすることはできますが,クラスタをアップデートするたびに最新のクラスタと元のオペレーティング・システムの相違点が増加していくことに注意してください。
クラスタで現在使用している Tru64 UNIX ベース・オペレーティング・システムと TruCluster Server ソフトウェアのパッチ。
NHD (New Hardware Delivery) キットのインストール (クラスタで TruCluster Server バージョン 5.1A 以降が動作していることが必要)。
パッチ・キットまたは NHD キットによるローリングでは,ベース・オペレーティング・システムおよびクラスタ・ソフトウェアの新リリースによるローリングと同じ手順を使用します。違いは,インストール段階で実行するコマンドです。
ベース・オペレーティング・システムおよびクラスタ・ソフトウェアをアップグレードする場合は,インストール段階で
installupdate
コマンドを使用します
パッチ・キットをロールする場合は,インストール段階で
dupatch
を実行します。インストール段階で,複数のパッチ・キットをロールするために
dupatch
を複数回実行することができます。
クラスタのノーロール・パッチを実行する場合は,clu_upgrade
コマンドは実行せずに,dupatch
コマンドをマルチユーザ・モードで起動しているクラスタ・メンバから実行します。
ノーロール・パッチはパッチを迅速に適用し,リブートの数を減らすことができます。ノーロール・パッチは 1 回の操作でクラスタにパッチをあてることができます。ただし,操作を完了するにはクラスタ全体をリブートする必要があるため,クラスタはその間利用することができません。詳細については,インストールしようとしているパッチ・キットに添付の 『Patch Kit Installation Instructions』 を参照してください。
NHD キットをインストールするには,インストール段階で
nhd_install
を実行します。
この章では,ローリング・アップグレードという用語を,ソフトウェア・キットのロール手順全体を表す用語として使用しています。
図 7-1 に示すように,1 回のローリング・アップグレードで複数の作業を行うことができます。
クラスタでバージョン 5.1A またはバージョン 5.1B が動作している場合は,ローリング・アップグレードとして,表 7-1
に示す作業を行うことができます。
表 7-1: バージョン 5.1A および バージョン 5.1B で行えるローリング・アップグレード作業
バージョン 5.1A から バージョン 5.1B へのアップデート・インストレーション バージョン 5.1B から次のリリースへのアップデート・インストレーション |
バージョン 5.1A のパッチ バージョン 5.1B のパッチ |
NHD (New Hardware Delivery) キットの バージョン 5.1A クラスタへのインストール NHD キットの バージョン 5.1B クラスタへのインストール |
ベース・オペレーティング・システムおよびクラスタ・ソフトウェアのバージョン 5.1A から バージョン 5.1B へのアップデート・インストレーションと,その後に行う &W4TCRversion のパッチ ベース・オペレーティング・システムおよびクラスタ・ソフトウェアの バージョン 5.1B から次のリリースへのアップデート・インストレーションと,その後に行う次のリリースのパッチ [脚注 5] |
バージョン 5.1A のクラスタへの NHD インストレーションと,その後に行うバージョン 5.1A のパッチ バージョン 5.1B のクラスタへの NHD インストレーションと,その後に行う バージョン 5.1B のパッチ |
バージョン 5.1A からバージョン 5.1B へのアップデート・インストレーションと,その後に行う &W4TCRversion への NHD キットのインストレーション ベース・オペレーティング・システムとクラスタ・ソフトウェアのバージョン 5.1B から次のリリースへのアップデート・インストレーションと,その後に行う次のリリースへの NHD キットのインストレーション [脚注 6] |
バージョン 5.1A から バージョン 5.1B へのアップデート・インストレーションと,その後に行う バージョン 5.1Bへの NHD キットのインストレーション,およびその後に行うバージョン 5.1B のパッチ バージョン 5.1B から次のリリースへのアップデート・インストレーションと,その後に行う次のリリースへの NHD キットのインストレーション,およびその後に行う次のリリースへのパッチ [脚注 6] |
7.2 ローリング・アップグレードでサポートされていない作業
ローリング・アップグレード中に実行できない作業,または実行しないことを推奨する作業のリストを以下に示します。
/var/adm/update
ディレクトリにあるファイルは削除も変更もしないでください。このディレクトリにあるファイルは,ロール処理にとって非常に重要です。削除するとローリング・アップグレードが失敗するおそれがあります。
インストール段階では,installupdate
コマンドより先に
dupatch
コマンドを実行することはできません。ローリング・アップグレードを実行する前に現在のソフトウェアにパッチをあてるには,ローリング・アップグレード操作を 2 回 (現在のソフトウェアに対するパッチを 1 回とアップデート・インストレーションを 1 回) 実行する必要があります。
ベース・オペレーティング・システムとクラスタ・ソフトウェアをローリング・アップグレードする際は,バージョンをスキップできません。あるバージョンからすぐ次のバージョンへのローリングができるだけです。実施可能なアップグレード・パスについては 表 1-1 を参照してください。
以下のサブセットの追加または削除の際に,/usr/sbin/setld
コマンドを使用しないでください。
ベース・オペレーティング・システム・サブセット (接頭文字
OSF
のついたもの)。
TruCluster Server サブセット (接頭文字
TCR
のついたもの)。
各国語サポート (WLS) サブセット (接頭文字
IOSWW
のついもの)。
ロール中にこれらのサブセットを追加または削除すると,タグ付きファイルが一致しなくなります。
ロール中にレイヤード・プロダクトをインストールしないでください。
最初にロールするメンバに製品の新バージョンをインストールできること,および複数のバージョンが混在するクラスタでレイヤード・プロダクトが動作できることが,レイヤード・プロダクトのドキュメントに特記されていない場合は,新しいレイヤード・プロダクトまたは現在インストールされているレイヤード・プロダクトの新バージョンをローリング・アップグレード中にインストールしないでください。
レイヤード・プロダクトおよびローリング・アップグレードについての詳細は 7.10 節を参照してください。
この節の手順では,特に明記しない限りコマンドはマルチユーザ・モードで実行します。各段階の手順は,それぞれの対応する項で詳しく説明します。ローリング・アップグレードを実行する場合は,その前に 7.7 節で各段階の詳しい説明を参照されることをお勧めします。
ローリング・アップグレードの段階の中には,他の段階よりも時間のかかるものがあります。表 7-2
に,各段階を完了するまでのおおよその所要時間をまとめています。
表 7-2: ローリング・アップグレードの各段階における所要時間
段階 | 所要時間 |
準備 | プログラム制御ではない。 |
セットアップ | 45〜120分。 [脚注 7] |
プリ・インストール | 15〜30分。 [脚注 7] |
インストール | 単一システムで
installupdate ,dupatch ,nhd_install ,またはこれらのコマンドの有効な組み合わせを実行する時間。 |
ポスト・インストール | 1 分未満。 |
ロール (メンバごと) | パッチ : 5 分未満。 アップデート・インストレーション : メンバの追加にかかる時間とほぼ同じ。 [脚注 8] |
スイッチ | 1 分未満。 |
クリーンアップ | 30〜90 分。 [脚注 7] |
以下の手順で,TruCluster Server バージョン 5.1A クラスタをバージョン 5.1B にアップグレードします。すでにバージョン 5.1B になっているクラスタをアップグレードする場合も同じです。
ローリング・アップグレードを実行するために,次のようにクラスタを準備します (7.7.1 項)。
先行メンバ (最初にロールするメンバ) として使用するクラスタ・メンバを選択します。この手順の例では,memberid
が
2
のメンバを先行メンバとして使用します。メンバのホスト名は,provolone
です。
クラスタのバックアップをとります。
インストール段階でアップデート・インストレーションを実行する場合は,クラスタにインストールされている表 7-6 のブロッキング・レイヤード・プロダクトを削除します。
任意のクラスタ・メンバで次のように
clu_upgrade -v check setup
lead_memberid
コマンドを実行し,クラスタをアップグレードする準備ができているかどうかを確認します。
# clu_upgrade -v check setup 2
ファイル・システムでより多くの空き容量が必要な場合は,addvol
などの AdvFS Utilities を使用して,必要なボリュームをドメインに追加します。必要なディスク・スペースについては,7.7.1 項を参照してください。AdvFS ドメインの管理方法については,Tru64 UNIX 『AdvFS 管理ガイド』を参照してください。
各システムのファームウェアが新しいソフトウェアをサポートしていることを確認します。ローリング・アップグレードの前に,必要に応じてファームウェアをアップデートします。
セットアップ段階を実行します (7.7.2 項)。
注意
現在のクラスタがバージョン 5.1A 以降である場合に,このインストール段階でベース・オペレーティング・システムとクラスタ・ソフトウェアをアップグレードする予定があれば,新しい TruCluster Server キットの入っているデバイスまたはディレクトリをマウントし,その後で
clu_upgrade setup
を実行します。setup
コマンドを実行すると,そのキットが/var/adm/update/TruClusterKit
ディレクトリにコピーされます。現在のクラスタがバージョン 5.1A 以降である場合に,インストール段階で NHD キットをインストールする予定があれば,新しい NHD キットの入っているデバイスまたはディレクトリをマウントし,その後で
clu_upgrade setup
を実行します。setup
コマンドを実行すると,そのキットが/var/adm/update/NHDKit
ディレクトリにコピーされます。
次の例のように,任意のメンバで
clu_upgrade setup
lead_memberid
コマンドを実行します。
# clu_upgrade setup 2
clu_upgrade
コマンドで表示されるメニューを
7.7.2 項
に示します。
セットアップ段階が完了すると,clu_upgrade
はプロンプトを表示して,先行メンバ以外の全クラスタ・メンバのリブートを求めます。
先行メンバ以外のすべてのクラスタ・メンバを一度に 1 つずつリブートします。これらのメンバがリブートされるか停止されるまで,プリ・インストール段階を開始しないでください。
プリ・インストール段階を実行します (7.7.3 項)。
先行メンバで,次のコマンドを実行します。
# clu_upgrade preinstall
現在のクラスタがバージョン 5.1A 以降である場合は,preinstall
コマンドを実行するときに,セットアップ段階で作成されたタグ付きファイルがあるかどうかを,必要に応じて確認することができます。
セットアップ段階を完了したばかりで,タグ付きファイルを削除するような操作をまだ行っていない場合は,このテストを省略してもかまいません。
セットアップ段階を完了してから時間が経過して,どうすべきかがよくわからなくなった場合は,preinstall
を実行して,タグ付きファイルが正しいかどうかをテストしてください。
インストール段階を実行します (7.7.4 項)。
注意
インストール段階では,新しいソフトウェアを先行メンバにロードし,実質的にそのメンバをロールします。ロール段階を実行すると,この新しいソフトウェアはクラスタ内の他のメンバに広まります。
clu_upgrade
コマンドは,インストール段階ではソフトウェアをロードしません。ソフトウェアのロードはどのコマンド (installupdate
,dupatch
,nhd_install
) を実行するかで決まります。バージョン 5.1A およびバージョン 5.1B で行えるローリング・アップグレード作業とその組み合わせについては,表 7-1 を参照してください。
installupdate
コマンドの使用方法については,Tru64 UNIX の『インストレーション・ガイド』を参照してください。
dupatch
コマンドの使用方法については,パッチ・キットに添付されている Tru64 UNIX と TruCluster Server の『Patch Kit Installation Instructions』を参照してください。
nhd_install
コマンドの使用方法については,NHD キットに添付されている Tru64 UNIX の『New Hardware Delivery Release Notes and Installation Instructions』を参照してください。
インストールするソフトウェアが,シングルユーザ・モードでインストレーション・コマンドを実行しなければならないソフトウェアである場合は,次のようにして,システムを停止した後,シングルユーザ・モードでブートします。
# shutdown -h now >>> boot -fl s
注意
システムを停止してリブートすることで,クラスタに提供するサービスを最小限に抑えることができます。その結果,稼働中のクラスタがこのシングルユーザ・モードで動作するメンバに依存する度合も最小限に抑えることができます。特に,サービスのフェイルオーバを完結させるために,クラスタ・メンバを一度は「DOWN」ステータスにしなければならないサービスがあれば,メンバを停止させることで,その要求を満たすこともできます。最初にクラスタ・メンバを停止しないと,サービスが期待どおりにフェイルオーバしません。
システムがシングルユーザ・モードになったら,次のコマンドを実行します。
# 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
などのサービスを使用して,先行メンバで別名宛の通信が処理されることを確認します。クラスタで提供する重要なサービスにクライアントからアクセスできるかどうかを検査します。
問題がない場合は,先行メンバで別名の属性を元の値に再設定します。
ポスト・インストール段階を実行します (7.7.5 項)。
先行メンバで次のコマンドを実行します。
# clu_upgrade postinstall
ロール段階を実行します (7.7.6 項)。
ロール前のクラスタ・メンバをロールします。 [脚注 9]
ロールされていないメンバの数 (クォーラム・ディスクが構成されている場合はクォーラム・ディスクも含む) がクラスタ・クォーラムを維持するのに十分な場合,複数のメンバを同時にロールすることができます (並列ロール)。
メンバをロールするには,以下の手順を実行します。
次のようにして,メンバ・システムを停止させた後シングルユーザ・モードでブートします。
# shutdown -h now >>> boot -fl s
システムがシングルユーザ・モードになったら,次のコマンドを実行します。
# init s # bcheckrc # lmf reset
メンバをロールします。
# clu_upgrade roll
並列ロールを実行する場合,clu_upgrade roll
コマンドの
-f
オプションを使います。このオプションをつけると,許可の入力を求めることなく自動的にメンバをリブートします。
# clu_upgrade -f roll
ロール・コマンドは,メンバをロールすることによってクォーラムが失われないことを確認します。ロールの結果クォーラムが失われると判断した場合,メンバはロールされず,エラー・メッセージが表示されます。現在ロール中のメンバの 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.
注意
実際のロールは,リブート中に行われます。
clu_upgrade roll
コマンドは,リブート中に実行するスクリプトをセットアップします。リブートが始まると, it
(8)it
スクリプトはメンバをロールして,カスタマイズしたカーネルを構築した後,そのメンバを再度リブートして,新しくカスタマイズしたカーネルが実行されるようにします。メンバが新しくカスタマイズしたカーネルをブートすると,ロールは終了し,タグ付きファイルを使用しないで動作するようになります。
スイッチ段階を実行します (7.7.7 項)。
すべてのメンバをロールした後,任意のメンバで
switch
コマンドを実行します。
# clu_upgrade switch
クラスタ・メンバを一度に 1 つずつリブートします。
クリーンアップ段階を実行します (7.7.8 項)。
任意のメンバで次のコマンドを実行し,クラスタのタグ付きファイル (.Old..
) を削除して,アップグレードを完了します。
# clu_upgrade clean
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
...]]
製品コードを指定しないと,クラスタ内のすべてのタグ付きファイルが検査されます。
注意
ロール中,クラスタには 2 つのバージョンの
clu_upgrade
コマンドが存在することがあります。2 つのバージョンとは,ロール前のメンバで使用する旧バージョン,および新バージョン (アップデート配布キットまたはパッチ・キットに含まれる場合) です。status
コマンドで表示される情報がロール前のメンバとロール後のメンバでは異なることがあります。そのため,2 つのメンバでstatus
コマンドを実行した場合は,出力表示の形式が異なることがありますので注意してください。
installupdate
を実行した後でclu_upgrade status
を実行すると,clu_upgrade
はメッセージを表示して,インストール段階が完了していることを通知してきます。しかし,実際には,clu_upgrade postinstall
コマンドを実行するまでインストール段階は完了していません。
clu_upgrade undo
コマンドでは,スイッチ段階を完了していないローリング・アップグレードを取り消すことができます。スイッチ段階とクリーンアップ段階を除いて,どの段階でも取り消すことができます。段階の取り消しは正しい順序で行わなければなりません。たとえば,プリ・インストール段階を完了した後でローリング・アップグレードを取り消す場合は,プリ・インストール段階を取り消してから,セットアップ段階を取り消します。
注意
段階を取り消す前に,関連するバージョンの 『クラスタ・リリース・ノート』 を読み,段階の取り消しに関連する制約事項があるかどうかを調べておくようお勧めします。
段階を取り消すには,取り消す段階を指定して
undo
コマンドを実行します。clu_upgrade
コマンドでは,指定した段階が取り消し可能であるかどうかを確認します。段階を取り消すための条件については,表 7-3
を参照してください。
表 7-3: 各段階の取り消し
取り消す段階 | コマンド | 説明 |
セットアップ | clu_upgrade undo setup |
このコマンドは,先行メンバで実行する。また,セットアップ段階を取り消す場合は,どのメンバもタグ付きファイルを使用して実行できない。 セットアップ段階を取り消す前に, タグ付きファイルを使用して実行中のメンバがない場合は,先行メンバで
|
プリ・インストール | clu_upgrade undo preinstall |
このコマンドは,先行メンバで実行する。 |
インストール | clu_upgrade undo
install |
このコマンドは,先行メンバ以外のメンバで実行する。 先行メンバを停止し,この先行メンバのブート・ディスクにアクセスできるメンバで
|
ポスト・インストール | clu_upgrade undo
postinstall |
このコマンドは,先行メンバで実行する。 |
ロール | clu_upgrade undo roll
memberid |
このコマンドはロール段階を取り消すメンバ以外のメンバで実行できる。 ロール段階を取り消すメンバを停止する。停止したメンバのブート・ディスクにアクセスできる他のメンバで
|
ローリング・アップグレード全体の流れは,
clu_upgrade
(8)clu_upgrade
コマンドを使用して制御します。このコマンドを使用すれば,正しい順序で各段階を実行することができます。インストール段階では,installupdate
,dupatch
,および
nhd_install
のうちの 1 つまたは複数を使用して,ソフトウェアのロードとインストールを実行することができます。これらのコマンドはローリング・アップグレードに対応しています。つまり,ローリング・アップグレードのインストール段階とロール段階でどの動作が許可されているかを判断できるようになっています。
ローリング・アップグレードを開始すると,クラスタは以前のリリースからソフトウェアを実行します。ローリング・アップグレードの最初の部分では,以前からクラスタにインストールされている
clu_upgrade
コマンドを実行します。ローリング・アップグレード中に新しいバージョンがインストールされた場合,コマンドのバージョンの違いにより画面表示や動作が多少異なることがあります。
インストールするキットにアップグレード・コマンドの新しいバージョンが含まれていた場合にローリング・アップグレードのどの段階でその新バージョンが使用できるようになるかを,以下の 2 つの表に示します。 [脚注 10]
表 7-4 は,バージョン 5.1A からバージョン 5.1B へローリング・アップグレードする場合,パッチ・キット,または NHD キットを適用する場合,またはバージョン 5.1B のベース・オペレーティング・システムおよびクラスタ・ソフトウェアへローリング・アップグレードした後に続けて新ソフトウェアのパッチをあてる場合の,コマンドと段階との対応を示しています。
表 7-5 は,オペレーティング・システムとクラスタ・ソフトウェアを バージョン 5.1B から次のリリースへローリング・アップグレードする場合,バージョン 5.1B パッチ・キット,または NKD キットを適用する場合,および,次のリリースのベース・オペレーティング・システムおよびクラスタ・ソフトウェアへローリング・アップデートした後に続けて新しいソフトウェアにパッチをあてる場合の,コマンドと段階との対応を示しています。
表 7-4: バージョン 5.1A からローリング・アップグレードする場合の段階と clu_upgrade のバージョンとの対応
段階 | バージョン 5.1A | 次のリリース [脚注 11] | 説明 |
準備 | X | 現在インストールされている (旧) バージョンの
clu_upgrade
が常に実行される。 |
|
セットアップ | X | 現在インストールされている (旧) バージョンの
アップデート・インストレーションを行う場合は
|
|
プリ・インストール | X | ローリング・アップグレードでアップデート・インストレーションを行う場合は,どのメンバも,セットアップ段階の途中でインストールされた新バージョンの
clu_upgrade
を使用する (それ以外の場合は,どのメンバも現バージョンの
clu_upgrade
を継続して使用する)。 |
|
インストール | X | ローリング・アップグレードでアップデート・インストレーションを行う場合は,どのメンバも,セットアップ段階の途中でインストールされた新バージョンの
アップデート・インストレーションの途中で, パッチ・キットを適用すると,常に最新バージョンの
パッチ・キットに新しいバージョンの
|
|
ポスト・インストール | X | セットアップ段階またはインストール段階のいずれかで新しいバージョンの
clu_upgrade
がインストールされた場合は,どのメンバもすべて新バージョンを使用する。 |
|
ロール | X | セットアップ段階またはインストール段階のいずれかで新しいバージョンの
clu_upgrade
がインストールされた場合は,どのメンバもすべて新バージョンを使用する。 |
|
スイッチ | X | セットアップ段階またはインストール段階のいずれかで新しいバージョンの
clu_upgrade
がインストールされた場合は,どのメンバもすべて新バージョンを使用する。 |
|
クリーンアップ | X | セットアップ段階またはインストール段階のいずれかで新しいバージョンの
clu_upgrade
がインストールされた場合は,どのメンバもすべて新バージョンを使用する。 |
表 7-5: バージョン 5.1B からローリング・アップグレードする場合の段階と clu_upgrade のバージョンとの対応
段階 | バージョン 5.1B | 次のリリース [脚注 12] | 説明 |
準備 | X | この段階では,現在インストールされている (旧) バージョンの
clu_upgrade
が常に実行される。 |
|
セットアップ | X | この段階では,現在インストールされている (旧) バージョンの
アップデート・インストレーションを実行する場合は, |
|
プリ・インストール | X | ローリング・アップグレードでアップデート・インストレーションを行う場合は,どのメンバも,セットアップ段階の途中でインストールされた新バージョンの
clu_upgrade
を使用する (それ以外の場合は,どのメンバも現バージョンの
clu_upgrade
を継続して使用する)。 |
|
インストール | X | ローリング・アップグレードでアップデート・インストレーションを行う場合は,どのメンバも,セットアップ段階の途中でインストールされた新バージョンの
アップデート・インストレーションの途中で, パッチ・キットを適用すると,常に最新バージョンの
パッチ・キットに新しいバージョンの
|
|
ポスト・インストール | X | セットアップ段階またはインストール段階のいずれかで新しいバージョンの
clu_upgrade
がインストールされた場合は,どのメンバもすべて新バージョンを使用する。 |
|
ロール | X | セットアップ段階またはインストール段階のいずれかで新しいバージョンの
clu_upgrade
がインストールされた場合は,どのメンバもすべて新バージョンを使用する。 |
|
スイッチ | X | セットアップ段階またはインストール段階のいずれかで新しいバージョンの
clu_upgrade
がインストールされた場合は,どのメンバもすべて新バージョンを使用する。 |
|
クリーンアップ | X | セットアップ段階またはインストール段階のいずれかで新しいバージョンの
clu_upgrade
がインストールされた場合は,どのメンバもすべて新バージョンを使用する。 |
この節では,ローリング・アップグレードの各段階について説明します。
注意
以降の各項では,各段階の概要を説明します。ローリング・アップグレードを実行する場合は,7.3 節で示す手順に従ってください。
準備段階 (7.7.1 項)
セットアップ段階 (7.7.2 項)
プリ・インストール段階 (7.7.3 項)
インストール段階 (7.7.4 項)
ポスト・インストール段階 (7.7.5 項)
ロール段階 (7.7.6 項)
スイッチ段階 (7.7.7 項)
クリーンアップ段階 (7.7.8 項)
コマンド | 実行場所 | 実行レベル |
clu_upgrade -v check setup
lead_memberid |
任意のメンバ | マルチユーザ・モード |
準備段階では,クラスタの重要なデータをすべてバックアップし,クラスタをロールする準備ができているかどうかを検査します。ローリング・アップグレードの開始前に,次の操作を行います。
最初にロールするメンバを,1 つ選択します。このメンバを先行メンバと呼びます。先行メンバは,ルート (/
),/usr
,/var
,および
i18n
(使用されている場合) ファイル・システムに対して直接アクセスできる必要があります。
先行メンバで重要なアプリケーションを実行できることを確認します。これらのアプリケーションをテストできるのは,インストール段階でこのメンバをアップデートしてから他のメンバをロールするまでの間です。問題が発生した場合は,次へ進む前にこのメンバで問題を解決します。問題を解決できない場合は,ローリング・アップグレードを取り消して,クラスタをロール前の状態に戻します (ローリング・アップグレードの各段階を取り消す方法については,7.5 節を参照)。
クラスタ単位のルート (/
),/usr
,および
/var
ファイル・システム,およびこれらのファイル・システムに含まれるメンバ固有のファイルすべてのバックアップをとってください。クラスタに独立した
i18n
ファイル・システムが含まれている場合は,このファイル・システムのバックアップもとります。また,他にも重要なユーザ・データやアプリケーション・データを格納したファイル・システムがある場合は,そのファイル・システムのバックアップもとってください。
注意
ローリング・アップグレード中に実行するクラスタの増分バックアップまたフル・バックアップは,タグ付きファイルで実行しているメンバ以外のメンバだけを対象にしてください。タグ付きファイルを使用しているメンバからバックアップをとると,
.Old..
ファイルの内容のみのバックアップをとることになります。先行メンバではタグ付きファイルを使用しないので,ローリング・アップグレード中は,先行メンバ (またはロール済みの他のメンバ) からクラスタのバックアップをとることができます。通常のサイトでは,バックアップ手順が自動化されています。クラスタのローリング・アップグレード中に自動バックアップが実行されることがわかっている場合は,そのバックアップが先行メンバまたはロール済みのメンバで実行されることを確認してください。
インストール段階で
installupdate
コマンドを実行する場合は,表 7-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 の空き容量の確保を推奨。
注意
addvol
コマンドを使用してメンバのルート・ドメイン (メンバのブート・ディスク上のパーティション) にボリュームを追加することはできません。ボリュームを追加する場合は,クラスタからそのメンバを削除して,diskconfig
または SysMan を用いてディスクを適切に構成した後,そのメンバをクラスタに戻さなければなりません。
パッチ・キットをインストールする場合は,パッチ・キットに添付されている 『Patch Kit Installation Instructions』 を参照し,このパッチ・キットのインストールに必要な空きディスク容量を確認する。NHD キットをインストールする場合は,NHD キットに添付されている 『New Hardware Delivery Release Notes and Installation Instructions』 を参照し,このパッチ・キットのインストールに必要な空きディスク容量を確認する。
ファイル・システムにより多くの空き容量が必要な場合は,addvol
などの AdvFS Utilities を使用して,必要に応じてドメインにボリュームを追加します。AdvFS ドメインの管理方法については,Tru64 UNIX 『AdvFS 管理ガイド』を参照してください (AdvFS Utilities は別ライセンスが必要)。クラスタ単位のルート (/
) ドメインは拡張することができます。
注意
clu_upgrade
コマンドは,ローリング・アップグレードを開始するときにディスク容量を確認します。ただし,ローリング・アップグレード中は,クラスタ・メンバがディスク容量を消費することを防止できないので,後の段階でディスク容量が不足することもあります。必要なディスク容量は場合に応じて変わってきます。ローリング・アップグレード中にメンバがディスク容量を大量に消費することがわかっている場合には,アップグレードの前に容量を追加しておいてください。
コマンド | 実行場所 | 実行レベル |
clu_upgrade setup
lead_memberid |
任意のメンバ | マルチユーザ・モード |
セットアップ段階では,clu_upgrade check setup
コマンドを実行してタグ付きファイルを作成し,クラスタをロールする準備をします。
clu_upgrade setup
lead_memberid
では,次のタスクが実行されます。
ローリング・アップグレードのログ・ファイル
/cluster/admin/clu_upgrade.log
が作成される (D.3 節に
clu_upgrade.log
ファイルのサンプルがある)。
7.7.1 項の
-v check setup
テストが実行される。
アップデート・インストレーション,パッチ・キットのインストール,NHD キットのインストール,またはその組み合わせのうち何を実行するかを確認するためのプロンプトが表示される。TruCluster Server バージョン 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 Server キットの場所を絶対パス名で指定するためのプロンプトを表示する。TruCluster Server バージョン 5.1B クラスタでアップデート・インストレーションを含むローリング・アップグレードを実行する場合は,clu_upgrade setup
コマンドを実行する前に,TruCluster Server キットをマウントすること。
TruCluster Server バージョン 5.1B クラスタで NHD インストレーションを実行する場合は,nhd_install
コマンドを使用して NHD キットを
/var/adm/update/NHDKit
にコピーする。
警告
/var/adm/update
にあるファイルは,ロール処理にとって非常に重要です。 このディレクトリのファイルは削除も変更もしないでください。 削除したり変更したりすると,ローリング・アップグレードが失敗するおそれがあります。
OSF
(ベース),TCR
(クラスタ),および
IOS
(各国語サポート) 製品に対して必要なタグ付きファイル・セットが作成される。
警告
アップグレード中にレイヤード・プロダクトのタグ付きファイルを作成する必要がある場合は,7.8 節を参照してください。
先行メンバを除くすべてのメンバで
sysconfigtab
変数が
rolls_ver_lookup=1
に設定される。rolls_ver_lookup=1
に設定されると,そのメンバでタグ付きファイルが使用される。そのため,他のメンバが
.Old..
ファイルを使用して動作している間に,先行メンバを現在のリリースからアップグレードすることができる。
先行メンバ以外のすべてのクラスタ・メンバをリブートするためのプロンプトが表示される。setup
コマンドが完了した後で,クラスタがクォーラムを保持できるようにこれらのメンバを一度に 1 つずつリブートする。その場合,複数のバージョンが混在するクラスタ内でタグ付きファイルを使用するメンバごとにリブートする必要がある。リブートが完了すると,先行メンバ以外のすべてのメンバがタグ付きファイルを使用して実行される。
コマンド | 実行場所 | 実行レベル |
clu_upgrade preinstall |
先行メンバ | マルチユーザ・モード |
プリ・インストール段階の目的は,クラスタの先行メンバで
installupdate
,dupatch
,および
nhd_install
コマンドを実行する準備ができているかどうかを確認することです。
clu_upgrade preinstall
コマンドでは,次の内容が実行されます。
このコマンドが先行メンバで実行されていること,実行中の先行メンバがタグ付きファイルを使用していないこと,および実行中の他のメンバがタグ付きファイルを使用していることが確認される。
必要に応じて,タグ付きファイルが存在すること,タグ付きファイルが製品のインベントリ・ファイルに一致すること,および各タグ付きファイルの AdvFS プロパティが正しく設定されていることが確認される (この処理には,やや時間がかかるが,セットアップ段階でタグ付きファイルを作成する操作よりは早く終了する。各段階の所要時間については,表 7-2 を参照)。
先行メンバ固有のファイルのバックアップ・コピーがディスク上に作成される。
コマンド | 実行場所 | 実行レベル |
installupdate |
先行メンバ | シングルユーザ・モード |
dupatch |
先行メンバ | シングルユーザ・モードまたはマルチユーザ・モード |
nhd_install |
先行メンバ | シングルユーザ・モード |
現在のクラスタが TruCluster Server バージョン 5.1B または バージョン 5.1Aで動作している場合は,表 7-1 に示す作業を単独または組み合わせて実行することがきます。
インストール段階は,clu_upgrade preinstall
コマンドが完了してから
clu_upgrade postinstall
コマンドを実行する直前までを指します。
注意
installupdate
を実行した後でclu_upgrade status
を実行すると,clu_upgrade
はメッセージを表示して,インストール段階が完了していることを通知します。しかし,実際にはclu_upgrade postinstall
コマンドを実行するまでインストール段階は完了していません。
installupdate
コマンドまたは
nhd_install
コマンドを実行するには,先行メンバをシングルユーザ・モードに設定する必要があります。また,dupatch
コマンドを実行する場合もシングルユーザ・モードに設定することをお勧めします。システムをシングルユーザ・モードに設定する場合は,システムを停止してから,シングルユーザ・モードでリブートします。
シングルユーザ・モードに設定されたシステムで,init s
,bcheckrc
,および
lmf reset
コマンドを実行してから
installupdate
,dupatch
,または
nhd_install
コマンドを実行します。これらのコマンドの使用方法については,Tru64 UNIX 『インストレーション・ガイド』,Tru64 UNIX および TruCluster Server の『Patch Kit Installation Instructions』,および Tru64 UNIX 『New Hardware Delivery Release Notes and Installation Instructions』を参照してください。
注意
複数のパッチをインストールするには,
dupatch
コマンドを複数回実行します。ただし,パッチ処理が完了してクラスタの使用中に問題が発生した場合,問題の特定が困難になります。インストール段階では,
installupdate
コマンドより先にdupatch
コマンドを実行することはできません。ローリング・アップグレードを実行する前に現在のソフトウェアにパッチをあてるには,ローリング・アップグレード操作を 2 回 (現在のソフトウェアに対するパッチを 1 回とアップデート・インストレーションを 1 回) 実行する必要があります。アップデート・インストレーションを含むローリング・アップグレードの一環として NHD インストレーションを行う場合は,
nhd_install
を手動で実行する必要がありません。installupdate
コマンドが NHD キットをインストールします。それ以外の場合は,セットアップ段階でclu_upgrade
がコピーしたnhd_install
コマンドを使用します。このコマンドは/var/adm/update/NHDKit/nhd_install
にあります。
コマンド | 実行場所 | 実行レベル |
clu_upgrade postinstall |
先行メンバ | マルチユーザ・モード |
ポスト・インストール段階では,先行メンバでアップデート・インストレーション,パッチ,または NHD インストレーションが完了したことを確認します。アップデート・インストレーションを実行した場合は,先行メンバが新しいバージョンのベース・オペレーティング・システムにアップグレードされたことを
clu_upgrade postinstall
コマンドで確認します。
7.7.6 ロール段階
コマンド | 実行場所 | 実行レベル |
clu_upgrade roll |
ロール中のメンバ | シングルユーザ・モード |
インストール段階では先行メンバをアップグレードしましたが,他のメンバはロール段階でアップグレードします。
多くのクラスタ構成では,複数のメンバを並列でロールし,クラスタ・アップグレードに必要な時間を短縮することができます。並列的にロールできるメンバの数は,ロールされていないメンバ (クォーラム・ディスクが構成されている場合は,クォーラム・ディスクを含む) がクォーラムを維持するのに十分なボートを持つ必要があるという要件によってのみ制限されます。並列ロールは,先行メンバがロールされた後にだけ実行することができます。
clu_upgrade roll
コマンドでは,次のタスクが実行されます。
メンバが先行メンバでないこと,メンバがロール前であること,およびメンバがシングルユーザ・モードであることが確認される。メンバをロールすることにより,クォーラムが失われないことが確認される。
メンバ固有のファイルのバックアップがとられる。
リブート時にロールを実行するための
it
(8)
メンバがリブートされる。ブート中に
it
スクリプトによりメンバがロールされ,カスタマイズされたカーネルが作成される。そのカーネルで,リブートされる。
注意
ローリング・アップグレードの途中でクラスタにメンバを追加しなければならない場合は,ロールを完了したメンバからそのメンバを追加してください。
すべてのメンバをロールし終える前にあるメンバがダウンして修復もリブートもできない場合は,クラスタのロールを完了させるために,そのメンバを削除しなければなりません。ただし,1 つのメンバを除いてすべてのメンバのロールが完了しているという状態で,ロールの完了していないそのメンバがロール段階でリブートする前にダウンした場合は,そのメンバを削除してから他のクラスタ・メンバをリブートする必要があります。clu_upgrade
はリブート中も動作して,クラスタに現在あるメンバの数に対してロールされたメンバがどれだけあるかを追跡します。clu_upgrade
は,それら 2 つの値が同じになると,ロール段階が完了したものとしてマークします。そのため,1 つのメンバを除いてすべてのメンバをロールした場合,ロールされていないメンバを削除して他のメンバをリブートすることにより,ロール段階が完了し,ローリング・アップグレードが継続できます。
7.7.7 スイッチ段階
コマンド | 実行場所 | 実行レベル |
clu_upgrade switch |
任意のメンバ | マルチユーザ・モード すべてのメンバが起動している [脚注 13] |
スイッチ段階では,ソフトウェアのアクティブ・バージョンを新バージョンに設定します。その結果,ローリング・アップグレード中に無効にしておいた新機能が有効になります (アクティブなバージョンと新バージョンについての説明は,7.9 節を参照してください)。
clu_upgrade switch
コマンドでは,次のタスクが実行されます。
すべてのメンバのロールが完了したこと,すべてのメンバで同じバージョンのオペレーティング・システムとクラスタ・ソフトウェアが実行されていること,およびタグ付きファイルを使用して実行されているメンバがないことが確認される。
各メンバの
sysconfigtab
ファイルと実行中のカーネルに新しいバージョンの ID が設定される。
すべてのクラスタ・メンバでアクティブ・バージョンが新バージョンに設定される。
注意
スイッチ段階の終了後は,クラスタ・メンバを一度に 1 つずつリブートする必要があります。
コマンド | 実行場所 | 実行レベル |
clu_upgrade clean |
任意のメンバ | マルチユーザ・モード |
クリーンアップ段階では,タグ付き (.Old..
) ファイルをクラスタから削除して,アップグレードを完了します。
clu_upgrade clean
コマンドでは,次のタスクが実行されます。
スイッチ段階が完了したこと,すべてのメンバで同じバージョンのオペレーティング・システムとクラスタ・ソフトウェアが実行されていること,およびタグ付きファイルを使用して実行されているメンバがないことが確認される。
すべての
.Old..
ファイルが削除される。
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
ファイルがこのアーカイブ・ディレクトリに格納される。
ローリング・アップグレードでは,一度に 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 Server (TCR
),および各国語サポート (IOS
) の製品コードを持つインベントリ・ファイルに対して作成されます。各製品のサブセットには,3 文字の製品コードから始まる名前が指定されています。たとえば,TruCluster Server のサブセット名は,TCRBASE540
,TCRMAN540
,TCRMIGRATE540
のように TruCluster Server の 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 Server のサブセット) に対して作成されたタグ付きファイルがすべて正しいかどうかが検査されます。
# clu_upgrade tagged check TCR
1 つの
.Old..
ファイルを誤って削除した場合,このファイルを再作成するために,レイヤード・プロダクト全体に対してタグ付きファイルを作成する必要があります。たとえば,vdump
コマンドが
OSF
製品の
OSFADVFS
xxx
サブセットに含まれる場合に
/sbin/.Old..vdump
を誤って削除すると,次のコマンドを実行して,レイヤード・プロダクト全体のタグ付きファイルを再作成する必要があります。
# clu_upgrade tagged add OSF
enable
コマンドと
disable
コマンドは,クラスタ・メンバごとにタグ付きファイルを使用可能または使用不能にする場合に実行します。通常,ローリング・アップグレード中には,enable
コマンドまたは
disable
コマンドを使用する必要はありません。
disable
コマンドは,セットアップ段階を取り消す場合に便利です。セットアップ段階を取り消す場合は,どのメンバもタグ付きファイルを使用して実行できないため,disable
コマンドで,現在タグ付きファイルを使用して実行されているクラスタ・メンバのタグ付きファイルを無効にします。たとえば,ID が 3 のメンバのタグ付きファイルを無効にするには,コマンドを次のように指定します。
# clu_upgrade tagged disable 3
enable
コマンドは,disable
コマンドを誤って実行した場合に使用します。
バージョン・スイッチは,アクティブ・バージョンのオペレーティング・システムから新しいバージョンのオペレーティング・システムへの移行を管理する場合に使用します。アクティブ・バージョンとは,現在使用中のバージョンを指します。クラスタでバージョン・スイッチを使用する目的は,すべてのメンバがアップデートされるまで,本質的に互換性がない新機能を導入しないようにするためです。たとえば,新バージョンでカーネル構造が変更されており,現在の構造と互換性がない場合,通常は,すべてのクラスタ・メンバがその新構造をサポートするバージョンにアップデートされるまで,クラスタ・メンバで新構造を使用しません。
ローリング・アップグレードの開始時には,どのメンバでもアクティブ・バージョンは新バージョンと同じです。ローリング・アップグレードが進むにつれて各メンバで新バージョンがアップデートされます。すべてのメンバでローリング・アップグレードが終了した後のスイッチ段階で,すべてのメンバのアクティブ・バージョンが新バージョンに設定されます。アップグレードが完了すると,再びすべてのメンバのアクティブ・バージョンが新バージョンと同じになります。次の簡単な例に,アクティブ・バージョン
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
コマンドを使用して,各メンバをロールするときにバージョン・スイッチのすべてのアクティビティを管理します。すべてのメンバをロールした後のスイッチ段階で,次のコマンドを実行して新しいソフトウェアへの移行を完了させます。
# clu_upgrade switch
7.10 ローリング・アップグレードとレイヤード・プロダクト
ここでは,レイヤード・プロダクトとローリング・アップグレードの相互作用を次の項に分けて説明します。
clu_upgrade setup
コマンドは,クラスタでオペレーティング・システムをローリング・アップグレードするための準備を行います。clu_upgrade setup
コマンドを実行してから最初のメンバを新しいバージョンにロールするまでの間は,setld
コマンドを用いてクラスタにソフトウェアをロードしないでください。clu_upgrade setup
コマンドを実行してからクラスタ・メンバを新しいバージョンにロールするまでの間にソフトウェアをインストールすると,新しいファイルは
clu_upgrade setup
で処理されなくなります。その結果,最初のクラスタ・メンバをロールする際に,その新しいファイルが上書きされてしまいます。
ソフトウェアをロードしなければならない場合は,次のような方法で行ってください。
少なくとも 1 つのメンバがロールされるまで待つ。
ロールされたメンバでソフトウェアをインストールする。
ブロッキング・レイヤード・プロダクトは,installupdate
コマンドによるアップデート操作を妨げる製品です。installupdate
コマンドを実行するローリング・アップグレードの開始前にクラスタからブロッキング・レイヤード・プロダクトを削除する必要があります。クラスタにパッチをあてるため,または NHD キットをインストールするためだけにローリング・アップグレードを実行する場合は,ブロッキング・レイヤード・プロダクトを削除する必要はありません。
表 7-6
は,このリリースのブロッキング・レイヤード・プロダクトをまとめたものです。
表 7-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 |
注意
3 文字の製品コードは,サブセット名の最初の 3 文字です。たとえば,ATMBASExxx という名前のサブセットは,ブロッキング・レイヤード・プロダクトの 1 つである ATM 製品 (Atom Advanced Developers Kit) の一部です。OSFATMBINxxx というサブセットは名前に ATM を含みますが,このサブセットはブロッキング・レイヤード・プロダクトの一部ではありません。これは OSF 製品 (ベース・オペレーティング・システム) のサブセットです。
ブロッキング・レイヤード・プロダクトをローリング・アップグレードの一環として削除すると,すべてのメンバからブロッキング・レイヤード・プロダクトが削除されます。ブロッキング・プロダクトに依存するサービスは,ロールが完了し,ブロッキング・レイヤード・プロダクトが再インストールされた後で使用できるようになります。
ローリング・アップグレードのインストール段階を実行する場合,CD-ROM またはリモート・インストレーション・サービス (RIS) サーバからベース・オペレーティング・システムのサブセットをロードすることができます。
注意
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
で表されます。アドレスの作成方法は,次のとおりです。
省略時の vMAC 接頭文字: AA:01 クラスタ別名の IP アドレス: 16.140.112.209 16 進数形式の IP アドレス: 10.8C.70.D1 この別名の vMAC : AA:01:10:8C:70:D1
8 つの 16 進数で構成される任意の文字列を vMAC の省略時の接頭文字 (AA:01
) に追加して,ハードウェア・アドレスを作成することもできます (例
AA:01:00:00:00:00
)。このアドレスが RIS サーバからサービスされる領域内で一意であることを確認してください。クラスタが複数ある場合に次の別名を追加するには,16 進数の任意の文字列の値を大きくしてください (vMAC アルゴリズムを使用すると,ネットワーク内で一意のアドレスを作成できる可能性が高いので便利です)。