Solução de problemas de desduplicação e taxa de compactação insatisfação de arquivos nos DDRs (Data Domain Restorers)

Os DDRs (Data Domain Restorers) foram projetados para armazenar grandes volumes de dados lógicos (pré-compactados) usando o mínimo de espaço físico (pós-compactado). Isso é feito usando:

• Desduplicação de dados incluídos para remover fragmentos duplicados de dados que já estão armazenados em disco no DDR, deixando apenas dados exclusivos
• Compactação de dados exclusivos antes que esses dados sejam gravados fisicamente no disco.

A taxa geral de compactação de dados que um DDR pode incluir varia devido a vários fatores, como:

• Caso de uso
• Tipos de dados que estão sendo incluídos
• Configuração do aplicativo de backup

Quando configurados de modo ideal, os DDRs normalmente atingem uma taxa de compactação geral de 10 a 20 vezes (e, às vezes, podem mostrar taxas maiores do que essa). Por outro lado, no entanto, em alguns ambientes, a taxa de compactação geral pode ser menor do que isso, o que pode causar:

• O DDR esgota rapidamente sua capacidade útil
• Impacto no desempenho de backup, restauração ou replicação
• Uma falha do DDR em atender às expectativas do cliente

Este artigo destina-se a discutir:

• Uma breve visão geral da desduplicação e compactação de dados em um DDR
• Como determinar a taxa de compactação geral para o sistema e os arquivos individuais
• Fatores que podem causar degradação à taxa de compactação geral

Como um Data Domain Restorer inclui novos dados?

• O aplicativo de backup envia dados (ou seja, arquivos) para o DDR.
• O DDR divide esses arquivos em fragmentos de 4 a 12 Kb de tamanho — cada fragmento é visto como um "segmento".
• O DDR gera uma "impressão digital" exclusiva (semelhante a um checksum) para cada segmento, dependendo dos dados contidos no segmento.
• As impressões digitais dos segmentos recém-entregues são verificadas nos índices de disco no DDR para determinar se o DDR já tem um segmento com a mesma impressão digital.
• Se o DDR já tiver um segmento com a mesma impressão digital, o segmento correspondente nos dados recém-entregues será uma duplicação e poderá ser descartado (ou seja, desduplicado).
• Depois que todos os segmentos duplicados forem removidos dos dados recém-entregues, somente segmentos exclusivos ou novos permanecerão.
• Esses segmentos exclusivos ou novos são agrupados em "regiões de compactação" de 128 Kb e, em seguida, compactados (usando o algoritmo lz por padrão).
• As regiões de compactação compactadas são compactadas em unidades de armazenamento de 4,5 Mb conhecidas como "contêineres", que são gravadas no disco rígido.

Como o DDR rastreia quais segmentos compõem um determinado arquivo?

Além da desduplicação/compactação de dados recém-recebidos, o DDR também cria uma "árvore de segmentos" para cada arquivo incluído. Esta é essencialmente uma lista de "impressões digitais" do segmento que compõem esse arquivo. Se o DDR precisar ler o arquivo posteriormente, ele:

• Determine o local da árvore de segmentos de arquivos.
• Leia a árvore de segmentos para obter uma lista de todas as impressões digitais do segmento que compõem a região do arquivo que está sendo lido.
• Use em índices de disco para determinar o local físico (ou seja, contêiner) dos dados no disco.
• Leia os dados do segmento físico dos contêineres subjacentes no disco.
• Use dados de segmento físico para reconstruir o arquivo.

As árvores de segmentos de arquivos também são armazenadas em contêineres de 4,5 Mb no disco e representam a maioria de cada arquivo "metadados" (discutido posteriormente neste artigo).

Como a taxa de compactação geral em um DDR pode ser determinada?

A utilização geral de um DDR (e a taxa de compactação) pode ser vista usando o comando "filesys show space". Por exemplo:

Active Tier:
Resource Size GiB Used GiB Use% Cleanable GiB*
---------------- -------- -------- --------- ---- --------------
/data: pre-comp - 115367.8 - -
/data: post-comp 679 4.2 6242.4 551,8 92% 202,5
/ddvar 49,2 9,1 37,6 20% -


---------------- -------- -------- --------- ---- -------------- neste caso, vemos que:

• Dados lógicos ou pré-compactados que são mantidos no DDR: 115367,8 Gb
• Espaço físico ou pós-compactado usado no DDR: 6242,4 Gb
• A taxa de compactação geral é 115367,8/6242,4 = 18,48x

A saída do comando "filesys show compression" confirma os dados mantidos, o espaço usado e a taxa de compactação. Por exemplo:

                   Pre-Comp Global-Comp Global-Comp Local-Comp Total-Comp
(GiB)
Factor (Reduction %)---------------- -------- --------- ----------- ---------- -------------

Currently Used:*   115367,8 6242,4 - - 18,5x (94,6) <=== NOTA
Escrita:                                                                          
  Últimos 7 dias 42214,7 1863,2 11,0x 2,1x 22,7x (95,6)
  Últimos 24 h 4924,8 274,0 8,8x 2,0x 18,0x (94,4)
---------------- -------- --------- ----------- ---------- ------------- Os números de utilização deoverall

no DDR são calculados da seguinte forma:

• Total de dados pré-compactados: A soma do tamanho pré-compactado (lógico) de todos os arquivos mantidos pelo DDR.
• Total de dados pós-compactados: O número de "contêineres" em uso no disco multiplicado por 4,5 Mb (o tamanho de um único contêiner).
• Tamanho total pós-compactação: O número máximo de "contêineres" que são criados devido ao espaço em disco disponível no sistema.

Estatísticas sobre o máximo em contêineres de uso estão disponíveis em autosupports. Por exemplo:

conjunto de contêineres 73fcacadea763b48:b66f6a65133e6c73:
...
    attrs.psize = 4718592 <=== Tamanho do contêiner em bytes
...
    attrs.max_containers = 1546057 <=== Máximo de contêineres possíveis
attrs.free_containers = 125562 <=== Contêineres
atualmente livres attrs.used_containers = 1420495 <=== Atualmente em contêineres de uso
...

Veja isso:
 
Como as taxas de desduplicação e compactação para um arquivo, diretório ou árvore de diretório individual podem ser determinadas?

Quando um arquivo é incluído, as estatísticas de registros DDR sobre o arquivo, inclusive:

• Bytes pré-compactados (lógicos)
• Tamanho de segmentos exclusivos após a desduplicação
• Tamanho de segmentos exclusivos após a desduplicação e a compactação
• Tamanho dos metadados do arquivo (ou seja, árvore de segmentos e assim por diante)

É possível fazer dump de algumas dessas estatísticas usando o comando "filesys show compression [path]", por exemplo, para relatar estatísticas de um só arquivo:

SE@DDVE60_JF## filesys show compression /data/col1/backup/testfile
Total files: 1;  bytes/storage_used: 2.9
Bytes originais:        3.242.460.364
globalmente compactados:        1.113.584.070
Localmente compactado:        1.130.871.915
Metadados:            4.772.672

Para relatar estatísticas de uma árvore inteira de diretórios:

SE@DDVE60_JF## filesys show compression /data/col1/backup
Total files: 3;  bytes/storage_used: 1.4
Bytes originais:        7.554.284.280
compactado globalmente:        5.425.407.986
Compactados localmente:        5.510.685.100
Metadados:           23.263.692

Observe, no entanto, que há algumas advertências sobre o uso dessas estatísticas:

• As estatísticas são geradas no momento da inclusão de arquivos ou dados e, depois disso, não são atualizadas. Devido ao funcionamento de um DDR, a inclusão de novos arquivos ou a exclusão de arquivos que referenciam os mesmos dados, e assim por diante, pode alterar a forma como um arquivo é desduplicado ao longo do tempo, fazendo com que essas estatísticas se tornem obsoletes.
• Além disso, certos casos de uso no DDR (como fastcopy de um arquivo e, em seguida, a exclusão do arquivo original) podem fazer com que essas estatísticas se tornem incorretas ou incorretas.

Como resultado, esses números devem ser considerados apenas como estimativas.

Os bytes pré-compactados não são necessariamente o tamanho lógico/pré-compactado do arquivo. Em vez disso, é o número total de bytes gravados em um arquivo durante sua vida útil. Como resultado, em determinados ambientes, os arquivos existentes geralmente são substituídos (como aqueles que usam a funcionalidade de biblioteca de fitas virtuais), essa figura pode ser maior que o tamanho lógico dos arquivos correspondentes.

A inclusão de dados de "baixa qualidade" pode causar degradação na taxa geral de compactação?

Sim — para um DDR alcançar uma boa taxa geral de compactação de dados incluídos, ele deve ser capaz de desduplicar e compactar esses dados. Há vários tipos de dados que podem impedir isso, conforme discutido abaixo:

Dados pré-compactados/pré-criptografados:

esses são tipos de dados compactados ou criptografados no sistema client ou pelo aplicativo de backup. Isso também pode incluir arquivos específicos do aplicativo que são compactados ou criptografados por design (por exemplo, arquivos de mídia) e arquivos de banco de dados que são compactados ou criptografados ou incorporados a objetos binários, como arquivos de mídia.

Devido à forma como o algoritmo de compactação ou criptografia funciona, uma alteração relativamente pequena nos dados subjacentes de um arquivo faz com que as alterações "dominem" em todo o arquivo. Por exemplo, um client pode conter um arquivo criptografado de 100 Mb no qual 10 Kb são modificados. Normalmente, o arquivo resultante seria idêntico antes e depois da modificação além da seção de 10 Kb que foi alterada. Quando a criptografia é usada, embora apenas 10 Kb de dados não criptografados sejam alterados antes e depois da modificação, o algoritmo de criptografia faz com que todo o conteúdo do arquivo seja alterado.

Quando esses dados são modificados regularmente e enviados periodicamente para um DDR, esse efeito de "cascata" faz com que cada geração do arquivo seja diferente das gerações anteriores do mesmo arquivo. Como resultado, cada geração contém um conjunto exclusivo de segmentos (e impressões digitais de segmento) para mostrar uma taxa de desduplicação insatisfação.

Observe também que, em vez de arquivos pré-compactados, é improvável que o algoritmo lz consiga compactar ainda mais os dados do segmento constituinte para que os dados não possam ser compactados antes de serem gravados no disco.

Como diretriz geral, a pré-compactação/pré-criptografia causa o seguinte:

• Dados pré-criptografados: Taxa de desduplicação insatisfação, mas taxa de compactação aceitável
• Dados pré-compactados: Taxa de desduplicação insatisfação e taxa de compactação insatisfação

Quando os mesmos dados pré-compactados/pré-criptografados (inalterados) são incluídos por um DDR várias vezes, a taxa de desduplicação dos dados melhora, pois, apesar do uso de algoritmos de compactação ou criptografia, um conjunto semelhante de segmentos (e impressões digitais de segmento) é visto durante cada backup.

Sempre que os dados possíveis enviados a um DDR não devem ser criptografados ou compactados , isso pode exigir a desativação da criptografia ou da compactação no client final ou no aplicativo de backup correspondente.

Para obter assistência na verificação, modificação de criptografia ou configurações de compactação em determinado backup, aplicativo client ou sistema operacional, entre em contato com o provedor de suporte apropriado.

Arquivos de mídia:

Determinados tipos de arquivo contêm dados pré-compactados ou pré-criptografados por padrão. Por exemplo:

• Arquivos PDF
• Determinados arquivos de áudio (mp3, wma, ogg e assim por diante)
• Arquivos de vídeo (avi, mkv e assim por diante)
• Arquivos de imagem (png, bmp, jpeg e assim por diante)
• Arquivos específicos de aplicativos (Microsoft Office, Open Office, Xml Office e assim por diante)

Os dados dentro dos arquivos são compactados ou criptografados pelo codec do arquivo e, como resultado, causam os mesmos problemas quando incluídos em um DDR, conforme descrito acima para dados pré-compactados ou pré-criptografados.

Arquivos com alta "exclusiva":

Alcançar uma boa taxa de desduplicação depende da DDR ver o mesmo conjunto de segmentos (e impressões digitais de segmento) várias vezes. No entanto, determinados tipos de dados contêm apenas dados transacionais exclusivos que, por padrão, contêm dados "exclusivos".

Se esses arquivos forem enviados a um DDR, cada geração do backup conterá um conjunto exclusivo de segmentos ou impressões digitais de segmento e, como resultado, verá a taxa de desduplicação degradada.

Exemplos desses arquivos são:

• Registros de transações de banco de dados (por exemplo, registros de arquivamento oracle).
• Registros de transações do Microsoft Exchange

O primeiro backup de um client "novo" para um DDR também pode causar esse problema (já que os dados não foram vistos anteriormente pelo DDR, portanto, os segmentos ou impressões digitais de segmento correspondentes no backup são exclusivos). Ao longo do tempo, no entanto, à medida que as gerações futuras do mesmo backup são enviadas para o DDR, a taxa de desduplicação de backups melhora à medida que menos segmentos em cada novo backup são exclusivos. Devido a isso, espera-se que a taxa geral de desduplicação ou compactação em um DDR recém-instalado que recebe principalmente novos backups esteja degradada, mas melhore ao longo do tempo.

Arquivos pequenos:

Arquivos pequenos causam vários problemas quando gravados em um DDR. São eles:

• Bloat de metadados — o DDR começa a conter uma quantidade maior do que o esperado de metadados de arquivo quando comparado aos dados físicos.
• Utilização insatisfação do contêiner - Por padrão (devido ao layout de segmento informado por fluxo do Data Domain ou arquitetura SISL), além do escopo deste documento), um contêiner de 4,5 Mb no disco só contém dados de um único arquivo. Como resultado, o backup de um único arquivo de 10 Kb, por exemplo, faz com que pelo menos um contêiner completo de 4,5 Mb seja gravado para esse arquivo. Isso pode significar que, para esses arquivos, o DDR usa consideravelmente mais espaço pós-compactação (físico) do que o volume correspondente de dados pré-compactados (lógicos) que estão sendo submetidos a backup, o que, por sua vez, causa uma taxa de compactação geral negativa.
• Taxa de desduplicação insatisfação : os arquivos menores que 4 Kb (o tamanho mínimo de segmento compatível em um DDR) consistem em um único segmento que é acolchoado a 4 Kb. Esses segmentos não são desduplicados, mas são gravados diretamente no disco. Isso pode fazer com que o DDR mantenha várias cópias do mesmo segmento (vistas como segmentos duplicados).
• Baixo desempenho de backup, restauração ou limpeza — há grandes sobrecargas durante o backup, a restauração ou a limpeza ao mover de um arquivo para o próximo (já que o contexto dos metadados que está sendo usado precisa ser alterado).

Veja isso:

• O impacto sobre o desempenho limpo ao usar arquivos pequenos foi reduzido, em certa medida, com a introdução da limpeza física ou da coleta de lixo no DDOS 5.5 e posterior.
• A limpeza tenta "desfazer" a utilização insatisfação do contêiner agregando dados de contêineres com baixa utilização em contêineres mais compactados durante a fase de cópia.
• A limpeza tenta remover segmentos duplicados excessivos durante a fase de cópia.

Apesar dos itens acima, o uso de grandes números de arquivos pequenos ou cargas de trabalho que consistem principalmente em arquivos pequenos deve ser evitado. É melhor combinar grandes números de arquivos pequenos em um só arquivo descompactado/não criptografado antes do backup do que enviar os arquivos pequenos para o DDR em seu estado nativo. Por exemplo, é muito melhor fazer backup de um único arquivo de 10 Gb contendo 1048576 arquivos individuais de 10 Kb do que todos os 1048576 individualmente.

Multiplexação excessiva por aplicativos de backup:

Os aplicativos de backup podem ser configurados para realizar multiplexação de dados entre os fluxos enviados ao dispositivo de backup, ou seja, os dados de fluxos de entrada (ou seja, clients diferentes) são enviados em um único fluxo para o dispositivo de backup. Essa funcionalidade é usada principalmente ao gravar em dispositivos de fita física como:

• Um dispositivo de fita física só pode suportar um único fluxo de gravação de entrada.
• O aplicativo de backup deve manter throughput suficiente para o dispositivo de fita a fim de impedir que a fita seja iniciada, interrompida ou retrocededa (também conhecida como remoção de calçados). Isso é mais fácil se o fluxo que vai para o dispositivo de fita contiver dados que estão sendo lidos de mais de um client.

No caso de um DDR, no entanto, isso faz com que um único arquivo no DDR contenha dados de vários clients que são intercalados em ordem arbitrária ou tamanhos de fragmentos. Isso pode causar uma taxa de desduplicação degradada, pois o DDR pode não conseguir notar com precisão segmentos duplicados de cada geração de um determinado backup de clients. Em geral, quando menor a granularidade da multiplexação, pior o impacto para a taxa de desduplicação.

Além disso, o desempenho da restauração pode ser ruim para restaurar determinados dados de clients, o DDR deve ler muitos arquivos ou contêineres em que a maioria dos dados nos arquivos ou contêineres é superfluente em relação aos backups de outros clients.

Os aplicativos de backup não devem usar multiplexação ao gravar em um DDR, pois os DDRs dão suporte a uma contagem de fluxo de entrada maior do que os dispositivos de fita física, com cada fluxo sendo capaz de gravar em uma velocidade variável. Como resultado, a multiplexação por aplicativos de backup deve ser desativada. Se o desempenho do backup for afetado após a desativação da multiplexação, então:

• Os aplicativos de backup usando CIFS, NFS ou OST (DDBoost) devem ter seu número de fluxos de gravação aumentado (para que mais arquivos possam ser gravados em paralelo no DDR).
• Ambientes que usam VTL devem adicionar unidades adicionais ao DDR, pois cada unidade permite o suporte a um fluxo de gravação paralelo adicional.

Se for necessária assistência na desativação da multiplexação ou se você quiser discutir a configuração recomendada de multiplexação para um aplicativo de backup específico, entre em contato com seu provedor de suporte contratado.

Aplicativos de backup que insere marcadores de fita excessivos:

Alguns aplicativos de backup podem inserir estruturas de dados repetidas em um fluxo de backup conhecido como "marcadores". Os marcadores não representam dados físicos no backup, mas são usados como um sistema de indexação ou posicionamento pelo aplicativo de backup.

Em algumas circunstâncias, a inclusão de marcadores em um fluxo de backup pode degradar a taxa de desduplicação, por exemplo:

• Na primeira geração de um backup, havia 12 Kb de dados que eram contíguos — isso foi reconhecido pela DDR como um segmento único.
• Na segunda geração do backup, no entanto, os mesmos 12 Kb de dados são divididos pela inclusão de um marcador de backup, que pode ser representado por 6 Kb de dados, marcador de backup, 6 Kb de dados.
• Como resultado, os segmentos criados durante a segunda geração do backup não correspondem aos gerados durante a primeira geração do backup, portanto, eles não são desduplicados corretamente.

Quanto mais próximos os marcadores forem mais próximos, maior será o impacto na taxa de desduplicação (por exemplo, um aplicativo de backup que insere marcadores a cada 32 Kb causa mais problemas do que um aplicativo de backup que insere marcadores a cada 1 Mb).

Para evitar esse problema, o DDR usa a tecnologia de reconhecimento de marcadores que permite:

• Marcadores de backup a serem removidos de modo transparente do fluxo de backup durante a inclusão do backup.
• Marcadores de backup a serem reinsertados no fluxo de backup durante a restauração do backup

Isso ajuda a impedir a fragmentação de dados ou segmentos por marcadores de backup e melhora a taxa de desduplicação dos backups correspondentes.

No entanto, para aproveitar ao máximo essa tecnologia, é importante que o DDR possa reconhecer corretamente os marcadores inseridos nos fluxos de backup. O DDR procura marcadores dependendo da configuração da opção "marker type", por exemplo:

SE@DDVE60_JF## filesys option show
Option Value
-------------------------------- --------
...
Tipo de marcador automático
...


-------------------------------- --------Usually isso deve ser deixado definido como "auto", pois isso permite que o DDR corresponda automaticamente aos tipos de marcador mais comuns. Se o sistema estiver incluindo dados de apenas um aplicativo de backup que insere marcadores, pode haver um benefício de desempenho ao especificar um tipo específico de marcador, ou seja:

# filesys option set marker-type {auto | nw1 | cv1 | tsm1 | tsm2 | eti1 fdr1 | hpdp1 | besr1 | ssrt1 | ism1 | bti1| none}

Veja que:

• Qualquer benefício para o desempenho ao selecionar um tipo específico de marcador provavelmente será mínimo.
• Selecionar um tipo de marcador incorreto pode causar degradação adicional significativa no desempenho de backup ou restauração e na taxa de desduplicação.

Como resultado, o Data Domain geralmente recomenda deixar o tipo de marcador definido como "automático". Para obter mais orientações sobre como modificar o tipo de marcador, entre em contato com seu provedor de suporte contratado.

Para sistemas que incluem dados de aplicativos que usam marcadores de backup, mas que não são reconhecidos pela tecnologia automatizada de tratamento de marcadores (como produtos do software BridgeHead), entre em contato com seu provedor de suporte contratado que pode trabalhar com o suporte do Data Domain para determinar as configurações necessárias no DDR para detectar o marcador fora do padrão.

Indicações de dados de "baixa qualidade" recebidos por um DDR:

A tabela a seguir lista as taxas esperadas de desduplicação e compactação para os diferentes tipos de dados listados acima. Esta lista não é exaustiva e, obviamente, pode haver alguma variação nas figuras exatas vistas em um determinado sistema devido à carga de trabalho ou aos dados que são incluídos pelo DDR:
 

Compactação global	Compactação local	Causa provável
Baixo (1 a 4x)	Baixo (1 a 1,5x)	Dados pré-compactados ou criptografados
Baixo (1 a 2x)	Alto (>2x)	Dados exclusivos, mas compactáveis, como registros de arquivamento de banco de dados
Baixo (2 a 5x)	Alto (>1,5x)	Marcadores que não são detectados, alta taxa de alteração de dados ou multiplexação de fluxo.
Alto (>10x)	Baixo (<1,5x)	Backups dos mesmos dados compactados ou criptografados. Isso é incomum.

Há certos fatores em um DDR que podem afetar a taxa de desduplicação geral?

Sim - Há vários fatores que podem fazer com que os dados antigos/superflousos sejam mantidos no disco em um DDR, o que causa um aumento no espaço em disco pós-compactado (físico) e uma queda na taxa geral de compactação. Esses fatores são discutidos abaixo.

Falha ao executar regularmente a limpeza do file system:

A limpeza do file system é a única maneira de remover fisicamente dados antigos/superflouses no disco que não estão mais sendo referenciados por arquivos no DDR. Como resultado, um usuário pode excluir vários arquivos do sistema (causando uma queda na utilização pré-compactada), mas não executar a limpeza (deixando alta a utilização física/pós-compactação). Isso causa uma queda na taxa geral de compactação.

O Data Domain recomenda que o agendamento de limpeza seja executado em intervalos regulares da seguinte maneira:

• DDR normal: Uma vez por semana
• DDR usando extended retention: Uma vez a cada duas semanas

A limpeza não deve ser executada mais de uma vez por semana, pois isso pode causar problemas com a fragmentação de dados no disco, que se manifesta como um desempenho ruim de restauração/replicação.

Snapshots antigos excessivos no sistema:

Os DDRs podem criar snapshots de mtree que representam o conteúdo de uma mtree no momento em que o snapshot foi criado. Observe, no entanto, que deixar snapshots antigos em um sistema pode causar um aumento na utilização física/pós-compactação, causando uma queda na taxa geral de compactação. Por exemplo:

• Existe uma mtree que contém muitos arquivos (portanto, a utilização pré-compactada é alta).
• Um snapshot da mtree é criado.
• Muitos arquivos são excluídos (fazendo com que a utilização pré-compactada seja suspensa).
• A limpeza do file system é executada — observe, no entanto, que o espaço mínimo do disco rígido é liberado como uma cópia dos arquivos excluídos permanece no snapshot de mtree, o que significa que os dados referenciados por esses arquivos não podem ser removidos do disco.
• Como resultado, a utilização física/pós-compactada permanece alta

O Data Domain recomenda que, se os snapshots de mtree forem usados (por exemplo, para recuperação de exclusão acidental de dados), eles sejam gerenciados usando agendamentos automatizados de snapshot, de modo que os snapshots sejam criados em intervalos regulares com um período de expiração definido (a quantidade de tempo antes que o snapshot seja removido automaticamente). Além disso, o período de expiração deve ser o mais curto possível (no entanto, obviamente, isso pode depender do caso de uso dos snapshots ou do nível de proteção que esses snapshots estão fornecendo). Isso impede a criação de snapshots antigos com um longo período de expiração.

Mais informações sobre como trabalhar com snapshots e agendamentos de snapshot estão disponíveis no seguinte artigo: Data Domain — gerenciando agendamentos de snapshots

Atraso excessivo de replicação:

A replicação nativa do Data Domain usa um registro de replicação ou snapshots de mtree (dependendo do tipo de replicação) para rastrear quais arquivos ou dados estão pendentes de replicação para um DDR remoto. Atraso de replicação é o conceito de réplica ficando para trás nas alterações no DDR de origem. Isso pode ocorrer devido a vários fatores, inclusive:

• Contextos de replicação desabilitados
• Largura de banda de rede insuficiente entre DDRs
• Desconexões frequentes de rede.

O grande atraso de replicação pode fazer com que o registro de replicação continue a conter referências aos arquivos que foram excluídos no DDR de origem ou snapshots de mtree antigos ou obsoletos nos DDRs de origem e destino. Conforme descrito acima, os dados mencionados por esses snapshots (ou o registro de replicação) não podem ser removidos fisicamente do disco no DDR, mesmo que os arquivos correspondentes tenham sido excluídos do sistema. Isso pode fazer com que a utilização física ou pós-compactada da DDR aumente, o que causa degradação da taxa de desduplicação.

Se os DDRs estão sofrendo com alta utilização, e acredita-se que isso seja devido ao atraso na replicação, entre em contato com seu provedor de suporte contratado para obter assistência adicional.

Há alterações de configuração ou certos fatores em um DDR que podem aumentar a taxa de compactação geral?

Sim — remover ou resolver os problemas discutidos anteriormente neste documento deve permitir que um DDR mostre uma taxa de compactação geral aprimorada ao longo do tempo. Há também vários fatores ou cargas de trabalho em um DDR, o que pode levar a um aumento na taxa de desduplicação. Geralmente, isso envolve:

• Redução da quantidade de espaço no disco rígido usado pelos arquivos no DDR (por exemplo, aumentando a agressividade do algoritmo de compactação usado pelo DDR)
• Repentinamente, aumentando a quantidade de dados pré-compactados (lógicos) no DDR sem um aumento correspondente na utilização física/pós-compactada

Modificação do algoritmo de compactação:

Por padrão, os DDRs compactam os dados que estão sendo gravados no disco com o algoritmo lz . Como mencionado anteriormente, o lz é usado, pois tem sobrecargas relativamente baixas em termos de CPU necessária para compactação ou descompactação, mas mostra eficácia razoável na redução do tamanho dos dados.

É possível aumentar a agressividade do algoritmo de compactação para fornecer mais economia na utilização pós-compactação ou do disco rígido (e, como resultado, melhorar a taxa geral de compactação). Os algoritmos de compactação compatíveis, em ordem de eficácia (de baixo para alto), são os seguintes:

• Lz
• gzfast
• Gz

Uma comparação geral de cada algoritmo é a seguinte:

• lz em comparação com o gzfast oferece compactação ~15% melhor e consome 2 CPUs.
• O lzem comparação com o gz oferece compactação ~30% melhor e consome 5 CPUs.
• o gzfast em comparação com o gz oferece compactação ~10 a 15% melhor.

Também é possível desativar completamente a compactação (especificar um algoritmo nenhum), no entanto, isso não é compatível para uso em sistemas do cliente e é apenas para testes internos.

De acordo com a tabela acima, quanto mais agressivo o algoritmo de compactação, mais CPU é necessária durante a compactação ou descompactação de dados. Devido a isso, as alterações em um algoritmo mais agressivo só devem ser feitas em sistemas que são levemente carregados sob carga de trabalho normal. Alterar o algoritmo em sistemas muito carregados pode levar a degradação extrema no desempenho de backup ou restauração e possíveis panes ou reinicializações do file system (causando uma interrupção do DDR).

Para obter mais informações sobre como alterar o tipo de compactação, consulte o seguinte artigo: Impacto da conversão em compactação do sistema Data Domain e do

desempenho de limpezaDevido ao possível impacto da alteração do algoritmo de compactação, recomenda-se que os clientes interessados em fazer isso entre em contato com o provedor de suporte contratado para discutir a alteração antes de prosseguir.

Uso de fastcopy do file system:

Os DDRs permitem o uso do comando "file system fastcopy" para copiar rapidamente um arquivo (ou árvore de diretórios). Essa funcionalidade cria um arquivo clonando os metadados de um arquivo existente (ou grupo de arquivos) para que, embora os novos arquivos não estejam fisicamente conectados ao arquivo original, eles consultem exatamente os mesmos dados no disco que o arquivo original. Isso significa que, independentemente do tamanho do arquivo original, o novo arquivo consome pouco espaço no disco (pois ele desduplica perfeitamente em relação aos dados existentes).

O resultado desse comportamento é que, quando o fastcopy do file system é usado, o tamanho pré-compactado (lógico) dos dados no DDR aumenta rapidamente, mas a utilização física/pós-compactada do DDR permanece estática.

Por exemplo, o seguinte DDR tem utilização da seguinte maneira (indicando a taxa de compactação geral de ~1,8x):

Nível ativo:
GiB de tamanho de recurso GiB usado GiB utilização% de GiB utilizável*
---------------- -------- -------- --------- ---- --------------
/dados: pré-compactação - 12,0 - -
/data: post-comp 71.5 6.8 64,7 10% 0,0
/ddvar 49.2 1.1 45,6 2% -
/ddvar/core 158.5 0.2 150.2 0% -
---------------- -------- -------- --------- ---- --------------

Contém um arquivo grande (/data/col1/backup/testfile):

!!! DDVE60_JF SEUS DADOS ESTÃO EM PERIGO DE !!! # ls -al /data/col1/backup/testfile-rw-r
--r-- 1 root root 3221225472 29 de julho 04:20 /data/col1/backup/testfile

O arquivo é fastcopied várias vezes:

sysadmin@DDVE60_JF# filesys fastcopy source /data/col1/backup/testfile destination /data/col1/backup/testfile_copy1
sysadmin@DDVE60_JF# filesys fastcopy source /data /col1/backup/testfile destination /data/col1/backup/testfile_copy2
sysadmin@DDVE60_JF# filesys fastcopy source /data/col1/backup/testfile destination /data/col1/backup/testfile_copy3

Isso faz com que a utilização pré-compactada aumente para pouca alteração na utilização pós-compactação:

Nível ativo:
GiB de tamanho de recurso GiB usado GiB uso% de GiB utilizável%
---------------- -------- -------- --------- ---- --------------/dados: pre-comp - 21.0 - - -
/data: post-comp 71.5 6.8 64.7 10% 0.0

/ddvar 49.2 1.1 45,6 2% -
/ddvar/core 158.5 0.2 150,2 0% -
---------------- -------- -------- --------- ---- --------------

Como resultado, o DDR agora mostra a taxa de compactação geral de ~3,1x.

Conforme mencionado acima, as estatísticas de compactação das cópias mostram que elas desduplicam perfeitamente:

sysadmin@DDVE60_JF# filesys show compression /data/col1/backup/testfile_copy1
Total files: 1;  bytes/storage_used: 21331976.1
Bytes originais:        3.242.460.364
globalmente compactados:                    0
Localmente compactado:                    0
Metadados:                  152

A funcionalidade Fastcopy não pode ser usada para melhorar a taxa de compactação geral, reduzindo a utilização física do DDR. No entanto, ela pode ser a causa da alta taxa de compactação geral (especialmente em ambientes que usam muito fastcopy, como o Avamar 6.x).