Data Domain: Anbefalte fremgangsmåter for datamigrering på PowerProtect Data Domain-systemer ved hjelp av Mtree-replikering
Summary: Denne artikkelen beskriver hvordan du forbereder overføring av data ved hjelp av Mtree-replikering (MRepl) fra eldre PowerProtect Data Domain (PPDD)-systemer uten intern QAT-kortstøtte. For eksempel DD9500 og DD9800. Det er viktig å vurdere den gjeldende arbeidsbelastningen for systemdriften for å unngå uventede bivirkninger som kan ha negativ innvirkning på resultatene av datamigreringen. Denne artikkelen hjelper deg med å planlegge overføringsoperasjoner som krever en ny MTREE-replikeringskontekstkonfigurasjon (MRepl) ved bruk av eldre PPDD-systemer som kilde. ...
Instructions
Med introduksjonen av 16G-plattformer er migrering av spesifikke MTrees fra eldre PPDD til et nyere system et vanlig krav.
Overføringsprosessen oppretter nye Mtree-replikeringskontekster. Vurder følgende for å sikre minst mulig forstyrrelser.
- Gjeldende systemworkload fra sikkerhetskopieringsoperasjoner
- Forskjeller i komprimeringsmuligheter (for eksempel QAT-kortstøtte)
- Plutselig innlemmelse av nye Mrepl kontekstkonfigurasjoner
- HW-feil som påvirker søppelinnsamlingsprosessen (GC)
For å opprettholde dataintegriteten og oppfylle servicenivåavtaler kan systemet få panikk ved visse operasjonsterskler.
Panikkmekanismen utløser selvkorrigerende tiltak for å sikre at systemet alltid fungerer pålitelig.
Dette drøfter disse vurderingene og veileder hvordan du kan forhindre uventet nedetid som kan forstyrre overføringsplaner.
Gjeldende systemworkload fra sikkerhetskopieringsoperasjoner:
Fokuser innledningsvis på gjeldende systemoperasjoner. Før overføringen må du overvåke viktige beregninger. Disse inkluderer pågående arbeidsbelastninger, CPU-bruk, minnebruk, nettverksstatus og maskinvarevarsler.
Målet er å bevare systemets drift innenfor normale parametere.
Forskjeller i komprimeringsmuligheter:
Når du forbereder migrering ved hjelp av Mtree-replikering (Mrepl), bør du vurdere forskjellen i komprimeringsfunksjoner mellom systemer.
Noen eldre systemer mangler et innebygd komprimeringskort for å hjelpe med komprimeringsrelaterte operasjoner.
DD9900-, DD9400- eller DD6900-systemene tillater tilkobling av et eksternt QAT-kort for å akselerere komprimeringsoperasjoner.
Når et QAT-kort ikke finnes (for eksempel DD9800, DD9500), er det avhengig av CPU- og minneressurser for komprimerings- og dekomprimeringsoppgaver.
Når du konfigurerer nye replikeringskontekster uten QAT-støtte, må dataene først være ukomprimerte.
Dette kan føre til en økning i CPU-bruken under initialiseringsfasen for replikering.
Kilden kontrollerer destinasjonen for å identifisere hvilken type komprimeringskort som er tilgjengelig.
Når et 16G-system (DD9910, DD9410 eller DD6410) er målet, må kilden dekomprimere data fra det eldre "gzfast"-formatet. Den må deretter komprimere den til LZ-formatet.
Gradvis innlemme ny mrepl kontekstkonfigurasjon:
Under nødgjenoppretting (DR), når replikering av data fra ett datadomene til et annet replikeres, starter replikeringsjobber vanligvis etter at datainntaket er fullført.
Dette sikrer at målområdet mottar alle replikerte data.
Når nye replikeringskontekster defineres for overføring, må kilden håndtere betydelige data under initialisering av replikering.
Dette er fordi destinasjonen mangler dedupliserte data og optimalisering er ennå ikke mulig. Dette resulterer i økt belastning på kildesystemet.
For å redusere dette, når systemet fortsetter å behandle sikkerhetskopieringsarbeidsbelastninger (I/O), gradvis innlemme replikeringskontekster knyttet til migreringen.
Definer en lav replikeringsgjennomstrømning for å begrense ressursene som er tildelt disse overføringsrelaterte replikeringskontekstene.
Når replikering begynner å bygge optimaliseringer på målet og driftsparameterne er validert, legger du til flere replikeringskontekster (overføringskontekster). Du kan også endre gjennomstrømmingen for replikering på eksisterende.
Målet er å unngå å utløse systemets beskyttelsesmekanismer. Dette fører til systempanikk som kan påvirke migreringer.
Husk at referanser for systemytelse beregnes basert på workloader i drift, ikke for nye arbeidsbelastninger.
Konfigurer begrensning gradvis under migreringsscenarier.
Kommandoen "replication throttle add" kan brukes til å planlegge et bestemt tidspunkt og tildele en definert båndbredde (i Mbps) for begrensning.
Start nye replikeringsjobber med en begrenset tilgjengelig båndbredde (lavere gass). Deretter vurderer du virkningen på systemdriften.
Når replikeringsjobben er i gang, kan gassen økes for å gi ekstra båndbredde.
Det anbefales også å overvåke systemanalyse, inkludert CPU, minne og nettverksforbruk, som er tilgjengelig på DDSM.
HW-feil som påvirker søppelinnsamlingsprosessen (GC):
En annen faktor som potensielt kan føre til redusert sikkerhetskopierings- eller replikeringsytelse, er knyttet til maskinvarefeil, spesielt under standard søppelinnsamlingsoperasjoner. Under normale driftsforhold fullfører søppelinnsamlingsmekanismen på PPDD-systemer plassgjenvinningsaktiviteter uten å påvirke inntaks-, gjenopprettings- eller replikeringsoperasjoner. I visse situasjoner tilbyr systemet alternativer for å definere struping av søppeloppsamling, noe som gir systemadministratorer ytterligere kontroll over når systemets rengjøringsprosesser oppstår.
Standard gasskonfigurasjon for søppelrydding påvirker ikke sikkerhetskopieringer og gjenopprettinger. De fleste tilfeller der en innvirkning er observert, er knyttet til maskinvarefeil. Når enkelte disker for eksempel må byttes ut, kan systemets kontinuerlige I/O-krav redusere lagringen av sikkerhetskopier og gjenopprettinger, noe som påvirker den totale GC-driften.
Data Domain-operativsystemet har omfattende varslingsmekanismer for slike maskinvareproblemer, og varsler proaktivt når disse forholdene oppdages. Dette gjør det lettere for backupoperatører å raskt løse maskinvarerelaterte problemer.
En annen viktig faktor å vurdere er at replikeringsaktiviteter er like viktige som sikkerhetskopiering og gjenoppretting. Etter design gir hver plattform et fast antall strømmer for hver jobb og kan behandle samtidige operasjoner under de definerte grensene for å oppfylle servicenivåavtaler (SLA-er).
Konklusjon:
Vellykket datamigrering ved hjelp av Mtree-replikering krever nøye vurdering av følgende;
- Overvåke gjeldende systemworkload fra sikkerhetskopieringsoperasjoner
- Forstå eldre plattformer som DD9800 eller DD9500
- Bruk en annen komprimeringsalgoritme (gzfast).
- Når nye MTree-replikeringskontekster (MRepl) opprettes på et system under drift, innlemmes de nye Mrepl-kontekstkonfigurasjonene gradvis.
- Overvåk nøye virkningen av de nye arbeidsbelastningene på systemet.
- Overvåk potensielle maskinvarefeil (som påvirker operasjoner fra søppelinnsamlingsprosessen).
Ved å følge disse anbefalte fremgangsmåtene, minimeres avbrudd og opprettholder systemets stabilitet.
Implementering av disse anbefalingene bidrar til å unngå uventet nedetid og forenkler datamigrering.