アプライアンスのアップグレードとレプリケーションについて

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

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

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

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

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

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

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

レプリケーション更新を実行する前に、レプリケーションサービスは、ターゲットシステムがソースからの新規データと互換性があることを検証します。

• ターゲットと互換性のないソース上で使用中の機能が存在し、その機能を安全に無効にできる場合は、レプリケーションサービスはその機能を無効にして更新を実行し、警告を発行します。

• ターゲットと互換性のないソース上で使用中の機能が存在し、その機能を無効にできない場合は、レプリケーションサービスは更新を実行せずに、エラーを発行します。

レプリケーションの互換性を壊す更新は、遅延更新として配布されます。最新のリストおよび説明については、Oracle ZFS Storage Appliance 顧客サービスマニュアル、更新および最新リリースの Oracle ZFS Storage Appliance リリースノートを参照してください。