Desarrollo de un entorno de trabajo Big Data que haga uso eficiente de los recursos computacionales del CECAD

(1)

Universidad Distrital Francisco José de Caldas Facultad de Ingeniería

Ingeniería de Sistemas

Desarrollo de un entorno de trabajo Big Data que

haga uso eficiente de los recursos computacionales

del CECAD

10 de junio de 2020

David Julian Amado Romero

[email protected]

(2)

Índice general

1. Introducción 5 1.1. Justificación . . . 8 1.2. Objetivos . . . 9 1.2.1. General . . . 9 1.2.2. Específicos . . . 9 2. Marco Teórico 10 2.1. Big data . . . 10 2.1.1. Apache . . . 11 2.2. DevOps . . . 12 2.2.1. Ansible . . . 12

2.3. Computación de alto desempeño . . . 13

2.3.1. CECAD . . . 14

3. Metodología 16 3.1. Modelo . . . 16

3.2. Implementación . . . 17

3.2.1. Despliegue de un cluster usando Apache Ambari . . . 17

3.2.2. Automatización del proceso de despliegue . . . 34

4. Pruebas de funcionalidad 47

5. Conclusiones 54

6. Futuros trabajos 55

(3)

Índice de figuras

2.1. Componentes de Sabio I. (Cáliz,2017a) . . . 14

2.2. Componentes de Sabio II. (Cáliz,2017b) . . . 14

2.3. Especificaciones Sabio I.(Cáliz,2017a) . . . 15

2.4. Especificaciones Sabio II.(Cáliz,2017b) . . . 15

3.1. Modelo de la solución . . . 16

3.2. Proceso de instalación, primera parte . . . 24

3.3. Proceso de instalación, segunda parte . . . 24

3.4. Proceso de arranque del servidor de ambari . . . 25

3.5. Pantalla de login de Ambari. . . 26

3.6. Lanzar wizard . . . 26

3.7. Nombrar el cluster . . . 27

3.8. Configurar el acceso de ambari a los hosts . . . 28

3.9. Validación del proceso de configuración previa para el despliegue de un cluster 29 3.10.Asignación de procesos maestros en las diferentes máquinas . . . 30

3.11.Asignación de procesos esclavos y clientes . . . 31

3.12.configuración del HDFS core-site . . . 32

3.13.Revision del proceso de despliegue . . . 33

3.14.Métricas de funcionamiento del cluster . . . 34

4.1. Cambiar a vista de ficheros . . . 47

4.2. Vista de ficheros . . . 48

4.3. Carga de datos por vista de ficheros . . . 48

4.4. Edición de permisos desde vista de ficheros . . . 49

4.5. Creación de un notebook de zeppelin . . . 50

4.6. Conexión de spark2 con hive . . . 50

(4)

ÍNDICE DE FIGURAS Universidad Distrital Francisco José de Caldas

4.8. Cargar datos geolocation en hive . . . 51

4.9. Operación select en hive por medio de spark2 . . . 52

4.10.Cargar datos trucks en hive . . . 52

4.11.Creación de nuevas tablas a partir de operaciones en spark2 . . . 52

4.12.Guardar una consulta en una variable . . . 53

(5)

Índice de ficheros

3.1. /etc/security/limits.conf . . . 19 3.2. /etc/hosts . . . 19 3.3. /etc/sysconfig/network . . . 20 3.4. /etc/selinux/config . . . 21 3.5. /var/lib/pgsql/data/pg_hba.conf . . . 22 3.6. /var/lib/pgsql/data/postgresql.conf . . . 22 3.7. hosts.yml . . . 36 3.8. conf_basica.yml encabezado . . . 36 3.9. ./vars/basic_vars.yml . . . 37 3.10.conf_basica.yml - Tareas 1 . . . 38 3.11.conf_basica.yml - Tareas 2 . . . 39 3.12.conf_basica.yml - Tareas 3 . . . 39 3.13../templates/hosts.j2 . . . 39 3.14.conf_basica.yml - Tareas 4 . . . 40 3.15.conf_basica.yml - Tareas 5 . . . 40 3.16.conf_basica.yml - Tareas 6 . . . 42 3.17.ambari_conf.yml parte 1 . . . 42 3.18../vars/postgres_vars.yml . . . 43 3.19.ambari_conf.yml parte 2 . . . 44 3.20.ambari_conf.yml parte 3 . . . 45 3.21.ambari_conf.yml parte 4 . . . 45

(6)

Capítulo 1

Introducción

En la historia de la humanidad se pueden resaltar descubrimientos y hechos importantes que han realizado cambios demasiado significativos en la forma en que el humano concibe su propia existencia, como por ejemplo el descubrimiento del fuego, ya que a partir de este avance tecnológico, el humano pudo desarrollar nuevas habilidades. Como éste evento, hay muchos otros, como la revolución agricultura, en donde se logra asentar el ser humano y le da un sin fin de oportunidades, o la revolución industrial. Todos estos eventos han sido hitos significativos en la historia de la humanidad, ya que ha abierto el espectro de lo que el humano puede hacer.

Un suceso de similar importancia, en los últimos años, se da cuando el humano comienza a almacenar información. Primeramente esto ocurre en medios análogos, y es en éste punto que el humano empieza a tener persistencia de muchos eventos que pasan a su alrededor. Esto sucede con la aparición de los medios de almacenamiento como las cintas de video, los casetes, etc. A mediados del año 2000, y con la aparición de los medios digitales, la hu-manidad empieza a migrar toda la información que tenía almacenada en medios análogos y se da una transición a los medios magnéticos, y es en ésta década que más del 50 % de la información almacenada por la humanidad ya está en medios digitales. Este evento se puede considerar como el primer hito de la era de la información, ya que a partir de este momento se empiezan a almacenar cada vez más datos en medios electrónicos.

Pero todos estos datos no significan mucho, son unos y ceros almacenados en una cinta magnética, es solo cuando se empiezan a analizar dichos datos, todos estos datos almace-nados desde los años 1980, donde se da otro gran hito en esta era de la información, y es el inicio del big data. Cuando se analizan todos estos datos y se extrae información de ellos se

(7)

CAPÍTULO 1. INTRODUCCIÓN Universidad Distrital Francisco José de Caldas

empieza a pensar en big data.

En este contexto, la humanidad venía almacenando cantidades exorbitantes de datos, pe-ro estos no tienen gran utilidad, ya que son datos no estructurados y es difícil deducir alguna información a partir de ellos, es solo cuando se empieza a limpiar y organizar dichos datos, y al volverlos información donde la humanidad empieza a sacar provecho de dichos datos, y es que es en estos datos que está relatada la historia de la humanidad, al analizarlos se tiene la información real de cómo ha funcionado el mundo, que ha pasado hasta la actualidad, qué acciones tienen que consecuencias, etc.

Al analizar esto se observa que no solo es posible entender la razón de ciertos sucesos, sino que se puede empezar a predecir sucesos a partir del recuento histórico, ya que se tiene toda la información verídica de lo que ha pasado y las consecuencias que se han desencade-nado por dichos actos.

El problema llega a la hora de computar estos datos, teniendo en cuenta que la palabra computar involucra procesamiento en una máquina, lo que significa tiempo y recursos, por lo cual el crecimiento de los datos significa una mayor demanda de recursos de cómputo. Los computadores promedio, se quedan cortos a la hora de manejar grandes cantidades de datos, pues los procesadores convencionales pueden llegar a tardar mucho en realizar tareas con grandes cantidades de datos.

En un esfuerzo por solucionar esto, nace el procesamiento por lotes, con lo cual se piensa en procesar los datos por un ciertos bloques de datos, los cuales solo se acceden con permisos de lectura, se procesan y se genera un nuevo lote de datos, con lo cual nunca fue necesario crear un bloqueo de escritura para un lote creado con anterioridad. esto soluciona el acceso concurrente a los datos, con lo cual se optimiza la velocidad a la cual se acceden estos datos.

Ya con esta idea de el procesamiento por lotes planteada, llega un algoritmo llamado MapReduce, el cual consiste en un proceso similar a divide y suma, con lo cual se busca coger una tarea compleja, como el procesamiento de un lote, dividirla en un número de tareas N las cuales no tienen correlación entre sí, y distribuirlo en un número de procesadores M, y al terminar, pasar por cada procesador y recoger el resultado, el cual debe ser la tarea inicial completada.

(8)

Lo que se obtiene con esto es poder distribuir una tarea en un número de procesadores, que incluso pueden estar en espacios físicos diferentes, obteniendo una respuesta rápida y confiable. Mapreduce no realiza solo está tarea, para esto existen otros algoritmos, con lo cuales se controla el paso de mensajes entre diferentes máquinas para coordinar los procesos y que cada máquina realice su tarea correctamente e informe a las máquinas correspondien-tes para seguir el procedimiento.

Estas tareas pueden tornarse de una complejidad algo engorrosa si se realiza de la manera rústica, puesto que se tienen diferentes servicios en diferentes máquinas. Estos servicios dependen de sus contrapartes en otras máquinas, como algunos procesos de tipo maestro tienen procesos esclavos en otras máquinas, con lo cual se llega a un nivel de arquitectura al-go más robusto que el que se observa en un sistema operativo común, lo cual puede implicar procedimientos de configuración bastante complicados y difíciles de llevar a cabo si nunca se han realizado, y aunque se hayan realizado previamente, son complicados de replicar a mano por la cantidad de acciones requeridas.

Es éste precisamente el problema que ésta tesis está atacando, y es el problema de desplie-gue de un entorno de desarrollo para trabajar en el campo del big data, buscando simplificar un poco éste proceso, y es que haciendo uso de herramientas de dev ops y con algo de código en bash, es posible automatizar el despliegue de un número N de máquinas, con las configuraciones previas para la instalación de un cluster de hadoop, con lo cual se podría replicar este proceso cualquier número de veces sin requerir ninguna configuración extra, o algún conocimiento de las configuraciones previas.

(9)

1.1. Justificación

Con la llegada de nuevas tecnologías como las herramientas usadas para big data, se abre una nueva puerta, se crea un nuevo mundo de soluciones a problemas que antes se veían inalcanzables, lo cual beneficia no solamente a la academia, sino que éstas son aplicables a múltiples ámbitos, por lo cual es de utilidad que la universidad disponga de de un ambiente configurado para que los estudiantes, ya sea de pregrado, maestría, e.t.c., profesores o incluso gente externa a la universidad pueda acceder a este tipo de tecnologías, probarlas, incursio-nar en éstas, y lograr avances en ésta área que tiene tanta demanda en la actualidad, como lo es en campo como la fisica cuantica, pronosticos climáticos, exploración de hidrocarburos, la astronomía, entre otros.

Por otro aspecto, tener automatizada la tarea de despliegue permite que se pueda utilizar en otros ambientes, otros centros de cómputo, por ejemplo, en donde lo único que se requiere es conocer la dirección ip de las máquinas.

También es posible usar esta configuración para desplegar una arquitectura diferente de un cluster, en caso de requerir más funcionalidades, ya que un cluster básico de hadoop con-tiene unos servicios limitados, y dependiendo de la necesidad, por ejemplo procesamiento de flujos de datos, como videos o streams, se agreguen nuevos servicios, ya que entre más servicios se tengan corriendo se requiere más procesamiento.

(10)

1.2. Objetivos

1.2.1. General

Automatizar el proceso de despliegue de un entorno de trabajo de big data.

1.2.2. Específicos

Configurar un conjunto de máquinas suministradas por el CECAD para el despliegue de un cluster de hadoop.

Escribir scripts para la automatización del aprovisionamiento de servidores para el despliegue de un cluster de hadoop aplicado a cualquier número de máquinas.

(11)

Capítulo 2

Marco Teórico

2.1. Big data

La generaciones presentes están sintiendo todos los cambios que trae para la humanidad la era digital, como por ejemplo el fácil acceso a todo tipo de información, en tiempo real o diferido, o la facilidad para almacenar información por medio de fotos, vídeos, textos, etc. Con estas posibilidades, la vida de la humanidad se transforma rápidamente, y cada vez se almacena información a una tasa más alta por persona.

Rápidamente se fue acogiendo la era digital hasta tal punto que ahora la mayoría de interacciones humanas se realizan por medios digitales, toda la información se crea y alma-cena de manera digital, de modo que se puede tratar esta misma información, con lo cual el ritmo al que se genera información crece de manera exponencial generando necesidades de almacenamiento y procesamiento de estos datos.

Con esta idea se crea el término “Big Data” o “grandes volúmenes de datos” que a varios autores les parece un nombre poco diciente, ya que lo que para unos muchos datos puede ser unas cuantas Terabytes (1.0E-6), para una empresa como Google este flujo de datos debe ser lo habitual y muchos datos sería en escalas de Yottabytes (1.0E-18).

Lo cierto es una cosa, los datos son exageradamente muchos, y las formas habituales de almacenamiento y acceso a los datos no son viables.

(12)

CAPÍTULO 2. MARCO TEÓRICO Universidad Distrital Francisco José de Caldas

2.1.1. Apache

El proyecto que se conoce hoy como apache hadoop, es la evolución de un subproyecto llamado Nutch.

El proyecto Nutch era una iniciativa de crear un motor de búsqueda web que nace en el 2002, pero se encuentran con el problema de la escalabilidad, ya que se esperaba que llegara a indexar los billones de páginas que existen en internet lo cual presentó un problema para la arquitectura de Nutch.(White,2015)

Por la misma época, en el 2003, se publica un paper en donde se expone el sistema de archivos de google GFS(Google File System), y un año más tarde, se publica otro paper en don-de se don-describe el algoritmo MapReduce, las soluciones a los problemas don-de almacenamiento y procesamiento fácilmente escalable.

En el 2006 se logra una implementación de ambos algoritmos en el proyecto Nutch, y se decide separar el subproyecto del proyecto Lucene, y se cambia en nombre del proyecto a Apache Hadoop, todo bajo licencia de software libre.

Posteriormente el proyecto cogió mucha fuerza, tanto así que se crearon proyectos anexos a hadoop, cada uno con su propio equipo de trabajo y sus propios tiempos de lanzamiento de actualizaciones.

El proyecto básico comprende 3 campos importantes, primero el sistema de archivos distribuido; segundo el MapReduce, un modelo de programación para el procesado de datos; y por último se tiene YARN(Yet Another Resource Negotiator) que mejora el funcionamiento de MapReduce.

Adicionalmente, la fundación Apache crea proyectos relacionados, como Apache Ambari, Pig y muchas otras herramientas que trabajan junto a hadoop para realizar tareas relaciona-das a éste campo.

(13)

2.2. DevOps

Este nuevo campo de la tecnología ha tenido un auge ya que brinda soluciones a proble-mas comunes en el ámbito del desarrollo de software. Principalmente DevOps comprende el manejo de ambientes de entornos de desarrollo y operaciones, despliegue automatizado, monitoreo de infraestructura, entre otras cosas.(Christof Ebert,2016)

Para esta tesis se entrará más a fondo en lo que respecta al despliegue automatizado, ya que por medio de estas herramientas se puede guardar una configuración de una o muchas máquinas para el despliuegue de un cluster de hadoop.

2.2.1. Ansible

Ansible se muestra como la respuesta a esas tareas que deben repetirse una y otra vez en el mundo del desarrollo. Tareas como la instalación de una base de datos, o la configuración de algún fichero específico pueden ser tareas que se describen en un lenguaje de alto nivel, o un lenguaje humano, donde literal se especifica que el estado en el que se desea que se encuentre el host después de el procedimiento, y por medio de un gran listado de módulos ofrecidos por el mismo ansible, es posible llevar a cabo éste tipo de tareas.(Ansible,2019)

Los módulos de ansible pueden ser usados tanto en línea de comandos, como en un documento llamado ansible-playbook. La segunda opción ofrece más ventajas, ya que es la forma de persistir una serie de instrucciones y poder ejecutarlas más adelante.

La forma en que Ansible se conecta a los equipo a aprovisionar es por medio de dos cosas, primero, se debe tener una lista de los respectivos hosts a lo que se desea acceder, y segundo se requiere crear un par de llaves RSA desde la máquina aprovisionadora, o dicho en otras palabras, la máquina en la que se instala Ansible.

Con las llaves creadas es necesario copiarlas a las respectivas máquinas que se desean modificar y de ésta manera ansible tiene todo el acceso para hacer modificaciones en los sistemas operativos de los hosts.

(14)

2.3. Computación de alto desempeño

Con la computación nace una demanda de procesamiento, que al comienzo se solven-ta con los monoprocesadores, un procesador con un solo núcleo o un solo cerebro, pero éstos se quedan cortos con el crecimiento de la demanda. Por esta razón llegan los mul-tiprocesadores, los cuales consisten en un procesadores con varios núcleos, pero aún así estos se comenzaron a volver obsoletos debido al crecimiento exponencial de la demanda de procesamiento.(Piccoli,2011)

Debido a la demanda de procesamiento en la industria de los videojuegos, se invierte mucho en desarrollo en las GPUs (Graphic Processing Units), las cuales tienen como objetivo original el procesar el renderizado de los procesos gráficos, para no asignar esa carga sobre el procesador de una máquina. Las GPUs logran una capacidad muy alta de procesamiento en paralelo, por lo que si se usa para propósitos diferente que para el renderizado de gráficos se obtiene muy buen procesamiento.(Piccoli,2011)

Pero hay entornos en donde una máquina de escritorio, con excelente especificaciones no es suficiente para tareas que requieren mucho procesamiento. Es por esto que piensa en una idea que de por sí no es nueva. El procesamiento en paralelo es la solución, si de por sí ya se está paralelizando procesos en los diferentes núcleos, es posible hacer lo mismo en otra escala. Ya que un solo procesador que desarrolle todo el proceso de cómputo es demasiado costoso, es mucho más eficiente distribuir la carga en varios procesadores, y entre más procesamiento se requiera, más procesadores se añaden al conjunto.

Llevar la idea anterior a gran escala es lo que se conoce como un centro de cómputo de alto rendimiento, el cual es un conjunto de procesadores, en la escala de miles en adelante, configurado especialmente para realizar tareas que normalmente llevaría años o siglos reali-zarla en una máquina tradicional.

Esto ha beneficiado numerosos campos en donde se requiere de mucho procesamiento, como lo es la astronomía, modelado del clima, medicina, bioinformática, entre muchos otros.(Ryan McKinney,2015;Lucia Morganti,2016;Bal,2002)

(15)

2.3.1. CECAD

El Centro de Computación de Alto Desempeño de la Universidad Distrital Francisco José de Caldas (CECAD)es un laboratorio adscrito al Doctorado en Ingeniería con el objetivo de fomentar la investigación y la transferencia de conocimiento en las áreas de ingeniería, tecno-logía, ciencias naturales, ciencias sociales, y en general todas las divisiones de la Universidad involucradas en el desarrollo y fortalecimiento de la comunidad académica institucional y nacional, para el crecimiento de la industria local, regional y nacional que se vea reflejado en el bienestar de la sociedad.(Cáliz,2019)

El CECAD cuenta con 2 secciones, “Sabio I”, el cual se describe en la figura 2.1; y “Sabio II”, cuya descripción se muestra en la figura 2.2.

Figura 2.1: Componentes de Sabio I. (Cáliz,2017a)

(16)

El resumen de las especificaciones logradas con dichos componentes es el siguiente.

Figura 2.3: Especificaciones Sabio I.(Cáliz,2017a)

(17)

Capítulo 3

Metodología

3.1. Modelo

(18)

CAPÍTULO 3. METODOLOGÍA Universidad Distrital Francisco José de Caldas

El sistema propuesto está compuesto por 4 máquinas entre las cuales se repartirán los softwares Ambari server, HDFS, YARN, SmartSense y Hive. Como se muestra en la figura 3.1 éstos softwares requieren de diversos servicios trabajando en máquinas diferentes, como en el caso de HDFS el cual provee un sistema de archivos distribuido y requiere un servicio activo llamado NameNode, para localizar los datos guardados, un SecondaryNameNode como respaldo del NameNode el cual reside en una máquina diferente a la que almacena el NameNode. Además requiere servicios cliente que residen en las últimas 2 máquinas, y es en esas en donde se almacena la información.

Funciona similar para YARN el cual sirve para agendar los trabajos de procesamiento sobre las diferentes máquinas del cluster. YARN guarda en 2 máquinas diferentes los logs de los trabajos realizados.

Para poder probar el funcionamiento del cluster se hará uso de spark2 y de la base de datos distribuida Hive.

Por otro lado, se requiere de Apache Ambari para facilitar el despliegue del cluster, y SmartSense el cual es sugerido ya se encarga de recolectar datos de funcionamiento del cluster.

3.2. Implementación

3.2.1. Despliegue de un cluster usando Apache Ambari

En el momento, la mayor parte del CECAD está siendo usado para diferentes tipos de proyectos de la universidad, por lo cual para el proyecto se dispusieron 4 máquinas, las cuales cuentan con las siguientes especificaciones:

Master

• No procesadores: 8 • Memoria RAM: 8 GB

• Sistema operativo: Centos 7 • Espacio en la raiz (/): 256 GB

(19)

Slave1, Slave2 y slave3 • No procesadores: 2 • Memoria RAM: 4 GB

• Sistema operativo: Centos 7 • Espacio en la raiz (/): 40 GB

Para este cluster se cuenta con 2 máquinas con 8 núcleos, 8 GBs de memoria RAM y 160 GBs de espacio en la raíz, las cuales tienen la ip 192.168.4.197 y 192.168.4.202 y seran usadas, la primera como máquina maestro, y como server de Apache Ambari y la segunda será esclava; y 2 máquinas con 2 núcleos, 4 GBs en RAM y 40 GBs de espacio en la raíz, con la ip 192.168.4.203 y 192.168.4.204 respectivamente.

La instalación de Apache Ambari no es tan compleja como desplegar un cluster a mano, pero igualmente requiere un proceso de configuración en los diferentes equipos en los que se desea desplegar el cluster, empezando por generar llaves rsa para establecer una conección sin autenticación y sin frase secreta, para que la máquina en la que se alojará el ambari server tenga acceso a todas las máquinas, incluyendo la máquina sobre la que corre ambari server, sí se desea que ésta tenga otros procesos diferentes a los de administración del cluster.

Todo lo realizado de ahora en adelante será hecho a partir del usuario root y debe hacerse en todas las máquinas del cluster. Es posible configurar Apache Ambari para correr bajo un usuario diferente a root, pero no se profundizará en este tema.

Primero es necesario configurar todos los hosts para que sea posible autenticarse por ssh por medio de la contraseña, lo cual se configura en el fichero /etc/ssh/sshd_config.

P a s s w o r d A u t h e n t i c a t i o n yes

Se debe reiniciar el servicio ssh para notar los cambios.

s y s t e m c t l r e s t a r t sshd

Ahora, desde la máquina maestro re crean las llaves rsa y se copian a todas las máquinas. Es importante crear las llaves sin frase, aunque ésto es una brecha de seguridad, facilita considerablemente el proceso de despliegue, ya que ésta misma llave será usada por Apache

(20)

Ambari para conectarse con todos los hosts. Éste proceso requiere saber la contraseña del usuario root de todas las máquinas.

ssh - k e y g e n

ssh - copy - id r o o t @ 1 9 2 . 1 6 8 . 4 . 1 9 7 ssh - copy - id r o o t @ 1 9 2 . 1 6 8 . 4 . 2 0 2 ssh - copy - id r o o t @ 1 9 2 . 1 6 8 . 4 . 2 0 3 ssh - copy - id r o o t @ 1 9 2 . 1 6 8 . 4 . 2 0 4

Como se puede observar en el las líneas de código anteriores, además de copiar la clave rsa a las otras máquinas, pero también a sí misma, ésto es necesario ya que tambien se desean instalar servicios en la máquina que se usa para la instalación del Ambari server.

Por otro lado, se requiere modificar ficheros de configuración de seguridad del sistema operativo, exactamente el fichero /etc/security/limits.conf el cual, entre varias opciones, permite indicar el número máximo de archivos abiertos por un usuario. La configuración deseada es que el número de archivos abiertos sea elevado pero menor a 200000 por lo cual se le asignó el valor de 190000. El asterisco indica que se aplique ésta configuración a todos los usuarios.

* soft n o f i l e 1 9 0 0 0 0

* hard n o f i l e 1 9 0 0 0 0

Fichero 3.1: /etc/security/limits.conf

Para que Ambari funcione, todas las máquinas deben tener configurado el DNS y el DNS reverso. Una solución rápida es modificar el archivo /etc/hosts agregando la ip de cada máquina y su respectivo nombre. El fichero suele estar creado con anterioridad y contie-ne 2 lícontie-neas las cuales no deben modificarse. Debajo de éstas se añade la información del cluster.(Cloudera,2019)

1 2 7 . 0 . 0 . 1 l o c a l h o s t l o c a l h o s t . l o c a l d o m a i n l o c a l h o s t 4 l o c a l h o s t 4 . l o c a l d o m a i n 4

(21)

CAPÍTULO 3. METODOLOGÍA Universidad Distrital Francisco José de Caldas l o c a l h o s t 6 . l o c a l d o m a i n 6 1 9 2 . 1 6 8 . 4 . 1 9 7 m a s t e r . c e c a d 1 9 2 . 1 6 8 . 4 . 2 0 2 s l a v e 1 . c e c a d 1 9 2 . 1 6 8 . 4 . 2 0 3 s l a v e 2 . c e c a d 1 9 2 . 1 6 8 . 4 . 2 0 4 s l a v e 3 . c e c a d Fichero 3.2: /etc/hosts

Es necesario configurar además el hostname de cada máquina, este nombre tiene que coincidir con el nombre usado en /etc/hosts. Para esto se usa el siguiente comando en la terminal de cada máquina, donde NOMBRE es la variable de entorno que contiene el nombre correspondiente para cada host.

h o s t n a m e $ N O M B R E . c e c a d

Es necesario modificar el fichero /etc/sysconfig/network, para activar la comunicación en red, y anotar el nombre del host.

N E T W O R K I N G = yes N O Z E R O C O N F = yes

H O S T N A M E = $ N O M B R E . c e c a d

Fichero 3.3: /etc/sysconfig/network

Como se requiere que los ficheros y directorios de ahora en adelante tengan permisos 644 (lectura y escritura para el dueño del fichero, y permisos de lectura para usuarios pertene-cientes al grupo y los otros), se usa el siguiente comando en la terminal.

u m a s k 022

El umask es una máscara que se aplica para determinar el valor por defecto de los permi-sos que tienen todos los archivos que se crean. Por defecto el valor inicial es 666, y al pasar por un umask de 022 se obtiene 644, o lo que es lo mismo -rw-r–r–.(Prasad,2012)

Para un mejor rendimiento en los tiempos de respuesta de peticiones de red entre el cluster se recomienda iniciar el proceso NTP, y preferiblemente habilitarlo, para que inicie al arrancar el sistema operativo.

s y s t e m c t l e n a b l e ntp s y s t e m c t l s t a r t ntp

(22)

Por otro lado, se requiere que los servicios de firewalld e iptables estén deshabilitados. s y s t e m c t l d i s a b l e f i r e w a l l d

s y s t e m c t l stop f i r e w a l l d s y s t e m c t l d i s a b l e i p t a b l e s s y s t e m c t l stop i p t a b l e s

Por último, selinux debe estar deshabilitado, por lo que se modifica el fichero /etc/selinu-x/config con lo siguiente.

...

S E L I N U X = d i s a b l e d ...

Fichero 3.4: /etc/selinux/config

Ahora se requiere realizar la configuración del servidor de Apache Ambari, razón por la cual los procedimientos próximos solo se necesitan para la maquina que aloja Ambari Server.

Lo primero, es garantizar que en el servidor se encuentren las dependencias requeridas.

Para empezar, se necesita un servidor de postgres corriendo, para lo cual se usará el manejador de paquetes del sistema operativo para obtener los paquetes necesarios.

yum i n s t a l l - y p o s t g r e s q l - s e r v e r \ p o s t g r e s q l - c o n t r i b p o s t g r e s q l \ p o s t g r e s q l - jdbc *

Además de la las librerías básicas de postgres, se instala postgres-jdbc el driver para co-nectarse a la base de datos. Es importante asegurar que el jdbc tenga los permisos correctos.

c h m o d 644 / usr / s h a r e / java / p o s t g r e s q l - jdbc ls - la / usr / s h a r e / java / p o s t g r e s q l - jdbc . jar

Ya está instalado el postgres, pero aún no hay ninguna estancia de ninguna base de datos, para lo cual se usan los siguientes comandos, primero se busca el binario postgresql-setup y

(23)

una vez localizado se usa para generar una instancia de la base de datos.

find / - name p o s t g r e s q l - s e t u p

/ usr / bin / p o s t g r e s q l - s e t u p i n i t d b s y s t e m c t l e n a b l e p o s t g r e s q l

s y s t e m c t l s t a r t p o s t g r e s q l s y s t e m c t l s t a t u s p o s t g r e s q l

Se modifican los ficheros /var/lib/pgsql/data/pg_hba.conf y /var/lib/pgsql/data/post-gresql.conf para que acepten peticiones de cualquier máquina en la red, ya sea por protocolo ipv4 o ipv6.

l o c a l all all t r u s t

host all all 0 . 0 . 0 . 0 / 0 t r u s t host all all ::/0 t r u s t

Fichero 3.5: /var/lib/pgsql/data/pg_hba.conf

...

l i s t e n _ a d d r e s s e s = ’ * ’ ...

Fichero 3.6: /var/lib/pgsql/data/postgresql.conf

Para que surta efecto los cambios es necesario reiniciar postgres.

Con postgres instalado, es necesario crear bases de datos para ciertas aplicaciones. Por el momento solo es necesario crear una para Hive, lo cual se consigue con el siguiente comando, donde $passwd es la contraseña guardada como variable de entorno.

echo " C R E A T E ␣ USER ␣ hive ␣ WITH ␣ P A S S W O R D ␣ ’ $passwd ’; " \ | sudo - u $ p o s t g r e s psql - U p o s t g r e s

echo " C R E A T E ␣ D A T A B A S E ␣ hive ␣ WITH ␣ O W N E R ␣ hive ; " \ | sudo - u $ p o s t g r e s psql - U p o s t g r e s

(24)

Ya con postgres instalado, se procede a agregar los repositorios de hdp y ambari dispo-nibles gracias a hortonworks. La version actual de los repositorios es la 3.1.0.0 para hdp y 2.7.3.0 para el repositorio de ambari. con yum repolist se listan los repositorios del sistema, con lo cual se asegura que se instalo el repositorio correctamente.

wget - nv \

http :// public - repo -1. h o r t o n w o r k s . com / HDP / c e n t o s 7 /3. x / u p d a t e s / 3 . 1 . 0 . 0 / hdp . repo \

- O / etc / yum . r e p o s . d / hdp . repo

wget - nv \

http :// public - repo -1. h o r t o n w o r k s . com / a m b a r i / c e n t o s 7 /2. x / u p d a t e s

/ 2 . 7 . 3 . 0 / a m b a r i . repo \

- O / etc / yum . r e p o s . d / a m b a r i . repo

yum r e p o l i s t

Una vez se tienen los repositorios en el sistema solo hace falta usar el manejador de paquetes para obtener el Ambari server.

yum i n s t a l l - y ambari - s e r v e r

Ambari server requiere de un proceso de configuración inicial, lo cual se consigue co-rriendo el siguiente comando.

ambari - s e r v e r s e t u p

A continuación la terminal pedirá un par de confirmaciones, lo cual puede observarse en la figura 3.2, empezando por la opción de configurar el demonio del Ambari Server. Entre las configuraciones se encuentra la posibilidad de usar el servicio de ambari con un usuario diferente al usuario root.

(25)

Figura 3.2: Proceso de instalación, primera parte

Como se observa en las ultimas figura 3.2 se debe seleccionar la versión del JDK a usar, y aceptar su respectiva licencia. Posterior a ésto la terminal pregunta si se desea instalar el software relacionado al proyecto que esté bajo la licencia GPL, opción que necesariamente debe confirmarse escribiendo ‘y’ en la terminal y presionando la tecla enter.

Figura 3.3: Proceso de instalación, segunda parte

Por último la terminal preguntará la base de datos que se desea usar y si se desea perso-nalizar la configuración de la base de datos, a lo cual se responde que ’n’ debido a que la base de datos de preferencia es postgres, y que la configuración por defecto es suficiente para los propósitos de ésta tesis.

Ahora se ejecuta el siguiente comando para indicar a Ambari donde está en conector a la base de datos.

ambari - s e r v e r s e t u p -- jdbc - db = p o s t g r e s \ -- jdbc - d r i v e r =/ usr / s h a r e / java / p o s t g r e s q l - jdbc . jar

(26)

ambari - s e r v e r s t a r t

Sí el proceso se llevó a cabo correctamente, este comando debería ser exitoso y responder que no se hallaron inconsistencias en la base de datos, como se ilustra en la figura 3.4. Esto debe haber iniciado un servicio web que se expone a través del puerto 8080 de la máqui-na maestro. Como las máquimáqui-nas en las que se está trabajando residen en un servidor en el centro de cómputo de la universidad distrital, fue necesario mapear el puerto 8080 al 200.69.103.29:34856 para poder acceder desde fuera de la red de doctorado de la Universidad Distrital Francisco José de Caldas.

Figura 3.4: Proceso de arranque del servidor de ambari

Al entrar al puerto indicado por medio de un navegador se observará una pantalla de login como se muestra en la figura 3.5.

(27)

Figura 3.5: Pantalla de login de Ambari.

Por defecto el usuario y la contraseña son admin. Una vez adentro, Ambari reconoce que no hay datos de ningún cluster ofrece como primera opción lanzar el instalador del cluster.

Figura 3.6: Lanzar wizard

(28)

’ce-CAPÍTULO 3. METODOLOGÍA Universidad Distrital Francisco José de Caldas

cad_cluster’ como se muetra en la figura 3.7.

Figura 3.7: Nombrar el cluster

Posterior a esto, Ambari solicita la versión deseada de HDP (Hortonworks Data Platform) que se desea instalar, teniendo en cuenta que dependiendo de la versión del HDP se tendrá acceso a unas versiones específicas de las aplicaciones que hacen parte del Hortonworks Data Platform.

Es posible configurar la instalación para hacer uso de un repositorio local en vez de los repositorios en línea, pero para este caso no es necesario, por lo que se prosigue con la instalación.

Ahora se debe introducir la información de los hosts, es posible usar expresiones regulares para mencionar los hosts.

En pasos anteriores se configuraron las llaves rsa para acceder desde la máquina maestro a todas las máquinas, ahora se requiere que pasemos esa misma llave.

(29)

Figura 3.8: Configurar el acceso de ambari a los hosts

Para conseguir la clave privada en una máquina que no se encuentra en la red de doctora-do de la universidad distrital, fue necesario copiar la llave a otro lugar diferente a doctora-donde está, ya que como se genero con el usuario root está en una ubicación protegida, por lo que se movió a /home/centos/id_rsa.

Ahora, desde la máquina usada para desplegar el cluster, la misma usada para acceder por ssh al resto de máquinas, se usa el siguiente comando para obtener esta clave.

sudo scp - P 3 4 6 8 6 - i b i g d a t a c e c a d . pem \ c e n t o s @ 2 0 0 . 6 9 . 1 0 3 . 2 9 : / home / c e n t o s

/ i d _ r s a / home / d a v i d / D o w n l o a d s /

Ahora se usa la clave que se consiguió, para que Ambari se conecte con todas las máqui-nas del cluster y pueda proceder con el despliegue. Con esto ya se tiene configurado la parte de los hosts y se puede continuar.

Sí todo se configuró correctamente, Ambari realiza un proceso de validación en cada host, y pasará exitosamente la prueba, como se observa en la figura 3.9, en donde se verifica que se pueda establecer una comunicación entre el servidor de ambari y las respectivas

(30)

máquinas que van a conformar el cluster. Al confirmar la disponibiblidad en los hosts se puede proseguir a escoger los servicios que se desean instalar en el cluster.

Figura 3.9: Validación del proceso de configuración previa para el despliegue de un cluster

De encontrarse problemas, el sistema advierte de las inconsistencias encontradas, con lo cual es posible tomar medidas correctivas. En el transcurso de desarrollar la tesis fue necesa-rio desplegar varias veces el cluster, y por cada vez que se llegó a éste punto, fue necesanecesa-rio detener procesos del sistema operativo en cada una de las máquinas, y desinstalar el software previamente instalado.

En el siguiente paso se debe escoger los servicios que se desean incluir en el despliegue del cluster. Como las máquinas asignadas no cuentan con demasiados recursos, es necesario incluir solo los servicios necesarios, ya que cada servicio adicional significa almacenamiento y el porcentaje de memoria RAM adicionales.

El primer servicio es esencial, y es sobre el cual reposan otros servicios, es el sistema de archivos HDFS, por lo que éste servicio viene seleccionado por defecto. Lo Siguiente es YARN y MapReduce que también es esencial para el funcionamiento del cluster. También es necesario seleccionar ZooKeeper, el cual es un sistema centralizado para el manejo de

(31)

seguridad del cluster. Por defecto Ambari instala el servicio Ambari Metrics, el cual sirve para recolectar información de funcionamiento del sistema. Por último se instalará Spark2 y Zeppelin Notebook para poder llevar a cabo una prueba de funcionamiento del cluster. Se requieren los servicios HIVE y Tez ya que algunos de los otros servicios seleccionados dependen de éstos.

En caso de requerir más adelante otro servicio, es posible añadirlo a partir del módulo de administración de Apache Ambari.

Al proseguir con el despliegue, se requiere escoger en donde se desea instalar cada com-ponente, como se observa en la figura 3.10. Se debe tener en cuenta que un servicio puede requerir más de un componente, y que cada componente puede alojarse en máquinas distin-tas, además de que cada servidor cuenta con recursos limitados y cada proceso consume una buena cantidad de espacio en la memoria ram, por lo que se deben repartir los componentes teniendo en cuenta estas variables.

(32)

Posterior a esto se requiere asignar los esclavos y los clientes, en donde los clientes instalarán las respectivas aplicaciones clientes para HDFS, YARN, MapReduce2, Tez, Hive, ZooKeeper y Spark2. El este paso el sistema avisa en qué máquinas corren procesos maestros, buscando prever que se saturen éstos servidores.

Figura 3.11: Asignación de procesos esclavos y clientes

Para continuar, ahora es requerido proveer credenciales a los sistemas que lo necesiten. Aparte, solicita la configuración de las bases de datos, a lo cual se busca conectarse a la que se creó previamente en el proceso de configuración.

También se requiere configurar el HDFS con la configuración que se muestra en la figura 3.12.

(33)

Figura 3.12: configuración del HDFS core-site

Esta configuración se descubre al hacer la prueba del cluster, ya que no fue posible subir archivos en primera instancia. Se descubre que como se realizó la instalación es en cluster es necesario especificar a todas las máquinas como hosts, ya que de otra manera se obtenia el siguiente error.

org . a p a c h e . h a d o o p . s e c u r i t y . a u t h o r i z e . A u t h o r i z a t i o n E x c e p t i o n : U n a u t h o r i z e d c o n n e c t i o n for super - user : root from IP 1 9 2 . 1 6 8 . 4 . 2 0 4

Con esto listo es posible continuar. En la figura 3.13 se observa el compendio general de la configuración realizada para el despliegue. es posible almacenar ésta información para replicar el cluster por medio de el servicio rest de apache ambari.

(34)

Figura 3.13: Revision del proceso de despliegue

Para terminar solo hace falta darle click a desplegar y esperar que el proceso se lleve a cabo.

Hecho esto, ya se tiene un cluster listo para realizar pruebas.

Esto nos deja en una pantalla donde se puede monitorear el estado del cluster con diferentes gráficas que reflejan el uso del disco, la cantidad de almacenamiento usada, y varios indicadores útiles para revisar el comportamiento del cluster como se puede observar en la figura 3.14

(35)

Figura 3.14: Métricas de funcionamiento del cluster

Cabe resaltar que por las especificaciones de las máquinas el cluster presentó problemas de rendimiento, por lo cual para la siguiente sección se modifica las caracteristicas del cluster.

3.2.2. Automatización del proceso de despliegue

Para este proceso el cluster tiene las siguientes especificaciones.

Master

• No procesadores: 16 • Memoria RAM: 14 GB • Sistema operativo: Centos 7 • Espacio en la raiz (/): 256 GB Slave1 y Slave2

• No procesadores: 4 • Memoria RAM: 8 GB

(36)

• Espacio en la raiz (/): 256 GB

Las ips en la red del CECAD son las siguientes 192.168.4.54 para la máquina maestro y 192.168.4.58 y 192.168.4.62 para las esclavas.

Con el proceso de configuración claro, es posible ahora automatizar el mismo, o por lo menos la parte que está a nivel de sistema operativo, ya que ahora se tiene la idea concreta del estado en el que se requiere que esté un servidor para llevar a cabo el proceso de despliegue, por lo que es posible usar herramientas de dev ops para replicar el proceso documentado previamente.

La herramienta adecuada para llevar a cabo el proceso de automatización es Ansible, con la cual es posible describir el proceso que debe realizar un servidor para estar acondicionado para el despliegue de un cluster de hadoop por medio de playbooks, por lo que al ejecutar un playbook, éste se remitirá al servidor sobre el cual recae dicho playbook y se encarga de garantizar que todo éste como lo dice el playbook, con validaciones que pueden llegar a ser bastante complejas de realizar en código en bash, como por ejemplo que los paquetes deseados estén instalados previamente y cosas por el estilo. Si un servidor ya cuenta con la configuración necesaria, no se repetirán procesos innecesariamente.

Ansible requiere de un par de llaves adicionales, las cuales se pueden generar desde una máquina externa a la red de doctorado de la universidad distrital. Se pueden generar usando el mismo comando usado previamente, ‘ssh-keygen’, pero la forma de copiarlas a las máquinas varía un poco, ya que toca especificar el puerto.

ssh - copy - id - p 3 4 6 8 6 r o o t @ 2 0 0 . 6 9 . 1 0 3 . 2 9 ssh - copy - id - p 2 4 3 4 1 r o o t @ 2 0 0 . 6 9 . 1 0 3 . 2 9 ssh - copy - id - p 2 4 4 1 5 r o o t @ 2 0 0 . 6 9 . 1 0 3 . 2 9

Se puede dividir el proceso en dos playbooks, en el primero se describe la configuración que es común para todas las máquinas, para dejar en un playbook aparte la configuración que es específica para la instalación del ambari server.

Lo primero que se define en un playbook es a qué hosts afectará el mismo, y con qué usuario accederá a dichos hosts. Estas variables se definen en un fichero aparte llamado

(37)

host.yml, el cual se explicará a continuación. all : h o s t s : m a s t e r : a n s i b l e _ s s h _ p o r t : 3 4 6 8 6 a n s i b l e _ s s h _ h o s t : 2 0 0 . 6 9 . 1 0 3 . 2 9 c h i l d r e n : s l a v e s : h o s t s : s l a v e 1 : a n s i b l e _ s s h _ p o r t : 2 4 3 4 1 a n s i b l e _ s s h _ h o s t : 2 0 0 . 6 9 . 1 0 3 . 2 9 fqdn : s l a v e 2 s l a v e 2 : a n s i b l e _ s s h _ p o r t : 2 4 4 1 5 a n s i b l e _ s s h _ h o s t : 2 0 0 . 6 9 . 1 0 3 . 2 9 Fichero 3.7: hosts.yml

En este yaml se están haciendo varias cosas, primero está declarando un host llamado master, el cual contiene 2 variables de host, por lo cual solo lo afectan a éste. La primera variable es usada por el mismo ansible para cambiar el puerto por defecto para la conexión ssh, el cual por defecto es el 22, pero como éstas máquinas se exponen para fuera de ésta red en una sola ip, pero en puertos diferentes, toca usar esta configuración. A parte de esta variable, se encuentra otra con la ip del host, también usada por ansible para la comunicación.

Después se está definiendo un grupo llamado slaves, que contiene los hosts slave1, slave2 y slave3, con sus respectivas variables. Si se desea agregar más hosts, es cuestión de agregarlos a la lista de hosts, aunque es posible también manejar rangos de ips para proveer estos datos.

Ahora se describe el yaml para la configuración común de todas las máquinas, el cual se llamará Configuración básica.

- name : C o n f i g u r a c i o n b a s i c a h o s t s :

(38)

CAPÍTULO 3. METODOLOGÍA Universidad Distrital Francisco José de Caldas m a s t e r s l a v e s r e m o t e _ u s e r : root v a r s _ f i l e s : - ./ vars / b a s i c _ v a r s . yml

Fichero 3.8: conf_basica.yml encabezado

En éste se declara que los hosts son todas las máquina definidas en el fichero hosts.yml, ya que se menciona al host master, que no se encuentra en ningún grupo, y el grupo de host slaves, en donde se encuentra el resto de las máquinas.

Posterior a ésto, se declara que se deben realizar los comandos posteriores con el usuario root, y que las variables usadas en éste playbook, y en los templates que se usan para mo-dificar los ficheros de configuración de los sistemas operativos, se encuentran en el fichero ./vars/basic_vars.yml. m a q u i n a s : - n o m b r e : m a s t e r ip : 1 9 2 . 1 6 8 . 4 . 5 4 - n o m b r e : s l a v e 1 ip : 1 9 2 . 1 6 8 . 4 . 5 8 - n o m b r e : s l a v e 2 ip : 1 9 2 . 1 6 8 . 4 . 6 2 p a q u e t e s : - curl - u n z i p - tar - wget - gcc - ntp Fichero 3.9: ./vars/basic_vars.yml

Con esto presente, es hora de describir las tareas que se requieren, las cuales ya se expli-caron en su mayoría anteriormente. Esto se describe en la sección tasks, la cual contiene una

(39)

lista de las tareas necesarias para todos los hosts.

t a s k s : - name : C o n f i g u r a r sshd t e m p l a t e : src : ./ t e m p l a t e s / s s h d _ c o n f i g . j2 dest : / etc / ssh / s s h d _ c o n f i g r e g i s t e r : r e s _ s s h d - name : R e i n i c i a r sshd s e r v i c e : name : sshd s t a t e : r e s t a r t e d when : r e s _ s s h d . c h a n g e d == true

Fichero 3.10: conf_basica.yml - Tareas 1

La primera tarea hace uso del módulo template de ansible, el cual permite escribir plan-tillas en jinja2, y llenar espacios faltantes con variables del host, o del entorno entre otras posibilidades. En este caso no fue necesario ninguna variable, pues lo deseado en éste caso es copiar tal cual la plantilla, ya que no usa ninguna variable, sino que es una configuración genérica del fichero /etc/ssh/sshd_config, asegurando que el valor sea posible autenticarse con contraseña por peticiones ssh con el parámetro “PasswordAuthentication yes”.

Con ansible es posible guardar una variable con la respuesta de una tarea, la cual trae parámetros como sí la tarea fue exitosa, si realizó cambios en el sistema, la salida estándar, entre otros, con la restricción acceso pues estas variables solo son visibles desde cada host, lo cual tiene sus ventajas y desventajas. Para el caso es de interés saber si la tarea realizó algún cambio, ya que si así fue es requerido reiniciar el servicio.

En la siguiente tarea, Reiniciar sshd, se usa el módulo service de ansible el cual provee control sobre los servicios de un sistema operativo. En dicha tarea se usa la sentencia when, la cual condiciona la tarea realizando ésta exclusivamente si la condición es verdadera. Se usa para reiniciar el servicio sshd únicamente sí el fichero /etc/ssh/sshd_config fue modificado por la tarea anterior.

(40)

- name : I n s t a l a r p a q u e t e s b a s i c o s yum :

name : " {{ ␣ p a q u e t e s ␣ }} "

En la tarea Instalar paquetes básicos, se puede observar como haciendo uso de el módulo yum, se accede a las variables declaradas en ./vars/basic_vars.yml, en donde se define la variable paquetes, la cual contiene un arreglo con las dependencias necesarias para usar el ambari agent en cada máquina. Al ser la variable paquetes una lista, el módulo yum iterará entre cada elemento.

- name : C o n f i g u r a r l i m i t s t e m p l a t e :

src : ./ t e m p l a t e s / l i m i t s . j2

dest : / etc / s e c u r i t y / l i m i t s . conf

- name : A g r e g a r los h o s t s en la l i s t a de h o s t s t e m p l a t e :

src : ./ t e m p l a t e s / h o s t s . j2 dest : / etc / h o s t s

En las siguientes tareas se vuelve a hacer uso del módulo template, pero esta vez, en Agregar los hosts en la lista de hosts, se hace uso de las variables definidas, ésta vez desde una plantilla en jinja2.

1 2 7 . 0 . 0 . 1 l o c a l h o s t l o c a l h o s t . l o c a l d o m a i n l o c a l h o s t 4 l o c a l h o s t 4 . l o c a l d o m a i n 4

::1 l o c a l h o s t l o c a l h o s t . l o c a l d o m a i n l o c a l h o s t 6 l o c a l h o s t 6 . l o c a l d o m a i n 6

(41)

{ % for m a q u i n a in m a q u i n a s %}

{{ m a q u i n a . ip }} {{ m a q u i n a . n o m b r e }}. c e c a d { % e n d f o r %}

Fichero 3.13: ./templates/hosts.j2

En el fichero 3.13 el cual es una plantilla en Jinja2, se observa una iteración en una lista, con la cual se busca registrar todos los hosts en el fichero /etc/hosts.

- name : C o n f i g u r a r h o s t n a m e h o s t n a m e : name : " {{ i n v e n t o r y _ h o s t n a m e }}. c e c a d " - name : H a b i l i t a r ntp s e r v i c e : name : sshd s t a t e : s t a r t e d

Para configurar el hostname se usó el módulo hostname y las variables especiales de ansi-ble. En estas variables se puede obtener información del host sobre el que se está trabajando, como el nombre que se le dió en el la descripción de los hosts o el sistema operativo, como también se obtiene información sobre las otras máquinas de la red.

Por otro lado se habilitó ntp por medio del módulo service.

- name : G e n e r a r l l a v e s p u b l i c a y p r i v a d a o p e n s s h _ k e y p a i r : path : / root /. ssh / i d _ r s a r e g i s t e r : r e s u l t a d o when : i n v e n t o r y _ h o s t n a m e == " m a s t e r " - name : G u a r d a r l l a v e p u b l i c a a d d _ h o s t :

(42)

CAPÍTULO 3. METODOLOGÍA Universidad Distrital Francisco José de Caldas name : " l l a v e _ p u b l i c a " v a l o r : " ␣ {{ ␣ r e s u l t a d o [ ’ p u b l i c _ k e y ’] ␣ }} " when : r e s u l t a d o . c h a n g e d == true - name : C o p i a r l l a v e a u t h o r i z e d _ k e y : user : root s t a t e : p r e s e n t key : " {{ ␣ h o s t v a r s [ ’ l l a v e _ p u b l i c a ’][ ’ valor ’] ␣ }} " when : " h o s t v a r s . l l a v e _ p u b l i c a ␣ is ␣ d e f i n e d "

Crear la llave rsa fue sencillo usando otro módulo de ansible llamado openssh_keypair el cual genera un par de llaves pública y privada en la ubicación especificada. Con la cláusula when se logra ejecutar ésta tarea únicamente en el host master de ambari, que es desde la máquina que se piensa desplegar el cluster y la que requiere el acceso a las máquinas. Se agrega la sentencia register para guardar el resultado de ésta operación con el fin de propagar las llaves si fue necesario la creación de un nuevo par de llaves.

Para la propagación de las llaves rsa hubo una complicación, ya que como se mencionó previamente, cada variable se puede acceder exclusivamente desde el host al que le per-tenece, por lo que propagar la llave presentó un problema, ya solo se tiene acceso a los ficheros de la llaves pública y privada desde adentro de la máquina en donde se generaron, el host identificado como master. Se notó, que aunque el proceso de creación de las llaves se omite en los hosts diferentes al master, el proceso de register igual genera información, comunicando que no se realizó cambio alguno.

La solución se halló en el módulo add_host, con el cual se creó un host en tiempo de ejecución en el cual se guardó la variable llave_publica con el contenido de la llave pública generada en la tarea anterior. Con ésto se persiste la llave, y se puede acceder al valor de dicha variable, ya que se conoce el nombre del host y el nombre de la variable por medio de las variables mágicas de ansible. Se usó de nuevo la cláusula when para que solo se realice ésta tarea en el host donde la tarea cambio datos en el host.

Con la clave guardada como variable en un host, solo hace falta copiarla a todas las máquinas, para lo cual se usa el módulo authorized_key el cual recibe una llave pública y la

(43)

agrega a la lista de host conocidos, por lo cual se debe correr ésta tarea en todos los hosts, pasando como parámetro la clave pública generada previamente y el usuario con el cual se desea acceder. En esta tarea se usó la cláusula when para confirmar que existe un host llama-do clave_publica, por lo que solo se realiza esta tarea cuanllama-do se genera un nuevo par de llaves.

- name : C o n f i g u r a r / etc / s y s c o n f i g / n e t w o r k t e m p l a t e : src : ./ t e m p l a t e s / s y s c o n f i g _ n e t w o r k . j2 dest : / etc / s y s c o n f i g / n e t w o r k - name : D e s h a b i l i t a r S E L i n u x s e l i n u x : s t a t e : d i s a b l e d - name : C o n f i g u r a r u m a s k r e p l a c e : path : / etc / p r o f i l e r e g e x p : ’ u m a s k ␣ 002 $ ’ r e p l a c e : ’ u m a s k ␣ 022 ’

Por terminar con el playbook solo hace falta configurar el /etc/sysconfig/network para que contenga el hostname, deshabilitar el SELinux y configurar el umask. Para la configura-ción de umask se modifica el fichero que define ésta variable para cada sesión, por medio del fichero /etc/profile, en el cual se busca y reemplaza la expresión regular ‘umask 002$’ por ‘umask 022’. El signo $ hace referencia al salto de línea, por lo que la expresión ‘umask 002X’ no encaja con ésta expresión regular, con lo cual se evitan errores. Con ésto ya queda lista la configuración básica de todas las máquinas.

Ahora solo hace falta la configuración específica para el servidor de ambari, la cual se describe en ambari_conf.yml.

(44)

CAPÍTULO 3. METODOLOGÍA Universidad Distrital Francisco José de Caldas h o s t s : m a s t e r r e m o t e _ u s e r : root v a r s _ f i l e s : - ./ vars / p o s t g r e s _ v a r s . yml t a s k s : - name : I n s t a l a r p o s t g r e s yum : name : " {{ ␣ p a q u e t e s ␣ }} " - name : C o r r e r P o s t g r e S Q L s e r v i c e : name : p o s t g r e s q l s t a t e : s t a r t e d e n a b l e d : yes - name : C a m b i a r p e r m i s o s al jdbc file :

path : / usr / s h a r e / java / p o s t g r e s q l - jdbc . jar mode : ’ 0644 ’

Fichero 3.17: ambari_conf.yml parte 1

Se puede observar que ésta vez en los hosts se seleccionó al master exclusivamente. Al igual que el anterior playbook todas las acciones se realizan con el usuario root del sistema. Las variables usadas por éste playbook se encuentran en ./vars/postgres_vars.yml.

p a q u e t e s : - p o s t g r e s q l - s e r v e r - p o s t g r e s q l - c o n t r i b - p o s t g r e s q l - p o s t g r e s q l - d e v e l - p o s t g r e s q l - jdbc * - epel - r e l e a s e - python - pip

(45)

p a q u e t e s _ p i p :

- psycopg2 - b i n a r y - p s y c o p g 2

Fichero 3.18: ./vars/postgres_vars.yml

La primera tarea consiste en instalar las dependencias necesarias para la instalación de ambari server, entre ellos postgres, el conector jdbc para la base de datos. Además de ésto, también se instalan dependencias de psycopg2, un conector hecho en python para postgres, el cual es usado por los módulos de conexión con postgres de ansible, como postgresql_user y postgresql_db. Con las dependencias instaladas se usa el módulo service para asegurar que el servicio de postgres esté corriendo. Posteriormente, se especifican los permisos 644 para el jdbc.

- name : i n s t a l a r p a q u e t e s pip pip :

name : " {{ p a q u e t e s _ p i p }} "

- name : C r e a r u s u a r i o en p o s t g r e s para hive p o s t g r e s q l _ u s e r :

name : hive

p a s s w o r d : c e c a d 1 2 3

- name : C r e a r base de d a t o s para hive p o s t g r e s q l _ d b :

name : hive o w n e r : hive

Se instalan los paquetes psycopg2 y psycopg2-binary, los cuales, como ya se mencionó anteriormente, son necesarios para usar los módulos postgresql_user, el cual es usado para crear el usuario hive en postgres, y postgresql_db con el cual se crea la base de datos hive, perteneciente al usuario hive.

(46)

- name : C o n f i g u r a r p g _ h b a t e m p l a t e :

src : ./ t e m p l a t e s / p g _ h b a . j2

dest : / var / lib / p g s q l / data / p g _ h b a . conf r e g i s t e r : r e s _ p g _ h b a

- name : C o n f i g u r a r p o s t g r e s . conf t e m p l a t e :

src : ./ t e m p l a t e s / p o s t g r e s . j2

dest : / var / lib / p g s q l / data / p o s t g r e s . conf r e g i s t e r : r e s _ p o s t g r e s

- name : R e i n i c i a r P o s t g r e S Q L s e r v i c e :

name : p o s t g r e s q l s t a t e : r e s t a r t e d

when : " r e s _ p g _ h b a . c h a n g e d == true ␣ or ␣ r e s _ p o s t g r e s . c h a n g e d == true "

Se configuran los ficheros pg_hba y postgres.conf con por medio de módulo template, con las especificaciones descritas en listing 5 y listing 6, y se guarda la respuesta de ambos, cosa tal que si alguna de las dos tareas efectúa un cambio en el sistema, se debe reiniciar el servicio de postgres.

- name : Add r e p o s i t o r y hdp y u m _ r e p o s i t o r y :

name : hdp

b a s e u r l : http :// public - repo -1. h o r t o n w o r k s . com / HDP / c e n t o s 7 /3. x / u p d a t e s / 3 . 1 . 0 . 0 /

d e s c r i p t i o n : hdp repo r e g i s t e r : res

- name : Add r e p o s i t o r y a m b a r i y u m _ r e p o s i t o r y :

(47)

name : a m b a r i

b a s e u r l : http :// public - repo -1. h o r t o n w o r k s . com / a m b a r i / c e n t o s 7 /2. x / u p d a t e s / 2 . 7 . 3 . 0 /

d e s c r i p t i o n : a m b a r i repo

- name : I n s t a l a r a m b a r i s e r v e r yum :

name : " ambari - s e r v e r "

Por último, solo hace falta agregar los repositorios, lo cual se logra usando el módulo yum_repository e instalar ambari server por medio de la paquetería del sistema.

Se buscó la manera de correr el comando de ambari-server setup, pero como dicho comando recibe datos de entrada por medio de terminal, se opta por realizar éste paso manualmente, por lo que se ingresó directamente a la máquina por medio de ssh y se ejecuto dicho comando teniendo en cuenta lo paramtros mencionados con anterioridad.

Hace falta solamente indicar a ambari server donde se encuentra el jdbc para correr de nuevo el servicio de ambari server para desplegar futuros clusters por medio del wizard de ambari, como se realizó anteriormente.

(48)

Capítulo 4

Pruebas de funcionalidad

Para llevar a cabo un proceso de pruebas para confirmar que los servicios funcionan correctamente, se instaló hive y spark2. Para comenzar, se importa el fichero de prueba geolocation.csv y el fichero trucks.csv desde el sistema de archivos remoto, en una má-quina fuera de la red de doctorado de la universidad distrital, lo cual se hace por medio de la vista de ficheros de Apache Ambari. Estos ficheros se encuentran disponibles en https://www.cloudera.com/content/dam/www/marketing/tutorials/getting-started-with-hdp-sandbox/assets/datasets/Geolocation.zip.

Para cargar ficheros usando la vista de ficheros se busca en la esquina superior derecha como se ve en la figura 4.1

Figura 4.1: Cambiar a vista de ficheros

La vista de ficheros se asemeja mucho a navegar en un gestor de archivos como se ve en la figura 4.2.

(49)

CAPÍTULO 4. PRUEBAS DE FUNCIONALIDADUniversidad Distrital Francisco José de Caldas

Figura 4.2: Vista de ficheros

Desde esta vista se pueden crear directorios desde el panel superior derecho. Se crea el directorio data en la ruta /tmp/.

Figura 4.3: Carga de datos por vista de ficheros

Desde el mismo panel se pueden cargar ficheros desde el sistema de archivos directamen-te al HDFS. Por ésdirectamen-te medio se cargan los ficheros geolocation.csv y trucks.csv en el clusdirectamen-ter. Al terminar el proceso el resultado se debe visualizar similar al de la figura 4.3

Desde esta vista se permite también la gestión de permisos de los ficheros y directorios como refleja la figura 4.4. Para el caso se le dará permisos de escritura para todos los usuarios a los ficheros cargados previamente.

(50)

Figura 4.4: Edición de permisos desde vista de ficheros

Con los ficheros en el sistema de archivos distribuido, ahora se puede usar los datos desde aplicativos como spark2. Por medio de los diferentes servicios que suministra hadoop, como spark2 se puede acceder a los datos del sistema de archivos, procesar los mismos para obtener nueva información, mostrar los datos obtenidos, guardarl dichos resultados en ficheros y almacenarlos en el HDFS entre otras opciones.

Para esto, se usa zeppelin, por lo cual se accede a dicho servicio. Por defecto zeppelin corre en el puerto 9995, pero como se explicó anteriormente es necesario mapear este puerto para ser accedido desde fuera de la red de doctorado, para lo cual se estableció el puerto 33847 en la ip 200.69.103.29.

Para usar zeppelin es necesario una sesión, en estas pruebas se uso el usuario admin, el cual tiene como contraseña nuevamente la palabra admin.

Con un usuario registrado en zeppelin es posible crear un notebook. Se crea un notebook con las opciones que se muestran en la figura 4.5.

(51)

Figura 4.5: Creación de un notebook de zeppelin

Desde el notebook se realiza el siguiente comando con el fin de conectar spark2 con hive como se muestra en la figura 4.6.

Figura 4.6: Conexión de spark2 con hive

Para observar si la conexión es correcta se puede usar el comando SHOW TABLES, con el cual se ´rueba si se tiene acceso a comandos SQL dispuestos por hive. Como no se ha creado ninguna tabla, se obtiene una respuesta sin ningun registro como muestra la figura 4.7.

(52)

Figura 4.7: Conexión exitosa con hive

Desde spark2 se pueden cargar los datos que se tienen en el sistema de archivos de ha-doop a tablas en hive, con lo cual se creará la tabla geolocation con los datos contenidos en /tmp/data/geolocation.csv.

Figura 4.8: Cargar datos geolocation en hive

Ahora se puede confirmar que los datos fueron cargados por medio de un select a la tabla geolocation como se ilustra en la figura 4.9.

(53)

Figura 4.9: Operación select en hive por medio de spark2

De la misma forma se puede cargar los datos contenidos en /tmp/data/trucks.csv en una tabla en hive.

Figura 4.10: Cargar datos trucks en hive

Es posible también crear nuevas tablas en hive a partir de las tablas existentes o producto de una consulta previa como se muestra en la figura 4.11.

(54)

Se puede comprobar la creación de la tabla anterior por medio de la sentencia "Select * from truckmilage".

Para terminar, se muestra como escribir una consulta a un fichero en el sistema de ar-chivos HDFS, lo cual se logra modificando el comando anterior, para que ya no muestre las respuesta sino la guarde en una variable como se ilustra en la figura 4.12.

Figura 4.12: Guardar una consulta en una variable

La variable prueba se guarda en el sistema de ficheros con el comando que se muestra en la figura 4.13.

Figura 4.13: Escribir una variable en el sistema de ficheros

Se puede observar por medio de la vista de ficheros como se creo de manera exitosa el directorio prueba.

Con ésto se comprueba que los servicios instalados previamente haciendo uso de Ambari server funcionan como se espera con lo cual ya se cuenta con un cluster funcional para el trabajo con grandes cúmulos de datos, y aunque por ahora solo se hizo uso de 2 servicios, Spark2 y zeppelin, a medida que se requieran nuevos servicios se pueden instalar y probar según la necesidad.

(55)

Capítulo 5

Conclusiones

Se logró efectuar la configuración de un cluster de hadoop, en un conjunto de máquinas alojadas en los servidores del CECAD, donde se realiza un despliegue de las herramien-tas requeridas para realizar una prueba de funcionamiento de las herramienherramien-tas que ofrece el proyecto hadoop y todos los proyectos asociados a éste.

Se automatizó el proceso de configuración en Playbooks de Ansible, con lo cual se tiene persistencia de todas las tareas requeridas para el montaje de un cluster de hadoop, y se puede replicar en diferentes ambientes.

Es muy importante disponer de las máquinas virtuales con los requerimientos adecua-dos, ya que se presentó el caso que algunas máquinas del cluster se vuelven inaccesibles. Cada proceso maestro requiere procesamiento en las máquinas que lo aloja y en las cuales están los servicios cliente, por lo cual debe tenerse en cuenta el número de servicios que se requieren corriendo, ya que es puede saturar las respectivas máquinas. Con ésta solución es posible desplegar cualquier número de máquinas para cumplir cualquier rol en el cluster. También se puede usar para agregar nuevas máquinas a un clúster existente, con lo cual se puede replicar el proceso en cualquier otro ambiente en donde se tenga acceso a varias máquinas con los recursos suficientes.

Es posible adaptar el codigo para que funcione en otros sistemas operativos, ya que en el script se usan módulos como yum que están ligados a un sistema operativo con paquetería RPM, y por otro lado, las direcciones que se usan son las que maneja centOS 7.

(56)

Capítulo 6

Futuros trabajos

Como ya está automatizado el proceso de despliegue de un cluster, ahora se puede em-pezar a realizar pruebas de las diferentes herramientas que componen dicho cluster, desde las diferentes intenciones que se presentan en la academia o en el ámbito comercial, ya que hadoop cuenta con un gran número de proyectos que lo rodean, los cuales proveen la posibilidad de analizar diferentes tipos de datos, como streamings o lotes de datos.

Sería posible incluso abrir espacios académicos destinados para diferentes áreas del conocimiento que se trabajan en nuestra universidad, en donde el campo de la big data se está popularizando como las ciencias o las ingenierías.

(57)

Referencias

Ansible. (2019, Noviembre). It automation. Descargado dehttps://www.ansible.com/ overview/it-automation

Bal, E. (2002). High performance computing and the medical industry. IEEE. Christof Ebert, J. H. N. S., Gorka Gallardo. (2016). Devops. IEEE.

Cloudera. (2019, Noviembre). Apache Ambari installation. Descargado de https://docs.cloudera.com/HDPDocuments/Ambari-2.7.1.0/bk_ambari

-installation/content/ch_Getting_Ready.html

Cáliz, R. (2017a, Octubre). Sabio i summary. (Especificaciones Sabio I) Cáliz, R. (2017b, Septiembre). Sabio i summary. (Especificaciones Sabio II)

Cáliz, R. (2019, Noviembre). ¿Qué es el CECAD? Descargado dehttps://cecad.udistrital .edu.co/index.php/home/que-es-el-cecad

Lucia Morganti, A. F., Daniele Cesini. (2016). Evaluating systems on chip through hpc bioinformatic and astrophysic applications. IEEE.

Piccoli, M. F. (2011). Computación de alto desempeño en gpu. Edulp.

Prasad, G. (2012). What is umask? Descargado dehttp://www.theunixschool.com/2012/ 04/what-is-umask.html

Ryan McKinney, R. V. N. M. T., Vivek K. Pallipuram. (2015). From hpc performance to climate modeling: Transforming methods for hpc predictions into models of extreme climate conditions. IEEE.