Avamar: Um par de replicação mostra diferentes níveis de uso da capacidade. Como investigar as causas.

Causas e possíveis razões para as diferenças entre os valores de "utilização do servidor":

Diferenças lógicas ou físicas entre as grades:

• Número diferente de nós de dados nas grades de origem e destino.
• Os nós de dados de cada grade têm diferentes configurações de disco.
• Distribuição adequadamente equilibrada de faixas entre os nós de dados dentro de cada sistema (com uma margem de 2%)
• Os requisitos de armazenamento e paridade diferem entre as versões do Avamar. Uma diferença no uso pode ser observada se as versões de software de origem e de destino forem diferentes.
• O nível de disco somente leitura do Avamar Server pode ser diferente entre as duas grades.   
• Uma grade pode estar configurada para paridade RAIN, a outra não.

Configuração de replicação:

• Os backups replicados no sistema de destino podem ter uma política de retenção diferente em comparação com a origem. Analise o indicador expiredelta para obter mais informações. Como alternativa, os backups replicados podem abranger apenas um período específico. Por exemplo, as últimas 4 semanas de backups da origem.
• A replicação pode ser configurada para replicar apenas um subconjunto de clients do sistema de origem para o sistema de destino. Verifique se as configurações "include" ou "exclude" são usadas.
• Os clients e seus backups associados podem ter sido excluídos do sistema de origem. A exclusão de um client ou de backups na origem não remove os mesmos backups do sistema de destino. Os backups permanecem no destino até que expirem de acordo com suas configurações de retenção.
• As políticas de retenção podem ser alteradas para backups ou clients no sistema de origem. A alteração nas políticas de retenção afeta somente os novos backups. Novos backups são replicados para o destino e aderem à política de retenção atualizada. Os backups já existentes no destino mantêm a política de retenção que foi aplicada a eles quando foram replicados.

Atividade anterior de gerenciamento de capacidade:

• Não é incomum que os clientes percebam que um dos sistemas do par de replicação do Avamar está se aproximando da capacidade e, em seguida, ajam para reduzir a capacidade. Lembre-se: um par de replicação do Avamar consiste em dois sistemas gerenciados de maneira independente. Se as ações são realizadas em um sistema, elas também devem ser realizadas no outro. 
• Se os backups forem excluídos ou as retenções reduzidas no sistema de origem, alterações idênticas deverão ser feitas no destino. A melhor maneira de gerenciar a capacidade é com o script modify-snapups. Ele pode ser executado nos dois Avamar Servers com as mesmas opções de modificação ou exclusão de backup.  

Estrutura de faixas diferente (por exemplo, mais faixas de paridade em um sistema):

• Por serem independentes, dois sistemas Avamar podem acabar com estruturas de faixas diferentes. Os sistemas de vários nós podem apresentar diferenças devido ao uso de faixas de paridade para proteger os dados. Dependendo do histórico de capacidade, dois sistemas de vários nós contêm os mesmos backups, mas um pode ter um número maior de frações de paridade do que o outro.
• Assim como as faixas regulares, uma vez criadas, uma faixa de paridade sempre permanece no sistema. Ao contrário das faixas regulares, ela sempre consome uma quantidade fixa de espaço no Avamar Server. Isso ocorre mesmo que as faixas seguras do grupo de paridade não contenham dados. A coleta de lixo não afeta esse comportamento.
• Um sistema de destino de replicação é protegido indiretamente contra grandes problemas de capacidade em uma origem de replicação. No entanto, a situação poderá ocorrer em qualquer uma das máquinas se uma delas for mal gerenciada do ponto de vista da capacidade.
• Artigo relacionado: O Avamar mostra até 30% de uso, mesmo depois que todos os backups foram excluídos e o lixo foi coletado

Backups ainda em MC_DELETED:

• Um cenário raro a ser observado é quando um client é excluído na origem, mas seus backups são mantidos. Isso pode fazer com que a origem tenha uma utilização maior do que o destino em que se espera que os backups expirem naturalmente. O uso do script dump_root_hashes.rb com a opção backupcompare ajuda a verificar esse cenário.

Dados no sistema de destino de backups não replicados:

• Se o sistema replicar em "apenas uma direção", verifique no destino se não existem clients fora de /REPLICATE e MC_SYSTEM.

Outros comportamentos:

• Os trabalhos de replicação podem não ser concluídos de maneira confiável. Os dados enviados para o destino podem "atrasar" a origem em vários dias.
• Os dois sistemas contêm a mesma quantidade de dados desduplicados, mas a quantidade de sobrecarga de paridade em cada um deles é diferente. Isso ocorre no seguinte cenário: 
  • Um sistema de origem do Avamar está quase cheio. 
  • Muitos backups são excluídos do sistema de origem para reduzir seu nível de capacidade. 
  • A replicação dos dados desduplicados ocorre da origem para o destino. 
  • O volume de dados desduplicados é o mesmo nos dois sistemas.
  • Inicialmente, o sistema de origem armazena mais sobrecarga de paridade do que o destino.
• A replicação não copia as faixas físicas da grade de origem para a de destino. Em vez disso, a grade de destino tem permissão para determinar por si mesma onde as faixas e os fragmentos de dados são armazenados.
• Às vezes, os sistemas Avamar de destino podem armazenar dados com mais eficiência do que uma grade de origem em que os dados são originalmente armazenados em backup.

Entenda o ambiente de replicação:

• Anote o nome de host completo da grade do Avamar de origem.
• Examine a configuração de replicação dos sistemas afetados para entender quais sistemas replicam quais dados e para onde. 
  • Pode ser útil desenhar um esquema se o ambiente for algo mais complicado do que a replicação de um Avamar Server para outro.
• Se a origem se integrar ao Data Domain (DD), saiba se a preocupação do cliente está relacionada a backups replicados entre dispositivos DD.
• Anote o nome de host completo da grade do Avamar de destino e todos os dispositivos DD associados que recebem backups replicados.

Verifique a integridade geral e a situação da grade:

• Execute o script de verificação proativo nas duas grades e obtenha uma cópia do hc_results.txt e revise para entender a situação geral do sistema. 

Qual é a gravidade do diferencial de capacidade?

• O cliente deve apresentar uma captura de tela mostrando o que está vendo, o que o leva a acreditar que há um diferencial de consumo de capacidade entre a origem e o destino.
• Não consideraríamos que haja motivo de alarme se a diferença de capacidade for menor que 5%.
• Verifique a interface do usuário do Avamar Administrator para entender os níveis de capacidade do Avamar Server e (se o Data Domain estiver integrado) a capacidade de metadados.
• Esteja ciente de como a exibição de capacidade da interface do usuário funciona (discutido em: O painel de indicadores da interface do usuário do Avamar na versão 7.2 e posteriores mostra a utilização de metadados em vez da utilização do Avamar).
• Execute o seguinte comando em ambos os sistemas. O valor de utilização do servidor fornece um valor geral dos níveis de capacidade do Avamar Server (mas não do Data Domain):

admin@utility:~/>: mccli server show-prop | grep "utilization"

Server utilization               3.7%

Verifique se o hardware é o mesmo nas duas grades:

• Só faz sentido comparar as diferenças de capacidade para sistemas "similares". 
• Usando a saída de verificação proativa, anote o tipo de nós presentes no sistema.
• O comando a seguir mostra um número geral, o tamanho e o consumo de espaço nos nós físicos:

admin@utility:~/>: mccli server show-prop | grep "Capacity\|capacity\|nodes"

Total capacity                   23.3 TB
Capacity used                    858.5 GB
Number of nodes                  3

• Esse resultado facilita a determinação do número e do tamanho dos nós no sistema. Eles são (23,3 / 3 = ~7,8 TB). 
• O número e o tamanho das partições de disco rígido em cada nó devem corroborar isso.

admin@utility:~/>: mapall 'df -h' | grep data

(0.0) ssh -q  -x  -o GSSAPIAuthentication=no admin@192.168.255.2 'df -h'
/dev/sda3       1.8T   55G  1.8T   4% /data01
/dev/sdb1       1.9T   54G  1.8T   3% /data02
/dev/sdc1       1.9T   53G  1.8T   3% /data03
/dev/sdd1       1.9T   53G  1.8T   3% /data04
/dev/sde1       1.9T   52G  1.8T   3% /data05
/dev/sdf1       1.9T   52G  1.8T   3% /data06
(0.1) ssh -q  -x  -o GSSAPIAuthentication=no admin@192.168.255.3 'df -h'
/dev/sda3       1.8T   56G  1.8T   4% /data01
/dev/sdb1       1.9T   53G  1.8T   3% /data02
/dev/sdc1       1.9T   52G  1.8T   3% /data03
/dev/sdd1       1.9T   52G  1.8T   3% /data04
/dev/sde1       1.9T   53G  1.8T   3% /data05
/dev/sdf1       1.9T   53G  1.8T   3% /data06
(0.2) ssh -q  -x  -o GSSAPIAuthentication=no admin@192.168.255.4 'df -h'
/dev/sda3       1.8T   55G  1.8T   4% /data01
/dev/sdb1       1.9T   53G  1.8T   3% /data02
/dev/sdc1       1.9T   53G  1.8T   3% /data03
/dev/sdd1       1.9T   52G  1.8T   3% /data04
/dev/sde1       1.9T   53G  1.8T   3% /data05
/dev/sdf1       1.9T   52G  1.8T   3% /data06

• Com essas informações, verifique o seguinte:

Verifique a versão e a configuração do software:

• Usando o resultado do comando status.dpn, compare a versão do Avamar em execução em cada sistema.
• Para sistemas de vários nós, confirme se ambos estão configurados com paridade RAIN de acordo com Avamar — como determinar se um servidor é RAIN ou não RAIN
• Verifique e compare os parâmetros de configuração do Avamar Server relacionados à capacidade dos dois sistemas. Por exemplo:

admin@utility:~/>: avmaint config --ava | grep -i "capacity\|disk"

  disknocreate="90"
  disknocp="96"
  disknogc="85"
  disknoflush="94"
  diskwarning="50"
  diskreadonly="65"
  disknormaldelta="2"
  freespaceunbalancedisk0="20"
  diskfull="30"
  diskfulldelta="5"
  balancelocaldisks="false"

Verifique o balanceamento de faixas:

• Verifique o resultado de status.dpn e observe o número total de frações em cada nó de dados. O número de frações é identificado entre colchetes (por exemplo, onl:xxx). 
• Deve haver menos de 2% de diferença entre o número total de frações em cada nó de dados.  

Verifique se a coleta de lixo está sendo executada corretamente nos dois sistemas:

• Se a coleta de lixo não estiver sendo executada de forma consistente e eficaz, ela não removerá os dados expirados. O sistema relata um uso de capacidade maior do que o esperado. 
  • Consulte o artigo Caminho de resolução do GC nas notas restritas para obter informações.  

Confirme que as replicações estejam sendo concluídas com sucesso:

• Certifique-se de que todas as tarefas de replicação da origem ao destino sejam concluídas com sucesso. Se isso não estiver acontecendo, pode ser que ainda haja dados a serem replicados da origem para o destino.  

Verifique a configuração de replicação:

• Verifique a configuração de replicação (na IU, na CLI ou nos logs) para qualquer um dos seguintes indicadores:  

--before
--after
--include
--exclude

--expiredelta

--retention-types

--retention-types=none,daily,weekly,monthly,yearly

Verifique as taxas de ingestão e remoção de dados de ambos os sistemas:

• Execute proactive_check.pl --capacity em ambos os sistemas e compare as taxas de ingestão dos sistemas de origem e de destino.
• Se o destino for puramente um sistema de destino e receber TODOS os backups da origem, sua taxa de ingestão deverá acompanhar de perto a taxa de ingestão da origem.
• As colunas Avamar NEW ou DDR NEW mostram o volume de novos dados que estão sendo adicionados a esses sistemas.
• Também preste muita atenção nas colunas "Removed", "Mins" e "Pass" para entender o comportamento da coleta de lixo em ambos os sistemas.
• Essas informações dão uma visão clara do que está acontecendo em ambos os sistemas.
• Para obter mais informações sobre a interpretação do resultado, consulte Avamar: Como gerenciar a capacidade com o script capacity.sh  

Descartar uma lista de backups existentes em cada sistema:

• O script dump_root_hashes.rb é um utilitário que ajuda a comparar a diferença nos backups armazenados entre um sistema de origem e um de destino do Avamar. Isso ocorre mesmo se os backups estiverem hospedados no armazenamento do Data Domain.   
• Consulte Avamar: Avamar: Como usar o script dump_root_hashes.rb para gerar uma lista de clients e backups para obter informações sobre como fazer download do utilitário e casos de uso, inclusive comparando o conteúdo de dois sistemas Avamar.
  • Execute a ferramenta. Verifique se há inconsistências nas contagens dos backups em todos os clients. Preste atenção às diferenças de +/- 2).  
• Conforme discutido na seção Causas, o gerenciamento assimétrico da capacidade resulta em diferenças entre os dois sistemas. Analise o resultado para determinar se esse pode ser o cenário.
• Também:
  • Verifique o destino para obter dados no sistema de destino de backups não replicados.
  • Verifique a origem para obter os dados que não foram replicados para o destino.  

Verifique se há estruturas de faixas diferentes (por exemplo, mais faixas de paridade em um sistema):

• Por serem independentes, dois sistemas Avamar podem ter estruturas de faixas diferentes. Os sistemas de vários nós podem apresentar diferenças devido ao uso de faixas de paridade para proteger os dados. Dependendo do histórico de capacidade, dois sistemas de vários nós contêm os mesmos backups, mas um pode ter um número maior de frações de paridade do que o outro.  
• Assim como as faixas regulares, uma vez criadas, uma faixa de paridade permanece no sistema. Ao contrário das faixas regulares, elas sempre consomem uma quantidade fixa de espaço no Avamar, mesmo que as faixas seguras do grupo de paridade não contenham dados. A coleta de lixo não afeta esse comportamento.
• Um sistema de destino de replicação é protegido indiretamente contra grandes problemas de capacidade em uma origem de replicação. No entanto, a situação poderá ocorrer em qualquer uma das máquinas se uma delas for mal gerenciada do ponto de vista da capacidade.
• Artigo relacionado:  O Avamar mostra até 30% de uso, mesmo depois que todos os backups foram excluídos e o lixo foi coletado  

Backups ainda em MC_DELETED:

• Um cenário raro a ser observado é quando um client foi excluído na origem, mas seus backups foram mantidos. Isso faz com que a origem tenha uma utilização maior do que o destino em que se espera que os backups expirem naturalmente. O uso do script dump_root_hashes.rb com a opção backupcompare deve ajudar a verificar esse cenário.