PowerScale: Smartsyncin SYNCIQ-käytännön siirtovirhe yksi-moneen- tai johdannaisreplikaatiossa

SmartSyncin SyncIQ-käytännön siirto epäonnistuu ja näyttää jommankumman seuraavista virheistä:

1. Error Message: Migration blocked: Source record snapshot (<snapshot-id>) does not match latest dataset snapshot (<snapshot-id>) for the source basepath (<source-base-path>). This source basepath may act as a target for an existing SmartSync policy. Hence, the SIQ policy migration can't proceed unless the two snapshots are identical. Start the SIQ policy to match the latest dataset snapshot (<snapshot-id>) in source.
2. Error Message: Migration blocked: Source record snapshot (<snapshot-id>) is older than the snapshot (<snapshot-id>) associated with the latest dataset (<dataset details>) for the source basepath (<source-base-path>). Replicate to the latest snapshot or above to proceed with the SIQ policy migration.

Virhe 1 ilmenee, kun lähdepolulla on aiemmin luotuja tietojoukkoja, jotka SmartSync on merkinnyt kohdetietojoukoksi. SyncIQ-käytännön lähdetietueen käyttämä siirtoon liittyvä tilannevedos ei ole sama kuin se, jota uusin tietojoukko käyttää tietylle lähdepohjapolulle.

Virhe 2 ilmenee, kun lähdepolulla on aiemmin luotuja tietojoukkoja, joita SmartSync ei ole merkinnyt kohdetietojoukoksi. SyncIQ-käytännön lähdetietueen käyttämä siirtoon liittyvä tilannevedos ei ole suurempi tai yhtä suuri kuin tilannevedos, jota uusin tietojoukko käyttää tietylle lähdepohjapolulle.

Jos virhe on jo ilmennyt, siirry Palautusvaiheet-osaan.

Ennakoivan siirron vaiheet

Varotoimet, jotka on toteutettava, ennen kuin virheet ovat jo näkyneet siirtotyössä. Vältä edellä mainitut virheet suorittamalla seuraavat toimet ennen siirtotyön aloittamista:

Tuuletinkokoonpano (A → B + A → C)

1. Vaihe 1: Määritä SyncIQ-käytäntösi Documentum Interactive Delivery Services. Esimerkki:

   1. Käytäntö A → B:
      # isi sync policies view <pol_a_b> | head -2
   2. Käytäntö A → C:
      # isi sync policies view <pol_a_c> | head -2

2. Vaihe 2: lähdetietueiden hakemisto klusterissa A:

   # cd /ifs/.ifsvar/modules/tsm/config/source_records/

3. Vaihe 3: Luetteloi kutakin käytäntötunnusta vastaava XML-tiedosto ja tarkastele sitä sekä merkitse viimeisimmän snap-id-arvon muistiin:

   1. Tarkista A→B-tilannevedos (seuraavassa vaiheessa tuloksena oleva tunnus on AX):
      # grep '<latest-snap-id>' <pol_a_b_ID>.xml

   2. Tarkista A→C-tilannevedos (seuraavassa vaiheessa tuloksena oleva tunnus on AY):
      # grep '<latest-snap-id>' <pol_a_c_ID>.xml

4. Vaihe 4: Vertaa uusimpia snap-id-arvoja. Siirrä ensin käytäntö, jossa on vanhempi (alempi) uusin-snap-id:
   Jos A–B-tilannevedos (AX) on vanhempi kuin A–C-tilannevedos (AY), esimerkiksi: AX = snapID 100,AY = snapID150.
   Siirrä sitten ensin käytäntö A:sta B:hen.
   
   Jos A–C-tilannevedos (AY) on vanhempi kuin A–B-tilannevedos (AX), esimerkiksi: AX = snapID 150,AY = snapID100.
   Siirrä sitten ensin A–C-käytäntö.
   
   Jos molemmat käytännöt käyttävät samaa tilannevedosta, esimerkiksi: AX = 100,AY = 100.
   Kumpikin käytäntö voidaan siirtää ensin. Toinen käytännön siirto käyttää tietojoukkoa uudelleen.

Ketjutettu (kaskadikokoonpano) (A → B → C)

1. Synkronoinnin olisi oltava täysin valmis ja varmistettava, että kaikki politiikan ketjutukseen osallistuvat klusterit heijastavat identtisiä tietoja.

2. Poista kaikki ketjun SyncIQ-käytännöt käytöstä, ennen kuin jatkat siirtoa. Tämä estää uusien lisäävien SyncIQ-töiden käynnistämisen siirron aikana. Voit esimerkiksi poistaa A→B→C-ketjussa käytöstä sekä A→B- että B→C-käytännöt.

3. Tärkeää: Siirto on aina aloitettava juuriklusterista (lähdeklusterista). Kaikissa keskitason klustereissa (kuten B 3 klusterin kokoonpanossa) kaikkien käytäntöjen, joiden lähdepohjapolku on myös toisen SmartSync-käytännön kohteena, on käytettävä samaa (identtistä) tilannevedosta kuin kyseisen peruspolun uusin tietojoukko. Jos tilannevedokset eivät täsmää, siirtotyö keskeytyy (ei ole pysyvästi estetty). Palautusvaiheet lisätty alla Palautusvaiheet-osioon.

   Ennen kuin siirrät ketjutettuja käytäntöjä, varmista, että B→C SyncIQ -käytäntö käyttää tilannevedoksiin perustuvaa synkronointia samalla tilannevedosmallilla, jonka klusterin B A→B-käytäntö tuottaa. Näin varmistetaan, että molemmilla käytännöillä on sama tilannevedoksen perustaso releklusterissa.

4. Jos B→C SyncIQ -käytäntöä ei alun perin määritetty tilannevedoksiin perustuvalla synkronoinnilla, päivitä se ennen siirtoa seuraavasti:

   1. Vaihe 1: Varmista, että A→B-käytäntö luo arkistoituja kohteen tilannevedoksia (Target Snapshot Archive: pitäisi näkyä Kyllä) sekä nimeämismallilla, joka poikkeaa SIQ-*:n oletusarvoisesta nimeämismallista.

      # isi sync policies view pol_wJ9n-a2b | grep -E "Target Snapshot Archive|Target Snapshot Pattern" Target Snapshot Archive: No Target Snapshot Pattern: SIQ-%{SrcCluster}-%{PolicyName}-%Y-%m-%d_%H-%M-%S

      Kuten huomaat yllä olevassa esimerkissä, Target Snapshot Archive -asetuksena on "Ei" ja kuvio on oletuskuvio, jonka etuliite on SIQ-*.

   2. Vaihe 2: Muokkaa A→ B -käytäntöä niin, että arkistotilannevedos luodaan oletusmallista poikkeavalla mallilla:

      # isi sync policies modify <A_to_B_policy> --target-snapshot-archive True --target-snapshot-pattern 'snapB-%{PolicyName}-%Y-%m-%d'

# isi sync policies view pol_wJ9n-a2b | grep -E "Target Snapshot Archive|Target Snapshot Pattern" Target Snapshot Archive: Yes Target Snapshot Pattern: snapB-%{PolicyName}-%Y-%m-%d
      

   3. Vaihe 3: Muokkaa B→C-käytäntöä käyttämään --schedule=when-snapshot-taken:

      # isi sync policies modify <B_to_C_policy> --schedule=when-snapshot-taken

   4. Vaihe 4: Käynnistä A→B-käytännön työ ja varmista, että B→käytäntö saa sen kiinni ja käyttää uudelleen A–B:>n luomaa arkistotilannevedosta. Voit tarkistaa tämän suorittamalla reports-komennon.

      # isi sync job start <A_to_B_policy>

# isi sync reports list

      Odota, että sekä A→B-käytännön työ on valmis että vuorostaan käynnistää B→-käytännön työn. Kun molemmat työt on tehty, varmista seuraavalla komennolla, että B→C:n uusin työ käyttää A→B-käytännön viimeisimmän suorituksen luomaa arkistotilannevedosta uudelleen:

      # cat /ifs/.ifsvar/modules/tsm/config/target_records/<A_to_B_policy_Id>.xml | grep latest-archive-snap 
   <latest-archive-snap-alias>621</latest-archive-snap-alias> 
         <latest-archive-snap>625</latest-archive-snap>

# cat /ifs/.ifsvar/modules/tsm/config/source_records/<B_to_C_policy_Id>.xml | grep latest-snap-id
           <latest-snap-id>625</latest-snap-id>
   <restore-latest-snap-id>0</restore-latest-snap-id>
      

      Kuten edellä todettiin, B→ C:n uusimman snap-id:n käytäntö on sama kuin A→ B:n viimeisin arkisto-snap. Mikä on tila, jossa ketjutetun politiikan muuttoliike menee onnistuneesti läpi.

Palautuksen siirron vaiheet

Jos siirtoa on jo yritetty ja siirtotyö siirtyy PAUSED-tilaan, toimi seuraavasti:

Tuulettimen kokoonpano

Jos SyncIQ-käytännön siirtotyö epäonnistuu virheen vuoksi, vastaava SyncIQ-käytäntö otetaan takaisin käyttöön. Lievennystoimet ovat seuraavat:

1. Vaihe 1: Suorita SyncIQ-käytäntö saadaksesi kiinni:
   # isi sync job start <policy-name>
   
2. Vaihe 2: Odota, että uusi työ suoritetaan onnistuneesti ja näkyy raporttien tuloksissa:
   # isi sync reports list --policy-name <policy-name>
3. Vaihe 3: Jatka SmartSync-siirtotyötä, joka oli keskeytetty:
   # isi dm jobs resume <job_id>

Ketjutettu (kaskadikokoonpano)

Jos SyncIQ-käytännön siirtotyö epäonnistuu virheen vuoksi, vastaava SyncIQ-käytäntö otetaan takaisin käyttöön. Lievennystoimet ovat seuraavat:

1. Vaihe 1: Muokkaa SyncIQ-käytäntöä komennolla
   # isi sync policies modify <B_to_C_policy> --schedule=when-snapshot-taken
2. Vaihe 2: Suorita A–>B Smart Sync -käytäntö komennolla (olettaen, että upstream-käytäntö on jo siirretty):
   # isi dm policies modify <policy_name> --run-now=yes
   Se synkronoi tilannevedoksen automaattisesti lähdepolun uusimman tietojoukkotilannevedoksen kanssa.
3. Vaihe 3: Jatka siirtotyötä komennolla
   # isi dm jobs resume <job_id>