Configuration matérielle requise pour HBase

HBase est une technologie puissante et flexible, mais accompagnant cette flexibilité est l'exigence pour la configuration et le réglage adéquat. Il est temps pour quelques directives générales pour la configuration des clusters Hbase. Votre "kilométrage" peut varier, en fonction des besoins spécifiques de calcul pour vos RegionServers (de coprocesseurs personnalisés, par exemple) et d'autres applications, vous pouvez choisir de co-localiser sur votre cluster.

RegionServers

La première tentation de résister lors de la configuration de vos RegionServers est plunking beaucoup d'argent pour certains systèmes d'entreprise haut de gamme. Ne pas le faire! HBase est généralement déployée sur des serveurs x86 produits vanilles.

Maintenant, ne prenez pas cette déclaration comme une autorisation de déployer les moins chers, les serveurs de faible qualité. Oui, HBase est conçu pour récupérer des échecs de nœuds, mais votre disponibilité souffre pendant les périodes de récupération de sorte que la qualité du matériel et la redondance faire matière.

Alimentations redondantes ainsi que redondants cartes d'interface réseau sont une bonne idée pour les déploiements de production. Généralement, les organisations choisissent deux machines de socket avec quatre à six cœurs chacun.

La seconde tentation est de résister à la configuration de votre serveur avec le stockage maximale et la capacité de mémoire. Une configuration commune inclurait de 6 à 12 téraoctets (To) d'espace disque et de 48 à 96 gigaoctets (Go) de mémoire vive. Contrôleurs RAID pour les disques ne sont pas nécessaires parce que HDFS fournit une protection des données lors de disques échouent.

HBase nécessite un cache de lecture et d'écriture qui est alloué dans le tas Java. Gardez cette déclaration à l'esprit que vous lisez sur les variables de configuration Hbase parce que vous verrez que une relation directe existe entre la capacité de disque d'un RegionServer et la pile Java d'un RegionServer. Découvrez une excellente discussion sur HBase RegionServer mémoire dimensionnement.

L'article souligne que vous pouvez estimer le ratio de l'espace disque brut à pile Java en suivant cette formule:

Regionsize divisé par Memstoresize multiplié par Facteur Replication HDFS multiplié par HeapFractionForMemstores

En utilisant les défaut Hbase variables de configuration fournit ce rapport:

10 Go / 128 * 3 * 0,4 = Ratio de 96Mo d'espace disque: 1 Mo Java heap space.

La ligne précédente équivaut à 3 To de capacité de disque brut par RegionServer avec 32 Go de RAM allouée au tas Java.

Qu'est-ce que vous vous retrouvez avec, alors, est de 1 téraoctet d'espace utilisable par RegionServer depuis le HDFS facteur de réplication par défaut est 3. Ce nombre est toujours impressionnant en termes de stockage de base de données par nœud, mais pas si impressionnant étant donné que les serveurs des produits de base peuvent généralement accueillir huit ou plus durs avec une capacité de 2 à 4 téraoctet un morceau.

Le problème fondamental de cette écriture est le fait que les machines virtuelles Java actuels (JVM) lutte pour fournir une gestion efficace de la mémoire (garbage collection, pour être précis) avec de grands espaces de tas (espaces de plus de 32 Go, par exemple).

Oui, il ya des ordures paramètres collecte de réglage que vous pouvez utiliser, et vous devriez vérifier avec votre fournisseur JVM pour assurer que vous avez les dernières options, mais vous ne serez pas en mesure d'obtenir très loin de les utiliser à ce moment.

La question de la gestion de la mémoire sera finalement résolu mais pour l'instant il faut savoir que vous pouvez rencontrer un problème si vos besoins de stockage Hbase sont de l'ordre de centaines de téraoctets à plus d'un pétaoctet. Vous pouvez facilement augmenter à 20 Go pour atteindre 6 To et 2 To brute utilisable.

Vous pouvez effectuer d'autres réglages (réduction de la taille des charges de travail lourdes MemStore lire, par exemple), mais vous ne ferez pas les ordres de grandeur des sauts dans l'espace utilisable jusqu'à ce que nous avons une JVM qui gère efficacement la collecte des ordures avec des tas massives.

Vous pouvez trouver des moyens autour de la question de la collecte des ordures JVM pour RegionServers mais les solutions sont nouvelles et pas encore partie de la distribution principale HBase de cette écriture.

Les serveurs maîtres

Le MasterServer ne consomme pas de ressources système comme les RegionServers font. Cependant, vous devez fournir pour la redondance matérielle, y compris RAID pour empêcher une défaillance du système. Pour faire bonne mesure, également configurer un MasterServer de sauvegarde dans le cluster. Une configuration commune est de 4 cœurs de processeur, entre 8 et 16 Go de RAM et 1 Gigabit Ethernet est une configuration commune. Si vous co-localiser MasterServers et nœuds Zookeeper, 16 Go de RAM est recommandé.

Zookeeper

Comme le MasterServer, Zookeeper ne nécessite pas une configuration matérielle importante, mais ne doit pas bloquer Zookeeper (ou être tenu de concourir pour) les ressources du système. Zookeeper, qui est le service de coordination pour un cluster HBase, se trouve dans le chemin de données pour les clients. Si Zookeeper ne peut pas faire son travail, les temps morts se produiront - et les résultats peuvent être catastrophiques.

Zookeeper besoins en matériel sont les mêmes que pour la MasterServer sauf qu'un disque dédié doit être fournie pour le procédé. Pour les petits groupes, vous pouvez co-localiser Zookeeper avec le serveur maître, mais rappelez-vous que Zookeeper besoin suffisamment de ressources système pour exécuter lorsque vous êtes prêt.