Como dijimos en el post «Montando un Cluster Big Data desde la a a la z«, es conveniente que los datos guardados en HDFS acaben en una partición de disco localizada en una unidad de almacenamiento externa a donde tenemos el sistema y las herramientas en cada datanode. Es por tanto que en este post, veremos como crear una partición y montarla en Linux para su posterior asignación a HDFS.
Una vez que tenemos la unidad de almacenamiento conectada al sistema, veremos que se ha añadido como sd<x> donde x toma letras a,b,c … según el número de discos que el sistema nos reconoce. Y de momento sin ninguna partición creada. Las particiones aparecen como sd<x><n> donde n es el número de la partición. Toda esta información la obtenemos como sigue:
lsblk
Esta estructura que vemos en la imagen, no es la ideal para un sistema Big Data, pues tenemos el disco sda particionado únicamente en dos particiones: sda1 para el boot lo cual está bien y sda2 para todo el resto desde la raiz /. Es más conveniente disponer de particiones propias para los logs, y para /root. Pero dejamos ese tema para otro post donde hablemos de qué particionado es más conveniente para un datanode.
Para formatear el disco sdb y crear una partición en éste, que llamaremos /data/hdfs, usaremos la herramienta fdisk
fdisk /dev/sdb
Una vez tecleamos la opción n, nos preguntará si la partición es primary (p) o extended (e). tecleamos p para indicar que es partición primaria.
Nos preguntará número de la partición, de 1 a 4 pues máximo podemos tener 4 particiones primarias en un disco. Tecleamos 1.
Nos preguntará en qué sector queremos que comienze la partición, aquí lo sencillo es dejar el valor por defecto. Le damos intro.
Nos preguntará último sector, como queremos que la totalidad del disco se dedique a dicha partición, dejamos el valor por defecto que es hasta el máximo sector disponible. Le damos intro.
Partition 1 of type Linux and of size 8 GiB is set
Este mensaje nos indica que la partición se ha creado. Tecleamos w (write table to disk and exit) para guardar la tabla de particiones.
Ahora ya nos ha creado la partición sdb1 con la totalidad del espacio del disco sdb pero aún no esta formateada ni asignada a la ruta /data/hdfs. Para ello, formateamos la partición con formato ext4 más conveniente para hadoop.
mkfs.ext4 /dev/sdb1
En este punto ya tenemos la partición formateada y un UUID asignado, que obtenemos con
blkid
Ahora creamos la ruta que asignaremos a la partición sdb1
cd /
mkdir /data
cd /data
mkdir hdfs
Finalmente para persistir los cambios y asignar la partición de forma permanente, modificamos el fichero /etc/fstab añadiendo:
noatime, nofail son opciones de montado de particiones que ayudan a mejorar el rendimiento de I/O y evitar errores. noatime evita guardar información relativa a cuándo se ha creado un fichero y cual es la última fecha de modificación. nofail va mejor combinada con x-systemd.device-timeout=5ms, pues dicha opción lo que hace es que en el inicio del sistema, si la unidad de almacenamiento falla, el sistema se inicia sin error, ya posteriormente podremos investigar el porqué ha fallado.
Para montar las paticiones:
mount -av
lsblk
Y esto seria todo, ya sería configuración de HDFS indicarle como ruta de data directory la ruta /data/hdfs.
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)
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.
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
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:
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
Añadir el repositorio de Hortonworks en cada host:
En cada host, modificamos el fichero ambari-agent.ini para indicarle el hostname del datanode:
vi /etc/ambari-agent/conf/ambari-agent.ini
En namenode, instalar Amabari-server:
yum install ambari-server
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.
SELinux is set to ‘permissive’ mode and temporarily disabled – tecleamos y
Customize user account for ambari-server daemon [y/n] (n)? – intro
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.
Si escogimos opción 1 en fase anterior, nos pedirá aceptar licencia Oracle, le damos inter
Enable Ambari Server to download and install GPL Licensed LZO packages [y/n] (n)? – le decimos y
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 HortonWorksEtapa 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.
En su nueva versión 18.04, Ubunto gestiona los adaptadores de red mediante netplan, así que vamos a configurar el fichero asociado, que está en formato yaml.
ifconfig -a
Nos muestra los adaptadores que el sistema tiene reconocidos.
sudo nano /etc/netplan/01-netcfg.yaml
Una estructura básica del fichero es la siguiente:
# This file describes the network interfaces available on your system
# For more information, see netplan(5).
network:
version: 2
renderer: networkd
ethernets:
enp0s3:
dhcp4: yes
enp0s8:
dhcp4: no
addresses: [192.168.56.100/24]
gateway4: 10.0.2.15
nameservers:
addresses: [8.8.8.8,8.8.4.4]
El nivel ethernets contiene los adaptadores de red, ejemplo «enp0s8»
dhcp4: yes/no, indica Ip dinámica/estática respectivamente
addresses: dirección IP en caso de ser IP estática, en este ejemplo es 192.168.56.100
gateway4: dirección IP del gateway, en este ejemplo 10.0.2.15 que corresponde a la dirección IP del adaptador «enp0s3»
nameservers: indicamos DNS server
Una vez modificado el fichero y guardado (Ctrl+X), ejecutamos los comándos:
sudo netplan apply
sudo reboot
ifconfig -a
Y ya deberíamos ver las IP estáticas que hemos definido.
Big Data && Maths !! 