Isilon : quelles sont les étapes de la CLI pour le basculement et la restauration automatique SyncIQ ?

Summary: Étapes de la CLI pour effectuer le basculement/la restauration automatique d’une règle.

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

Quelles sont les étapes de la CLI pour le basculement et la restauration automatique SyncIQ ?
Le processus de l’interface utilisateur comporte un guide pas à pas ; existe-t-il un guide similaire pour la CLI ?

 

Cause

Procédure détaillée des tâches de basculement et de restauration automatique

 

Resolution

Guide de la CLI pour le basculement et la restauration automatique :

Bien que la documentation ci-dessus offre de bonnes informations, les étapes ci-dessous sont plus détaillées lors de l’exécution d’un basculement et d’une restauration automatique à l’aide de la CLI.

Les étapes ci-dessous utilisent la terminologie SyncIQ pour ces deux termes :

  • Cluster SOURCE = PRINCIPAL
  • Cluster CIBLE = SECONDAIRE

BASCULEMENT :

  1. Au niveau du CLUSTER PRINCIPAL, envisagez d’exécuter la tâche domainmark Tâche jours ou semaines à l’avance s’il s’agit de la première tentative de basculement pour le cluster. Si le jeu de données est volumineux, cela permet de gagner du temps en accélérant la domainmark phase de la tâche.

    Remarque : Une nouvelle option appelée « Accelerated Failback » permet de supprimer cette étape. Cette étape ne doit être effectuée qu’une seule fois. Une fois marqué, futur domainmark Les tâches sont (voir l’étape 7 ci-dessous) no-op. 
    # isi job jobs start domainmark --root=<path> --dm-type=synciq

    Avant le début du processus de basculement, LIN doit être marqué avec l’ID de domaine de protection approprié. Cela permet d’éviter les erreurs potentielles qui pourraient survenir lors de la tâche de basculement elle-même (voir étape 7). La commande domainmark tâche peut prendre beaucoup de temps en fonction de la taille du jeu de données.

  2. Arrêtez toute écriture sur le chemin de la règle PRIMAIRE.

    Remarque : les écritures effectuées sur le chemin des règles du cluster PRINCIPAL après cette étape ne sont pas conservées, ce qui peut éventuellement entraîner une perte de données. Vérifiez que toutes les écritures sur ce chemin sur le serveur principal ont cessé.

  3. Sur le cluster PRINCIPAL, sauvegardez les planifications de règles, puis désactivez toutes les planifications en définissant les règles sur le mode manuel.

    Pour enregistrer une copie de sauvegarde des planifications :

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

    Désactivez ensuite toutes les planifications en définissant les règles sur le mode manuel.

    Remarque : par leur conception, il n’est pas possible d’exécuter simultanément une tâche de synchronisation et une tâche de basculement. Toute exécution simultanée entraînerait un échec de la tentative de basculement. Pour éviter ce problème, définissez toutes les règles sur manuel. 
    # isi sync policies modify  --policy=[POLICY] --schedule=""

  4. Au niveau du cluster PRINCIPAL, exécutez une dernière tâche de synchronisation et vérifiez qu’elle s’est terminée correctement.

    Remarque : Cette étape est uniquement recommandée en cas de test de la fonctionnalité FOFB. N’EFFECTUEZ PAS cette étape si le cluster PRINCIPAL a déjà rencontré un événement de défaillance et que le cluster SECONDAIRE a déjà été configuré pour autoriser les écritures. 
    # isi sync jobs start [POLICY]

    Exécutez cette commande pour confirmer la réussite de l’exécution :

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

    Au niveau du cluster PRINCIPAL, exécutez une dernière tâche de synchronisation.

    # isi sync jobs start [POLICY]

  5. Sur le cluster SECONDAIRE, exécutez l’action « Autoriser les écritures » et vérifiez que la tâche locale termine cette action.

    # 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
    Remarque : Modifiez les paramètres du répertoire SmartLock selon les besoins sur les deux clusters.
    https://infohub.delltechnologies.com/en-us/l/dell-powerscale-smartlock-best-practices/synciq/

  6. Redirigez les clients (SMB, NFS, HTTP, FTP, etc.) vers le cluster SECONDAIRE.

    Remarque : les détails de cette étape n’entrent pas dans le périmètre de cet article de la base de connaissances et impliquent la création de partages SMB, une jonction de domaines Active Directory, des comptes/SPN d’ordinateurs, des exportations NFS, une redirection du DNS SmartConnect et l’ajout de fournisseurs d’authentification.

  7. Créez un snapshot de récupération sur les deux clusters avant de passer à la préparation de la resynchronisation.

    SUR LA SOURCE

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

    SUR LA CIBLE

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

  8. Sur le cluster PRINCIPAL, exécutez la tâche de basculement avec préparation de la resynchronisation et vérifiez que la phase de resync_prep_finalize est terminée.

    # 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

RESTAURATION AUTOMATIQUE

Remarque importante : avant d’exécuter cette étape, vérifiez sur le cluster SECONDAIRE s’il existe un fichier XML source_record avec le même ID de règle que dans la règle d’origine. Par exemple, pour l’ID de règle source 7da67596f099b75ad687a05f6b11781d, exécutez la commande suivante sur la cible : 
ls -l /ifs/.ifsvar/modules/tsm/config/source_records/7da67596f099b75ad687a05f6b11781d*

  1. La nouvelle règle [POLICY]_mirror sur le cluster SECONDAIRE peut être exécutée pour démarrer la synchronisation avec le cluster PRINCIPAL.

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

  2. Arrêtez toute écriture sur le chemin de la règle SECONDAIRE.

    Remarque : les écritures effectuées sur le chemin des règles du cluster SECONDAIRE après cette étape ne sont pas conservées, ce qui peut éventuellement entraîner une perte de données. Vérifiez que toutes les écritures sur ce chemin sur le serveur secondaire ont cessé.

  3. Désactivez toutes les planifications en définissant les règles sur le mode manuel.

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

  4. Au niveau du cluster SECONDAIER, exécutez une dernière tâche de synchronisation.

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

  5. Sur le cluster PRINCIPAL, exécutez l’action « Autoriser les écritures » et vérifiez que la tâche locale termine cette action.

    # 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
    Remarque : Modifiez les paramètres du répertoire SmartLock selon les besoins sur les deux clusters.
    https://infohub.delltechnologies.com/en-us/l/dell-powerscale-smartlock-best-practices/synciq/

  6. Redirigez les clients (SMB, NFS, HTTP, FTP, etc.) vers le cluster PRINCIPAL.

    Remarque : les détails de cette étape n’entrent pas dans le périmètre de cet article et impliquent la création de partages SMB, des exportations NFS et une redirection du DNS SmartConnect.

  7. Créez un snapshot de récupération sur les deux clusters avant de passer à la préparation de la resynchronisation.

    SUR LA SOURCE

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

    SUR LA CIBLE

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

  8. Sur le cluster SECONDAIRE, effectuez la tâche de restauration automatique avec préparation de la resynchronisation et vérifiez que le resync_prep_finalize a réussi

    # 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

    Le cluster SECONDAIRE est maintenant en LECTURE SEULE et la règle [POLICY]_mirror du cluster SECONDAIRE est désactivée.

    Remarque : ne supprimez aucune règle de mise en miroir.

  9. Les règles d’origine sur le serveur PRINCIPAL sont désormais activées. Utilisez le fichier de sauvegarde de l’étape 3 de BASCULEMENT pour restaurer vos planifications de règles.

    Sur le serveur PRINCIPAL :
    Affichez la copie enregistrée des planifications de la règle :

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

    Restaurez les planifications de la règle :

    # isi sync policies modify  --policy=[POLICY] --schedule=[schedule]
  10. Sur le serveur secondaire d’origine, le dernier snapshot SIQ-mirrorpolID<> est laissé de côté après une restauration automatique réussie. Nettoyez manuellement le dernier snapshot SIQ-mirrorpolID<> pour éviter les écritures COW sur les snapshots existants sur Secondary. 
    # 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

L’exemple ci-dessous décrit des étapes de test qui ignorent les modifications sur le cluster secondaire après le basculement et la restauration automatique. Les mêmes étapes sont reproduites, sauf que la règle de mise en miroir est exécutée uniquement sous forme de TÂCHE DE PRÉPARATION À LA RESYNCHRONISATION ET NON DE TÂCHE DE SYNCHRONISATION RÉGULIÈRE entre le cluster secondaire et le cluster principal, de sorte que les modifications ne sont pas renvoyées au cluster principal. Assurez-vous que chaque étape est terminée avant de passer à l’étape suivante.

BASCULEMENT :

  1. Au niveau du CLUSTER PRINCIPAL, envisagez d’exécuter la tâche domainmark Tâche jours ou semaines à l’avance s’il s’agit de la première tentative de basculement pour le cluster. Si le jeu de données est volumineux, cela permet de gagner du temps en accélérant la domainmark phase de la tâche.

    Remarque : cela n’a d’intérêt que pour la toute première tentative de basculement. Les tentatives de basculement ultérieures n’en bénéficient plus. 
    # isi job jobs start domainmark --root=<path> --dm-type=synciq

    Avant le début du processus de basculement, LIN doit être marqué avec l’ID de domaine de protection approprié. Cela permet d’éviter les erreurs potentielles qui pourraient survenir lors de la tâche de basculement elle-même (voir étape 7). la commande domainmark tâche peut prendre beaucoup de temps en fonction de la taille du jeu de données.

  2. Arrêtez toute écriture sur le chemin de la règle PRIMAIRE.

    Remarque : les écritures effectuées sur le chemin des règles du cluster PRINCIPAL après cette étape ne sont pas conservées, ce qui peut éventuellement entraîner une perte de données. Vérifiez auprès du client qu’il n’y a plus aucune écriture sur ce chemin du cluster PRINCIPAL.

  3. Sur le cluster PRINCIPAL, sauvegardez les planifications de règles, puis désactivez toutes les planifications en définissant les règles sur le mode manuel.

    Pour enregistrer une copie de sauvegarde des planifications :

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

    Désactivez ensuite toutes les planifications en définissant les règles sur le mode manuel.

    Remarque : par leur conception, il n’est pas possible d’exécuter simultanément une tâche de synchronisation et une tâche de basculement. Toute exécution simultanée entraînerait un échec de la tentative de basculement. Pour éviter ce problème, définissez toutes les règles sur manuel. 
    # isi sync policies modify  --policy=[POLICY] --schedule=""

  4. Au niveau du cluster PRINCIPAL, exécutez une dernière tâche de synchronisation et vérifiez qu’elle s’est terminée correctement.

    Remarque : cette étape n’est recommandée que si vous testez la fonctionnalité de basculement/restauration automatique. N’EFFECTUEZ PAS cette étape si le cluster PRINCIPAL a déjà rencontré un événement de défaillance et que le cluster SECONDAIRE a déjà été configuré pour autoriser les écritures. 
    # isi sync jobs start [POLICY]

    Exécutez cette commande pour confirmer la réussite de l’exécution :

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

    Au niveau du cluster PRINCIPAL, exécutez une dernière tâche de synchronisation.

    # isi sync jobs start [POLICY]

  5. Sur le cluster SECONDAIRE, exécutez l’action « Autoriser les écritures » et vérifiez que la tâche locale termine cette action.

    # 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. Redirigez les clients (SMB, NFS, HTTP, FTP, etc.) vers le cluster SECONDAIRE.

    Remarque : les détails de cette étape n’entrent pas dans le périmètre de cet article de la base de connaissances et impliquent la création de partages SMB, une jonction de domaines Active Directory, des comptes/SPN d’ordinateurs, des exportations NFS, une redirection du DNS SmartConnect et l’ajout de fournisseurs d’authentification.

  7. Au niveau du cluster PRINCIPAL, effectuez la tâche de basculement avec la commande « prepare re-sync » et vérifiez que la tâche « resync_prep_finalize » a bien été exécutée

    # 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
Remarque : la source est maintenant EN LECTURE SEULE et la règle PRINCIPALE est désactivée. Cette tâche permet également de créer une règle de mise en miroir à laquelle est ajouté le nom « _mirror » sur le cluster SECONDAIRE utilisé pour effectuer une restauration automatique sur le cluster PRINCIPAL.

RESTAURATION AUTOMATIQUE

IGNOREZ LES ÉTAPES 1 ET 4 (SUPPRIMÉES CI-DESSOUS) SI VOUS NE SOUHAITEZ PAS QUE LES MODIFICATIONS SOIENT RENVOYÉES À L’ÉQUIPE PRINCIPALE POUR LE TEST.

La nouvelle règle [POLICY]_mirror sur le cluster SECONDAIRE peut être exécutée pour démarrer la synchronisation avec le cluster PRINCIPAL.

  1. Arrêtez toute écriture sur le chemin de la règle SECONDAIRE.

  2. Désactivez toutes les planifications en définissant les règles sur le mode manuel.

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

  3. Sur le cluster PRINCIPAL, exécutez l’action « Autoriser les écritures » et vérifiez que la tâche locale termine cette action.

    # 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. Redirigez les clients (SMB, NFS, HTTP, FTP, etc.) vers le cluster PRINCIPAL.

    Remarque : les détails de cette étape n’entrent pas dans le périmètre de cet article de la base de connaissances et impliquent la création de partages SMB, des exportations NFS et une redirection du DNS SmartConnect.

  5. Au niveau du cluster SECONDAIRE, effectuez la tâche de restauration automatique avec la commande « prepare re-sync » et vérifiez que la tâche « resync_prep_finalize » a bien abouti.

    # 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

    Le cluster SECONDAIRE est maintenant en LECTURE SEULE et la règle [POLICY]_mirror du cluster SECONDAIRE est désactivée.

    Remarque : ne supprimez aucune règle de mise en miroir.

  6. Les règles d’origine sur le serveur PRINCIPAL sont désormais activées. Utilisez le fichier de sauvegarde de l’étape 3 de BASCULEMENT pour restaurer vos planifications de règles. Sur le serveur PRINCIPAL :

    Affichez la copie enregistrée des planifications de la règle :

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

    Restaurez les planifications de la règle :

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