Instalación

Mordiendo Hadoop – Instalación con Ambari

Han pasado casi 6 años desde los artículos de Mordiendo Hadoop: Mordiendo Hadoop: Instalación y primeras pruebas, Mordiendo Hadoop: Instalación en Cluster y Mordiendo Hadoop: Desarrollo de aplicaciones MapReduce. En ese tiempo el ecosistema de Hadoop se ha enriquecido, su arquitectura ha cambiado y su uso se ha extendido, convirtiéndose en la referencia de tecnología para Big Data. En estos años hemos realizado varias instalaciones de Hadoop en el grupo de Ingeniería de Información de la universidad, tanto para los cursos de maestría como para proyectos de pregrado y postgrado.

Desde hace poco más de 3 años, usamos la distribución de HortonWorks, HDP, por su facilidad de instalación (a través de ambari), por ser de código abierto y por su estabilidad. Cada vez es más fácil realizar la instalación, pero todo depende de la configuración previa de los nodos. En este artículo describiré la instalación de HDP, los pasos preliminares y las lecciones aprendidas que pueden ser aplicadas a nuevas instalaciones ( una traducción-resumen de la documentación oficial, con algunos consejos).

Preparación

Antes de iniciar la instalación de la plataforma HDP, debemos asegurarnos de cumplir con unos prerrequisitos:

Tener instalado en los nodos un sistema operativo soportado (Recomendados para HDP 2.3: Centos 6.x o 7.x). Consejo: Instalar el sistema operativo en inglés, ambari en ocasiones tiene problemas con la codificación de caracteres cuando el sistema operativo tiene un idioma diferente.
Desde la que será la máquina host de ambari el usuario root debe poder autenticarse sin contraseña a las otras máquinas del cluster.
Todas las máquinas deberían tener la hora sincronizada (usando ntp), el servicio de ntp debe estar configurado para iniciar al iniciar el sistema operativo.
Todas las máquinas deben ser alcanzables por nombre de dominio. (DNS es la mejor opción, si no es posible se puede lograr agregándolas al /etc/hosts de todas las máquinas).
Cada máquina debe tener correctamente configurado su FQDN (es una continuación del punto anterior). En especial, si la máquina tiene más de una interfaz de red debemos asegurarnos que siempre resuelva su nombre de dominio con la misma dirección IP (y que sea la que está en el segmento del cluster).
El número máximo de descriptores de archivos abiertos (el número máximo de archivos abiertos de forma simultanea) debe ser de, como mínimo, 10000 (el recomendado es 65536 ). Se puede verificar usando ulimit -Sn y ulimit -Hn (Límite suave y fuerte respectivamente) y se puede cambiar usando ulimit -n 10000.
Desactivar SELinux y configurar el firewall para que las máquinas del cluster puedan comunicarse entre ellas por los puertos apropiados, y permitir el acceso de los usuarios a los servicios. Se recomienda desactivar el firewall durante el proceso de instalación, e iniciarlo y configurarlo apropiadamente una vez la instalación esté completa.
Debemos tener una idea de cómo vamos a distribuir los servicios en el cluster (en qué máquinas tendremos los servicios maestros y en cuáles tendremos los esclavos y los clientes).

Instalación

Antes de iniciar la instalación debemos determinar cuál será la máquina dedicada como host de Ambari. En esta máquina debemos:

Configurar el repositorio:

wget -nv http://public-repo-1.hortonworks.com/ambari/centos7/2.x/updates/2.1.0/ambari.repo -O /etc/yum.repos.d/ambari.repo

Instalar ambari-server:
```
yum install ambari-server
```
Configurar ambari-server:
```
ambari-server setup
```
1. Seleccione el JDK deseado (Oracle JDK 1.8 es una buena opción). Debe aceptar la licencia para continuar con la instalación.
2. Si desea tener una manejador de bases de datos diferente a postgres para ambari, seleccione la configuración avanzada. En caso contrario acepte el valor por defecto (En ese caso se creará en Postgres una base de datos llamada ambari; El usuario por defecto será ambari y contraseña bigdata).
Inicie el servidor ambari:
```
ambari-server start
```
Desde un navegador web ingresar al servidor de ambari, http://<fqdn del servidor de ambari>:8080
- Ingresar con el nombre de usuario y contraseña por defecto (admin /admin).
- Al ingresar podrá crear un nuevo cluster usando el asistente, manejar los usuarios y grupos que pueden acceder a ambari y desplegar vistas.
- Al iniciar el asistente para la creación de un nuevo cluster le solicitará un nombre. Debe ser descriptivo, porque es la forma de identificar el cluster en ambari.
- El segundo paso del asistente es seleccionar la versión de HDP a instalar. Si las máquinas tendrán conexión a Internet durante la instalación sólo es necesario indicar la versión, en caso contrario es necesario abrir las opciones avanzadas y configurar la dirección del repositorio local que se utilizará.
- En el siguiente paso se agregan los nombres de las máquinas que harán parte del cluster, una por línea o utilizando expresiones. También debe indicar la llave privada ssh autorizada para acceder a los nodos del cluster. (Si realizó correctamente el paso 2 de la preparación, la llave privada probablemente estará en /root/.ssh/id_rsa del host de ambari)
  Si utilizó expresiones aparecerá una ventana confirmando los nombres
- En el siguiente paso se instalará el agente de ambari en los hosts seleccionados y se pueden eliminar nodos que no se quieran incluir en el cluster.
- A continuación es necesario seleccionar los servicios que se desean en el cluster.
- Luego debemos seleccionar dónde quedaran los componentes maestros de estos servicios.
- También seleccionar en qué nodos quedarán los componentes esclavos y los clientes de los servicios.
- Antes de la revisión final y la instalación, debemos personalizar la configuración de los servicios. Ambari hace recomendaciones de acuerdo a las características de los nodos, que pueden ser usados como valores por defecto, sin embargo conviene revisarlas y es necesario completar las configuraciones que aparecen marcadas en rojo (para las cuales no hay un valor pre-establecido).
- Luego se realiza una revisión final y se procede a la instalación, configuración y prueba de los servicios.
  
  El proceso de instalación puede tomar varios minutos, pero es completamente automático. Si hay una falla en alguno de los procesos se puede hacer clic en el mensaje para obtener el log (para determinar la causa). Son comunes los problemas de conexión con los servidores espejo, por lo que la solución más común es reintentar la instalación. Al finalizar verá el resumen de la instalación y podrá ir al tablero de control, en el cual puede ver cuáles servicios están activos, cuáles inactivos, los recursos utilizados, ver las alertas y realizar tareas de administración (por ejemplo, agregar un nuevo servicio al cluster, iniciar o detener un servicio y modificar la configuración).

El proceso de instalación es sencillo, semiautomático y permite tener rápidamente un entorno funcional. Sin embargo, se debe tener en cuenta que esta instalación es sólo un punto de arranque y se deben definir políticas para el uso de los recursos (generalmente más de un usuario utilizará el cluster) e ir ajustando la configuración de acuerdo a las métricas obtenidas.

agosto 18, 2016 por Christian Ariza TechStuff 0

Ubuntu Enterprise Cloud

Ubuntu Enterprise Cloud permite el despliegue de una Cloud privada, con el enfoque infraestructura como servicio(IaaS) compatible con Amazon EC2. Usa el hypervisor KVM y una versión de Eucalyptus modificada para usarlo. En este post revisaremos la arquitectura e instalación de Ubuntu Enterprise Cloud, siendo principalmente un resumen, y traducción, de la documentación pertinente.

Una visión general de los componentes se presenta en el siguiente diagrama, tomado del white paper Ubuntu Enterprise Cloud Architecture:

UEC Architecture

Cloud Controller

Provee la interface con la que el usuario de la cloud interactúa. Esta interface se compone de una API SOAP standard compatible con la API de Amazon EC2, una interfaz de consulta más simple que es usada por euca2ools y ElasticFox, y una interfaz web tradicional para la interacción directa.

Walrus Storage Controller(WS3)

Implementa APIs REST y SOA que son compatibles con Amazon Simple Storace Protocol (S3). Es usado para almacenar las imágenes de máquinas que pueden ser instanciadas por UEC y para acceder y almacenar datos. Actualmente la máquina en la cual corre el Cloud Controller también corre WS3, pero se espera que ésta limitación sea removida en las siguientes versiones.

Elastic Block Storage Controller(EBS)

Corre en la misma máquina que el Cluster Controller y se configura cuando éste es instalado. Permite crear dispositivos de bloques persistentes que pueden ser montados en máquinas en ejecución. Estos dispositivos pueden ser usados como cualquier dispositivo de bloques, por ejemplo creando en ello un sistema de archivos.

EBS permite crear instantaneas de volúmenes, que son almacenados en WS3. Las instantaneas pueden ser usadas como punto de inicio para nuevos EBS. La misma instantánea puede ser usada para instanciar tantos volúmenes como se desee.

A nivel de red los dispositivos de bloques se acceden usando ATA over Ethernet(AoE). Dado que los paquetes no pueden ser ruteados se requiere que tanto el EBS como los nodos que tienen las imágenes de las máquinas que lo acceden estén en el mismo segmento Ethernet.

Cluster Controllers

Opera entre los Node Controllers y el Cloud Controller. Recibe las peticiones para asignar imágenes de máquinas del Cloud Controller y decide cual Node Controller correrá la instancia de máquina (MInst). Esta decición es tomada en base a los reportes de estado que el Cluster Controller recibe de cada Node Controller. También puede responder al Cloud Controller acerca de la capacidad del cluster de correr tipos específicos de instancia, ayudándolo a decidir sobre cual cluster correr nuevas instancias.

El Cluster Controller está a cargo de manejar las redes virtuales que las Minst corran y enrutar el tráfico entre ellas. Los Cluster Controllers también corren los EBS Controllers. El grupo formado por un Cluster Controller y EBS Controller y un número variable de Node Controllers conforman el equivalente a las “zonas de disponibilidad” de Amazon.

Node Controllers

Corre en las máquinas físicas en las cuales se instanciarán las imágenes de máquinas. Interactúa con el hypervisor y el sistema operativo corriendo en el nodo, según es instruido por el Cluster Controller. La tarea inicial del Node Controller es descubrir el entorno en el cual está corriendo, en términos de recursos disponibles(memoria, espacio en disco, tipo de procesador y número de núcleos) así como máquinas virtuales en ejecución que puedieron se iniciadas independientemente del Node Controler, Cluster Controller y Cloud Controller.

Los node controllers esperan y realizan las tareas solicitadas por el Cluster Controller (iniciar o parar instancias) o responde a consultas de disponibilidad.

Cuando le llega una petición para instanciar una imágen de máquina el NC debe:

verificar la autenticidad de la petición.
Descargar la imagen de WS3(Las imágenes son cacheadas, para iniciar varias instancias en una máquina sólo se descarga una vez).
Se crea la intefaz de red virtual (VNI).
Inicia la instancia de la máquina corriendo como una maquina virtual.

Para detenerla se realizan las operaciones opuestas en el orden 1,4,3.

Instalación y despliegue.

Seguir leyendo…

febrero 10, 2011 por Christian Ariza TechStuff 5

Mordiendo Hadoop: Instalación y primeras pruebas.

Hadoop es un framework para computación distribuida que soporta aplicaciones con uso intensivo de datos. Implementa, entre otras cosas, el paradigma MapReduce y HDFS, un sistema de archivos distribuido y el principal sistema de almacenamiento en Hadoop.

En esta primera aproximación probaré la instalación y ejecución de Hadoop, haciendo un resumen de los pasos necesarios, traduciéndolos, y comentarios al margen frente a la documentación.

Los prerrequisitos de Hadoop son Java 1.6, ssh server y rsync, en Windows será necesario también Cygwin. Para éstas pruebas usaré una máquina virtual con Debian 5.0.5, Java 1.6.0_20, openssh 5.1p1.

La instalación de Hadoop se reduce a descargar la versión estable y descomprimirlo:

wget http://apache.mirrors.tds.net//hadoop/core/stable/hadoop-0.20.2.tar.gz
tar -xvf hadoop-0.20.2.tar.gz

Ahora, entrando a la carpeta que se descomprimió, se edita conf/hadoop-env.sh definiendo la variable JAVA_HOME con la ubicación de la instalación de java, en teoría funcionaría si la variable JAVA_HOME está definida en el entorno, pero es mejor definirla en el archivo para facilitar la distribución. A continuación se puede ejecutar el comando:

bin/hadoop

Para ver la documentación de uso.

Existen 3 configuraciones posibles de Hadoop: Standalone, pseudo-distribuida y distribuida. La configuración predeterminada es Standalone, no distribuida y un solo proceso de java, útil para depuración según la documentación. Con ésta instalación se puede ejecutar el primer ejemplo de Hadoop, un grep basado en MapReduce:

$ mkdir input
$ cp conf/*.xml input
$ bin/hadoop jar hadoop-*-examples.jar grep input output 'dfs[a-z.]+'
$ cat output/*

La salida crea dos archivos: part-0000 con la respuesta y .part-0000.crc con el CRC checksum.

Para ejecutar Hadoop en el modo Pseudo-distribuido, varios nodos en una máquina en procesos java diferentes, debemos modificar los archivos conf/core-site.xml, conf/hdfs-site.xml y conf/mapred-site.xml así:

conf/core-site.xml:

<configuration>

<property>

<name>fs.default.name</name>

<value>hdfs://localhost:9000</value>

</property>

</configuration>

conf/hdfs-site.xml:

<configuration>

<property>

<name>dfs.replication</name>

<value>1</value>

</property>

</configuration>

conf/mapred-site.xml:

<configuration>

<property>

<name>mapred.job.tracker</name>

<value>localhost:9001</value>

</property>

</configuration>

En el ambiente de pruebas funciona ssh a localhost sin contraseña, sin embargo esto puede no ser cierto en todos los ambientes. En el manual de Hadoop describen la forma configurarlo para ese caso. Esto sólo es necesario si no se puede hacer ssh a localhost sin contraseña:

$ ssh-keygen -t dsa -P '' -f ~/.ssh/id_dsa

$ cat ~/.ssh/id_dsa.pub >> ~/.ssh/authorized_keys

Ahora podemos ejecutar hadoop, primero creando un nuevo sistema de archivo distribuido, para luego ejecutar los nodos

$ bin/hadoop namenode -format
$ bin/start-all.sh

Ahora podemos acceder a la interfaz web del Job Tracker y del Namenode en el puerto 50030 y 50070 respectivamente.

Ahora ejecutaremos el ejemplo con el que probamos el Singlenode, para lo cual necesitamos copiar los archivos de entrada al sistema de archivos distribuido, en el cual también se crearán los archivos de salida, para hacer visibles las diferencias entre los dos modos se pueden borrar las carpetas input y output creadas anteriormente. Para ejecutar el ejemplo hacemos:

$ rm -rf input output

$ bin/hadoop fs -put conf input

$ bin/hadoop jar hadoop-*-examples.jar grep input output 'dfs[a-z.]+'

Ahora los archivos de salida están en el sistema de archivos distribuido, para traerlos ejecutamos:

$ bin/hadoop fs -get output output
$ cat output/*

o podemos ver el resultado directamente en el sistema de archivos distribuido:

bin/hadoop fs -cat output/*

Cuando terminamos podemos detener los nodos ejecutando:

$ bin/stop-all.sh

La salida incluye además de la respuesta los logs de la ejecución.

En un próximo post revisaremos la configuración de Hadoop en modo distribuido en un Cluster de máquinas.

octubre 3, 2010 por Christian Ariza TechStuff 6

Instalación

Preparación

Instalación

Cloud Controller

Walrus Storage Controller(WS3)

Elastic Block Storage Controller(EBS)

Cluster Controllers

Node Controllers

Instalación y despliegue.

Tag Cloud :)