PowerScale: Erro de migração de política SYNCIQ do SmartSync para replicação de um para muitos ou em cascata

A migração de políticas do SyncIQ do SmartSync falha com um dos dois erros:

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.

O erro 1 ocorre quando o caminho base de origem tem conjuntos de dados pré-existentes marcados como um conjunto de dados de destino pelo SmartSync. E o snapshot associado que está sendo usado para migração, usado pelo registro de origem da política do SyncIQ, não é o mesmo usado pelo conjunto de dados mais recente para o caminho base de origem específico.

O erro 2 ocorre quando o caminho base de origem tem conjuntos de dados pré-existentes que não são marcados como um conjunto de dados de destino pelo SmartSync. E o snapshot associado que está sendo usado para migração, usado pelo registro de origem da política do SyncIQ, não é maior ou igual ao snapshot usado pelo conjunto de dados mais recente para o caminho base de origem específico.

Se o erro já tiver ocorrido, vá para a seção Etapas de recuperação.

Etapas de migração preventiva

Etapas de precaução a serem seguidas antes que os erros já tenham sido exibidos no trabalho de migração. Antes de iniciar o trabalho de migração, execute as seguintes etapas para evitar os erros mencionados acima:

Configuração fan-out (A → B + A → C)

1. Passo 1: Identifique sua política do SyncIQ Documentum Interactive Delivery Services. Por exemplo:

   1. Política A → B:
      # isi sync policies view <pol_a_b> | head -2
   2. Política A → C:
      # isi sync policies view <pol_a_c> | head -2

2. Etapa 2: o diretório de registros de origem no cluster A:

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

3. Passo 3: Liste e visualize o arquivo XML correspondente a cada ID de política e observe o valor mais recente:

   1. Verifique o snapshot A→B (o ID resultante será AX na próxima etapa):
      # grep '<latest-snap-id>' <pol_a_b_ID>.xml

   2. Verifique o snapshot →C (o ID resultante será AY na próxima etapa):
      # grep '<latest-snap-id>' <pol_a_c_ID>.xml

4. Passo 4: Compare os valores mais recentes de snap-id. Migre primeiro a política com o mais antigo (inferior)latest-snap-id:
   Se o snapshot A para B (AX) for mais antigo que o snapshot A para C (AY), por exemplo: AX = snapID 100,AY = snapID150.
   Em seguida, migre primeiro a política de A para B.
   
   Se o snapshot A para C (AY) for mais antigo que o snapshot A para B (AX), por exemplo: AX = snapID 150,AY = snapID100.
   Em seguida, migre primeiro a política A para C.
   
   Se ambas as políticas usarem o mesmo snapshot, por exemplo: AX = 100,AY = 100.
   Qualquer política pode ser migrada primeiro. A segunda migração de política reutiliza o conjunto de dados.

Configuração encadeada (em cascata) (A → B → C)

1. A sincronização deve ser totalmente concluída, garantindo que todos os clusters envolvidos no encadeamento de políticas reflitam dados idênticos.

2. Desative todas as políticas do SyncIQ na cadeia antes de prosseguir com a migração. Isso impede que qualquer novo trabalho incremental do SyncIQ seja acionado enquanto a migração está em andamento. Por exemplo, em uma cadeia A→B→C, desative as políticas A→B e B→C.

3. Importante: A migração deve sempre começar a partir do cluster raiz (origem). Para qualquer cluster intermediário (como B em uma configuração de 3 clusters), todas as políticas cujo caminho base de origem também é um destino para outra política do SmartSync devem usar o mesmo snapshot (idêntico) que o conjunto de dados mais recente para esse caminho base. Se os snapshots não corresponderem, o trabalho de migração será pausado (não bloqueado permanentemente). Etapas de recuperação adicionadas abaixo na seção Etapas de recuperação.

   Antes de migrar políticas encadeadas, certifique-se de que a política do B→C SyncIQ use a sincronização baseada em snapshot com o mesmo padrão de snapshot produzido pela política A→B no cluster B. Isso garante que ambas as políticas compartilhem a mesma linha de base de snapshot no cluster de retransmissão.

4. Se a política do B→C SyncIQ não foi originalmente configurada com sincronização baseada em snapshot, atualize-a antes da migração usando as seguintes etapas:

   1. Passo 1: Verifique se a política A→B cria snapshots de destino de arquivamento (Target Snapshot Archive: deve mostrar Yes) também com um padrão de nomenclatura diferente do padrão de SIQ-*.

      # 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

      Como você notaria no exemplo acima, o Target Snapshot Archive é definido como "No" e o padrão é o padrão com um prefixo SIQ-*.

   2. Passo 2: Modifique a política A→ B para criar um snapshot de arquivo com um padrão diferente do padrão:

      # 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. Passo 3: Modifique a política B→C para usar --schedule=when-snapshot-taken:

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

   4. Passo 4: Acione o trabalho da política de A→B para garantir que a política de B→C a alcance e reutilize o snapshot de arquivamento criado por A-B>; você pode verificar executando o comando de relatórios.

      # isi sync job start <A_to_B_policy>

# isi sync reports list

      Aguarde até que o trabalho da política A→B seja concluído, o que acionará o trabalho da política B→C. Depois que os dois trabalhos forem concluídos, valide se o snapshot de arquivamento criado pela execução mais recente da política A→B é reutilizado pelo trabalho mais recente do B→C usando o seguinte comando:

      # 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>
      

      Como você notou acima, o mais recente-snap-id para a política B→ C é o mesmo que o mais recente-archive-snap para A→ B. Qual é o estado do qual a migração da política encadeada deve ser realizada com sucesso.

Etapas da migração de recuperação

Se a migração já tiver sido tentada e o trabalho de migração entrar em um estado PAUSADO, siga estas etapas de recuperação:

Configuração de fan-out

Quando um trabalho de migração de política do SyncIQ apresenta falha com o erro, a política correspondente do SyncIQ é ativada de volta. As etapas de redução são:

1. Etapa 1: Execute a política do SyncIQ para recuperar o atraso:
   # isi sync job start <policy-name>
   
2. Etapa 2: Aguarde até que a execução do novo trabalho seja concluída com sucesso e apareça na saída dos relatórios:
   # isi sync reports list --policy-name <policy-name>
3. Etapa 3: retome o trabalho de migração do SmartSync que foi pausado:
   # isi dm jobs resume <job_id>

Configuração em cadeia (em cascata)

Quando um trabalho de migração de política do SyncIQ apresenta falha com o erro, a política correspondente do SyncIQ é ativada de volta. As etapas de redução são:

1. Passo 1: Modifique a política do SyncIQ usando o comando:
   # isi sync policies modify <B_to_C_policy> --schedule=when-snapshot-taken
2. Passo 2: Execute a política A-B> Smart Sync usando o comando (supondo que a política de upstream já tenha sido migrada):
   # isi dm policies modify <policy_name> --run-now=yes
   Ele sincronizará automaticamente o snapshot com o snapshot mais recente do conjunto de dados no caminho base de origem.
3. Passo 3: Retome o trabalho de migração usando o comando:
   # isi dm jobs resume <job_id>