Data Domain: Como resolver problemas relacionados à alta utilização de espaço ou à falta de capacidade disponível em DDRs (restauradores do Data Domain)

 

• Essa é a área do disco onde residem os arquivos/dados recém-incluídos e, na maioria dos DDRs, os arquivos permanecem nela até que eles expirem/sejam excluídos por um aplicativo de backup do client
• Nos DDRs configurados com retenção estendida (ER) ou retenção a longo prazo (LTR), periodicamente, o processo de movimentação de dados pode ser executado para migrar arquivos antigos do nível ativo para os níveis de arquivamento ou de nuvem
• A única maneira de recuperar o espaço do nível ativo que foi usado pelos arquivos excluídos/migrados é executando o processo de coleta de lixo/limpeza (GC)

• O nível ativo pode começar a ficar sem espaço disponível, causando a exibição de alertas/mensagens como os seguintes:

• Se o nível ativo ficar 100% completo, dados novos não poderão ser gravados no DDR, o que pode fazer com que os backups/a replicação apresentem falha. Neste cenário, podem ser exibidos alertas/mensagens como estes:

• Em algumas circunstâncias, o fato de o nível ativo ficar cheio poderá tornar o Data Domain File System (DDFS) somente leitura. Nesse ponto, os arquivos existentes não poderão ser excluídos

• Explicar por que o nível ativo pode ficar cheio
• Descrever um conjunto simples de verificações que podem ser realizadas para determinar a causa da alta utilização do nível ativo e as etapas corretivas correspondentes

• este artigo não é completo (por exemplo, pode haver um número reduzido de situações em que o nível ativo de um DDR se torna altamente utilizado/completo por um motivo não discutido neste documento). No entanto, ele aborda as causas e problemas mais comuns
• Este artigo não abrange a alta utilização de níveis de nuvem ou de arquivamento

  O nível ativo de um DDR pode ter uma utilização maior do que o esperado por vários motivos:

• Os arquivos de backup/savesets não estão sendo expirados/excluídos corretamente por aplicativos de backup do client devido a uma configuração do aplicativo de backup ou política de retenção incorreta
• Um atraso na replicação faz com que um grande volume de dados antigos seja mantido no nível ativo e a replicação para réplicas fica pendente
• Os dados que estão sendo gravados no nível ativo têm uma taxa de compactação geral menor que a esperada
• O sistema não foi dimensionado corretamente, por exemplo, ele é muito pequeno para o volume de dados a ser armazenado nele
• Os backups consistem em vários arquivos muito pequenos, e esses arquivos consomem muito mais espaço do que o esperado quando são gravados inicialmente. No entanto, esse espaço deve ser recuperado durante a coleta de lixo/limpeza
• A movimentação de dados não é executada regularmente em sistemas configurados com ER/LTR, o que faz com que os arquivos antigos sejam migrados para os níveis de arquivamento/nuvem para permanecerem no nível ativo
• A limpeza/coleta de lixo não está sendo executada regularmente
• Snapshots de mtree excessivos ou antigos existentes no DDR estão impedindo a limpeza do espaço de recuperação de dados/arquivos excluídos

Etapa 1 - Determinar se a limpeza do nível ativo precisa ser executada

O Data Domain Operating System (DDOS) tenta manter um contador chamado "Cleanable GiB" para o nível ativo. Ele é uma estimativa da quantidade de espaço físico (pós-compactação) que poderia ser recuperada no nível ativo por meio da execução de limpeza/coleta de lixo. Esse contador é mostrado pelos comandos 'filesys show space'/'df':
 
Se:

• O valor de 'Cleanable GiB' for grande
• O DDFS tiver ficado 100% cheio (ficando, portanto, somente leitura)

A limpeza deve ser realizada e pode ser executada até a conclusão antes da realização das outras etapas deste documento. Para começar a limpeza, o comando 'filesys clean start' deve ser usado, por exemplo:
 
Para confirmar se a limpeza foi iniciada como esperado, o comando 'filesys status' pode ser usado, por exemplo:
 
Observe que:

• Se a limpeza não for iniciada, entre em contato com o fornecedor de suporte contratado para obter assistência adicional. Isso pode indicar que o sistema encontrou um "erro de segmento ausente", causando a desativação da limpeza
• Se a limpeza já estiver em execução, a mensagem a seguir será exibida quando você tentar iniciá-la:

• Nenhum espaço no nível ativo será liberado/recuperado até que a limpeza atinja a fase de cópia (por padrão, fase 9 no DDOS 5.4.x e anteriores, fase 11 no DDOS 5.5.x e posteriores). Para obter mais informações sobre as fases usadas pela limpeza, consulte: https://support.emc.com/kb/446734
• A limpeza pode não recuperar a quantidade de espaço indicada por 'Cleanable GiB', pois esse valor é apenas uma estimativa. Para obter mais informações sobre isso, consulte: https://support.emc.com/kb/485637
• A limpeza pode não recuperar todo o espaço possível em uma única execução. Isso ocorre porque, em DDRs que contêm conjuntos de dados muito grandes, a limpeza ocorre em relação à porção do sistema de arquivos que contém os dados mais supérfluos (por exemplo, para oferecer melhor resultado de liberação de espaço pelo tempo necessário para a execução da limpeza). Em alguns cenários, a limpeza pode precisar ser executada várias vezes antes que todo o espaço possível seja recuperado
• Se o valor de 'Cleanable GiB' era muito grande, isso pode indicar que a limpeza não foi executada em intervalos regulares. Verifique se um agendamento de limpeza foi definido:

Depois que a limpeza tiver sido concluída, use os comandos 'filesys show space'/'df' para determinar se os problemas de utilização foram resolvidos. Se a utilização ainda estiver alta, siga as etapas restantes deste artigo.

Etapa 2 - Verificar se há grandes quantidades de atraso de replicação em relação aos contextos de replicação de origem

A replicação nativa do Data Domain foi projetada com base no conceito de "contextos de replicação". Por exemplo, quando os dados precisam ser replicados entre sistemas:

• Os contextos de replicação são criados nos DDRs de origem e de destino
• Os contextos são inicializados
• Quando a inicialização for concluída, a replicação enviará periodicamente atualizações/deltas da origem para o destino para manter os dados sincronizados nos sistemas

Se um contexto de replicação de origem atrasar, isso pode fazer com que os dados antigos sejam mantidos no disco no sistema de origem (observe que o atraso em contextos de replicação não pode causar excesso de utilização no sistema de destino):

• Contextos de replicação de diretório (usados durante a replicação de uma única árvore de diretório em /data/col1/backup entre sistemas):

•  Contextos de replicação de mtree (usados durante a replicação de qualquer mtree diferente de /data/col1/backup entre os sistemas):

• Contextos de replicação de conjunto (usados durante a replicação de todo o conteúdo de um DDR para outro sistema):

 Para determinar se os contextos de replicação estão atrasados, as etapas a seguir devem ser realizadas:

• Determine o nome do host do sistema atual:

• Determine a data/hora do sistema atual:

• Liste os contextos de replicação configurados no sistema, juntamente com o "horário da última sincronização". Observe que contextos de interesse são aqueles em que o "destino" não contém o nome do host do sistema atual (que indica que o sistema atual é a origem) e o "horário da última sincronização" é significativamente antigo:

Contextos para os quais o sistema atual é a origem e que exibem atrasos significativos ou contextos que não são mais necessários devem ser interrompidos. Isso pode ser feito executando o seguinte comando nos sistemas de origem e de destino:
 
Por exemplo, para interromper os contextos "interessantes" mostrados acima, os seguintes comandos seriam executados na origem e no destino:
 
Observe que:

• quando os contextos forem interrompidos, a limpeza do nível ativo precisará ser realizada para recuperar o espaço possível no nível ativo
• Se a replicação de mtree for usada quando os contextos forem interrompidos, os snapshots de replicação de mtree poderão permanecer no disco. Siga a Etapa 5 para expirar os snapshots supérfluos antes de executar a limpeza
• Se a mtree de origem/destino estiver configurada para migrar dados para níveis de arquivamento ou nuvem, é preciso tomar cuidado ao interromper os contextos de replicação de mtree correspondentes, pois esses contextos podem não ser recriados/inicializados novamente no futuro. Isso acontece porque quando um contexto de replicação de mtree é inicializado, um snapshot de mtree é criado no sistema de origem e contém detalhes de todos os arquivos na mtree (independentemente do nível). Em seguida, esse snapshot é replicado de modo completo para o nível ativo de destino. Como resultado, se o nível ativo de destino não tiver espaço livre suficiente para incluir todos os dados da mtree de origem, a inicialização não poderá ser concluída. Para obter mais informações sobre esse problema, entre em contato com o fornecedor de suporte contratado
• Se um contexto de replicação de conjunto for interrompido, o contexto não poderá ser recriado/inicializado sem primeiro destruir a instância do DDFS no DDR de destino (e perder todos os dados no sistema). Como resultado, uma inicialização subsequente poderá consumir uma quantidade considerável de largura de banda da rede/tempo, uma vez que todos os dados da origem devem ser fisicamente replicados de volta para o destino

Etapa 3 - Verificar se há mtrees que não são mais necessárias

O conteúdo do DDFS é dividido logicamente em mtrees. É comum que os clients/aplicativos de backup individuais gravem em uma mtree individual. Se um aplicativo de backup for desativado, ele não poderá mais gravar/excluir dados do DDR, o que pode deixar mtrees antigas/supérfluas no sistema. Os dados nessas mtrees continuarão a existir indefinidamente usando espaço em disco no DDR. Como resultado, qualquer mtree supérflua deve ser excluída. Por exemplo:

• Obtenha uma lista de mtrees no sistema:

• Todas os mtrees que não forem mais necessárias devem ser excluídas com o comando 'mtree delete', por exemplo:

• O espaço consumido no disco pela mtree excluída será recuperado na próxima vez que a coleta de lixo/limpeza do nível ativo for executada.

Observe que:

• mtrees que forem destinos para replicação de mtree (por exemplo, com um status RO/RD no resultado da lista de mtrees) devem ter seu contexto de replicação correspondente interrompido antes que a mtree seja excluída
• As mtrees usadas como unidades de armazenamento lógico (LSUs) de DDBoost ou como pools de VTL (Virtual Tape Library, biblioteca de fitas virtuais) não podem ser excluídas com o comando 'mtree delete'. Consulte o Guia de administração do Data Domain para obter mais detalhes sobre a exclusão dessas mtrees
• As mtrees configuradas para bloqueio de retenção (por exemplo, com um status RLCE ou RLGE) não podem ser excluídas. Em vez disso, os arquivos individuais na mtree devem ter os bloqueios de retenção revertidos e ser excluídos individualmente. Consulte o Guia de Administração do Data Domain para obter mais detalhes

Etapa 4 - Verificar se há snapshots antigos/supérfluos de mtrees

Um snapshot do Data Domain representa um snapshot pontual da mtree correspondente. Como resultado:

• Todos os arquivos que existirem na mtree quando o snapshot for criado serão referenciados pelo snapshot
• Enquanto o snapshot continuar a existir, mesmo se esses arquivos forem removidos/excluídos, a limpeza não será capaz de recuperar o espaço físico usado no disco. Isso ocorre porque os dados devem permanecer no sistema caso a cópia do arquivo no snapshot seja acessada mais tarde

Para determinar se as mtrees têm snapshots antigos/supérfluos, as seguintes etapas devem ser realizadas:

• Obtenha uma lista de mtrees no sistema usando o comando 'mtree list', conforme mostrado na Etapa 3
• Liste os snapshots que existem para cada mtree usando o comando 'snapshot list':

• Onde existirem snapshots, use o resultado de 'snapshot list mtree [nome da mtree]' para determinar os snapshots que:

• Se o comando de lista de snapshots for executado novamente, esses snapshots agora serão listados como expirados:

Observe que:

• não é possível determinar o volume de dados físicos de um snapshot individual ou conjunto de snapshots mantém no disco. O único valor de "espaço" associado a um snapshot é uma indicação do tamanho compactado (lógico) da mtree quando o snapshot foi criado (como mostrado no resultado acima)
• Os snapshots nomeados como 'REPL-MTREE-AUTO-AAAA-MM-DD-HH-MM-SS' são gerenciados pela replicação de mtree e, em circunstâncias normais, não precisam ser expirados manualmente (a replicação expirará automaticamente esses snapshots quando eles não forem mais necessários). Se tais snapshots forem extremamente antigos, isso indica que o contexto de replicação correspondente provavelmente está mostrando um atraso significativo (conforme descrito na Etapa 2)
• Os snapshots nomeados como 'REPL-MTREE-RESYNC-RESERVE-AAAA-MM-DD-HH-MM-SS' são criados pela replicação de mtree quando um contexto de replicação de mtree é interrompido. Eles podem ser usados para evitar uma ressincronização completa dos dados de replicação se o contexto interrompido for posteriormente recriado (por exemplo, se o contexto foi interrompido por engano). Se a replicação não tiver que ser restabelecida, esses contextos poderão ser expirados manualmente, conforme descrito acima
• Os snapshots expirados continuarão a existir no sistema até a próxima vez que a coleta de lixo/limpeza for executada. Nesse momento, eles serão excluídos fisicamente e serão removidos do resultado de 'snapshot list mtree [nome da mtree]'. A limpeza poderá, então, recuperar qualquer espaço que os snapshots estavam usando no disco

Etapa 5 - Verificar se há um número inesperado de arquivos antigos no sistema

Os Autosupports do DDR contêm histogramas que mostram a divisão dos arquivos no DDR por data de criação. Por exemplo:
 
Isso pode ser útil para determinar se há arquivos no sistema que ainda não foram expirados/excluídos conforme esperado pelo aplicativo de backup do client. Por exemplo, se o sistema acima tiver sido gravado por um aplicativo de backup em que o período de retenção máximo para qualquer arquivo era de 6 meses, é óbvio que o aplicativo de backup não está expirando/excluindo arquivos conforme o esperado, pois há aproximadamente 80.000 arquivos com mais de 6 meses no DDR.

Observe que:

• É de responsabilidade do aplicativo de backup realizar a expiração/exclusão de todos os arquivos
• Um DDR nunca expirará/excluirá arquivos automaticamente. A menos que instruído pelo aplicativo de backup para excluir explicitamente um arquivo, o arquivo continuará a existir no DDR usando espaço indefinidamente

Como resultado, problemas como esse devem ser primeiro investigados pela equipe de suporte dos fornecedores de aplicativos de backup.

Se necessário, o suporte do Data Domain pode oferecer outros relatórios para:

• Determinar o nome/a hora de modificação de todos os arquivos em um DDR ordenados por data de criação (assim, o nome/local dos dados antigos pode ser determinado)
• Dividir os histogramas da data de criação do arquivo em relatórios separados para o nível ativo/de arquivamento/em nuvem (em que os recursos ER/LTR estão ativados)

Para fazer isso:

• Colete evidências conforme descrito no parágrafo "Coleta de sfs_dump" da seção Observações deste documento
• Abra um chamado para o fornecedor de suporte contratado

Quando os arquivos antigos/supérfluos forem excluídos, a coleta de lixo/limpeza do nível ativo precisará ser executada para recuperar fisicamente o espaço no nível ativo

Etapa 6 - Verificar se há backups que incluam um grande número de arquivos pequenos

Devido ao design do DDFS, os arquivos pequenos (essencialmente, qualquer arquivo que seja menor do que aproximadamente 10 MB) podem consumir espaço excessivo quando gravados inicialmente no DDR. Isso acontece porque a arquitetura "SISL" (Stream Informed Segment Layout) faz com que os arquivos pequenos consumam vários blocos individuais de 4,5 MB de espaço em disco. Por exemplo, um arquivo de 4 KB pode consumir até 9 MB de espaço em disco físico quando gravado inicialmente.

Esse espaço excessivo é recuperado subsequentemente quando a coleta de lixo/limpeza é executada (porque os dados de arquivos pequenos são agregados em um número menor de blocos de 4,5 MB). Mas isso pode fazer com que modelos menores do DDR gerem utilização e preenchimento excessivos quando esses backups são executados.

Os autosupports contêm histogramas de arquivos divididos por tamanho, por exemplo:
 
Se houver evidências de backups gravando números muito grandes de arquivos pequenos, o sistema pode ser afetado por aumentos temporários significativos na utilização entre cada invocação de coleta de lixo/limpeza. Nesse cenário, é preferível alterar a metodologia de backup para incluir todos os arquivos pequenos em um único arquivamento maior (como um arquivo tar) antes de gravá-los no DDR. Observe que os arquivamentos não devem ser compactados ou criptografados (porque isso danificará a taxa de compactação/desduplicação dos dados).

Etapa 7 - Verificar se a taxa de desduplicação é menor que a esperada

O principal objetivo de um DDR é desduplicar e compactar os dados incluídos pelo dispositivo. A taxa de desduplicação/compactação depende bastante do caso de uso do sistema e do tipo de dados que ele contém. No entanto, em muitos casos, haverá uma taxa de compactação geral "esperada" com base nos resultados obtidos pelo teste de prova de conceito ou semelhante. Para determinar a taxa de compactação geral atual do sistema (e, portanto, se ela está atendendo às expectativas), o comando 'filesys show compression' pode ser usado. Por exemplo:
 
No exemplo acima, o sistema está atingindo uma taxa de compactação geral de 65,3 x para o nível ativo (o que é muito bom). Se, no entanto, esse valor mostrar que a taxa de compactação geral não está atendendo às expectativas, provavelmente será necessário realizar uma investigação mais profunda. Observe que a investigação de uma taxa de compactação menor que a esperada é um assunto complexo que pode ter muitas causas raíz. Para obter mais informações sobre como fazer essa investigação, consulte este artigo: https://support.emc.com/kb/487055

Etapa 8 - Verificar se o sistema é uma origem de replicação de conjunto

Ao usar a replicação de conjunto, se o sistema de origem for fisicamente maior do que o destino, o tamanho do sistema de origem será artificialmente limitado para corresponder ao do destino (por exemplo, uma área de disco na origem será marcada como inutilizável). Isso ocorre porque, ao usar a replicação de conjunto, o destino precisa ser uma cópia em nível de bloco da origem. No entanto, se a origem for fisicamente maior do que o destino, os dados excessivos poderão ser gravados na origem, mas não replicados para o destino (já que ele já está cheio). Esse cenário é evitado com a limitação do tamanho da origem para corresponder ao destino.

• Usando os comandos da Etapa 2, verifique se o sistema é uma origem para a replicação de conjunto. Para fazer isso, execute 'replication status' e determine se há contextos de replicação iniciando com 'col://' (indicando a replicação de conjunto) que NÃO contêm o nome do host do sistema local no destino (indicando que esse sistema deve ser uma origem para o contexto de replicação)
• Se o sistema for uma origem para a replicação de conjunto, verifique o tamanho de cada nível ativo do sistema fazendo login em ambos e executando o comando 'filesys show space'. Compare o tamanho de 'post-comp' dos níveis ativos de cada sistema
• Se a origem for significativamente maior do que o destino, o tamanho do nível ativo será artificialmente limitado
• Para permitir que todo o espaço da origem seja utilizado pelos dados, faça o seguinte:

Etapa 9 - Verificar se a movimentação de dados está sendo executada regularmente

Se o DDR estiver configurado com retenção estendida (ER) ou retenção a longo prazo (LTR), ele terá um segundo nível de armazenamento conectado (nível de arquivamento para ER ou nível da nuvem para LTR). Nesse cenário, as políticas de movimentação de dados provavelmente são configuradas em relação às mtrees para migrar dados mais antigos/não modificados que exigem retenção a longo prazo do nível ativo para o nível alternativo de armazenamento, de forma que o espaço utilizado por esses arquivos no nível ativo possa ser fisicamente recuperado pela coleta de lixo/limpeza. Se as políticas de movimentação de dados forem configuradas incorretamente ou se o processo de movimentação de dados não for executado regularmente, os dados antigos permanecerão no nível ativo por mais tempo do que o esperado e continuarão a usar o espaço físico no disco.

• Inicialmente, confirme se o sistema está configurado para ER ou LTR executando 'filesys show space' e verificando a existência de um nível de arquivo ou de nuvem. Observe que, para serem utilizados, esses níveis alternativos de armazenamento devem ter > 0 Gb após a compactação:

• Se o sistema estiver configurado com ER/LTR, verifique as políticas de movimentação de dados em relação às mtrees para garantir que elas estejam conforme o esperado e definidas de forma que os dados antigos sejam enviados para o nível alternativo de armazenamento:

• Se o sistema estiver configurado com ER/LTR, verifique se a movimentação de dados está agendada para ser executada em intervalos regulares para migrar fisicamente arquivos/dados do nível ativo para o armazenamento alternativo:

• Se o sistema estiver configurado para ER/LTR, verifique a última vez em que a movimentação de dados foi executada:

• Depois que a movimentação de dados for concluída, a limpeza do nível ativo deve ser executada (observe que ela pode ser configurada para ser iniciada automaticamente após a conclusão da movimentação de dados) para garantir que o espaço usado pelos arquivos migrados no nível ativo seja fisicamente liberado:

Etapa 10 - Adicionar mais armazenamento ao nível ativo

Se todas as etapas anteriores tiverem sido realizadas, a limpeza do nível ativo tiver sido concluída e, mesmo assim, não houver espaço suficiente disponível no nível ativo, é provável que o sistema não tenha sido dimensionado corretamente para a carga de trabalho que está recebendo. Nesse caso, realize uma das seguintes ações:

• Reduza a carga de trabalho no sistema. Por exemplo:

• Adicione mais armazenamento ao nível ativo do sistema e expanda seu tamanho:

O suporte do Data Domain pode gerar vários relatórios que mostram informações como:

• Uma lista de todos os arquivos em um nível específico (por ex., ativo/arquivamento/nuvem) ordenados por data de criação
• Tamanho estimado e taxa de compactação por mtree/árvore de diretório principal
• Uma lista de todos os arquivos em uma mtree específica ordenados por data de criação
• e assim por diante

Para isso, as seguintes informações devem ser coletadas:

• Um novo pacote de suporte do DDR - acesse a seguinte página para obter mais informações: https://support.emc.com/kb/323283
• O resultado de 'sfs_dump' ou 'sfs_dump-c':

• Um relatório do local do arquivo (necessário se o sistema estiver configurado para ER ou LTR):

Para obter assistência na coleta das informações acima ou em qualquer uma das etapas dessa limpeza de arquivamento, entre em contato com seu fornecedor de suporte contratado.