2009.Q3 以前からのアップグレード

2009.Q3 リリースと 2010.Q1 リリースの間では、レプリケーションの実装が大幅に変更されています。2009.Q3 以前からのアップグレードを開始する前に、ZFSSA へのレプリケーションおよび ZFSSA からのレプリケーションを一時停止することを引き続き強くお勧めします。順次アップグレードを使用するクラスタでは、これは必須です。

2010.Q1 以降へのアップグレードに関連して、ユーザーの目に触れる重要な変更が 3 つあります。

• レプリケーションに使用されるネットワークプロトコルが拡張されました。2009.Q3 システムは、任意のリリース (2010.Q1 以降も含む) を実行しているシステムにレプリケートできますが、2010.Q1 以降を実行しているシステムは、2010.Q1 以降を実行しているほかのシステムにのみレプリケートできます。実際には、プロトコルのバージョンに互換性がないことから発生する障害を避けるために、レプリケーションターゲットのアップグレードをレプリケーションソースよりも前または同時に行う必要があります。

• レプリケーションアクションの構成は、ヘッドシステム上ではなく、ストレージプール自体に保存されるようになりました。そのため、2009.Q3 以前から 2010.Q1 にアップグレードしたあとで、レプリケーション構成を移行するために管理者が遅延更新を適用する必要があります。

• * これらの更新を適用するまでは、既存のレプリケーションのレプリケーション更新が着信しても失敗し、2009.Q3 以前で構成されていたアクションのレプリケーション更新は送信されません。さらに、BUI や CLI からは管理できない未移行のレプリカのためにストレージプールの領域が使用されます。

• * すべての遅延更新と同様に、これらの更新を適用したあとでシステムのソフトウェアをロールバックすると、結果は不定になます。その古いリリースでは、レプリケートされたデータにアクセスできなくなり、レプリケーションアクションはすべて未構成になり、着信するレプリケーション更新は完全更新になることが想定されます。

• レプリケーションの承認は、専用のスコープから「プロジェクトとシェア」スコープに移動されました。2009.Q3 以前で構成されていたレプリケーションの承認は、2010.Q1 には存在しなくなります。レプリケーションに詳細なアクセス制御を使用している管理者は、アップグレード後に新しいレプリケーションの承認を適切な管理者に委任するようにしてください。