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

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?

Passaggi dettagliati per eseguire FOFB

Guida CLI per failover e failback:

• Guida
  all'amministrazione di PowerScale OneFS 9.5.0.0 CLI Pagina 271 per 9.5
• Guida
  all'amministrazione di PowerScale OneFS 9.7.0.0 CLI Pagina 288 per 9.7
• Guida
  all'amministrazione di PowerScale OneFS 9.8.0.0 CLI Pagina 295 per 9.8
• Guida
  all'amministrazione della CLI PowerScale OneFS 9.9.0.0 Pagina 296 per 9.9
• Guida
  all'amministrazione di PowerScale OneFS 9.10.0.0 CLI Pagina 299 per 9.10

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

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>

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

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]