Instalación de un entorno Hadoop con Ambari en AWS

1
13096

Instalación de un entorno Hadoop con Ambari en AWS

Contenidos.

Prerrequisitos.

Si quieres aprovechar bien el contenido de este tutorial, deberás tener:

  • conocimientos de la arquitectura de Hadoop. Nivel medio.
  • conocimientos de administración de Linux. Nivel medio.
  • conocimientos de administración de Redes/Seguridad. Nivel básico.

Sobre todo el primer punto es importante. En este tutorial no se explica la arquitectura Hadoop. 😉

Introducción y objetivos.

El objetivo de este tutorial es aprender a instalar, configurar y monitorizar un cluster Hadoop en modo distribuido, mediante el framework Ambari, todo ello usando máquinas virtuales de AWS. Espero que os sea útil.

¿Qué es Hadoop?

Hadoop es el nombre del peluche que tenía el hijo de Doug Cutting, uno de los dos creadores de Hadoop junto con Mike Cafarella. Aparte de esto, Hadoop es un framework de código abierto creado en 2005 usado para almacenar, procesar y analizar grandes volúmenes de datos, enfocado en el paradigma MapReduce.

Hadoop se encuadra dentro del frameork Apache y posee su propio sistema de archivos o filesystem (HDFS: Hadoop Distributed File System) y un entorno de utilidades adicionales (aunque opcionales) que facilitan ciertas tareas (ecosistema Hadoop: Flume, Nagios, HBase, Ganglia, Scoop, ZooKeeper, Pig, Flume. El nombre de “ecosistema” es obvio como deduciréis). Actualmente tanto Hadoop como su ecosistema están en contínua evolución debido a sus evidentes ventajas: gratuito y efectivo.

TODO: en otros tutoriales explicaré más en detalle qué es eso de MapReduce (a mí la primera vez me costó entenderlo), HDFS, y el ecosistema Hadoop.

¿Qué es Ambari?

Para aprovechar bien las capacidades del entorno Hadoop conviene disponer de un mainframe distribuido (cluster) y proceder a la instalación y configuración de toda la arquitectura de los nodos maestro/esclavo/backups en distintas redes y/o servidores. Hacer esto manualmente es un trabajo complicado y bastante propenso a errores. Pensar en todos los pasos que hay que seguir en todos los nodos: instalación del paquete de hadoop, configuración de variables de entorno, definición de archivos de configuración, definir permisos, levantar demonios, etc.

Además, la posterior administración y monitorización de un entorno distribuido como Hadoop es oscura.

TODO: en otro tutorial explicaré en detalle cómo instalar una arquitectura Hadoop manualmente y desde cero.

Para aliviar todos estos inconvenientes surge Ambari: Ambari es un framework open source de la empresa HortonWorks. Consiste en un conjunto de herramientas diseñadas para simplificar la instalación y monitorización de un cluster Hadoop.

¿Qué es AWS?

Amazon Web Services (AWS) es una suite de herramientas basadas en la nube que ofrece un conjunto de servicios globales de informática, almacenamiento, bases de datos, análisis, aplicaciones, etc. Para el contexto de nuestro objetivo, AWS ofrece varios servicios basados en la nube, incluida una serie de instancias de máquinas virtuales cuyo escalado se puede aumentar y reducir automáticamente, todo esto gratuitamente (siempre que esté correctamente gestionado. Ya lo veremos más adelante).

Como es evidente poca gente (salvo perfiles tipo administradores de Entornos Productivos o Centros de Procesamiento en empresas o instituciones públicas) tiene acceso a un cluster real para poder experimentar o trabajar con una arquitectura real distribuida. Considerar que un entorno medianamente “real” de Hadoop es a partir de 4-8 nodos (actualmente hay empresas con más de 1500 nodos activos). Podemos montarnos nuestro propio cluster compartiendo varias máquinas físicas en red, de compañeros por ejemplo, o bien lanzar varias máquinas virtuales en la misma máquina (si tu equipo lo soporta claro).

Pero la mejor alternativa es usar AWS lo que nos permite definir mediante máquinas virtuales (o instancias) un cluster y poder trabajar con él de forma sencilla (más o menos), e independiente. AWS permite definir N máquinas virtuales con grandes capacidades hardware/software, todo ello en la nube por lo que localmente no necesitaremos de un gran equipo.

Entorno.

Para seguir los pasos en este tutorial necesitaremos:

  • Sistema Operativo Linux: lo usaremos para conectarnos a cada una de las instancias y poder configurarlas. Yo he usado una máquina virtual Linux CentOS v6 (64 bits, requerido por Hadoop) y 8Gb RAM. Os recomiendo la distribución CentOS ya que es la más popular dentro de la comunidad Hadoop.

Nuestro trabajo estará en la nube por lo que básicamente esto es todo lo que necesitas. Si no tienes un Linux en local también puedes trabajar desde Windows aunque algunas cosas se complicarán.

Definición de las instancias en Amazon Web Services.

Manos a la obra. Empezaremos definiendo nuestra cuenta en Amazon web services. Si ya tienes una, sáltate esta primera parte. Para ello:

NOTA: el equipo de Amazon cambia constantemente la interfaz de AWS, por lo que no puedo asegurar que las capturas que aparezcan en este manual se correspondan con la versión que estéis usando en vuestras pruebas.

  1. Accede a http://aws.amazon.com/es/ y dar en “Cree una cuenta Gratuita”. Rellena los diferentes formularios con tus datos:

  2. Lo importante a tener en cuenta viene en la siguiente pantalla. Amazon te ofrece 1 año gratuito de servicios pero tendrás que indicar tu tarjeta de crédito/débito (debe ser real). Tranquilo, no te harán cargo alguno siempre que uses servicios gratuitos, como los de este tutorial. Puedes obtener más información aquí https://aws.amazon.com/es/free/ aunque Amazon te informa muy claramente, de cuándo un servicio que has seleccionado es o no de pago y cuánto te va a facturar:

  3. Una vez verificados los datos proporcionados de la tarjeta y elegido el plan que deseas (AWS Support (Basic)), recibirás varios correos de bienvenida y ya tendrás la cuenta de AWS creada. Accede a ella.

    Lo siguiente será crear las máquinas virtuales o instancias como las llama Amazon. No es difícil pero hay que dar una serie de pasos que no son intuitivos, pero hay que darlos para que todo encaje posteriormente.
  4. Accede a tu nueva cuenta AWS. No te marees por la cantidad de servicios que nos ofrecen. Sólo vamos a necesitar uno: EC2. Lo primero que yo haría es definir la zona horaria. La zona disponible más acorde a nuestro uso horario (UTC+01) es Irlanda. Cámbialo desde la vista general de Servicios:

  5. Accede a “EC2 Virtual Servers” y luego a instancias. Aquí es donde crearemos las máquinas virtuales. Pulsa en “Launch Instance”. De todas las que salen, selecciona la versión Red Hat Enterprise Linux 6.5 para 64 bits (1 core, 512 Mb RAM). Recuerda que para aprovechar Hadoop hay que usar entornos de 64 bits. Fíjate también en el subtítulo “Free tier Elegible”: así estamos seguros de usar un servicio gratuíto.

    Aunque lo más lógico hubiera sido elegir la última versión 7.0 de Red Hat (la primera de todas en la lista), posteriormente nos hubieran aparecido errores en la instalación de Ambari:

  6. Pulsaremos en “Next” en las sucesivas pantallas de configuración dejando por defecto todos los valores hasta pulsar en “Review and Launch”. Nos aparecerá algo como esto:

    El warning nos indica que el nivel de seguridad de la instancia es bajo ya que será accesible desde el exterior. De momento lo obviamos y pulsamos en “Launch”.

  7. Aquí definiremos el fichero .pem con las claves para permitir el acceso a nuestros nodos Linux. Generaremos un nuevo fichero de claves y lo guardamos en local ya que lo necesitaremos posteriormente (no perder este archivo). Pulsamos en “Launch Instances”:

    La segunda recomendación es opcional pero te recomiendo que la sigas. Sirve para configurar una alerta por correo cuando esté previsto realizar un cargo en la tarjeta.

  8. En la vista de instancias, verás tu nueva instancia corriendo (por defecto al crear una instancia se levanta automáticamente. Esto no debería ser así). Las propiedades que se muestran en cada columna y que merecen ser comentadas son:
    • Name : nombre nemotécnico que quieras darle. Es un TAG AWS. AWS te permite gestionar TAGs en entidades (BBDD, instancias, volúmenes, etc.) para poder definir valores personalizados. El TAG “Name” de Instances viene creado por defecto.
    • Instance type : debe ser la gratuita: t1.micro.
    • Availibity zone : zona horaria que hemos configurado: eu-west.
    • Instance state : estado. Aquí es importante tener claro los conceptos:
      1. Stopped: equivale a un shutdown. Cuando veas que no vas a seguir trabajando más, deja las instancias en este estado.
      2. Terminated: cuidado porque esto borra la instancia definitivamente. No usar nunca salvo para limpieza. Una vez en este estado, tarda tiempo en desaparecer definitivamente la instancia de la lista.
      3. Running: pues eso. Aunque te salgas de la sesión AWS, las máquinas en este estado no se pararán.
    • Alarm status : si tienes configuradas alarmas, aparecerán aquí.
    • Public IP : por defecto tienes una IP dinámica que cambiará cada vez que levantes la instancia. Más adelante veremos cómo resolver esto.
    • Key name : nombre del fichero .pem usado. Por comodidad debería ser el mismo para todas las instancias.
    • Security groups: define la seguridad del tráfico de la red in/out. Luego lo veremos. Por defecto asigna un grupo “launch-wizard-N” sin restricciones para el tráfico entrante.
  9. A continuación definiremos la seguridad del tráfico en la red para la instancia. Nos vamos a la vista de “Security Groups” y pulsamos en “Create Security Groups”. Indicamos un nombre y pulsamos en “Add Rule” para definir las reglas inbound:

    Debemos definir reglas para los protocolos SSH y HTTP. Lo más simple es no indicar restricciones de IPs (Source=Anywere) pero lo mejor es restringir a nuestra red (Source=Custom IP):

    Volvemos a la vista de instancias, “ActionsàNetworkingàChange Security Groups” y seleccionamos el nuevo grupo creado.

  10. Ahora “clonaremos” esta instancia para tener finalmente el número de nodos deseado. Para ello, en la vista de instancia, “ActionsàLaunch more like this” y repetiremos el proceso para cada nodo salvo que ahora indicamos el fichero de claves .pem previamente creado (y tildar la opción “I acknowledge that I have access to the selected prívate file….”). Por defecto, AWS asociará una misma imagen (Amazon Machine Image AMI) para cada instancia con toda la configuración definida, así que no tenemos que preocuparnos de esta gestión.

    En el modelo AWS, cualquier instancia procede de una AMI. Es como lo tienen montado.

    Otra forma de proceder hubiera sido al comienzo, al crear la primera instancia indicamos “Number of instances=N” pero entonces el proceso de configuración posterior tendría que haberse repetido N veces.
  11. Este paso es opcional pero recomendable por la comodidad que posteriormente ofrece.
    A continuación definiremos las IPs de los nodos para que sean estáticas entre reinicios. A esto Amazon lo llama “Elastic IPs” (EIP). Nos vamos a la vista de “Elastic IPs” y pulsamos en “Allocate New Address”, y seleccionamos la instancia. Repite el proceso para cada instancia.
    Sólo podremos definir/asignar 5 IPs como máximo (importante limitación). Cuidado, el uso de EIPs a instancias que no están en ejecución (Running) tiene asociado un cargo mensual en tarjeta ($0.005 por Elastic IP).

    Al final nos debería quedar algo como lo siguiente:

Configuración de los nodos Hadoop.

Antes de instalar Ambari, debemos dejar los nodos del cluster Hadoop configurados para que Ambari los pueda reconocer. Para ello:

  • En nuestro Linux en local debemos tener copiado (en el $HOME por ejemplo) el fichero de claves .pem que hemos generado. A continuación y con permisos de root, registramos las IPs de cada nodo en el fichero /etc/hosts de nuestro Linux local. Tener en cuenta que las instancias creadas en AWS tienen un usuario por defecto “ec2-user” sin permisos de root, pero con “sudo” podemos resolver este inconveniente. Los nombres deberán seguir la nomenclatura que se muestra a continuación:

  • Los siguientes puntos habrá que repetirlos para cada nodo hadoop: nos logamos en el nodo con ssh. Respondemos con “yes” para agregar el host en la lista de conocidos y que no nos vuelva a preguntar:

    Configuramos el fichero de hosts de la misma forma que en nuestro Linux local. Podemos editarlo manualmente (siempre como root) o bien copiarlo desde nuestro Linux local mediante:

    Cambiamos el nombre del host para que coincida con el configurado en el fichero de hosts:

    Este cambio lo podemos hacer permanente editando la propiedad HOSTNAME en el fichero:

    Durante la instalación de Ambari, necesitamos tener abiertos ciertos puertos por lo que desactivaremos las tablas IP:

    En la versión Red Hat que nos proporciona AWS el servicio ntpd está por defecto caído. Lo levantamos con:

Instalación del entorno Ambari.

A continuación podemos ya instalar el paquete Ambari (última versión 1.7.0) en uno de los nodos (o instancia siguiendo la nomenclatura Amazon). Para ello:

  1. Nos logamos en el nodo que hará de servidor Ambari con ssh. Respondemos con “yes” para agregar el host en la lista de conocidos y que no nos vuelva a preguntar:

    Configuramos de la misma forma el fichero de hosts. Podemos editarlo manualmente (siempre como root) o bien copiarlo desde nuestro Linux local mediante:

    Cambiamos el nombre del host para que coincida con el configurado en el fichero de hosts:

    Hacerlo permanente editando la propiedad HOSTNAME en el fichero:

    Generamos una clave pública sin password:
  2. Ya estamos listos para instalar el paquete Ambari. Para ello nos descargamos el software de HortonWorks mediante HTTP (también podemos usar RPM). Da lo mismo. Aseguraros que la versión es la centos6:

    El fichero “ambari.repo” que se ha descargado con la descripción de los paquetes se copia posteriormente a:

    …para que yum tome los cambios. A continuación instalamos los paquetes y dependencias. Aceptar todas las opciones con el valor por defecto (copio sólo algunas trazas):

    Si tenéis problemas de dependencias (puede que con python o postgresql) es porque las versiones (de SO, de paquete, etc.) que estáis usando no son las correctas. Revisarlo bien.
    Hacemos que Ambari se autoconfigure (aceptamos todos los valores por defecto):

    Iniciamos el servidor:

    Comprobamos que está corriendo con:

    Este proceso se levantará cada vez que arranquemos la instancia por lo que nos olvidamos de él. Ya podemos entrar en la ventana de configuración desde cualquier navegador en: http://****:8080/#/login (usuario y pass: admin/admin luego se podrá cambiar), donde en lugar de los asteriscos tendrás que indicar la IP del nodo Ambari. Si en la política de grupos de seguridad de la instancia has puesto “Source=Anywere”, podrás acceder también desde Windows.

  3. Una vez en este paso configurar Ambari es sencillo siguiendo el asistente web que se nos proporciona desde el navegador. Antes de seguir, aseguraros de tener todas las instancias EC2 levantadas.
    Proporcionamos un nombre para el cluster (cualquiera vale):

    Seleccionamos la versión de Hadoop a usar. Recomiendo por sencillez la 1.3.3, aunque la 2.0.6 exige menos requisitos hardware:

    También ayudamos a Ambari indicando el tipo de distribución Linux que tenemos instalada (así las cosas irán más rápidas):

    Indicamos la lista de nodos que formarán nuestro cluster (sin incluir el nodo donde corre Ambari). El formato del nombre debe ser el mostrado en la imagen (xxx.hdp.hadoop):

    Cargamos el fichero .pem con la clave e indicamos la cuenta con permisos de root:

    A continuación se procederá a registrar cada nodo automáticamente:

    Si habéis tenido que repetir el proceso más de una vez puede que no tengáis limpios los nodos de instalaciones anterioes por lo que os saldrán warnings:

    Lanzando este comando en los nodos con warnings y dando a “Rerun Checks” se soluciona el problema:

    Seleccionamos los servicios a instalar. Como mínimo: HDFS + YARN (o MapReduce1 según la versión que elijáis). El servicio ZooKeeper no es necesario instalarlo en la versión 1.3.3 pero sí los servicios de monitorización Nagios y Ganglia. En MapReduce2 (YARN) sólo Zookeeper es obligatorio instalarlo.

    No os preocupéis por estas combinaciones, ya que Ambari nos alertará sugiriendo las opciones más adecuadas según el caso:

    Distribuimos los servicios maestros en los distintos nodos que disponemos. Los servicios Namenode y SNameNode deben ir en el mismo nodo, si no tendréis muchos problemas. Para el resto de servicios se aconseja tener 1 servicio por nodo para no saturar el mismo nodo:

    Distribuimos los nodos esclavos en el cluster. Realmente con 1 esclavo de cada tipo es suficiente para comenzar. Posteriormente se pueden agregar más esclavos. Recomiendo no abusar de las pretensiones de nuestro cluster, ya que las instancias EC2 están bastante limitadas en recursos hardware.

    Asignar usuario y clave para los servicios Nagios, Hive y Ozzie (si procede):

    Pulsar en “Deploy”:

    Este paso llevará un tiempo y es el más crítico y delicado de todos. Básicamente lo que hace ahora Ambari es lanzar un conjunto de scripts Python en cada máquina para configurar los servicios maestro/esclavo. Como véis no hay magia, ya que es todo un poco rudimentario.
    Esta fase comprende 2 etapas en cascada: la instalación de los servicios y el inicio de los mismos. Si falla la primera en cualquier nodo, no se continuará con la segunda etapa. Si durante el inicio de los servicios falla algún maestro, no arrancarán los esclavos de los que depende (como es lógico). El maestro más importante es el NameNode:

    En caso de fallo puedes ver el error por la misma interfaz de Ambari, o mejor yendo a cada directorio de logs del nodo que ha fallado que son:

    Si falla el repositorio de paquetes verás el siguiente error:

    …tendrás que limpiar el repositorio tal y como se indica abajo y pulsar en “Retry”:

    Si al arrancar el NameNode ves en el log este error (puede darse dependiendo de la distribución de maestros elegida):

    …tienes que cambiar la IP pública del nodo indicado en el error, en el fichero /etc/hosts para que usar la IP privada (Private IPs del EC2).

    Si estás en un callejón sin salida y quieres volver a empezar la instalación Ambari desde cero, lanza estos comandos que borran toda la configuración en el servidor Ambari:

    Si todo ha ido bien verás que los servicios se han arrancado correctamente. Realmente el servicio más importante para Ambari es el NameNode ya que controla el HDFS, y permite que el proceso de configuración pueda continuar sin el resto de servicios (claro está, aparecerán warnings en Ambari y además no podrás lanzar trabajos):

    Finalmente este será el aspecto de la página principal de administración de Ambari. El trabajo de despliegue ha terminado.

    Desde esta pantalla podemos realizar tareas adicionales de monitorizarión/administración como por ejemplo:

    • Agregar/eliminar servicios esclavos (tasktracker, datanode, etc.).
    • Iniciar/Detener servicios del cluster.
    • Agregar/eliminar/mover nodos al cluster.
    • Crear alarmas/informes personalizados (uso de disco,memoria,red por nodo,job,tarea, etc.).
    • Acceder al sistema HDFS.
    • Monitorizar los trabajos de cada usuario en el cluster.
    • Acceder a Ganglia-Mobile vía smartphone.

    Para poder acceder al servidor de archivos HDFS vía web (Namenode) y ver el contenido sin este error:

    …tendrás que dar permisos en HDFS al usuario “gopher” del servidor web:

Conclusiones.

Ambari puede ayudar a controlar clusters que cambian continuamente o que deben ser manejamos por equipos sin formación técnica específica. Encuentro interesante el módulo de definición de informes y alertas. También la posibilidad de mover un servicio de nodo lo encuentro útil (aunque no está del todo automatizado).

Como puntos débiles he encontrado el proceso de instalación y despliegue bastante frágil, y requiere conocimientos adicionales para poder salir del problema. También la interfaz presenta algunos fallos relacionados con el estado real de cada servicio así como los warnings mostrados. La documentación oficial publicada en la web de HortonWorks está limitada y algunos de los problemas que la comunidad de usuarios publican en el foro de soporte (http://hortonworks.com/community/forums ) siguen sin solución.

Puedes encontrar más información en:

Si te ha gustado este tutorial y quieres seguir aprendiendo sobre Hadoop puedes enviarme sugerencias del siguiente tutorial a mi correo. Gracias.

Saludos.

1 Comentario

  1. Muy bueno el tutorial pero no me queda claro a que red te refieres cuando definimos las reglas para SSH y HTTP. que significa exactamente «nuestra red» (Source=Custom IP):

    Saludos

Dejar respuesta

Please enter your comment!
Please enter your name here