Avamar: Teoria e comportamento do desempenho de backup

O objetivo deste artigo é descrever o que acontece durante um backup do Avamar com foco em ajudar o leitor a entender o comportamento do desempenho do backup.

Este artigo complementa os seguintes artigos:

• Avamar: Solução de problemas de desempenho lento do backup
• Avamar: Ajustando os backups para serem concluídos rapidamente

O que acontece durante um backup do Avamar?

O processo de backup avtar :

1) Carrega os arquivos e os arquivos de cache de hash na memória

2017-06-09 23:00:25 avtar Info <5586>: Loading cache files from C:\Program Files\avs\var
2017-06-09 23:00:25 avtar Info <8650>: Opening filename cache file 'C:\Program Files\avs\var\f_cache2.dat'
2017-06-09 23:00:25 avtar Info <5573>: - Loaded filename cache file (6,532,792 bytes)
2017-06-09 23:00:26 avtar Info <8650>: Opening hash cache file 'C:\Program Files\avs\var\p_cache.dat'
2017-06-09 23:00:28 avtar Info <5573>: - Loaded hash cache file (402,653,728 bytes)
2017-06-09 23:01:01 avtar Info <6426>: Done loading cache files

2) Cria snapshots do VSS (no Windows):

2017-06-09 23:04:32 avtar Info <19008>: Obtaining available VSS providers
2017-06-09 23:04:32 avtar Info <8776>: Freezing volumes now...
2017-06-09 23:04:32 avtar Info <8780>: Creating the shadow copy set (DoSnapshotSet) ... 
2017-06-09 23:14:33 avtar Info <8781>: Shadow copy set successfully created.
2017-06-09 23:14:34 avtar Info <6074>: VSS snapshot set creation successful

3) Percorre todos os arquivos definidos pelo conjunto de dados Para todos os arquivos dentro do conjunto
de dados de origem, o avtar pega o caminho completo e o combina com os metadados semelhantes a estatísticas para calcular um hash para identificar exclusivamente o arquivo.

Para obter mais detalhes, consulte Avamar: O que acontece quando o avtar lê um arquivo durante a fase de varredura do arquivo.

4) Compare os hashes calculados com os caches

do client local O Avtar procura o hash do arquivo no cache do arquivo. Ele verifica se é novo ou se foi modificado desde o backup anterior.

Se a pesquisa de cache de arquivo for bem-sucedida, o arquivo existe e permanece inalterado.

Se a pesquisa falhar, o arquivo é novo ou foi alterado. Ele deve ser lido e processado.

Para obter mais detalhes, consulte Avamar Client — O que precisa mudar antes de o avtar considerar que um arquivo foi modificado?

5) Processar arquivos

novos e modificados Para qualquer arquivo novo ou modificado, o avtar deve:

• Leia o arquivo inteiro
• Divida-o em fragmentos de tamanho variável
• Compactar cada fragmento
• Calcule um hash para cada fragmento

6) Verifique se hashes ausentes estão presentes no Avamar Server.

O Avtar envia dados de todos os hashes ausentes pela rede para o servidor Avamar para verificar se eles já existem. Essas solicitações são conhecidas como "ispresent".

7) Os dados são gravados no Avamar Server (e, se apropriado, no Data Domain). 

Para obter um fluxo de trabalho mais detalhado, consulte o Avtarprocess.pdf anexo.


Visão geral de um backup do Avamar de uma perspectiva de desempenho:

Seguindo os estágios acima, nós os dividimos em "fases" que têm o maior impacto sobre o desempenho do backup:

Fase 0. Crie snapshots do VSS.

O VSS (Volume Shadowcopy Service, serviço de cópias de sombra de volume) cria snapshots de volumes especificados no conjunto de dados de origem. Os aplicativos podem continuar a gravar no volume enquanto o backup é executado.
O Avamar faz backup do snapshot "congelado" somente leitura do volume, em vez do volume gravável. Isso garante que ele tenha um conjunto consistente de dados para fazer backup.

Os snapshots do VSS levam segundos para serem concluídos. Se um client estiver enfrentando problemas de VSS, isso atrasará ou impedirá que o backup continue.

Fase 1. Fase de varredura de arquivos. O processo avtar cria estatísticas de todos os arquivos no conjunto

de dados de destinoPara clientes com milhões de arquivos, essa fase pode ser a mais demorada.
Os dados do banco de dados contêm poucos arquivos maiores, portanto, a fase de varredura de arquivos leva pouco tempo. Os clients de banco de dados normalmente consomem seu tempo durante a fase #2.

Para um client com discos rotativos na configuração RAID 5, o desempenho típico da varredura de arquivos de ~1 milhão de arquivos por hora. Isso varia de 300 mil a 3 milhões por hora. Isso depende do ambiente do client e das características dos dados que estão sendo submetidos a backup.

A partir da versão 7.3, os clients Linux que fazem backup no Data Domain podem aproveitar a funcionalidade de LFI (Fast Incremental, Incremento Rápido) do Linux. Isso evita a varredura de todo o conjunto de dados sempre que o backup é executado.

Recursos essenciais: desempenho de busca aleatória do disco onde os dados de backup estão armazenados.

Fase 2. O Avtar lê os arquivos alterados e, em seguida, fragmenta, compacta e analisa o hash dos dados.

Muitos cálculos ocorrem durante essa fase. Para cada arquivo novo ou modificado, o avtar o divide em pequenos fragmentos. Ele compacta cada bloco e calcula um hash como uma "impressão digital" para identificar o fragmento.

Os arquivos em backups de banco de dados geralmente são grandes e tendem a mudar diariamente. A Avtar passa a maior parte do tempo nessa fase. É melhor usar plug-ins oficiais do banco de dados do Avamar para garantir que o banco de dados seja tratado com eficiência, aproveitando a funcionalidade de backup incremental, registros de transações e assim por diante.

O desempenho típico do processamento de arquivos é de cerca de 100 GB por hora, mas pode variar até 300 GB por hora. Isso depende do ambiente.

Recursos essenciais: Disco e CPU

do client Para backups de LAN em que não há gargalos no envio de dados para o Avamar Server, as fases #1 e #2 levam mais tempo.

No gráfico a seguir, considere que a quantidade de área nas barras do gráfico corresponde ao tempo necessário do backup. Arquivos alterados podem aumentar drasticamente a quantidade de tempo necessária, especialmente se esses arquivos forem grandes.

Para conjuntos de dados do file system, espere que ~0-3% dos arquivos sejam alterados diariamente.

O Avtar deve "stat()" cada arquivo que for alterado executando duas operações de E/S, uma para verificar os atributos do arquivo e outra para os atributos de segurança.

Para alcançar o desempenho da taxa de varredura de referência de ~1 milhão de arquivos/hora para backups do file system, o avtar requer aproximadamente dois milhões de operações de busca por hora ou 600 operações de busca por segundo.

Por exemplo: Se um backup tiver uma taxa de alteração de 3%, 97 de um total de 100 arquivos exigirão operações de busca de dois discos para identificar se eles foram alterados. Os três restantes, que foram alterados, devem ser digitalizados, fragmentados, compactados e hash.

Isso considera apenas a fase de varredura do arquivo e não leva em consideração os recursos de E/S necessários para processar os arquivos que foram modificados.
Quanto mais dados houver nos arquivos modificados, mais trabalho será necessário para concluir o backup.

Fase 3. Verificando a existência de hashes no servidor

AvamarAs fases #1 e #2 produzem hashes que apontam para elementos do backup. Esses elementos podem ser fragmentos de arquivos exclusivos, sistemas de arquivos ou backups inteiros.

Os hashes são gravados nos arquivos de cache do client e comparados com os hashes presentes no servidor Avamar para verificar se é necessário adicionar novos dados. Isso é verdadeiro seja um Avamar Server ou Data Domain o armazenamento de destino.

As comparações de hash entre o Avamar Client e o servidor geralmente são rápidas. Eles não devem afunilar o backup se o Avamar Server for;

• Saudável
• Em níveis de carga regulares
• Localizado no mesmo segmento de LAN que o cliente

Como os hashes têm apenas 20 bytes de tamanho, essa fase é influenciada mais pela latência da rede do que pela largura de banda da rede. Quando o hash chega ao Avamar Server, a carga geral e o desempenho de busca aleatória do subsistema de disco dos nós de dados determinam a rapidez com que o hash é recuperado e comparado com o enviado pelo client.

Recursos essenciais: Tempo de resposta da rede e desempenho de busca aleatória do nó de dados do Avamar.

O desempenho de busca aleatória de um Avamar físico é dimensionado com o número e o tamanho dos nós de dados. Os sistemas AVE têm um desempenho menos bom, comparável a um sistema de único nó.

Fase 4. Enviando o novo fragmento pela rede para o Avamar Server ou Data Domain

Quando um cliente envia um fragmento novo e exclusivo (até 64 KB de tamanho) para o servidor, o desempenho depende principalmente da largura de banda da rede. Isso afeta principalmente os clients baseados em WAN que geram uma grande quantidade de dados alterados todos os dias. Isso também pode afetar aqueles que operam em links de rede congestionados. 

Veja abaixo esquemas que mostram o fluxo de dados em que um client envia dados para um sistema Avamar e para um sistema Avamar - Data Domain integrado.






Recursos essenciais: Largura de banda da rede entre o client e o servidor

Fase 5. Dados gravados no Avamar Server ou Data Domain

Os dados de backup devem ser gravados no Avamar Server ou no sistema Data Domain.

Recursos essenciais: Desempenho de gravação em disco e carregamento geral do Avamar Server.