Isilon: Jaké jsou kroky rozhraní příkazového řádku pro převzetí služeb při selhání SyncIQ a navrácení po obnovení

Summary: Postup v rozhraní příkazového řádku pro převzetí při selhání / navrácení zásad po obnovení (FOFB)

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.

Symptoms

Jaké jsou kroky rozhraní příkazového řádku pro převzetí při selhání SyncIQ a navrácení po obnovení?
Postup v uživatelském rozhraní obsahuje podrobného průvodce, existuje podobný průvodce pro rozhraní příkazového řádku?

 

Cause

Podrobné kroky k provádění FOFB

 

Resolution

Příručka k rozhraní příkazového řádku pro převzetí služeb při selhání a navrácení po obnovení:

I když výše uvedená dokumentace nabízí některé dobré informace, níže uvedené kroky jsou podrobnější při provádění převzetí služeb při selhání a navrácení po obnovení pomocí příkazového řádku.

V následujících krocích se pro tyto dva termíny používá terminologie SyncIQ:

  • ZDROJOVÝ cluster = PRIMÁRNÍ.
  • CÍLOVÝ cluster = SEKUNDÁRNÍ

Převzetí služeb při selhání:

  1. Na primárním clusteru zvažte spuštění domainmark Úlohy dny nebo týdny předem, pokud se jedná o první pokus o převzetí služeb při selhání clusteru. Pokud je datová sada velká, pomáhá ušetřit čas při urychlení pracovní fáze domainmark .

    Poznámka: Nová možnost „Accelerated Failback“ tento krok odstraňuje. Tento krok je nutné provést POUZE jednou. Jakmile je označeno, budoucí domainmark Úlohy jsou (viz krok 7 níže) no-op.
    # isi job jobs start domainmark --root=<path> --dm-type=synciq

    Tím se každému LIN předem označí příslušné ID ochranné domény, místo aby to všechno provedla úloha převzetí služeb při selhání (viz krok 7). Skript domainmark může trvat dlouhou dobu v závislosti na velikosti datové sady.

  2. Zastavte veškerý zápis do cesty primární zásady.

    Poznámka: Zápisy do cesty zásad primárního clusteru, ke kterým dochází od tohoto kroku, se nezachovají, což může vést ke ztrátě dat. Ověřte, že všechny zápisy do této cesty na primární úrovni byly zastaveny.
  3. U primárního clusteru zálohujte plány zásad a poté všechny plány zakažte nastavením zásad na ruční.

    Uložení záložní kopie plánů:

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

    Poté zakažte všechny plány nastavením zásad na ruční.

    Poznámka: Úloha synchronizace a úloha převzetí služeb při selhání nemohou být záměrně spuštěny současně a způsobí, že pokus o převzetí služeb selže. Chcete-li se tomuto problému vyhnout, nastavte všechny zásady na ruční.
    # isi sync policies modify  --policy=[POLICY] --schedule=""
  4. V primárním clusteru spusťte poslední úlohu synchronizace a potvrďte, že byla úspěšně dokončena.

    Poznámka: Tento krok se doporučuje pouze v případě, že testujete funkčnost FOFB. Tento krok neprovádějte, pokud v primárním clusteru již došlo k události selhání a sekundární cluster již byl nastaven tak, aby povoloval zápisy.
    # isi sync jobs start [POLICY]

    Spuštěním tohoto příkazu potvrďte úspěšné dokončení procesu:

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

    V primárním clusteru spusťte poslední úlohu synchronizace.

    # isi sync jobs start [POLICY]
  5. V sekundárním clusteru proveďte akci Povolit zápisy a ověřte, že místní úloha tuto akci dokončí.

    # 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
    POZNÁMKA: Obraťte nastavení adresáře SmartLock podle potřeby na obou clusterech.
    https://infohub.delltechnologies.com/en-us/l/dell-powerscale-smartlock-best-practices/synciq/
  6. Přesměrujte klienty (SMB, NFS, HTTP, FTP atd.) na sekundární cluster.

    Poznámka: Specifika tohoto kroku jsou mimo rozsah tohoto článku znalostní databáze a vyžadují vytvoření sdílených složek SMB, připojení k doméně Active Directory, účty počítače, SPN, exporty NFS, přesměrování SmartConnect DNS a přidání poskytovatelů ověřování.
  7. Než budete pokračovat v přípravě na opětovnou synchronizaci, vytvořte snapshot pro obnovení na obou clusterech.

    Ve zdrojovém clusteru

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

    V cílovém clusteru

    # isi snapshot snapshots create --path=[TARGET_PATH] --name=SIQ-recovery-policy-[POLICY_NAME] --expires=2W
  8. V primárním clusteru proveďte úlohu převzetí služeb při selhání s přípravou opětovné synchronizace a ujistěte se, že je resync_prep_finalize fáze dokončena.

    # 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

Navrácení služeb po obnovení

Důležitá poznámka: Před spuštěním tohoto kroku zkontrolujte, zda v sekundárním clusteru existuje soubor XML source_record se stejným ID zásady jako u původní zásady. Například pro ID zdrojové zásady 7da67596f099b75ad687a05f6b11781d spusťte v cílovém clusteru:
ls -l /ifs/.ifsvar/modules/tsm/config/source_records/7da67596f099b75ad687a05f6b11781d*
  1. Novou zásadu [ZÁSADA]_mirror v sekundárním clusteru lze spustit, a zahájit tak synchronizaci s primárním clusterem.

    # isi sync jobs start --policy-name=[POLICY]_mirror
  2. Zastavte veškerý zápis do cesty sekundární zásady.

    Poznámka: Zápisy do cesty zásad sekundárního clusteru, ke kterým dochází od tohoto kroku, se nezachovají, což může vést ke ztrátě dat. Ověřte, že všechny zápisy do této cesty na sekundární cestě byly zastaveny.
  3. Zakažte všechny plány nastavením zásad na ruční.

    # isi sync policies modify  --policy=[POLICY]_mirror --schedule=""
  4. V sekundárním clusteru spusťte poslední úlohu synchronizace.

    # isi sync jobs start --policy-name=[POLICY]_mirror
  5. V primárním clusteru proveďte akci Povolit zápisy a ověřte, že místní úloha tuto akci dokončí.

    # 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
    POZNÁMKA: Obraťte nastavení adresáře SmartLock podle potřeby na obou clusterech.
    https://infohub.delltechnologies.com/en-us/l/dell-powerscale-smartlock-best-practices/synciq/
  6. Přesměrujte klienty (SMB, NFS, HTTP, FTP atd.) na primární cluster.

    Poznámka: Specifika tohoto kroku jsou mimo rozsah tohoto článku znalostní databáze a vyžadují vytvoření sdílených složek SMB, exportů NFS a přesměrování SmartConnect DNS.
  7. Než budete pokračovat v přípravě na opětovnou synchronizaci, vytvořte snapshot pro obnovení na obou clusterech.

    Ve zdrojovém clusteru

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

    V cílovém clusteru

    # isi snapshot snapshots create --path=[TARGET_PATH] --name=SIQ-recovery-policy-[POLICY_NAME] --expires=2W
  8. V sekundárním clusteru proveďte úlohu navrácení služeb po obnovení s přípravou opětovné synchronizace a ověřte, že resync_prep_finalize proběhla úspěšně

    # 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

    Sekundární cluster je nyní jen pro čtení a sekundární zásada [ZÁSADA]_mirror je zakázaná.

    Poznámka: Neodstraňujte žádné zrcadlové zásady.
  9. Původní zásady v primárním clusteru jsou nyní povoleny. Pomocí záložního souboru z kroku 3 převzetí služeb při selhání obnovte plány zásad.

    V primárním clusteru:
    Zobrazení uložené kopie plánů zásad:

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

    Obnovení plánů zásad:

    # isi sync policies modify  --policy=[POLICY] --schedule=[schedule]
  10. Na původním sekundárním snímku zůstane po úspěšném navrácení služeb po obnovení snímek SIQ-mirrorpolID-last<>. Ručně vyčistěte snapshot SIQ-mirrorpolID-last<>, aby nedocházelo k zápisu COW do existujících snapshotů na sekundárním serveru.
    # 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

Tady je příklad testovacích kroků, které ignorují změny v sekundárním clusteru po převzetí služeb při selhání a navrácení služeb po obnovení. Postupují se stejně s tím rozdílem, že zásada zrcadlení se spouští jenom jako RESYNC PREP a ne jako běžná úloha synchronizace ze sekundárního do primárního, takže se změny neodesílají zpět do primárního clusteru. Před přechodem k dalšímu kroku se ujistěte, že jste dokončili každý krok.

Převzetí služeb při selhání:

  1. Na primárním clusteru zvažte spuštění domainmark Úlohy dny nebo týdny předem, pokud se jedná o první pokus o převzetí služeb při selhání clusteru. Pokud je datová sada velká, pomáhá ušetřit čas při urychlení pracovní fáze domainmark .

    Poznámka: To je výhodné pouze pro vůbec první pokus o převzetí služeb při selhání. Následné pokusy o převzetí služeb při selhání již nepřinesou žádný užitek.
    # isi job jobs start domainmark --root=<path> --dm-type=synciq

    Tím se každému LIN předem označí příslušné ID ochranné domény, místo aby to všechno provedla úloha převzetí služeb při selhání (viz krok 7). Příkaz domainmark může trvat dlouhou dobu v závislosti na velikosti datové sady.

  2. Zastavte veškerý zápis do cesty primární zásady.

    Poznámka: Zápisy do cesty zásad primárního clusteru, ke kterým dochází od tohoto kroku, se nezachovají, což může vést ke ztrátě dat. Ujistěte se se zákazníkem, že všechny zápisy do této cesty v primárním clusteru byly zastaveny.
  3. U primárního clusteru zálohujte plány zásad a poté všechny plány zakažte nastavením zásad na ruční.

    Uložení záložní kopie plánů:

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

    Poté zakažte všechny plány nastavením zásad na ruční.

    Poznámka: Úloha synchronizace a úloha převzetí služeb při selhání nemohou být záměrně spuštěny současně a způsobí, že pokus o převzetí služeb selže. Chcete-li se tomuto problému vyhnout, nastavte všechny zásady na ruční.
    # isi sync policies modify  --policy=[POLICY] --schedule=""
  4. V primárním clusteru spusťte poslední úlohu synchronizace a potvrďte, že byla úspěšně dokončena.

    Poznámka: Tento krok se doporučuje pouze v případě, že testujete funkci FOFB. Tento krok neprovádějte, pokud v primárním clusteru již došlo k události selhání a sekundární cluster již byl nastaven tak, aby povoloval zápisy.
    # isi sync jobs start [POLICY]

    Spuštěním tohoto příkazu potvrďte úspěšné dokončení procesu:

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

    V primárním clusteru spusťte poslední úlohu synchronizace.

    # isi sync jobs start [POLICY]
  5. V sekundárním clusteru proveďte akci Povolit zápisy a ověřte, že místní úloha tuto akci dokončí.

    # 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. Přesměrujte klienty (SMB, NFS, HTTP, FTP atd.) na sekundární cluster.

    Poznámka: Specifika tohoto kroku jsou mimo rozsah tohoto článku znalostní databáze a vyžadují vytvoření sdílených složek SMB, připojení k doméně Active Directory, účty počítače, SPN, exporty NFS, přesměrování SmartConnect DNS a přidání poskytovatelů ověřování.
  7. V primárním clusteru proveďte úlohu navrácení služeb po obnovení s přípravou na opětovnou synchronizaci a ověřte, že se úloha resync_prep_finalize dokončí.

    # 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
Poznámka: Zdroj je nyní pouze pro čtení a primární zásada je zakázána. Tato úloha také vytvoří zrcadlovou zásadu s příponou „_mirror“ na sekundárním clusteru, která se používá k navrácení služeb po obnovení do primárního clusteru.

Navrácení služeb po obnovení

PŘESKOČTE KROKY 1 A 4 (ODSTRANĚNÉ NÍŽE), POKUD NECHCETE, ABY SE ZMĚNY ODESÍLALY ZPĚT NA PRIMÁRNÍ TEST.

Novou zásadu [ZÁSADA]_mirror v sekundárním clusteru lze spustit, a zahájit tak synchronizaci s primárním clusterem.

  1. Zastavte veškerý zápis do cesty sekundární zásady.

  2. Zakažte všechny plány nastavením zásad na ruční.

    # isi sync policies modify  --policy=[POLICY]_mirror --schedule=""
  3. V primárním clusteru proveďte akci Povolit zápisy a ověřte, že místní úloha tuto akci dokončí.

    # 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. Přesměrujte klienty (SMB, NFS, HTTP, FTP atd.) na primární cluster.

    Poznámka: Specifika tohoto kroku jsou mimo rozsah tohoto článku znalostní databáze a vyžadují vytvoření sdílených složek SMB, exportů NFS a přesměrování SmartConnect DNS.
  5. V sekundárním clusteru proveďte úlohu navrácení služeb po obnovení s přípravou na opětovnou synchronizaci a ověřte, že úloha resync_prep_finalize proběhla úspěšně.

    # 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

    Sekundární cluster je nyní jen pro čtení a sekundární zásada [ZÁSADA]_mirror je zakázaná.

    Poznámka: Neodstraňujte žádné zrcadlové zásady.
  6. Původní zásady v primárním clusteru jsou nyní povoleny. Pomocí záložního souboru z kroku 3 převzetí služeb při selhání obnovte plány zásad. V primárním clusteru:

    Zobrazení uložené kopie plánů zásad:

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

    Obnovení plánů zásad:

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