Isilon: Was sind die CLI-Schritte für SyncIQ Failover und Failback?

Was sind die CLI-Schritte für SyncIQ Failover und Failback?
Der UI-Prozess enthält eine Schritt-für-Schritt-Anleitung, ich hatte gehofft, dass es eine ähnliche Anleitung für die CLI gibt.

Detaillierte Schritte zur Durchführung von FOFB

CLI-Leitfaden für Failover und Failback:

• PowerScale OneFS 9.5.0.0 CLI-Administrationshandbuch
  Seite 271 für 9.5
• PowerScale OneFS 9.7.0.0 CLI-Administrationshandbuch
  Seite 288 für 9.7
• PowerScale OneFS 9.8.0.0 CLI-Administrationshandbuch
  Seite 295 für 9.8
• PowerScale OneFS 9.9.0.0 CLI-Administrationshandbuch
  Seite 296 für 9.9
• PowerScale OneFS 9.10.0.0 CLI-Administrationshandbuch
  Seite 299 für 9.10

Während die obige Dokumentation einige gute Informationen bietet, sind die folgenden Schritte bei der Durchführung eines Failovers und Failbacks mithilfe der CLI detaillierter.

In den folgenden Schritten wird SyncIQ-Terminologie für diese beiden Begriffe verwendet:

• QUELLCLUSTER = PRIMÄR
• ZIELCLUSTER = SEKUNDÄR

FAILOVER:

1. Erwägen Sie auf dem PRIMÄREN Cluster das Ausführen von domainmark Führen Sie einen Job Tage oder Wochen im Voraus aus, wenn dies der erste Failover-Versuch für das Cluster ist. Wenn das Datenvolumen groß ist, können Sie Zeit sparen, indem Sie die domainmark Jobphase beschleunigen.

   Hinweis: Mit der neuen Option „Beschleunigtes Failback“ wird dieser Schritt entfernt. Dieser Schritt darf NUR einmal durchgeführt werden. Einmal markiert, Zukunft domainmark Jobs sind (siehe Schritt 7 unten) ein No-Op.

   # isi job jobs start domainmark --root=<path> --dm-type=synciq

   Dadurch wird jede LIN im Voraus mit der entsprechenden Schutzdomain-ID versehen, anstatt dass der Failover-Job alles ausführt (siehe Schritt 7). Bei der domainmark Job kann je nach Größe des Datensatzes viel Zeit in Anspruch nehmen.

2. Beenden Sie alle Schreibvorgänge in den Pfad der primären Policy.

   Hinweis: Schreibvorgänge in den Policy-Pfad des PRIMÄREN Clusters werden ab diesem Schritt nicht beibehalten, was zu möglichem Datenverlust führt. Vergewissern Sie sich, dass alle Schreibvorgänge auf diesen Pfad AUF DEM PRIMÄREN beendet wurden.

3. Sichern Sie auf dem PRIMÄREN Cluster die Policy-Zeitpläne und deaktivieren Sie dann alle Zeitpläne, indem Sie die Policies auf manuell setzen.

   So speichern Sie eine Sicherungskopie der Zeitpläne:

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

   Deaktivieren Sie dann alle Zeitpläne, indem Sie die Richtlinien auf manuell setzen.

   Hinweis: Ein Synchronisierungsjob und ein Failover-Job können standardmäßig nicht gleichzeitig ausgeführt werden und führen dazu, dass der Failover-Versuch fehlschlägt. Um diese Bedingung zu vermeiden, setzen Sie alle Policies auf manuell.

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

4. Führen Sie auf dem PRIMÄREN Cluster einen letzten Synchronisierungsjob aus und vergewissern Sie sich, dass er erfolgreich abgeschlossen wurde.

   Hinweis: Dieser Schritt wird nur empfohlen, wenn Sie die FOFB-Funktionalität testen. Führen Sie diesen Schritt NICHT aus, wenn auf dem PRIMÄREN Cluster bereits ein Fehlerereignis aufgetreten ist und der SEKUNDÄRE Cluster bereits so eingestellt wurde, dass Schreibvorgänge zugelassen werden.

   # isi sync jobs start [POLICY]

   Führen Sie diesen Befehl aus, um den erfolgreichen Abschluss zu bestätigen:

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

   Führen Sie auf dem PRIMÄREN Cluster einen letzten Synchronisierungsjob aus.

   # isi sync jobs start [POLICY]

5. Führen Sie auf dem SEKUNDÄREN Cluster die Aktion "Schreibvorgänge zulassen" aus und überprüfen Sie, ob der lokale Job diese Aktion abschließt.

   # 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

   HINWEIS: Kehren Sie die SmartLock-Verzeichniseinstellungen nach Bedarf auf beiden Clustern um.
   https://infohub.delltechnologies.com/en-us/l/dell-powerscale-smartlock-best-practices/synciq/

6. Leiten Sie Clients (SMB, NFS, HTTP, FTP usw.) zum SEKUNDÄREN Cluster um.

   Hinweis: Die Einzelheiten dieses Schritts gehen über den Rahmen dieses Artikels hinaus und erfordern das Erstellen von SMB-Freigaben, den Beitritt zur Active Directory-Domain, Maschinenkonten/SPN, NFS-Exporte, die Umleitung von SmartConnect DNS und das Hinzufügen von Authentifizierungsanbietern.

7. Erstellen Sie einen Recovery-Snapshot auf beiden Clustern, bevor Sie mit der Vorbereitung der Neusynchronisierung fortfahren

   AUF DER QUELLE

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

   AUF DEM ZIEL

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

8. Führen Sie auf dem PRIMÄREN Cluster den Failover-Job mit Vorbereitung und Neusynchronisierung aus und bestätigen Sie, dass die resync_prep_finalize Phase abgeschlossen ist.

   # 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. Die neue Policy [POLICY]_mirror auf dem SEKUNDÄREN Cluster kann ausgeführt werden, um die Synchronisierung mit dem PRIMÄREN Cluster zu starten.

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

2. Beenden Sie alle Schreibvorgänge in den Pfad der SEKUNDÄREN Policy.

   Hinweis: Schreibvorgänge in den Policy-Pfad des SEKUNDÄREN Clusters werden ab diesem Schritt nicht beibehalten, was zu möglichem Datenverlust führt. Vergewissern Sie sich, dass alle Schreibvorgänge auf diesen Pfad AUF DEM SEKUNDÄREN beendet wurden.

3. Deaktivieren Sie alle Zeitpläne, indem Sie die Richtlinien auf manuell setzen.

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

4. Führen Sie auf dem SEKUNDÄREN Cluster einen letzten Synchronisierungsjob aus.

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

5. Führen Sie auf dem PRIMÄREN Cluster die Aktion "Schreibvorgänge zulassen" aus und überprüfen Sie, ob der lokale Job diese Aktion abschließt.

   # 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

   HINWEIS: Kehren Sie die SmartLock-Verzeichniseinstellungen nach Bedarf auf beiden Clustern um.
   https://infohub.delltechnologies.com/en-us/l/dell-powerscale-smartlock-best-practices/synciq/

6. Leiten Sie Clients (SMB, NFS, HTTP, FTP usw.) zum PRIMÄREN Cluster um.

   Hinweis: Die Einzelheiten dieses Schritts gehen über den Rahmen dieses Artikels hinaus und erfordern die Erstellung von SMB-Freigaben, NFS-Exporten und die Umleitung von SmartConnect DNS.

7. Erstellen Sie einen Recovery-Snapshot auf beiden Clustern, bevor Sie mit der Vorbereitung der Neusynchronisierung fortfahren

   AUF DER QUELLE

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

   AUF DEM ZIEL

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

8. Führen Sie auf dem SEKUNDÄREN Cluster den Failback-Job mit Vorbereitung und Neusynchronisierung durch und bestätigen Sie, dass die resync_prep_finalize erfolgreich war

   # 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

   Der SEKUNDÄRE Cluster ist jetzt SCHREIBGESCHÜTZT und die Policy [POLICY]_mirror des SEKUNDÄREN Clusters ist deaktiviert.

   Hinweis: Löschen Sie keine Spiegelungs-Policies.

9. Die ursprünglichen Policies auf dem PRIMÄREN Cluster sind jetzt aktiviert. Verwenden Sie die Backupdatei von FAILOVER-Schritt 3, um Ihre Policy-Zeitpläne wiederherzustellen.

   Auf dem PRIMÄREN Cluster:
   Zeigen Sie die gespeicherte Kopie der Policy-Zeitpläne an:

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

   Stellen Sie die Policy-Zeitpläne wieder her:

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

10. Auf dem ursprünglichen sekundären Snapshot bleibt der SIQ-mirrorpolID-latest<> Snapshot nach einem erfolgreichen Failback übrig. Bereinigen Sie den Snapshot "SIQ-mirrorpolID-lateste>" manuell, um COW-Schreibvorgänge< auf vorhandenen Snapshots auf dem sekundären Snapshot zu vermeiden.

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

Hier ist ein Beispiel für Testschritte, die Änderungen auf dem sekundären Cluster nach Failover und Failback ignorieren. Es werden dieselben Schritte durchgeführt, mit dem Unterschied, dass die Spiegelungs-Richtlinie nur als VORBEREITUNG FÜR DIE NEUSYNCHRONISIERUNG UND NICHT ALS REGULÄRER SYNCHRONISIERUNGS-JOB vom sekundären zum primären Cluster ausgeführt wird, sodass Änderungen nicht an den primären Cluster zurückgesendet werden. Stellen Sie sicher, dass jeder Schritt abgeschlossen ist, bevor Sie mit dem nächsten Schritt fortfahren.

FAILOVER:

1. Erwägen Sie auf dem PRIMÄREN Cluster das Ausführen von domainmark Führen Sie einen Job Tage oder Wochen im Voraus aus, wenn dies der erste Failover-Versuch für das Cluster ist. Wenn das Datenvolumen groß ist, können Sie Zeit sparen, indem Sie die domainmark Jobphase beschleunigen.

   Hinweis: Dies ist nur beim ersten Failover-Versuch von Vorteil. Nachfolgende Failover-Versuche profitieren nicht mehr davon.

   # isi job jobs start domainmark --root=<path> --dm-type=synciq

   Dadurch wird jede LIN im Voraus mit der entsprechenden Schutzdomain-ID versehen, anstatt dass der Failover-Job alles ausführt (siehe Schritt 7). Der Befehl domainmark Job kann je nach Größe des Datensatzes viel Zeit in Anspruch nehmen.

2. Beenden Sie alle Schreibvorgänge in den Pfad der primären Policy.

   Hinweis: Schreibvorgänge in den Policy-Pfad des PRIMÄREN Clusters werden ab diesem Schritt nicht beibehalten, was zu möglichem Datenverlust führt. Verifizieren Sie mit dem Kunden, dass alle Schreibvorgänge zu diesem Pfad AUF DEM PRIMÄREN Cluster gestoppt wurden.

3. Sichern Sie auf dem PRIMÄREN Cluster die Policy-Zeitpläne und deaktivieren Sie dann alle Zeitpläne, indem Sie die Policies auf manuell setzen.

   So speichern Sie eine Sicherungskopie der Zeitpläne:

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

   Deaktivieren Sie dann alle Zeitpläne, indem Sie die Richtlinien auf manuell setzen.

   Hinweis: Ein Synchronisierungsjob und ein Failover-Job können standardmäßig nicht gleichzeitig ausgeführt werden und führen dazu, dass der Failover-Versuch fehlschlägt. Um diese Bedingung zu vermeiden, setzen Sie alle Policies auf manuell.

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

4. Führen Sie auf dem PRIMÄREN Cluster einen letzten Synchronisierungsjob aus und vergewissern Sie sich, dass er erfolgreich abgeschlossen wurde.

   Hinweis: Dieser Schritt wird nur empfohlen, wenn Sie die FOFB-Funktion testen. Führen Sie diesen Schritt NICHT aus, wenn auf dem PRIMÄREN Cluster bereits ein Fehlerereignis aufgetreten ist und der SEKUNDÄRE Cluster bereits so eingestellt wurde, dass Schreibvorgänge zugelassen werden.

   # isi sync jobs start [POLICY]

   Führen Sie diesen Befehl aus, um den erfolgreichen Abschluss zu bestätigen:

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

   Führen Sie auf dem PRIMÄREN Cluster einen letzten Synchronisierungsjob aus.

   # isi sync jobs start [POLICY]

5. Führen Sie auf dem SEKUNDÄREN Cluster die Aktion "Schreibvorgänge zulassen" aus und überprüfen Sie, ob der lokale Job diese Aktion abschließt.

   # 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. Leiten Sie Clients (SMB, NFS, HTTP, FTP usw.) zum SEKUNDÄREN Cluster um.

   Hinweis: Die Einzelheiten dieses Schritts gehen über den Rahmen dieses Artikels hinaus und erfordern das Erstellen von SMB-Freigaben, den Beitritt zur Active Directory-Domain, Maschinenkonten/SPN, NFS-Exporte, die Umleitung von SmartConnect DNS und das Hinzufügen von Authentifizierungsanbietern.

7. Führen Sie auf dem PRIMÄREN Cluster den Failback-Job mit Vorbereitung der Neusynchronisierung durch und vergewissern Sie sich, dass resync_prep_finalize erfolgreich abgeschlossen wurde.

   # 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

ÜBERSPRINGEN SIE SCHRITT 1 UND 4 (UNTEN ENTFERNT), WENN SIE NICHT MÖCHTEN, DASS DIE ÄNDERUNGEN FÜR DEN TEST ZURÜCK AN DEN PRIMÄREN SERVER GESENDET WERDEN.

Die neue Policy [POLICY]_mirror auf dem SEKUNDÄREN Cluster kann ausgeführt werden, um die Synchronisierung mit dem PRIMÄREN Cluster zu starten.

1. Beenden Sie alle Schreibvorgänge in den Pfad der SEKUNDÄREN Policy.

2. Deaktivieren Sie alle Zeitpläne, indem Sie die Richtlinien auf manuell setzen.

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

3. Führen Sie auf dem PRIMÄREN Cluster die Aktion "Schreibvorgänge zulassen" aus und überprüfen Sie, ob der lokale Job diese Aktion abschließt.

   # 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. Leiten Sie Clients (SMB, NFS, HTTP, FTP usw.) zum PRIMÄREN Cluster um.

   Hinweis: Die Einzelheiten dieses Schritts gehen über den Rahmen dieses Wissensdatenbank-Artikels hinaus und erfordern die Erstellung von SMB-Freigaben, NFS-Exporten und die Umleitung von SmartConnect DNS.

5. Führen Sie auf dem SEKUNDÄREN Cluster den Failback-Job mit Vorbereitung der Neusynchronisierung durch und vergewissern Sie sich, dass resync_prep_finalize erfolgreich abgeschlossen wurde.

   # 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

   Der SEKUNDÄRE Cluster ist jetzt SCHREIBGESCHÜTZT und die Policy [POLICY]_mirror des SEKUNDÄREN Clusters ist deaktiviert.

   Hinweis: Löschen Sie keine Spiegelungs-Policies.

6. Die ursprünglichen Policies für den PRIMÄREN Cluster sind jetzt aktiviert. Verwenden Sie die Backupdatei von FAILOVER-Schritt 3, um Ihre Policy-Zeitpläne wiederherzustellen. Auf dem PRIMÄREN Cluster:

   Zeigen Sie die gespeicherte Kopie der Policy-Zeitpläne an:

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

   Stellen Sie die Policy-Zeitpläne wieder her:

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