Veritas Access インストールガイド
- Veritas Access のライセンス
- システム要件
- Veritas Access をインストールする準備
- VMware ESXi での Veritas Access インストール用の仮想マシンの配備
- クラスタのインストールと設定
- クラスタの各ノードでのオペレーティングシステムのインストール
- ターゲットクラスタノードでの Veritas Access のインストール
- NIC、結合、および VLAN デバイスの管理について
- VLAN のタグ付けについて
- 応答ファイルを使用した Veritas Access のインストールと設定の自動化
- クラスタのノードの表示と追加
- オペレーティングシステムと Veritas Access のアップグレード
- ローリングアップグレードの実行
- Veritas Access のアンインストール
- 付録 A. インストールの参考情報
- 付録 B. 通信用のセキュアシェルの設定
- 付録 C. Veritas Access の手動配備
インストーラを使用したローリングアップグレードの実行
メモ:
ローリングアップグレードを開始する前に、Veritas Access リリースノートの「既知の問題」にある「アップグレードの問題」セクションをお読みください。
ローリングアップグレードを開始する前に、VCS (Veritas Cluster Server) がクラスタのすべてのノードで実行されていることを確認します。
VCS の制御下にないすべての VxVM ボリュームのすべてのアクティビティを停止します。たとえば、データベースなどのボリュームにアクセスするすべてのアプリケーションを停止し、ボリュームに作成されているすべてのファイルシステムをマウント解除します。その後、すべてのボリュームを停止します。
VCS の制御下にないすべての VxFS ファイルシステムをマウント解除します。
メモ:
マスターノードでローリングアップグレードを開始してから完了するまで、Veritas Access GUI にはアクセスできません。
メモ:
ローリングアップグレード中、Veritas Access コマンドラインインターフェースで使用するのは、list コマンドと show コマンドのみにすることをお勧めします。create、destroy、add、remove などの他のコマンドを使用すると、Veritas Access の設定が更新される場合があります。これは、ローリングアップグレード中には推奨されません。
ローリングアップグレードを実行するには
- LTR が設定されている Veritas Access クラスタの場合、NetBackup からのバックアップジョブまたは復元ジョブが停止していることを確認します。
- ローリングアップグレードの段階 1 は、2 番目のサブクラスタで開始します。2 番目のサブクラスタで予備手順を完了します。
VCS の制御下にないすべての VxFS ファイルシステムをマウント解除します。
# umount mount_point
- 必要に応じて、オペレーティングシステムへの更新を完了します。
Veritas Access の既存のバージョンが、適用するオペレーティングシステムの更新をサポートしていることを確認します。Veritas Access の既存のバージョンがオペレーティングシステムの更新をサポートしていない場合、最初に Veritas Access をオペレーティングシステムの更新をサポートしているバージョンにアップグレードします。
手順については、Red Hat Enterprise Linux (RHEL) オペレーティングシステムのマニュアルを参照してください。
アプリケーションを残りのサブクラスタに切り替えて、1 番目のサブクラスタのオペレーティングシステムをアップグレードします。
オペレーティングシステムの更新後に、ノードが再起動されます。
- キャッシュ領域がオンラインの場合は、キャッシュ領域をオフラインにしてから VxVM RPMs をアップグレードする必要があります。キャッシュ領域をオフラインにするには、次のコマンドを使用します。
# sfcache offline cachename
- スーパーユーザーとしてログオンし、Veritas Access 7.4.2 インストールメディアをマウントします。
- ルートからインストーラを起動します。
# ./installaccess -rolling_upgrade
- インストーラはシステム通信、リリース互換性、バージョン情報を確認し、クラスタ名、ID、クラスタノードを一覧表示します。インストーラからローリングアップグレードを続行する許可が求められます。
Would you like to perform rolling upgrade on the cluster? [y,n,q] (y)
続行するには、y を入力します。
- ローリングアップグレードの段階 1 が開始されます。段階 1 は、一度に 1 つのノードで実行する必要があります。インストーラからシステム名が求められます。
ローリングアップグレードを実行するシステムの名前をスペースで区切って入力してください。[q?]
ローリングアップグレードを実行するいずれかのスレーブノードの名前または IP アドレスを入力します。
- インストーラがクラスタ内のノードでさらに事前チェックを実行し、警告が表示されることがあります。y を入力して続行することも、インストーラを終了して事前チェックの警告に対処することもできます。
- ブートディスクがカプセル化され、ミラー化されている場合は、バックアップブートディスクを作成できます。
バックアップブートディスクを作成する場合は、y を入力します。ブートディスクグループにバックアップ名を付けるか、デフォルト名を受け入れます。次にインストーラによってブートディスクグループのバックアップが作成されます。
- インストーラでオンラインサービスグループが検出されると、ユーザーは次のいずれかを行うことを求められます。
サービスグループを手動で切り替える
CPI を使用してサービスグループを自動的に切り替える
ダウンタイムは、サービスグループのフェールオーバーにかかる時間です。
メモ:
ベリタスでは、手動でのサービスグループの切り替えを推奨しています。サービスグループの自動切り替えでは、依存関係の問題は解決されません。
- インストーラから該当するプロセスを停止するように求められます。続行するには、y を入力します。
インストーラによってすべてのサービスグループがこの時点でアップグレードされていないノードに退避されます。インストーラによってアップグレードされるノード上のパラレルサービスグループが停止されます。
インストーラによって関連プロセスがすべて停止され、古いカーネル RPMs がアンインストールされ、新しい RPMs がインストールされます。
- インストーラによって、アップグレードの設定が行われ、プロセスが開始されます。アップグレード前にブートディスクがカプセル化されると、アップグレードの設定を実行した後にインストーラからノードを再起動するように求められます。
- まだアップグレードしていないノードで予備手順を完了します。
すべてのノードで VCS の制御下にないすべての VxFS ファイルシステムをマウント解除します。
# umount mount_point
- オペレーティングシステムの更新が不要な場合、この手順をスキップします。
手順 16 に進みます。
そうでない場合は、まだアップグレードしていないノードでオペレーティングシステムへの更新を完了します。手順については、Red Hat Enterprise Linux (RHEL) オペレーティングシステムのマニュアルを参照してください。
- ノードで段階 1 のアップグレードが終了したら、ノードがクラスタ外にはないことを確認します。
# vxclustadm nidmap コマンドを入力します。
アップグレードしたノードがクラスタ外にある場合、次のノードの段階 1 のアップグレードを開始する前に、ノードがクラスタに参加するまで待機します。
- ローリングアップグレードの段階 1 が 1 番目のノードで完了します。次のスレーブノードの段階 1 のアップグレードを開始できます。再度、インストーラからシステム名が求められます。
次のノードのローリングアップグレードの段階 1 を開始する前に、進行中のリカバリタスクがないかどうかを確認します。リカバリタスクの完了を待機します。
マスターノードで次のコマンドを入力します。
# vxtask list Check if following keywords are present: ECREBUILD/ATCOPY/ATCPY/PLXATT/VXRECOVER/RESYNC/RECOV
進行中のリカバリタスクがある場合、タスクが完了するまで待機し、次のノードの段階 1 のアップグレードを開始します。
- 残りのノードですべてのキャッシュ領域をオフラインに設定します。
# sfcache offline cachename
インストーラからアップグレードを実行するノード名が求められます。
- ローリングアップグレードを実行するシステムの名前をスペースで区切って入力してください。[q,?]
クラスタノード名を入力するか、q を入力して終了します。
多くのノードがあるクラスタの場合、このプロセスが数回繰り返される場合があります。サービスグループが終了し、アップグレードに対応するために起動されます。
- ローリングアップグレードの段階 1 が完了したら、VCS の制御下にないすべての VxFS ファイルシステムを手動でマウントします。
ローリングアップグレードの段階 2 を開始する前に、すべてのノードがクラスタに参加しており、すべてのリカバリタスクが完了していることを確認します。
アップグレードの段階 2 を開始します。アップグレードの段階 2 には、VCS エンジン (HAD) のダウンタイムが含まれます。これにはアプリケーションのダウンタイムは含まれません。続行するには、y を入力します。ここからローリングアップグレードの段階 2 が開始します。
- インストーラによってアップグレードする残りの RPMs が決定されます。続行する場合は y キーを押します。
- VCS (Veritas Cluster Server) プロセスはインストーラによって停止されますが、アプリケーションは引き続き実行されます。続行するには、y を入力します。
インストーラによって prestop が実行され、古い RPMs がアンインストールされ、新しい RPMs がインストールされます。インストール後のタスクとアップグレードの設定が実行されます。
- インターネットへのネットワーク接続がある場合、インストーラによって更新が確認されます。
更新が検出された場合は、ここで適用できます。
- クラスタの状態を確認します。
# hastatus -sum
- LTR が設定されている Veritas Access クラスタのみのアップグレード後の手順:
次のコマンドを使用して、すべての OpenDedup ボリュームをオフラインにします。
cluster2> opendedup volume offline <vol-name>
次のように、すべての OpenDedup
config.xml
ファイルを更新します。"/etc/sdfs/<vol-name>-volume-cfg.xml
次のパラメータを <extended-config> タグに追加することで更新します。
dist-layout="false"
メモ:
既存の OpenDedup ボリュームはデフォルトのレイアウトの既存のデータを持つ可能性があるため、これらのボリュームにこのパラメータを使用しないでください。既存の OpenDedup ボリュームを使用する場合は、データが破損する可能性があります。
次のコマンドを使用して、すべての OpenDedup ボリュームをオンラインにします。
cluster2> opendedup volume online <vol-name>
詳細情報