Tolerância a falhas do modelo MapReduce pelo framework hadoop

Olá pessoal,

Hoje vamos comentar sobre um dos pontos mais importantes do Hadoop, a tolerância a falhas.

• De onde vem essas possíveis falhas? Como por exemplo:

1. Código feito pelo programador. Quando a exceção do código acontece, é possível ser um motivo de falha
2. Falha de alguma máquina no cluster. Disco danificado ou cheio, memória ram, processador, e etc
3. Comunicação da rede

• O maior beneficio do hadoop é o de lidar com a falha. de modo que o processamento não seja parado em caso de algum erro. A tolerância a falhas do hadoop independe do programador. o framework do hadoop garante o processamento do trabalho iniciado
• O que acontece numa falha?

1. Quando um erro acontece a JVM comunica ao TaskTracker (Responsável pelas tarefas MapReduce)
2. TaskTracker excecuta uma tarefa atribuida ao Map ou Reduce
3. O erro é registrado em um log por meio do TaskTracker e marca a tarefa como falha
4. Em seguida aquele nó(máquina), é liberado para outra tarefa
5. O nó master é avisado da falha e redistribui o trabalho

• Caso o TaskTracker fique sem comunicação ou muito tempo sem receber informações de algum dos nós do cluster, a tarefa que está/estava naquele nó é considerada nula

1. Esse limite de tempo de resposta é configurado dentro dos arquivos de configuração no map-site

• Não é necessário que a JVM avise que um erro aconteceu para se ter uma falha. Caso ocorra o caso citado acima ele já considera uma falha
• Caso uma mesma tarefa falhe sucessivamente:

1. A tarefa pode ser cancelada, e com isso uma parte do arquivo deixa de ser processada.
2. O número limite de tentativas também é configurado nos arquivos de parâmetros

• Existe um parâmetro, também configurável, que serve para cancelar o processamento como um todo quando houverem muitas falhas. Caso o programador deseje que o processamento seja cancelado por ter um número muito alto de falhas, basta programar o percentual de falhas entre todas as tarefas
• Um dos maiores problemas é se o nó mestre falhar

1. Pois geralmente ele não é substituivel. Acontece quando não se tem um nó mestre redundante. O ideal é que a arquitetura desenvolvida tenha em seu planejamento ter um nó reserva para o nó mestre
2. Assim que o nó mestre falha, o nó substituto continua o trabalho. Todas as tarefas são replicadas para o nó reserva.
3. O nó reserva fica em stand by enquanto o nó principal está funcional
4. Caso não exista redundância, o trabalho inteiro terá de ser reprocessado

Obrigado mais uma vez por toda atenção. 

Toda e qualquer sugestão será bem vinda!