NetWorker: Capacity Mode vProxy clone job performance problems between Data Domains

• A velocidade de clonagem do vProxy caiu de GBs/s para velocidades mais convencionais e realistas.
• A largura de banda da rede foi descartada como causa do gargalo, permanecendo bem abaixo do limite durante a clonagem.
• As mensagens são encontradas nos ddfs.registros de informações referentes a um ou mais arquivos *-flat.vmdk para os discos da VM afetada que contêm:
  • synthesized_vbytes 0 e terminando com recipe_repl FALSE
  • srepl_filecopy_recipe_validate_bf: srepl_get_replica_attr arquivo base e terminar com o erro Identificador do arquivo está obsoleto.
• Mensagens encontradas nos registros de ação de clonagem (quando o nível de depuração do clone é 3 ou superior) referem-se a um ou mais arquivos *-flat.vmdk para os discos da VM afetada que contêm:
  • A replicação sintética não pode ser usada para o arquivo... path.../vm-vmnumber-disk-key-disknumber-flat.vmdk

O vProxy usa sintéticos virtuais para aproveitar a API de rastreamento de blocos alterados da VMware, fornecendo enormes ganhos para operações de backup e clonagem. Isso requer manutenção ativa de associações internas de heredidade de conjuntos de arquivos de VM em cada Data Domain envolvido. Se surgirem problemas ao se preparar para clonar usando sintéticos virtuais, o NetWorker e o Data Domain, em vez disso, fazer failback para usar o workflow de replicação padrão. Isso exige o processamento de todos os arquivos de disco virtual, em vez de apenas os blocks alterados, em vez de apenas os blocks alterados fornecidos pela API da VMware, e 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:

• Diferentes endereços IP que são resolvidos pelo NetWorker para os dispositivos Data Domain de origem ou destino entre 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 duram longos períodos sem nenhuma alteração (particularmente, 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 CronologicamenteOrder Action se estiver usando o NetWorker 19.6 e versões posteriores

Como há várias causas possíveis, analise as configurações do Data Domain e do NetWorker e garanta:

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

Ao usar o NetWorker 19.5 ou abaixo:

• Certifique-se de que os trabalhos de clonagem sejam executados em série e na ordem dos backups; Observe que isso não pode ser controlado quando vários clones de uma determinada VM estão na mesma lista de trabalhos (clone Action ou nsrclone saveset file list).
• Certifique-se de um só volume de backup e clone por pool para evitar a clonagem simultânea quando vários volumes estão disponíveis para origem.

A partir do NetWorker 19.6, você deve sempre habilitar o recurso CronológicaOrder para ações de clone de saveset vProxy, que podem estar ocultas na interface do usuário:

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

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

  • No prompt nsradmin:

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

    • update Chronological order: Yes

      
       
• Quando isso é concluído, as restrições mencionadas anteriormente em volumes de origem e destino únicos, bem como incrementos de várias instâncias por client de VM, são removidas e podem ser processadas corretamente.

IMPORTANTE: Algumas condições podem ser possíveis para a recuperação do NetWorker e do Data Domain, em que os savesets são clonados fora do pedido. Isso faz com que alguns não possam usar o VSR para replicação, mas depois que toda a cadeia é restaurada, a clonagem do VSR pode continuar sem problemas. Geralmente, a clonagem fora de ordem, a clonagem de vários volumes e de vários savesets pode acompanhar e retornar à operação regular.
 
No entanto, no caso de vários endereços IP do Data Domain já tiverem sido usados ou alterados completamente a origem ou o destino do Data Domain, a única maneira de retornar à otimização de VSR regular e consistente é 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 registro do Data Domain e/ou do NetWorker, bem como as velocidades de clonagem, indicam que os problemas de desempenho permanecem.