Isilon: Quais são as etapas da CLI para o failover e failback do SyncIQ?

Summary: Etapas da CLI para fazer failover-failback (FOFB) de uma política.

This article applies to This article does not apply to This article is not tied to any specific product. Not all product versions are identified in this article.
Check out other resources

Symptoms

Quais são as etapas da CLI para failover e failback do SyncIQ?
O processo de IU tem um guia passo a passo, há um guia semelhante para a CLI?

 

Cause

Etapas detalhadas sobre como fazer FOFB

 

Resolution

Guia da CLI para failover e failback:

Embora a documentação acima ofereça algumas boas informações, as etapas abaixo são mais detalhadas ao executar um failover e failback usando a CLI.

As etapas abaixo usam a terminologia do SyncIQ para esses dois termos:

  • Cluster de origem = PRINCIPAL
  • Cluster de destino = SECUNDÁRIO

FAILOVER:

  1. No cluster PRINCIPAL, considere executar o trabalho domainmark Trabalhe com dias ou semanas de antecedência, se essa for a primeira tentativa de failover do cluster. Se o conjunto de dados for grande, isso ajudará a economizar tempo acelerando a fase de trabalho domainmark .

    Nota: Uma nova opção de "Accelerated Failback" remove essa etapa. Essa etapa precisa ser realizada APENAS uma vez. Uma vez marcado, futuro domainmark Os trabalhos são (consulte a etapa 7 abaixo) um No-Op. 
    # isi job jobs start domainmark --root=<path> --dm-type=synciq

    Isso marcará antecipadamente cada LIN com o ID de domínio de proteção apropriado, em vez de fazer com que o trabalho de failover execute tudo (consulte a Etapa 7). A coluna domainmark pode levar muito tempo, dependendo do tamanho do conjunto de dados.

  2. Interrompa todas as gravações no caminho da política PRIMÁRIA.

    Nota: As gravações no caminho da política do cluster PRINCIPAL que ocorrerem a partir desta etapa não ficarão retidas, resultando em uma possível DL. Confirme se todas as gravações nesse caminho NO PRINCIPAL foram interrompidas.

  3. No cluster PRINCIPAL, faça backup dos agendamentos de política e, em seguida, desative todos os agendamentos configurando as políticas como manual.

    Para salvar uma cópia de backup dos agendamentos:

    # cat /ifs/.ifsvar/modules/tsm/config/siq-policies.gc|egrep 'common.name|schedule ' >> /ifs/.ifsvar/modules/tsm/config/policy-schedules.txt

    Em seguida, desative todos os agendamentos definindo as políticas como manual.

    Nota: Por padrão, um trabalho de sincronização e um de failover não podem ser executados simultaneamente, causando uma falha na tentativa de failover. Para evitar essa condição, defina todas as políticas como manual. 
    # isi sync policies modify  --policy=[POLICY] --schedule=""

  4. No no cluster PRINCIPAL, execute um último trabalho de sincronização e confirme se ele foi concluído com sucesso.

    Nota: Esta etapa só é recomendada se estiver testando a funcionalidade do FOFB. Não execute essa etapa se o cluster Principal já tiver identificado um evento de falha e o cluster Secundário já tiver sido configurado para permitir gravações. 
    # isi sync jobs start [POLICY]

    Execute este comando para confirmar a conclusão bem-sucedida:

    # isi sync reports list --reports-per-policy=1
*Confirm the End time and State=finished

    No cluster PRINCIPAL, execute um último trabalho de sincronização.

    # isi sync jobs start [POLICY]

  5. No cluster SECUNDÁRIO, execute a ação "Allow Writes" e verifique se o trabalho local conclui essa ação.

    # isi sync recovery allow-write --policy-name=[POLICY]
# isi sync target list
Name             Source    Target Path              Last Job State  FOFB State
-----------------------------------------------------------------------------------
qtestsync  primary_clust      /ifs/data/siq_quota_test finished        writes_enabled
-----------------------------------------------------------------------------------
Total: 1
    Nota: Inverta as configurações do diretório SmartLock, conforme necessário, em ambos os clusters.
    https://infohub.delltechnologies.com/en-us/l/dell-powerscale-smartlock-best-practices/synciq/

  6. Redirecione os clients (SMB, NFS, HTTP, FTP etc.) para o cluster SECUNDÁRIO

    Nota: As especificidades dessa etapa estão fora do escopo deste artigo e exigem a criação de compartilhamentos SMB, ingresso no domínio do Active Directory, contas de máquina, SPN, exportações NFS, redirecionamento de DNS do SmartConnect e adição de provedores de autenticação.

  7. Crie um snapshot de recuperação em ambos os clusters antes de prosseguir com o resync-prep

    NA ORIGEM

    # isi snapshot snapshots create --path=[SOURCE_PATH] --name=SIQ-recovery-policy-[POLICY_NAME] --expires=2W

    NO DESTINO

    # isi snapshot snapshots create --path=[TARGET_PATH] --name=SIQ-recovery-policy-[POLICY_NAME] --expires=2W

  8. No cluster PRINCIPAL, execute o trabalho de failover com prepare resync e confirme se a fase resync_prep_finalize foi concluída.

    # isi sync recovery resync-prep --policy-name=[POLICY]

# isi sync reports list --policy-name=qtestsync --sort job_id
Policy Name  Job ID  Start Time          End Time            Action                  State
---------------------------------------------------------------------------------------------
qtestsync    1       2015-02-11T08:31:27 2015-02-11T08:31:34 run                     finished
qtestsync    2       2015-02-11T08:41:19 2015-02-11T08:41:31 resync_prep             finished
qtestsync    3       2015-02-11T08:41:31 2015-02-11T08:41:34 resync_prep_domain_mark finished
qtestsync    4       2015-02-11T08:41:34 2015-02-11T08:41:42 resync_prep_restore     finished
qtestsync    5       2015-02-11T08:41:42 2015-02-11T08:41:45 resync_prep_finalize    finished

FAILBACK

Nota importante: Antes de executar essa etapa, verifique no cluster SECUNDÁRIO a existência de um xml source_record para o mesmo ID de política da política original. Por exemplo, no caso do ID da política de origem 7da67596f099b75ad687a05f6b11781d, execute no destino: 
ls -l /ifs/.ifsvar/modules/tsm/config/source_records/7da67596f099b75ad687a05f6b11781d*

  1. A nova política [POLICY]_mirror no cluster SECUNDÁRIO pode ser executada para iniciar a sincronização de volta para o cluster PRINCIPAL.

    # isi sync jobs start --policy-name=[POLICY]_mirror

  2. Interrompa todas as gravações no caminho da política SECUNDÁRIA.

    Nota: As gravações no caminho da política do cluster SECUNDÁRIO que ocorrerem a partir desta etapa não ficarão retidas, resultando em uma possível DL. Confirme se todas as gravações nesse caminho NO SECUNDÁRIO foram interrompidas.

  3. Desative todos os agendamentos definindo as políticas como manual.

    # isi sync policies modify  --policy=[POLICY]_mirror --schedule=""

  4. No cluster SECUNDÁRIO, execute um último trabalho de sincronização

    # isi sync jobs start --policy-name=[POLICY]_mirror

  5. No cluster PRINCIPAL, execute a ação "Allow Writes" e verifique se o trabalho local conclui essa ação.

    # isi sync recovery allow-write --policy-name=[POLICY]_mirror
# isi sync target list
Name             Source    Target Path              Last Job State  FOFB State
-----------------------------------------------------------------------------------
qtestsync_mirror secondary_clust      /ifs/data/siq_quota_test finished        writes_enabled
-----------------------------------------------------------------------------------
Total: 1
    Nota: Inverta as configurações do diretório SmartLock, conforme necessário, em ambos os clusters.
    https://infohub.delltechnologies.com/en-us/l/dell-powerscale-smartlock-best-practices/synciq/

  6. Redirecione os clients (SMB, NFS, HTTP, FTP etc.) para o cluster PRINCIPAL

    Nota: As especificidades dessa etapa estão fora do escopo deste artigo e exigem criação de compartilhamentos SMB, exportações NFS e redirecionamento de DNS do SmartConnect.

  7. Crie um snapshot de recuperação em ambos os clusters antes de prosseguir com o resync-prep

    NA ORIGEM

    # isi snapshot snapshots create --path=[SOURCE_PATH] --name=SIQ-recovery-policy-[POLICY_NAME] --expires=2W

    NO DESTINO

    # isi snapshot snapshots create --path=[TARGET_PATH] --name=SIQ-recovery-policy-[POLICY_NAME] --expires=2W

  8. No cluster SECUNDÁRIO, execute o trabalho de failback com prepare resync e confirme se o resync_prep_finalize foi bem-sucedido

    # isi sync recovery resync-prep --policy-name=[POLICY]_mirror

# isi sync reports list --policy-name=[POLICY]_mirror --sort job_id --reports-per-policy=5
Policy Name  Job ID  Start Time          End Time            Action                  State
---------------------------------------------------------------------------------------------
qtestsync_mirror    1       2015-02-12T08:31:27 2015-02-12T08:31:34 run                     finished
qtestsync_mirror    2       2015-02-12T08:41:19 2015-02-12T08:41:31 resync_prep             finished
qtestsync_mirror    3       2015-02-12T08:41:31 2015-02-12T08:41:34 resync_prep_domain_mark finished
qtestsync_mirror    4       2015-02-12T08:41:34 2015-02-12T08:41:42 resync_prep_restore     finished
qtestsync_mirror    5       2015-02-12T08:41:42 2015-02-12T08:41:45 resync_prep_finalize    finished

    O cluster SECUNDÁRIO agora é Somente leitura e a política [POLICY]_mirror do cluster SECUNDÁRIO está desativada.

    Nota: Não exclua nenhuma política de espelhamento.

  9. Agora, as políticas originais no cluster PRINCIPAL estão ativadas. Use o arquivo de backup da etapa 3 do Failover para restaurar seus agendamentos de política.

    No cluster PRINCIPAL:
    Visualize a cópia salva dos agendamentos de política:

    # cat /ifs/.ifsvar/modules/tsm/config/policy-schedules.txt

    Restaure os agendamentos de política:

    # isi sync policies modify  --policy=[POLICY] --schedule=[schedule]
  10. No secundário original, o snapshot SIQ-mirrorpolID-latest> será deixado após um failback bem-sucedido<. Limpe manualmente o snapshot SIQ-mirrorpolID-latest<> para evitar gravações COW em qualquer snapshot existente no secundário. 
    # isi snapshot snapshots list
ID   Name                                        Path
-----------------------------------------------------------------------
16   SIQ-recovery-policy-Test                    /ifs/data/failovertest
18   SIQ-005056ac0655f7f5e267a71dae70c997-latest /ifs/data/failovertest  <-- pol_mirror-latest
24   SIQ-ps9715x1-Test-2025-03-25_19-20-52       /ifs/data/failovertest
-----------------------------------------------------------------------
Total: 3

# isi snapshot snapshots delete --id=<id>

Additional Information

Este é um exemplo de etapas de teste que ignoram as alterações no cluster secundário após failover e failback. As mesmas etapas são seguidas, exceto que a política de espelhamento é executada apenas como Resync Prep, e não como um trabalho de sincronização regular do cluster secundário para o principal. Dessa forma, as alterações não são enviadas de volta ao cluster principal. Certifique-se de que cada etapa seja concluída antes de passar para a próxima.

FAILOVER:

  1. No cluster PRINCIPAL, considere executar o trabalho domainmark Trabalhe com dias ou semanas de antecedência, se essa for a primeira tentativa de failover do cluster. Se o conjunto de dados for grande, isso ajudará a economizar tempo acelerando a fase de trabalho domainmark .

    Nota: Isso só é benéfico para a primeira tentativa de failover. As tentativas subsequentes de failover não se beneficiam mais disso. 
    # isi job jobs start domainmark --root=<path> --dm-type=synciq

    Isso marcará antecipadamente cada LIN com o ID de domínio de proteção apropriado, em vez de fazer com que o trabalho de failover execute tudo (consulte a Etapa 7). O comando domainmark pode levar muito tempo, dependendo do tamanho do conjunto de dados.

  2. Interrompa todas as gravações no caminho da política PRIMÁRIA.

    Nota: As gravações no caminho da política do cluster PRINCIPAL que ocorrerem a partir desta etapa não ficarão retidas, resultando em uma possível DL. Confirme com o cliente se todas as gravações no caminho do cluster PRINCIPAL foram interrompidas.

  3. No cluster PRINCIPAL, faça backup dos agendamentos de política e, em seguida, desative todos os agendamentos configurando as políticas como manual.

    Para salvar uma cópia de backup dos agendamentos:

    # cat /ifs/.ifsvar/modules/tsm/config/siq-policies.gc|egrep 'common.name|schedule ' >> /ifs/.ifsvar/modules/tsm/config/policy-schedules.txt

    Em seguida, desative todos os agendamentos definindo as políticas como manual.

    Nota: Por padrão, um trabalho de sincronização e um de failover não podem ser executados simultaneamente, causando uma falha na tentativa de failover. Para evitar essa condição, defina todas as políticas como manual. 
    # isi sync policies modify  --policy=[POLICY] --schedule=""

  4. No no cluster PRINCIPAL, execute um último trabalho de sincronização e confirme se ele foi concluído com sucesso.

    Nota: Essa etapa só será recomendada se você estiver testando a funcionalidade FOFB. Não execute essa etapa se o cluster Principal já tiver identificado um evento de falha e o cluster Secundário já tiver sido configurado para permitir gravações. 
    # isi sync jobs start [POLICY]

    Execute este comando para confirmar a conclusão bem-sucedida:

    # isi sync reports list --reports-per-policy=1
*Confirm the End time and State=finished

    No cluster PRINCIPAL, execute um último trabalho de sincronização.

    # isi sync jobs start [POLICY]

  5. No cluster SECUNDÁRIO, execute a ação "Allow Writes" e verifique se o trabalho local conclui essa ação.

    # isi sync recovery allow-write --policy-name=[POLICY]
# isi sync target list
Name             Source    Target Path              Last Job State  FOFB State
-----------------------------------------------------------------------------------
qtestsync  primary_clust      /ifs/data/siq_quota_test finished        writes_enabled
-----------------------------------------------------------------------------------
Total: 1

  6. Redirecione os clients (SMB, NFS, HTTP, FTP etc.) para o cluster SECUNDÁRIO

    Nota: As especificidades dessa etapa estão fora do escopo deste artigo e exigem a criação de compartilhamentos SMB, ingresso no domínio do Active Directory, contas de máquina, SPN, exportações NFS, redirecionamento de DNS do SmartConnect e adição de provedores de autenticação.

  7. No cluster PRINCIPAL, execute o trabalho de failover com prepare re-sync e confirme se a fase resync_prep_finalize foi concluída.

    # isi sync recovery resync-prep --policy-name=[POLICY]
    # isi sync reports list --policy-name=qtestsync --sort job_id
Policy Name  Job ID  Start Time          End Time            Action                  State
---------------------------------------------------------------------------------------------
qtestsync    1       2015-02-11T08:31:27 2015-02-11T08:31:34 run                     finished
qtestsync    2       2015-02-11T08:41:19 2015-02-11T08:41:31 resync_prep             finished
qtestsync    3       2015-02-11T08:41:31 2015-02-11T08:41:34 resync_prep_domain_mark finished
qtestsync    4       2015-02-11T08:41:34 2015-02-11T08:41:42 resync_prep_restore     finished
qtestsync    5       2015-02-11T08:41:42 2015-02-11T08:41:45 resync_prep_finalize    finished
Nota: A origem agora é Somente leitura e a política do cluster PRINCIPAL está desabilitada. Esse trabalho também cria uma política de espelhamento anexada com nome "_mirror" no cluster SECUNDÁRIO que é usada para failback para o cluster PRINCIPAL.

FAILBACK

IGNORE AS ETAPAS 1 E 4 (REMOVIDAS ABAIXO) SE VOCÊ NÃO QUISER QUE AS ALTERAÇÕES SEJAM ENVIADAS DE VOLTA À PRIMÁRIA PARA O TESTE.

A nova política [POLICY]_mirror no cluster SECUNDÁRIO pode ser executada para iniciar a sincronização de volta para o cluster PRINCIPAL.

  1. Interrompa todas as gravações no caminho da política SECUNDÁRIA.

  2. Desative todos os agendamentos definindo as políticas como manual.

    # isi sync policies modify  --policy=[POLICY]_mirror --schedule=""

  3. No cluster PRINCIPAL, execute a ação "Allow Writes" e verifique se o trabalho local conclui essa ação.

    # isi sync recovery allow-write --policy-name=[POLICY]_mirror
# isi sync target list
Name             Source    Target Path              Last Job State  FOFB State
-----------------------------------------------------------------------------------
qtestsync_mirror secondary_clust      /ifs/data/siq_quota_test finished        writes_enabled
-----------------------------------------------------------------------------------
Total: 1

  4. Redirecione os clients (SMB, NFS, HTTP, FTP etc.) para o cluster PRINCIPAL

    Nota: As especificidades dessa etapa estão fora do escopo deste artigo da KB e exigem criação de compartilhamentos SMB, exportações NFS e redirecionamento de DNS do SmartConnect.

  5. No cluster SECUNDÁRIO, execute o trabalho de failback com prepare re-sync e confirme se o resync_prep_finalize foi bem-sucedido

    # isi sync recovery resync-prep --policy-name=[POLICY]_mirror

# isi sync reports list --policy-name=qtestsync_mirror --sort job_id
Policy Name  Job ID  Start Time          End Time            Action                  State
---------------------------------------------------------------------------------------------
qtestsync_mirror    1       2015-02-12T08:31:27 2015-02-12T08:31:34 run                     finished
qtestsync_mirror    2       2015-02-12T08:41:19 2015-02-12T08:41:31 resync_prep             finished
qtestsync_mirror    3       2015-02-12T08:41:31 2015-02-12T08:41:34 resync_prep_domain_mark finished
qtestsync_mirror    4       2015-02-12T08:41:34 2015-02-12T08:41:42 resync_prep_restore     finished
qtestsync_mirror    5       2015-02-12T08:41:42 2015-02-12T08:41:45 resync_prep_finalize    finished

    O cluster SECUNDÁRIO agora é Somente leitura e a política [POLICY]_mirror do cluster SECUNDÁRIO está desativada.

    Nota: Não exclua nenhuma política de espelhamento.

  6. Agora, as políticas originais no cluster PRINCIPAL estão ativadas. Use o arquivo de backup da etapa 3 do Failover para restaurar seus agendamentos de política. No cluster PRINCIPAL:

    Visualize a cópia salva dos agendamentos de política:

    # cat /ifs/.ifsvar/modules/tsm/config/policy-schedules.txt

    Restaure os agendamentos de política:

    # isi sync policies modify  --policy=[POLICY] --schedule=[schedule]

 

Affected Products

Isilon SyncIQ

Products

Isilon X-Series
Article Properties
Article Number: 000035266
Article Type: Solution
Last Modified: 20 Jan 2026
Version:  13
Find answers to your questions from other Dell users
Support Services
Check if your device is covered by Support Services.