Veritas Access インストールガイド
- Veritas Access の概要
- Veritas Access のライセンス
- システム要件
- 重要なリリース情報
- システム要件
- Linux の必要条件
- オペレーティングシステム RPM のインストール要件とオペレーティングシステムのパッチ適用
- 正確に事前定義済みの RPM バージョンでインストールする必要があるカーネル RPM
- 正確に事前定義済みの RPM バージョンでインストールする必要がある OL カーネル RPM
- OL 6.8 に必要なオペレーティングシステム RPM
- OL 7.3 に必要なオペレーティングシステム RPM
- OL 7.4 に必要なオペレーティングシステム RPM
- RHEL 6.6 に必要なオペレーティングシステム RPM
- RHEL 6.7 に必要なオペレーティングシステム RPM
- RHEL 6.8 に必要なオペレーティングシステム RPM
- RHEL 7.3 に必要なオペレーティングシステム RPM
- RHEL 7.4 に必要なオペレーティングシステム RPM
- VMware ESXi 環境に Veritas Access をインストールするためのソフトウェア要件
- Veritas Access 仮想マシンをインストールするためのハードウェア要件
- 管理サーバーの Web ブラウザサポート
- サポート対象の NetBackup バージョン
- サポート対象の OpenStack バージョン
- サポート対象の Oracle バージョンとホストオペレーティングシステム
- サポート対象の IP バージョン 6 インターネット標準プロトコル
- Linux の必要条件
- ネットワークとファイアウォールの要件
- 最大構成の制限
- Veritas Access をインストールする準備
- VMware ESXi での Veritas Access インストール用の仮想マシンの配備
- クラスタのインストールと設定
- 応答ファイルを使用した Veritas Access のインストールと設定の自動化
- クラスタのノードの表示と追加
- Veritas Access のアップグレードとオペレーティングシステム
- ローリングアップグレードを使用した Veritas Access のアップグレード
- Veritas Access のアンインストール
- 付録 A. インストールの参考情報
- 付録 B. LTR アップグレードのトラブルシューティング
- 付録 C. 通信用のセキュアシェルの設定
ローリングアップグレードについて
Veritas Access のこのリリースでは、Veritas Access 7.2.1.1 以降のバージョンからのローリングアップグレードをサポートしています。ローリングアップグレードは、RHEL 6.6、6.7、6.8 でサポートされています。
ローリングアップグレードが、サービスグループフェールオーバーの実行に要するアップグレード時間を制限することで、高可用性クラスタのサービスとアプリケーションの停止時間が最小化されます。1 つのクラスタで異なる製品バージョンを持つノードを実行できます。
ローリングアップグレードには、2 つの主要な段階があります。インストーラにより段階 1 でカーネル RPMs が、段階 2 で VCS エージェント RPMs がアップグレードされます。アップグレードプロセスでは、クラスタが 1 番目のサブクラスタ、2 番目のサブクラスタと呼ばれる 2 つのサブクラスタに分割されます。まず、アップグレードは 1 番目のサブクラスタで実行されます。アップグレードプロセスは 1 番目のサブクラスタのノードのすべてのサービスとリソースを停止します。すべてのサービス (VIP グループを含む) は 2 番目のサブクラスタにフェールオーバーします。フェールオーバープロセス時に、1 番目のサブクラスタノードの VIP グループに接続しているクライアントは断続的に中断されます。タイムアウトしないクライアントの場合、サービスは、VIP グループが 2 番目のサブクラスタのいずれかのノードでオンラインになった後に再開されます。
アップグレードプロセスが 1 番目のサブクラスタのノードで実行中の間、2 番目のサブクラスタのノードではクライアントを実行し続けます。1 番目のサブクラスタノードはアップグレードされた後、最初の段階のノードのサービスとリソースを再起動します。1 番目のサブクラスタが実行された直後に、アップグレードプロセスは残りのノードのサービスとリソースを停止します。すべてのサービスとリソースはオンラインになり、クライアントにサービスを提供します。それと同時に、ローリングアップグレードが残りのノードでアップグレードプロセスを開始します。アップグレードが残りのノードで完了すると、クラスタが回復し、サービスがクラスタ間で調整されます。
このプロセスは、Veritas Access クラスタでの LTR (Long-term Retention の略で長期的な保有期間) のアップグレードに必要です。ローリングアップグレードプロセスを開始する前に、NetBackup からのすべてのバックアップジョブや復元ジョブを停止する必要があります。
LTR アップグレードシナリオでは、次のスクリプトを使用する必要があります。
preUpgrade_ltr_access731.pypostUpgrade_ltr_access731.py
LTR のローリングアップグレードを開始する前の作業:
OpenDedup ボリュームのキャッシュデータをバックアップするための
odd_cache_fsファイルシステムを作成するpreUpgrade_ltr_access731.pyスクリプトを実行する必要があります。このファイルシステムのサイズは、現在のキャッシュサイズ (/opt/sdfs) に基づいて決定されます。このファイルシステムを作成する Objectaccess のデフォルトプールとして設定されるプール。そのため、このプールには十分な空き領域が必要です。
Odd_cache_fsファイルシステムがプロビジョニングされた後、すべての OpenDedup ボリュームはオフラインになり、設定とキャッシュデータがバックアップされます。
クラスタのローリングアップグレードが完了すると、すべての設定が復元された後にすべての OpenDedup ボリュームがオンラインになる postUpgrade_ltr_access731.py スクリプトを実行する必要があります。
設定されたクラウド階層に対してワンタイム階層ポリシーが作成され、OpenDedup メタデータファイル (終わりに .6442 拡張子が付いている) をクラウド階層からオンプレミスストレージに移動します。これらのメタデータファイルは、OpenDedup の設定を検証および復元するために必要です。これらのファイルをクラウド階層に格納している場合、これらの操作のパフォーマンスが低下する可能性があります。
ローリングアップグレードには 2 つの主要な段階があります。インストーラは段階 1 でカーネル RPMs をアップグレードし、段階 2 で VCS エージェントに関連する非カーネル RPMs をアップグレードします。
次のアップグレード前の手順は、LTR が設定されている Veritas Access クラスタにのみ使用します。
メモ:
これらの手順は、OpenDedup ボリュームが Veritas Access クラスタでプロビジョニングされている場合に必要です。
NetBackup からのバックアップジョブや復元ジョブが停止していることを確認します。
ISO から、
upgrade_scripts/preUpgrade_ltr_access731.pyスクリプトを、OpenDedup ボリュームがオンラインになっている各ノードの/に複製します。OpenDedup ボリュームがオンラインになっているノードごとに 1 回ずつ
preUpgrade_ltr_access731.pyスクリプトを実行します。
アップグレードプロセスで、クラスタが 1 番目のサブクラスタと 2 番目のサブクラスタの 2 つのサブクラスタに分割されます。
段階 1 で、2 番目のサブクラスタでアップグレードが実行されます。アップグレードプロセスにより、2 番目のサブクラスタのノードですべてのサービスとリソースが停止されます。すべてのサービス (VIP グループを含む) が 1 番目のサブクラスタにフェールオーバーします。2 番目のサブクラスタのパラレルサービスグループがオフラインになります。
フェールオーバープロセス中に、2 番目のサブクラスタノードの VIP グループに接続されているクライアントが断続的に中断されます。タイムアウトしないクライアントについては、1 番目のサブクラスタのノードのいずれかで VIP グループがオンラインになった後、サービスが再開されます。
インストーラは 2 番目のサブクラスタでカーネル RPMs をアップグレードします。1 番目のサブクラスタのノードは、引き続きクライアントに提供されます。
ローリングアップグレードの段階 1 が 2 番目のサブクラスタで完了すると、ローリングアップグレードの段階 1 が 1 番目のサブクラスタで実行されます。アプリケーションは 2 番目のサブクラスタにフェールオーバーされます。パラレルサービスグループは、2 番目のサブクラスタでオンラインになり、1 番目のサブクラスタでオフラインになります。
段階 1 が完了すると、古いプロトコルバージョンではなく、新しい RPMs でノードが実行されます。
ローリングアップグレードの段階 2 では、残りのすべての RPMs がクラスタのすべてのノードで同時にアップグレードされます。VCS と VCS のエージェントパッケージがアップグレードされます。カーネルドライバは、新しいプロトコルバージョンにアップグレードされます。段階 2 の間、アプリケーションはオンラインのままです。High Availability Daemon (HAD) が停止し、再び起動します。
次のアップグレード後の手順は、LTR が設定されている Veritas Access クラスタにのみ使用します。
メモ:
これらの手順は、OpenDedup ボリュームが Veritas Access クラスタでプロビジョニングされている場合に必要です。
ISO から、
upgrade_scripts/postUpgrade_ltr_access731.pyスクリプトを管理コンソールノードの/に複製します。postUpgrade_ltr_access731.pyスクリプトを実行します。OpenDedup ボリュームがオンラインになっているノードごとに 1 回ずつ
preUpgrade_ltr_access731.pyスクリプトを実行します。