PowerScale: SmartSyncs SYNCIQ-policymigreringsfeil for én-til-mange- eller gjennomgripende replikering
Summary: Migreringen blokkeres av to feil: én når øyeblikksbildet av kilden ikke samsvarer med det siste øyeblikksbildet, og en annen når det er eldre enn det nyeste. På grunn av uoverensstemmelser i fan-out eller overlappende oppsett. ...
Symptoms
SmartSyncs SyncIQ-policymigrering mislykkes med én av to feil:
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.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.
Cause
Feil 1 oppstår når kildebasen har eksisterende datasett(er) som er merket som et måldatasett av SmartSync. Det tilknyttede øyeblikksbildet som brukes til migrering, og som brukes av SyncIQ-policyens kildeoppføring, er ikke det samme som brukes av det nyeste datasettet for den bestemte kildegrunnlagsbanen.
Feil 2 oppstår når kildebasen har eksisterende datasett(er) som ikke er merket som et måldatasett av SmartSync. Det tilknyttede øyeblikksbildet som brukes til migrering, og som brukes av SyncIQ-policyens kildeoppføring, er ikke større enn eller lik øyeblikksbildet som ble brukt av det nyeste datasettet for den bestemte kildegrunnlagsbanen.
Resolution
Hvis feilen allerede har oppstått, går du til delen Gjenopprettingstrinn.
Forebyggende migreringstrinn
Forholdsregler før feilene allerede vises i overføringsjobben. Før du starter overføringsjobben, må du utføre følgende trinn for å unngå feilene som er nevnt ovenfor:
Vifte-ut-konfigurasjon (A → B + A → C)
-
Trinn 1: Identifiser SyncIQ-policyen din Documentums interaktive leveringstjenester. For eksempel:
- Policy A → B:
# isi sync policies view <pol_a_b> | head -2 - Policy A → C:
# isi sync policies view <pol_a_c> | head -2
- Policy A → B:
-
Trinn 2: kildepostkatalogen på klynge A:
# cd /ifs/.ifsvar/modules/tsm/config/source_records/ -
Trinn 3: Vis XML-filen som tilsvarer hver policy-ID, og noter deg den nyeste snap-id-verdien:
-
Kontroller A→B-øyeblikksbildet (den resulterende ID-en blir AX i neste trinn):
# grep '<latest-snap-id>' <pol_a_b_ID>.xml -
Kontroller øyeblikksbildet → AC (resulterende ID blir AY i neste trinn):
# grep '<latest-snap-id>' <pol_a_c_ID>.xml
-
-
Trinn 4: Sammenlign de nyeste verdiene for øyeblikks-ID. Migrer policyen med den eldre (lavere) siste-snap-id-en først:
Hvis øyeblikksbildet fra A til B (AX) er eldre enn øyeblikksbildet fra A til C (AY), for eksempel:AX = snapID 100,AY = snapID150.
Deretter migrerer du policyen A til B først.
Hvis øyeblikksbildet fra A til C (AY) er eldre enn øyeblikksbildet fra A til B (AX), for eksempel:AX = snapID 150,AY = snapID100.
Deretter migrerer du A-til-C-policyen først.
Hvis begge policyene bruker samme øyeblikksbilde, for eksempel:AX = 100,AY = 100.
Begge policyene kan overføres først. Den andre policyoverføringen bruker datasettet på nytt.
Sammenkoblet (gjennomgripet) konfigurasjon (A → B → C)
-
Synkroniseringen bør være fullstendig fullført, slik at alle klynger som er involvert i policykjeding gjenspeiler de samme dataene.
-
Deaktiver alle SyncIQ-policyer i kjeden før du fortsetter med migreringen. Dette forhindrer at nye trinnvise SyncIQ-jobber utløses mens migreringen pågår. I en A→B→C-kjede deaktiverer du for eksempel både A→B- og B→C-policyen.
-
Viktig: Migreringen må alltid starte fra rotklyngen (kilde). For alle mellomliggende klynger (for eksempel B i et oppsett med 3 klynger), må alle policyer som har kildebane som også er mål for en annen SmartSync-policy, bruke det samme (identiske) øyeblikksbildet som det siste datasettet for den opprinnelige banen. Hvis øyeblikksbildene ikke samsvarer, stanser overføringsjobben (ikke blokkert permanent). Gjenopprettingstrinnene er lagt til nedenfor i delen Gjenopprettingstrinn.
Før du overfører kjedede policyer, må du sørge for at B→C SyncIQ-policyen bruker øyeblikksbildebasert synkronisering med samme øyeblikksbildemønster som produseres av A→B-policyen for klynge B. Dette sikrer at begge policyene deler samme grunnlinje for øyeblikksbilde på reléklyngen.
-
Hvis B→C SyncIQ-policyen ikke opprinnelig ble konfigurert med øyeblikksbildebasert synkronisering, må du oppdatere den før migreringen ved hjelp av følgende trinn:
-
Trinn 1: Kontroller at A→B-policyen oppretter øyeblikksbilder av arkivmål (Target Snapshot Archive: bør vise Ja) med et annet navnemønster enn standard navnemønster for SIQ-*.
# 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-%SSom du vil legge merke til i eksemplet ovenfor, er Target Snapshot Archive satt til"Nei"og mønsteret er standard med et prefiks av SIQ-*.
-
Trinn 2: Endre A→ B-policyen for å opprette et arkivøyeblikksbilde med et annet mønster enn standardmønsteret:
# 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 -
Trinn 3: Endre B→C-policyen til å bruke --schedule=when-snapshot-taken:
# isi sync policies modify <B_to_C_policy> --schedule=when-snapshot-taken -
Trinn 4: Utløse jobben til A→B-policyen for å sikre at B→C-policyen fanger den opp og bruker arkivøyeblikksbildet som ble opprettet av A-B>, på nytt. Du kan bekrefte ved å kjøre kommandoen rapporter.
# isi sync job start <A_to_B_policy>
# isi sync reports listVent til både A→B policyens jobb skal fullføres, og i sin tur vil det utløse B→C policyens jobb. Når begge jobbene er fullført, kontrollerer du at arkivøyeblikksbildet som ble opprettet av den siste kjøringen av A→B-policyen, brukes på nytt av den nyeste jobben til B→C ved hjelp av følgende kommando:
# 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>Som du vil legge merke til ovenfor, er den siste-snap-id for B→ C-policyen den samme som den siste-arkiv-snap for A→ B. Som er tilstanden for kjedet politikkens migrasjon å gå gjennom vellykket.
-
Trinn for gjenopprettingsoverføring
Hvis det allerede er forsøkt å overføre den, og overføringsjobben går til en MIDLERTIDIG stanset tilstand, følger du disse gjenopprettingstrinnene:
Konfigurasjon av vifteutgang
Når en SyncIQ-policymigreringsjobb mislykkes med feilen, aktiveres den tilsvarende SyncIQ-policyen tilbake. Avbøtende tiltak er:
- Trinn 1: Kjør SyncIQ-policyen for å få med deg:
# isi sync job start <policy-name> - Trinn 2: Vent til den nye jobbkjøringen er fullført og vises i rapportutdataene:
# isi sync reports list --policy-name <policy-name> - Trinn 3: Gjenoppta SmartSync Migration-jobben som hadde satt på pause:
# isi dm jobs resume <job_id>
Sammenkoblet (overlappende) konfigurasjon
Når en SyncIQ-policymigreringsjobb mislykkes med feilen, aktiveres den tilsvarende SyncIQ-policyen tilbake. Avbøtende tiltak er:
- Trinn 1: Endre SyncIQ-policyen ved hjelp av kommandoen:
# isi sync policies modify <B_to_C_policy> --schedule=when-snapshot-taken - Trinn 2: Kjør AB-policy> for smart synkronisering ved hjelp av kommandoen (forutsatt at oppstrømspolicyen allerede er migrert):
# isi dm policies modify <policy_name> --run-now=yes
Det vil automatisk få øyeblikksbildet synkronisert med det nyeste øyeblikksbildet av datasettet på kildebasebanen. - Trinn 3: Gjenoppta overføringsjobben ved hjelp av kommandoen:
# isi dm jobs resume <job_id>