Monitorización en Hadoop

Hadoop es un sistema distribuido a gran escala de almacenamiento de datos y provee la infraestructura para el procesamiento distribuido utilizando grupos de hosts conectados en red. El Seguimiento y gestión de este tipo de sistemas distribuidos complejos es costosa.

1.1 Apache Ambari

http://incubator.apache.org/ambari/

Proyecto para facilitar la gestión de Hadoop. Para ello provee un interfaz gráfico intuitivo y fácil de usar.

1.1.1 Características de Ambari

· Provisión para clústeres Hadoop

Ambari proporciona un asistente paso a paso para la instalación de servicios de Hadoop a través de cualquier número de equipos e incluye una interfaz Web intuitiva que le permite fácilmente disposición, configurar y probar todos los servicios de Hadoop y componentes básicos.

· Administrar un clúster Hadoop

Ambari proporciona gestión central para iniciar, detener y volver a configurar los servicios de Hadoop en todo el clúster.

Los servicios se dividen en estas siete secciones:

1. Servicios de navegación

2. Resumen

3. Configuración para la actualización

4. Enlaces rápidos

5. Alertas y controles de estado

6. Gestión de cabeceras

7. Métricas

· Monitorizar el clúster Hadoop

Ofrece un panel de control para conocer el estado del clúster. Y tiene la posibilidad de definir alertas para los servicios de Hadoop.

Utiliza Ganglia (http://ganglia.sourceforge.net/) para la recolección métricas.

Se integra con Nagios para el sistema de alertas y de notificaciones

· Ambari también incluye herramientas de diagnóstico de trabajo para visualizar las interdependencias de los Jobs y ver cronogramas de tareas como una forma de solucionar los problemas de ejecución

.

· Expone un API de REST para poder utilizar su funcionalidad desde aplicaciones externas

1.1.2 Arquitectura

Ambari sirve como punto central de recogida de los datos de todo el clúster. Cada host tiene un Agente Ambari – ya sea instalado automáticamente por el asistente de instalación o manual – que permite que al servidor Ambari controlar cada host. Además, cada equipo tiene un proceso Ganglia Monitor (gmond), que recoge la información métrica que se pasa al conector de Ganglia, y luego en el servidor Ambari.

1.2 Cloudera Manager

http://www.cloudera.com/content/cloudera/en/products/cloudera-manager.html

1.2.1 Características

Es el producto de Cloudera para la administración de Hadoop y tiene dos versiones: una para Cloudera Standard y otra para Cloudera Entreprise.

Permite la gestión de los nodos desde una única consola y facilita su instalación y replicado. Desde allí se controlan los cambios en la configuración de todo el clúster, e incorpora un completo gama de herramientas de diagnóstico y presentación de informes para ayudar a optimizar el rendimiento y la utilización. Se integra con la herramientas de monitorización de red SNMP.

Cloudera Standard soporta el despliegue, la configuración, administración, supervisión, diagnóstico y la ampliación sencilla del clúster.

Cloudera Entreprise tiene capacidades adicionales para la integración, automatización de procesos y recuperación de caídas.

1.2.2 Arquitectura

1.3 mikoomi

https://code.google.com/p/mikoomi/

Mikoomi es un proyecto dedicado al desarrollo de plugins de monitorización para Zabbix . Entre otros existe uno para Apache Hadoop (https://code.google.com/p/mikoomi/wiki/05) y para HBase (https://code.google.com/p/mikoomi/wiki/06)

1.3.1 Plugin Apache Hadoop

Permite la monitorización del NameNode y del JobTracker de un cluster Hadoop.

Las métricas de monitorización para el NameNode son las siguientes:

  • Configured Cluster Storage
  • Configured Max. Heap Size (GB)
  • Hadoop Version
  • NameNode Process Heap Size (GB)
  • NameNode Start Time
  • Number of Dead Nodes
  • Number of Decommissioned Nodes
  • Number of Files and Directories in HDFS
  • Number of HDFS Blocks Used
  • Number of Live Nodes
  • Number of Under-Replicated Blocks
  • Ping Check
  • Storage Unit
  • Total % of Storage Available
  • Total % of Storage Used
  • Total Storage Available
  • Total Storage Used by DFS
  • Total Storage Used by non-DFS
  • Least (min) Node-level non-DFS Storage Used
  • Least (min) Node-level Storage Configured
  • Least (min) Node-level Storage Free
  • Least (min) Node-level Storage Free %
  • Least (min) Node-level Storage Used
  • Least (min) Node-level Storage Used %
  • Most (max) Node-level non-DFS Storage Used
  • Most (max) Node-level Storage Configured
  • Most (max) Node-level Storage Free
  • Most (max) Node-level Storage Free %
  • Most (max) Node-level Storage Used
  • Most (max) Node-level Storage Used %
  • Node-level Storage Unit of Measure
  • Node with Least (min) Node-level non-DFS Storage Used
  • Node with Least (min) Node-level Storage Configured
  • Node with Least (min) Node-level Storage Free
  • Node with Least (min) Node-level Storage Free %
  • Node with Least (min) Node-level Storage Used
  • Node with Least (min) Node-level Storage Used %
  • Node with Most (max) Node-level non-DFS Storage Used
  • Node with Most (max) Node-level Storage Configured
  • Node with Most (max) Node-level Storage Free
  • Node with Most (max) Node-level Storage Free %
  • Node with Most (max) Node-level Storage Used
  • Node with Most (max) Node-level Storage Used %

Las métricas de monitorización para el JobTracker son las siguientes:

  • Average Task Capacity Per Node
  • Hadoop Version
  • JobTracker Start Time
  • JobTracker State
  • Map Task Capacity
  • Number of Blacklisted Nodes
  • Number of Excluded Nodes
  • Number of Jobs Completed
  • Number of Jobs Failed
  • Number of Jobs Retired
  • Number of Jobs Running
  • Number of Jobs Submitted
  • Number of Map Tasks Running
  • Number of Nodes in Hadoop Cluster
  • Number of Reduce Tasks Running
  • Occupied Map Slots
  • Occupied Reduce Slots
  • Reduce Task Capacity
  • Reserved Map Slots
  • Reserved Reduce Slots

Los posibles triggers a configurar para el NameNode son:

  • Less than 20% free space available on the cluster
  • NameNode was restarted
  • No monitoring data received for the last 10 minutes
  • One or more nodes have become alive or restarted
  • One or more nodes have become dead
  • One or more nodes have been added to the decommissioned list
  • One or more nodes have been removed from the decommissioned list
  • The number of live nodes has been reduced
  • The number of live nodes has increased
  • There has been a reduction in the number of under-replicated blocks
  • There has been an increase in the number of under-replicated blocks
  • Less than 20% free space available on one or more nodes in the cluster

Los posibles triggers a configurar para el JobTracker son:

  • No monitoring data received for the last 10 minutes
  • One or more jobs have failed
  • One or more nodes have become blacklisted
  • One or more nodes have been added to the exclude list
  • One or more nodes have been added to the Hadoop cluster
  • One or more nodes have been removed from the blacklisted nodes
  • One or more nodes have been removed from the exclude list
  • One or more nodes have been removed from the Hadoop cluster
  • The JobTracker was restarted

Un poco de ElasticSearch

Tengo pendiente este post sobre ElasticSearch desde hace al menos 1 año…y ha tenido que venir Fernando para recordármelo 😀

Elasticsearch es un producto open source que podría definirse como un motor de búsqueda distribuido en tiempo real basado en Java.

Sus principales características son:

· Datos en tiempo real: ElasticSearch disponibiliza los últimos cambios realizados sobre los datos en tiempo real

· Distribuido y escalable horizontalmente: lo que nos permite ir creciendo conforme lo hagan nuestras necesidades.

· Alta Disponibilidad: los clusters Elasticsearch son capaces de detectar y eliminar nodos que estén fallando y reorganizarse a sí mismos para asegurar que los datos estén a salvo y permanezcan accesibles.

· Multi-tenancy: Un cluster de Elasticsearch puede alojar múltiples índices que pueden ser consultados de manera independiente. También permite definir índices online.

· Búsquedas full-text: Elasticsearch se basa en Lucene para sus capacidades de búsqueda de texto, soportando geolocalización, autocompletado,…

· Orientado a documentos: Las entidades se almacenan en Elasticsearch como documentos JSON estructurados. Todos los campos son indexados por defecto y todos los índices pueden ser usados en una misma consulta.

· Gestión de conflictos: provee mecanismos (optimistic version control) para asegurar que los datos no se pierdan debido a cambios simultáneos sobre un mismo documento realizados por diferentes procesos.

· Sin esquemas: permite trabajar sin esquemas que definan la estructura de los datos.

· API Restful. Elasticsearch proporciona un API Restful sobre JSON. Además ofrece Apis para otros lenguajes como Java.

Algunos productos como Kibana usan ElasticSearch como almacenamiento.

El uso de ElasticSearch es enormemente sencillo:

· Se arranca con un comando (en Windows bin/elasticsearh.bat)

· En la URL http://localhost:9200/indica su estado

· Para indexar documentos (con curl):

Las inserciones se hacen en una URL de este estilo:

http://<dominio>/<indice>/<tipo>/<id>

por tanto mails es el índice que se creará la primera vez que inserte un elemento.

· Para consultar por clave: curl -XGET localhost:9200/mails/message/1

Que devuelve:

· Para recuperar documentos de índice mails, tipo message y from:unpocodejava@wordpress.com :

curl -XGET localhost:9200/mails/message/_search?q=from:unpocodejava@wordpress.com

Sin duda que ElasticSearch es una gran alternativa a Apache Solr fundamentalmente por su rápida puesta en marcha (facilidad de despliegue y configuración) y naturaleza distribuida aunque perdamos una riqueza funcional que ofrece Solr (a veces difícil de usar/implementar).

Siempre que pienso en ElasticSearch se me ocurre un ElasticSearch vs MongoDB (al estilo de esas míticas peleas entre superhéroes de Bat In The Sun), y aunque eso se merezca un post o varios, algunos links:

System Properties Comparison Elasticsearch vs. MongoDB

Why should not I use ElasticSearch as my primary datastore?

Cassandra vs MongoDB vs CouchDB vs Redis vs Riak vsHBase vs Couchbase vs Neo4j vs Hypertable vsElasticSearch vs Accumulo vs VoltDB vs Scalaris

Usando MongoDB con ElasticSearch (esto me suena a la peli de Batman con Superman…que me da miedito, aunque a lo mejor al final me convence):

http://v.bartko.info/?p=463

https://coderwall.com/p/sy1qcw

Drivers de Adopción Open Source

No hará falta recalcar que soy un fan del Open Source (no hay más que ver estos posts 😀)!

De :

El software Open-Source es cada vez más popular a nivel empresarial por su estabilidad, escalabilidad y confiabilidad.

Las compañías que adoptan tecnologías open-source buscan productos seguros y customizables.

Con el software propietario las compañías se hacen dependientes de una empresa de software para su evolución y soporte, mientras que en el modelo open-source pueden encontrar diversas opciones para el mantenimiento y evolución. Leer más

Esta infografía recoge todas estas consideraciones