1 Oracle ZFS Storage Appliance の概要
プロジェクトレベルのレプリケーションとシェアレベルのレプリケーションの比較
レプリケーションを逆向きにする - 障害からの回復のシミュレート
スナップショットは増分レプリケーションの基礎です。増分レプリケーションを継続するためには、ソースとターゲットが常に共通のスナップショットをシェアする必要があります。また、ソースは、どれがターゲット上で最新のスナップショットかを把握する必要があります。これを簡単にするために、レプリケーションサブシステムは独自のスナップショットを作成して管理します。通常、管理者がこれらに注意を払う必要はありませんが、スナップショットはストレージの利用率にかなり影響することがあるため、ここで詳細に説明します。
特定のアクションのレプリケーション更新は、それぞれ次の手順で行われます。
以前にこのアクションのレプリケーションを試みたかどうか、およびターゲットが増分更新に必要なスナップショットをすでに持っているかどうかに基づいて、これが増分更新か完全更新かを判定します。
新しいプロジェクトレベルのスナップショットを作成します。
更新を送信します。完全更新の場合は、この新しいスナップショットまでのグループの内容全体を送信します。増分更新の場合は、前回のスナップショット (基礎) とこの新しいスナップショットの間の差分を送信します。
この新しいスナップショットを次回の更新のベーススナップショットとして記録し、前回のベーススナップショットを破棄します (増分更新の場合)。ベーススナップショットは、次回の更新を受信するまでターゲット上に残ります。次回の更新の時点で、そのベーススナップショットは破棄される最初の項目となります。
これは、スナップショットの管理にいくつかの影響を与えます。
最初のレプリケーション更新の進行中、および最初の更新のあとレプリケーションがアクティブでないときは、グループのプロジェクトまたはシェアに構成されている各アクションに、プロジェクトレベルのスナップショットが正確に 1 つ存在します。レプリケーションアクションで、そのアクションによりレプリケートされているグループ内のシェアと同じプロジェクト内にあるが、そのグループ用の更新の一部として送信されていないシェア上にスナップショットが作成されることがあります。
特定のアクションによる以降のレプリケーション更新の進行中には、そのアクションに関連するプロジェクトレベルのスナップショットが 2 つ存在することがあります。ソースで、ターゲットが新しいスナップショットを正常に受信したかどうかを判定できなかった場合 (更新中にネットワークの機能停止で障害が発生した場合など)、更新の完了後に両方のスナップショットが残ることがあります。
レプリケーションアクションに関連付けられたスナップショットを管理者が破棄すると、増分レプリケーションが破壊されます。管理者は、ソースまたはターゲット上にある、増分レプリケーションに必要なスナップショットを破棄することはできません。ソース上のそのようなスナップショットを破棄するには、アクションを破棄する必要があります (これにより、そのアクションに関連付けられたスナップショットが破棄される)。ターゲット上のそのようなスナップショットを破棄するには、まずパッケージを切断する必要があります (これにより、そのパッケージに増分更新を受信できなくなる)。
管理者はレプリケーションスナップショットより前に作成されたスナップショットにロールバックしてはいけません。この操作を行うと、それよりあとのレプリケーションスナップショットが破棄され、それらのスナップショットを使用するすべてのアクションの増分レプリケーションが破壊されます。
レプリケーションでスナップショットを使用するには、管理者は、ZFSSA のスペース管理、特にそのスナップショットへの適用について理解している必要があります。
LUN のレプリケーションのスペース管理の詳細は、LUN のレプリケーションのスペース管理を参照してください