Avamar GSAN ou caminho de resolução de capacidade do usuário

Summary: Este artigo do caminho de resolução destina-se a lidar e solucionar problemas de capacidade do GSAN (também conhecida como Capacidade do usuário) no Avamar.

This article applies to This article does not apply to This article is not tied to any specific product. Not all product versions are identified in this article.
Check out other resources

Symptoms

Para obter os conceitos iniciais e a compreensão da capacidade do sistema operacional (SO), consulte Avamar: Treinamento geral de capacidade — Caminho de resolução

Muitas vezes é mais fácil de considerar GSAN Capacidade como espaço e utilização para client backups.

Como resumido neste artigo de treinamento, uma compreensão razoável dos seguintes tópicos deve ser necessária para continuar durante o restante deste artigo:
  • Noções básicas sobre desduplicação
  • Noções básicas de checkpoint, validação de checkpoint (hfscheck), e Coleta de Lixo, e a importância de cada um.
  • A diferença entre GSAN (ou Usuário) Capacidade e capacidade do SO
  • Taxa de alteração
  • Estado estacionário
 
Impactos da alta GSAN A capacidade pode incluir:
  • Falha de backup ou replicação quando o estado de acesso à grade foi alterado para o "modo admin"
    • Um trabalho de backup do client pode falhar com uma mensagem semelhante a:  "avtar Info <5314>: Command failed (1 error, exit code 10028: Operation failed because target server is full)"
  • A desativação automática do agendador de backup (até que seja reconhecido e removido por alguém)
 
Quando os limites a seguir são ultrapassados, um evento, advertência ou erro é gerado na interface do usuário de administração do Avamar:
  • 80% - Aviso de capacidade
  • 95% — o limite da verificação de integridade foi atingido (isso às vezes pode desativar o agendador de backup, pelo menos até ser reconhecido manualmente)
  • 100% - O limite somente leitura do servidor foi atingido (a grade entra no modo de administrador)

Cause

Em um breve resumo: Avamar Server e GSAN A capacidade "desduplica" os dados de backup, ou seja, quando determinados bytes ou fragmentos de dados são semelhantes, só é necessário armazenar esse fragmento uma vez. Todos os dados podem ser "desduplicados" em relação a quaisquer outros dados dos mesmos clients ou de diferentes clients que passaram por backup na grade do Avamar. Como esses fragmentos de dados são pequenos, ele pode encontrar muitas duplicações e economizar muita capacidade sem precisar fazer backup repetidamente.
O ciclo de vida de capacidade dos dados de backup do client:
  1. O Avamar só precisa salvar e armazenar as pequenas alterações e diferenças entre cada trabalho de backup do client devido à desduplicação. À medida que novos backups (ou replicação de entrada) são executados, ele pode adicionar novos dados e aumentar a capacidade ou o valor de utilização do Avamar. 
  2. Depois de um determinado período, os backups expirarão com base em sua retenção e expiração configuradas e não serão encontrados na grade do Avamar disponível para restauração. 
  3. Quando o trabalho de manutenção do Avamar chamado Garbage Collection (GC) é executado, ele encontra todas as partes ou partes exclusivas de dados que não são mais necessárias devido a esses backups expirados. A GC verifica se nenhum outro backup atual compartilha os mesmos dados (devido à desduplicação) e , em seguida, remove ou libera esses fragmentos de dados que não são mais necessários para reduzir a capacidade ou a utilização do servidor Avamar.
 

Quando a quantidade de dados recebidos diariamente adicionados é aproximadamente a mesma que a quantidade de dados diários que estão sendo limpos, isso é chamado de "estado estacionário". Esse é o objetivo de cada grade do Avamar instalada.

Antes que uma nova grade do Avamar seja configurada, cálculos gerais de dimensionamento de pré-instalação são feitos para determinar a capacidade necessária para armazenar os dados de backup. Esses cálculos são baseados nos requisitos de retenção de clientes e no volume de dados que deve ser submetido a backup. Ele também estima quanto desses dados poderia desduplicar em média e assim por diante.

No entanto, às vezes, a capacidade não atinge um estado estável. Isso pode ser causado por:
  1. A coleta de lixo não está sendo executada de forma consistente
  2. O desempenho da coleta de lixo está lento ou não está em execução por tempo suficiente
  3. As estimativas de desduplicação anteriores à instalação da grade do Avamar não eram precisas o suficiente
  4. Os dados que não foram calculados antes da instalação da grade do Avamar estão sendo submetidos a backup nesse servidor Avamar.
  5. Outros motivos

Resolution

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

Nota: As etapas são organizadas na sequência mais apropriada para isolar o problema e identificar a resolução adequada.
Não ignore nenhuma etapa.
 
 

Etapa 1. Recolha de dados:

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

Isso inclui erros de hardware, problemas de integridade dos dados (inclusive nós off-line), faixas off-line, falhas de validação de checkpoint ou falhas em trabalhos de manutenção. Se qualquer um desses problemas for um problema, a solução de problemas de capacidade deverá ser interrompida e outros problemas resolvidos. Depois que outros problemas forem resolvidos, a capacidade poderá ser revista.

Uma verificação de integridade deve ser executada (Avamar: Como executar o script de verificação de integridade do proactive_check.pl em um Avamar Server, mas pelo menos o status.dpn O comando pode fornecer uma rápida visão geral e verificação da maioria desses mesmos problemas. Consulte Avamar: Como entender o resultado gerado pelo comando status.dpn

Consulte o seguinte artigo para obter informações adicionais: Avamar: Como aplicar a abordagem da "hierarquia de solução de problemas do Avamar" corretamente.

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

 

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

Consulte o seguinte 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

No mínimo, o status.dpn ou os valores na interface do usuário de administração do Avamar mostram o GSAN capacidade.

Nota: A capacidade mostrada pelo status.dpn e a interface do usuário diferem pelo design pretendido.
 
 

Passo 3. Verifique se a capacidade do SO está cheia:

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

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"
 
Aviso: Embora a alta capacidade do SO possa não parecer ser a maior preocupação, isso impede a solução de problemas GSAN Capacidade porque a coleta de lixo não poderá ser executada se a capacidade exceder 89%. Isso é discutido em mais detalhes, e as etapas de solução de problemas são fornecidas em: Avamar: Capacidade do sistema operacional (SO) (caminho de resolução)
 

Somente se a capacidade do SO estiver abaixo de 85%, o GSAN A solução de problemas de capacidade continua. 

 

Passo 4. Problemas de não capacidade que às vezes podem ser mal entendidos como capacidade:

É possível que os backups do client falhem não por motivos de "capacidade", mas sim por motivos de "cota". Às vezes, isso pode ser entendido erroneamente como capacidade.

Essa situação pode ser confirmada pelo status.dpn ou alguma outra saída coletada mostrando menor capacidade.

Também é possível que os backups do client tenham falhado ou não tenham sido executados devido a outros Non-GSAN Motivos de capacidade. As informações coletadas devem confirmar isso ou também podem ser vistas na interface do usuário de administração do Avamar.

Se a solicitação do GSAN A capacidade não é alta, consulte os seguintes artigos:
 

Se a solicitação do GSAN A capacidade é alta, e essas outras capacidades também são altas. A solução de problemas pode ser realizada em qualquer ordem (exceto para a capacidade do SO, que deve ser sempre a primeira).

Nota: É possível que o GSAN A capacidade, a capacidade de metadados e a capacidade do DD podem ser altas. Nessas situações, elas podem ser abordadas em qualquer ordem, ao contrário da capacidade do sistema operacional, que sempre deve ser abordada primeiro.
 
 
 

Passo 5. Balanceamento de faixas e balanceamento de disco do sistema operacional:

"Stripes" no Avamar são os arquivos de contêiner nos quais os dados de backup são armazenados nos nós de dados (exceto para uma grade do Avamar de único nó).

A expectativa é que as frações sejam "equilibradas" ou distribuídas uniformemente entre os diferentes discos e nós da grade, no entanto, às vezes elas podem se tornar desequilibradas.

Por design no Avamar, o maior nó ou partição de disco é o fator limitador quando se trata de capacidade do Avamar.

Isso é intencional; portanto, nenhum dos discos ou nós cria mais frações do que podem manipular (ou permitem), portanto, ter faixas balanceadas é importante para a capacidade.

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

Nota: Enquanto um equilíbrio de listras perfeito é desejado e muitas vezes visto, problemas podem surgir e "não é bem assim", mas perto, equilíbrio é visto. A equipe de engenharia do Avamar confirmou que uma diferença de 4% e tolerância entre os balanceamentos de faixas está dentro dos limites esperados.
 
 

Outro tipo de balanceamento que requer compreensão é o balanceamento de disco do sistema operacional. Isso é limitado apenas a partições de dados no mesmo nó, não partições em vários nós. 

Se, no mesmo nó de dados, uma partição for muito maior ou menor do que outra partição do MESMO nó, um limite poderá ser excedido chamado "freespaceunbalance". Geralmente, isso está no sistema operacional e não no GSAN Capacidade, ela pode ser relatada como um GSAN Problema de capacidade.

 

Passo 6. Verifique 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"
 

Idealmente, a saída mostrará 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 da GC podem incluir, entre outras, o seguinte:

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 o GC estiver falhando, resolva isso 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.)

 

Passo 7. O GC está funcionando por tempo suficiente?

Advertência: Não confunda isso com "MSG_ERR_TIMEOUT" dos resultados do GC. Esse erro é totalmente diferente e pode ser abordado no artigo Caminho de resolução de erros do GC. Aqui, o tempo limite significa que no GC atingiu seu tempo de execução máximo, mas termina silenciosamente e de forma limpa sem qualquer erro. As informações nesta etapa ajudam a confirmar se isso está ocorrendo.
 
 

um. Execute o seguinte comando para verificar o tempo máximo permitido para 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"/>
 

Tome nota do maxtime valor, que neste exemplo é 14400 (segundos).
(Um valor de 0 significa ilimitado)

b. Execute o seguinte comando para determinar por quanto tempo a GC está sendo executada 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 sejam vistas. Cada passagem é uma camada do 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 passes e o elapsed-time (segundos).

 

c. Supondo que o maxtime for diferente de zero, calcule 2/3 de maxtime, e compare-o com o tempo decorrido.
(No exemplo acima, 2/3 de 14400 é 9600, e todas as saídas de tempo decorrido estão bem abaixo dessa figura.)

  • Se a solicitação do elapsed-time é inferior a 2/3 de maxtime, é provável que o GC tenha terminado mais cedo porque não havia mais nada para coletar e foi alcançado.

  • Se o número de passagens for alto (14 ou mais), é provável que o GC esteja removendo quantidades suficientes de dados.
    Nota: Entenda que, se nenhum dado expirou e não há nada para limpar, espera-se que o valor das passagens seja baixo, portanto, é melhor entender toda a situação e o ambiente também. Não assuma que poucos passes significam que há um problema.
 

Vários problemas podem fazer com que a GC seja executada lentamente ou não verifique tudo. Isso pode incluir não ter tido tempo suficiente para executar por uma quantidade significativa de tempo ou dias no passado, configuração incorreta, erros e muito mais.

Se houver preocupações sobre o maxtime, ou número de senhas, crie um chamado com a equipe de suporte do Avamar da Dell Technologies para investigar mais.

 

Etapa 8. Se suspeitar que a GC não removeu dados suficientes ou os 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 fora do controle de coleta de lixo. Esta é uma lista dos motivos documentados que geralmente devem ser verificados:

um. Verifique se os backups estão configurados para pelo menos expirar eventualmente ou regularmente. Se não houver backups expirantes frequentes, a GC não terá muito trabalho a fazer.

b. Use este artigo para encontrar os clients "Top Change Rate": Avamar: Como gerenciar a capacidade com o script capacity.sh. (Reveja ambos os "% OF TOTAL" e "CHGRATE".)

c. Verifique se há hashes ignorados por Avamar: A coleta de lixo do Avamar relata "skipped-hashes" que não podem ser limpos. Se estes estão ocorrendo, mas raros, isso é normal e isso pode ser ignorado.

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

e. Se os backups foram trocados recentemente de GSAN para o back-end do DD ou houve um acidente GSAN backup, mas o GSAN A capacidade não diminui. Crie um chamado com a equipe de suporte do Avamar da Dell Technologies para investigar mais.

 

Passo 9. A grade do Avamar é subdimensionada 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 isso não for um problema de configuração ou com dados acidentais:

Isso significa que os dados podem exigir exclusão ou opções exploradas, como migrar determinados clients para outras grades do Avamar, adicionar novos nós de dados e assim por diante.

 

Passo 10. Confirme quaisquer eventos de capacidade e retome o agendador de backup, se necessário:

um. Depois que os problemas de capacidade forem resolvidos, confirme todos os eventos relacionados à capacidade na interface do usuário Admin do Avamar.

b. Retome o agendador de backup:

dpnctl start sched
 

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

Additional Information

A coleta de lixo manual ou "agressiva" não é recomendada.
(Esta é uma referência à execução do GC fora dos horários automáticos agendados.)
  • Essa ação por si só pode "mascarar" e ocultar os problemas reais, só fazendo com que eles reapareçam em alguns dias ou semanas depois, fazendo com que esse trabalho manual seja desperdiçado tempo.
  • Além disso, o GC manual pode não ser executado com a mesma eficiência, pois está ficando sem agendamento.
 
As etapas de resolução acima não mencionam nem recomendam alterar as configurações de capacidade máxima de disco e específicas ao GSAN Capacidade em tudo.
  • Essa alteração ou ação geralmente não é executada e não deve ser considerada por padrão. Um engenheiro do Avamar L2 ou um especialista no assunto (SME) deve aprovar essa alteração.
  • Infelizmente, essas ações geralmente podem causar danos permanentes a uma grade do Avamar de várias maneiras que só podem ser resolvidas com a adição de nós de armazenamento adicionais ou a reimplementação.
 

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

Affected Products

Avamar

Products

Avamar, Avamar Server
Article Properties
Article Number: 000164132
Article Type: Solution
Last Modified: 07 Nov 2025
Version:  10
Find answers to your questions from other Dell users
Support Services
Check if your device is covered by Support Services.