Data Domain: Instruções de upgrade para o DD habilitado para PCR/PCM

Com a versão DD OS 5.7, introduzimos a geração de relatórios/medição de capacidade física (PCR/PCM). Essa é uma maneira de estimar a quantidade de espaço real em disco (pós-compactação) usado pelos dados no FS, de modo confiável e reproduzível, para chargeback e outros cenários de negócios.

Você pode encontrar mais detalhes sobre o recurso na FAQ (Perguntas frequentes) do artigo da KB 465216 abaixo:   
Medição/geração de relatórios de capacidade física (PCM/PCR) do Data Domain Operating System (DDOS)

Para gerar relatórios de PCR, o gerenciador de diretório (DM) do sistema de arquivos do Data Domain (DDFS) cria Btrees de PCR no sistema. 

A engenharia do Dell EMC Data Domain identificou um defeito de código em que as páginas de Btree de PCR do DM podem ficar corrompidas e o DDFS pode entrar em pane quando um trabalho de PCR é iniciado no sistema. No entanto, mesmo no caso de páginas corrompidas da Btree de PCR existentes, os trabalhos de PCR podem ser executados até o final sem quaisquer problemas de FS várias vezes, mas, em outras ocasiões, o FS ainda pode falhar.

Esse defeito, que estava presente em todas as versões do DD OS 5.7–6.2, foi corrigido em algumas versões posteriores do DD OS (leia abaixo), de modo que a execução do PCR não correrá o risco de causar PANE no FS, desde que as páginas corrompidas da Btree de PCR ainda não estejam no sistema.

Como não é possível saber antes se há páginas corrompidas (que podem levar a PANE do FS), ao fazer upgrade para uma versão corrigida, é obrigatório seguir as etapas descritas abaixo, para garantir que, uma vez em uma versão corrigida (que não criará páginas corrompidas de Btree de PCR), o FS não entrará em PANE nas páginas de Btree de PCR corrompidas criadas anteriormente. Note que a atividade exige que o DD FS esteja inativo e, portanto, o tempo de inatividade precisa ser planejado com antecedência. Não é possível dar uma boa estimativa do tempo de inatividade necessário, mas 2 horas devem ser suficientes para concluir a tarefa.

Note que, dependendo das versões atual e de destino do DD OS e de outros fatores, a tarefa pode ser feita imediatamente antes do upgrade para qualquer versão corrigida do DD OS ou imediatamente após a conclusão do upgrade para a nova versão, antes que qualquer trabalho de PCR seja agendado para ser executado. O objetivo é, em todo caso, ter um DD OS com a correção em execução sem qualquer uma das btrees de PCR existentes transferidas da versão anterior, para evitar qualquer chance de falhas nas páginas de Btree de PCR corrompidas.

NA

O defeito que causa páginas corrompidas de btree de PCR é abordado no código do DD OS para as versões a seguir. Note que não há correção para as versões do DD OS 5.7.x, pois o mesmo já está no fim da vida útil:

• O DD OS 6.0.2.50 e versões posteriores da família DD OS 6.0 têm o defeito corrigido.
• O DD OS 6.1.2.40 e versões posteriores da família DD OS 6.1 têm o defeito corrigido (Nota: O DD OS 6.1.2.40 NÃO deve ser usado com o DD3300 devido a um defeito não relacionado)
• O DD OS 6.2.0.20 e versões posteriores da família DD OS 6.2 têm o defeito corrigido

Se um usuário já usou PCR no passado e deseja fazer upgrade para qualquer uma das versões fixas mencionadas acima, é obrigatório que algumas etapas manuais sejam executadas pelo suporte (imediatamente antes ou depois do upgrade) para garantir que não haja páginas corrompidas de Btree de PCR no sistema após o upgrade do DD OS. Deixar de seguir essa recomendação levaria o DD do usuário a executar um DD OS corrigido, que ainda poderia travar da mesma forma devido à corrupção da página de btree de PCR pré-existente.

Os usuários que nunca usaram o PCR ou que estão fazendo upgrade para qualquer versão do DD OS que não tenha a correção de código não precisam passar pelas etapas mencionadas.

Uma nota importante para clusters do DD HA:
As etapas descritas abaixo para tratar e resolver o problema com possíveis btrees de PCR corrompidas devem ser executadas apenas a partir do nó do DD HA ativo. Executar as etapas (script) do nó em espera pode resultar em problemas, pois as operações de DMCK de baixo nível podem ser bem-sucedidas no FS apenas porque o nó em espera não tem o FS ativado dessa forma, enquanto, ao mesmo tempo, os dados estão sendo acessados simultaneamente a partir do nó ativo por meio do processo de FS ativado.

Em caso de dúvida ou se você estiver planejando um upgrade desse tipo e precisar de assistência com o processo, entre em contato com seu provedor de suporte contratado e consulte este artigo da KB.