Avamar – Treinamento e conceitos sobre gerenciamento de capacidade

Este artigo é voltado para as versões 5.x e posteriores do Avamar. 

Para problemas de gerenciamento de capacidade relacionados a dispositivos de Data Domain, consulte o capítulo "Recuperando o armazenamento em um sistema Data Domain completo" do Guia de integração do sistema Avamar e Data Domain.

Objetivos deste artigo:

• Resumir os tipos de dados armazenados nas partições /data*
• Apresentar o conceito de "capacidade do sistema operacional" e compará-lo com o conceito de "capacidade do usuário" (às vezes chamado de "capacidade GSAN")
• Explicar por que o Avamar não deve ser executado próximo ao limite de capacidade do usuário
• Listar os fatores que contribuem para a sobrecarga de checkpoint
• Descrever como monitorar a utilização da partição de dados
• Descrever os sintomas observados nos casos em que a capacidade do sistema operacional sai do controle
• Listar as causas típicas da mensagem MSG_ERR_DISKFULL
• Descrever os métodos de recuperação que poderão ser realizados quando a alta utilização da capacidade do sistema operacional afetar a operação normal do sistema
• Descrever os sintomas observados nos casos em que a capacidade do usuário excede o limite
• Discutir como se recuperar de uma situação de alta utilização da capacidade do usuário

O artigo da KB presume que o leitor esteja familiarizado coma seção "Gerenciando a capacidade" do Guia de práticas recomendadas operacionais do Avamar.

Problemas comuns que afetam a "capacidade do sistema operacional" ou são sintomas de uma utilização muito alta dessa capacidade:

• A validação de checkpoint (HFS Check) está falhando
• A coleta de lixo não é executada e gera relatórios comMSG_ERR_DISKFULL
• A criação de checkpoint apresenta falha

Os sintomas comuns que estão intimamente associados à utilização muito alta da "capacidade do usuário" são:

• Falhas de backup.
• Falha nos trabalhos de replicação de entrada 
• A interface do administrador mostra o sistema no modo "Admin" durante a janela de backup.

Como os dados são armazenados na grade do Avamar?

O gerenciamento de capacidade do Avamar diz respeito aos dados localizados nas partições /data* de todos os nós de dados do Avamar.  Eles são compostos por:

• Dados de backup desduplicados
• Dados de paridade RAIN
• Dados de sobrecarga de checkpoint. 

Os dados de paridade RAIN e os de checkpoint são camadas de redundância disponíveis para o Avamar, além das camadas de RAID e de replicação.

Também é necessário espaço livre nas partições de dados para tarefas de manutenção, como coleta de lixo e processamento assíncrono de frações, para que sejam executadas corretamente.

Veja abaixo uma representação gráfica do espaço de armazenamento físico que está disponível nas partições de dados dos nós de armazenamento do Avamar.

Como os dados são armazenados nas partições de dados?

No diagrama acima, podemos ver uma representação simples de como o espaço é usado nas partições de dados.

O valor de 100%, à esquerda, é definido como a quantidade total de espaço físico disponível para o sistema operacional nas partições de dados.

Se qualquer uma das partições de dados consumir mais de 85% do espaço total, a coleta de lixo não poderá ser executada.

O marcador de capacidade do usuário de 100% (limite somente leitura) indica que até 65% do espaço total na partição de dados está disponível para armazenamento de dados desduplicados. O espaço abaixo desse marcador de capacidade do usuário de 100% é equivalente ao valor de utilização do servidor, que fica visível na GUI do administrador. Se a quantidade de dados desduplicados armazenada em qualquer partição de dados de algum nó atingir 65%, o sistema Avamar se tornará somente leitura e recusará mais dados de backup.

Agora podemos entender que, na GUI do administrador do Avamar, o usuário tem visibilidade do espaço consumido pelos backups, mas ele não tem visibilidade do espaço consumido nas partições de dados do sistema operacional.

Por que um sistema Avamar não deve ser executado com a "capacidade do usuário" próxima ao limite?

A relação entre a alta utilização da "capacidade do usuário" e a sobrecarga de checkpoint ocorre de tal forma que, conforme um sistema fica cada vez mais cheio, até mesmo pequenos aumentos nos dados de backup podem causar grandes aumentos na sobrecarga de checkpoint.  Um discussão completa sobre esse caso está além do escopo deste artigo. No entanto, é importante lembrar que:

• Quanto mais próximo um sistema Avamar estiver de utilizar 100% da capacidade do usuário, menos capacidade do sistema operacional estará disponível para a sobrecarga de checkpoint.

Em um sistema cheio, como podemos ver no diagrama acima, a sobrecarga de checkpoint é limitada a 20% do espaço total do sistema operacional nas partições de dados.

Para que um sistema Avamar seja executado de forma confiável em altos níveis de "capacidade do usuário", ele deve atender aos seguintes critérios:

1. O sistema deve ter uma taxa baixa de dados alterados diariamente (não superior a 1%).
2. A capacidade deve estar em estado estável (conforme descrito no Guia de práticas recomendadas operacionais do Avamar).
3. As tarefas de manutenção devem ser concluídas com êxito, todos os dias.

Se qualquer uma dessas afirmações passar de verdadeiro para falso, a sobrecarga de checkpoint poderá aumentar gradualmente ou de forma repentina, causando sérios problemas operacionais.

Fatores que contribuem para a sobrecarga de checkpoint:

Os fatores a seguir podem fazer com que a sobrecarga de checkpoint aumente.

• Processamento assíncrono de frações (ativado por padrão).
• Número de pontos de checkpoints armazenados no sistema.
• Validação de checkpoint não concluída com êxito todos os dias.
• A foma como as frações vazias estão quando são reutilizadas pelo Avamar Server (a situação fica ainda mais grave com uma utilização maior do servidor).
• Taxa de alteração do backup diário.

Um administrador do sistema tem um certo grau de controle sobre esses fatores. A configuração de processamento assíncrono é apenas para uso de suporte, mas os administradores podem remover checkpoints excessivos, investigar falhas de checkpoint e influenciar a taxa de utilização do servidor e de alteração de dados diária.

Como monitorar a utilização de partições de dados

A maneira correta de monitorar a utilização da partição de dados do sistema operacional é executar o seguinte comando, a partir do nó do utilitário do Avamar.

Por exemplo:

admin@utilitynode:~/>: avmaint nodelist | grep fs-percent fs-percent-full="7.8" fs-percent-full="6.3" fs-percent-full="6.4" fs-percent-full="6.4" fs-percent-full="7.6" fs-percent-full="6.2" fs-percent-full="6.1" fs-percent-full="6.6" fs-percent-full="7.8" fs-percent-full="6.4" fs-percent-full="6.5" fs-percent-full="6.8"

Esse resultado fornece uma leitura verdadeira da utilização da capacidade do sistema operacional. Em uma grade em que os nós de dados usam um pool de arquivos, o comando "df" do Linux não é significativo porque as frações são pré-alocadas no pool de arquivos, e muitas delas podem não estar em uso.

O que acontecerá se o uso da capacidade do sistema operacional ficar fora de controle?

Do ponto de vista de um usuário, a primeira indicação de que a utilização da partição de dados está fora de controle ocorre quando ela fica acima de 85%.

A coleta de lixo não pode mais ser executada e falhará com uma mensagem de erro MSG_ERR_DISKFULL. 

• Veja onde os enganos geralmente ocorrem.

Normalmente, o usuário acha que a mensagem MSG_ERR_DISKFULL indica que o sistema não tem mais espaço para backups.

Essa interpretação não está correta, apesar de o usuário geralmente verificar o valor de utilização do servidor na GUI do administrador do Avamar e considerar o valor aceitável, por exemplo, 60%.

O usuário pode tentar excluir backups da interface de gerenciamento de backups da GUI do Avamar. Mesmo que o nível de capacidade do usuário estivesse alto, a exclusão de backups não aliviaria a situação, pois a coleta de lixo não consegue ser executada e remover fragmentos expirados de dados do sistema.

Lembre-se: Se um sistema estiver enfrentando problemas de alta utilização da capacidade do sistema operacional e alta utilização da capacidade do usuário, concentre-se em resolver o problema do sistema operacional primeiro.

Em casos de alta utilização da capacidade do sistema operacional, o sistema pode ficar sem espaço para criar novos checkpoints.

O que causa a mensagem MSG_ERR_DISKFULL?

A causa mais comum é uma sobrecarga muito alta de checkpoint. Os fatores usuais de alta sobrecarga de checkpoint podem ser:

A validação do checkpoint (HFScheck) falhou de repente.

• A falha do HFScheck pode ocorrer por diversas causas raiz (cancelamento abrupto, falha de software etc.).

O sistema está funcionando com uma utilização de capacidade muito alta e apresenta uma taxa de alteração de dados diária muito elevada.

• O sistema precisa de mais nós de dados para lidar com a taxa de alteração de dados e armazenar os dados.
• O sistema está configurado para fazer backup de mais dados ou clients do que foi dimensionado para comportar.

Muitos checkpoints estão sendo armazenados (o Avamar armazena dois checkpoints por padrão, um deles foi validado).

• Checkpoints em excesso foram criados pelo administrador do sistema
• A manutenção foi realizada recentemente, mas as retenções de checkpoint padrão não foram restabelecidas.

Consulte o artigo a seguir como auxílio para resolver uma situação MSR_ERR_DISKFULL.

• Somente clientes Dell registrados podem acessar o conteúdo do link a seguir pelo site Dell.com/support Artigo 468219 da KB: As tarefas de manutenção do Avamar falham com "MSG_ERR_DISKFULL" devido à utilização da capacidade de partição de dados do SO superior a 85%  

Ações para investigar e ajudar a aliviar a alta utilização da capacidade do sistema operacional

1. Descubra quando a última verificação HFScheck bem-sucedida foi concluída.

Para fazer isso, use o administrador do Avamar ou a linha de comando no nó do utilitário do Avamar.

No administrador do Avamar, acesse a guia Server > Checkpoint Management.

Verifique a data e a hora mais recentes, listadas na coluna Checkpoint Validation. Isso deve ter ocorrido nas últimas 24 horas.

Ou, usando a linha de comando no nó do utilitário do Avamar:

Execute o comando "cplist"

Veja abaixo um exemplo de saída. O checkpoint validado mais recente listado aqui é o de 14 de janeiro, 11:14. Podemos identificá-lo pelo indicador que fica logo após o marcador "valid". Dependendo dos tipos de HFSchecks definidos no sistema, o indicador pode ser "rol" ou "hfs". Aqui temos um "rol" (rolling HFScheck). 

admin@utilitynode:~/>: cplist cp.20110114111419 Fri Jan 14 11:14:19 2011 valid rol --- nodes 3/3 stripes 1131 cp.20110114194457 Fri Jan 14 19:44:57 2011 valid --- --- nodes 3/3 stripes 1131

Se os resultados mostrarem que o último checkpoint validado tem mais de 24 horas, descubra o motivo.

Isso pode ocorrer porque o HFScheck não foi executado ou porque falhou.

2. Confirme se o HFScheck foi executado ou se falhou

No nó do utilitário do Avamar, execute "status.dpn" e localize a linha que contém "Last hfscheck",

Por exemplo:

Last hfscheck: finished Sat Jan 15 11:07:17 2011 after 06m 41s >> checked 528 of 528 stripes (OK)

Anote a data em que ele foi concluído e qual foi o status (na linha acima, o status é mostrado como "OK").

Nota:o script "ched.sh" também pode ser usado para identificar quando um HFScheck foi executado pela última vez e se ele foi bem-sucedido.

 Se os trabalhos de HFScheck falharem, isso deve ser investigado imediatamente.

 Se o HFScheck não tiver sido executado recentemente, confirme se as tarefas de manutenção estão ativadas. Por meio da interface de linha de comando no nó do utilitário do Avamar, digite "dpnctl status" 

admin@utilitynode:~/>: dpnctl status Identity added: /home/admin/.ssh/dpnid (/home/admin/.ssh/dpnid) dpnctl: INFO: gsan status: ready dpnctl: INFO: MCS status: up. dpnctl: INFO: EMS status: up. dpnctl: INFO: Backup scheduler status: up. dpnctl: INFO: dtlt status: up. dpnctl: INFO: Maintenance windows scheduler status: enabled. dpnctl: INFO: Maintenance cron jobs status: enabled. dpnctl: INFO: Unattended startup status: disabled.

Se "maintenance windows scheduler" estiver com o status "disabled", ele poderá ser ativado com o comando:

dpnctl start maint

Assim que o HFScheck for concluído com êxito e o checkpoint mais antigo for "removido" do sistema, a utilização da capacidade do sistema operacional deverá ser reduzida consideravelmente.

Se a utilização da capacidade do sistema operacional ainda estiver muito alta e a coleta de lixo continuar falhando com a mensagem MSG_ERR_DISKFULL, a assistência do suporte da EMC poderá ser necessária.

Caso contrário, se a utilização da capacidade do sistema operacional for baixa o suficiente, isso permitirá que a coleta de lixo seja executada, trabalhe para reduzir a utilização da "capacidade do usuário" e diminua a quantidade de "utilização do servidor".

 

Ações para aliviar a alta utilização da capacidade do usuário

Diferentemente da capacidade do sistema operacional, os níveis de capacidade do usuário são influenciados com mais facilidade e de forma direta pelo administrador do sistema do Avamar.

Esse é talvez o ponto mais crucial, pois até mesmo um sistema de tamanho adequado atingirá rapidamente a alta utilização da capacidade do usuário se a coleta de lixo não for executada de forma regular ou confiável.

Como mostrado anteriormente, confirme se a janela de manutenção está ativada e use os scripts capacity.sh e sched.sh para verificar se a coleta de lixo está em execução, se ela está removendo dados e se nenhum trabalho de backup e replicação está sendo executado quando a janela de blackout aparecer.

No Avamar v5 SP1, a coleta de lixo terá prioridade sobre os backups se o sistema estiver começando a ficar cheio. Quando a coleta de lixo é iniciada, se o sistema estiver mais cheio do que o valor de aviso do disco (aproximadamente, 77% de utilização do servidor), todos os backups que estiverem em execução serão cancelados normalmente.

No Avamar v7, a coleta de lixo pode ser executada ao mesmo tempo em que os backups

Quando um sistema Avamar estiver se aproximando do limite de capacidade, devemos parar imediatamente de adicionar novos clients para evitar que a situação piore.

Se você tiver outra grade do Avamar em execução com um nível mais baixo de utilização do servidor, considere adicionar novos clients a ela, e não ao servidor que está ficando cheio.

Para resolver um problema de capacidade, nós devemos identificar quais clients são responsáveis por adicionar a maioria dos dados ao sistema Avamar.

A interface do Enterprise Manager fornece relatórios que retornam essas informações. Consulte no guia do administrador do Avamara seção "Taxas médias de alteração diária de servidor e client” para obter instruções sobre como acessar esses relatórios.

O script capacity.sh (executado a partir da linha de comando do nó do utilitário do Avamar) também pode ser usado para identificar quais clients têm a taxa de alteração mais alta.

Somente clientes Dell registrados podem acessar o conteúdo do link a seguir pelo site Dell.com/support
Consulte o artigo 336542 da KB: Como usar o script capacity.sh para entender as alterações diárias de dados em um sistema Avamar para obter mais detalhes sobre como usar o script capacity.sh.

Muitas vezes, os clients que "mais consomem" são aqueles que fazem backup de bancos de dados SQL ou de servidores de e-mail. Dessa forma, fique atento a esses casos em particular.

3. Reavalie as políticas de retenção.

Depois de identificar clients com altas taxas de alteração, reavalie as políticas de retenção para verificar se alguma delas pode ser diminuída para reduzir os requisitos de armazenamento a um nível aceitável.

Nota: É recomendável que as políticas de retenção sejam definidas para, no mínimo, 14 dias.

Se o sistema for antigo o suficiente para começar a expirar os backups retidos por mais tempo, depois de reduzir as políticas de retenção, esperamos ver um aumento na quantidade de dados removidos diariamente pela coleta de lixo. Monitore essa tendência com capacity.sh.

Se o sistema Avamar ainda não for antigo o suficiente para começar a expirar os backups, as políticas de retenção talvez precisem ser alteradas para que os backups mais antigos comecem, agora, a expirar.

 Se não for possível reduzir as políticas de retenção devido a requisitos regulamentares, considere a expansão do sistema Avamar ou a migração de clients para outro sistema Avamar menos utilizado.

4. Migre clients para um sistema Avamar alternativo

Se outro sistema Avamar estiver disponível, considere a possibilidade de migrar clients grandes ou com taxa de alteração alta, de sistemas mais utilizados para sistemas menos utilizados, usando a interface do Avamar Client Manager.
Nota: 

• É preciso que o novo Avamar Server tenha espaço de armazenamento suficiente para os Avamar Clients que você deseja migrar
• Mantenha os clients com tipos semelhantes de dados no mesmo sistema Avamar para aproveitar o bom desempenho da desduplicação.
• Essa estratégia é usada de forma melhor onde os sistemas Avamar ficam mesma rede local

5. Exclua backups antigos.

Se o nível de utilização da capacidade do usuário for grave (superior a 90%), talvez seja necessário expirar backups antigos por meio da interface de gerenciamento de backups ou com a ferramenta modify-snapups. 

Somente clientes Dell registrados podem acessar o conteúdo do link a seguir pelo site Dell.com/support
Consulte o artigo 333438 da KB: Gerenciamento de capacidade do Avamar: Como excluir ou expirar backups em massa com a ferramenta "modify-snapups"  

A exclusão dos backups não reduzirá imediatamente o nível de utilização do servidor.  O que a exclusão faz é permitir que a coleta de lixo comece a remover os dados na próxima vez em que for executada.  A exclusão de backups antigos é uma solução temporária. Os backups simplesmente serão substituídos nos próximos dias. Se os backups forem excluídos, também será indispensável ajustar as políticas de retenção.

6. Aumente a janela de blackout.

Agora que excluímos backups e reduzimos as políticas de retenção, podemos permitir que a coleta de lixo comece a liberar espaço no sistema.

Para permitir que a coleta de lixo remova o máximo possível de dados, a janela de blackout deve ser aumentada a partir do nível padrão. O tempo que será definido para a janela de blackout dependerá de vários fatores. No entanto, para os primeiros dias, você deve considerar um aumento.

7. Monitore a alteração de dados usando capacity.sh

Depois que os backups forem excluídos e as políticas de retenção forem alteradas, monitore atentamente a quantidade de alterações de dados no sistema usando o script capacity.sh. Você deve começar a ver o aumento do valor de dados "removed", e o valor "Net Change" deve se tornar negativo. Eventualmente, à medida que os dados em excesso são apagados do sistema, o valor "removed" começa a retornar a níveis mais normais. Quando isso ocorrer, você poderá reduzir gradualmente a duração da janela de blackout. Continue a monitorar o valor "removed".

Se o valor "Net Change" não ficar negativo, verifique o log de coleta de lixo para ver por quanto tempo a coleta de lixo está realmente sendo executada e a quantidade de trabalho que ela está realizado dentro das janelas de blackout.

Somente clientes Dell registrados podem acessar o conteúdo do link a seguir pelo site Dell.com/support
Consulte o artigo 336542 da KB: Como usar o script capacity.sh para entender as alterações diárias de dados em um sistema Avamar

8. Expandindo o sistema Avamar

 Muitas vezes, a alta utilização no sistema Avamar se deve ao crescimento de dados natural e esperado. Para continuar os backups de produção, é preciso disponibilizar mais espaço.

 Como isso pode ser feito depende do tipo de sistema Avamar.

•  Sistemas de único nó e sistemas Avamar Virtual Edition (AVE)

Eles não podem ser expandidos. Encomende um segundo sistema Avamar maior e peça para os Serviços profissionais da EMC realizarem uma migração do sistema menor para o maior. Os Serviços profissionais podem ser engajados por meio do gerente da conta da EMC.
O novo sistema pode ser um sistema de único nó, vários nós ou AVE, desde que ele forneça mais espaço de armazenamento do que o de origem.

• Sistemas de vários nós

Esses sistemas podem ser expandidos para até 16 nós de dados. Entre em contato com o gerente da conta da EMC para obter detalhes. 
As adições de nós não são realizadas por canais de suporte regulares, portanto, um SR não deve ser aberto para solicitar esse trabalho.

• Integre o Data Domain

A integração de um sistema Data Domain como um dispositivo de armazenamento de back-end é uma maneira útil de expandir a capacidade disponível para clients que fazem backup no Avamar. Discuta as opções com seu gerente da conta da EMC.

Ferramentas úteis

• status.dpn
• capacity.sh
• Avalanche
• Relatório de resumo do DPN
• replcnt.sh
• Avamar Client Manager

Práticas recomendadas:

• Tente impedir que o valor de utilização do Avamar Server (capacidade do usuário) fique superior a 80%.
• A menor utilização da capacidade do usuário oferece resiliência em relação às alterações inesperadas na quantidade de dados adicionados e pode proteger contra a inutilização do sistema em caso de falhas inusitadas ou problemas temporários com tarefas de manutenção.
• Um sistema Avamar executado com uma utilização da capacidade do usuário superior a 80% exige que o administrador do sistema realize um monitoramento substancialmente mais cuidadoso para garantir que as tarefas de manutenção sejam concluídas com êxito e que o sistema não se torne somente leitura.