NetWorker: Problemi relativi alle prestazioni dei job di clonazione vProxy in modalità capacità tra Data Domain

• La velocità di clonazione di vProxy è scesa da GB/sec a velocità più convenzionali e realistiche.
• Larghezza di banda della rete esclusa come causa del collo di bottiglia, rimanendo ben al di sotto della soglia durante la clonazione.
• I messaggi sono disponibili in ddfs.log di informazioni che fanno riferimento a uno o più file *-flat.vmdk per i dischi della VM interessati contenenti:
  • synthesized_vbytes 0 e termina con recipe_repl FALSE
  • srepl_filecopy_recipe_validate_bf: srepl_get_replica_attr per il file di base e termina con l'errore Handle di file non è supportato.
• Messaggi trovati nei log delle azioni clone (quando il livello di debug del clone è 3 o superiore) che fanno riferimento a uno o più file *-flat.vmdk per i dischi della VM interessati contenenti:
  • La replica sintetica non può essere utilizzata per il file in corso... percorso.../vm-vmnumber-disk-key-disknumber-flat.vmdk

vProxy utilizza sintetici virtuali per sfruttare l'API changed block tracking di VMware, fornendo enormi vantaggi sia per le operazioni di backup che per le operazioni di clonazione. Ciò richiede la manutenzione attiva delle associazioni interne di fileset delle VM su ciascun Data Domain coinvolto. Se si verificano problemi durante la preparazione alla clonazione utilizzando sintetici virtuali, NetWorker e Data Domain non riescono a utilizzare il workflow di replica predefinito. Ciò richiede l'elaborazione dell'intero file del disco virtuale, anziché solo dei block modificati, a differenza dei soli block modificati forniti dall'API VMware e, anche se in ultima analisi vengono inviati piccoli dati a causa della deduplica, la durata del job di clonazione può aumentare di multipli.
 
Le cause che possono causare il guasto del rilevamento sintetico virtuale includono:

• Diversi indirizzi IP risolti da NetWorker per i dispositivi Data Domain di origine o di destinazione tra i job devono rimanere coerenti per il rilevamento interno dei sintetici virtuali
• Modifica del Data Domain di origine o di destinazione per i backup o i cloni vProxy
• Più volumi di origine o di destinazione per i backup o i cloni vProxy, che possono portare alla clonazione simultanea di più saveset nella catena
• Più di un saveset vProxy che richiede la clonazione per una determinata VM, il che può portare alla clonazione sconsigliata di saveset nella catena
• Dischi di VM che durano per lunghi periodi senza modifiche (in particolare, periodi che superano i periodi di retention del saveset, ad esempio 35 giorni senza modifiche, dove la retention è di 30 giorni)
• Impossibile utilizzare la proprietà ChronologicalOrder Action, se si utilizza NetWorker 19.6 e versioni successive

Poiché esistono numerose cause potenziali, esaminare le configurazioni di Data Domain e NetWorker e assicurarsi di:

• ifgroups sono configurati correttamente sia per i data domain di origine (backup) che per la destinazione (destinazione del clone)
• Il server NetWorker, gli storage node e i Data Domain dispongono tutti di voci di file host che utilizzano gli IP ifgroup appropriati per Data Domain e DNS affidabile per i client (utilizzando i file host del client NetWorker in caso di necessità).
• Singolo Data Domain per ogni pool di backup e clone.

Quando si utilizza NetWorker 19.5 o versione successiva:

• Assicurarsi che i processi di clonazione vengano eseguiti in modo seriale e nell'ordine dei backup; Nota: questo non può essere controllato quando più cloni per una determinata VM sono nello stesso elenco di job (clone Action o nsrclone saveset file list).
• Garantire un singolo volume di backup e clonazione per pool, per evitare la clonazione simultanea quando sono disponibili più volumi per l'origine.

A partire da NetWorker 19.6, è sempre necessario abilitare la funzione ChronologicalOrder per le azioni di clonazione del saveset vProxy, che potrebbero essere nascoste nell'interfaccia utente:

• Se si utilizza il comando nsrclone, utilizzare l'opzione -O per applicare questa nuova funzione quando si utilizza un elenco di saveset con più saveset in una determinata catena di client
• Per abilitare nel criterio, utilizzare uno dei due comandi seguenti:

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

  • Nel prompt nsradmin:

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

    • update Chronological order: Yes

      
       
• Una volta completata questa operazione, le restrizioni menzionate in precedenza sui volumi di origine e destinazione, nonché i incrementali multi-istanza per ogni client VM, vengono rimosse e possono essere elaborate correttamente.

IMPORTANTE: Alcune condizioni potrebbero essere possibili per il ripristino di NetWorker e Data Domain, da cui i saveset vengono clonati in modo non ordinato. Ciò impedisce ad alcuni di utilizzare VSR per la replica, ma una volta ripristinata l'intera catena, la clonazione di VSR potrebbe procedere senza problemi. In genere, la clonazione out-of-order, la clonazione multi-volume e multi-saveset possono recuperare terreno e tornare a un'operazione regolare.
 
Tuttavia, nel caso in cui più indirizzi IP Data Domain siano già stati utilizzati o abbiano modificato completamente l'origine o la destinazione di Data Domain, l'unico modo per tornare a un'ottimizzazione VSR regolare e coerente consiste nel forzare un nuovo backup completo delle VM interessate per reimpostare il tracciamento dei block modificato e ripristinare l'ottimizzazione VSR. Questo aspetto deve essere considerato quando sono stati completati i passaggi precedenti, ma il logging di Data Domain e/o NetWorker, nonché la velocità di clonazione, indicano che rimangono problemi di prestazioni.