Caminho de resolução para problema de GSAN ou capacidade do usuário do Avamar

Para conceitos básicos e entender melhor a capacidade do sistema operacional (SO), consulte Avamar: treinamento geral de capacidade - Caminho de resolução

Muitas vezes, é mais fácil considerar a GSAN capacidade como o espaço e utilização para backups de clients.

• Conhecimento básico da desduplicação
• Conhecimento básico de ponto de verificação, validação de ponto de verificação (hfscheck), coleta de lixo e a importância de cada um.
• A diferença entre GSAN (ou usuário) capacidade e capacidade do sistema operacional
• Taxa de alteração
• Estado estacionário

• Falha de backup ou replicação quando o estado de acesso ao grid é alterado para "modo admin"

  • Uma tarefa de backup de client pode falhar com uma mensagem parecida com esta:  "avtar Info <5314>: Command failed (1 error, exit code 10028: Operation failed because target server is full)"
• A desativação automática do programador de backups (até que alguém reconheça e limpe o alerta)

• 80%: aviso de capacidade
• 95%: o limite de verificação de integridade foi atingido (isso às vezes pode desativar o programador de backups, pelo menos até que seja confirmado manualmente)
• 100%: o limite somente leitura do servidor foi atingido (o grid entra no modo admin)

1. O Avamar só precisa salvar e armazenar as pequenas alterações e diferenças entre cada trabalho de backup do client, justamente por causa da desduplicação. À medida que novos backups (ou replicação de entrada) são executados, eles podem adicionar novos dados e aumentar a capacidade ou o valor de utilização do Avamar. 
2. Após um determinado período, os backups expiram com base na retenção e expiração configuradas e não serão encontrados no grid Avamar disponível para restauração. 
3. Quando o trabalho de manutenção do Avamar chamado Coleta de lixo (GC) é executado, ele identifica todas as partes únicas ou blocos de dados que não são mais necessários devido à expiração desses backups. O GC verifica se nenhum outro backup atual compartilha esses mesmos dados (por causa da desduplicação) e então remove ou libera esses blocos de dados que não são mais necessários, reduzindo a capacidade ou a utilização do Avamar Server.

Quando a quantidade de dados recebidos diariamente adicionados é aproximadamente a mesma que a quantidade de dados diários que está sendo limpa, isso é chamado de "Estado estacionário". Esse é o objetivo de cada grid Avamar instalado.

Para que um novo grid Avamar seja instalado e configurado, são feitos cálculos gerais de dimensionamento de pré-instalação para determinar a capacidade necessária para armazenar os dados de backup. Esses cálculos são baseados nos requisitos de retenção dos clientes e na quantidade de dados para backup. Ele também estima quanto desses dados pode ser desduplicado em média e assim por diante.

1. A Coleta de lixo não está em execução de forma consistente
2. O desempenho da Coleta de lixo está lento ou ela não está em execução por tempo suficiente
3. As estimativas de desduplicação antes da instalação do grid Avamar não eram precisas o suficiente
4. Os dados que não foram calculados antes da instalação do grid Avamar estão sendo copiados para esse Avamar Server.
5. Outros motivos

Confirme se cada etapa de solução de problemas abaixo é verdadeira para o ambiente:

Etapa 1. Coleta de dados:

Certifique-se de que não haja outros problemas de não capacidade com a rede do Avamar. Se houver, eles podem exigir atenção ANTES de solucionar problemas de capacidade.

Por exemplo, erros de hardware, problemas de integridade de dados (incluindo nós off-line), frações off-line, falhas de validação de checkpoint ou trabalhos de manutenção com falha. Se qualquer um desses problemas estiver presente, a solução de problemas de capacidade deve ser interrompida e outros problemas devem ser tratados. Depois que outros problemas forem resolvidos, a capacidade poderá ser retomada.

Uma verificação de integridade deve ser executada (Avamar: como executar o script de verificação de integridade proactive_check.pl em um Avamar Server, mas, no mínimo, status.dpn o comando pode fornecer uma visão geral rápida e a verificação da maioria desses mesmos problemas. Consulte Avamar: Como entender a saída gerada pelo comando "status.dpn"

Consulte os seguintes artigos para obter mais informações: Avamar: Como aplicar a abordagem "hierarquia de solução de problemas do Avamar" corretamente.

Se for necessária assistência para resolver quaisquer problemas que não são de capacidade, crie um chamado com a equipe de suporte do Avamar da Dell Technologies.

Etapa 2. Coleta de informações de capacidade: 

Consulte o material a seguir para obter todas as informações necessárias para solucionar problemas de capacidade do Avamar: Avamar: como coletar as informações para solucionar problemas de capacidade

Pelo menos, o comando status.dpn ou os valores na interface do Avamar Administration mostram a GSAN capacidade.

Etapa 3. Verificar se a capacidade do sistema operacional está cheia:

O comando a seguir ajuda a mostrar o valor atual da capacidade do sistema operacional para cada partição de disco. Se qualquer um dos valores tiver atingido ou excedido 85%, como na segunda saída de amostra, isso será considerado alta capacidade do sistema operacional:

avmaint nodelist | egrep 'nodetag|fs-percent-full'

Exemplos de resultados:

nodetag="0.2"
        fs-percent-full="56.6"
        fs-percent-full="54.7"
        fs-percent-full="54.4"
        fs-percent-full="54.6"
        fs-percent-full="54.7"
        fs-percent-full="54.7"
      nodetag="0.1"
        fs-percent-full="56.2"
        fs-percent-full="54.6"
        fs-percent-full="54.6"
        fs-percent-full="54.8"
        fs-percent-full="54.8"
        fs-percent-full="54.5"
      nodetag="0.0"
        fs-percent-full="56.2"
        fs-percent-full="54.7"
        fs-percent-full="54.8"
        fs-percent-full="54.7"
        fs-percent-full="54.6"
        fs-percent-full="54.6"

nodetag="0.2"
        fs-percent-full="94.5"
        fs-percent-full="94.4"
        fs-percent-full="94.2"
        fs-percent-full="94.1"
        fs-percent-full="94.0"
        fs-percent-full="94.0"
      nodetag="0.1"
        fs-percent-full="94.5"
        fs-percent-full="94.3"
        fs-percent-full="94.1"
        fs-percent-full="93.6"
        fs-percent-full="94.0"
        fs-percent-full="93.9"
      nodetag="0.0"
        fs-percent-full="94.4"
        fs-percent-full="94.4"
        fs-percent-full="94.0"
        fs-percent-full="94.1"
        fs-percent-full="92.7"
        fs-percent-full="92.5"

Somente se a capacidade do sistema operacional estiver abaixo de 85% é que a GSAN solução de problemas de capacidade deve continuar. 

Etapa 4. Problemas que não são de capacidade e que às vezes podem ser interpretados incorretamente como problemas de capacidade:

É possível que os backups de clients falhem não por motivos de "capacidade", mas sim por motivos de "cota". Às vezes, podem ser interpretados incorretamente como um problema de capacidade.

Essa situação pode ser confirmada pelo status.dpn comando ou por algum dos outros resultados coletados mostrando baixa capacidade.

Além disso, é possível que os backups do client tenham falhado ou não tenham sido executados por outros motivos Non-GSAN não relacionados à capacidade. As informações coletadas devem confirmar isso ou também podem ser vistas na IU do Avamar Administration.

• Avamar: caminho de resolução para problemas de capacidade de metadados
• Data Domain: caminho de resolução para problemas de alta capacidade decorrente da integração com o Avamar

Se a GSAN A capacidade estiver alta e essas outras capacidades também estiverem altas, a solução de problemas pode ser realizada em qualquer ordem (exceto para a capacidade do sistema operacional, que deve ser sempre ser tratada primeiro).

Etapa 5. Equilíbrio de faixas e balanceamento de disco do sistema operacional:

As "faixas" no Avamar são os arquivos de contêiner nos quais os dados de backup são armazenados nos nós de dados (exceto em um grid Avamar de nó único).

A expectativa é que as faixas sejam "equilibradas" ou distribuídas uniformemente entre os diferentes discos e nós dentro da rede, mas às vezes elas podem se tornar desequilibradas.

No Avamar, por padrão, o maior nó ou partição de disco é o fator limitante quando se trata da capacidade do Avamar.

Isso é intencional para que nenhum dos discos ou nós criem mais faixas do que conseguem (ou podem) acomodar. Portanto, ter faixas equilibradas é importante para a capacidade.

Por exemplo, ao adicionar nós de dados adicionais para a expansão do grid Avamar, o balanceamento deve ser executado para distribuir uniformemente as faixas para os novos nós e diminuir a porcentagem de capacidade geral do Avamar.

Outro tipo de balanceamento que exige compreensão é o balanceamento de discos do sistema operacional. Ele se limita apenas às partições de dados dentro do mesmo nó, não a partições em vários nós. 

Se, em um mesmo nó de dados, uma partição for significativamente maior ou menor do que outra partição do MESMO nó, pode-se exceder um limite chamado"freespaceunbalance". Embora isso geralmente ocorra no sistema operacional e não na GSAN capacidade, poderá ser relatado como um GSAN problema de capacidade.

Etapa 6. Verificar se a coleta de lixo está sendo concluída: 

Execute o seguinte comando para obter informações sobre a coleta de lixo:

dumpmaintlogs --types=gc --days=30 | grep "4201\|2402"

O ideal é que o resultado mostre que a GC foi concluída nos últimos 30 dias:

2025/10/07-12:00:35.24911 {0.1} <4201> completed garbage collection
2025/10/08-12:00:34.61185 {0.1} <4201> completed garbage collection
2025/10/09-12:00:35.14874 {0.1} <4201> completed garbage collection
2025/10/10-12:00:34.67986 {0.1} <4201> completed garbage collection
2025/10/11-12:00:34.73284 {0.1} <4201> completed garbage collection
2025/10/12-12:00:33.23205 {0.1} <4201> completed garbage collection
2025/10/13-12:00:33.41448 {0.1} <4201> completed garbage collection
2025/10/14-12:00:35.70726 {0.1} <4201> completed garbage collection
2025/10/15-12:00:35.08316 {0.1} <4201> completed garbage collection
2025/10/16-12:00:34.82681 {0.1} <4201> completed garbage collection
2025/10/17-12:00:35.29262 {0.1} <4201> completed garbage collection
2025/10/18-12:00:35.24618 {0.1} <4201> completed garbage collection
2025/10/19-12:00:34.56531 {0.1} <4201> completed garbage collection
2025/10/20-19:06:45.15574 {0.1} <4201> completed garbage collection
2025/10/21-12:00:34.21062 {0.1} <4201> completed garbage collection
2025/10/22-12:00:35.29770 {0.1} <4201> completed garbage collection
2025/10/23-12:00:36.13041 {0.1} <4201> completed garbage collection
2025/10/24-12:00:35.52502 {0.1} <4201> completed garbage collection
2025/10/25-12:00:35.93730 {0.1} <4201> completed garbage collection
2025/10/26-12:00:35.55037 {0.1} <4201> completed garbage collection
2025/10/27-12:00:36.12049 {0.1} <4201> completed garbage collection
2025/10/28-12:00:35.75633 {0.1} <4201> completed garbage collection
2025/10/29-12:00:34.85499 {0.1} <4201> completed garbage collection
2025/10/30-12:00:34.96325 {0.2} <4201> completed garbage collection
2025/10/31-12:00:35.39840 {0.0} <4201> completed garbage collection
2025/11/01-12:00:35.11248 {0.0} <4201> completed garbage collection
2025/11/02-13:00:34.39202 {0.0} <4201> completed garbage collection
2025/11/03-13:00:34.70587 {0.0} <4201> completed garbage collection
2025/11/04-13:00:34.18799 {0.0} <4201> completed garbage collection
2025/11/05-13:00:34.44950 {0.0} <4201> completed garbage collection

As mensagens de falha de GC podem incluir, entre outros:

2025/11/04-13:00:01.62234 {0.1} <4202> failed garbage collection with error MSG_ERR_DDR_ERROR

2025/11/01-12:35:06.62868 {0.2} <4202> failed garbage collection with error MSG_ERR_BACKUPSINPROGRESS

2025/10/13-12:20:07.35498 {0.7} <4202> failed garbage collection with error MSG_ERR_TRYAGAINLATER

2025/10/27-12:07:44.35485 {0.0} <4202> failed garbage collection with error MSG_ERR_DISKFULL

2025/11/02-13:16:39.72027 {0.1} <4202> failed garbage collection with error MSG_ERR_MISC

2025/11/02-13:16:39.72027 {0.1} <4202> failed garbage collection with error MSG_ERR_TIMEOUT

2025/11/02-13:16:39.72027 {0.1} <4202> failed garbage collection with error MSG_ERR_GARBAGECOLLECT

Se a GC estiver falhando, trate esse problema primeiro usando o seguinte artigo como referência: Avamar: solução de problemas de falhas de Coleta de lixo (GC) (caminho de resolução)
(Se algum problema já tiver sido resolvido, vá para a próxima etapa.)

Etapa 7. A GC está em execução por tempo suficiente?

a. Execute o seguinte comando para verificar o tempo máximo permitido para a GC:

dumpmaintlogs --types=gc --days=30 | grep gcflags 

Exemplo de resultado:

2025/10/07-12:00:20.05509 {0.1} <gcflags gccount="0" gcmincount="0" kill="0" limitadjust="5" maxpass="0" maxtime="14400" refcheck="true" throttlelevel="0" usehistory="false" orphansfirst="false"/>
2025/10/08-12:00:20.09141 {0.1} <gcflags gccount="0" gcmincount="0" kill="0" limitadjust="5" maxpass="0" maxtime="14400" refcheck="true" throttlelevel="0" usehistory="false" orphansfirst="false"/>
2025/10/09-12:00:20.42307 {0.1} <gcflags gccount="0" gcmincount="0" kill="0" limitadjust="5" maxpass="0" maxtime="14400" refcheck="true" throttlelevel="0" usehistory="false" orphansfirst="false"/>
2025/10/10-12:00:20.47775 {0.1} <gcflags gccount="0" gcmincount="0" kill="0" limitadjust="5" maxpass="0" maxtime="14400" refcheck="true" throttlelevel="0" usehistory="false" orphansfirst="false"/>
...
2025/11/02-13:00:19.76100 {0.0} <gcflags gccount="0" gcmincount="0" kill="0" limitadjust="5" maxpass="0" maxtime="14400" refcheck="true" throttlelevel="0" usehistory="false" orphansfirst="false"/>
2025/11/03-13:00:19.92093 {0.0} <gcflags gccount="0" gcmincount="0" kill="0" limitadjust="5" maxpass="0" maxtime="14400" refcheck="true" throttlelevel="0" usehistory="false" orphansfirst="false"/>
2025/11/04-13:00:19.42781 {0.0} <gcflags gccount="0" gcmincount="0" kill="0" limitadjust="5" maxpass="0" maxtime="14400" refcheck="true" throttlelevel="0" usehistory="false" orphansfirst="false"/>
2025/11/05-13:00:19.74984 {0.0} <gcflags gccount="0" gcmincount="0" kill="0" limitadjust="5" maxpass="0" maxtime="14400" refcheck="true" throttlelevel="0" usehistory="false" orphansfirst="false"/>

Anote o maxtime valor, que neste exemplo é 14.400 (segundos).
(Um valor de 0 significa ilimitado)

b. Execute o seguinte comando para determinar por quanto tempo a GC está em execução e quantas "passagens" foram concluídas:
As passagens têm relação com as camadas dos dados de backup armazenados. Pense na GSAN capacidade como camadas de uma cebola. As camadas externas devem ser descascadas ou removidas antes que as camadas internas possam ser vistas. Cada passagem é uma camada dos GSAN dados armazenados.

dumpmaintlogs --types=gc --days=30 | grep passes | cut -d ' ' -f1,14-20

Exemplo de resultado:

2025/10/07-12:00:35.24463 passes="24" start-time="1758283220" elapsed-time="250" end-time="1758283235"/>
2025/10/08-12:00:34.60779 passes="3" start-time="1758369620" elapsed-time="70" end-time="1758369627"/>
2025/10/09-12:00:35.14232 megabytes-recovered="1" passes="4" start-time="1758456020" elapsed-time="85" end-time="1758456028"/>
2025/10/10-12:00:34.67590 passes="3" start-time="1758542420" elapsed-time="72" end-time="1758542427"/>
...
2025/11/02-13:00:34.38348 megabytes-recovered="2" passes="18" start-time="1762088419" elapsed-time="89" end-time="1762088427"/>
2025/11/03-13:00:34.69743 passes="18" start-time="1762174819" elapsed-time="9" end-time="1762174828"/>
2025/11/04-13:00:34.17943 megabytes-recovered="8" passes="22" start-time="1762261219" elapsed-time="134" end-time="1762261228"/>
2025/11/05-13:00:34.44187 megabytes-recovered="2" passes="16" start-time="1762347619" elapsed-time="119" end-time="1762347628"/>

Anote o número de passagens e elapsed-time (segundos).

c. Supondo que maxtime seja diferente de zero, calcule 2/3 de maxtimee compare com o tempo decorrido.
No exemplo acima, 2/3 de 14.400 é 9.600, e todas as saídas de tempo decorrido estão bem abaixo desse valor.

Vários problemas podem fazer com que a GC seja executada com lentidão ou não verifique tudo. Isso pode incluir não ter tido tempo suficiente para execução por um período significativo ou dias no passado, configuração incorreta, erros e muito mais.

Se você tiver dúvidas sobre maxtimeou o número de passagens, crie um chamado com a equipe de suporte do Avamar da Dell Technologies para investigar em mais detalhes.

Etapa 8. Se houver suspeita de que a GC não removeu dados suficientes ou esperados:

Se confirmado que a GC está em execução por tempo suficiente, é possível que os dados não estejam sendo coletados por motivos não relacionados à coleta de lixo. Esta é uma lista dos motivos documentados que geralmente devem ser verificados:

a. Verifique se os backups estão configurados para expirar pelo menos eventualmente ou de forma regular. Se não houver backups frequentes prestes a expirar, a GC não terá muito trabalho a fazer.

Para encontrar os clients com a maior taxa de mudança, use este artigo: Avamar: Como gerenciar a capacidade com o script capacity.sh. (Analise "% OF TOTAL" e "CHGRATE".)

c. Verifique se há hashes ignorados de acordo com Avamar: a coleta de lixo do Avamar relata "hashes ignorados" que não podem ser limpos. Essa ocorrência, embora rara, é normal e pode ser ignorada.

d. Há uma sinalização ou opção que força o Avamar Server a manter o último e mais recente backup de cada client. Isso é usado para fins de segurança, para evitar que os backups de um client expirem acidentalmente. No entanto, isso pode causar outros problemas quando se trata de limpeza de dados e coleta de lixo. A equipe de suporte do Avamar da Dell Technologies pode confirmar se essa opção está ativada.

e. Se os backups tiverem sido trocados recentemente de GSAN para back-end do DD ou tiver ocorrido um backup GSAN acidental, mas a GSAN capacidade não diminuir, crie um chamado com a equipe de suporte do Avamar da Dell Technologies para investigar em mais detalhes.

Etapa 9. O grid Avamar está subdimensionado para a quantidade de dados atuais ou esperados a serem adicionados:

Depois que todas as outras soluções e possíveis causas tiverem sido analisadas quanto à alta capacidade, e for descartada a possibilidade de ser um problema de configuração ou de dados acidentais:

Isso significa que os dados podem exigir exclusão ou análise de opções, como migrar determinados clients para outras redes do Avamar, adicionar novos nós de dados, entre outros.

Etapa 10. Confirme todos os eventos de capacidade e retome o programador de backup, se necessário:

a. Uma vez que os problemas de capacidade forem resolvidos, confirme todos os eventos relacionados à capacidade na IU do Avamar Admin.

b. Retome o programador de backups:

dpnctl start sched

Para quaisquer outras dúvidas sobre capacidade do Avamar, treinamento, solução de problemas e muito mais, consulte: Avamar: solução de problemas, problemas e dúvidas sobre capacidade — Toda a capacidade (caminho de resolução)

• Essa ação por si só pode "mascarar" e ocultar os problemas reais, fazendo com que eles reapareçam alguns dias ou semanas depois, o que torna esse trabalho manual um desperdício de tempo.
• Além disso, a coleta manual talvez não seja executada com tanta eficiência, já que ocorre fora da programação.
  • Em alguns casos, isso pode piorar outros problemas. Para obter mais informações, consulte: Avamar: sobre o uso da coleta manual de lixo

• Em geral, essa alteração ou ação não é realizada e não deve ser considerada como o padrão. Um engenheiro L2 do Avamar ou um especialista no assunto (SME) deve aprovar essa alteração.
• Infelizmente, essas ações podem causar danos permanentes a um grid Avamar de várias formas, que só podem ser resolvidas com a adição de mais nós de armazenamento ou com uma nova implantação.

Entenda que nenhuma das ações listadas acima é realizada porque a equipe de suporte deseja ajudar a resolver os problemas de capacidade da maneira mais benéfica.