NetWorker: Problemer med kapasitetsmodus vProxy-kloning av jobbytelse mellom datadomener

• vProxy-kloningshastigheten har falt fra GBs/sek til mer konvensjonelle og realistiske hastigheter.
• Nettverksbåndbredde utelukket som årsak til flaskehals, og holder seg godt under terskelen under kloning.
• Meldinger blir funnet i ddfs.infologger som refererer til én eller flere *-flat.vmdk-filer for de berørte VM-diskene som inneholder:
  • synthesized_vbytes 0 og slutter med recipe_repl FALSE
  • srepl_filecopy_recipe_validate_bf: srepl_get_replica_attr for basisfil og slutter med feil Filreferanse er foreldet.
• Meldinger som finnes i handlingsloggene for kloning (når feilsøkingsnivået for kloning er 3or høyere), refererer til én eller flere *-flat.vmdk-filer for de berørte VM-diskene som inneholder:
  • Syntetisk replikering kan ikke brukes for filen ... bane ... / vm-vmnumber-disk-key-disknumber-flat.vmdk

vProxy bruker virtuellesyntetiske stoffer til å utnytte VMwares endrede blokksporings-API, noe som gir mestringsforbedringer for både sikkerhetskopierings- og kloningsoperasjoner. Dette krever aktivt vedlikehold av interne tilknytninger til VM-filsett-hereditet på hvert av de involverte Data Domain-ene. Hvis det oppstår problemer mens du forbereder deg på å klone ved hjelp av virtuelle syntetiske stoffer, kan ikke NetWorker og Data Domain gå tilbake til å bruke standard replikeringsarbeidsflyt. Dette krever behandling av hele virtuelle diskfiler, i stedet for bare de endrede blokkene, i motsetning til bare de endrede blokkene som leveres av VMware API- og selv om lite data til slutt sendes på grunn av deduplisering, kan kloning av jobbvarighet øke med multipler.
 
Årsaker som kan føre til svikt i virtuell, syntetisk sporing, omfatter:

• Ulike IP-adresser som løses av NetWorker for kilde- eller måldatadomeneenheter mellom jobber – disse må forbli konsekvente for virtuellsyntetisk intern sporing
• Endre kilde- eller måldatadomene for vProxy-sikkerhetskopier eller -kloner
• Flere kilde- eller målvolumer for vProxy-sikkerhetskopier eller -kloner, noe som kan føre til samtidig kloning av flere lagre i kjeden
• Mer enn én vProxy-lagringssett som krever kloning for en gitt VM, noe som kan føre til forstyrrende kloning av lagre i kjeden
• VM-disker som går i lange perioder uten endringer (særlig perioder som overskrider lagrede oppbevaringsperioder, for eksempel 35 dager uten endring der oppbevaring er 30 dager)
• Hvis du ikke bruker chronologicalOrder Action-egenskapen, hvis du bruker NetWorker 19.6 og nyere

Siden det finnes flere potensielle årsaker, kan du se gjennom Data Domain- og NetWorker-konfigurasjoner og sikre:

• ifgroups er riktig konfigurert for både kildedatadomener (sikkerhetskopiering) og måldatadomener (klonemål)
• NetWorker-server, lagringsnoder og datadomener har alle vertsfiloppføringer som bruker riktig ifgroup IP-er per datadomene, og pålitelig DNS for klienter (ved hjelp av NetWorker-klientvertsfiler ved behov).
• Single Data Domain for hvert utvalg for sikkerhetskopiering og klone.

Når du bruker NetWorker 19.5 eller nyere:

• Sørge for at klonejobber utføres serielt og i rekkefølgen av sikkerhetskopieringer; Vær oppmerksom på at dette ikke kan kontrolleres når flere kloner for en gitt VM er i samme jobbliste (klonehandling eller nsrclone saveset-filliste).
• Sørg for ett enkelt sikkerhetskopierings- og klonevolum per utvalg for å unngå samtidig kloning når flere volumer er tilgjengelige for kilde.

Fra og med NetWorker 19.6 bør du alltid aktivere ChronologicalOrder-funksjonen for vProxy saveset clone-handlinger, som kan være skjult i brukergrensesnittet:

• Hvis du bruker nsrclone-kommandoen, bruker du O-svitsjen til å fremtvinge denne nye funksjonen når du bruker en lagringssettliste med flere lagringssett i en gitt klientkjede
• Hvis du vil aktivere i policyen, bruker du én av følgende to kommandoer:

  • nsrpolicy action update clone -p policyname -w workflowname -A actionname [--chronological_order | -l] 

  • I nsradmin-ledeteksten:

    • . type nsr protection policy action; policy name: policy; workflow: workflow: name: action

    • update Chronological order: Yes

      
       
• Når dette er fullført, løftes tidligere nevnte restriksjoner på enkeltkilde- og målvolumer, samt trinnvis flere forekomster per VM-klient, og kan behandles på riktig måte.

VIKTIG: Noen betingelser kan være mulig for NetWorker og Data Domain å gjenopprette fra, der lagrene er klonet ut av rekkefølge. Dette fører til at noen ikke kan bruke VSR for replikering, men når hele kjeden er gjenopprettet, kan VSR-kloning fortsette uten problemer. Generelt sett kan kloning utenfor rekkefølgen, multivolum og multisparende kloning ta seg opp og gå tilbake til vanlig drift.
 
Hvis flere IP-adresser for Data Domain allerede har blitt brukt eller endret datadomenekilden eller -målet helt, er den eneste måten å gå tilbake til regelmessig og konsekvent VSR-optimalisering på, å tvinge en ny fullstendig sikkerhetskopi av de berørte VIRTUELLE-ene til å tilbakestille den endrede blokksporingen og gjenopprette VSR-optimaliseringen. Dette bør vurderes når de foregående trinnene er fullført, men Data Domain- og/eller NetWorker-logging, i tillegg til kloningshastigheter, indikerer at ytelsesproblemene blir værende.