PowerScale:1対多またはカスケード レプリケーションでのSmartSyncのSYNCIQポリシー移行エラー

SmartSyncのSyncIQポリシーの移行が、次の2つのエラーのいずれかで失敗します。

1. Error Message: Migration blocked: Source record snapshot (<snapshot-id>) does not match latest dataset snapshot (<snapshot-id>) for the source basepath (<source-base-path>). This source basepath may act as a target for an existing SmartSync policy. Hence, the SIQ policy migration can't proceed unless the two snapshots are identical. Start the SIQ policy to match the latest dataset snapshot (<snapshot-id>) in source.
2. Error Message: Migration blocked: Source record snapshot (<snapshot-id>) is older than the snapshot (<snapshot-id>) associated with the latest dataset (<dataset details>) for the source basepath (<source-base-path>). Replicate to the latest snapshot or above to proceed with the SIQ policy migration.

エラー1は、ソース ベースパスに、SmartSyncによってターゲット データセットとしてマークされている既存のデータセットがある場合に発生します。また、移行に使用されている関連スナップショット(SyncIQポリシーのソース レコードによって使用されている)が、特定のソース ベースパスの最新のデータセットで使用されているスナップショットと同じではありません。

エラー2は、ソース ベースパスに、SmartSyncによってターゲット データセットとしてマークされていない既存のデータセットがある場合に発生します。また、移行に使用される関連スナップショット(SyncIQポリシーのソース レコードによって使用される)が、特定のソースベースパスに対して最新のデータセットによって使用されるスナップショット以上ではありません。

エラーがすでに発生している場合は、「回復手順」セクションに進みます。

事前の移行手順

移行ジョブにエラーが表示される前に実行する予防措置。移行ジョブを開始する前に、次の手順を実行して、前述のエラーを回避します。

ファンアウト構成(A → B + A → C)

1. ステップ1: SyncIQポリシーのDocumentum Interactive Delivery Servicesを特定します。例：

   1. ポリシーA→B:
      # isi sync policies view <pol_a_b> | head -2
   2. ポリシーA→C:
      # isi sync policies view <pol_a_c> | head -2

2. ステップ2:クラスターAのソース レコード ディレクトリー:

   # cd /ifs/.ifsvar/modules/tsm/config/source_records/

3. ステップ3: 各ポリシーIDに対応するXMLファイルを一覧表示して表示し、最新のsnap-id値をメモします。

   1. A→Bスナップショットを確認します(結果のIDは次の手順でAXになります)。
      # grep '<latest-snap-id>' <pol_a_b_ID>.xml

   2. A→Cスナップショットを確認します(結果のIDは次の手順でAYになります)。
      # grep '<latest-snap-id>' <pol_a_c_ID>.xml

4. ステップ4: latest-snap-idの値を比較します。古い(より低い)latest-snap-idを最初に使用してポリシーを移行します。
   AからBのスナップショット(AX)がAからCのスナップショット(AY)よりも古い場合は、次のようになります。 AX = snapID 100,AY = snapID150.
   次に、最初にAからBポリシーに移行します
   
   たとえば、A から C のスナップショット (AY) が A から B のスナップショット (AX) よりも古い場合は、次のようになります。 AX = snapID 150,AY = snapID100.
   次に、最初にAからCポリシーに移行します。
   
   両方のポリシーで同じスナップショットを使用する場合は、例: AX = 100,AY = 100.
   どちらのポリシーも最初に移行できます。2番目のポリシー移行では、データセットが再利用されます。

チェーン(カスケード)構成(A→B→C)

1. 同期が完全に完了し、ポリシー チェーンに関与するすべてのクラスターが同一のデータを反映していることを確認する必要があります。

2. 移行を続行する前に、チェーン内のすべてのSyncIQポリシーを無効にします。これにより、移行の進行中に新しい増分SyncIQジョブがトリガーされるのを防ぐことができます。たとえば、A→B→Cチェーンでは、A→BポリシーとB→Cポリシーの両方を無効にします。

3. 重要: 移行は常にルート(ソース)クラスターから開始する必要があります。中間クラスター(3クラスター構成のBなど)の場合、ソース ベースパスが別のSmartSyncポリシーのターゲットでもあるすべてのポリシーは、そのベースパスの最新のデータセットと同じ(同一の)スナップショットを使用する必要があります。スナップショットが一致しない場合、移行ジョブは一時停止します(永続的にブロックされるわけではありません)。「リカバリー手順」セクションに以下のリカバリー手順が追加されました。

   チェーン ポリシーを移行する前に、B→C SyncIQポリシーが、クラスターBのA→Bポリシーによって生成されたスナップショット パターンと同じスナップショット ベースの同期を使用していることを確認します。これにより、両方のポリシーがリレークラスタ上で同じスナップショットベースラインを共有するようになります。

4. B→C SyncIQポリシーが最初にスナップショットベースの同期で設定されていなかった場合は、移行前に次の手順に従ってポリシーをアップデートします。

   1. ステップ1: A→Bポリシーによって、デフォルトの命名パターンSIQ-*以外の命名パターンを使用して、アーカイブ ターゲット スナップショット(Target Snapshot Archive:Yesと表示されている)も作成されていることを確認します。

      # isi sync policies view pol_wJ9n-a2b | grep -E "Target Snapshot Archive|Target Snapshot Pattern" Target Snapshot Archive: No Target Snapshot Pattern: SIQ-%{SrcCluster}-%{PolicyName}-%Y-%m-%d_%H-%M-%S

      上記の例でお気づきのように、Target Snapshot Archiveは「No」に設定されており、パターンはデフォルトのもので、プレフィックスはSIQ-*です。

   2. ステップ2: デフォルト以外のパターンでアーカイブ スナップショットを作成するには、A→Bポリシーを変更します。

      # isi sync policies modify <A_to_B_policy> --target-snapshot-archive True --target-snapshot-pattern 'snapB-%{PolicyName}-%Y-%m-%d'

# isi sync policies view pol_wJ9n-a2b | grep -E "Target Snapshot Archive|Target Snapshot Pattern" Target Snapshot Archive: Yes Target Snapshot Pattern: snapB-%{PolicyName}-%Y-%m-%d
      

   3. ステップ3: B→Cポリシーを変更して--schedule=when-snapshot-takenを使用します。

      # isi sync policies modify <B_to_C_policy> --schedule=when-snapshot-taken

   4. ステップ4: A→Bポリシーのジョブをトリガーして、B→Cポリシーがそのジョブに追いつき、A->Bによって作成されたアーカイブ スナップショットを再利用するようにします。reportsコマンドを実行して確認できます。

      # isi sync job start <A_to_B_policy>

# isi sync reports list

      両方の A→B ポリシーのジョブが完了するのを待ち、B→C ポリシーのジョブをトリガーします。両方のジョブが完了したら、次のコマンドを使用して、A→Bポリシーの最新の実行によって作成されたアーカイブ スナップショットがB→Cの最新ジョブによって再利用されていることを確認します。

      # cat /ifs/.ifsvar/modules/tsm/config/target_records/<A_to_B_policy_Id>.xml | grep latest-archive-snap 
   <latest-archive-snap-alias>621</latest-archive-snap-alias> 
         <latest-archive-snap>625</latest-archive-snap>

# cat /ifs/.ifsvar/modules/tsm/config/source_records/<B_to_C_policy_Id>.xml | grep latest-snap-id
           <latest-snap-id>625</latest-snap-id>
   <restore-latest-snap-id>0</restore-latest-snap-id>
      

      前述のように、B→Cポリシーのlatest-snap-idは、A→Bのlatest-archive-snapと同じです。これは、連鎖ポリシーの移行が正常に完了する状態です。

リカバリ移行手順

移行がすでに試行されていて、移行ジョブがPAUSED状態になる場合は、次のリカバリー手順に従います。

ファンアウト構成

SyncIQポリシー移行ジョブがエラーで失敗すると、対応するSyncIQポリシーが再度有効になります。軽減手順は次のとおりです。

1. ステップ1:SyncIQポリシーを実行して、キャッチアップします。
   # isi sync job start <policy-name>
   
2. 手順2:新しいジョブの実行が正常に完了し、レポート出力に表示されるまで待ちます。
   # isi sync reports list --policy-name <policy-name>
3. 手順3:一時停止していたSmartSync移行ジョブを再開します。
   # isi dm jobs resume <job_id>

チェーン(カスケード)構成

SyncIQポリシー移行ジョブがエラーで失敗すると、対応するSyncIQポリシーが再度有効になります。軽減手順は次のとおりです。

1. ステップ1: 次のコマンドを使用して、SyncIQポリシーを変更します。
   # isi sync policies modify <B_to_C_policy> --schedule=when-snapshot-taken
2. ステップ2: 次のコマンドを使用して、A->B Smart Syncポリシーを実行します(アップストリーム ポリシーがすでに移行されていることを前提としています)。
   # isi dm policies modify <policy_name> --run-now=yes
   スナップショットは、ソース ベースパス上の最新のデータセット スナップショットと自動的に同期されます。
3. ステップ3: 次のコマンドを使用して移行ジョブを再開します。
   # isi dm jobs resume <job_id>