Índice:
Vídeo: Hadoop Rack Awareness 2025
Em um cluster Hadoop, cada nó de dados (também conhecido como nodo escravo ) executa um processo de fundo chamado DataNode. Este processo em segundo plano (também conhecido como daemon ) acompanha as fatias de dados que o sistema armazena em seu computador. Ele fala regularmente para o servidor mestre para HDFS (conhecido como NameNode) para informar sobre a saúde e o status dos dados armazenados localmente.
Os blocos de dados são armazenados como arquivos brutos no sistema de arquivos local. Do ponto de vista de um usuário Hadoop, você não tem idéia de qual dos nós escravos tem as peças do arquivo que você precisa processar. De dentro do Hadoop, você não vê blocos de dados ou como eles são distribuídos em todo o cluster - tudo o que você vê é uma listagem de arquivos no HDFS.
A complexidade de como os blocos de arquivos são distribuídos no cluster está escondida de você - você não sabe o quão complicado é tudo, e você não precisa para conhecer. Na verdade, os próprios nós escravos nem sabem o que está dentro dos blocos de dados que estão armazenando. É o servidor NameNode que conhece os mapeamentos de quais blocos de dados compor os arquivos armazenados no HDFS.
Melhor vida através da redundância
Um princípio de design básico do HDFS é o conceito de minimizar o custo dos nós escravos individuais usando componentes de hardware básicos. Para sistemas amplamente escaláveis, essa idéia é sensata porque os custos escalam rapidamente quando você precisa de centenas ou milhares de nós escravos. O uso de hardware de menor custo tem conseqüência, no entanto, em que os componentes individuais não são tão confiáveis como hardware mais caro.
Quando você está escolhendo opções de armazenamento, considere o impacto do uso de unidades de produtos em vez de unidades de qualidade empresarial mais caras. Imagine que você tenha um cluster de 750 nós, onde cada nó possui 12 unidades de disco rígido dedicadas ao armazenamento HDFS.
Com base em uma taxa de falha anual (AFR) de 4 por cento para unidades de disco de commodities (uma determinada unidade de disco rígido tem uma probabilidade de 4 por cento de falhar em um determinado ano, em outras palavras), seu cluster provavelmente experimentará um disco rígido falha todos os dias do ano.
Como pode haver tantos nós escravos, sua falha também é uma ocorrência comum em clusters maiores com centenas ou mais nós. Com esta informação em mente, o HDFS foi projetado com base no pressuposto de que todos os componentes de hardware , mesmo no nível do nó escravo, não são confiáveis.
HDFS supera a falta de confiabilidade de componentes de hardware individuais por meio de redundância: essa é a idéia por trás dessas três cópias de todos os arquivos armazenados em HDFS, distribuídos por todo o sistema.Mais especificamente, cada bloco de arquivo armazenado no HDFS possui um total de três réplicas. Se um sistema quebrar com um bloco de arquivo específico que você precisa, você pode recorrer aos outros dois.
Esboçar o design do servidor de nó escravo
Para equilibrar fatores importantes como o custo total de propriedade, capacidade de armazenamento e desempenho, você precisa planejar cuidadosamente o design de seus nós escravos.
Você geralmente vê os nós escravos agora, onde cada nó normalmente possui entre 12 e 16 unidades de disco rígido de 3 TB normalmente conectadas. Os nós escravos usam CPUs de dupla soquete moderadamente rápidos com seis a oito núcleos cada um - sem demônios de velocidade, em outras palavras. Isso é acompanhado por 48 GB de RAM. Em suma, este servidor é otimizado para armazenamento denso.
Como o HDFS é um sistema de arquivos ao nível do usuário, é importante otimizar o sistema de arquivos local nos nós escravos para trabalhar com o HDFS. A este respeito, uma decisão de alto impacto ao configurar seus servidores é escolher um sistema de arquivos para a instalação do Linux nos nós escravos.
O Ext3 é o sistema de arquivos mais comumente implantado porque tem sido a opção mais estável há vários anos. Dê uma olhada no Ext4, no entanto. É a próxima versão do Ext3, e está disponível o tempo suficiente para ser amplamente considerado estável e confiável.
Mais importante ainda para nossos propósitos, possui uma série de otimizações para lidar com arquivos grandes, o que o torna uma escolha ideal para servidores de nodos escravos HDFS.
Não use o Linux Logical Volume Manager (LVM) - representa uma camada adicional entre o sistema de arquivos Linux e o HDFS, o que impede o Hadoop de otimizar seu desempenho. Especificamente, o LVM agrega discos, o que dificulta o gerenciamento de recursos que HDFS e YARN fazem, com base em como os arquivos são distribuídos nas unidades físicas.
