O Secondary NameNode (SNN) é um componante essencial na arquitetura do HDFS, mas seu nome pode levar a interpretações equivocadas. Ele não é um backup quente do NameNode (NN), mas sim um nó que auxilia na manutenção e recuperação dos metadados do HDFS, além de reduzir o tempo de reinicialização do NN.

Entendendo o Papel do NameNode e Secondary NameNode

O NameNode é responsável por gerenciar os metadados do HDFS, como a estrutura de diretórios e a localização dos blocos de arquivos. Para garantir a performence, esses metadados são carregados na memória do NameNode. O estado atual do sistema de arquivos é persistido em um arquivo chamado fsimage. As operações realizadas no sistema de arquivos são registradas em um arquivo de log chamado editlog. Ao reiniciar o NameNode, ele carrega o fsimage e, em seguida, aplica as transações do editlog para restaurar o estado mais recente.

O Secondary NameNode periodicamente combina o editlog com o fsimage, criando um novo fsimage e limpando o editlog. Esse processo, conhecido como checkpoint, é crucial para reduzir o tempo de reinicialização do NameNode, pois um editlog menor requer menos operações para serem aplicadas. Embora o SNN não alivie a carga de processamento das operações de HDFS no NameNode, ele fornece um ponto de recuperação. Em caso de falha do NameNode, os metadados podem ser copiados do SNN para restaurar o sistema de arquivos.

Por que Executar o Secondary NameNode em uma Máquina Separada?

Executar o SNN em uma máquina distinta do NameNode oferece duas vantagens principais:

1. Escalabilidade: A criação de um checkpoint envolve a cópia de todos os metadados do NameNode para a memória. Se o cluster HDFS for muito grande, a máquina do NameNode pode ficar sobrecarregada de memória. Separar o SNN permite que ele utilize recursos de outra máquina para essa tarefa.
2. Tolerância a Falhas: Ao criar um checkpoint, o SNN pode gerar cópias redundantes dos metadados. Executar essa operação em um nó separado aumenta a resiliência do sistema de arquivos distribuído.

Fluxo de Trabalho do Checkpoint

1. O Secondary NameNode solicita ao NameNode que envie o arquivo edits. O NameNode cria um novo arquivo edits.new.
2. O Secondary NameNode baixa os arquivos fsimage e edits do NameNode via HTTP. Esses arquivos são temporariamente armazenados em diretórios como temp.check-point no SNN.
3. O Secondary NameNode combina o fsimage baixado com o arquivo edits para criar um novo arquivo de checkpoint, nomeado como fsimage.ckpt.
4. O Secondary NameNode envia o fsimage.ckpt de volta para o NameNode via HTTP POST.
5. O NameNode renomeia fsimage.ckpt para fsimage e edits.new para edits, atualizando também o timestamp do sistema.

Em versões mais recentes do Hadoop (a partir da 0.21.0), as funções do Secondary NameNode foram divididas em Checkpoint Node e Backup Node. Os parâmetros que controlam o checkpoint são:

• fs.checkpoint.period: Define o intervalo em segundos para checkpoints periódicos.
• fs.checkpoint.size: Define o tamanho em bytes do editlog que aciona um checkpoint.
• dfs.http.address: Especifica o endereço e a porta HTTP para o NameNode (necessário quando o SNN é um nó separado).

Configurando o Secondary NameNode em uma Máquina Remota

Por padrão, o script start-dfs.sh (ou start-all.sh) inicia o NameNode na máquina onde o script é executado. Os DataNodes são iniciados nas máquinas listadas no arquivo conf/slaves. Para configurar um SNN em uma máquina separada, é necessário especificar essa máquina no arquivo conf/masters.

Atenção: O nome do arquivo conf/masters pode ser confuso. Ele não se refere ao JobTracker ou NameNode, mas sim à máquina onde o SNN será executado. Um nome como conf/secondaries seria mais apropriado.

Hadoop 1.x

Edite o arquivo masters no diretório de configuração do Hadoop e adicione o nome do host da máquina onde o SNN será executado.

# Exemplo: Edite masters e adicione o nome do host do SNN
# hdp122m (nome original, exemplo)
# secondary-node-hostname (novo nome, exemplo)

Reinicie o cluster HDFS após a alteração.

Hadoop 2.x

É necessário modificar os arquivos de configuração hdfs-site.xml e core-site.xml.

hdfs-site.xml

<property>
    <name>dfs.http.address</name>
    <value>namenode-host:50070</value>
    <description>The address and the base port where the dfs namenode web ui will listen on. If the port is 0 then the server will start on a free port.</description>
</property>
<property>
    <name>dfs.namenode.secondary.http-address</name>
    <value>secondary-namenode-host:50090</value>
    <!-- Se houver múltiplos SNNs, pode-se usar 0.0.0.0:50090 -->
</property>

core-site.xml

<property>
    <name>fs.checkpoint.period</name>
    <value>3600</value>
    <description>The number of seconds between two periodic checkpoints.</description>
</property>

<property>
    <name>fs.checkpoint.size</name>
    <value>67108864</value>
    <description>Em bytes, o tamanho do edit log que dispara um backup.</description>
</property>

<property>
    <name>fs.checkpoint.dir</name>
    <value>/path/to/snn/checkpoints</value>
    <description>O diretório local no SNN onde os checkpoints temporários são armazenados. Pode ser uma lista separada por vírgulas para redundância.</description>
</property>

Verificação da Configuração

Após cofnigurar, verifique se o SNN está funcionando corretamente observando os diretórios de checkpoint na máquina designada.

Para clusters com Federation (vários NameNodes), um Secondary NameNode pode ser configurado para cada NameNode. Consulte a documentação específica para configurações de Federation.

Recuperação com Checkpoint

Em caso de falha do NameNode, a recuperação pode ser feita a partir de um checkpoint:

1. Mate o processo do NameNode.
2. Remova os dados temporários do diretório especificado por hadoop.tmp.dir (ou similar) para simular uma falha completa.
3. Crie um diretório vazio na localização especificada por dfs.name.dir.
4. Copie os arquivos de checkpoint (fsimage e editlog) do diretório fs.checkpoint.dir do SNN para o diretório dfs.name.dir do NameNode.
5. Inicie o NameNode com a flag -importCheckpoint: ``` $HADOOP_HOME/bin/hadoop namenode -importCheckpoint

Gerenciando o Secondary NameNode

Iniciando e Parando

Os comandos para gerenciar os processos do Secondary NameNode são:

# Iniciar
bin/hadoop-daemons.sh --config conf/ --hosts masters start secondarynamenode

# Parar
bin/hadoop-daemons.sh --config conf/ --hosts masters stop secondarynamenode

O script start-dfs.sh geralmente inicia o NameNode, DataNodes e o Secondary NameNode automaticamente, com base nas configurações em conf/masters e conf/slaves.

Para desativar o início automático do SNN com start-dfs.sh, você pode comentar ou remover a seção relevante no script.

Considerações Finais

• É possível configurar múltiplos Secondary NameNodes. Adicione os nomes dos hosts das máquinas desejadas no arquivo conf/masters.
• A cópia manual dos metadados do SNN para o NameNode é necessária para recuperação; não é um processo automático.
• O intervalo e o tamanho do editlog para a criação de checkpoints podem ser ajustados para otimizar o desempenho e a frequência de backup.