Data Domain: Uma visão geral das fases de limpeza/coleta de lixo (DDFS) do Data Domain File System (GC)

O File System do Data Domain (DDFS) é diferente de muitas implementações comuns de File System quando um arquivo é excluído do espaço do File System usado pelo arquivo não está imediatamente disponível para reutilização. O motivo para isso ocorre porque o Data Domain restorer (DDR) não sabe imediatamente se os dados que foram mencionados pelo arquivo excluído também estão sendo desduplicados em relação a outros arquivos e, portanto, se é seguro remover esses dados ou não.

A limpeza (às vezes chamada de coleta de lixo/GC) é o processo pelo qual um DDR:

• Determina quais dados em disco são supérfluos (ou seja, não é mais referido por objetos como, por exemplo, arquivos ou snapshots)
• O Remove fisicamente dados supérfluos que tornam o espaço em disco subjacente disponível para reutilização (ou seja, inclusão de novos dados)

O Clean/CG geralmente é agendado para ser executado em intervalos regulares (por padrão, ele começa às 6am todas as terças-feiras) e pode ser:

• Tempo de execução
• Computacionalmente caro

No entanto, observe que não há nenhuma relação com a execução de Clean/GC, no qual os dados podem ser removidos/ter espaço fisicamente liberado em um restorer do Data Domain (ou seja, não há nenhum atalho para acelerar esse processo).

Este artigo descreve o Clean/GC em mais detalhes, explicando:

• As fases que normalmente são executadas
• Os diferentes algoritmos de limpeza usados em várias versões de DDOS

Nenhuma

Cada vez que o Clean/CG é executado, ele tem duas principais finalidades, primeiramente, ele deve encontrar dados supérfluos no DDR uma visão geral de como isso é feito, da seguinte maneira:

• Clean/GC enumera o conteúdo do File System do DDFS, que procura objetos como, por exemplo, arquivos, snapshots e registros de replicação que atualmente existem no sistema
• Em seguida, ele determina todos os dados físicos no disco que são consultados ativamente por esses objetos.
• Os dados que são mencionados ativamente são considerados como "vivos" e não podem ser removidos da DDR caso contrário, os objetos que fazem referência a esses dados serão danificados (eles não poderão mais ser lidos, pois os dados subjacentes que dependeriam não existirão mais no disco)
• Os dados que não são informados ativamente por qualquer objeto são considerados como inativos e são supérfluos-esses dados podem ser removidos do sistema com segurança.
• Todos os dados em um DDR são empacotados em objetos de 4,5 MB de tamanho conhecidos como contêineres
• Por meio de limpeza de enumeração/GC pode determinar quais contêineres de 4,5 MB contêm dados inativos e o volume de dados inativos em cada
• Por padrão, a opção Clean/GC selecionará os contêineres de 4,5 MB > segurando dados de 8% inativos para o "processamento"

Além disso, é necessário remover os dados inativos no DDR-uma explicação resumida de como isso é feito, da seguinte maneira:

• Os contêineres selecionados para processamento são verificados novamente para confirmar que eles possuem um bom volume de dados inativos
• Os dados em tempo real são extraídos desses contêineres e gravados em novos contêineres de 4.5 MB no final do File System
• Uma vez concluída a seleção de contêineres selecionados (incluindo os dados inativos que eles contêm) são excluídos do disco fisicamente, libere espaço em disco

O processo de limpeza é dividido em uma série de "fases", com o número total da fase dependente de:

• A versão do DDOS sendo usada no DDR (portanto, o algoritmo limpo usado, por padrão, por essa versão do DDOS)
• A configuração/o conteúdo do sistema

Em geral, no entanto, o processo de resultado de dados "inativos" e a seleção de contêineres correspondentes ocorre em uma série de fases, enquanto a remoção de dados inativos é executada em uma fase única conhecida como "cópia". Por exemplo, certas versões de DDOS executaram as fases limpas da seguinte maneira:

1. Pré-Enumeração-enumera o conteúdo do File System do DDFS
2. Pre-Merge — execute uma mesclagem de índice do DDFS para garantir que a cópia mais recente das informações do índice seja descarregada para o disco
3. Pré-filtro-determine se há dados duplicados dentro do File System DDFS e, em caso afirmativo, se esse for
4. Pre-SELECT — determine quais contêineres de 4,5 MB devem ser "processados" pela limpeza
5. Copy — extrair fisicamente os dados em tempo real dos contêineres selecionados, gravá-los em novos contêineres e excluir contêineres selecionados
6. Resumo – vetores de Resumo de reconstrução (que são usados como uma otimização durante a inclusão de novos dados)

Nas fases de exemplo acima 1-4 são usadas para determinar onde existem dados "inativos" no DDR (chamado de "fases de enumeração" no restante deste documento), enquanto a fase 5 (cópia) é usada para remover fisicamente esses dados.

Lembre-se de que nenhum espaço será fisicamente liberado no sistema até que o Clean/CG atinja a fase de cópia. Como resultado, pode haver um atraso significativo entre a limpeza sendo iniciada e o espaço começando a ser liberado (devido ao processo de enumeração ter que ser executado pela primeira vez até a conclusão). Por esse motivo, o sistema não deve ter permissão para preencher o 100% completo antes que o Clean/CG seja iniciado.

As fases de enumeração tendem a ser caras em termos de utilisations de CPU (isto é, geralmente eles são vinculados à CPU), enquanto a fase de cópia é cara em termos de CPU e I/O (isto é, geralmente, a CPU e o limite de I/O). No resumo, no entanto, é possível supor que:

• O comprimento total das fases de enumeração depende da quantidade de dados no DDR que precisa ser enumerada
• O comprimento total da fase de cópia depende da quantidade de dados inativos no DDR que precisa ser removido e como os dados são fragmentados em disco (discutido mais abaixo)

A quantidade/funcionalidade das fases de enumeração depende da versão do DDOS usada em uma DDR.

DDOS 5,4 (e anterior)-algoritmo completo de limpeza: Executa 6 ou 10 fases (como mostrado acima):

• O conteúdo do File System do DDFS é enumerado de cima para baixo (isto é, é centrado em arquivos)
• O DDFS detecta todos os arquivos que existem no DDR e, em seguida, verifica cada arquivo por vez para determinar quais dados são referidos por esse arquivo
• Isso permite que o Clean/CG determine quais dados no disco são "Live"

DDOS 5,5 (e posterior)-algoritmo de limpeza física (PGC): Executa 7 ou 12 fases:

• O conteúdo do DDFS é enumerado de baixo para cima (isto é, ele não verifica mais arquivos individuais)
• O DDFS detecta metadados do File System que referenciam dados físicos no disco e verifica se os metadados para determinar quais dados são mencionados
• Isso permite que o Clean/CG determine quais dados no disco são "Live"
• Isso é feito por meio da adição de uma fase de "análise" (portanto, o aumento na quantidade de fases em relação ao algoritmo completo de limpeza)
• Na maioria dos casos, no entanto, a duração total da limpeza física deve ser menor do que a limpeza completa para o mesmo sistema (apesar de consistir em mais fases individuais)

DDOS 6,0 (e posterior)-algoritmo de limpeza físico perfeitos (PPGC):

• Isso é simplesmente uma otimização para o algoritmo de limpeza física e é discutido ainda mais abaixo

Observe que o DDOS mudou do algoritmo completo de limpeza para o algoritmo de limpeza física para aprimorar a escalabilidade/desempenho do processo de enumeração – devido à natureza superior à parte superior do algoritmo de limpeza completo que ele não dimensionou bem em DDRs com:

• Um grande número de arquivos pequenos (como o switch de contexto ao mover de enumeração de um arquivo para o próximo era caro/lento)
• Alta taxa de desduplicação (como vários arquivos nos quais os mesmos dados físicos são mencionados, para que os mesmos dados tenham sido enumerados várias vezes)

Os DDRs alternam de algoritmos de limpeza Full para físico ao fazer upgrade do DDOS 5,4 (ou anterior) para o 5,5 (ou posterior). A única exceção a isso é que os sistemas configurados com Extended Retention, em que o conteúdo do File System DDFS precisa ser verificado para arquivos "estendidos" antes que a limpeza física possa ser ativada. uma discussão desse processo está além do escopo deste documento, no entanto, esta verificação é executada automaticamente após o upgrade, e a limpeza física está habilitada na conclusão

desta Da mesma forma, os DDRs alternam de algoritmos físicos para perfeitos e perfeitos automaticamente após o upgrade do DDOS 5. x para o 6,0 (ou posterior). No entanto, observe que, no entanto, o algoritmo de limpeza física perfeita exige que os índices estejam no formato ' index 2,0 ' antes que ele possa ser usado. Observe que:

• O formato ' index 2,0 ' foi introduzido com DDOS 5,5 (portanto, todos os File Systems criados no 5,5 ou posterior já estarão usando o índice 2,0)
• Inicialmente, o File System criado no 5,4 ou anterior terá índices no formato de índice 1,0. Uma vez que o upgrade para DDOS 5,5 (ou posterior), os índices serão convertidos no formato 2,0 Format — a conversão ocorrerá sempre que o Clean for executado apenas aproximadamente 1% dos índices são convertidos durante cada limpeza, para que possam ser levados até dois anos (supondo execuções de limpeza semanalmente) para converter totalmente os índices no formato 2,0

Os DDRs que executam inicialmente DDOS 5,4 (ou anteriores), mas que, posteriormente, foram atualizados para DDOS 5,5 (ou posterior) podem ser forçados a converter índices no formato de indexação 2,0 por uma única "reconstrução de índice". No entanto, observe que uma reconstrução de índice exige um período de tempo inativo durante a reconstrução física das indexações — essa operação geralmente leva de 2-8 horas para ser concluída, dependendo do tamanho/volume de dados no DDR. Para discutir a realização de uma reconstrução de índice, entre em contato com seu fornecedor de suporte contratado.

Conforme mencionado acima, independentemente do algoritmo Clean/CG usado, a limpeza pode exigir um número variável de fases — por exemplo, o algoritmo completo de limpeza pode exigir 6 ou 10 fases. O motivo para isso é que:

• Quando o DDFS é iniciado, ele reserva uma quantidade fixa de memória a ser usada pelo Clean/GC
• Dentro desta memória, a limpeza/CG cria estruturas de dados para descrever os resultados da enumeração (ou seja, descrever onde existem dados ativos versus inativos no disco)
• Quando um DDR contém um volume relativamente pequeno de dados, todo o conteúdo do File System do DDFS pode ser descrito nesta área de memória.
• Em muitos sistemas, no entanto, isso não é possível e essa área de memória fica esgotada antes que todo o conteúdo do File System do DDFS fosse enumerado
• Como resultado, esses sistemas realizam a "amostra", o que aumenta o número de fases limpas necessárias

Quando o uso de amostragem for limpo, o GC:

• Execute uma amostra de amostra de enumeração em todo o File System — Observe que essa enumeração não é "Complete" (ou seja, ela não registra informações completas sobre cada parte do File System, mas, em vez disso, aproxima-se de informações para cada parte do File System)
• Use essas informações de amostragem para determinar qual parte do File System do DDFS se beneficiaria da maioria da execução limpa/GC em relação a ele (ou seja, qual parte do File System daria melhor retornos em termos de espaço sendo liberado se fosse limpo)
• Execute uma segunda rodada de enumeração completa em relação à parte selecionada do File System cujo conteúdo agora pode ser totalmente descrito dentro da memória reservada para GC

A amostragem será automaticamente ativada durante o Clean/GC se necessário, no entanto, fará com que:

• Um aumento no número de fases que precisam ser realizadas pelo Clean/GC
• Um aumento correspondente na duração total do Clean/GC

Antes do DDOS 6,0, a maioria dos DDRs realiza amostragem durante o Clean/GC (a menos que eles contenham um conjunto de dados relativamente pequeno). O algoritmo de limpeza física perfeita, no entanto, inclui vários optimisations para reduzir a quantidade de memória necessária para limpar/GC ao enumerar dados dentro do File System. Isso significa que muitos sistemas que estavam realizando uma amostra durante o Clean/GC no DDOS 5. x não mais precisarão de amostragem no DDOS 6,0 – isso reduz o número de fases realizadas pela limpeza e causa uma redução correspondente no tempo de execução total de limpeza (ou seja, melhoria no desempenho claro).

Não há nenhuma informação disponível para determinar diretamente se um sistema mudou do algoritmo de limpeza física para o algoritmo de limpeza física perfeita diferente de:

• Quando o sistema estava executando uma limpeza física no DDOS 5,5-5,7, ele estava realizando 12 fases durante a limpeza
• Depois que o sistema estiver recebendo upgrade para DDOS 6,0 (ou posterior), ele executará apenas 7 fases durante a limpeza

Se um sistema que executa DDOS 6,0 ainda precisa executar uma amostra, isso será ativado automaticamente durante a limpeza e fará a execução de 12 fases durante a limpeza.

Independentemente do algoritmo limpo usado na fase de cópia (onde os dados inativos são removidos fisicamente do sistema) funcionam de maneira semelhante em todas as versões. Geralmente, o desempenho da fase de cópia depende de:

• O volume de dados "inativos" que deve ser removido
• A "fragmentação" dos dados inativos (ou seja, como ele se espalha em todo o disco)

Conforme descrito acima, a cópia funciona, selecionando os contêineres de 4.5 MB que contêm dados inativos, extraindo todos os dados em tempo real desses contêineres e gravando os dados em tempo real em novos contêineres e, em seguida, excluindo os Os exemplos a seguir descrevem por que fragmentação dos dados inativos são importantes:

exemplo 1:

• 10 contêineres são selecionados para cópia (45 MB total de dados)
• Todos se esses contêineres não contiverem dados em tempo real (ou seja, os dados que eles têm são completamente não referenciados/inativos)
• Como uma cópia de resultado simplesmente precisa marcar esses contêineres como excluídos para liberar espaço físico do 45 MB no disco

Exemplo 2:

• os contêineres 100 são selecionados para cópia (450Mb total Data)
• Cada um desses contêineres contém 90% de dados em tempo real/10% de dados inativos
• Para processar essa cópia de contêineres, você deve:

Obviamente, uma quantidade significativamente maior de I/O e CPU é necessária para executar a cópia descrita no exemplo 2, em comparação com isso, no exemplo 1, por isso, isso levará significativamente mais tempo para liberar espaço físico 45 MB no disco neste exemplo.

Geralmente, os usuários não têm controle sobre a "fragmentação" de dados inativos em disco em uma DDR, pois isso depende do caso de uso/tipo de dados que estão sendo gravados no sistema. No entanto, observe que o Clean/CG mantém as estatísticas que ajudam a determinar a "fragmentação" dos dados inativos encontrados durante a fase de cópia (o que permite que um usuário determine se essa fragmentação pode explicar uma fase de cópia potencialmente demorada). Tais estatísticas da fase mais recente de limpeza/GC são coletadas em autosupports. Por exemplo, o seguinte mostra uma fase de cópia em que os dados inativos eram razoavelmente contíguos (ou seja, a maioria dos contêineres selecionados para cópia em grande parte dos dados inativos): a

porcentagem de dados em tempo real na cópia:              3,6% 4,3%

Por outro lado, a seguinte mostra uma fase de cópia em que os dados inativos eram fragmentados (ou seja, a maioria dos contêineres selecionados para cópia em grande parte dos dados reais): a

porcentagem de dados em tempo real na cópia:             70,9% 71,5%

Conforme descrito acima, Clean/GC terá que executar comparativamente mais trabalho no segundo cenário para liberar espaço para espaço físico no DDR, o que fará com que o throughput da fase de cópia reduza.

O throughput da fase de cópia também pode ser afetado negativamente por:

• O uso de criptografia: Pode ser necessário que os dados sejam descriptografados/recriptografados durante a cópia, o que aumenta significativamente o tamanho da CPU necessária.
• O uso de otimização de pouca largura de banda: Os contêineres podem precisar de informações de "esboço" para serem geradas durante a cópia, o que também causa um aumento significativo na quantidade de CPU necessária

Observe que, se a otimização de pouca largura de banda e/ou a criptografia tiverem sido habilitadas recentemente, todos os contêineres existentes (independentemente de terem sido selecionados para cópia ou não) podem precisar ser criptografados e/ou ter informações de esboço geradas de maneira significativamente maior do que o normal.

Outras observações sobre como verificar/modificar o agendamento e o acelerador limpo estão disponíveis no seguinte artigo da base de conhecimento: https://support.emc.com/kb/306100

Observe que:

• Em circunstâncias normais, a limpeza deve ser agendada para ser executada no máximo uma vez por semana, com a execução limpa com mais frequência do que isso pode fazer com que os dados no disco se tornem excessivamente ' fragmentados ' (ou seja, a exposição a uma localidade espacial ruim), que pode resultar em desempenho ruim de leitura/replicação/movimentação de dados
• O controle de limpeza não afeta a quantidade total de CPU e a largura de banda de I/O consumida por limpeza, em vez disso, controla como a limpeza confidencial é para outra carga de trabalho no sistema. Por exemplo:

• Por padrão, o acelerador de limpeza é definido como 50 – é de responsabilidade do usuário testar a execução de limpeza com diferentes configurações de aceleração, embora o DDR apresente carga de trabalho normal para determinar uma configuração de aceleração que permite:

• Observe que uma limpeza demorada não é necessariamente um problema, desde que:

• O sistema que usa a funcionalidade Extended Retention deve ser configurado de modo que:

• Informações completas da última operação de limpeza são incluídas em autosupports e detalhes: