NetWorker: Problemas de desempenho do trabalho de clone do vProxy no modo de capacidade entre Data Domains

• A velocidade de clonagem do vProxy caiu de GBs/s para velocidades mais convencionais e realistas.
• A largura de banda da rede é descartada como causa do gargalo, permanecendo bem abaixo do limite durante a clonagem.
• As mensagens são encontradas no ddfs.Logs de informações referentes a um ou mais logs de informações referentes a um ou mais *-flat.vmdk arquivos para os discos de máquina virtual (VM) afetados contendo:
  • synthesized_vbytes 0 e terminando com recipe_repl FALSE
  • srepl_filecopy_recipe_validate_bf: srepl_get_replica_attr para o arquivo base e terminando com o erro Identificador de arquivo está obsoleto.
• Mensagens encontradas nos logs de ação de clonagem (quando o nível de depuração do clone é 3 ou superior) referentes a um ou mais arquivos *-flat.vmdk dos discos da VM afetada contendo:
  • Não é possível usar a replicação sintética para o arquivo... caminho.../vm-vmnumber-disk-key-disknumber-flat.vmdk

O vProxy usa sintéticos virtuais para aproveitar a API de rastreamento de blocos alterados da VMware, proporcionando enormes ganhos para operações de backup e clonagem. Isso requer a manutenção ativa de associações internas da hereditariedade do conjunto de arquivos da VM em cada Data Domain envolvido. Se surgirem problemas durante a preparação para clonar usando sintéticos virtuais, o NetWorker e o Data Domain farão failback usando o fluxo de trabalho de replicação padrão. Isso requer o processamento de todos os arquivos de disco virtual, em vez de apenas dos blocos alterados, em vez de apenas os blocos alterados fornecidos pela API do VMware. Mesmo que poucos dados sejam enviados devido à desduplicação, a duração do trabalho de clonagem pode aumentar em múltiplos.
 
As causas que podem levar à falha do rastreamento sintético virtual incluem:

• Endereços IP diferentes que são resolvidos no NetWorker para os dispositivos Data Domain de origem ou destino entre os trabalhos. Eles devem permanecer consistentes para o rastreamento interno dos sintéticos virtuais
• Alterando o Data Domain de origem ou destino para backups ou clones do vProxy
• Vários volumes de origem ou destino para os backups ou clones do vProxy, o que pode levar à clonagem simultânea de vários savesets na cadeia
• Mais de um saveset do vProxy que exige clonagem para uma determinada VM, o que pode levar à clonagem desordenada de savesets na cadeia
• Discos de VM que passam por longos períodos sem alterações (especificamente, períodos que excedem os períodos de retenção do saveset, como 35 dias sem alteração em que a retenção é de 30 dias)
• Falha ao usar a propriedade ChronologicalOrder Action

Como há várias causas potenciais, analise as configurações do Data Domain e do NetWorker e certifique-se de:

• ifgroups são configurados corretamente para os Data Domains de origem (backup) e destino (destino do clone)
• O servidor do NetWorker, os nós de armazenamento e os Data Domains têm entradas de arquivo de hosts usando as ifgroup IPs por Data Domain e DNS confiável para clients (usando arquivos de hosts de client do NetWorker conforme necessário).
• Data Domain único para cada pool de backup e clone.

Habilite o recurso ChronologicalOrder para ações de clone do saveset do vProxy, que podem estar ocultas na interface do usuário:

• Se estiver usando nsrclone , use o comando -O Alterne para impor esse novo recurso ao usar uma lista de savesets com vários savesets na cadeia de um determinado client
• Para habilitar o na política, use um dos dois comandos a seguir:

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

• No prompt nsradmin:

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

update Chronological order: Yes

• Depois que isso for concluído, as restrições mencionadas anteriormente em volumes únicos de origem e destino, bem como incrementais de várias instâncias por client de VM, serão removidas e poderão ser processadas adequadamente.

IMPORTANTE: Algumas condições podem ser possíveis para que o NetWorker e o Data Domain se recuperem, de onde os savesets são clonados fora de ordem. Isso faz com que alguns não consigam usar o VSR para replicação, mas depois que toda a cadeia for restaurada, a clonagem do VSR poderá prosseguir sem problemas. Geralmente, a clonagem fora de ordem, de vários volumes e de vários savesets pode recuperar o atraso e retornar à operação normal.
 
No caso de vários endereços IP do Data Domain já terem sido usados ou de alterarem totalmente a origem ou o destino do Data Domain, a única maneira de retornar à otimização regular e consistente do VSR é forçar um novo backup completo das VMs afetadas para redefinir o rastreamento de blocos alterados e restaurar a otimização do VSR. Isso deve ser considerado quando as etapas anteriores tiverem sido concluídas, mas o log do Data Domain e/ou NetWorker e as velocidades de clonagem indicam que os problemas de desempenho permanecem.