Data Domain: Best practices voor datamigratie op PowerProtect Data Domain systemen met behulp van Mtree-replicatie
Summary: In dit artikel wordt de voorbereiding besproken voor het migreren van data met behulp van Mtree-replicatie (MRepl) van oudere PowerProtect Data Domain (PPDD)-systemen zonder ondersteuning voor interne QAT-kaarten. Bijvoorbeeld DD9500 en DD9800. Het is van cruciaal belang om rekening te houden met de huidige werklast van het systeem om onverwachte bijwerkingen te voorkomen die een negatieve invloed kunnen hebben op de resultaten van de datamigratie. Dit artikel helpt bij het plannen van migratiebewerkingen waarvoor een nieuwe Mtree Replication (MRepl)-contextconfiguratie nodig is met behulp van legacy PPDD-systemen als bron. ...
Instructions
Met de introductie van 16G-platforms is het migreren van specifieke MTrees van legacy PPDD naar een nieuwer systeem een veelvoorkomende vereiste.
Het migratieproces creëert nieuwe Mtree-replicatiecontexten. Houd rekening met het volgende om een minimale verstoring te garanderen.
- Huidige systeemworkload van back-upbewerkingen
- Verschillen in compressiemogelijkheden (bijvoorbeeld QAT-kaartondersteuning)
- Plotselinge integratie van nieuwe Mrepl-contextconfiguraties
- HW-fouten die van invloed zijn op het garbage collection-proces (GC)
Om de data-integriteit te handhaven en te voldoen aan Service Level Agreements, kan het systeem in paniek raken bij bepaalde operationele drempels.
Het paniekmechanisme activeert zelfcorrigerende acties om ervoor te zorgen dat het systeem altijd betrouwbaar werkt.
Hierin worden deze overwegingen besproken en wordt uitgelegd hoe u onverwachte downtime kunt voorkomen die de migratieplannen kan verstoren.
Huidige systeemworkload van back-upbewerkingen:
Richt u in eerste instantie op de huidige systeemactiviteiten. Bewaak vóór de migratie de belangrijkste statistieken. Deze omvatten doorlopende workloads, CPU-gebruik, geheugengebruik, netwerkstatus en hardwarewaarschuwingen.
Het doel is om de werking van het systeem binnen de normale parameters te houden.
Verschillen in compressiemogelijkheden:
Houd bij de voorbereiding van de migratie met behulp van Mtree-replicatie (Mrepl) rekening met het verschil in compressiemogelijkheden tussen systemen.
Sommige oudere systemen hebben geen ingebouwde compressiekaart om te helpen bij compressiebewerkingen.
Op de DD9900-, DD9400- of DD6900-systemen kan een externe QAT-kaart worden aangesloten om compressiebewerkingen te versnellen.
Wanneer een QAT-kaart niet aanwezig is (bijvoorbeeld DD9800, DD9500), vertrouwt deze op CPU- en geheugenbronnen voor compressie- en decompressietaken.
Bij het configureren van nieuwe replicatiecontexten zonder QAT-ondersteuning moeten de data eerst worden gedecomprimeerd.
Dit kan resulteren in een piek in het CPU-gebruik tijdens de initialisatiefase van de replicatie.
De bron controleert de bestemming om het type compressiekaart te identificeren dat beschikbaar is.
Wanneer een 16G-systeem (DD9910, DD9410 of DD6410) het doel is, moet de bron data decomprimeren uit het verouderde gzfast-formaat. Het moet het dan comprimeren naar het LZ-formaat.
Geleidelijk een nieuwe mrepl contextconfiguratie integreren:
Tijdens herstel na noodgeval (DR), bij het repliceren van data van het ene datadomein naar het andere, beginnen replicatietaken meestal nadat de data-opname is voltooid.
Dit zorgt ervoor dat de doelsite alle gerepliceerde data ontvangt.
Wanneer nieuwe replicatiecontexten worden gedefinieerd voor migratie, moet de bron belangrijke data verwerken tijdens de replicatie-initialisatie.
Dit komt omdat de bestemming geen gededupliceerde data heeft en optimalisatie nog niet mogelijk is. Dit resulteert in een verhoogde belasting van het bronsysteem.
Als u dit wilt beperken, moet u bij het verwerken van back-upworkloads (I/O) geleidelijk replicatiecontexten opnemen die aan de migratie zijn gekoppeld.
Definieer een lage replicatiedoorvoer om de resources te beperken die zijn toegewezen aan deze migratiegerelateerde replicatiecontexten.
Zodra replicatie begint met het opbouwen van optimalisaties op de bestemming en de operationele parameters zijn gevalideerd, voegt u meer replicatiecontexten (migratie) toe. Of wijzig de replicatiedoorvoer op bestaande doorvoeren.
Het doel is om te voorkomen dat de beschermingsmechanismen van het systeem worden geactiveerd. Dit leidt tot systeempanics die van invloed kunnen zijn op migraties.
Vergeet niet dat referentiereferenties voor systeemprestaties worden berekend op basis van actieve workloads, niet voor nieuwe workloads.
Configureer beperkingen geleidelijk tijdens migratiescenario's.
De opdracht "replication throttle add" kan worden gebruikt om een specifiek tijdstip te plannen en een gedefinieerde bandbreedte (in Mbps) toe te wijzen voor beperking.
Start nieuwe replicatietaken met een beperkte beschikbare bandbreedte (lagere throttle). Beoordeel vervolgens de impact op de werking van het systeem.
Zodra de replicatietaak is uitgevoerd, kan de throttle worden verhoogd om extra bandbreedte te bieden.
Het wordt ook aanbevolen om systeemanalyses te controleren, inclusief CPU-, geheugen- en netwerkverbruik, die beschikbaar zijn op DDSM.
HW-fouten die van invloed zijn op het garbage collection (GC)-proces:
Een andere factor die mogelijk leidt tot verslechtering van de back-up- of replicatieprestaties heeft te maken met hardwarestoringen, met name tijdens standaard garbage collection-bewerkingen. Onder normale operationele omstandigheden voltooit het garbage collection-mechanisme op PPDD-systemen ruimterecyclingactiviteiten zonder gevolgen voor opname-, herstel- of replicatiebewerkingen. In bepaalde situaties biedt het systeem opties om garbage collection throttling te definiëren, waardoor systeembeheerders extra controle hebben over wanneer de opschoonprocessen van het systeem worden uitgevoerd.
De standaard throttle-configuratie voor garbage collection heeft geen invloed op back-ups en herstelbewerkingen. De meeste gevallen waarin een impact wordt waargenomen, houden verband met hardwarestoringen. Wanneer bijvoorbeeld bepaalde schijven moeten worden vervangen, kunnen de voortdurende I/O-vereisten van het systeem de storage van back-ups en herstelbewerkingen vertragen, wat van invloed is op de algehele GC-bewerkingen.
Het Data Domain-besturingssysteem biedt uitgebreide waarschuwingsmechanismen voor dergelijke hardwareproblemen, waarbij proactief waarschuwingen worden gegenereerd wanneer deze omstandigheden worden gedetecteerd. Dit vergemakkelijkt back-upoperators bij het snel oplossen van hardwaregerelateerde problemen.
Een andere belangrijke factor om rekening mee te houden is dat replicatieactiviteiten even belangrijk zijn als back-up en herstel. Door het ontwerp biedt elk platform een vast aantal streams voor elke taak en kan het gelijktijdige bewerkingen verwerken onder de gedefinieerde limieten om te voldoen aan Service Level Agreements (SLA's).
Conclusie:
Succesvolle datamigratie met behulp van Mtree-replicatie vereist een zorgvuldige afweging van het volgende:
- De huidige systeemworkload bewaken vanuit back-upbewerkingen
- Inzicht in legacy-platforms zoals DD9800 of DD9500
- Gebruik een ander compressiealgoritme (gzfast).
- Wanneer nieuwe MTree-replicatiecontexten (MRepl) worden gemaakt op een systeem dat in gebruik is, neemt u geleidelijk de nieuwe Mrepl-contextconfiguraties op
- Houd de impact van de nieuwe workloads op het systeem nauwlettend in de gaten.
- Controleer mogelijke hardwarefouten (die van invloed zijn op activiteiten van het garbage collection-proces).
Door deze best practices te volgen, worden onderbrekingen tot een minimum beperkt en blijft het systeem stabiel.
Het implementeren van deze aanbevelingen helpt onverwachte downtime te voorkomen en vergemakkelijkt datamigratie.