Data Domain: Uma introdução à retenção em longo prazo/limpeza do nível da nuvem/coleta de lixo nos Data Domain Restorers (DDRs)

O Data Domain Operating System (DDOS) 6.0 introduz um novo recurso conhecido como retenção em nuvem ou retenção em longo prazo (LTR). Esse recurso permite que um segundo nível de armazenamento baseado em objeto provisionado por um provedor de serviços em nuvem seja adicionado a determinados modelos do Data Domain Restorer (DDR) com uma licença CLOUD_CAPACITY associada.

Em sistemas que usam LTR, os arquivos ingeridos pelo DDR são inicialmente gravados no nível ativo (armazenamento conectado localmente). As políticas de movimentação de dados/limites de idade são configurados por mtree, de modo que determinados arquivos que exigem retenção em longo prazo sejam posteriormente migrados do nível ativo para o nível da nuvem pelo processo de movimentação de dados (uma tarefa agendada regularmente).

Os arquivos no nível da nuvem podem ser excluídos normalmente, no entanto, o espaço associado no armazenamento em nuvem/objeto não é recuperado imediatamente para uso. Para remover dados superflous da nuvem, o nível da nuvem deve ser limpo.

Estrutura do nível da nuvem:

O nível da nuvem é subdividido em "unidades de nuvem". Observe que:

• O nível da nuvem pode conter até duas unidades de nuvem
• Cada unidade de nuvem pode ser tão grande quanto o tamanho máximo compatível do nível ativo para o modelo específico de DDR
• Cada unidade de nuvem pode ser provisionada de um provedor de armazenamento em objeto diferente

Por exemplo:

# cloud unit list
Name                      Profile        Status
-----------------------   ------------   ------
B-unit                    LTR-ECS-Ben    Active <=== ECS provider
cloud-unit-virtustream1   virtustream1   Active <=== Virtustream provider
-----------------------   ------------   ------

Conceitos básicos de limpeza da nuvem:

• A limpeza da nuvem opera somente em uma única unidade de nuvem durante cada execução — para determinar a unidade de nuvem que está sendo limpa, a seguinte mensagem pode ser encontrada nos logs do DDFS (/ddr/var/log/debug/ddfs.info) — nesse caso, a unidade de nuvem cloud-unit-virtustream1 está sendo limpa:

• Se um sistema tiver várias unidades de nuvem configuradas, a limpeza da nuvem fará rodízio dessas unidades tentando limpar uma única unidade sempre que a limpeza da nuvem for executada
• A limpeza da nuvem pode ser iniciada manual ou automaticamente por meio de um agendamento — para iniciar de modo manual, o seguinte comando é usado:

• Não é possível executar a limpeza do nível ativo e da nuvem em paralelo (porque ambos usam as mesmas estruturas de memória no DDFS)
• Se a limpeza do nível ativo estiver em execução (iniciada manualmente ou por meio de agendamento) e se houver tentativa de iniciar a limpeza da nuvem, ocorrerá um erro, ou seja:

• Se a limpeza da nuvem tiver sido iniciada automaticamente (ou seja, por meio de agendamento) e a limpeza do nível ativo for iniciada, a limpeza da unidade de nuvem será abortada para permitir que a limpeza do nível ativo seja executada. Isso é indicado a seguir nos logs do DDFS:

• Se a limpeza da nuvem tiver sido iniciada manualmente e se houver uma tentativa de inicialização, a limpeza do nível ativo não será iniciada, a limpeza da nuvem será deixada para ser executada até o fim, ou seja:

• Uma unidade de nuvem deve ter registrado um mínimo de 1% de "churn" de dados (ou seja, >= 1% dos dados atualmente na unidade de nuvem deve ser considerado supérfluo e, portanto, removível) para que a limpeza da nuvem comece. Se esse não for o caso, o seguinte será exibido na linha de comando se a limpeza da nuvem for iniciada manualmente:

• Se um sistema contiver duas unidades de nuvem e a limpeza agendada da primeira unidade falhar por algum motivo (por exemplo, churn insuficiente), a limpeza tentará iniciar automaticamente na segunda unidade (ou seja, não há necessidade de aguardar a próxima execução agendada da limpeza da nuvem para que a segunda unidade seja limpa)
• A limpeza da nuvem pode ser acelerada (semelhante à limpeza do nível ativo) para determinar qual ação deverá ser tomada quando o sistema estiver sob outra carga de trabalho significativa (ou seja, ingestão/restauração/replicação).

Agendamento da limpeza da nuvem:

No DDOS 6.0 e posterior, a maneira como a limpeza do nível ativo é agendada não foi alterada — por padrão, a limpeza do nível ativo é agendada para ser executada uma vez por semana, às 06h00 de terça-feira, ou seja

:# filesys clean show schedule
A limpeza do file system está agendada para ser executada em "Tue" às "0600".

A limpeza da nuvem é agendada, por padrão, para ser executada após cada 4ª chamada da limpeza agendada do nível ativo. Para exibir o agendamento de limpeza da nuvem, o seguinte comando deve ser usado:

# cloud clean frequency show
A frequência de limpeza do nível da nuvem é definida para ser executada após cada quatro ciclos de limpeza do nível ativo.

Como resultado, em um sistema com configuração padrão, a limpeza da nuvem será iniciada a cada 4 semanas. Se o sistema tiver duas unidades de nuvem, cada unidade será limpa uma vez a cada 8 semanas.

Para alterar a frequência de limpeza da nuvem, o seguinte comando pode ser usado:

# cloud clean frequency set 2
A frequência de limpeza do nível da nuvem é definida para ser executada após cada dois ciclos de limpeza do nível ativo.

Para redefinir a limpeza da nuvem para o agendamento padrão de após cada limpeza do nível ativo, o seguinte comando pode ser usado:

# cloud clean frequency reset
A frequência de limpeza do nível da nuvem é redefinida para o padrão (a cada quatro ciclos de limpeza do nível ativo).

Note que o agendamento de limpeza da nuvem não inclui ciclos de limpeza do nível ativo iniciados manualmente. Como resultado, no sistema acima, mesmo que a limpeza do nível ativo fosse executada manualmente, todos os dias, a limpeza do nível da nuvem só seria iniciada uma vez a cada 4 semanas.

Também é possível desativar completamente a limpeza agendada da nuvem usando o seguinte comando:

# cloud clean frequency set never
A frequência de limpeza do nível da nuvem é definida como "never".

Nesse caso, a limpeza da nuvem só será executada quando iniciada manualmente.

Para interromper uma limpeza de nuvem em execução no momento, o seguinte comando pode ser usado:

# cloud clean stop

Para determinar quando a limpeza da nuvem foi executada pela última vez, o seguinte comando pode ser usado:

# cloud clean status
A limpeza do nível da nuvem terminou em 01/08/2016 às 20:54:43.

Algoritmo de limpeza da nuvem:

A limpeza da nuvem usará o mesmo algoritmo de limpeza configurado para o nível ativo. No DDOS 6.0 (e posterior), o padrão é a coleta de lixo físico perfeita (PPGC). No entanto, ela pode ser alterada para coleta de lixo físico (PGC) por meio dos parâmetros do sistema.

Note que a coleta de lixo físico não deve ser desativada, pois usar o algoritmo de limpeza tradicional/completa para limpar uma unidade de nuvem pode resultar em uma pane/reinicialização do DDFS

O algoritmo usado para a limpeza da nuvem é exibido nos logs do DDFS quando a limpeza é iniciada, ou seja:

06/28 10:51:56.960 (tid 0x7fc5bccb2d50): gc: gc_start_intern: Algorithm selected: Physical Cleaning <=== PPGC or PGC
07/27 12:21:18.224 (tid 0x7f92b8cfe7e0): gc: gc_start_intern: Algorithm selected: Full Cleaning <=== Tradicional GC

Note que a partir da saída acima não é possível distinguir entre PPGC ou PGC, o algoritmo específico usado é evidente devido ao número de fases executadas por limpeza, em geral:

Traditional/full GC: 10 phases
PGC: 12 phases
PPGC: 6 phases

Para obter mais informações sobre como alterar o algoritmo de limpeza usado em um sistema, entre em contato com o provedor de suporte contratado

Diferenças entre as fases de cópia da limpeza do nível ativo e do nível da nuvem:

A fase de cópia da limpeza é a fase em que os dados supérfluos em um DDR são fisicamente removidos/espaço recuperado. Note que há diferenças entre como a fase de cópia opera em relação aos níveis ativo e de nuvem:

Active tier:

• Os dados gravados no nível ativo de um DDR estão contidos em contêineres de 4,5 Mb
• Por padrão, um contêiner só será considerado para "cópia" por limpeza se contiver <= 92% de dados "ativos" (ou seja, ativamente referenciados)
• Os dados em tempo real serão extraídos do contêiner e gravados em um novo contêiner (juntamente com dados em tempo real de outros contêineres copiados) no final do file system
• Os índices do disco são atualizados para refletir o novo contêiner que contém os dados em tempo real
• O contêiner original (que contém dados ativos e inativos) é excluído e o espaço em disco subjacente disponibilizado para uso

Nível da nuvem:

• Os dados gravados no nível da nuvem de um DDR são estruturados de maneira diferente: em vez de serem colocados dentro de contêineres de 4,5 Mb, fragmentos de dados individuais (regiões de compactação de 64 Kb) são gravados na unidade de nuvem (NOTA: no DDOS 6.1.2.0 e posterior, os objetos armazenados na unidade de nuvem serão maiores, consulte Data Domain: Tamanho do objeto grande para o nível da nuvem para obter detalhes)
• Em vez de extrair dados em tempo real de uma região de compactação existente e copiá-los, a limpeza da nuvem considerará apenas as regiões de compactação que contêm apenas dados inativos para exclusão

Essa diferença se deve ao custo inerente envolvido na leitura/gravação de grande quantidade de dados no armazenamento em nuvem, no entanto, significa que uma unidade de nuvem pode se tornar artificialmente cheia (ou seja, conter um grande número de regiões de compactação, cada uma das quais contém uma quantidade muito pequena de dados ativos, impedindo sua remoção).

Se essa situação ocorrer, é possível definir parâmetros do sistema forçando uma "limpeza de desfragmentação" da unidade de nuvem. Isso copiará os dados ativos das regiões de compactação existentes para consolidar os dados ativos no menor número possível de regiões de compactação, permitindo que o espaço seja liberado.

Para obter mais informações sobre como executar uma "limpeza de desfragmentação", entre em contato com o provedor de suporte contratado.