Montando un Cluster Big Data desde la A a la Z. (Hortonworks)

El objetivo de este poste es el siguiente: tenemos máquinas conectadas a una red interna y queremos instalar y configurar herramientas Big Data para tener nuestro Cluster funcional usando Data Platforms que nos facilitan la integración de los servicios.


Inciso : En el curso Big Data Management iremos integrando las herramientas una a una según las vayamos necesitando y que en este post creamos un Cluster para tal fin: Management_prerrequisito01.


El paradigma en Big Data, y de sus frameworks y herramientas principales, es la distribución y el paralelismo. De ahí la necesidad de trabajar en una estructura de Cluster, máquinas conectadas entre sí que pueden trabajan juntas en la misma tarea. (Les recomiendo ver la sesión 01 del Curso de Management donde hablamos de estos temas: Management_sesión01)

Contenido

  1. Qué necesitamos antes de comenzar?
    1. Elección e instalación del sistema operativo de las máquinas.
    2. Configura la conectividad entre éstas.
    3. Arquitectura y servicios.
  2. Qué es Hortonworks Data Platform HDP?
  3. Instalar y configurar HDP.
  4. Crear un Cluster Big Data con HDP.
    1. Escoger los servicios que necesitamos.
    2. Configurar los servicios.
  5. Conclusiones.

1. Qué necesitamos antes de comenzar?

A la hora de escoger un sistema operativo para cada host de nuestro cluster, las empresas por lo general suelen decantarse por aquellas distribuciones Linux que poseen soporte y actualizaciones/parches garantizados a largo plazo, como por ejemplo Red Hat, SUSE, Ubuntu LTS. No obstante, no podemos afirmar qué distribución Linux es la mejor o estándar, cada caso de negocio casara mejor con alguna. Pero sí podemos afirmar que las mencionadas aquí son las que más mercado tienen.

En nuestro caso, y para la prueba que haremos aquí, usaremos Centos7 (1908) minimal iso. Centos (Community ENTerprise Operating System) Es un sistema operativo de código abierto, basado en la distribución Red Hat Enterprise Linux. Que usaremos por ser gratuita y que parte de Red Hat, una distribución empresarial ampliamente usada. Escoger la versión minimal es para reducir recursos y dado que no tendrá un uso de «desktop», nos comunicaremos con las máquinas via cliente ssh.

Al no disponer de máquinas reales, usaremos virtualización con VirtualBox.

  • Creamos una máquina Virtual con 30GB de disco virtual (Recomendable tamaño fijo para mejor rendimiento de la máquina virtual, tomará más tiempo en crearse pero si su computadora posee disco SDD no será demasiado), 3GB de RAM (que podremos manipular posteriormente en configuraciones)
    • En configuraciones de Red, para adaptador 1 escogemos NAT y en tipo adaptador Intel PRO/1000 MT Desktop. Adaptador que servirá para que la máquina virtual tenga acceso a Internet. Un segundo adaptador de tipo Red Nat para que las máquinas tengan una red interna entre sí y puedan comunicarse entre ellas (que previamente debemos añadir a la configuración global de VirtualBos en Herramientas -> Preferencias -> Red)
  • Instalamos el sistema Centos7 en la máquina montando la iso que nos hemos descargado previamente.

Una vez que tenemos el sistema operativo instalado, procedemos a configuraciones de red. Necesitamos modificar el hostname, definir una Ip estática para el adaptador Red Nat y añadir al resto de máquinas (que serán un clone de ésta cambiándoles la Ip) al fichero Hosts.

Para modificar el hostname:

hostnamectl set-hostname namenode
hostanem -f

Tendrá efecto el cambio al reiniciar la máquina.

Para definir IP estática:
Modificaremos ficheros asociados a cada adaptador localizados en la ruta /etc/sysconfig/network-scripts/ pero como me es más cómodo usar ifconfig para temas de red, lo tenemos que instalar

yum -y update
yum -y install net-tools
ifconfig -a

Veremos los nombres de los adaptadores de red

Modificaremos la IP para el adaptador enp0s8

cd /etc/sysconfig/network-scripts/
ls -al ifcfg*

La salida nos tiene que arrojar tantos ficheros como adaptadores, si nos falta alguno podemos copiar otro existente con el nombre correspondiente y modificarlo.

vi ifcfg-enp0s8
[root@localhost network-scripts]# cat ifcfg-enp0s8
TYPE=Ethernet
PROXY_METHOD=none
BROWSER_ONLY=no
BOOTPROTO=none # hemos modificado dhcp por none
DEFROUTE=yes
IPV4_FAILURE_FATAL=no
IPV6INIT=yes
IPV6_AUTOCONF=yes
IPV6_DEFROUTE=yes
IPV6_FAILURE_FATAL=no
IPV6_ADDR_GEN_MODE=stable-privacy
NAME=enp0s8
UUID=1c3979b1-53f8-408d-bd40-64086876ac00
DEVICE=enp0s8
ONBOOT=yes #lo hemos domificado a yes
IPADDR=192.168.56.100 #IP fija
NETMASK=255.255.255.0 
GATEWAY=10.0.2.15 # Gateway IP adaptador enp0s3
DNS1=8.8.8.8
DNS2=8.8.4.4

Una vez guardado el fichero, y para que tenga efecto el cambio, refrescamos el NetworkManager:

systemctl stop NetworkManager
systemctl disable NetworkManager
systemctl restart network
chkconfig network on
ifconfig -a

Ya deberíamos tener la IP configurada y con ping google.com por ejemplo comprobamos que seguimos teniendo conexión a internet.

Añadir datanodes al fichero Hosts (Si poseen suficientes recursos pueden tener un elevado número de datanodes, por lo menos 3 si queremos respetar el factor de replicación de HDFS de 3 réplicas de cada bloque por defecto) pero en mi caso sólo tendré un datanode, máquina virtual clone de ésta con IP 192.168.56.101

vi /etc/hosts
[root@localhost network-scripts]# cat /etc/hosts
127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6
192.168.56.100  namenode
192.168.56.101  datanode

Una vez que he clonado la máquina virtual namenode, para tener otra máquina datanode, he realizado los mismos pasos anteriores, primero modificar hostname y posteriormente IP fija para el adaptador enp0s8 y también cambié el UUID que cambia de máquina a otra para ambos adaptadores. Para modificar el UUID podemos generarlo con uuidgen y añadirlo al fichero borrando el uuid existente:

uuidgen enp0s8 >> /etc/sysconfig/network-scripts/enp0s8
uuidgen enp0s3 >> /etc/sysconfig/network-scripts/enp0s3

También he añadido un disco duro virtual adicional al datanode (en configuración -> almacenamieto -> nuevo disco vdi). En una arquitectura Big Data, el namenode ha de tener más RAM y en general no se encarga de guardar datos y por tanto no importa que tenga mucha capacidad de almacenamiento. Los datanodes en cambio, guardan datos por lo que necesitan más capacidad de almacenamiento. Por lo general es recomendable que los datos se guarden en un disco adicional en cada datanode, así los datos no se mezclen con el sistema y una migración a discos más potentes sea más fácil.

Para ver como montar el disco duro y formatearlo para ser usado como almacenamiento de datos, véase este post: anadir-almacenamiento-para-hdfs

Resumen de lo que tenemos hasta ahora:

En cuanto a la arquitectura y servicios, en nuestro ejemplo tenemos un NameNode y un DataNode debido a las limitada RAM de mi computadora, es un ejemplo que no usaremos para ningún fin analítico sino simplemente montar la arquitectura que es exportable a caso real con más computdoras físicas y por tanto más servicios/herramientas podemos usar.

Ambas máquinas harán el rol de NodeManager. el DataNode tomara también el rol de segundary namenode y Zookeeper manager.

Los servicios que añadiremos son los básicos, HDFS como sistema de almacenamiento formateado en la ruta del disco adicional del datanode, YARN, MapReduce y Zookeeper.

Pueden probar y testear otras herramientas como Kafka, Spark, Hbase, más datanodes si poseen 16GB o más de RAM.

2. Qué es Hortonworks Data Platform HDP?

Las herramientas Big Data por lo general son software libre, pero la cuestión es que unas tienen cierta dependencia de otras lo que requiere de integración entre sí. La integración de las herramientas pasa por configuraciones en diversos ficheros lo que supone conocer bien las herramientas y su arquitectura para una integración óptima.

Otro punto que surge de forma natural de estas dependencias entre las herramientas es que para iniciar y usar una de ellas, se necesita iniciar, lanzando los scripts correspondientes, las herramientas de las que depende la que queremos usar. Como tampoco podemos dejarlos iniciados, sobre todo si tenemos nuestro negocio en el Cloud por cuestión de minimizar costes, surge una complejidad creciente en temas de integración.

Probablemente necesitaremos crear scripts que nos ayuden a iniciar las herramientas en el orden adecuado y tener al día los ficheros de configuración de cada herramienta. Si añadimos nuevas herramientas, tenemos que sumarlas a la integración del sistema.

En definitiva, existe una complejidad en integración y de ahí que surjan modelos de negocio basados en automatizar al cliente parte de dicha integración. Estos modelos de negocio, los Data Platform, como lo es Hortonworks, son un servicio que proporciona un ecosistema big data de manera más sencilla ocupándose de la parte de integración y Managment.

Hortonworks es una compañía de software que comenzó ofreciendo software libre (Y por tanto sólo integra software del ecosistema Hadoop opensource) para paliar esa necesidad de integración de herramientas y ofrecer un Data Platform. Últimamente fue adquirido por Cloudera, empresa que se encarga de ofrecer Data Platforms con soporte y otros más productos segmentando por ejemplo entre CDP (Cloudera Data Platform), CDF (Cloudera Data Flow para escenarios más enfocados a Stremaing), soluciones Híbridas entre OnPremis y Cloud, etc.

Aquí usaremos la Versión HDP 3.1.0 que nos da posibilidad de añadir a nuestro Cluster diversas herramientas Apache como HDFS, MapReduce, Yarn, Zookeeper, Hbase, Hive, Kafka, Spark,Pig, Oozie,Ranger, Tez, entre otras. Vease la documentación oficial en Cloudera HDP.

Para descargar y monitorizar las herramientas que incluye HDP, usaremos Apache Amabri, en su versión 2.7.4 . Donde tenemos acceso a la guía oficial en la documentación de Cloudera.

3. Instalar y configurar HDP

En este punto ya tenemos que tener todos los hosts configurados de modo que pueden comunicarse entre sí y poseen conexión a internet.

Para instala HDP mediante Ambari-server tenemos dos vías de hacerlo, una es mediante conectividad ssh, y otra es instalando previamente Ambari-agent en cada host. La primera opción necesita de nosotros crear public ssh-keys de cada host y añadirla al fichero /.ssh/authorized-keys de cada host e indicarle a Ambari-server la clave del namenode, entonces Ambari se encarga por nosotros de bajar los Ambari-agents en cada host mediante ssh. Pero aquí lo que haremos es evitar la conectividad ssh sin contraseñas e instalaremos primero Amabri-agent en cada host «a mano».

En todo lo que sigue, se ha de usar usuario root

  1. Añadir el repositorio de Hortonworks en cada host:
yum -y install wget
wget -nv http://public-repo-1.hortonworks.com/ambari/centos7/2.x/updates/2.7.4.0/ambari.repo -O /etc/yum.repos.d/ambari.repo
  1. En cada host, instalar Amabari-agent:
yum install ambari-agent
  1. En cada host, modificamos el fichero ambari-agent.ini para indicarle el hostname del datanode:
vi /etc/ambari-agent/conf/ambari-agent.ini
  1. En namenode, instalar Amabari-server:
yum install ambari-server
  1. En cada host, desactivar temporalmente el firewall. Ambari necesitará conectarse a diversos puertos, por simplicidad desactivamos el firewall. En un entorno real, o bien configuras una política de puertos, o bien añades una capa de VPN.
systemctl disable firewalld
systemctl stop firewalld
  1. Configuramos Amabari-server, en namenode:
ambari-server setup
  1. Configuraciones:
    1. SELinux is set to ‘permissive’ mode and temporarily disabled – tecleamos y
    2. Customize user account for ambari-server daemon [y/n] (n)? – intro
    3. Para el JDK escojemos opción 1 si no tenemos java instalado aún como es el caso, nos bajara open-jdk. Si no opción 2 y le damos la ruta donde tenemos Java.
    4. Si escogimos opción 1 en fase anterior, nos pedirá aceptar licencia Oracle, le damos inter
    5. Enable Ambari Server to download and install GPL Licensed LZO packages [y/n] (n)? – le decimos y
    6. Enter advanced database configuration [y/n] (n)? – le damos intro ( nos bajará PostgreSQL como base de datos «embebida» para almacenar configuraciones y metadata que necesita)

Nos aparecerá un mensaje indicando que la configuración ha acabado con éxito

Ambari Server 'setup' completed successfully.

Iniciamos Ambari-agent en cada host y comprobamos que los logs no arrojan errores:

ambari-agent start

Iniciamos Amabari-server en namenode:

ambari-server start

Entonces aquí ya tenemos Ambari-server escuchando en el puerto por defecto IP:8080. (En virtualBox he añadido en red la re-dirección de puertos para poder acceder desde el navegador de la máquina anfitrión). Así que, podemos acceder la interfaz gráfica de Ambari para comenzar a instalar en nuestro Cluster la plataforma HDP.
Las credenciales por defecto son admin admin.

4. Crear un Cluster Big Data con HDP

Una vez iniciado Ambari-server y estando en la interfaz web IP:8080, nos da la opción de crear un Cluster:

Etapa 0: Launch install Wizard, le danos nombre al Cluster.
Etapa 1: escogemos la versión HDP, nos indicará las herramientas que incorpora. También nos preguntará de qué repositorio bajar las herramientas, eliminamos todos menos los repositorios que corresponden a nuestro OS.
Etapa 2: dejamos los hostnames de cada host en diferentes lineas tal y como nos arroja el comando <hostname -f>. Escogemos la opción «perform manual registration» dado que hemos instalado e iniciado ambari-agent en cada host manualmente.
Etapa 3: después de aceptar las alertas de la etapa anterior, Ambari comprobara que tiene acceso a cada máquina sin errores y si todo es Ok, activará el botón next.
Etapa 4: escoger las herramientas que queremos instalar. Algunas herramientas como Hive, necesitan guardar sus metadatos y configuraciones en bases de datos como MySQL, PostgreSQL. Si escogemos dichos servicios nos pedirá bajar los correspondientes conectores y añadirlos a la configuración de Ambari-server setup.
Etapa 5: definir los roles de cada host. Aquí definimos la arquitectura de nuestro Cluster. En caso real, SnameNode suele ser una máquina que no hace el rol de Datanode como es el caso, pues se reserva para nameNode en caso de que el NameNode principal falle, pero aquí se lo asignamos al único datanode que tenemos. También, se recomienda tener ResourceManager asignado a NameNode en Clusters pequeños y un número impar de servicios Zookeeper. Es importante investigar esté tema según los servicios que necesita y recursos que dispone para definir una arquitectura de Cluster óptima en cuanto a disponibilidad y tolerancia a fallos. Doc HortonWorks
Etapa 6: asignar datanodes, namenodes, nodeManager y Clients. En Cluster pequeño, Datanode y NodeManager se asignan a los slaves. Clients tanto a Namenode como Slaves. El nameNode, no toma el rol de datanode, no guardará datos.
Etapa 7: en esta etapa se configuran los servicios, definir rutas donde dejar logs, datos, contraseñas para aquellos servicios que necesitan credenciales, conectividad a BBDD si hay servicios que lo necesitan etc. Aquí lo único que cambiaremos es el directorio HDFS que por defecto es /hadoop/hdfs/* a la ruta /data/hdfs/* que hemos creado en datanode en el almacenamiento añadido. En está etapa también podremos definir Java Heap Size y configuraciones de los ficheros de configuración de cada herramienta.

Una vez que hemos acabado de configurar los parámetros que nos interesan de cada fichero de configuración, le damos a next. Nos indicará un resumen, si todo nos parece coherente le damos Deploy y en la etapa 9 comenzará a instalar los servicios. Las configuraciones se pueden modificar posteriormente en caso de error o afinar algún parámetro, así como añadir datanodes o suprimir alguno.

Finalmente en la etapa 10, nos mostrará un resumen de la situación y posteriormente la interfaz de Ambari, donde podemos monitorizar el Cluster.

Ambari nos añade al PATH variables para acceder por consola a los servicios, podemos por ejemplo acceder a HDFS tecleando hdfs, a Hive usando hive etc.

5. Conclusiones

Hemos visto que un data platform nos permite bajar las herramientas, configurar sus ficheros de configuración, definir la arquitectura de nuestro Cluster y monitorizar cada servicio. Con sencillos pasos tenemos un Cluster funcional, dejando de lado la complejidad de gestionar cada herramienta por separado.

Nos permite tener los ficheros de configuración de cada herramienta bien organizdos, con la posiblidad de modificar dichos ficheros desde una interfaz web amigable. También nos permite iniciar y parar los servicios sin necesidad de lanzar los scripts correspondientes a ello, reduciendo esta labor a acceder al servicio en la interfaz web y seleccionar inicar o parar.

En cambio, notaremos que el consumo de recursos es mayor, y que quizás perdamos la habitud de conocer más a fondo nuestro entorno. Qué servicios iniciar y en qué orden, crear scripts para ellos, acceder a las rutas de configuración en caso de querer modificar algún parámetro y se genera la sensación de perder cierto control.

Para Clusters pequeños, personalmente prefiero integrar las herramientas sin usar Data platforms, en cambio para infraestructuras más complejas y con más recursos, un entorno basado en Data platfrom, puede simplificarnos en gran medida el tiempo dedicado al manegement, y también por lo general sólo las grandes empresas necesitan una estructura más compleja y les es rentable costear los precios de un Data platform que cada vez más tiende a soluciones en el Cloud o Híbridas.

Deja un comentario

Este sitio utiliza Akismet para reducir el spam. Conoce cómo se procesan los datos de tus comentarios.