Storage Foundation and High Availability 8.0.2 設定およびアップグレードガイド - Linux

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

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

複数の Storage Foundation バージョンにわたるレプリケーションに対する VVR サポートについて詳しくは、『Veritas InfoScale リリースノート』を参照してください。

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

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

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