Requisitos de hardware para HBase

HBase es una tecnología poderosa y flexible, pero que acompaña a esta flexibilidad es el requisito para la configuración y puesta a punto adecuada. Es hora de que algunas pautas generales para configurar grupos HBase. Su "kilometraje" puede variar, dependiendo de los requerimientos específicos de computación para sus RegionServers (coprocesadores personalizados, por ejemplo) y otras aplicaciones que usted puede elegir para ubicar en el clúster.

RegionServers

La primera tentación de resistirse a la hora de configurar sus RegionServers se plunking un montón de dinero en efectivo para algunos sistemas empresariales de gama alta. ¡No lo hagas! HBase normalmente se implementa en servidores x86 de los productos básicos plain vanilla.

Ahora, no tome esa declaración como una licencia para desplegar los servidores de baja calidad, más baratos. Sí, HBase está diseñado para recuperarse de errores de nodo, pero su disponibilidad sufre durante los períodos de recuperación por lo que la calidad de hardware y redundancia hacer importar.

Fuentes de alimentación redundantes, así como tarjetas de interfaz de red redundantes son una buena idea para los despliegues de producción. Por lo general, las organizaciones eligen dos máquinas de socket con cuatro y seis núcleos cada uno.

La segunda tentación de resistir es configurar el servidor con la máxima capacidad de almacenamiento y memoria. Una configuración común incluye de 6 a 12 terabytes (TB) de espacio en disco y de 48 a 96 gigabytes (GB) de RAM. Controladores RAID para los discos son innecesarias porque HDFS proporciona protección de datos cuando los discos fallan.

HBase requiere una caché de lectura y escritura que se asigna desde el almacenamiento dinámico de Java. Mantenga esta declaración en mente al leer acerca de las variables de configuración HBase porque verá que existe una relación directa entre la capacidad del disco de un RegionServer y Java heap del RegionServer. Echa un vistazo a una excelente discusión sobre HBase RegionServer dimensionamiento memoria.

El artículo señala que se puede estimar la proporción de espacio de disco sin procesar de almacenamiento dinámico de Java siguiendo esta fórmula:

RegionSize Dividido por Memstoresize multiplicada por HDFS Factor de replicación multiplicada por HeapFractionForMemstores

Utilizando las variables de configuración predeterminados HBase ofrece esta relación:

10GB / 128MB * 3 * 0,4 = Ratio de espacio en disco 96 MB: 1 MB Java espacio de almacenamiento dinámico.

La línea anterior equivale a 3 TB de capacidad de disco en bruto por RegionServer con 32 GB de memoria RAM asignada al almacenamiento dinámico de Java.

Lo que usted termina con, entonces, es de 1 terabyte de espacio utilizable por RegionServer ya que el factor de replicación HDFS por defecto es 3. Este número sigue siendo impresionante en términos de almacenamiento de base de datos por nodo, pero no tan impresionante dado que los servidores de las materias primas normalmente tienen capacidad para ocho o más unidades con una capacidad de 2 a 4 terabytes una pieza.

El problema general de este escrito es el hecho de que las actuales máquinas virtuales Java (JVM) lucha para proporcionar una gestión eficiente de la memoria (recolección de basura, para ser exactos), con grandes espacios de almacenamiento dinámico (espacios mayores de 32 GB, por ejemplo).

Sí, hay parámetros de ajuste de recogida de basura que puede utilizar, y usted debe consultar con su proveedor de JVM para asegurarse de tener las últimas opciones, pero no serán capaces de llegar muy lejos usarlos en este momento.

El tema de gestión de memoria con el tiempo se puede solucionar, pero por ahora tenga en cuenta que puede encontrar un problema si sus requerimientos de almacenamiento HBase están en el rango de cientos de terabytes a más de un petabyte. Usted puede aumentar fácilmente a 20GB para llegar a 6 TB y 2 TB prima utilizable.

Usted puede hacer otros ajustes (reducción del tamaño MEMSTORE para grandes cargas de trabajo de lectura, por ejemplo) pero no se harán pedidos de saltos de magnitud en el espacio utilizable hasta que tengamos una JVM que maneja de manera eficiente la recolección de basura con montones enormes.

Usted puede encontrar maneras de evitar el problema de recolección de basura JVM para RegionServers pero las soluciones son nuevos y no son todavía parte de la distribución principal HBase partir de este escrito.

Servidores maestros

El MasterServer no consume recursos del sistema como los RegionServers hacen. Sin embargo, usted debe proporcionar redundancia de hardware, incluyendo RAID para evitar el fallo del sistema. Por si fuera poco, también configurar un MasterServer copia de seguridad en el clúster. Una configuración común es de 4 núcleos de CPU, entre 8GB y 16 GB de RAM y 1 Gigabit Ethernet es una configuración común. Si co-localizar MasterServers y nodos Zookeeper, 16 GB de memoria RAM es recomendable.

Zookeeper

Al igual que el MasterServer, Zookeeper no requiere una configuración de hardware grande, pero Zookeeper no debe bloquear (o ser necesaria para competir por) los recursos del sistema. Zookeeper, que es el servicio de coordinación para un clúster HBase, se encuentra en la ruta de datos para los clientes. Si Zookeeper no puede hacer su trabajo, los tiempos de espera se producen - y los resultados pueden ser catastróficos.

Zookeeper requisitos de hardware son los mismos que para el MasterServer excepto que un disco dedicado debe proporcionar para el proceso. Para los pequeños grupos se puede co-localizar Zookeeper con el servidor maestro, pero recuerde que Zookeeper necesita suficientes recursos del sistema para funcionar cuando esté listo.