Isilon: quali sono i passaggi della CLI per il failover e il failback di SyncIQ

Summary: Passaggi della CLI per eseguire il failover/failback (FOFB) di una policy.

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

Quali sono i passaggi della CLI per il failover e il failback di SyncIQ?
Il processo dell'interfaccia utente include una guida dettagliata, esiste una guida simile per la CLI?

 

Cause

Passaggi dettagliati per eseguire FOFB

 

Resolution

Guida CLI per failover e failback:

Sebbene la documentazione di cui sopra offra alcune informazioni utili, i passaggi riportati di seguito sono più dettagliati quando si esegue un failover e un failback utilizzando la CLI.

La procedura riportata di seguito utilizza la terminologia SyncIQ per questi due termini:

  • Cluster di ORIGINE = PRIMARIO
  • Cluster di DESTINAZIONE = SECONDARIO

FAILOVER:

  1. Nel cluster PRIMARIO, valutare l'esecuzione del processo domainmark Job con giorni o settimane di anticipo se si tratta del primo tentativo di failover per il cluster. Se il data set è di grandi dimensioni, può ridurre il tempo necessario per accelerare la fase del processo domainmark .

    Nota: Una nuova opzione "Accelerated Failback" rimuove questo passaggio. Questo passaggio deve essere eseguito SOLO una volta. Una volta segnato, futuro domainmark I job sono (vedere il passaggio 7 di seguito) una no-op. 
    # isi job jobs start domainmark --root=<path> --dm-type=synciq

    In questo modo, ogni LIN viene contrassegnato in anticipo con l'ID di dominio protettivo appropriato, senza che l'operazione debba essere eseguita dal processo di failover (vedere il passaggio 7). La colonna domainmark può richiedere molto tempo a seconda delle dimensioni del data set.

  2. Interrompere tutte le scritture nel percorso della policy PRIMARIA.

    Nota: le scritture nel percorso delle policy del cluster PRIMARIO da questo passaggio in poi non vengono conservate, con conseguente possibile perdita di dati (DL). Verificare che tutte le scritture su tale percorso SUL PRIMARIO siano state interrotte.

  3. Sul cluster PRIMARIO, eseguire il backup delle pianificazioni delle policy, quindi disabilitare tutte le pianificazioni impostando le policy come manuali.

    Per salvare una copia di backup delle pianificazioni:

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

    Quindi, disabilitare tutte le pianificazioni impostando le policy su manuale.

    Nota: un processo di sincronizzazione e un processo di failover non possono essere eseguiti contemporaneamente per impostazione predefinita e causano l'esito negativo del tentativo di failover. Per evitare questa condizione, impostare tutte le policy come manuali. 
    # isi sync policies modify  --policy=[POLICY] --schedule=""

  4. Sul cluster PRIMARIO, eseguire un ultimo processo di sincronizzazione e verificare che venga completato correttamente.

    Nota: Questo passaggio è consigliato solo in caso di test della funzionalità FOFB. NON eseguire questo passaggio se il cluster PRIMARIO ha già riscontrato un evento di errore e il cluster SECONDARIO è già stato impostato per consentire scritture. 
    # isi sync jobs start [POLICY]

    Eseguire questo comando per verificare il completamento dell'operazione:

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

    Sul cluster PRIMARIO, eseguire un ultimo processo di sincronizzazione.

    # isi sync jobs start [POLICY]

  5. Nel cluster SECONDARIO, eseguire l'azione "Consenti scritture" e verificare che il processo locale completi tale azione.

    # 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: Invertire le impostazioni della directory SmartLock in base alle esigenze su entrambi i cluster.
    https://infohub.delltechnologies.com/en-us/l/dell-powerscale-smartlock-best-practices/synciq/

  6. Reindirizzare i client (SMB, NFS, HTTP, FTP e così via) al cluster SECONDARIO.

    Nota: le specifiche di questo passaggio non rientrano nell'ambito di questo articolo e richiedono la creazione di condivisioni SMB, l'aggiunta a un dominio Active Directory, account di computer, SPN, esportazioni NFS, il reindirizzamento del DNS SmartConnect e l'aggiunta di provider di autenticazione.

  7. Creare una snapshot di ripristino su entrambi i cluster prima di procedere con il processo resync-prep

    SULL'ORIGINE

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

    SULLA DESTINAZIONE

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

  8. Nel cluster PRIMARY eseguire il processo di failover con prepare resync e verificare che la fase resync_prep_finalize sia stata completata.

    # 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: prima di eseguire questo passaggio, verificare nel cluster SECONDARIO l'esistenza di un file XML source_record per lo stesso ID di policy della policy originale. Ad esempio, per l'ID della policy di origine 7da67596f099b75ad687a05f6b11781d eseguire sulla destinazione: 
ls -l /ifs/.ifsvar/modules/tsm/config/source_records/7da67596f099b75ad687a05f6b11781d*

  1. È possibile eseguire la nuova policy [POLICY]_mirror sul cluster SECONDARIO per avviare nuovamente la sincronizzazione con il cluster PRIMARIO.

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

  2. Interrompere tutte le scritture nel percorso della policy SECONDARIA.

    Nota: le scritture nel percorso delle policy del cluster SECONDARIO da questo passaggio in poi non vengono conservate, con conseguente possibile perdita di dati (DL). Verificare che tutte le scritture su tale percorso SUL SECONDARIO siano state interrotte.

  3. Disabilitare tutte le pianificazioni impostando le policy come manuali.

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

  4. Sul cluster SECONDARIO eseguire un ultimo processo di sincronizzazione

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

  5. Nel cluster PRIMARIO, eseguire l'azione "Consenti scritture" e verificare che il processo locale completi tale azione.

    # 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: Invertire le impostazioni della directory SmartLock in base alle esigenze su entrambi i cluster.
    https://infohub.delltechnologies.com/en-us/l/dell-powerscale-smartlock-best-practices/synciq/

  6. Reindirizzare i client (SMB, NFS, HTTP, FTP e così via) al cluster PRIMARIO.

    Nota: le specifiche di questo passaggio non rientrano nell'ambito di questo articolo e richiedono la creazione di condivisioni SMB, esportazioni NFS e il reindirizzamento del DNS SmartConnect.

  7. Creare una snapshot di ripristino su entrambi i cluster prima di procedere con il processo resync-prep

    SULL'ORIGINE

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

    SULLA DESTINAZIONE

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

  8. Nel cluster SECONDARY eseguire il processo di failback con prepare resync e verificare che il resync_prep_finalize sia riuscito

    # 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

    Il cluster SECONDARIO è ora READ-ONLY e la policy [POLICY]_mirror del cluster SECONDARIO è disabilitata.

    Nota: non eliminare alcuna policy di mirroring.

  9. Le policy originali sul cluster PRIMARIO sono ora abilitate. Utilizzare il file di backup del passaggio 3 di FAILOVER per ripristinare le pianificazioni delle policy.

    Sul cluster PRIMARIO:
    Visualizzare la copia salvata delle pianificazioni delle policy:

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

    Ripristinare le pianificazioni delle policy:

    # isi sync policies modify  --policy=[POLICY] --schedule=[schedule]
  10. Nel secondario originale, l'istantanea SIQ-mirrorpolID<> più recente verrà lasciata dopo un failback riuscito. Pulire manualmente la snapshot SIQ-mirrorpolID-latest<> per evitare scritture COW in qualsiasi snapshot esistente nel secondario. 
    # 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

Di seguito è riportato un esempio di passaggi di test che ignorano le modifiche apportate al cluster secondario dopo il failover e il failback. Viene eseguita la stessa procedura, eccetto per il fatto che la policy di mirroring viene eseguita solo come processo di PREPARAZIONE DELLA RISINCRONIZZAZIONE E NON COME PROCESSO DI SINCRONIZZAZIONE REGOLARE dal database secondario a quello primario, in modo che le modifiche non vengano inviate nuovamente al cluster primario. Assicurarsi che ogni passaggio sia completato prima di procedere al successivo.

FAILOVER:

  1. Nel cluster PRIMARIO, valutare l'esecuzione del processo domainmark Job con giorni o settimane di anticipo se si tratta del primo tentativo di failover per il cluster. Se il data set è di grandi dimensioni, può ridurre il tempo necessario per accelerare la fase del processo domainmark .

    Nota: ciò è vantaggioso solo per il primo tentativo di failover in assoluto. I tentativi di failover successivi non ne traggono più vantaggio. 
    # isi job jobs start domainmark --root=<path> --dm-type=synciq

    In questo modo, ogni LIN viene contrassegnato in anticipo con l'ID di dominio protettivo appropriato, senza che l'operazione debba essere eseguita dal processo di failover (vedere il passaggio 7). Il comando domainmark può richiedere molto tempo a seconda delle dimensioni del data set.

  2. Interrompere tutte le scritture nel percorso della policy PRIMARIA.

    Nota: le scritture nel percorso delle policy del cluster PRIMARIO da questo passaggio in poi non vengono conservate, con conseguente possibile perdita di dati (DL). Verificare con il cliente che tutte le scritture su tale percorso del cluster SECONDARIO si siano arrestate.

  3. Sul cluster PRIMARIO, eseguire il backup delle pianificazioni delle policy, quindi disabilitare tutte le pianificazioni impostando le policy come manuali.

    Per salvare una copia di backup delle pianificazioni:

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

    Quindi, disabilitare tutte le pianificazioni impostando le policy su manuale.

    Nota: un processo di sincronizzazione e un processo di failover non possono essere eseguiti contemporaneamente per impostazione predefinita e causano l'esito negativo del tentativo di failover. Per evitare questa condizione, impostare tutte le policy come manuali. 
    # isi sync policies modify  --policy=[POLICY] --schedule=""

  4. Sul cluster PRIMARIO, eseguire un ultimo processo di sincronizzazione e verificare che venga completato correttamente.

    Nota: questo passaggio è consigliato solo se si sta testando la funzionalità FOFB. NON eseguire questo passaggio se il cluster PRIMARIO ha già riscontrato un evento di errore e il cluster SECONDARIO è già stato impostato per consentire scritture. 
    # isi sync jobs start [POLICY]

    Eseguire questo comando per verificare il completamento dell'operazione:

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

    Sul cluster PRIMARIO, eseguire un ultimo processo di sincronizzazione.

    # isi sync jobs start [POLICY]

  5. Nel cluster SECONDARIO, eseguire l'azione "Consenti scritture" e verificare che il processo locale completi tale azione.

    # 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. Reindirizzare i client (SMB, NFS, HTTP, FTP e così via) al cluster SECONDARIO.

    Nota: le specifiche di questo passaggio non rientrano nell'ambito di questo articolo e richiedono la creazione di condivisioni SMB, l'aggiunta a un dominio Active Directory, account di computer, SPN, esportazioni NFS, il reindirizzamento del DNS SmartConnect e l'aggiunta di provider di autenticazione.

  7. Sul cluster PRIMARIO eseguire il processo di failover con resync-prep e verificare che la fase resync_prep_finalize sia stata completata.

    # 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: L'origine è ora READ-ONLY e la policy PRIMARIA è disabilitata. Questo processo crea inoltre una policy di mirroring a cui è stato aggiunto il nome "_mirror" nel cluster SECONDARIO utilizzato per eseguire il failback nel cluster PRIMARIO.

FAILBACK

IGNORARE I PASSAGGI 1 E 4 (RIMOSSI DI SEGUITO) SE NON SI DESIDERA CHE LE MODIFICHE VENGANO RINVIATE AL DATABASE PRINCIPALE PER IL TEST.

È possibile eseguire la nuova policy [POLICY]_mirror sul cluster SECONDARIO per avviare nuovamente la sincronizzazione con il cluster PRIMARIO.

  1. Interrompere tutte le scritture nel percorso della policy SECONDARIA.

  2. Disabilitare tutte le pianificazioni impostando le policy come manuali.

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

  3. Nel cluster PRIMARIO, eseguire l'azione "Consenti scritture" e verificare che il processo locale completi tale azione.

    # 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. Reindirizzare i client (SMB, NFS, HTTP, FTP e così via) al cluster PRIMARIO.

    Nota: le specifiche di questo passaggio non rientrano nell'ambito di questo articolo della Knowledge Base e richiedono la creazione di condivisioni SMB, esportazioni NFS e il reindirizzamento del DNS SmartConnect.

  5. Sul cluster SECONDARIO eseguire il processo di failback con resync-prep e verificare che la fase resync_prep_finalize sia stata completata

    # 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

    Il cluster SECONDARIO è ora READ-ONLY e la policy [POLICY]_mirror del cluster SECONDARIO è disabilitata.

    Nota: non eliminare alcuna policy di mirroring.

  6. Le policy originali sul cluster PRIMARIO sono ora abilitate. Utilizzare il file di backup del passaggio 3 di FAILOVER per ripristinare le pianificazioni delle policy. Sul cluster PRIMARIO:

    Visualizzare la copia salvata delle pianificazioni delle policy:

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

    Ripristinare le pianificazioni delle policy:

    # 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: 10 Sept 2025
Version:  12
Find answers to your questions from other Dell users
Support Services
Check if your device is covered by Support Services.