Usando yarn y slider para levantar procesos en un cluster de hortonworks

Siguiendo con las pruebas y las arquitecturas relacionados con bigdata vamos a inspeccionar las capacidades de yarn para levantar procesos en un cluster HDP. Lo primero que habría que introducir es el producto yarn. De la página siguiente de hortonworks podemos obtener la siguiente definición

YARN is the prerequisite for Enterprise Hadoop, providing resource management and a central platform to deliver consistent operations, security, and data governance tools across Hadoop clusters.
YARN also extends the power of Hadoop to incumbent and new technologies found within the data center so that they can take advantage of cost effective, linear-scale storage and processing. It provides ISVs and developers a consistent framework for writing data access applications that run IN Hadoop.

Por tanto como podemos ver yarn es una suerte de sistema operativo para interactuar con hadoop y que éste (yarn) gestione los recursos del cluster de hadoop/hortonworks.

Sobre Yarn existen varios APIs que podemos usar para desplegar nuestros propios procesos.

• YARN (API de más bajo nivel sobre el que se montan, TEZ y SLIDER)
• TEZ (API para simplificar el desarrollo de aplicaciones que se pueden ejecutar sobre YARN, se puede ver como un API para ejecutar procesos, por ejemplo scripts de PIG, HIVE etc...)
• SLIDER (API que simplifica el desarrollo de aplicaciones que se pueden ejecutar sobre YARN, a diferencia de TEZ slider está diseñado para es levantar servicios, como explican el la página de howtonworks, Slider is a framework for deployment and management of these long-running data access applications in Hadoop)

Una vez presentados los tres "sabores" principales vamos con el caso de uso que estamos probando. En este caso lo que vamos a crear es bot para slack que va a leer los mensajes de un canal y va a contestar a los mensajes de dicho canal. La idea es que una vez que tengamos esa aplicación java desarrollada la levantemos sobre el cluster de hdp/yarn usando slider.

La arquitectura general de la solución es la siguiente

Donde podemos ver que los eventos producidos en un canal de slack son consumidos por el bot que se ha levantado en un cluster de hadoop usando slider. Para desarrollar esta prueba de concepto los requisitos son

• Disponer de un cluster hadoop/hortonworks con los servicios de yarn levantados y con el cliente de slider instalado
• Disponer de un paquete slider para poder desplegar

El primer requisito se ha tratado en otros posts en este blog. El segundo requisito es la parte en la que nos hemos centrado para crear esta entrada. Un paquete slider se compone (a grandes rasgos) de los elementos que vemos en la siguiente imagen

Donde lo principal son los ficheros de configuración, los scripts de arranque, y los binarios que se ejecutan. Los binarios son la parte que en este caso hemos desarrollado en java. Los archivos de configuración nos permiten definir las siguientes características:

• classloader de la aplicación
• version de java que se quiere usar
• memoria reservada para el proceso
• nombre del paquete/servicio
• parámetros extra que se pasan al proceso (pueden ser parámetros gestionados por el que despliega el proceso o por el propio nodo donde se levanta el proceso)
• threshold que nos permite definir los límites que hacen que un proceso que se ha detenido se vuelva a levantar automáticamente. Por ejemplo si se ha producido un error de comunicación y el proceso se muere según definamos los límites el proceos se volverá a levantar de manera automática.
• numero mínimo y máximo de procesos que se deben levantar
• ... y un montón más de características que podemos ver en el site del proyecto

Una vez que tenemos el paquete creado podríamos desplegarlo usando los siguientes comandos de slider

• slider  package --install --replacepkg  --name MOMO_BOT --package /home/hadoop/jenkins/jobs/slack_bot/slack_bot-0.0.1-SNAPSHOT-slider-package.zip
• slider stop momo_bot
• slider  destroy momo_bot
• slider  create momo_bot --template /home/hadoop/jenkins/jobs/slack_bot/appConfig-default.json --resources /home/hadoop/jenkins/jobs/slack_bot/resources-default.json

Una vez ejecutada esta secuencia podremos ver nuestro proceso desde la vista slider de nuestro ambari.

Para la generación del paquete hemos usando maven y para el despliegue automatizado jenkins. El objetivo de esta prueba era analizar las características de slider como modelo de despliegue de aplicaciones. El hecho de desplegar una aplicación usando este modelo dota al servicio de las siguientes características

• auto-escalado
• monitorización y re-arranque de containers en base de los parámetros definidos en la configuración del paquete slider
• gestión de los recursos asociados al servicio usando del modelo de containers de yarn
• registro automático del servicio etc..

En esta página se puede ver todo lo que slider puede hacer (https://slider.incubator.apache.org/docs/manpage.html). Lo más destacable a nuestro modo de ver sería

• A user can create an application instance.
• Users can flex an application instance: adding or removing components dynamically. If the application instance is live, the changes will have immediate effect. If not, the changes will be picked up when the instance is next started.

Y como última conclusión ... slider es mucho más que de lo que se ha explicado en este post... parafraseando a pedro salinas ... Eso no es nada aún. Buscaos bien, hay más.