lunes, 17 de febrero de 2014

AWS: Building blocks

AWS es principalmente conocido por sus máquinas virtuales, servicio formalmente conocido como EC2 (Elastic Cloud Computing). Pero AWS ofrece mucho mas. El set de servicios es extenso y crece cada día. En una serie de entradas en este blog me gustaría enseñar algunos de ellos partiendo de los mas simples y comunes hasta los mas complejos. El objetivo es obtener una visión general de lo que AWS puede ofrecernos desde una aproximación práctica y amena.

Pero dejemos de hablar y pongámonos manos a la obra. Primero necesitaremos establecer un entorno adecuado donde desplegar nuestra arquitectura. Partamos de un diseño de arquitectura tradicional con dos redes diferenciadas: una de frontend donde desplegaremos los servicios de cara al publico y otra de backend donde instalaremos los servicios de bases de datos. Esquemáticamente:

Diagrama general

Los elementos principales que deberemos definir son:

  • VPC (Virtual Private Cloud): Es el espacio reservado para nosotros donde desplegaremos toda la infraestructura. Piensa en ello como un trozo de AWS donde podrás definir todo lo que necesiten tus servicios. Usaremos para nuestra VPC un rango 10.0.0.0/16 que nos dará un amplio margen de direccionamiento.
  • Internet Gateway: Será nuestra punto de conexión entre la VPC e Internet
  • Public subnet: La subred pública. Con un rango de 10.0.0.0/24 pondremos dentro de esta subred todas las máquinas que ofrecerán servicio de cara al público (frontend)
  • Private subnet: La red privada. En esta subred contendrá todas las máquinas con información privada. Su acceso estará mas limitado y generalmente se utilizan para contener la información (backend)
  • NAT Instance: Las máquinas de backend por seguridad no deben conectarse directamente a Internet. Pero generalmente necesitarán hacer conexiones al exterior, por ejemplo para actualizar paquetes. La instancia de NAT nos permitirá poder hacer estas comunicaciones desde el backend de forma mas segura. 
  • Web Server: El servidor web que ofrecerá los servicios a nuestros clientes. 
  • DB Server: El servidor de base de datos que contendrá la información que use nuestro aplicativo.
Veamos cómo podemos crear y configurar este entorno de forma rápida y sencilla en AWS.

NOTA: Crear recursos en tu cuenta AWS puede tener asociado costes. Si no estas seguro consulta la tabla de precios para cada servicio antes de iniciar cualquier cambio que pueda derivar en un sobrecoste mensual inesperado.


Creación de la red y subredes

Creación de la VPC

Entramos en la consola AWS y seleccionamos el servicio VPC. En 'Your VPCs' nos aparecerán todas las VPC que tenemos creada para la región actual. Pulsamos el botón 'Create VPC' e introducimos los datos:


Una vez pulsado el botón 'Yes, Create' nos aparecerá nuestra nueva VPC dentro de la lista de VPCs disponibles:



Ahora nos vamos al apartado 'Subnets' y pulsamos el botón 'Create Subnet'. Deberemos repetir el proceso dos veces, una por cada subred que queremos crear:




Una vez hecho, nos deberán aparecer las dos nuevas subredes en la lista de subredes disponibles para la región:



Por último en el apartado de redes deberemos crear un Internet Gateway. Para hacerlo, nos vamos al apartado 'Internet Gateways' y pulsamos el botón 'Create Internet Gateway'. Ahora, pulsando botón derecho del ratón sobre el Internet Gateway que acabamos de crear, seleccionamos 'Attach to VPC' para asociarlo a nuestra VPC 10.0.0.0/16:


Una vez hecho, en la lista aparecerá asociado el Internet Gateway a la VPC:




Instancia NAT

NAT son las siglas de Network Address Translation y es un mecanismo usado por los routers para encaminar paquetes entre diferentes redes. Si recordais, tenemos dos subredes diferentes: una con los servidores de producción o frontend y otra con los servidores que contienen la información o backend. Por seguridad crearemos una instancia de NAT que colocaremos en la subred de frontend con dos funciones principales:
  1. Punto único de entrada para la administración: Habilitaremos reglas para poder acceder a esta instancia a tréves del puerto SSH (22/TCP) con el objetivo de administrar el entorno. Crear un único punto de entrada nos securizará el entorno y nos permitirá mas fácilmente controlar el acceso. En el resto de instancias nos ocuparemos de securizarlas para permitir solo accesos de administración desde la instancia de NAT y abrir los puertos de servicio requerido para clientes o internos, según el caso.
  2. Puente de comunicación para la red de backend: No es seguro que la red de backend se comunique directamente con Internet, pero puede que sea necesario para algunas labores como la actualización de paquetes por ejemplo. Para restringir este tráfico configuraremos para que el tráfico de las instancias de esta subred sea enrutado por la instancia de NAT.
Lo primero que necesitaremos será crear esta instancia de NAT. Amazon ya provee de una AMI enfocada a este propósito. En nuestra consola AWS iremos al servicio EC2 --> Instances y pulsaremos el botón 'Launch Instance'. En '1. Choose AMI' iremos a 'Community AMIs', marcaremos la casilla 'Amazon Linux' del apartado 'Operating System' y en el campo de búsqueda escribiremos 'NAT':




Seleccionaremos la AMI de fecha mas reciente. En '2. Choose Instance Type' elegiremos una t1.micro ya que el propósito de este artículo es demostrativo. Para un entorno productivo real deberíamos elegir un tipo de instancia adecuado al throughput de red que necesitemos.


Seguimos. En '3. Configure Instance' en los apartados 'Network' y 'Subnet' seleccionaremos la VPC 10.0.0.0/16 y la subred 10.0.0.0/24. De esta forma enmarcamos la instancia dentro de la subred de frontend:


Next, en '4. Add Storage' lo dejaremos por defecto. Esta instancia no necesita de almacenamiento adicional. Con el volumen raíz será suficiente. Siguiente, en '5. Tag Instance' como nombre le asignaremos el valor 'NAT instance'. De esta forma reconoceremos facilmente la instancia posteriormente. En '6. Configure Security Group' configuraremos un nuevo grupo de seguridad llamado 'NAT-Security-Group' y, por ahora, permitiremos el acceso SSH desde cualquier origen. Esto es inseguro y es altamente recomendable modificarlo para restringir el conjunto de IPs que puedan acceder a este puerto. Pero por ahora, y para facilitar la configuración, lo dejaremos así:


En el último apartado, '7. Review', revisaremos las opciones elegidas y si estamos conforme pulsaremos el botón 'Launch' para crear la nueva instancia:


Después de unos segundos nuestra nueva instancia NAT aparecerá disponible en la lista de instancias en ejecución para la región seleccionada.

Dado que nuestra instancia NAT necesitará comunicarse con Internet necesitará disponer de una IP pública. Para conseguirlo haremos uso de las EIP, Elastic IP. En la consola AWS iremos al servicio VPC, apartado 'Elastic IPs' y pulsaremos al botón 'Allocate New Address'. Una vez creada la IP pública pulsando sobre ella con el botón derecho del razón seleccionamos 'Associate' y la asociaremos a la instancia de NAT:



Con esto, ya tenemos una IP pública asociada a la instancia de NAT. En la consola AWS, vamos a EC2 --> Instances. En el apartado 'Security Groups' seleccionaremos el grupo de seguridad de nuestra instancia NAT y añadiremos una regla de entrada (Inbound) para permitir todo el tráfico desde la red VPC (10.0.0.0/16):


Esto permitirá a las máquinas de nuestra VPC comunicarse a través de la instancia de NAT. Podremos restringir esto mas adelante (de hecho es lo recomendable para aumentar la seguridad), pero por ahora lo dejaremos así. Solo resta deshabitar el chequeo de ip origen y destino en la instancia. Volvemos a EC2 --> Instances , botón derecho sobre la instancia NAT y seleccionamos 'Change Source/Dest. Check' para poner el valor a 'False':


Por defecto las instancias AWS tienen este chequeo activo por motivos de seguridad, denegando cualquier paquete en el que no aparezca la IP de la instancia como origen o destino. Pero dado que la instancia NAT va a realizar trabajo de enrutado de paquetes para otras instancias, si tiene activa esta comprobación no podrá enrutar el tráfico correctamente. Nuestra instancia NAT está lista para su uso:




Tablas de enrutado

Para nuestro entorno necesitaremos definir dos tablas de enrutado:
  • Main route table: O tabla de enrutado principal. Es la tabla de rutas por defecto que se genera cuando creamos nuestra VPC. Debemos definir esta tabla para que envie directamente por la interfaz el trafico local (10.0.0.0/16) y el resto de tráfico lo encamine hacia la instancia de NAT. Asociaremos esta tabla de enrutado a la subred de backend.
  • Custom route table: O tabla de enrutado personalizada. Será una nueva tabla de rutas que crearemos. Al igual que la anterior, el tráfico local se enviará directamente por la interfaz y el resto de tráfico se enviará al Internet Gateway que creamos al principio. Asociaremos esta tabla de enrutado a la subred de frontend.
Vemos el proceso de creación en la consola AWS. Iremos a servicios VPC --> Route Tables. Para nuestro ejemplo la tabla de rutas rtb-a8011eca es la principal asociada a la VPC 10.0.0.0/16. En la pestaña 'Routes' añadiremos la ruta por defecto (0.0.0.0/0) y como objetivo (Tarjet) seleccionaremos la instancia de NAT:


A continuación en la pestaña 'Associations' asociaremos la subred de backend (10.0.1.0/24) a la tabla de rutas principal:



Ahora añadiremos la tabla de enrutado personalizada pulsando el botón 'Create Route Table' y seleccionado nuestra VPC 10.0.0.0/16. Seleccionamos la nueva tabla de rutas y en la pestaña 'Routes' añadimos la ruta por defecto (0.0.0.0/16) hacia nuestro Internet Gateway creado en un apartado anterior:


De forma similar a lo realizado anteriormente, en la pestaña 'Associations' de la tabla de rutas asociaremos la subred de frontend (10.0.0.0/24):


Instancias de servicio

En este apartado voy a ser bastante mas escueto. Cread dos instancias t1.micro, usando como referencia los pasos seguidos para la instancia NAT. Una la llamaremos 'DB Server' y a la otra 'Web Server'. Como AMI recomiendo usar la estándar de Amazon para 64bits y como únicas recomendaciones afinad los security groups para permitir tráfico solo en los puertos y para las redes necesarias:

  • DB Server:

  • Web Server:


El servidor de base de datos, al estar en red de backend, no necesitará IP para comunicarse con Internet. Pero sí el servidor Web. Por lo que habrá que crear una EIP que asociar a la instancia 'Web Server'. Una vez concluido el proceso, deberemos tener tres instancias:



Para un testeo rápido que todo funciona:
  • Entrar en la instancia de NAT (debes adaptar el comando al uso de tu clave privada y EIP para la instancia de NAT): $ ssh -i TU_CLAVE_PRIVADA.pem ec2-user@TU_EIP
  • Actualizar paquetes (altamente recomendable por motivos de seguridad): $ sudo yum update;sudo yum upgrade
  • Desde la instancia de NAT acceder usando SSH a las instancias de base de datos y web. Para conocer las IP privadas de cada instancia usa la información que se muestra en la consola AWS. Actualizar los paquetes en cada instancia ($ sudo yum update;sudo yum upgrade) e instala MySQL y Apache respectivamente:
  • DB Server:
  • $ sudo yum install mysql-server
  • $ sudo chkconfig mysqld on
  • $ sudo service mysqld start

  • Web Server:
  • $ sudo yum install httpd
  • $ sudo chkconfig httpd on
  • $ sudo service httpd start

Si se ha configurado correctamente el entorno deberíamos poder ver la pagina web de ejemplo de nuestra instancia 'Web Server' desde cualquier navegador indicando su EIP asociada:


Lo dejaremos en este punto. En entregas posteriores aumentaremos la seguridad, incluiremos nuevos servicios y evolucionaremos nuestro entorno para hacer uso de algunas de las características mas interesantes y novedosas de AWS. 

Como podéis comprobar, definir y desplegar nuestra infraestructura de servicios en Amazon Web Services es fácil y rápido. Nos permite crear desde simples instancias virtuales para pocos servicios hasta complejas infraestructuras con alta disponibilidad, VPN y servicios de alta demanda con baja latencia a nivel global.


sábado, 11 de enero de 2014

Primera semana en Dublín

A punto de concluir mi primera semana en Dublin quiero compartir mis primeras experiencias y esos contrastes que siempre encuentras cuando vas a un lugar con costumbres diferentes a las de tu lugar de origen.

Llegar en Enero no es la mejor época para disfrutar de Dublín. Los días son muy cortos y el tiempo no acompaña. Aunque como me dijo mi responsable el primer día: si no te gusta el clima de Dublín espérate diez minutos. Y es cierto, el tiempo a lo largo del día puede cambiar mucho. De ofrecerte un cielo despejado a cerrarse, llover, hacer viento y volver a despejarse. Es así creedme, he podido experimentarlo. Sobre el frío no hace tanto como podría esperarse por la latitud a la que se encuentra. Por lo visto una corriente cálida que baña las costas es la responsable de que no haga tanto frío como podría esperarse. Ahora mismo estamos rondando los 5º, dos grados arriba, dos grados abajo (según la hora del día/noche). Nada que no pueda llevarse perfectamente con una buena ropa de abrigo. Eso sí: raro es el día que no llueve. Pero aunque suele hacerlo con frecuencia, no suele durar mucho y también suele ser de baja intensidad. Vamos, que es mas molesto que otra cosa porque calar no llega a calar. Este será el principal motivo por la que ves a poca gente por la calle con paraguas. Generalmente si cae algo se ponen un gorro o la capucha del abrigo. Me han comentado que la cosa en verano gana bastante con días larguísimos (anocheciendo a las 11 de la noche) y unas temperaturas agradables que rondan los 20º. Tiene buena pinta, desde luego no echaré de menos 'la caloh' de Sevilla en verano aunque aun me queda para disfrutar de ello. Paciencia.

La ciudad es bonita arquitectónicamente hablando, de estilo bastante 'british', y darse un paseo merece la pena. Pero desde el punto de vista funcional es un caos. Se ve que el responsable de urbanismo debe llevar unos 400 años de vacaciones y los irlandeses se han dedicado en ese tiempo a lanzar calles como a cada uno le ha parecido. El resultado es una ciudad que resulta complicada para el tráfico rodado. Esto hace que con pocos coches se formen monumentales atascos y que para recocer distancias relativamente cortas se emplee mas tiempo del necesario. Los servicios de transporte público son escasos y poco eficientes. Algunas lineas de bus, como la 69 que intenté coger el miércoles pasado, de 1 hora de 'frecuencia'. Están los LUAS, que son tranvías de superficie, pero solo hay dos lineas y no es que cubran suficiente superficie. Si te vas a vivir al campo (zonas fuera de la M50, la ronda de circunvalación de Dublín) esta el DART, un tren que aun no he usado pero que por lo que me cuentan ofrece conexiones interesantes a lugares bonitos que visitar. Muchos de los irlandeses se mueven en bicicleta. La ciudad es bastante plana, como Sevilla, y eso facilita su uso. Ademas, los conductores son bastante respetuosos con ellos. Pero en esta organización de los desplazamientos se han olvidado de los peatones. Los semáforos para ellos tienen, como los de los vehículos, tres estados: rojo, amarillo y verde. Verde es el estado al que se llega después de pulsar el botón de 'quiero cruzar' y esperar. Esperar mucho. Además el semáforo en este estado dura un nanosegundo. Luego cambia a amarillo que es en plan 'date prisa que voy a cortar' y por último rojo: su estado natural. Imagino que esta organización viene derivada del caos urbanístico que comentaba antes y en un afán de facilitar la circulación rodada se han olvidado de los peatones. De ahí que el deporte de riesgo favorito del irlandés (y los que vivimos por aquí) sea saltarse los semáforos de peatones. Una actividad de lo mas estimulante si añadimos al riesgo propio de hacerlo que la circulación aquí, al igual que en UK, es por la izquierda. Es sorprendente lo bien aprendido que se tiene nuestro cerebro cómo se mueve el tráfico. Solo que aquí, si tu cerebro está acostumbrado como el mío a que los coches vengan por la derecha, te la juega constantemente. En bastantes calles, sobre todo céntricas, te ayudan a no meter la pata pintando en el suelo 'look left' o 'look right'. Si no aparece pintado mi consejo es que, ante la duda, mirad a ambos lados antes de saltaros el semáforo (porque sabeis que os lo vais a saltar).

Tengo mas peculiaridades que comentar, pero bueno hay que dejar algo para otro día, ¿no?

 DART (que acaba de salir de la parada junto al edificio de Google Docks) pasando por el puente en Sandwith Street Upper

jueves, 23 de mayo de 2013

WordCount: testing Hadoop

En la anterior entrada hablé de Ambari, la plataforma para el control de clusters Hadoop y servicios asociados. Hoy vamos a poner a prueba el funcionamiento de cluster. Para ello lanzaremos nuestro primer programa paralelo. Para lo ocasión usaremos uno de ejemplo de los que podréis encontrar en la Wiki de Hadoop y cuya función es contar las palabras que aparecen en uno (o varios) archivos de texto.

Antes de ello, repasemos algunos conceptos asociados a Hadoop. Como ya vimos anteriormente, su objetivo es proveer un entorno para el trabajo paralelo bajo el paradigma MapReduce, trabajos que se distribuyen para su procesamiento en un cluster. HDFS es el sistema de ficheros en dicho cluster que soporta esta operativa. Este sistema de ficheros permite, usando el disco local de cada máquina, generar un espacio unificado que desde el punto de vista lógico se comporta y gestiona como si de un solo disco se tratase. En realidad por debajo HDFS lo que hace es replicar la información en los diferentes nodos del cluster asegurando en todo momento la coherencia de datos y la tolerancia a fallos por caídas puntuales de nodos.

Lo primero que necesitaremos en un fichero de entrada con palabras que contar. Como es un test tampoco importa mucho cómo sea ese fichero. Por ejemplo, he generado uno de nombre input1.txt concatenando varios ficheros de logs del sistema. El fichero ocupa 542MB y tiene mas de 6 millones de líneas:


Como puede verse en la imagen anterior, primero deberemos copiar el fichero al espacio de disco HDFS del cluster. Eso se consigue haciendo uso de los comandos Hadoop asociados al tratamiento del almacenamiento (dfs), en concreto tendremos que crear un nuevo directorio que contenga el fichero de entrada y copiarlo en dicha localización dentro del espacio HDFS.

Pero antes de lanzar nuestro programa tendremos que crearlo. Hadoop está desarrollado con tecnología Java por lo que ofrece todo un conjunto completo de librerías bajo este lenguaje para desarrollar los aplicativos paralelos. En nuestro caso el código que especifica cómo debe ser tratada la entrada, wordcount, debe definir las acciones tanto para el mapeo (Map) como la reducción (Reduce). Siguiendo el ejemplo de la wiki comentado anteriormente, el código quedaría de la siguiente forma:

Es bastante intuitivo interpretar lo definido anteriormente. Se puede apreciar que están definidas claramente tres secciones:
  1. La función Map: en la que a cada palabra se le asigna el valor 1 (one)
  2. La función Reduce: en la que se agrega dicho valor por cada palabra mapeada
  3. La función main: principal, que es la que controla la creación de la tarea (Job), establece los parámetros iniciales de lanzamiento y controla su estado.
Definido el fichero de entrada y el programa paralelo solo resta ejecutarlo en nuestro cluster:

Como acabamos de comprobar, nuestro job paralelo se ha ejecutado en el cluster Hadoop satisfactoriamente, obteniendo una respuesta a nuestra necesidad: contar el numero de veces que cada palabra aparecía en el fichero de entrada. Pero recordemos que disponemos de la plataforma Ambari, nuestro controlador del cluster Hadoop. Si revisamos en su interfaz web podremos ver detalles interesantes como, por ejemplo, la información asociada al job:


De forma rápida tenemos acceso a información detallada sobre el trabajo en ejecución. Y si pulsamos sobre el job en concreto obtendremos un detalle aun mayor de cómo y cuando se han ido ejecutando las diferentes fases del trabajo:


Visualmente obtenemos información tan interesante como:
  • El estado de ejecución: exitoso (SUCCESS) o erróneo (FAILED)
  • La duración total del trabajo, casi 212 segundos
  • 5 de los 6 nodos disponibles han estado implicados en el trabajo
  • Detalles sobre el estado de ejecución de la tarea en el tiempo, como cuantos nodos han participado en las diferentes fases Map y Reduce.
Si comparamos esta tarea con realizar el cálculo haciendo uso de un script tradicional (secuencial) observamos el siguiente resultado:


En este caso, la ejecución completa del trabajo ha tardado 4 minutos y 35 segundos, es decir, 275 segundos. Comparativamente se ha obtenido una reducción del 30% en tiempo de ejecución gracias al uso del cluster.

Y esto es solo un ejemplo. Con tareas mejor diseñadas las reducciones podrían ser mas significativas. Y no olvidemos que el cluster, y su filosofía de trabajo paralelizada, nos permiten abordar problemas de cálculo con volúmenes de entrada muy grandes. En este ejemplo hemos usando un fichero con unas 6 millones de lineas. Pero imaginad que tuviera, por ejemplo, 10 o 100 veces más. El problema seguiría siendo resoluble en nuestro cluster Hadoop y sin embargo, por limitaciones de memoria, una sola máquina de forma secuencial dificilmente podría abordarlo.

domingo, 19 de mayo de 2013

Ambari: Plataforma para el procesamiento paralelo

Hoy quiero hablar de Ambari, un proyecto bajo el auspicio de la Fundación Apache y que cuenta con el apoyo de la gente de Hortonworks. El objetivo de Ambari es proveer de un framework amigable para el uso de Hadoop y sus aplicaciones complementarias (HDFS, MapReduce, Hive, HCatalog, HBase, etc) en una solución integrada y facilmente escalable. Si tu pregunta es ¿qué es Hadoop?, pues Hadoop es una solución de software libre para el tratamiento de lo que ahora está tan de moda: el Bigdata.

Bigdata es (según la Wikipedia), en el sector de tecnologías de la información y la comunicación, una referencia a los sistemas que manipulan grandes conjuntos de datos. A grandes rasgos se trata de analizar ingentes cantidades de datos con el objetivo de obtener información relevante de ellos. Pero procesar grandes volúmenes de información no es una tarea fácil. Muchas veces el conjunto de datos a analizar es tan grande que excede las capacidades de espacio, en disco y memoria, de los sistemas convencionales y el tiempo que requeriría su análisis secuencial sería considerable. ¿Cómo resolver el problema? Divide y vencerás.

En 2004 los gurus de Google publicaron una documentación relativa al paradigma MapReduce el cual toma un problema complejo y lo divide en varios trozos procesables de forma paralela. Cada uno de estos trozos son enviados un servidor, o nodo del cluster, que trabaja con ellos en dos fases claramente diferenciadas:
  • Map: Fase de mapeo en la que se toma el conjunto de datos de entrada y se mapea esa entrada de una determinada forma
  • Reduce: Fase en la que se toman los valores mapeados previamente y se aplica un determinado procesamiento para reducirlos y obtener la información de interés
Tomando el ejemplo descrito en el documento de Google, imaginad que quereis contar el número de veces que aparecen las palabras en un determinado documento. Expresado en pseudo-código el ejemplo tendría mas o menos de la siguiente forma:


En la primera fase (Map) se mapearia cada palabra al valor 1. En la segunda fase (Reduce) por cada palabra se agregarán sucesivamente los valores a un contador. Como resultado tendremos el conteo requerido. Algunos pensareis --- ¡qué tontería! podría haberlo calculado facilmente con un pequeño script secuencial. De acuerdo, si el documento es pequeño es una opción valida para resolver el problema. Imaginad ahora que en lugar de un documento quieres contar las ocurrencias en un libro, o en la colección de libros de una gran biblioteca. El problema se complica y la solución no es alcanzable si no cambiamos el paradigma de programación y paralelizamos el problema. Eso es lo que hace Hadoop:


Hadoop, y el conjunto de programas anexos, nos ayudan a trabajar de forma paralela. Haciendo uso de HDFS, un sistema de ficheros distribuido que permite alojar grandes cantidades de datos bajo hardware económico. La idea es conseguir potencia a base de unir nodos, equipos de prestaciones normales y económicos. Si un nodo se estropea es facilmente reemplazable por otro. Si necesitamos mas potencia solo necesitaremos añadir nodos al cluster creciendo de forma prácticamente lineal las capacidades disponibles. Interesante, ¿no?

Pero Hadoop y sus aplicaciones anexas no son demasiado user friendly. Si a eso unimos que para el trabajo necesitaremos desplegar los aplicativos en multiples nodos, controlar su estado, etc, la tarea se vuelve mas y mas compleja. No nos olvidemos que nuestro objetivo es procesar la información para obtener datos relevantes no el cluster en si mismo (el cluster es solo la herramienta). Para eso está Ambari: simplifica el despliegue de estos aplicativos, monitoriza su estado y proporciona herramientas para controlar el correcto funcionamiento tanto del cluster como de los trabajos desplegados, todo desde un entorno web muy agradable.

Para instalar Ambari lo mejor es seguir la guía (versión 1.2.2 en el momento de realizar este artículo) que los desarrolladores proporcionan en su web. Yo voy a comentar cómo he desplegado mi cluster Hadoop de pruebas y haré foco de atención en puntos importantes que hay que tener en cuenta para montar correctamente el cluster. Empecemos.

Ambari se despliega sobre REHL5/6, CentOS 5/6 y SLES 11. Importante es que solo admite versión x86_64 (64bits) como sistema operativo. Hace unos meses quise desplegar Ambari sobre equipos antiguos (HP Proliant G3) y me llevé un chasco al verificar con los desarrolladores del producto que al ser plataforma de 32bits no podía hacerlo.  Como lo mio es una prueba de concepto lo he desplegado sobre máquinas virtuales alojadas en mi PC: procesador Intel i7-2600K 3.4GHz (4 cores con HyperThreading) y 16GB de RAM. Pero podría hacerse igualmente sobre máquinas físicas o incluso sobre plataformas en la nube como AWS de Amazon.

Como sistema operativo base para los nodos del cluster he usado CentOS 6.4 minimal. Mi consejo es que, useis la distro que useis (dentro de las permitidas) instaleis una version mínima para reducir los requisitos de paquetes instalados. No os preocupeis porque Ambari, cuando lo necesite, instalará los paquetes que sean necesarios. Configuré 6 nodos con las siguientes características:
  • master-node: El nodo maestro. Donde instalaré el servidor de Ambari y las aplicaciones principales. 4GB de RAM y 2 cores. 7GB para disco de sistema (/) y 20GB para disco de cluster (/cluster)
  • backup-node: El nodo secundario. Donde se instalarán las aplicaciones maestras secundarias. 4GB de RAM y 1 core. 5GB para disco de sistema (/) y 20GB para disco de cluster (/cluster)
  • node02: Nodo cliente. 2GB de RAM y 1 core. 5GB para disco de sistema (/) y 20GB para disco de cluster (/cluster)
  • node03: Nodo cliente. 2GB de RAM y 1 core. 5GB para disco de sistema (/) y 20GB para disco de cluster (/cluster)
  • node04: Nodo cliente. 2GB de RAM y 1 core. 5GB para disco de sistema (/) y 20GB para disco de cluster (/cluster)
  • node05: Nodo cliente. 2GB de RAM y 1 core. 5GB para disco de sistema (/) y 20GB para disco de cluster (/cluster)
Mi consejo es que instaleis primero un CentOS base, casi sin nada, y una vez listo, haciendo uso de la utilidad de clonación de MV de VMWare, crear el resto. El resultado final en la consola de VMWare es el siguiente:



Paso previo a instalar y MUY IMPORTANTE es que los nodos deben verse entre sí. Para ello la resolución de nombres debe funcionar correctamente. Si no tienes un DNS donde dar de alta a los nodos del cluster una solución eficaz es meter la resolución de nombres en cada fichero '/etc/hosts' y asegurar que el hostname de cada nodo corresponde exactamente con dicha resolución:


Si lo anterior no está puesto correctamente fallará la fase de detección de nodos del cluster. Bien, ya tenemos todo listo para empezar. Lanzamos desde la interfaz web de administración de Ambari la configuración del nuevo cluster: establecer nombre, incluir los nombres de los nodos que lo forman (los nombres añadidos en el fichero de hosts). Listo, ahora deberemos seleccionar los aplicativos que queremos desplegar en nuestro cluster Hadoop:


El único que es obligatorio es el sistema de ficheros de cluster HDFS. Mi recomendación es que los añadas todos (no ocupan demasiado espacio y siempre puedes detenerlos después si no vas a hacer uso de ellos). Una vez elegidos los servicios a incluir, deberemos distribuirlos entre los nodos del cluster:


Yo he distribuido los servicios mas o menos para que todos los principales estén en el nodo maestro y backup. Seguramente haya una mejor distribución pero como mi objetivo sobre todo es evaluarlo no me preocupé demasiado en cómo distribuirlos. Ambari si precisa que algún servicio esté en varios nodos ya se preocupa de que así sea. Una vez distribuidos, proseguimos con la instalación.

Esta parte es delicada ya que, según como hayamos distribuido los servicios, Ambari tendrá que instalar unos u otros paquetes en los diferentes nodos del cluster. ¿Cómo hace este trabajo? La forma de interactuar de Ambari con los nodos del cluster usa dos caminos: SSH (si has seguido la guía de instalación oficial habrás tenido que configurar para que nodo maestro pueda acceder mediante este protocolo de forma directa, sin tener que proporcionar password alguna) y ambari-agent. En todos los nodos que formen parte del cluster se instalará el cliente de Ambari (via SSH) y, una vez provisionado, este será el método de comunicación. El cliente no es mas que una customizada adaptación de puppet. El nodo maestro, haciendo uso de los manifiestos (manifest), traslada configuraciones de un nodo del cluster a otro asegurando la coherencia en todo momento.

Como decía, esta parte es delicada ya que puede requerir instalar muchos paquetes en los diferentes nodos. A mi me dio error y revisando los nodos me percaté que no es que hubiera fallado la instalación, es que en varios nodos aun se estaban instalando muchos paquetes habiéndose llegado a una situación de timeout por el trabajo que ello requiere. ambari-agent recibe el manifiesto desde el nodo maestro, empieza a instalar paquetes (que requieren hacer uso de Internet via yum en muchas ocasiones). Mi consejo es que mireis en cada nodo y aseguraos que no hay procesos pendientes. Es facil detectarlo mirando la lista de procesos. Vereis que ambari-agent está ejecutando procesos relacionados con la instalación de paquetes:


Cuando veáis que la actividad en los nodos ha cesado, pulsar el botón de reintento. Debe aparecer una ventana similar a esta mostrando el progreso de instalación de los servicios en los nodos:


Y finalmente, si todo va bien, llegaremos a un estado donde todos los servicios se han desplegado correctamente en los diferentes nodos del cluster:


Entramos ahora en la ventana de dashboard de Ambari:


Esta ventana nos muestra una imagen general de cómo se encuentra nuestro cluster: los servicios activos y gráficas de las principales métricas asociadas al estado de computación: carga, uso de CPU, memoria, etc. Si pulsamos sobre cualquier gráfica, nos abre una ventana que nos permite ver interactivamente el detalle de la misma:


Como puede apreciarse, se ofrecen formas simples, interactivas e intuitivas para conocer el estado de salud de nuestro cluster, monitorizando los diferentes servicios, y ofreciendo información precisa gracias a los agentes de control integrados en el cluster como Ganglia y Nagios. Todo ello de forma cómoda: si necesitas mas potencia basta con añadir nuevos nodos al cluster. Ambari gestionará la provisión automática para integrar los nuevos nodos dentro de los procesos de control y gestión del cluster:






En la pestaña de Jobs podremos revisar el estado de ejecución de los diferentes procesos lanzados en la plataforma:


Como hemos visto, Ambari puede facilitarnos la gestión de nuestro cluster Hadoop. Ahora que tenemos una plataforma adecuada para desplegar nuestros jobs paralelos es el momento de empezar a usarla para procesar esa información que nos ayude a obtener datos significativos y, en definitiva, nos permita tomar mejores decisiones para el desarrollo de nuestra empresa a futuro.

PD: Lectura recomendada: MapReduce Design Patterns (O'Reilly)