Data Domain: Tamanho limpável é uma estimativa

Muitas vezes, há confusão sobre o valor de "GiB limpável" apresentado em um sistema Data Domain e expectativas inadequadas sobre a quantidade de espaço que será recuperada após a execução da limpeza.

O número "GiB limpável" fornecido é puramente uma estimativa, e não é possível obter um valor preciso de quanto espaço será recuperado pela execução da limpeza, devido às escolhas tecnológicas feitas ao desenvolver o sistema de arquivos do Data Domain.

A seguir está uma explicação sucinta de por que as estimativas de espaço limpável podem variar substancialmente do espaço real recuperado. Há outros fatores não explicados aqui, no entanto, que podem fazer com que a estimativa e a quantidade de espaço em disco realmente liberado após a execução limpa difiram substancialmente
 

Quando os dados são incluídos pelo sistema Data Domain, o valor pós-compactação é calculado e armazenado como dados estáticos para cada arquivo. O valor "Limpável" é simplesmente a soma do valor pós-compactação de todos os arquivos excluídos desde a última vez em que a limpeza do DD foi executada até a conclusão.
 

O valor Limpável se tornará impreciso se os segmentos de arquivo para arquivos excluídos tiverem sido usados na eliminação de dados de desduplicação em outros arquivos que não foram excluídos. Desde que haja um único arquivo referente a um segmento exclusivo existente, o processo de limpeza do DD não considerará esses segmentos para recuperação. Portanto, mesmo que o post-comp de um arquivo fosse adicionado no contador "GiB limpável" como se todos os seus segmentos exclusivos estivessem prestes a serem descartados, alguns (ou muitos) podem não ser por causa de serem reutilizados por outros arquivos.
 

Um exemplo mais detalhado mostrando esse efeito segue:

Suponha que você tenha 5 arquivos, adicionados um por um a um sistema Data Domain, sem nenhum outro dado anteriormente nele.

Como os primeiros arquivos de 100 GB continham todos os dados exclusivos, sua taxa de compactação é de 1x (supondo que o primeiro arquivo não tenha redundância dentro do próprio arquivo). Os arquivos do 2º ao 5º foram capazes de fazer a desduplicação em relação aos dados do 1º arquivo e a cada um dos arquivos mais antigos à medida que são adicionados, cada um ganhando cada vez mais desduplicação devido ao aumento de arquivos contra os quais desduplicar.

File 1: precomp: 100 GB postcomp: 100 GB compression ratio: 1x
File 2: precomp: 100 GB postcomp:  50 GB compression ratio: 2x
File 3: precomp: 100 GB postcomp:  25 GB compression ratio: 4x
File 4: precomp: 100 GB postcomp:  25 GB compression ratio: 4x
File 5: precomp: 100 GB postcomp:   1 GB compression ratio: 100x

Resource            Size GiB    Used GiB   Avail GiB   Use%   Cleanable GiB*
----------------   ---------   ---------   ---------   ----   --------------
/backup: pre-comp          -         500           -      -                -
/backup: post-comp      1000         201         799    20%                0
----------------   ---------   ---------   ---------   ----   --------------

Exemplo 1. Status após excluir os 3 primeiros arquivos de /backup :
 

Resource            Size GiB    Used GiB   Avail GiB   Use%   Cleanable GiB*
----------------   ---------   ---------   ---------   ----   --------------
/backup: pre-comp          -         200           -      -                -
/backup: post-comp      1000         201         799    20%              175
----------------   ---------   ---------   ---------   ----   --------------

Se você executar a limpeza depois disso, poderá recuperar 125 em vez do 175 totalmente limpável. Isso se deve ao fato de que os últimos 2 arquivos compartilham segmentos com arquivos 1-3.  A limpeza não recuperará os outros 50 GB de espaço porque esses segmentos ainda estão em uso pelos arquivos 3-5.
 

Exemplo 2: Usando o mesmo ponto de partida do Exemplo 1, suponha que o arquivo 1 foi excluído, em seguida, uma cópia rápida executada em toda a pasta /backup (ou seja, todos os 5 arquivos) e, em seguida, a exclusão dos arquivos 2-4. 

Resource            Size GiB    Used GiB   Avail GiB   Use%   Cleanable GiB*
----------------   ---------   ---------   ---------   ----   --------------
/backup: pre-comp          -         800           -      -                -
/backup: post-comp      1000         201         799    20%              200
----------------   ---------   ---------   ---------   ----   --------------

O valor de "Tamanho GiB" para pré-compactação vem de (500-100)=400*2=800, dando 500 para os 5 arquivos originais, subtraindo 100 para excluir o arquivo 1 dá 400 GiB.  Em seguida, 400 GiB multiplicados por 2 devido à cópia rápida em todos os 4 arquivos restantes.

Observe que o espaço de pós-compactação usado ainda é o mesmo, porque uma filecopy adiciona apenas uma pequena quantidade de espaço, consistindo dos ponteiros de metadados para os dados originais. O uso do espaço não foi alterado apesar da exclusão do Arquivo 1 porque um "filesys clean start" não foi executado (para iniciar a limpeza). 
 

Depois da Limpeza veremos:
 

Resource            Size GiB    Used GiB   Avail GiB   Use%   Cleanable GiB*
----------------   ---------   ---------   ---------   ----   --------------
/backup: pre-comp          -         800           -      -                -
/backup: post-comp      1000         176         824    18%                0
----------------   ---------   ---------   ---------   ----   --------------

Observe que, embora 200 GB tenham sido mostrados como limpáveis, apenas 25 GB foram realmente limpos. O "GiB limpável" era exibido como 200 porque o tamanho do arquivo "post-comp" dos arquivos de 1 a 4 adicionava 200 GB.  Apenas o "Arquivo 1" foi removido, que tinha 100 GB, mas dos quais 75 GB ainda estavam em uso pelos outros 4 arquivos (devido à eliminação de duplicação).  

Isso pode parecer estranho, já que "Arquivo 2" até "Arquivo 4" também foram excluídos, mas lembre-se de que, embora o sistema mostrará "Arquivo 2" a "Arquivo 4" como removido, os segmentos de dados reais desses arquivos não puderam ser removidos porque esses arquivos foram copiados rapidamente para outra pasta.   Somente depois que todas as versões de cópia rápida também tiverem sido removidas, o espaço poderá ser totalmente recuperado por limpeza.

Como a GiB limpável é apenas uma "estimativa" e pode não ser precisa, até mesmo às vezes ela pode refletir um tamanho grande ou igual ao da capacidade física do Data Domain.

Isso pode causar confusão para permitir que a limpeza agendada do DDFS seja executada ou manualmente se o uso de espaço do DDFS estiver próximo de 100% porque o GiB limpável mostra um valor próximo ou igual ao de "/data: post-comp".

Para ter uma maneira melhor e mais confiável de estimar a quantidade de espaço em disco que a limpeza recuperaria durante a execução, a partir do DDOS 7.7.x, agora é possível determinar na CLI o espaço total limpável real que o próximo GC no nível ativo poderá recuperar. Este é um resumo da CLI:
 

# filesys cleanable-space calculate
Cleanable space calculation started. Use 'filesys cleanable-space watch' to monitor progress.

O processo fará o mesmo que um GC regular, passando pelas fases 1 a 4, mas ignorando a fase 5 (cópia), que é aquela que efetivamente copiaria contêineres de encaminhamento para recuperar o espaço em disco inativo. Dessa forma, levará o tempo que uma GC regular levar para concluir as fases limpas de 1 a 4 para retornar um valor, portanto, isso não é algo a ser executado regularmente para ter uma estimativa atualizada, mas apenas quando necessário. Em outras palavras, "filesys cleanable-space calculate" executará o GC no nível ativo apenas ignorando a parte na qual ele recupera espaço.

O processo pode ser monitorado da seguinte forma:
 

# filesys cleanable-space watch
Beginning 'filesys cleanable-space calculation' monitoring.  Use Control-C to stop monitoring.

Cleaning: phase 1 of 4 (pre-merge)
  100.0% complete, 96233 GiB free; time: phase  0:02:07, total  0:02:07

Cleaning: phase 2 of 4 (pre-analysis)
  100.0% complete, 96233 GiB free; time: phase  0:06:51, total  0:08:59

Cleaning: phase 3 of 4 (pre-enumeration)
  100.0% complete, 96233 GiB free; time: phase  0:00:20, total  0:09:20

Cleaning: phase 4 of 4 (pre-select)
  100.0% complete, 96233 GiB free; time: phase  0:00:25, total  0:09:46

Uma vez concluído, pode-se acessar o resultado da medição limpável:

# filesys cleanable-space status

Cleanable space on active tier is 94649698202 bytes. Last calculated on 2023/08/25 03:29:51
Cleanable space calculation finished at 2023/08/25 03:29:51.

Então, aqui no teste de exemplo acima, se o DD GC for executado agora, ele liberará 94649698202 bytes. Isso é 88,1 GiB, enquanto no momento do cálculo, a estimativa relatada por "df" no DD de laboratório usado foi de 41,9 GiB. É claro que, à medida que forem feitas alterações no FS (novos backups, mais exclusões, snapshots sendo criados e expirados etc.), o cálculo será desativado.

Se necessário, para interromper o processo acima, o comando abaixo pode ser usado:

# filesys cleanable-space stop

The 'filesys cleanable-space stop' command stops calculating cleanable space in the system.
Are you sure? (yes|no) [no]: yes

ok, proceeding.

# filesys cleanable-space status
Cleanable space on active tier is 2607064 bytes. Last calculated on 2021/06/27 23:23:05
Cleanable space calculation started at 2021/06/27 23:27:58 and was aborted at 2021/06/27 23:28:19.
Cleaning was aborted by user.

Observe que essa CLI se aplica somente ao DD Active Tier. Não há um processo equivalente para calcular o limpável para uma unidade de nuvem DD, que tem sua própria estimativa, sujeita às mesmas incertezas descritas acima.