この章では,TruCluster Production Server Software あるいは TruCluster Available Server Software バージョン 1.5 またはバージョン 1.6 から TruCluster Server バージョン 5.1B にアップグレードする際の注意事項について説明します (この章の主な焦点は Production Server および Available Server クラスタのアップグレードですが,8.9 節で,Memory Channel Software を実行するクラスタのアップグレードも説明しています)。
注意
この章では,便宜上,バージョン 1.5 または 1.6 の TruCluster Production Server Software クラスタ,あるいは TruCluster Available Server Software を指すのに 「ASE」という用語を使用し,新しい TruCluster Server バージョン 5.1B クラスタを指すのに「クラスタ」という用語を使用します。
この章では,次の 3 つのアップグレード・パスについて説明します。これらのパスは,TruCluster Production Server Software あるいは TruCluster Available Server Software バージョン 1.5 またはバージョン 1.6 からのアップグレードに使用します。
オプション 1 : 新しいシステムと新しいストレージ・ハードウェアを使用して別のクラスタを作成する。新しいクラスタが完全に構成されてテストされた後,データを ASE から新しいクラスタに移行する。
オプション 2 : 新しいシステムとクラスタおよびテスト・アプリケーションを作成するのに十分な新しいストレージを使用して,別のクラスタを作成する。新しいクラスタが完全に構成されてテストされた後,ASE から新しいクラスタへ古いストレージを物理的に移動する。
オプション 3 : 既存のハードウェアとストレージを使用したまま,ASE をアップグレードする。ASE から 1 つのメンバを削除して取り外し,そのシステムで Tru64 UNIX バージョン 5.1B をインストールおよび構成して,ASE 内の他のシステムをシャットダウンする。ASE のストレージを Tru64 UNIX バージョン 5.1B システムに接続して,そのストレージを構成し,シングル・メンバ・クラスタを作成したのち,他のシステムを新しいクラスタに追加する。
注意
バージョン 1.5 より前の TruCluster Production Server Software または TruCluster Available Server Software 製品では,Tru64 UNIX バージョン 5.1B と TruCluster Server バージョン 5.1B のフル・インストレーションを行う必要があります。
TruCluster 製品に対してサポートされているアップグレード・パスのリストについては,表 1-1 を参照してください。
これとは別に,現在の構成と用途に応じて独自のカスタマイズ手順を設計することもできます。8.8 節に,オプション 3 を一部変更した手順をケース・スタディとして示しています。他のケース・スタディについては以下の URL をご覧ください。そこには,社内の運用レベルのクラスタを TruCluster Production Server バージョン 1.6 からパッチ・キットを含めた TruCluster Server バージョン 5.0A にアップグレードする場合の説明が記載されています。
http://www.tru64unix.compaq.com/docs/highavail/index.htm
この章で説明する内容は次のとおりです。
別のクラスタを作成するか,または既存クラスタをアップグレードするかの決定方法 (8.1 節)
ストレージとクラスタ・インターコネクトに関する制約事項のリスト (8.2 節)
アップグレードの準備方法 (8.3 節)
オプション 2 およびオプション 3 で使用されるアップグレード・スクリプトの説明 (8.4 節)
オプション 1 : 別のクラスタの作成 新しいシステムと新しいストレージを使用 (データのみ移行) (8.5 節)
オプション 2 : 別のクラスタの作成 新しいシステムを使用し,既存のストレージを移行 (物理ストレージを移動) (8.6 節)
オプション 3 : 既存 ASE のアップグレード 既存のシステムおよびストレージを使用 (8.7 節)
オプション 3 の手順を一部変更した手順を使用したアップグレードのケース・スタディ (8.8 節)
TruCluster Server Memory Channel Software 製品を実行しているクラスタをアップグレードするためのアプローチ (8.9 節)
アップグレードの準備については,第 1 章
〜
第 5 章を参照してください。
8.1 別のクラスタを作成するか既存クラスタをアップグレードするかの決定
アップグレードのための多数のアプローチの中から,この章では,ASE からクラスタにアップグレードするための 3 つの方法について説明します。
オプション 1 : すべて新しいシステム・ハードウェアとストレージで別個のクラスタを作成する。このクラスタは,テスト専用に設計された 2 ノードの最小構成から本格的な運用レベルのクラスタまで作成できる。
この方法 (新しいシステムと新しいストレージ) では,現在のハードウェア構成の制約,あるいは,Tru64 UNIX バージョン 4.x オペレーティング・システムまたはバージョン 1.5/1.6 の TruCluster Software 製品における制約を受けずに,新しいクラスタを作成できます。たとえば,HSG80 コントローラと Fibre Channel を使用して新たに NSPOF (no-single-point-of-failure) クラスタを作成できます。
次に,以前の ASE を新しいバージョン 5.1B クラスタと並行して実行します。この構成では,既存の ASE からクライアントにサービスを提供する一方で,新しいクライアントでアプリケーションを広範囲にテストできます。新しいクラスタに満足した場合は,以前の ASE から新しいクラスタに (ストレージ・ハードウェアではなく) アプリケーション・データを移行します。
新しいシステムおよび新しいストレージとともに,別個のクラスタを並行して使用すると,共用されるハードウェアがなく,ASE から新しいクラスタに移されるストレージもないため,リスクは最も低くなります。新しいクラスタには継続使用されるハードウェアがないため,たとえば,ハードウェアをマルチパス構成して冗長化するなど,TruCluster Server バージョン 5.1B のすべての機能を活用できます。
別個のクラスタの作成方法については,8.5 節で説明します。
オプション 2 : 新しいストレージをいくつか使用して別個のクラスタを作成するが,ASE から新しいクラスタに既存のストレージを移す。
この方法 (新しいシステムと古いストレージ) では,ASE に影響を与えることなく,新しいシステムを構成して,アプリケーションのテストを行うという限度において,ある程度の独立が提供されます。ただし,現在の ASE ストレージ構成の制約事項が,新しいクラスタにも適用されます。これらの制約事項のために,このクラスタでは新しい機能が利用できないこともあります。たとえば,古いストレージがマルチパス化をサポートしていないかもしれません。
8.6 節に,既存の ASE から新しいクラスタへストレージを移す方法と,新しいクラスタでストレージを構成する方法を示します。その節では,ストレージの移行と構成のために使用するスクリプトの処理も説明します。
注意
考慮しなければならないことの 1 つは,データの移行です。ユーザのサイトで,データのコピー (オプション 1),またはストレージの物理的な移動 (オプション 2) の利点と不利な点を判断します。たとえば,ASE に大量の共用ストレージがあり,データのバックアップを取って,新しいクラスタにリストアするのに,たいへんな時間がかかるために無理な場合は,その環境にとって,ストレージを物理的に移動するのがより良い解決方法であると決定します。
オプション 1 では,ASE とクラスタの両方が,アプリケーション・データを完全に複製したセットを持つことができるため,クライアント・サービスを ASE からクラスタへ切り替える前に,アプリケーション環境を広範囲にわたってテストして調整することができます。
オプション 2 では,ASE のストレージをクラスタへ物理的に接続した後,新しいクラスタで,ASE から移したすべてのアプリケーション・データにアクセスできるようになります。ある時点で ASE を停止し,物理ストレージ・デバイスを新しいクラスタへ移す必要があります。
オプション 3 : 既存の ASE ハードウェアを新しいクラスタのベースとして使用し,Memory Channel ハードウェア (希望する場合) とストレージを追加して,必要に応じてストレージとシステムを移行する。
この方法 (既存のシステムおよびハードウェア) では,金額的なコストを最も低く抑えることができます。ただし危険性は,完全に別個のクラスタを実行する場合よりも本質的に高まります。稼働中の ASE からメンバを削除する必要があるため,クライアントに対するサービスに利用できるシステムの数は減少します。アプリケーションのテストは,マルチ・メンバ・クラスタではなくシングル・メンバ・クラスタで行われるため,アプリケーション・フェイルオーバ・テストは実施できません。
この方法については,8.7 節で説明します。そこでは,スクリプトを使用して ASE が認識しているストレージの移行と構成を容易に行う手順についても説明します。
どの方法を採用するのがよいかがわからない場合は,決定する前に章全体をお読みになることをお勧めします。この章の情報を出発点として使用して,ニーズに合ったアプローチと手順を決定してください。8.8 節と以下の URL に,アップグレードのケース・スタディが記載されています。
http://www.tru64unix.compaq.com/docs/highavail/index.htm
これらのケース・スタディを読めば,どのアプローチを用いてアップグレードすればよいかを決定するのに役立ちます。
8.2 ストレージとクラスタのインターコネクトに関する制約事項
この節では,ASE から TruCluster Server クラスタへアップグレードする場合の一般的な制約事項を示します。既存のハードウェアをアップグレードするときには制約が厳しくなりますが,どのようなアップグレード形態であっても,同一のストレージ・バスまたは同一のクラスタ・インターコネクトにおいて ASE と新しいクラスタの両方を同時にアクティブにすることはできません。
ASE と新しいクラスタのシステムを同一のストレージ・バス上で実行してはならない。
ストレージは,ASE または新しいクラスタのいずれかによってアクセスされ,両方によってアクセスされることはありません。ASE と新しいクラスタの両方からシステムが同一のストレージ・デバイスにアクセスできる場合,データが破壊される可能性があります。ストレージを移行するときには,ASE システムを共用ストレージから物理的に分離するか,またはシステムを停止し,電源をオフにしてください。
ASE のシステムと新しいクラスタのシステムを同一のクラスタ・インターコネクト上で実行してはならない。
クラスタ・インターコネクト・ハードウェアは ASE または新しいクラスタのいずれかに稼働状態のまま接続できますが,両方には絶対に接続しないでください。ASE と新しいクラスタがどちらも同じクラスタ・インターコネクトに接続されると,システムのブート不良のために,さまざまな問題が発生するおそれがあります (マシン・チェックなど)。システムを移行するときには,既存の ASE システムをクラスタ・インターコネクトから物理的に切り離すか,またはシステムを停止し,電源をオフにしてください。
新しいクラスタの第 1 メンバになる ASE システムを停止したら,既存デバイスを新しいクラスタ上の新スタイルのデバイス名にすべてマップするまで,ストレージ・トポロジを変更してはならない。
アップグレードを開始してからデバイスを新スタイルのデバイス名にマップするまでに,ストレージ・トポロジを変更すると,Tru64 UNIX バージョン 5.1B システムにのみ認識されているデバイスが導入されます。そのため,デバイスのマッピングが正しいかどうかを確認することが困難になります。この制約は,主に,既存のハードウェアを使用してアップグレードする場合に適用されます。ただし,既存のストレージを別個のクラスタに物理的に接続する場合は,この制約が適用されます。
以降の各項で,アップグレードのための準備を行う方法について説明します。
準備を始める前に,既存の ASE と,TruCluster バージョン 5.1B の新しい機能とアーキテクチャとの相違点を理解しておく必要があります。相違点を理解したら,ユーザのサイト固有のニーズに応じたアップグレード計画を立案できます。
新しい AdvFS フォーマット,拡張 SCSI サポート,および新しいデバイス命名規則については,Tru64 UNIX 『Tru64 UNIX 概要』および『システム管理ガイド』を参照してください。
TruCluster Server バージョン 5.1B の推奨構成の詳細と,動作上および NSPOF (no-single-point-of-failure) に関する TruCluster Server バージョン 5.1B のクラスタ構成と以前の TruCluster 構成との重要な相違点については,TruCluster Server 『クラスタ・ハードウェア構成ガイド』および『クラスタ概要』を参照してください。
バージョン 5.1B クラスタで高可用性アプリケーションを実行する方法については,『クラスタ高可用性アプリケーション・ガイド』を参照してください。TruCluster Server では,高可用性サービスを提供するときに ASE パラダイムを使用しません。つまり,asemgr
コマンドも
asecdb
データベースもありません。代わりに,TruCluster Server では,クラスタ・ファイル・システム (CFS),CAA (cluster application availability),およびクラスタ別名機能を使用して,高可用性アプリケーションを提供します。
注意
Oracle や Informix などのサード・パーティから出ているアプリケーションを使用する場合は,そのアプリケーションのベンダにお問い合わせください。
新しいクラスタでハードウェア RAID を使用してファイル・システムをミラー化する場合,アップグレードは,RAID ハードウェアを追加して,マルチパス化を実施するよい機会となります。
綿密な計画を作成して,構成図を作成します。現在の環境の構成マップを作成するには,cluster_map_create -full
コマンドを実行します。マップの表示および印刷を行うには,クラスタ・モニタ (cmon
) を使用します。
ストレージを移行する場合は,すべてのケーブルとストレージにラベルを付けます。必要なハードウェアを入手します。サイト固有のファイルのコピーを作成します。いつ,何をバックアップするかを決定します。アップグレード・オプションについて説明している節の手順を参照します。その後,ユーザのサイトおよび選択したアップグレード方法に適合する詳細な手順を作成します。別個のクラスタを作成する場合でも,手順を参照すると,ストレージの移行に関する概念を得ることができます。
以下の URL に,メンバが 2 つの社内クラスタをオプション 3 でアップグレードする際の,管理者のテキスト・ログが載っています。
http://www.tru64unix.compaq.com/docs/highavail/migration/migration_log.htm
ここでは,クラスタが TruCluster Software Production Server バージョン 1.6 からパッチ・キットを含めた TruCluster Server バージョン 5.0A へアップグレードされています。これはバージョン 5.1B へのアップグレードではありませんが,計画のアプローチ方法と基本的な処理手順は同じです。
付録 A のチェックリストを使用して,新しいクラスタのホスト名,ディスク,および IP アドレスを記録します。
次のリストに,既存の ASE からのアップグレードに影響を与える可能性がある,最も一般的なハードウェアの要件を示します。これらの要件は,新しいクラスタで現在の ASE ハードウェアのいくつかまたはすべてを使用する,オプション 2 およびオプション 3 のアップグレード・パスに当てはまります。TruCluster Server バージョン 5.1B ハードウェア構成に関する正確な情報については,『クラスタ・ハードウェア構成ガイド』を参照してください。
(オプション 2) 新しいクラスタを構成する際には,ASE から新しいクラスタにストレージを接続するために,各システムに空いている SCSI アダプタが必要になります (代替方法としては,ASE アダプタをストレージとともに移動します)。
(オプション 2 およびオプション 3) アップグレード・パスがストレージの物理的な移行を伴う場合,ASE は,シンメトリックな共用ストレージ構成でなければなりません (ASE サービスが使用する各共用デバイスは,同一のスペシャル・ファイル名ですべての ASE メンバに認識されています。たとえば,すべてのメンバで,rz17c
は同一の物理デバイスを参照します)。
さらに,Production Server 環境には,ASE が 1 つだけ含まれていなければなりません。
これらが要件となっているのは,8.4 節で説明するスクリプトの自動化のためです。このスクリプトでは,現在の ASE 環境が,一意の AdvFS ドメイン名,LSM ボリューム,および ASE サービスが使用するすべての共用ストレージのデバイス・スペシャル・ファイル名を持っている必要があります。これらのスクリプトにより,ASE サービスが現在使用しているストレージを新しいクラスタへ移動する処理を自動化できます (これらの制約を満足していない ASE のあるサイトでは,付録 F で説明する,手動によるデバイス名マッピングおよびストレージ構成を使用することができます)。
現在の ASE の構成マップを作成していない場合またはマップが古い場合は,先に
cluster_map_create
(8)/etc/CCM
ファイルを作成します。
# cluster_map_create cluster_name -full
クラスタの構成マップを表示するには,クラスタ・モニタ (cmon
) を使用します。移行スクリプトを使用してアップグレード中にストレージをマップできるかどうかをこの情報から判断します (cluster_map_create
コマンドと
cmon
コマンドの詳細については,TruCluster Software Products バージョン 1.5 またはバージョン 1.6 の『管理ガイド』を参照してください)。
(オプション 3) ASE システムは,TruCluster Server バージョン 5.1B でサポートしているシステムでなければなりません。サポートされるハードウェアについては,TruCluster Server バージョン 5.1B『QuickSpecs』を参照してください。
(オプション 3) 新しいクラスタで追加のストレージ・ハードウェアが必要な場合は,アップグレードを開始する前にこのハードウェアを ASE に追加することをお勧めします。新しいクラスタには,クラスタ単位のファイル・システム,メンバ・ブート・ディスク,およびオプションのクォーラム・ディスク用の共用ストレージを設置する必要があります。HSZ または HSG タイプのストレージ・デバイスをこの共用バスに設置して,クォーラム・ディスクとメンバ・ブート・パーティションをミラー化することをお勧めします (詳細については,2.5 節で説明している,クラスタ単位のファイル・システムのミラー化に関する注意を参照してください)。
注意
クォーラム・ディスクは ASE のタイブレーカ・ディスクに類似している所がありますが,重要な違いがあります。ASE のタイブレーカ・ディスクは ASE サービスに参加していなければなりません。クォーラム・ディスクには,重要なデータは保存しないようにしてください。
システムのプライベート・バスに別個のディスクを用意し,Tru64 UNIX バージョン 5.1B をそのディスクにインストールすることをお勧めします。ASE で使用されるオペレーティング・システムを格納しているディスクにバージョン 5.1B の Tru64 UNIX オペレーティング・システムをインストールするのは,できるだけ避けてください。ASE に戻す場合,以前のオペレーティング・システムを再インストールしてこのシステムに ASE 環境を再作成するよりも,ASE オペレーティング・システムのディスクをブートする方が簡単です。
注意
TruCluster Server では,0 〜 15 の SCSI ID をサポートしています。アップグレードを開始する前に利用可能な SCSI ID がなかった場合は,Tru64 UNIX オペレーティング・システムをブートし,既存のデバイス名を新しいデバイス名にマップした後にストレージを追加できます。クラスタを作成する前に,ストレージをすべて Tru64 UNIX に接続して,認識された状態にしなければなりません。
Tru64 UNIX バージョン 5.1B および TruCluster Server バージョン 5.1B のメンバ・ブート・ディスクを LUN 0 に設置する必要はありません。
(オプション 3) 新しいクラスタで LSM を使用する場合は,2.5.2 項を参照してください。共用ドライブ上に
rootdg
ディスク・グループ用として少なくとも 1 つの利用可能なパーティションが必要となります (冗長構成にするには複数のパーティションが必要です)。クラスタ単位のルート (/
) ファイル・システムは,サイズ上の理由から通常はデバイスの
b
パーティションに配置しますが,a
パーティションを使用することもできます。
ハードウェア RAID を用いてクラスタのファイル・システムをミラー化する場合,アップグレードは,RAID ハードウェアを追加してマルチパス化を行うよい機会となります。TruCluster Server バージョン 5.1B クラスタでのストレージ構成については,『クラスタ・ハードウェア構成ガイド』 を参照してください。
TruCluster Server バージョン 5.1B クラスタは,AdvFS ファイル・システムを使用します。UFS はクラスタ単位の読み取り専用アクセスだけがサポートされています。クラスタ・メンバは UFS ファイル・システムを読み取り/書き込みでマウントできます。ただし,そのファイル・システムにアクセスできるのは,そのメンバに限られます。
注意
アップグレード時のファイル・システムの移行を簡単に行うために,TruCluster Server バージョン 5.1B では,UFS ファイル・システムの読み取り/書き込みがサポートされています。バージョン 5.1B クラスタに UFS ファイル・システムを読み取り/書き込みアクセスでマウントする場合は,特に指定しなくても
mount
コマンドに-o server_only
引数が使用されます。これらのファイル・システムはパーティション化されたファイル・システムとして扱われます。つまり,そのファイル・システムは,それをマウントしたメンバしかアクセスできません。他のクラスタ・メンバはこのファイル・システムで読み取りも書き込みも実行できません。リモート・アクセスもフェイルオーバもできません。UFS ファイル・システムを,すべてのクラスタ・メンバから読み取り専用でアクセスできるようにマウントする場合は,読み取り専用と明示してマウントしなければなりません。ファイル・システムをマウントする際に
-o server_only
引数を明示して指定すると,AdvFS ファイル・システムをパーティション化されたファイル・システムとしてマウントできます。ファイル・システムのパーティション設定については,『クラスタ管理ガイド』 と
に記載されています。 mount
(8)
新しいクラスタで読み取り/書き込みアクセスを行う予定のデータが現在の ASE で UFS ファイル・システムを通して読み取り/書き込みが行われている場合は,アップグレードを開始する前に,これらのファイル・システムを AdvFS に移行することをお勧めします (新しいクラスタの 1 メンバのみに UFS ファイル・システムへの読み取り/書き込みアクセスを制限できる場合は,ファイル・システムをパーティション化できます)。データを移行する場合,その方法は,現在の構成において,新しいストレージに AdvFS ドメインを作成するための十分なストレージがあるかどうかや,現在のストレージを再使用するために,バックアップしてリストアする必要があるかどうかによって異なります。移行ストラテジのひとつとして,UFS の読み取り/書き込みに対して TruCluster Server のローカル・サポートを使用するという方法もあります。
注意
アップグレード・パスがオプション 1 (新しいシステムと新しいストレージ) の場合には,ASE で使用されているファイル・システムを変換したり,変更したりする必要はありません。ただし,ファイル・システムのデータ移行ストラテジとしては,全メンバに読み取りと書き込みの両方ができるファイル・システムを提供するために,新しいクラスタでは AdvFS ファイル・システムを採用する必要があります。
バージョン 5.0 以降のオペレーティング・システムでは,ドメイン・バージョン番号 4 (DVN4) というディスク構造で AdvFS ドメインを作成します。DVN4 では,2 T バイト (TB) を超えるクォータ値が可能で,ディレクトリに何千ものファイルが置かれている場合の性能が向上します。バージョン 5.0 より以前に作成されたドメインは DVN3 を使用しています。これらのドメインは新しいバージョンでも認識されますが,新しいディスク構造へ自動的にアップグレードされるわけではありません。
TruCluster Server へアップグレードする作業が完了すれば,AdvFS DVN3 ドメインを DVN4 に変換できます。変換するかしないか,また,いつ変換するかは,ユーザの都合によります。Tru64 UNIX バージョン 5.1B は DVN3 と DVN4 の両方のフォーマットを認識します (mkfdmn
-V3
オプションを使用すると,新しいクラスタ上に古いスタイルの AdvFS ドメインを作成することができます)。
現在のストレージを再使用する場合,既存の ASE での UFS から AdvFS へのファイル・システム変換は,都合の良いときに行うことができますが,ファイル・システムのフォーマットは DVN3 です。現在の ASE で UFS から AdvFS へ変換しない場合は,アップグレードの一環として変換できますが,ダウンしている時間が長くなります。また,アップグレード中に問題が発生しても,ASE に戻すことは困難です。
フォーマットを変換する際,ファイル・システム上で
vdump
/vrestore
ユーティリティを実行するのに時間がかかります。新しいクラスタ上で新しい AdvFS フォーマットを活用したい場合は,次のような UFS の変換方法があります。
移行前に UFS ファイル・システムを AdvFS DVN3 ドメインへ変換してから,移行後に AdvFS DVN4 へ変換する。変換を 2 回実行することになるが,クラスタに移行すると直ちにデータの読み取り/書き込みが可能になる (ASE で UFS を AdvFS に変換し,新しいクラスタでしばらくの間継続して AdvFS DVN3 フォーマットを使用した後,DVN4 の機能を利用する必要が生じたときにドメインを DVN4 に変換することもできる)。
移行後に AdvFS へ変換する。変換は 1 回だけであるが,変換を行うまでは,読み取り/書き込みがローカル使用に限定され,クラスタ単位では読み取りしかできない (UFS ファイル・システムを新クラスタの AdvFS ドメインに移行する際は,ローカル使用限定の UFS 読み取り/書き込み機能を使用して制御することができる)。
8.4 オプション 2 およびオプション 3 で使用するアップグレード・スクリプト
次に,オプション 2 およびオプション 3 のアップグレード手順で使用する
TCRMIGRATE540
サブセット内のスクリプトを示します。スクリプトおよび関連するユーティリティ・プログラムは,「Tru64 UNIX Associated Products Volume 2」CD-ROM の TruCluster Server バージョン 5.1B ディレクトリに用意されており,TCRMIGRATE540
サブセット内にあります。ASE の各メンバにサブセットをロードするには,setld
コマンドを使用します。ユーティリティおよび関連ライブラリは,/usr/opt/TruCluster/tools/migrate
ディレクトリにインストールされます。
スクリプトは Korn シェル (ksh
) スクリプトです。シェル・プログラミングの知識があり,スクリプトで何をしているのかを正確に知りたい場合は,実行する前にスクリプトのコードを調べることができます (付録 F
で,ストレージ移行スクリプトに代わる方法として,デバイス名のマッピングとストレージの構成を手動で行う手順を説明しています)。
clu_migrate_check
(オプション 3) ハードウェア,ファームウェア,およびファイル・システムの一般的なタイプ・チェックを行います。
オプション 3 のアップグレードを開始する前に,現在の ASE の各メンバで
clu_migrate_check
を実行します。
clu_migrate_save
(オプション 2 およびオプション 3) ディレクトリを作成し,現在のシステム,ASE 構成,および ASE が使用する共用ストレージに関する情報を保存します。
新しいクラスタを作成した後,すべての共用ストレージがまだ ASE に接続されている間に,オンラインの ASE サービスが提供されている ASE の各メンバで
clu_migrate_save
を実行します。clu_migrate_save
スクリプトにより,ASE サービスが現在使用しているストレージを新しいクラスタへ移行するために必要な情報がすべて収集されます (これには,このストレージに関連する AdvFS ドメインまたは LSM ボリュームの移行も含まれます)。スクリプトが現在の構成に対して行う唯一の変更は,各ディスクの
rz*
スペシャル・ファイル名をディスクのラベルの
label:
フィールドに書き込むことです。ただし,スクリプトは元のディスク・ラベルを保存します。このラベルは,clu_migrate_configure
を実行する際にリストアすることができます。rz*
名を
label:
フィールドに書き込むと,clu_migrate_configure
により各ディスク・デバイスをその新しいスタイルの
dsk*
デバイス名にマップできるようになります。
clu_migrate_save
スクリプトでは,データを新しいクラスタ (オプション 2) か Tru64 UNIX バージョン 5.1B システム (オプション 3) のどちらかに自動的にコピーすることを選択できます。スクリプトは
/var/TruCluster_migration
ディレクトリにある情報を,ターゲット・システム上に各メンバ独自のディレクトリを割り当てて,保存します。このとき,各メンバの
/etc/rc.config
にある
CLUSTER_NET
変数を使用して,次のように命名します。
/var/TruCluster_migration/CLUSTER_NET
次に,clu_migrate_configure
スクリプトによりこれらのディレクトリの情報が使用されて,物理ストレージ・デバイス名がマップされるとともに,新しいクラスタ上または Tru64 UNIX システム上のストレージが構成されます。
clu_migrate_configure
(オプション 2 およびオプション 3) 新しい TruCluster Server バージョン 5.1B クラスタ (オプション 2) または Tru64 UNIX バージョン 5.1B システム (オプション 3) 上のストレージを構成します。
ASE システムの電源をオフにして共用ストレージを新しいクラスタに接続した後,clu_migrate_configure
を実行すると,以前 ASE で管理していたストレージが自動的に構成されます。clu_migrate_configure
スクリプトにより,ASE メンバ上での
clu_migrate_save
による出力から収集された情報がマージされます。次にストレージの構成,つまり,各ディスクの
label:
フィールドに書き込まれた古いスタイルのデバイス名から新しいスタイルの
dsk
デバイス名へのマップ,LSM ボリュームのインポート,AdvFS ドメインの再作成,マウント・ポイントのテスト,および
/etc/fstab
および
/etc/exports
へのエントリの追加が行われます。ストレージの構成が完了すると,このスクリプトにより,clu_migrate_save
によって上書きされた,保存されている
label:
フィールド値がすべて復元されます。
clu_migrate_configure
スクリプトでは,すべての共用ディスク・デバイスについてデバイス名マッピングが行えますが,ASE で管理していないストレージは構成されません。共用ストレージが ASE で管理されていなかった場合,ASE メンバの
/etc/fstab
ファイルにあるそのストレージのエントリは移行されません。
このスクリプトでは,既存の AdvFS ファイル・システムは新しい AdvFS フォーマットに変換されません。新しい AdvFS フォーマットを使用するには,アップグレードを完了してから AdvFS ファイル・システムを変換します。
clu_migrate_configure
スクリプトの実行中に,vollogcnvt
を実行するように指示するメッセージが表示されることがあります。これは,ブロック変更ロギング (BCL) を使用するボリュームを検出したため,ダーティ・リージョン・ロギング (DRL) に変換する必要があることを示します。変換には
vollogcnvt
ユーティリティを使用します。詳細については,
vollogcnvt
(8)
clu_migrate_recover
(オプション 2 およびオプション 3) デバイスの予約を解除して,ASE メンバの LSM 構成を復元します。正常に行われているアップグレードでは,このスクリプトは実行しません。
clu_migrate_recover
スクリプトは,ASE システムで実行され,8.7.2 項に示す回復手順の一部として ASE に戻します。このスクリプトは,アップグレードが正常に完了できなかった場合のみ実行します。
注意
アップグレード中に AdvFS ファイル・システムを新しい AdvFS フォーマットに変換した場合は,
clu_migrate_recover
スクリプトでそれらを古いフォーマットに戻すことはできません。これは,手動で行う必要があります。
8.5 オプション 1 : 別のクラスタの作成 新しいシステムと新しいストレージ
別のクラスタを作成すると,現在の運用環境に影響を与えることなくアプリケーションとシステム構成をテストできます。
別のクラスタを設定できるかどうかは,現在のハードウェア構成,および新しいハードウェア購入の可否によって異なります。新しいハードウェアを購入でき,別のクラスタを構成するスペースがある場合には,この方法をお勧めします。
次に,この方法の一般的な手順について概略を説明します。
『クラスタ・ハードウェア構成ガイド』の情報を参照して,新しいクラスタのハードウェア構成を設計します。次の点について考慮する必要があります。
NSPOF (no-single-point-of-failure) クラスタを作成する (NSPOF クラスタを作成するための基本的なハードウェアの必要条件については 『クラスタ・ハードウェア構成ガイド』を参照)。
高速の RAID コントローラとマルチパス化を使用して,クォーラム・ディスクまたはメンバ・ブート・パーティションのミラーリングを実行する (TruCluster Server は,これらのファイル・システムに対して LSM ミラーリングをサポートしていない)。
拡張の余地を残しておく。たとえば,構成時にまだ空き PCI (Peripheral Component Interconnect) スロットがあるシステムを注文しておき,拡張可能なネットワークおよびストレージ・トポロジを作成する。
ハードウェアがサイトに届いたら,すべてのファームウェアとコンソールの構成を完了させ,物理的に接続したのち,本書の情報を参照して TruCluster Server クラスタを作成します。
注意
新しいクラスタ用に IP アドレスを選択する際には,現在 ASE で使用されているアドレスを使用してはなりません (新しいクラスタが動作している場合,クライアントでは,すべての NFS マウント要求を省略時のクラスタ別名か,または
/etc/exports.aliases
の中に名前が指定されている別名に宛てて送信する必要があります)。
新しいクラスタの機能を習得してください。
『クラスタ管理ガイド』の情報を参照して,クラスタを構成および管理します。たとえば,データのバックアップおよびリストア・プロシージャの作成とテスト,ハードウェアの監視,クラスタの調整および負荷分散などを行います。
『クラスタ高可用性アプリケーション・ガイド』の情報を参照して,高可用性アプリケーションを作成してテストします。使用する予定の重要な各アプリケーションについて,どちらの方法がそのアプリケーションに適しているのかを判断します。アプリケーションとフェイルオーバ・ポリシを構成したら,強制的にフェイルオーバさせてみて,期待どおりの結果が得られるかどうかを確認します。満足できるまで,変更と調整を繰り返します。
データの移行: 新しいクラスタは,現在の ASE とは完全に独立しているため,主な作業は,ASE から新しいクラスタへのアプリケーション・データの移行です。
注意
データの移行を開始する前に,ASE と新しいクラスタの両方のバックアップをとっておくことをお勧めします。
ASE で使用されているデータを新しいクラスタにいつ,どのように移動するかは,ユーザが決定しなければなりません。ここでは,推奨する手順やツールは示しません。次に,データ移行の方針を決める際に考慮する必要のある重要なポイントについて説明します。
標準の
vdump
/vrestore
ユーティリティかアプリケーション固有のデータ移行ツールを使用するかは,現在の環境,アプリケーション,およびデータの量によって決まります。また,アプリケーション・データのいくつかまたはすべてが UFS フォーマットで保存されている場合は,新しいクラスタ上の AdvFS フォーマットにリストアする必要があります (UFS から AdvFS への変換についての詳細は
8.3.3 項を参照)。
データベース・ベンダは通常,データベースのリモート・コピーをアップデートできるアプリケーションを提供しています。リモート・アップデート機能のあるデータベース・アプリケーションを使用している場合は,その機能を使用して,ASE からクラスタへデータを移行することができます。アップデート (および新しいクラスタでのテスト) が完了すると,データベース・サービス用の IP アドレスを新しいクラスタに移動します。
現在の ASE で,複数のアプリケーションのサービスを行っている場合は,すべてのアプリケーション・データを同時に移行するのか,あるいは,ASE と新しいクラスタの両方からクライアントに対してサービスを行いながら,一度に 1 つのアプリケーションを移行するのかを決定しなければなりません。アプリケーションを一度に移行する場合には,それらを移行する順番も決定します。
移行の途中で,ASE とクラスタの両方がクライアントに対してサービスを行っている場合は,移行期間中にバックアップとリカバリを行う手順を考えます。
8.6 オプション 2 : 別のクラスタの作成 新しいシステムと既存ストレージの使用
この方法はオプション 1 に似ていますが,ある時点で,既存の ASE ストレージ・デバイスを新しいクラスタに物理的に移動する点が異なります。この節では,次の事項について説明します。
次に,オプション 2 のための一般的な手順について概略を説明します。
『クラスタ・ハードウェア構成ガイド』の情報を参照して,新しいクラスタのハードウェア構成を設計します。その際,次の点について考慮する必要があります。
NSPOF (no-single-point-of-failure) クラスタを作成する (NSPOF クラスタを作成するための基本的なハードウェアの必要条件については 『クラスタ・ハードウェア構成ガイド』を参照)。ASE からのストレージ・ハードウェアを使用しているため,その構成での NSPOF 制約事項が新しいクラスタに影響する。たとえば,ディスクの中にはマルチパス化をサポートしていないものもある。
新しいクラスタには,クラスタの作成およびメンバの追加に必要な共用ストレージがなければならない。さらに,ASE ストレージを新しいクラスタに物理的に移動する前に行うアプリケーション・テストのために,追加の共用ストレージも必要。
新しいクラスタでは,アプリケーション・データ用に現在の ASE からのストレージ・ハードウェアを使用するため,新しいクラスタ・システムに,ASE のストレージ・トポロジと互換性のあるストレージ・アダプタがあることを確認する。ASE システムから新しいシステムにアダプタを移す場合は,そのアダプタが新しいシステムでサポートされていることを確認する。
高速の RAID コントローラおよびマルチパス化を使用して,クォーラム・ディスクまたはメンバ・ブート・パーティションをミラーリングする (TruCluster Server では,これらのファイルに対して LSM ミラーリングをサポートしていない)。
拡張の余地を残しておく。たとえば,構成時にまだ空き PCI スロットがあるシステムを注文しておき,拡張可能なネットワークおよびストレージ・トポロジを作成する。
ハードウェアがサイトに届いたら,すべてのファームウェアとコンソール構成を完了させ,物理的に接続したのち,本書の情報を参照して TruCluster Server クラスタを作成します。
注意
新しいクラスタ用に IP アドレスを選択する際には,現在 ASE で使用されているアドレスを使用してはなりません。
TruCluster Server クラスタの機能を習得してください。
『クラスタ管理ガイド』の情報を参照して,クラスタを構成および管理します。たとえば,データのバックアップおよびリストア・プロシージャの作成およびテスト,ハードウェアの監視,クラスタの調整および負荷分散などを行います。
『クラスタ高可用性アプリケーション・ガイド』の情報を参照して,高可用性アプリケーションを作成してテストします。たとえば,2 つのサブシステム間の相違が理解できるまで,CAA とクラスタ別名を使用します。アプリケーションとフェイルオーバ・ポリシを構成したら,強制的にフェイルオーバさせてみて,期待どおりの結果が得られるかどうかを確認します。満足できるまで,変更と調整を繰り返します。
この時点まで,ASE と TruCluster Server クラスタは完全に独立しているため,一方に対して行ったことがもう一方に影響することはありません。次の手順からは,ストレージを ASE から新しいクラスタに移動する準備を開始します。 作業を続行する前に,次のことを行ってください。
8.4 節のユーティリティ・スクリプトに関する説明と,8.7.1 項のオプション 3 の手順を読んでおいてください。ASE からクラスタにストレージを移動する際に,そのスクリプトと手順の一部を使用します。
新しいクラスタの
/.rhosts
を編集して,ASE の各メンバから
root
アクセスできるようにします。これにより,clu_migrate_save
が,ASE メンバからクラスタ上の
/var/TruCluster_migration
ディレクトリに,情報を自動的にコピーできるようになります。
新しいクラスタのバックアップをとります。何か問題が起こった場合にも,リカバリが可能です。
ASE の各メンバで,TCRMIGRATE540
サブセットをロードします。このサブセットは,「Tru64 UNIX Associated Products Volume 2」CD-ROM の TruCluster Server バージョン 5.1B ディレクトリに入っています。次の例では,CD-ROM を
/mnt
にマウントしていると想定しています。
# setld -l /mnt/TruCluster/kit TCRMIGRATE540
移行スクリプト,ユーティリティ・プログラム,およびライブラリが
/usr/opt/TruCluster/tools/migrate
ディレクトリにインストールされます。
すべてのストレージのケーブルとアダプタにラベルを付けます。これは,ストレージを ASE に再接続する必要が生じた場合のためです。
すべての LSM ベースのサービスが ASE でオンラインになっていることを確認します。
ASE サービスを実行する ASE の各メンバで,clu_migrate_save
を実行します。
# /usr/opt/TruCluster/tools/migrate/clu_migrate_save
TruCluster Server バージョン 5.1B クラスタで次の処理を行います。
clu_migrate_save
で作成されたファイルが
/var/TruCluster_migration
ディレクトリにコピーされていることを確認します。
クラスタをシャットダウンして,停止します。
# shutdown -c now
クラスタの各メンバの電源をオフにします。
注意
ストレージの電源をオフにするかしないかは,ユーザの判断によります。
ASE の全メンバで次の処理を行います。
通常のバックアップ手順に従い,すべてのデータのバックアップを取ります。 次の手順からは,ASE からクラスタにストレージ・デバイスを移行します。 何らかの理由で ASE に戻す必要がある場合,これが現在の構成のフル・バックアップを行う最後の機会です。
ASE サービスをすべてオフラインにします。 データのバックアップ時にオフラインにする必要がない場合は,この時点でオフラインにします。
各システムをシャットダウンして,停止します。
各システムの電源をオフにします。
TruCluster Server クラスタで次の処理を行います。
共用ストレージを ASE からクラスタ・システムに接続します。
注意
TruCluster Server バージョン 5.1B では,ストレージがクラスタ・メンバにシンメトリックに接続されていなくても利用することができます。ただし,ASE のストレージには,高可用性のアプリケーション・データが含まれているため,ストレージはすべてのメンバから直接アクセスできるように接続することをお勧めします。
共用ストレージの電源がオフになっている場合は,その電源をオンにします。
クラスタ・メンバの電源を投入します。
各コンソールで
show dev
コマンドを実行し,ASE が使用するディスク・デバイスが認識されていることを可能な限り確認します。クラスタをブートする前に,ハードウェア関連の問題を発見して,修正してください。
クラスタをブートします。新しいストレージがシンメトリックに構成されていない場合は,新しいストレージに直接接続されているすべてのメンバを確実にブートしてください。
注意
ブート・フェーズでは,クラスタ・メンバは新しいデバイスを検出して,スペシャル・デバイス・ファイルを作成します。
クラスタの 1 つのメンバで
clu_migrate_configure
を実行します。このコマンドにより,ストレージ・デバイスがオペレーティング・システムに認識されているかどうかを確認します。また,このコマンドでは古いスタイルのデバイス名が新しいスタイルのデバイス名にマップされて,ストレージが構成されます。
クラスタで,次の作業を行います。
アプリケーションを,完全なストレージでテストします。アプリケーションがデータを認識できるかどうか,およびデータを使用できるかどうかを確認します。以前のアプリケーション・テストでは,アプリケーションが問題なく実行できることを確認しました。完全なストレージで行うこのテストの目的は,クライアントにサービスを提供するときに使用するデータを,アプリケーションが認識して操作できるかどうかを確認することです。
注意
解決できない問題を発見し,ASE に戻すことを決定した場合は,8.6.2 項の手順に従ってください。
クライアントへのサービスを開始します。NFS クライアントでは,NFS マウント要求を,省略時のクラスタ別名,または
/etc/exports.aliases
の中に名前が指定されている別名に宛てて送信する必要があります。
(オプション作業) 移行用のディレクトリおよび移行サブセットを削除します。クラスタの 1 つのメンバで次の作業を行います。
移行用のディレクトリを削除します。
# rm -rf /var/TruCluster_migration
移行用のツールを削除します。
# setld -d TCRMIGRATE540
ストレージの移行時またはアップグレードの完了後に,解決できない問題が発生した場合は,次の手順に従って ASE 構成に戻します。
クラスタを停止します。
クラスタの各メンバの電源をオフにします。
注意
ストレージの電源をオフにするかどうかは,ユーザの判断です。
ストレージを,ASE に再接続します。以前とまったく同様に接続されていることを確認してください。
共用ストレージの電源がオフになっている場合は,その電源をオンにします。
すべての ASE システムの電源をオンにします。
ASE メンバをブートします。
clu_migrate_save
を実行した ASE の各メンバ上で
clu_migrate_recover
コマンドを実行します。
# /usr/opt/TruCluster/tools/migrate/clu_migrate_recover
すべてのメンバが動作し,回復したときに,いずれかのメンバ上で
asemgr
コマンドを実行して,すべてのサービスをオンラインに設定します。
(オプション作業) 移行ディレクトリおよび移行サブセットを削除します。ASE の各メンバで次の作業を行います。
移行ディレクトリを削除します。
# rm -rf /var/TruCluster_migration
移行ツールを削除します。
# setld -d TCRMIGRATE540
この節では,既存のハードウェアを引き続き使用し,既存のバージョン 1.5 またはバージョン 1.6 の TruCluster Production Server Software クラスタあるいは TruCluster Available Server Software (ASE) を TruCluster Server バージョン 5.1B にアップグレードする方法を説明します。
次の手順では,8.4 節で説明したスクリプトを使用して,いくつかの移行作業を自動化しています。スクリプトを使用する場合,現在の ASE 構成は,8.3.2 項に示すハードウェアおよびストレージのトポロジ要件を満たしていなければなりません。
次のようなアップグレード方法があります。
自動ストレージ構成: 現在のシステム構成の確認,情報の保存,および新しいクラスタでのストレージの自動構成を,すべてスクリプトを使用して行う。
手動ストレージ構成: スクリプトを使用して現在のシステム構成を確認し,情報を保存するが,新しいクラスタ上では
clu_migrate_configure -x
を実行する。-x
オプションにより,すべての構成情報が表示されるが,ストレージを構成する代わりに,clu_migrate_configure
が通常使用する構成コマンドの一覧がリストされるだけである。その後,コマンドの順序を調べ,ユーザ独自の一連のコマンドを作成して手動で実行するか,あるいは,-x
オプションを指定しないで
clu_migrate_configure
を再実行することができる。
どちらの方法でも,ほとんどの手順は同じです。新しいクラスタでストレージを手動で構成するユーザだけの手順には,「ストレージ手動構成のみ」と記しています。clu_migrate_configure
を使用して新しいクラスタでストレージを構成するユーザだけの手順には,「ストレージ自動構成のみ」と記しています。
使用している環境にどちらの方法が適しているかを判断する前に,手順全体を参照することをお勧めします。
ASE の各メンバで,TCRMIGRATE540
サブセットをロードします。このサブセットは「Tru64 UNIX Associated Products Volume 2」CD-ROM の TruCluster Server バージョン 5.1B ディレクトリにあります。次の例では,CD-ROM を
/mnt
にマウントしていると想定しています。
# setld -l /mnt/TruCluster/kit TCRMIGRATE540
移行スクリプト,ユーティリティ・プログラム,およびライブラリが
/usr/opt/TruCluster/tools/migrate
ディレクトリにインストールされます。
現在の ASE の各メンバで,clu_migrate_check
を実行します。
# /usr/opt/TruCluster/tools/migrate/clu_migrate_check
出力を8.3.2 項に示す必要条件と照合して,各システムのハードウェアとファームウェアが,アップグレードできるよう適切に構成されていることを確認します。
すべてのストレージのケーブルとアダプタにラベルを付けます。
新しいクラスタの第 1 メンバにする ASE メンバ・システムを決定します。
ASE の残りのメンバに ASE サービスを手動で再配置します。
新しいクラスタの第 1 メンバになるシステムを ASE から削除します。
新しいクラスタの第 1 メンバになるシステムで,次の作業を行います。
システムをシャットダウンし,停止します。
システム・コンソールで次の作業を行います。
show dev
コマンドを実行し,すべての共用ストレージに関する出力を記録します。
すべてのコンソール変数と値を記録します。
次のコンソール変数を設定します。
>>> set auto_action halt >>> set bootdef_dev "" >>> set boot_reset on
bus_probe_algorithm
変数をサポートするシステムについては,次のように設定します。
>>> set bus_probe_algorithm new
コンソール変数についての詳細は,2.7 節を参照してください。bus_probe_algorithm
変数を使用しないシステムでこの変数を設定しても障害にはなりません。この変数は,次の
init
または電源をオフにしたのちにオンにしたときに,クリアされます。
システムの電源をオフにします。
すべてのケーブルと接続にラベルが付けられていることを確認した後で,システムからすべての共用ストレージのケーブル (SCSI や Fibre Channel など) を外し必要に応じてアダプタをターミネートします。既存のケーブルが Y ケーブルまたはトライリンク・アダプタでターミネートされている場合は,ターミネータを追加する必要はありません。SCSI アダプタのターミネートについては,『クラスタ・ハードウェア構成ガイド』を参照してください。
システムに 1 つ以上の Memory Channel クラスタ・インターコネクト・アダプタを取り付けている場合は,ケーブルを外します。
クラスタ・インターコネクトを変更するには,『クラスタ・ハードウェア構成ガイド』 の手順に従って作業します。この時点では,アダプタをケーブルに接続しないでください。
システムの電源をオンにします。
コンソールで
show config
コマンドを使用して,コンソールおよびアダプタのファームウェア・リビジョン番号をチェックし,Tru64 UNIX バージョン 5.1B と互換性があるかどうかを確認します。互換性がない場合には,必要に応じてファームウェアをアップデートします。
第 3 章の指示に従って,Tru64 UNIX バージョン 5.1B のフル・インストレーションを行います。
注意
ASE で使用するオペレーティング・システムを格納したディスクは,決して重ね書きしないでください。後で問題が発生した場合にも,これらのディスクの内容が損なわれていなければ,このシステムを直ちに ASE に戻すことができます。
ディスクを上書きする必要がある場合は,Tru64 UNIX バージョン 5.1B をインストールする前に現在のオペレーティング・システムのバックアップを取っておいてください。
Tru64 UNIX バージョン 5.1B システムで,次の作業を行います。
Tru64 UNIX オペレーティング・システムを完全に構成します。第 3 章の指示に従ってください。
アプリケーションをインストールします。
Tru64 UNIX バージョン 5.1B システムで
/.rhosts
を編集して,ASE の残りのメンバから
root
アクセスできるようにします。こうすることにより,残りの ASE メンバからの情報を
clu_migrate_save
で自動的にコピーできます。
TruCluster Server バージョン 5.1B ライセンスとサブセットをインストールします。
注意
作業を続行する前に,バージョン 5.1B のシステムのバックアップを取っておくことをお勧めします。この後の手順で問題が起こった場合には,Tru64 UNIX をインストールおよび構成してからアプリケーションをインストールし,TruCluster Server サブセットをロードするよりも,速くこの時点まで復元することができます。
すべての LSM ベースのサービスが ASE でオンラインになっていることを確認します。
ASE サービスを実行する ASE の各メンバで,clu_migrate_save
を実行します。
# /usr/opt/TruCluster/tools/migrate/clu_migrate_save
Tru64 UNIX システムで,次の作業を行います。
clu_migrate_save
で作成されたファイルが,/var/TruCluster_migration
ディレクトリにコピーされていることを確認します。
システムを停止して,電源をオフにします。
ASE のすべてのメンバで,次の作業を行います。
通常のバックアップ手順に従い,すべてのデータのバックアップを取ります。次の手順からは,ASE から Tru64 UNIX バージョン 5.1B システムにストレージ・デバイスを移動します。何らかの理由により ASE に戻す必要がある場合,これが現在の構成のフル・バックアップを行う最後の機会です。
ASE サービスをすべてオフラインにします。データのバックアップ時にオフラインにする必要がなかった場合は,この時点でオフラインにします。
各システムをシャットダウンして,停止します。
各システムのコンソールで,次のコンソール変数を設定します。
>>> set auto_action halt >>> set bootdef_dev "" >>> set boot_osflags A >>> set boot_reset on
bus_probe_algorithm
変数をサポートするシステムでは,次のように設定します。
>>> set bus_probe_algorithm new
コンソール変数についての詳細は,2.7 節を参照してください。bus_probe_algorithm
変数を使用しないシステムでこの変数を設定しても障害にはなりません。この変数は,次の
init
または電源をオフにしたのちにオンにしたときに,クリアされます。
各システムの電源をオフにします。
注意
指示があるまで,これらのシステムの電源はオンにしないでください。
Tru64 UNIX バージョン 5.1B システムで,次の作業を行います。
すべての共用ストレージをシステムに接続します。ストレージのケーブルは,システムが ASE の一部であったときとまったく同様に接続してください。
クラスタ・インターコネクト・ケーブルをシステムに接続します。クラスタ構成が Memory Channel ハブか,または,イーサネット・ハブあるいはスイッチを使用する場合,ケーブルをハブあるいはスイッチに接続します。ハブもスイッチも使用しない場合は,ケーブルのみを接続します。
システムの電源をオンにします。
コンソールで
show dev
コマンドを実行し,すべての共用デバイスが認識されていることを可能な限り確認します。表示されたデバイス・リストと,ストレージを分離する前に保存した情報とを比較します。システムをブートする前に,ハードウェア関連の問題を発見して,修正してください。
また,保存されているその他のコンソール情報も,現在のコンソールのものと比較します。
システムをマルチユーザ・モードでブートして,ログインします。
ストレージ自動構成のみ
: Tru64 UNIX バージョン 5.1B システムで
clu_migrate_configure
を実行します。このコマンドにより,ストレージ・デバイスがオペレーティング・システムに認識されているかどうかを確認します。また,このコマンドでは古いスタイルのデバイス名が新しいスタイルのデバイス名にマップされ,ストレージが設定されます。
# /usr/opt/TruCluster/tools/migrate/clu_migrate_configure
ストレージ手動構成のみ
:
Tru64 UNIX バージョン 5.1B システムで
clu_migrate_configure -x
を実行します。
# /usr/opt/TruCluster/tools/migrate/clu_migrate_configure
-x
-x
オプションにより,すべての構成情報が表示されますが,ストレージを構成する代わりに,clu_migrate_configure
が通常使用する構成コマンドの一覧がリストされるだけです。その後,コマンドの順序を調べ,ユーザ独自の一連のコマンドを作成して手動で実行するか,あるいは,-x
オプションを指定しないで
clu_migrate_configure
を再実行することができます。
表示された一連のコマンドを調べたのち,ストレージを自動的に構成することを決定した場合は,clu_migrate_configure
を実行します。
# /usr/opt/TruCluster/tools/migrate/clu_migrate_configure
表示された一連のコマンドを調べたのち,ストレージを手動で構成することを決定した場合は,それを今実行します (ストレージを手動で構成する方法については,F.2 節で説明しています)。作業が終了したら,次のコマンドを使用して,ストレージの構成を調べ,元のディスク・ラベルを復元 (オプション作業) します。
次の LSM コマンドを実行して,LSM の構成を表示します。
# voldisk list # volprint -thA
各 AdvFS ドメインについて,showfdmn
domain
コマンドを実行します。
各 AdvFS ドメインについて,showfsets
domain
コマンドを実行し,ドメインのファイル・セットが適切であることを確認します。
(オプション作業)
clu_migrate_save
は,実行した各 ASE メンバに対して,/var/TruCluster_migration/CLUSTER_NET/Packids
ファイルを作成しています。Packids
ファイルには,そのメンバで認識されている共用デバイスの元のディスク・ラベルが含まれています。元のディスク・ラベルの packid (label:
) フィールドに値が含まれていた場合は,元のラベルを復元できます。元のラベルを復元するには,restore_packids
スクリプトを使用します。ディレクトリを
/usr/opt/TruCluster/tools/migrate/utils
に変更して,次のコマンドを実行します。
# ./restore_packids -f \ /var/TruCluster_migration/CLUSTER_NET/Packids
CLUSTER_NET
は,各メンバの値に置き換えてください。たとえば,CLUSTER_NET
値が
mcclu14
である ASE メンバの場合,コマンドは次のようになります。
# ./restore_packids -f \ /var/TruCluster_migration/mcclu14/Packids
Tru64 UNIX バージョン 5.1B システムで,次の作業を行います。
第 4 章の手順に従い,clu_create
コマンドを実行してシングル・メンバ・クラスタを作成します。
システムを停止し,それをシングル・メンバ・クラスタとしてブートします。
シングル・メンバの TruCluster Server バージョン 5.1B クラスタで次の作業を行います。
アプリケーション用の CAA プロファイルおよびスクリプトを設定します。アプリケーション・プロファイルの作成と CAA の使用については,『クラスタ高可用性アプリケーション・ガイド』,『クラスタ管理ガイド』,および
caa_profile
(8)
省略時のクラスタ別名以外のクラスタ別名を使用する場合は,それらのクラスタ別名を指定し,加わります。クラスタ別名の構成については,『クラスタ管理ガイド』および
cluamgr
(8)
アプリケーションを,完全なストレージでテストします。アプリケーションがデータを認識できるかどうか,およびデータを使用できるかどうかを確認します。以前のアプリケーション・テストでは,アプリケーションが問題なく実行できることを確認しました。完全なストレージで行うこのテストの目的は,クライアントにサービスを提供するときに使用するデータを,アプリケーションが認識して操作できるかどうかを確認することです。
注意
解決できない問題を発見し,ASE に戻すことを決定した場合は,8.7.2 項の手順に従ってください。
クライアントへのサービスを開始します。NFS クライアントでは,すべての NFS マウント要求を省略時のクラスタ別名または
/etc/exports.aliases
の中に名前が指定されている別名に宛てて送信する必要があります。
残りの ASE メンバを一度に 1 つずつクラスタに追加します。各システムで次の作業を行います。
システムの電源がオフになっていることを確認します。
クラスタ・インターコネクト・アダプタ (Memory Channel またはイーサネット) の追加または交換が必要な場合は,アダプタを取り付けます。
システムを共用ストレージに接続します。
クラスタ・インターコネクト・ケーブルを接続します。
システムの電源をオンにします。
show config
コンソール・コマンドを使用して,コンソールとアダプタ・ファームウェアのリビジョン番号が Tru64 UNIX バージョン 5.1B と互換性があるかどうかを確認します。互換性がない場合は,必要に応じてファームウェアをアップデートします。
第 5 章で説明する手順に従い,現在のクラスタ・メンバで
clu_add_member
コマンドを実行して,新しいメンバのブート・ディスクを作成します。その後,新しいメンバをクラスタにブートします。
(オプション作業) 移行ディレクトリを削除し,移行サブセットを削除します。いずれかのクラスタ・メンバで,次の作業を行います。
移行ディレクトリを削除します。
# rm -rf /var/TruCluster_migration
移行ツールを削除します。
# setld -d TCRMIGRATE540
ストレージの移行時またはアップグレードの完了後に,解決できない問題が発生した場合は,次の手順に従って ASE 構成に戻します。
すべてのシステムを停止します。
すべてのシステムの電源をオフにします。
注意
ストレージの電源をオフにするかどうかは,ユーザの判断です。
Memory Channel アダプタを取り付けていた場合は,それらを取り外します。
ストレージがすべてのシステムに接続されていない場合は,ストレージを再接続します。ASE に接続されていたのと全く同様にストレージが接続されていることを確認します。
共用ストレージの電源がオフになっていた場合は,電源をオンにします。
システムの電源をオンにします。
コンソール変数を以前の値に戻します。
アップグレード中に SCSI のワイド・アドレス (ID 8〜15) を使用した場合,保存してある以前の設定値に復元します。
ASE の各メンバで,旧バージョンのオペレーティング・システムをマルチユーザ・モードでブートします。
clu_migrate_save
を実行した ASE の各メンバ上で
clu_migrate_recover
コマンドを実行します。
# /usr/opt/TruCluster/tools/migrate/clu_migrate_recover
すべてのメンバが動作し,回復したときに,いずれかのメンバ上で
asemgr
コマンドを実行して,すべてのサービスをオンラインに設定します。
(オプション作業) 移行ディレクトリおよび移行サブセットを削除します。 ASE の各メンバで次の作業を行います。
移行ディレクトリを削除します。
# rm -rf /var/TruCluster_migration
移行ツールを削除します。
# setld -d TCRMIGRATE540
この節では,4 つのメンバを持つ TruCluster Production Server バージョン 1.6 のクラスタを TruCluster Server バージョン 5.0A へアップグレードする方法について説明します。例として,類似したハードウェアで移行をテストしてから,実際に運用しているバージョン 1.6 の複数のクラスタのアップグレード方法を決定する場合をとりあげます。
注意
ケース・スタディのターゲットにしているバージョンはバージョン 5.0A ですが,TruCluster Server のどの 5.x バージョンにアップグレードする場合でも,基本手順は同じです。
ここで述べるケース・スタディ以外にも,社内の運用レベルのクラスタを TruCluster Production Server バージョン 1.6 からパッチ・キットを含めた TruCluster Server バージョン 5.0A にアップグレードする場合の説明については,以下の URL にあるリンクをたどってください。
http://www.tru64unix.compaq.com/docs/highavail/index.htm
アップグレード前のクラスタは,次のハードウェアとソフトウェアで構成されています。
4 台の AlphaServer GS140 ラックマウント・システム (各システムに,8 つの CPU,8GB の RAM,および 14 個の KGPSA-BC アダプタを装備)。
14 の Fibre Channel ストレージ・エリア・ネットワーク・スイッチ (16 ポート)。
14 の StorageWorks ESA 12000 ストレージ・アレイ Fibre Channel キャビネット (各キャビネットに,二重冗長 HSG80 アレイ・コントローラおよび 36GB のディスク 48 台を装備)。
2 つの StorageWorks ESL9326D エンタープライズ・テープ・ライブラリ。
2 つの Memory Channel II ハブ。
Tru64 UNIX バージョン 4.0F (パッチつき)。
TruCluster Production Server バージョン 1.6 (ASE サービスと LSM は使用しない)。
このクラスタは,Tru64 UNIX バージョン 5.0A と TruCluster Server バージョン 5.0A で構成されて出荷されたものですが,アップグレードをテストするために,あえて Tru64 UNIX バージョン 4.0F と Production Server バージョン 1.6 とともにロードされるようにしています。
112 DRD (Distributed Raw Disk) デバイスを使用した Oracle 8.1.6 のシングル・インスタンス。
バージョン 5.0A のクラスタで同じバイナリを実行し,アップグレードが成功したかどうかをテストします。
アップグレード後のクラスタは,Tru64 UNIX バージョン 5.0A 上で TruCluster Server バージョン 5.0A を実行します。
3 通りの標準的なアップグレード方法の中からオプション 3 の修正バージョンでアップグレードします。次の事項が決定されました。
ストレージまたは Memory Channel のケーブルを外さない。
この規模のクラスタでは多数のケーブル接続が必要なため,ケーブルを外さずに作業時間の短縮とリスクの軽減を図ります。
ストレージ,Memory Channel ハブ,およびシステムの電源を切らない。
実際のアップグレードはコンピュータ・センタからリモートで制御するため,電源を切断するかわりに必要に応じてシステムをコンソール・プロンプトで制御します。ただし,この場合,管理者が誤ってシステムを起動しないようにする必要があります。
同時にすべてのシステムを停止する。
ストレージと Memory Channel ハブが接続され,電源が入った状態になっているため,Tru64 UNIX バージョン 5.0A のインストール中には,Production Server クラスタの実行を継続することはできません。
アップグレード前に,Tru64 UNIX バージョン 5.0A をインストールするシステムのローカル・ディスクのファイル・システムに
clu_migrate_save
からのすべての出力をコピーする。Tru64 UNIX バージョン 5.0A システムをインストールしてから
clu_migrate_configure
を実行するまでの間に,ファイル・システムをマウントし,ファイルを
/var/TruCluster_migration
にコピーする。
オプション 2 とオプション 3 では,新しいクラスタ (オプション 2) またはストレージおよび Memory Channel と物理的に接続されていない現在のクラスタのメンバ (オプション 3) に
clu_migrate_save
の出力がネットワークを介してコピーされます。前述の手順では,Tru64 UNIX バージョン 5.0A のインストール前にバージョン 1.6 の Production Server クラスタ全体をシャットダウンするため,ファイルをバージョン 5.0A のシステムにコピーする必要があります。
アップグレード前のクラスタは,少しカスタマイズされています。LSM が使用されておらず,ASE サービスも定義されていません。Oracle 8.1.6 のシングル・インスタンスは,アップグレードが成功したかどうかのテストとして使用されます。このアプリケーションを新しいクラスタで実行し,このクラスタのすべてのストレージにアクセスできる場合は,アップグレードが成功したものとみなすことができます。
実際のアップグレード手順の概要は,次のとおりです。
TruCluster Software バージョン 1.6 のクラスタの 4 つのメンバすべてに TCRMIGRATE505 サブセットをロードします。
すべてのメンバで
clu_migrate_check
を実行します。
1 つのメンバを先行メンバ (最初にアップグレードするシステム) として選択します。
/var/TruCluster_migration
ディレクトリを作成します。
先行メンバの
/var/TruCluster_migration
ディレクトリを
clu_migrate_save
で作成するデータ・ファイルの
rcp
の格納先として指定し,すべてのメンバで
clu_migrate_save
を実行します。
disklabel -r
を使用してディスク・ラベルを検査します。ディスクの現在のデバイス・スペシャル・ファイル名を表す
@rz
xxx
文字列がディスク・ラベルに含まれていることを確認します。
バージョン 1.6 クラスタのすべてのメンバをシャットダウンしてコンソール・モードにします。
注意
この例では,バージョン 5.0A でサポートされる HSG80 のマルチバス・フェイルオーバを利用するように Fibre Channel スイッチ・ファブリックをあらかじめ構成しておきます。このように構成していない場合は,SAN スイッチのケーブルを接続し直します。このアップグレード方法では,すべてのシステムをコンソール・プロンプトで制御する間,各 HSG80 コントローラが透過的フェイルオーバからマルチバス・フェイルオーバに変更されて,再起動されます。
HSG80 コンソールで,5 つのディスクを使用してストレージセット (RAID レベル 5) を作成し,次のパーティションを設定します (サイズはパーセンテージで表します。パリティを除いた後の平均合計空き容量は,145GB です)。
Tru64 UNIX バージョン 5.0A ディスク : 6% (約 8.7 GB)
TruCluster Server バージョン 5.0A ディスクのルート (/
),/usr/
,および
/var
: 6% (約 8.7 GB)
各メンバのブート・ディスク : 15% (約 21.8 GB)
GS140 には 8 GB のメモリが含まれるため,各システムに多くのスワップ領域が必要。
クォーラム・ディスク : 1% (約 1.45 GB)
残りのパーティション (将来使用するために予約されている) : 27% (約 39.3 GB)
HSG80 コンソールで使用するコマンドの概要は,次のとおりです。
注意
この例では,ストレージとブート・ディスクを構成するためのコンソール・コマンドと HSG80 コマンドの一部を紹介します。HSG80 コントローラの配下でブート・ディスクを使用する場合は,TruCluster Server 『クラスタ・ハードウェア構成ガイド』で説明する手順に従ってください。
HSG14 BOT> show unit LUN Uses Used by ------------------------------------------------------------------------------ D0 R1 D1 R2 D2 R3 D3 R4 D100 R5 D101 R6 D102 R7 D103 R8 HSG14 BOT> locate d103 ! verify the disk to be deleted HSG14 BOT> locate cancel HSG14 BOT> delete unit d103 ! delete the existing unit HSG14 BOT> show r8 ! check how much space is available Name Storageset Uses Used by ------------------------------------------------------------------------------ R8 raidset DISK21100 DISK31100 DISK41100 DISK51100 DISK61100 Switches: POLICY (for replacement) = BEST_PERFORMANCE RECONSTRUCT (priority) = NORMAL CHUNKSIZE = 256 blocks State: UNKNOWN -- State only available when configured as a unit Size: 284389020 blocks HSG14 BOT> create_partition r8 size=6 HSG14 BOT> create_partition r8 size=6 HSG14 BOT> create_partition r8 size=15 HSG14 BOT> create_partition r8 size=15 HSG14 BOT> create_partition r8 size=15 HSG14 BOT> create_partition r8 size=15 HSG14 BOT> create_partition r8 size=1 HSG14 BOT> create_partition r8 size=largest Name Storageset Uses Used by ------------------------------------------------------------------------------ R8 raidset DISK21100 DISK31100 DISK41100 DISK51100 DISK61100 Switches: POLICY (for replacement) = BEST_PERFORMANCE RECONSTRUCT (priority) = NORMAL CHUNKSIZE = 256 blocks State: UNKNOWN -- State only available when configured as a unit Size: 284389020 blocks Partitions: Partition number Size Starting Block Used by --------------------------------------------------------------------- 1 17062907 ( 8736.20 MB) 0 2 17062907 ( 8736.20 MB) 17062912 3 42657787 ( 21840.78 MB) 34125824 4 42657787 ( 21840.78 MB) 76783616 5 42657787 ( 21840.78 MB) 119441408 6 42657787 ( 21840.78 MB) 162099200 7 2843643 ( 1455.94 MB) 204756992 8 76788375 ( 39315.64 MB) 207600640 HSG14 BOT> add unit d4 r8 part=1 ! Tru64 UNIX V5.0A disk HSG14 BOT> add unit d5 r8 part=2 ! TruCluster V5.0A disk HSG14 BOT> add unit d6 r8 part=3 ! member 1 boot disk HSG14 BOT> add unit d7 r8 part=4 ! member 2 boot disk HSG14 BOT> add unit d8 r8 part=5 ! member 3 boot disk HSG14 BOT> add unit d9 r8 part=6 ! member 4 boot disk HSG14 BOT> add unit d10 r8 part=7 ! quorum disk HSG14 BOT> add unit d11 r8 part=8 ! remaining space HSG14 BOT> show r8 Name Storageset Uses Used by ------------------------------------------------------------------------------ R8 raidset DISK21100 D10 DISK31100 D11 DISK41100 D4 DISK51100 D5 DISK61100 D6 D7 D8 D9 Switches: POLICY (for replacement) = BEST_PERFORMANCE RECONSTRUCT (priority) = NORMAL CHUNKSIZE = 256 blocks State: NORMAL DISK21100 (member 0) is NORMAL DISK31100 (member 1) is NORMAL DISK41100 (member 2) is NORMAL DISK51100 (member 3) is NORMAL DISK61100 (member 4) is NORMAL Size: 284389020 blocks Partitions: Partition number Size Starting Block Used by --------------------------------------------------------------------- 1 17062907 ( 8736.20 MB) 0 D4 2 17062907 ( 8736.20 MB) 17062912 D5 3 42657787 ( 21840.78 MB) 34125824 D6 4 42657787 ( 21840.78 MB) 76783616 D7 5 42657787 ( 21840.78 MB) 119441408 D8 6 42657787 ( 21840.78 MB) 162099200 D9 7 2843643 ( 1455.94 MB) 204756992 D10 8 76788375 ( 39315.64 MB) 207600640 D11 HSG14 BOT> show unit LUN Uses Used by ------------------------------------------------------------------------------ D0 R1 D1 R2 D2 R3 D3 R4 D4 R8 (partition) D5 R8 (partition) D6 R8 (partition) D7 R8 (partition) D8 R8 (partition) D9 R8 (partition) D10 R8 (partition) D11 R8 (partition) D100 R5 D101 R6 D102 R7 HSG14 BOT> set d4 id=100 ! create user-defined identifiers (UDIDs) HSG14 BOT> set d5 id=101 HSG14 BOT> set d6 id=1 HSG14 BOT> set d7 id=2 HSG14 BOT> set d8 id=3 HSG14 BOT> set d9 id=4
先行メンバ (メンバ 1) のコンソールで,wwidmgr
コマンドを使用して,コンソール・デバイス名を Tru64 UNIX バージョン 5.0A ディスクのユーザ定義 ID (UDID) にマップします。この ID は HSG80 上で作成されます。また,このメンバのブート・ディスクをコンソール・デバイス名にマップし,bootdef_dev
を設定します。
P00>>> set mode diag Console is in diagnostic mode P00>>> wwidmgr -quickset -udid 100 # Tru64 UNIX Version 5.0A disk P00>>> wwidmgr -quickset -udid 1 # member 1 boot disk
.
.
.
Disk assignment and reachability after next initialization: 6000-1fe1-0005-9dc0-0009-0010-4628-00c6 via adapter: via fc nport: connected: dgm1.1001.0.7.7 kgpsam0.0.0.7.7 5000-1fe1-0005-9dc3 Yes dgm1.1002.0.7.7 kgpsam0.0.0.7.7 5000-1fe1-0005-9dc1 No dgn1.1003.0.10.7 kgpsan0.0.0.10.7 5000-1fe1-0005-9dc2 No dgn1.1004.0.10.7 kgpsan0.0.0.10.7 5000-1fe1-0005-9dc4 Yes
.
.
.
P00>>> init
.
.
.
P00>>> show device
.
.
.
kgpsam0.0.0.7.7 PGM0 WWN 1000-0000-c922-09f9 dgm100.1001.0.7.7 $1$DGA100 HSG80 V85F dgm1.1001.0.7.7 $1$DGA1 HSG80 V85F dgm1.1002.0.7.7 $1$DGA1 HSG80 V85F dgn1.1003.0.10.7 $1$DGA1 HSG80 V85F dgn1.1004.0.10.7 $1$DGA1 HSG80 V85F
.
.
.
P00>>> set bootdef_dev dgm1.1001.0.7.7 P00>>> init
.
.
.
残りの各メンバについては,各コンソールで
wwidmgr
コマンドを使用して,それぞれのブート・ディスクの UDID をコンソール・デバイス名にマップし,bootdef_dev
を設定します。
(member 2) P00>>> set mode diag Console is in diagnostic mode P00>>> wwidmgr -s quickset udid 2 P00>>> init
.
.
.
P00>>> set bootdef_dev dgm2.1001.0.7.7 P00>>> init
.
.
.
(member 3) P00>>> set mode diag Console is in diagnostic mode P00>>> wwidmgr -quickset -udid 3 P00>>> init
.
.
.
P00>>> set bootdef_dev dgm3.1001.0.7.7 P00>>> init
.
.
.
(member 4) P00>>> set mode diag Console is in diagnostic mode P00>>> wwidmgr -quickset -udid 4 P00>>> init
.
.
.
P00>>> set bootdef_dev dgm4.1001.0.7.7 P00>>> init
.
.
.
注意
この例では,クラスタを作成するために必要なディスクの初期構成時に,起動可能なディスクだけに UDID を割り当てていますが,他のディスクにも UDID を割り当てることをお勧めします。UDID とディスクを関連付けると,
hwmgr
などのユーティリティを使用してデバイスを追跡しやすくなります。1000 の UDID を使用できるため,制限する必要はありません。また,この例では,コンソールで
bootdef_dev
環境変数を使用して各起動デバイスにパスを 1 つだけ設定しています。クラスタの作成後,各メンバに複数のブート・パスを設定します。
先行メンバのコンソールで,Tru64 UNIX バージョン 5.0A をインストールします。基本的なネットワーク・サービスとタイム・サービスを構成します。TruCluster Server バージョン 5.0A のサブセットをロードします。
Tru64 UNIX バージョン 4.0F の
usr_domain#usr
を
/mnt
にマウントし,clu_migrate_save
で収集されたストレージ情報を含む移行ディレクトリをバージョン 5.0A システムの
/var/TruCluster_migration
にコピーします。
clu_migrate_configure -x
を実行します。clu_migrate_configure
で実行されるコマンドを検査します。
clu_migrate_configure
を実行します (この TruCluster Software バージョン 1.6 の Production Server クラスタでは,ASE サービスも LSM も使用しないため,clu_migrate_configure
で,/etc/fstab
へのエントリの追加,ファイル・システムのマウント,および LSM ボリュームの作成が行われることはありません)。
新しいスタイルの
dsk
デバイス名を Oracle のテスト・データベースで使用する
drd
リンクにマップするシェル・スクリプトの入力として,clu_migrate_configure
ログ・ファイルを使用します。
注意
Tru64 UNIX バージョン 5.0A をインストールしてバージョン 5.0A クラスタを作成するためのディスク・デバイスは,バージョン 1.6 クラスタのシャットダウン後に作成されます。そのため,
clu_migrate_save
ではこれらのデバイスを認識できません。また,clu_migrate_configure
では,以前のスタイルのデバイス名が存在しないため,以前のデバイス名を Tru64 UNIX バージョン 5.0A のインストール時に割り当てられる新しいスタイルのデバイス名にマップすることができません。
clu_create
を実行して,シングル・メンバ・クラスタを作成します。
Tru64 UNIX バージョン 5.0A システムを停止し,シングル・メンバ・クラスタとして起動する前に,クラスタのブート・ディスクに対するブート・パスを複数設定します。
P00>>> set bootdef_dev dgm1.1001.0.7.7,dgm1.1002.0.7.7,\ dgn1.1003.0.10.7,dgn1.1004.0.10.7
.
.
.
P00>>> init
clu_add_member
を実行し,4 つのメンバの TruCluster Server バージョン 5.0A クラスタの作成を終了します。先行メンバと同様に,各メンバをクラスタとして起動する前にそれぞれについて複数のブート・パスを設定します。
Oracle バージョン 8.1.6 のバイナリを実行し,バージョン 1.6 の Production Server クラスタで作成されたテスト・データベースに Oracle からアクセスできるかどうかをテストします。
テストが成功しました。
移行は完了です。
8.9 TruCluster Memory Channel Software クラスタのアップグレード
この節では,TruCluster Memory Channel Software クラスタを TruCluster Server バージョン 5.1B へアップグレードするための一般的な方法を説明します。
この節の説明には,次のような前提条件を設けています。
かなり低いコストで TruCluster Server バージョン 5.1B へアップグレードすることを目標とする。したがって,ストレージを追加する場合は,HSZ70 RAID アレイ・コントローラや Fibre Channel と HSG80 の組み合わせではなく,可能な限り,SCSI アダプタ,ケーブル,および UltraSCSI BA356 などのローエンドのストレージ・コンテナを使用する。
Memory Channel クラスタには,現在,TruCluster Server バージョン 5.1B のインストールに必要な共用ストレージが構成されていない。おそらく,共用ストレージはほとんど (またはまったく) 存在せず,メンバは Memory Channel だけで接続されている。メンバが必要とするストレージはすべて,そのメンバの内部か,またはプライベート・バス上にある。ハードウェアの主な変更は,TruCluster Server バージョン 5.1B のクラスタを作成するために必要な SCSI アダプタ,ケーブル,ストレージ・コンテナ,およびディスクの追加だけである。既存の Memory Channel インターコネクトと,すべての外部ネットワーク接続は変更の必要がない。
ほとんどの Memory Channel クラスタは可用性よりも性能に重点を置いて設計されているため,アップグレードして NSPOF (no-single-point-of-failure) の構成にする必要がない。バージョン 5.1B クラスタを作成するためにハードウェアを追加して準備する場合は,ニーズに最も合った冗長構成を採ることができる。
すべてのメンバにそれぞれオペレーティング・システムがあるため,Memory Channel クラスタには,オペレーティング・システムのレベルである程度の冗長性が備わっています (1 つのメンバでオペレーティング・システム・ディスクに障害が発生しても,クラスタ全体はダウンしません)。アップグレードすると,TruCluster Server クラスタ・メンバは同じルート (/
),/usr
,/var
ファイル・システムを共用するようになります。このため,ディスクが 1 台使用できなくなっただけでクラスタが利用できなくならないように,何らかの形でソフトウェアまたはハードウェアの RAID が必要となります。アップグレードしたクラスタが使用するストレージはローエンドであり,ハードウェアの RAID コントローラをサポートしないので,LSM を使用してルート (/
),/usr
,および
/var
ファイル・システムをミラー化します。
アップグレード中のダウン時間は問題にならない。Memory Channel クラスタは,共用ストレージを追加して TruCluster Server バージョン 5.1B ソフトウェアをインストールするために,シャットダウンされる。このダウン時間を許容できない環境であれば,TruCluster Server バージョン 5.1B クラスタを別に作成する必要がある。
図 8-1 に,8 個のノードで構成するクラスタの基本ブロック図を示します。『クラスタ・ハードウェア構成ガイド』 に,この図の他にいくつかの図を加えて,詳細なケーブル接続とストレージのレイアウトが示されています。
注意
『クラスタ・ハードウェア構成ガイド』 には,「外部終端の共用 SCSI バスを使った 8 メンバ・クラスタの構成」という章があります。そこには,この図の他にも詳細な構成図がいくつか紹介されています。またその章には,ここで述べる手順と組み合わせて使用する詳細なハードウェア構成情報も記載されています。
このブロック図には,ルート (
/
),/usr
,および/var
ファイル・システムの LSM ミラーが置かれているストレージは示してありません。『クラスタ・ハードウェア構成ガイド』 の「概要」の章には,これらのファイル・システムを LSM でミラー化するために SCSI バスを二重化する方法が図で示されています。
Memory Channel クラスタの構成は多岐にわたるため,以下の手順では,クラスタのアップグレードに必要な手順をすべて記述しているわけではありません。以下の手順は,場合に応じて必要なアップグレードを行うための出発点としてください。
Memory Channel クラスタ内のシステムが TruCluster Server バージョン 5.1B でサポートされていることを確認します。サポートされているシステムについては,TruCluster Server バージョン 5.1B の『QuickSpecs』を参照してください。『QuickSpecs』の最新版は,以下の URL から入手できます。
http://www.tru64unix.compaq.com/docs/pub_page/spds.html
注意
8.4 節に記載してある
clu_migrate_check
スクリプトは使用できません。このスクリプトは TruCluster Production Server および Available Server クラスタのためのものです。
『クラスタ・ハードウェア構成ガイド』 の「外部終端の共用 SCSI バスを使った 8 メンバ・クラスタの構成」という章を参照して,クラスタへ追加する必要があるストレージ・ハードウェアを決定します。Memory Channel クラスタのメンバの数に基づいて,アップグレードに必要な共用 SCSI バスの数を決定します (1 本の SCSI バスに 4 メンバまで接続できます)。次に,SCSI アダプタ,ケーブル,ターミネータ,ストレージ・シェルフ,およびディスクの必要な数を判断します。
さらに,本書の第 1 章と第 2 章を参照して,ディスク・スペースの割り当て方と,クォーラム・ディスクを使用するかどうかを決めます。付録 A のチェックリストにデータを記入します。
アップグレードに必要なハードウェア,ソフトウェア,およびライセンスを入手します。
注意
新バージョンのオペレーティング・システムおよびクラスタ・ソフトウェアには,通常,新バージョンの AlphaServer SRM ファームウェアが必要です。この時点で SRM ファームウェアをアップデートできますが,Memory Channel クラスタをシャットダウンした後で行ってもかまいません。ダウン時間を最短に抑えるには,SRM ファームウェアを一度に 1 システムずつアップグレードし,その後で Memory Channel クラスタ全体をシャットダウンします。SRM ファームウェアについての詳細は,3.1 節を参照してください。
sysconfig -q rm
を使用して
rm_rail_style
属性の値を表示します。この値を記録しておきます (ほとんどの Memory Channel クラスタはマルチアクティブ・レール・スタイル (rm_rail_style=0
) を使用しますが,TruCluster Server バージョン 5.1B の省略時のスタイルはフェイルオーバ・ペア (rm_rail_style=1
) です)。
新しいクラスタの最初のメンバになるシステムを決めます。このシステムは TruCluster Server の共用ルート (/
),/usr
,および
/var
ファイル・システムを置くストレージに直接接続していなければなりません。
現在のオペレーティング・システムが置かれているディスクに Tru64 UNIX をインストールする場合は,現在のオペレーティング・システムのバックアップを取ってから作業を続けます。
各システムをシャットダウンして,停止します。
各システムのコンソールで,次のコンソール変数を設定します。
>>> set auto_action halt >>> set bootdef_dev "" >>> set boot_osflags A >>> set boot_reset on
bus_probe_algorithm
変数をサポートしているシステムでは,次のように設定します。
>>> set bus_probe_algorithm new
コンソール変数についての詳細は,2.7 節を参照してください。bus_probe_algorithm
変数を使用しないシステムでこの変数を設定しても問題はありません。この変数は,次の
init
または電源の再投入で,クリアされます。
各システムの電源をオフにします。
注意
指示があるまで,これらのシステムの電源はオンにしないでください。
『クラスタ・ハードウェア構成ガイド』 の説明を参照して,TruCluster Server バージョン 5.1B クラスタの作成に必要なストレージを追加します。他のハードウェアを追加または再構成する場合は,この時点で実行します。SRM ファームウェアをアップデートしていない場合は,ここでアップデートします。
Memory Channel ハブを使用している場合は,ハブの電源がオンになっていることを確認します。
新しいクラスタの最初のメンバになるシステムの電源をオンにします。コンソールのプロンプトに対して,show config
コンソール・コマンドを使用して,コンソールおよびアダプタのファームウェア・リビジョンが Tru64 UNIX バージョン 5.1B と互換性があることを確認します。互換性がない場合は,必要に応じてファームウェアをアップデートします。
第 3 章の説明に従って,Tru64 UNIX バージョン 5.1B のフル・インストレーションを実行します。
注意
Memory Channel クラスタの使用するオペレーティング・システムが置かれているディスクは,上書きしないことを強くお勧めします。ディスクを変更しなければ,後で問題が発生した場合に,このシステムを簡単に Memory Channel クラスタへ戻すことができます。
Tru64 UNIX バージョン 5.1B システムで,次の操作を実行します。
Tru64 UNIX オペレーティング・システムを完全に構成します。第 3 章の手順に従って作業してください (ベース・オペレーティング・システム上に LSM を構成する場合は,2.5.2 項を参照してください)。
アプリケーションをインストールします。
アプリケーションを,いつどのようにインストールするかは,アプリケーションの種類と Memory Channel クラスタの使い方によって異なります。TruCluster Server バージョン 5.1B クラスタのファイル・システムは同じネーム・スペースを共有しているので注意してください。TruCluster Server バージョン 5.1B クラスタでアプリケーションを実行する方法についての詳細は,『クラスタ高可用性アプリケーション・ガイド』 を参照してください。
TruCluster Server バージョン 5.1B のライセンスとサブセットをインストールします。
注意
作業を続ける前にシステムのバックアップをとっておくことをお勧めします。この後の手順で不具合が生じた場合には,Tru64 UNIX をインストールおよび構成してからアプリケーションをインストールし,TruCluster Server サブセットをロードするよりも,速くこの時点まで復元することができます。
第 4 章の手順に従い,clu_create
コマンドを実行してシングル・メンバ・クラスタを作成します。
システムを停止し,それをシングル・メンバのクラスタとしてブートします。
Memory Channel クラスタ・システムの
rm
サブシステム属性が
rm_rail_style=0
であった場合は,次のようにして,シングル・メンバの TruCluster Server バージョン 5.1B クラスタでそれを
0
に設定してから,システムをリブートします。
/etc/sysconfigtab
ファイルを変更して,次のスタンザを含むようにします。
rm: rm_rail_style=0
シングル・メンバのクラスタをリブートします。
# shutdown -r now
LSM を使用して,ルート (/
),/usr
,および
/var
ファイル・システムをミラー化します (2.5.2 項
,
volmigrate
(8)volencap
(8)
その他のシステムを一度に 1 つずつクラスタに追加します。各システムで次の作業を行います。
システムの電源をオンにします。
show config
コンソール・コマンドを使用して,コンソールおよびアダプタのファームウェア・リビジョンが Tru64 UNIX バージョン 5.1B と互換性があるかどうかを確認します。互換性がない場合は,必要に応じてファームウェアをアップデートします。
第 5 章で説明している手順に従い,現在のクラスタ・メンバで
clu_add_member
コマンドを実行して,新しいメンバのブート・ディスクを作成します。
新しいメンバをブートしてクラスタに追加します。