Avamar: Capacidade do sistema operacional (SO) (caminho de resolução)
Summary: Este artigo do caminho de resolução é para lidar ou solucionar problemas de capacidade do sistema operacional (SO) no Avamar.
Symptoms
Como lidar ou solucionar problemas de capacidade do SO no Avamar.
Este artigo do caminho de resolução foi projetado para abordar ou solucionar problemas de capacidade do sistema operacional no Avamar.
Para obter os conceitos iniciais e a compreensão da capacidade do SO, consulte o artigo de treinamento Avamar: Conceitos e treinamento
de gerenciamento de capacidadeConforme resumido no artigo de treinamento, uma compreensão razoável dos seguintes tópicos deve ser necessária para prosseguir com o restante deste artigo:
- Uma compreensão básica de checkpoints (cp), validação de checkpoint (
hfscheck)e Coleta de lixo (GC) e a importância de cada um - A diferença entre
GSAN(também conhecida como "Capacidade do usuário" e Capacidade do sistema operacional) - Dados de sobrecarga de checkpoint
- Se qualquer uma das partições de dados estiver em mais de 89% do espaço total de capacidade do SO físico, a coleta de lixo não poderá ser executada.
- Quanto mais próxima uma grade do Avamar estiver de 100% da capacidade do usuário, menor será a capacidade do SO disponível para sobrecarga de checkpoint.
- Fatores que contribuem para a sobrecarga do checkpoint, incluindo análise assíncrona, número de checkpoints armazenados,
HFSChecke a importância da validação do ponto de verificação, e assim por diante. - Como encontrar os níveis de capacidade do SO
- Ações básicas para aliviar a capacidade do SO
Geralmente, é mais fácil considerar a capacidade do SO como o tamanho do GSAN dados (mais especificamente o espaço alocado para esses dados) e a sobrecarga gerada pelos checkpoints do Avamar. Quanto maior o número de checkpoints e maior a taxa de alteração, maior será a sobrecarga do checkpoint.
Os impactos da alta capacidade do SO podem incluir:
- Falha na coleta de lixo: A GC falha com MSG_ERR_DISKFULL se a capacidade do SO subir acima de 89%
- Falha de backup ou replicação: Os backups ou a replicação de entrada podem falhar com o MSG_ERR_STRIPECREATE se a capacidade do SO ficar acima de 90%. (Isso somente se uma nova fração de dados precisar ser criada. Se uma nova fração não for necessária, os backups e a replicação ainda poderão ser executados com sucesso.)
- Falha de checkpoint: Um checkpoint falhará com MSG_ERR_DISKFULL se a capacidade do SO ficar acima de 96%
Como o mencionado acima pode indicar, a capacidade do SO geralmente é o primeiro tipo de capacidade do Avamar a ser solucionada quando outras capacidades do Avamar também são altas. No mínimo, a coleta de lixo não pode ser executada quando a capacidade do SO atinge determinados níveis, mesmo quando o GSAN ou a capacidade do usuário também é alta.
Geralmente, a capacidade do SO é considerada alta quando a GC falha com MSG_ERR_DISKFULL se a capacidade do SO ficar acima de 89%. Se a capacidade do SO for menor que 89%, nenhum trabalho de manutenção será afetado.
Cause
A capacidade do Avamar OS pode aumentar devido a qualquer combinação dos seguintes motivos:
- Alta taxa de alteração de dados de backup, adição de "muito rápido demais"
- High
GSANou "Capacidade do usuário", que deixa menos espaço para a capacidade do sistema operacional e, às vezes, pode até resultar em taxas de alteração mais altas - Falha na conclusão bem-sucedida do checkpoint, o que resulta no status "MSG_ERR_DISKFULL", conforme visto na saída.
- Uma validação de checkpoint (
hfscheck)apresentou falha ou não foi executado recentemente, de modo que os checkpoints mais antigos não podem ser prorrogados ou removidos - Os checkpoints não são desativados por outros motivos, inclusive as configurações de retenção de checkpoints muito altas
A alta capacidade do SO em outras partições de disco pode surgir de várias causas, incluindo posicionamento incorreto de dados, arquivos de log ficando muito grandes e assim por diante.
- Para um breve histórico, os checkpoints do Avamar são um snapshot somente leitura e um link para os dados em tempo real. Como ele é criado com links, um checkpoint não usará nenhum espaço extra em disco imediatamente após sua criação. Se não houver alterações nos dados em tempo real, o checkpoint não usará espaço adicional.
- Isso muda à medida que os dados ativos são modificados enquanto o checkpoint permanece o mesmo. Nesse ponto, há uma cópia original dos dados no checkpoint e a cópia atualizada em tempo real dos dados modificados. Isso é completamente intencional e intencional. É por isso que há espaço reservado de capacidade do SO.
- No entanto, se a quantidade ou a taxa de alteração dos dados aumentar drasticamente e repentinamente, isso poderá causar um aumento incomum no tamanho da capacidade do SO e ser considerado "muito rápido"
- A coluna
capacity.shmostra essa como a causa ao comparar a saída ao longo de vários dias.
Resolution
Se os trabalhos de manutenção, inclusive a coleta de lixo, apresentarem falha devido à alta capacidade do Avamar OS, siga estas etapas:
1. Colete todas as informações de capacidade do Avamar para criar um quadro da situação: Avamar: Como coletar as informações necessárias para solucionar problemas de capacidade.
2. Em seguida, analise o nível de capacidade do SO e quais ações podem ser necessárias. No artigo da coleta de dados, é possível encontrar isso usando o seguinte comando:
avmaint nodelist | egrep 'nodetag|fs-percent-full'
Como o Avamar funciona é que o MAIOR valor para fs-percent-full mostrado é o fator limitante da capacidade atual do sistema operacional. Dependendo da geração e do tamanho do tipo de nó, o número de partições de dados que armazenam dados de backup e checkpoint pode variar. Como visto no sistema operacional Linux, eles podem ser discos ou partições como "/data0*", onde "*" pode ser um dígito. O número de partições de dados depende do tipo de nó, da geração do hardware e do tamanho (e não pode ser alterado).
3. Analise o número de checkpoints encontrados e o quão recentemente eles foram validados a partir do comando:
cplist
cp.20290310080041 Mon Mar 10 08:00:41 2025 valid rol --- nodes 4/4 stripes 5980
cp.20290310080649 Mon Mar 10 08:06:49 2025 valid --- --- nodes 4/4 stripes 5980
4. Verifique se as operações de checkpoint estão falhando em "MSG_ERR_DISKFULL" executando o seguinte comando:
dumpmaintlogs --types=cp --days=4 | grep "\<430"
Se os checkpoints forem concluídos com sucesso, um resultado semelhante ao seguinte será exibido:
2020/03/07-08:00:39.51323 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/07-08:01:31.49490 {0.0} <4301> completed checkpoint maintenance
2020/03/07-08:07:47.36128 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/07-08:08:29.40139 {0.0} <4301> completed checkpoint maintenance
2020/03/08-08:00:39.93332 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/08-08:01:29.50546 {0.0} <4301> completed checkpoint maintenance
2020/03/08-08:06:45.37918 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/08-08:07:27.36749 {0.0} <4301> completed checkpoint maintenance
2020/03/09-08:00:36.57433 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/09-08:01:24.22214 {0.0} <4301> completed checkpoint maintenance
2020/03/09-08:06:40.52884 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/09-08:07:22.18463 {0.0} <4301> completed checkpoint maintenance
2020/03/10-08:00:39.83562 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/10-08:01:31.87814 {0.0} <4301> completed checkpoint maintenance
2020/03/10-08:06:48.27867 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/10-08:07:29.95640 {0.0} <4301> completed checkpoint maintenance
Se houver falha devido a MSG_ERR_DISKFULL, esse resultado será exibido:
2020/03/07-08:00:39.51323 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/07-08:01:31.49490 {0.0} <4301> failed checkpoint maintenance with error MSG_ERR_DISKFULL
2020/03/07-08:07:47.36128 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/07-08:08:29.40139 {0.0} <4301> completed checkpoint maintenance
2020/03/08-08:00:39.93332 {0.0} <4300> failed checkpoint maintenance with error MSG_ERR_DISKFULL
2020/03/08-08:01:29.50546 {0.0} <4301> completed checkpoint maintenance
2020/03/08-08:06:45.37918 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/08-08:07:27.36749 {0.0} <4301> completed checkpoint maintenance
2020/03/09-08:00:36.57433 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/09-08:01:24.22214 {0.0} <4301> completed checkpoint maintenance
2020/03/09-08:06:40.52884 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/09-08:07:22.18463 {0.0} <4301> completed checkpoint maintenance
2020/03/10-08:00:39.83562 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/10-08:01:31.87814 {0.0} <4301> completed checkpoint maintenance
2020/03/10-08:06:48.27867 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/10-08:07:29.95640 {0.0} <4301> completed checkpoint maintenance
cplist cOMMAND Mostra quantos checkpoints foram encontrados e há quanto tempo um checkpoint foi validado. Como também mostrado no artigo de coleta de dados, use Avamar - Como entender o resultado gerado pelo comando cplist para entender o cplist saída.
Deve haver dois ou três checkpoints, e pelo menos um dos checkpoints das últimas 24 horas é exibido como validado com
hfscheck. Esse seria o comportamento e o resultado normais de todos os trabalhos executados com sucesso e configurações normais de retenção de checkpoints.
Se houver mais de três checkpoints ou nenhum checkpoint validado nas últimas 24 horas, isso precisará ser resolvido primeiro, pois pode ser a única maneira de reduzir a capacidade do SO. Se esse cenário for encontrado, abra um chamado com a Dell Technologies, caso contrário, continue da etapa 6.
6. Determine a taxa de alteração:
capacity.sh
Exemplo de resultado:
DATE AVAMAR NEW #BU SCANNED REMOVED MINS PASS AVAMAR NET CHG RATE
========== ============= ==== ============= ============= ==== ==== ============= ==========
2020-02-25 1066 mb 8 302746 mb -641 mb 0 23 425 mb 0.35%
2020-02-26 1708 mb 8 303063 mb -518 mb 0 23 1189 mb 0.56%
2020-02-27 3592 mb 8 304360 mb -413 mb 0 23 3178 mb 1.18%
2020-02-28 1086 mb 8 304892 mb -372 mb 0 23 713 mb 0.36%
2020-03-01 1002 mb 8 305007 mb -7469 mb 0 25 -6467 mb 0.33%
2020-03-02 585 mb 7 197874 mb 0 mb 0 9 585 mb 0.30%
2020-03-03 348 mb 7 199305 mb 0 mb 0 10 348 mb 0.17%
2020-03-04 775 mb 7 198834 mb -2 mb 0 10 773 mb 0.39%
2020-03-05 380 mb 4 196394 mb -5 mb 0 10 375 mb 0.19%
2020-03-06 1068 mb 4 159960 mb 0 mb 0 9 1067 mb 0.67%
2020-03-07 443 mb 4 197132 mb -18 mb 0 17 424 mb 0.23%
2020-03-08 348 mb 4 197231 mb -48 mb 0 20 300 mb 0.18%
2020-03-09 370 mb 4 196506 mb 0 mb 0 9 370 mb 0.19%
2020-03-10 349 mb 4 197292 mb -17 mb 0 20 332 mb 0.18%
2020-03-11 974 mb 2 77159 mb 0 mb 0 0 974 mb 1.26%
=============================================================================================
14 DAY AVG 940 mb 5 222517 mb -634 mb 0 15 306 mb 0.42%
30 DAY AVG 1121 mb 5 195658 mb -771 mb 0 14 349 mb 0.59%
60 DAY AVG 994 mb 4 128657 mb -1165 mb 0 17 -170 mb 0.98%
Top Change Rate Clients. Total Data Added 14103mb
NEW DATA % OF TOTAL CHGRATE TYPE CLIENT
============= ========== ======= ====
6803 mb 48.24 0.91% AVA /Windows/testing/Hyper-V/hyperv1
3218 mb 22.82 0.61% AVA /clients/exchange1
2932 mb 20.80 0.44% AVA /BMR/server1
983 mb 6.97 0.10% AVA /Windows/testing/SQL/sql1
97 mb 0.69 1.13% AVA /REPLICATE/grid2.company.com/MC_BACKUPS
Às vezes, se a alta taxa de mudança ou a situação "muito rápida" se repetir, isso pode ser aliviado baixando o GSAN ou capacidade do usuário. Com um menor GSAN capacidade, há um pouco mais de espaço para sobrecarga de capacidade do sistema operacional e também resulta em menos alterações no contêiner de armazenamento de dados. Para obter assistência com esse cenário, abra um chamado com a equipe de suporte do Avamar da Dell Technologies; caso contrário, continue da etapa 7.
7. Problemas com altas capacidades do sistema operacional em outras partições de disco têm várias causas, mas as soluções exigem suporte técnico. Abra um chamado com a equipe de suporte do Dell Technologies Avamar; caso contrário, continue da etapa 7.
Depois que a capacidade do SO for atendida, GSAN ou outras capacidades do Avamar podem ser revisadas. Consulte Solução de problemas, problemas e perguntas sobre capacidade do Avamar — toda a capacidade (caminho de resolução)