Requisitos de hardware para HBase

HBase é uma tecnologia poderosa e flexível, mas que acompanha esta flexibilidade é o requisito para a configuração adequada e tuning. É hora de algumas diretrizes gerais para configuração de clusters de HBase. Seu "quilometragem" pode variar, dependendo dos requisitos específicos de computação para o seu RegionServers (co-processadores personalizados, por exemplo) e outras aplicações que você pode escolher para co-localizar em seu cluster.

RegionServers

A primeira tentação de resistir ao configurar suas RegionServers é desembolsar muito dinheiro para alguns sistemas corporativos de alto nível. Não faça isso! HBase geralmente é implantado em servidores de commodities x86 plain vanilla.

Agora, não tome essa declaração como uma licença para implantar os servidores mais baratos, de baixa qualidade. Sim, HBase é projetado para se recuperar de falhas de nós, mas a sua disponibilidade sofre durante os períodos de recuperação para qualidade de hardware e redundância Faz importam.

fontes de alimentação redundantes, bem como cartões de interface de rede redundantes são uma boa idéia para implantações de produção. Normalmente, as organizações escolher duas máquinas de soquete com quatro a seis núcleos cada.

A segunda tentação de resistir é configurar o servidor com o máximo de armazenamento e capacidade de memória. Uma configuração comum incluiriam de 6 a 12 terabytes (TB) de espaço em disco e de 48 a 96 gigabytes (GB) de RAM. controladores RAID para os discos são desnecessários porque HDFS oferece proteção de dados quando os discos falham.

HBase requer um cache de leitura e de escrita que está alocada do heap Java. Manter esta declaração em mente como você ler sobre as variáveis ​​de configuração HBase, porque você vai ver que existe uma relação direta entre a capacidade de disco de um RegionServer e heap Java de um RegionServer. Confira uma excelente discussão sobre dimensionamento de memória HBase RegionServer.

O artigo aponta que você pode estimar a proporção de espaço em disco cru para heap Java com a seguinte fórmula:

RegionSize dividido por Memstoresize multiplicado por Fator de replicação HDFS multiplicado por HeapFractionForMemstores

Usando as variáveis ​​de configuração HBase padrão fornece essa relação:

10GB / 128MB * 3 * 0,4 = Relação de espaço em disco 96MB: 1 MB Java heap space.

A linha anterior equivale a 3 TB de capacidade de disco bruto por RegionServer com 32GB de RAM alocada para o heap Java.

O que você acabar com, então, é de 1 terabyte de espaço utilizável por RegionServer uma vez que o fator de replicação HDFS padrão é 3. Este número ainda é impressionante em termos de armazenamento de banco de dados por nó, mas não tão impressionante dado que os servidores de commodities geralmente pode acomodar oito ou mais unidades com uma capacidade de 2 a 4 terabyte um pedaço.

O problema fundamental, pois desta escrita é o fato de que os atuais Java Virtual Machines (JVMs) luta para proporcionar uma gestão eficiente de memória (coleta de lixo, para ser preciso) com espaços heap grandes (espaços maiores do que 32 GB, por exemplo).

Sim, há lixo parâmetros coleção de ajuste você pode usar, e você deve verificar com o seu fornecedor JVM para garantir que você tenha as últimas opções, mas você não será capaz de chegar muito longe de usá-los neste momento.

O problema de gerenciamento de memória acabará por ser resolvido, mas por agora estar ciente de que você pode encontrar um problema se os seus requisitos de armazenamento HBase estão na faixa de centenas de terabytes para mais de um petabyte. Você pode facilmente aumentar para 20 GB para chegar 6TB cru e 2TB utilizável.

Você pode fazer outros ajustes (reduzindo o tamanho MemStore para cargas de trabalho pesadas ler, por exemplo), mas você não vai fazer as ordens de saltos de magnitude no espaço utilizável até que tenhamos um JVM que eficientemente lida com a coleta de lixo com montes maciças.

Você pode encontrar maneiras de contornar o problema de recolha de lixo da JVM para RegionServers mas as soluções são novos e ainda não fazem parte da distribuição principal HBase como esta escrito.

servidores mestres

O MasterServer não consomem recursos do sistema, como os RegionServers fazer. No entanto, você deve fornecer para redundância de hardware, incluindo RAID para evitar a falha do sistema. Para a boa medida, também configurar um MasterServer backup para o cluster. Uma configuração comum é de 4 núcleos de CPU, entre 8GB e 16GB de RAM e 1 Gigabit Ethernet é uma configuração comum. Se você co-localizar MasterServers e nós Zookeeper, 16GB de RAM é aconselhável.

Zookeeper

Como o MasterServer, Zookeeper não requer uma configuração de hardware grande, mas Zookeeper não deve bloquear (ou ser obrigados a competir por) recursos do sistema. Zookeeper, que é o serviço de coordenação para um cluster HBase, senta-se no caminho de dados para os clientes. Se Zookeeper não pode fazer o seu trabalho, time-outs irá ocorrer - e os resultados podem ser catastróficos.

Zookeeper requisitos de hardware são os mesmos que para o MasterServer excepto que deve ser proporcionado um disco dedicado para o processo. Para pequenos grupos pode co-localizar Zookeeper com o servidor mestre, mas lembre-se que Zookeeper precisa de recursos de sistema suficientes para executar quando estiver pronto.