Storage Foundation 7.3.1 設定およびアップグレードガイド- Linux

以前の VVR バージョンからのアップグレードの計画

VVR を以前の VVR バージョンからアップグレードする場合、ホストを個別の時間にアップグレードすることによって、アプリケーション停止時間を減らして、VVR をアップグレードできます。 プライマリがアップグレードされる間、アプリケーションはセカンダリに移行されるので、ダウンタイムを削減できます。 プライマリをアップグレードすると、VVR のバージョンがセカンダリと異なるものになりますが、それでも複製は可能です。 この機能により、両方のサイト上で VVR アップグレードが完了しなくても、高可用性を保つことができます。 セカンダリホストは、RDS（Replicated Data Set）のプライマリホストより前にアップグレードすることをお勧めします。

Storage Foundation バージョンを渡ってレプリケートするための VVR サポートに関する情報が記載されている『Veritas InfoScale™ リリースノート』を参照してください。

異なるバージョン間でレプリケートするのは、プライマリとセカンダリを同時にアップグレードすることの制限を取り除くためです。 VVR は、アップグレードするシステムで RVG（Replicated Volume Group）のある既存の RDS をレプリケートし続けることができます。 プライマリとセカンダリが異なるバージョンであるとき、VVR は vradmin コマンドでの設定の変更、または新しい RDS の作成をサポートしません。


TCP をネットワークプロトコルとして指定する場合は、プライマリおよびセカンダリの VVR バージョンによって、チェックサムが計算されるかどうかが決まります。 表: VVR バージョンとチェックサム計算 に示すように、プライマリまたはセカンダリで 7.3.1 以前のバージョンの VVR が動作していて、TCP プロトコルを使う場合は、レプリケートするデータパケットごとにチェックサムが計算されます。 プライマリとセカンダリで VVR 7.3.1 が動作している場合は、チェックサムは計算されません。代わりに TCP チェックサム機構が使われます。

RDS のすべてのホストを同時にアップグレードする必要がないのであれば、1 台のホストをアップグレードした後、バージョン間の複製を使用できます。 その後、都合のよい時点で、RDS の他のホストをアップグレードできます。