NetWorker: Problemi di prestazioni del 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.
• La larghezza di banda della rete viene esclusa come causa del collo di bottiglia, rimanendo ben al di sotto della soglia durante la clonazione.
• I messaggi sono stati trovati in ddfs.log informativi riferiti a uno o più *-flat.vmdk file per i dischi della macchina virtuale (VM) interessati contenenti:
  • synthesized_vbytes 0 e finendo con recipe_repl FALSE
  • srepl_filecopy_recipe_validate_bf: srepl_get_replica_attr per il file di base e termina con l'errore L'handle del file non è aggiornato.
• Messaggi trovati nei log delle azioni di clonazione (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 interessata contenenti:
  • Impossibile utilizzare la replica sintetica per il file... percorso.../vm-vmnumber-disk-key-disknumber-flat.vmdk

vProxy utilizza supporti sintetici virtuali per sfruttare l'API Changed Block Tracking di VMware, fornendo enormi vantaggi sia per le operazioni di backup che di clonazione. Ciò richiede la manutenzione attiva delle associazioni interne dell'ereditarietà del fileset di VM in ogni Data Domain coinvolto. Se si verificano problemi durante la preparazione della clonazione utilizzando supporti sintetici virtuali, NetWorker e Data Domain eseguono invece il failback utilizzando il flusso di lavoro di replica predefinito. Ciò richiede l'elaborazione di tutti i file del disco virtuale, anziché solo dei blocchi modificati, a differenza dei soli blocchi modificati forniti dall'API VMware. Anche se alla fine vengono inviati pochi dati a causa della deduplica, la durata del processo di clonazione può aumentare di diversi tipi.
 
Le cause che possono causare l'errore del tracciamento sintetico virtuale includono:

• Indirizzi IP diversi risolti in NetWorker per i dispositivi Data Domain di origine o di destinazione tra un job e l'altro. Questi devono rimanere coerenti per il tracciamento interno dei sintetici virtuali
• Modifica del Data Domain di origine o di destinazione per i backup o i cloni di vProxy
• Più volumi di origine o di destinazione per i backup o i cloni di vProxy, che possono causare la clonazione simultanea di più saveset nella catena
• Più saveset vProxy che richiedono la clonazione per una determinata VM, il che può causare la clonazione disordinata dei saveset nella catena
• Dischi di VM che rimangono per lunghi periodi senza alcuna modifica (in particolare, i periodi che superano i periodi di retention dei saveset, ad esempio 35 giorni senza modifiche dove la conservazione è di 30 giorni)
• Mancato utilizzo della proprietà ChronologicalOrder Action

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

• ifgroups siano impostati correttamente sia per i Data Domain di origine (backup) che per quelli di destinazione (destinazione del clone)
• Il server NetWorker, gli storage node e i Data Domain dispongono tutti di voci di file host che utilizzano il file ifgroup IP per Data Domain e DNS affidabile per i client (utilizzando i file host del client NetWorker in base alle esigenze).
• Data Domain singolo per ogni pool di backup e clonazione.

Abilitare la funzionalità ChronologicalOrder per le azioni di clonazione del saveset vProxy, che potrebbero essere nascoste nell'interfaccia utente:

• Se si utilizza nsrclone , utilizzare il comando -O Cambiare per applicare questa nuova funzione quando si usa un elenco di saveset con più saveset nella catena di un client
• Per l'abilitazione nella policy, utilizzare uno dei due comandi seguenti:

nsrpolicy action update clone -p policyname -w workflowname -A actionname [--chronological_order | -l] <yes|no>

• 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 singoli volumi di origine e destinazione, nonché gli incrementali a più istanze per client VM, vengono rimosse e possono essere elaborate correttamente.

IMPORTANTE: Potrebbero essere possibili alcune condizioni da cui NetWorker e Data Domain possono eseguire il ripristino, in cui i saveset vengono clonati in modo non ordinato. Per questo motivo, alcuni non sono in grado di utilizzare VSR per la replica, ma una volta ripristinata l'intera catena, la clonazione VSR procede senza problemi. In genere, la clonazione non ordinata, la clonazione di più volumi e di più saveset può recuperare il ritardo e riprendere il normale funzionamento.
 
Nel caso in cui siano già stati utilizzati più indirizzi IP di Data Domain o modifichino 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 blocchi modificati e ripristinare l'ottimizzazione VSR. Questa operazione deve essere presa in considerazione al completamento dei passaggi precedenti, ma la velocità di registrazione e clonazione di Data Domain e/o NetWorker indica che permangono problemi di prestazioni.