Veritas Access 7.3 インストールガイド
- Veritas Access の概要
- Veritas Access のライセンス
- システム要件
- システム要件
- Linux の必要条件
- Linux の必要条件
- ネットワークとファイアウォールの要件
- Veritas Access をインストールする準備
- VMware ESXi での Veritas Access インストール用の仮想マシンの配備
- クラスタのインストールと設定
- 応答ファイルを使用した Veritas Access のインストールと設定の自動化
- クラスタのノードの表示と追加
- Veritas Access のアップグレード
- ローリングアップグレードを使用した Veritas Access のアップグレード
- Veritas Access のアンインストール
- 付録 A. インストールの参考情報
- 付録 B. 通信用のセキュアシェルの設定
Veritas Access パッチのタイプについて
パッチにクラスタの再起動が必要かどうかによって、Veritas Access パッチは次の 2 つのタイプに分類されます。
クラスタの再起動を必要としないパッチ
これらのパッチは、直接アップグレードする方法で、Veritas Access パッケージと重要性の低いパッケージをアップグレードします。直接アップグレードする方法では、パッチの適用時にノードまたはリソースが停止しません。アップグレードでは、パッチがすべてのノードで同時に適用されます。アップグレードプロセスの実行時は、クラスタは RUNNING の状態のままで、クライアントにサービスが提供されます。
クラスタの再起動が必要なパッチ
これらのパッチでは、ローリングアップグレードの方法で重要なパッケージをアップグレードします。その際 1 度だけクラスタの再起動が必要です。ローリングアップグレードの方法で、Veritas Access リリースをガイドに従ってすべてのクラスタノードにインストールできます。ローリングアップグレードが、サービスグループフェールオーバーの実行に要する時間を制限することで、高可用性クラスタのダウンタイムが最小化されます。
メモ:
単一のノードクラスタでパッチを更新すると、サービスのダウンタイムが発生します。これはカーネル RPM と VCS エージェント RPM の両方が 1 つの段階でアップグレードされるためです。
ローリングアップグレードには、2 つの主要な段階があります。インストーラにより段階 1 でカーネル RPMs が、段階 2 で VCS エージェント RPMs がアップグレードされます。アップグレードプロセスでは、クラスタが 1 番目のサブクラスタ、2 番目のサブクラスタと呼ばれる 2 つのサブクラスタに分割されます。まず、アップグレードは 1 番目のサブクラスタで実行されます。アップグレードプロセスは 1 番目のサブクラスタのノードのすべてのサービスとリソースを停止します。すべてのサービス (VIP グループを含む) は 2 番目のサブクラスタにフェールオーバーします。フェールオーバープロセス時に、1 番目のサブクラスタノードの VIP グループに接続しているクライアントは断続的に中断されます。タイムアウトしないクライアントの場合、サービスは、VIP グループが 2 番目のサブクラスタのいずれかのノードでオンラインになった後に再開されます。
アップグレードプロセスが 1 番目のサブクラスタのノードで実行中の間、2 番目のサブクラスタのノードではクライアントを実行し続けます。1 番目のサブクラスタノードはアップグレードされた後、最初の段階のノードのサービスとリソースを再起動します。1 番目のサブクラスタが実行された直後に、アップグレードプロセスは残りのノードのサービスとリソースを停止します。すべてのサービスとリソースはオンラインになり、クライアントにサービスを提供します。それと同時に、ローリングアップグレードが残りのノードでアップグレードプロセスを開始します。アップグレードが残りのノードで完了すると、クラスタが回復し、サービスがクラスタ間で調整されます。