SafeChildren Banner

Havoc Oracle Solaris Experts

jueves, 16 de julio de 2009

Instalación de Hadoop sobre Solaris 10 - Configuración

Introducción
Ya hemos visto en el post anterior como Instalar Hadoop sobre Solaris 10, sin embargo, no hemos hecho más que empezar. En esta nueva entrega configuraremos Hadoop y Solaris para tener un Cluster funcional con soporte para HDFS.

Debemos tener en cuenta que la seguridad de HDFS no es más elevada que la que nos pueda proporcionar NFS, por lo tanto, es altamente recomendable que las máquinas que componen el cluster de Hadoop sólo se dediquen a esto y que los usuarios no puedan hacer login en las mismas.

Por ejemplo, podemos estructurar nuestra red utilizando el siguiente esquema:

Nota: La configuración del esquema es conceptual ya que las reglas del firewall deben ser más extensas, sin embargo, quería mostrar el concepto de bloquear todo el acceso al cluster de Hadoop desde cualquier workstation exceptuando una encargada de su gestión.

Desactivación de servicios no necesarios en Solaris 10
Aunque este paso no es estrictamente necesario, es muy recomendable ya que queremos realizar una instalación lo más óptima posible con el fin de poder utilizar Hadoop en producción.
# svcadm disable svc:/application/graphical-login/cde-login:default
# svcadm disable svc:/network/smtp:sendmail

Configuración de Hadoop - HDFS

Vamos a comenzar configurando el sistema HDFS, para ello, debemos tener en cuenta que en esta arquitectura el namenode es nuestro punto único de fallo (SPOF) y por lo tanto los metadatos y log de transacciones son nuestro mayor tesoro, son como los Redolog y ArchiveLog de Oracle, por ello, vamos a utilizar la arquitectura OFA pero un poco adaptada.

En Oracle utilizaríamos una SAN para almacenar los datos, sin embargo, una de las principales caracteristicas de HDFS es que utiliza una arquitectura shared_nothing, es decir, cada nodo almacena su información independientemente de los demás. Esta arquitectura nos permite que el fallo de una datanode no afecte a los demás.

Voy a tratar de explicarlo con un ejemplo. Pensemos en HSFS como un RAID 5, donde cada disco del RAID es un datanode y por lo tanto ante la pérdida de un disco, los demás reconstruyen el contenido. Bien, HDFS copia cada bloque de datos n veces, siendo 3 por defecto, por lo tanto, es aquí donde encontramos la redundancia. Creo que el funcionamiento de HDFS y su tuning me llevará todo un post que lo verás dentro de poco, hasta entonces puedes encontrar más información en Apache HDFS.

Como ya he comentado nuestro namenode es nuestro SPOF por lo tanto, debemos tener la mayor redundancia posible en este host, es decir, RAID 1 o RAID 1+0 para el almacenamiento de los metadatos y transaction logs que serán las partes necesarias para poder reconstruir el sistema de ficheros ante una caída.

Nota: En mi instalación de ejemplo no existe RAID, ni HDD separados, aunque sea para pruebas no es muy recomendable esta configuración.

Por lo tanto, vamos a utilizar el path /u02/metadata/${user.name} para el almacenamiento de los metadatos, /u02/editlog/${user.name} para transaction log (EditLog) y /u02/data/${user.name} para los bloques de datos, de esta forma, podemos tener varias instalaciones de Hadoop ejecutándose con diferentes nombres, con un único path de almacenamiento ya que Hadoop convertirá ${user.name} al nombre de usuario que está ejecutando Hadoop.

# mkdir -p /u02/metadata/hadoop
# mkdir -p /u02/editlog/hadoop
# mkdir -p /u02/data/hadoop
# mkdir -p /u02/pid/hadoop
# chown -R hadoop:hadoop /u02/
# chmod 700 /u02

Nota: Como siempre, deberemos crear la estructura de directorios en todos los nodos del cluster.


Ya estamos listos para comenzar con la configuración de Hadoop, nos conectaremos a la máquina que va hacer de namenode y establecemos la configuración que luego replicaremos en todos los nodos. La configuración mínima que debemos establecer es:
  • JAVA_HOME path de java, en nuestro caso, /usr/java
  • HADOOP_HEAPSIZE tamaño máximo en Mb de JavaHeap, en nuestro caso, 500
  • HADOOP_OPTS opciones de tuning para la máquina virtual, en nuestro caso, -server
  • HADOOP_MASTER configuración de la cual se sincronizarán los clientes, en nuestro caso, master:$HADOOP_HOME/src/hadoop
  • HADOOP_PID_DIR ubicación de los pid, en Solaris es, /var/run
Así que nos conectamos al NameNode y configuramos el sistema de la siguiente forma
# zonename
global
# su - hadoop
$ cd $HADOOP_HOME
$ vi conf/hadoop-env.sh
export JAVA_HOME=/usr/java
export HADOOP_HEAPSIZE=500
export HADOOP_OPTS=-server
export HADOOP_PID_DIR=/u02/pid/hadoop

# Command specific options appended to HADOOP_OPTS when specified
export HADOOP_NAMENODE_OPTS="-Dcom.sun.management.jmxremote $HADOOP_NAMENODE_OPTS"
export HADOOP_SECONDARYNAMENODE_OPTS="-Dcom.sun.management.jmxremote $HADOOP_SECONDARYNAMENODE_OPTS"
export HADOOP_DATANODE_OPTS="-Dcom.sun.management.jmxremote $HADOOP_DATANODE_OPTS"
export HADOOP_BALANCER_OPTS="-Dcom.sun.management.jmxremote $HADOOP_BALANCER_OPTS"
export HADOOP_JOBTRACKER_OPTS="-Dcom.sun.management.jmxremote $HADOOP_JOBTRACKER_OPTS"
En el archivo $HADOOP_HOME/conf/core-site.xml

<property>
<name>fs.default.name</name>
<value>hdfs://namenode.hadoop.test.com:54310/</value>
<final>true</final>
</property>

<property>
<name>mapred.job.tracker</name>
<value>hdfs://namenode.hadoop.test.com:54311/</value>
<final>true</final>
</property>
Nota: El valor debe ser hdfs://___nombre_dns__que__queramos__/

Ahora vamos a editar el archivo de configuración de HDFS que se encuentra en $HADOOP_HOME/conf/hdfs-site.xml sin embargo hay que tener en cuenta unas cosas. En nuestra configuración queremos hacer distinción de metadata, editlog y data, por ello vamos a definir las propiedades dfs.name.dir (MetaDatos), dfs.name.edits.dir (EditLog) y dfs.data.dir, si no queremos separarlo podemos dejarlo con sus configuraciones por defecto, para ello sólo debemos establacer el la propiedad hadoop.tmp.dir. Puedes ver la configuración por defecto que se aplicará a HDFS en $HADOOP_HOME/src/hdfs/hdfs-default.xml

  • dfs.name.dir ubicación de los metadatos, en nuestro caso, /u02/metadata/${user.name}
  • dfs.name.edits.dir ubicación de los editlog, en nuestro caso, /u02/editlog/${user.name}
  • dfs.data.dir ubicación de los bloques de datos, en nuestro caso, /u02/data/${user.name}
  • dfs.replication número de réplicas, en nuestro caso, 8
El formato del archivo es xml utilizando los tags property, name y value para asignarlos. Existe una etiqueta llamada final que si está establecida a true el valor de la propiedad no puede ser modificado en ejecución. A continuación se muestra el archivo $HADOOP_HOME/conf/hdfs-site.xml

<property>
<name>dfs.name.dir</name>
<value>/u02/metadata/${user.name}</value>
<final>true</final>
</property><property>
<name>dfs.name.edits.dir</name>
<value>/u02/editlog/${user.name}</value>
<final>true</final>
</property>
<property>
<name>dfs.data.dir</name>
<value>/u02/data/${user.name}</value>
<final>true</final>
</property>
<property>
<name>dfs.replication</name>
<value>8</value>
</property>
Asignaremos ahora los master y slaves, como hemos comentado con anterioridad, HDFS necesita de un NameNode y JobTracker como mínimo y de mútiples datanodes. Así que en el fichero masters pondremos el NameNode y TrackerNode y en el fichero slaves todos los datanode que queramos, en nuestro caso node1 y node2.

Nota: Esto no lo tengo todavía muy claro, ya que no encuentro ninguna información sobre "TrackerNode" así que he asumido que irá en Masters, ya que son los dos únicos que hacen de Master

$ echo "namenode" > $HADOOP_HOME/conf/masters
$ echo "node1" > $HADOOP_HOME/conf/slaves
$ echo "node2" >> $HADOOP_HOME/conf/slaves
Ya hemos configurado el nodo principal, ahora tenemos que replicar la configuración a los nodos secundarios node1 y node2

$ pwd
/opt/hadoop/conf
$ scp hadoop-env.sh core-site.xml hdfs-site.xml masters hadoop@node1:$PWD
hadoop-env.sh 100% |**********************************************************************************************************| 2222 00:00
core-site.xml 100% |**********************************************************************************************************| 433 00:00
hdfs-site.xml 100% |**********************************************************************************************************| 599 00:00
masters 100% |**********************************************************************************************************| 9 00:00

$ scp hadoop-env.sh core-site.xml hdfs-site.xml masters hadoop@node2:$PWD
hadoop-env.sh 100% |**********************************************************************************************************| 2222 00:00
core-site.xml 100% |**********************************************************************************************************| 433 00:00
hdfs-site.xml 100% |**********************************************************************************************************| 599 00:00
masters 100% |**********************************************************************************************************| 9 00:00

Y eliminamos el contenido del archivo slaves en los nodos node1 y node2 ya que no tienen ninguno.

$ ssh node1
$ echo "" > $HADOOP_HOME/conf/slaves

$ ssh node2
$ echo "" > $HADOOP_HOME/conf/slaves

Con esto, hemos acabado la configuración de Hadoop!! Ahora, el siguiente paso es formatear la nueva unidad HDFS para que podamos empezar a trabajar con ella.

$ bin/hadoop namenode -format
09/07/17 10:37:00 INFO namenode.NameNode: STARTUP_MSG:
/************************************************************
STARTUP_MSG: Starting NameNode
STARTUP_MSG: host = sol10-enigma/10.1.1.4
STARTUP_MSG: args = [-format]
STARTUP_MSG: version = 0.20.0
STARTUP_MSG: build = https://svn.apache.org/repos/asf/hadoop/core/branches/branch-0.20 -r 763504; compiled by 'ndaley' on Thu Apr 9 05:18:40 UTC 2009
************************************************************/
Re-format filesystem in /u02/metadata/hadoop ? (Y or N) Y
09/07/17 10:37:03 INFO namenode.FSNamesystem: fsOwner=DrWho,hadoop
09/07/17 10:37:03 INFO namenode.FSNamesystem: supergroup=supergroup
09/07/17 10:37:03 INFO namenode.FSNamesystem: isPermissionEnabled=true
09/07/17 10:37:03 INFO common.Storage: Image file of size 95 saved in 0 seconds.
09/07/17 10:37:03 INFO common.Storage: Storage directory /u02/metadata/hadoop has been successfully formatted.
09/07/17 10:37:03 INFO common.Storage: Storage directory /u02/editlog/hadoop has been successfully formatted.
09/07/17 10:37:03 INFO namenode.NameNode: SHUTDOWN_MSG:
/************************************************************
SHUTDOWN_MSG: Shutting down NameNode at sol10-enigma/10.1.1.4
************************************************************/

Una vez formateado en nuevo sistema de ficheros, ya podemos iniciar Hadoop, para ello, debemos iniciar HDFS y MAP

$ $HADOOP_HOME/bin/start-dfs.sh
starting namenode, logging to /opt/hadoop/bin/../logs/hadoop--namenode-sol10-enigma.out
node1: starting datanode, logging to /opt/hadoop/bin/../logs/hadoop-hadoop-datanode-node1.out
node2: starting datanode, logging to /opt/hadoop/bin/../logs/hadoop-hadoop-datanode-node2.out
namenode: starting secondarynamenode, logging to /opt/hadoop/bin/../logs/hadoop-hadoop-secondarynamenode-sol10-enigma.out

$ $HADOOP_HOME/bin/start-mapred.sh
starting jobtracker, logging to /opt/hadoop/bin/../logs/hadoop--jobtracker-sol10-enigma.out
node1: starting tasktracker, logging to /opt/hadoop/bin/../logs/hadoop-hadoop-tasktracker-node1.out
node2: starting tasktracker, logging to /opt/hadoop/bin/../logs/hadoop-hadoop-tasktracker-node2.out

Si todo ha ido bien, podemos ver que el sistema está funcionando utilizando el comando jps del JDK que nos proporciona el pid y ClassName

$ /usr/java/bin/jps
8619 Jps
8473 JobTracker
2998 SecondaryNameNode
2826 NameNode


Un poco de resumen

Hemos visto como configurar el sistema de ficheros HDFS utilizando diferentes path para los metadatos, editlog y data, de esta forma, podemos separar en diferentes unidades físicas cada una de las partes, añadiendo tolerancia a fallos incorporando algún sistema de RAID en metadata y editlog.

En el próximo post empezaremos con nuestro HelloWorld dentro de HDFS y los comandos más básicos, espero no haberos aburrido mucho :)

miércoles, 15 de julio de 2009

Instalación de Hadoop sobre Solaris 10

Introducción

En el artículo anterior hacíamos una breve introducción sobre qué es hadoop y para que nos puede servir, ahora comenzaremos una nueva entrega para ver cómo podemos instalar Hadoop en Solaris 10 en una arquitectura multinodo

Requisitos Iniciales


Hadoop está escrito en Java y por lo tanto, debe funcionar en aquellas plataformas sobre las que esté soportado, sin embargo, nosotros nos vamos a centrar en la instalación de Hadoop sobre Solaris 10.
  • Descargar Hadoop de aquí
  • Java JDK 1.6+
Estructura Hadoop

Hadoop está compuesto de varios componentes y pueden ser instalados en una o varias máquinas aunque nosotros vamos a realizar la instalación con varios nodos cada uno de ellos una zona de Solaris 10.
  • NameNode. Sistema encargado de gestionar los Metadatos (Al menos 1)
  • DataNode. Almacenamiento de datos (Al menos 1)
  • JobTracker. Sistema encargado de gestionar los Jobs (Reduce)
  • TaskTacker. Sistema encargado de gestionar los Task (Map)
  • SecondaryNameNode. Sistema de Backup para NameNode
Vamos a realizar una instalación de Hadoop sobre Solaris 10, teniendo la siguiente estructura:

En la Zona Global instalaremos Hadoop NameNode y JobTracker y en la Zona node1 y node2 serán DataNodes. Puedes encontrar información más detallada de qué es cada uno de ellos aquí

Ajustes de Solaris para mayor seguridad


Vamos ha realizar unos ajustes en las instalaciones de Solaris para mejorar su seguridad, esto debemos hacerlo en cada una de las zonas. Por defecto, Solaris guarda las contraseñas utilizando crypt, sin embargo, soporta muchos más algoritmos, para ello editamos el archivo /etc/security/policy.conf y modificamos la entrada

CRYPT_DEFAULT=__unix__


por

CRYPT_DEFAULT=1

Esto hará que las contraseñas ahora se guarden utilizando md5. También, vamos a poner un banner en cada maquina para poder distinguirlas fácilmente

# banner node1 > /etc/issue

Nota: Sustituye "node1" por el nombre que le quieras asignar

Ajuste de Fecha/Hora automática

Es muy importante tener los relojes sincronizados para que el sistema Hadoop funcione correctamente, por ello, vamos a configurar ntp en la Zona Global (ya que las Zonas NoGlobales no puede modificar el clock)

# echo "server hora.rediris.es" > /etc/inet/ntp.conf
# svcadm enable svc:/network/ntp:default


Creación del Usuario, Grupo y Project
# groupadd hadoop
# projadd hadoop
# useradd -g hadoop -p hadoop -s /bin/bash -d /export/home/hadoop -m hadoop
# passwd hadoop
Nota: Todos los usuarios deben tener la misma ruta de $HOME, id, groupid para evitar problemas.

Estructura de directorios y variables de entorno

Deberemos crear la estructura de directorios igual en todas las máquinas que pertenezcan al cluster de hadoop
# cd /opt
# /usr/sfw/bin/wget http://apache.rediris.es/hadoop/core/hadoop-0.20.0/hadoop-0.20.0.tar.gz
# /usr/sfw/bin/gtar zxvpf hadoop-0.20.0.tar.gz
# mv hadoop-0.20.0 hadoop
# chown -R hadoop:hadoop hadoop
Ya hemos instalado hadoop, fácil no? La verdad es que no hemos hecho más que empezar ... Ahora nos vamos a conectar a la máquina (zona) que hará de NodeName (en nuestro caso será la zona global)

# uname -a
SunOS sol10-enigma 5.10 Generic_139556-08 i86pc i386 i86pc
# zonename
global


Vamos a editar el $HOME/.profile del usuario "hadoop" para asignar las variables necesarias para la instalación: JAVA_HOME, HADOOP_HOME

# su - hadoop
Sun Microsystems Inc. SunOS 5.10 Generic January 2005
$ vi .profile
JAVA_HOME=/usr/java
HADOOP_HOME=/opt/hadoop
HADOOP_DATA_DIR=/var/hadoop-datastore/hadoop
PATH=$PATH:$HADOOP_HOME/bin:/usr/sfw/bin:/usr/local/bin:/usr/ccs/bin
export PATH HADOOP_HOME JAVA_HOME HADOOP_DATA_DIR

MAIL=/usr/mail/${LOGNAME:?}

Editamos el archivo /etc/hosts (de cada máquina) he introducimos las direcciones IP de los datanode y el namenode (en mi caso 10.1.1.3/10.1.1.5 para DataNode y 10.1.1.4 para NameNode)

##########################################################
## CLUSTER HADOOP
##########################################################
10.1.1.3 node1 node1.hadoop.test.com
10.1.1.4 namenode namenode.hadoop.test.com
10.1.1.5 node2 node2.hadoop.test.com

Generamos una nueva clave SSH para el usuario "hadoop" y configuramos el sistema para que nos permita acceder de un nodo a otro sin contraseña

$ pwd
/export/home/hadoop
$ zonename
global
$ ssh-keygen -t rsa
Generando pareja de claves pública/privada rsa.
Escriba el archivo en el que se debe guardar la clave (/export/home/hadoop/.ssh/id_rsa):
Directorio creado '/export/home/hadoop/.ssh'.
Escriba una frase de contraseña (si está vacío se interpreta que no hay ninguna frase de contraseña):
Escriba la misma frase de contraseña de nuevo:
Se ha guardado su identificación en /export/home/hadoop/.ssh/id_rsa.
Se ha guardado su clave pública en /export/home/hadoop/.ssh/id_rsa.pub.
La huella de la clave es:
3e:05:9b:1c:6d:80:50:5a:53:77:5d:54:15:b4:b1:02 hadoop@sol10-enigma
$ cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
$ ssh namenode
No se puede establecer la autenticidad del sistema 'namenode (10.1.1.4).
RSA la firma de la clave es 8f:5e:ae:c4:fa:4e:25:3b:9d:1d:ed:2d:4c:97:d6:c1.
¿Desea continuar con la conexión (sí/no)? sí
Advertencia: Se ha agregado permanentemente 'namenode,10.1.1.4' (RSA) a la lista de hosts conocidos.
Last login: Sat Jul 11 17:24:38 2009 from sol10-enigma
Sun Microsystems Inc. SunOS 5.10 Generic January 2005
$ exit
Copiamos las claves a los demás nodos y nos conectamos a ellos para comprobar que podemos acceder sin contraseña. Desde la Zona Global
$ pwd
/export/home/hadoop/.ssh
$ cd ..
$ scp -r .ssh hadoop@node1:~
Contraseña:
id_rsa 100% |******************************************************************************| 883 00:00
id_rsa.pub 100% |******************************************************************************| 229 00:00
authorized_keys 100% |******************************************************************************| 229 00:00
known_hosts 100% |******************************************************************************| 451 00:00
$ ssh node1
Last login: Mon Jul 13 20:36:29 2009 from namenode
Sun Microsystems Inc. SunOS 5.10 Generic January 2005
$ exit
logout
Cerrada la conexión con node1.
Copiaremos el profile que hemos creado para el usuario "hadoop" a todos los nodos y comprobaremos que tenemos "hadoop" en el path

$ scp .profile hadoop@node1:~
.profile 100% |******************************************************************************| 176 00:00
$ ssh node1
Last login: Mon Jul 13 20:40:22 2009 from namenode
Sun Microsystems Inc. SunOS 5.10 Generic January 2005
$ which hadoop
/opt/hadoop/bin/hadoop

Vamos a hacer un pequeño resumen de lo que hemos hecho hasta ahora:

  1. Descargar e Instalar Hadoop en cada una de las máquinas
  2. Crear Usuario, Grupo y Proyecto en cada una de las máquinas
  3. Crear clave RSA y copiarla al resto de las máquinas para permitir el acceso sin contraseña

Espero no haberos aburrido con esta entrega y en la próxima comenzaremos con la configuración de nuestro cluster de Hadoop.

lunes, 13 de julio de 2009

Apache Hadoop - Qué es y para qué sirve

Introducción

Llevo un tiempo investigando y analizando la información disponible sobre Hadoop en Internet y he decidido crear un Post (después de mucho tiempo) para intentar aclarar: Qué es, Para qué sirve y Quién debe usarlo.

Espero poder responder a estas preguntas de la forma más sencilla posible (siempre entendiendo que si estás aquí es porque eres técnico ;) )

Qué es Hadoop

Dentro de la Web de Hadoop encontramos la definición de Hadoop como:

“Apache Hadoop Core is a software platform that lets one easily write and run applications that process vast amounts of data”
“Apache Hadoop Core es una plataforma de software que permite el desarrollo y ejecución de aplicaciones que procesan ingentes cantidades de datos”

Es decir, Hadoop es un Framework para el desarrollo de aplicaciones de procesamiento paralelo utilizando MaReduce, por lo tanto, Hadoop en sí “no es nada”

Qué es MapReduce?

MapReduce es un framework diseñado por Google para solucionar los problemas de procesamiento que tenían en sus aplicaciones más críticas (Buscador, Maps, Gmail, etc. )

No voy a entrar en detalle de cuál es el funcionamiento de MapReduce, puedes la documentación del análisis aquí simplemente haré un pequeño resumen (obtenido de Wikipedia, Hadoop y Google)

“La idea principal de MapReduce consiste en dividir los datos en un conjunto Map(clave, valor), y posteriormente aplicar Reduce sobre todos los Map(clave, valor) creados."

En términos UNIX se puede escribir como: $cat|map|sort|reduce

Para qué sirve Hadoop y cómo puedo aplicarlo en mi estructura?

La verdad es que es una pregunta que he tardado en responderme yo mismo. En principio todos nos sentimos “atraídos” por una nueva forma de ejecución paralela (nos entra la necesidad de aplicarlo a todo software a nuestro alcance ... :) ), sin embargo, la casuística que resuelve MapReduce no es aplicable a todo, para ello tiene que darse una condición muy simple: “El volumen de datos a procesar sea muy muy elevado”

Por ejemplo, si necesitamos saber cuántas peticiones ha hecho cada IP a nuestro “index.html”, puede ser una aplicación Hadoop o No, en función de cuál sea el volumen y la arquitectura de nuestros servidores, me explico con un ejemplo.


Tenemos como arquitectura Web la siguiente:

Para ello, podemos utilizar unos “simples” comandos de la shell para hacerlo. He modificado la dirección IP origen para que los tres últimos valores, siempre sean “0”


$ time cat /opt/www/squid-2.7/var/logs/access.log | grep "/AssistedSearch/index.html" |awk '{print $1" "$7}'|uniq -c
2 79.0.0.0 http://search.sfchildren.com/AssistedSearch/index.html
1 80.0.0.0 http://search.sfchildren.com/AssistedSearch/index.html
1 80.0.0.0 http://search.sfchildren.com/AssistedSearch/index.html
1 80.0.0.0 http://search.sfchildren.com/AssistedSearch/index.html
7102 10.0.0.0 http://search.sfchildren.com/AssistedSearch/index.html
..............

real 1m10.191s
user 1m13.253s
sys 0m6.940s

$ time cat /opt/www/squid-2.7/var/logs/access.log |wc -l 4636356
real 0m23.575s
user 0m19.087s
sys 0m6.568s

Como podemos ver, hemos contado las veces que cada IP ha realizado la llamada a nuestro “Index.html” utilizando simplemente shell (hay que decir que esto no cuenta de una forma optimizada ya distinguimos entre mayúsculas y minúsculas y los parámetros se computan, deberíamos optimizar el comando, pero a modo de ejemplo nos sirve), vemos que para procesar 4.636.356 registros le ha llevado 1' 10'', teniendo en cuenta que el archivo de log es de 666Mb (es totalmente fortuito :/ )

Nuestro requisito principal para poder utilizar de forma óptima Hadoop es que existe una cantidad de datos muy elevada a procesar, y 600Mb, no lo es. Así que hemos creado un archivo de 2Gb para volver a repetir el mismo comando.

Ahora los resultados han sido de 3' 46'' para contar el número de registros (un total de 18.545.467) y de 6' 39'' para el uniq -c.

Hombre, no es un tiempo “excesivo”, sin embargo, debemos tener en cuenta que sólo hemos buscado por una única dirección, si queremos hacer esto para varias URL llevaría un tiempo considerable, y si además añadimos el hecho de que sólo hemos consultado el Log de un único servidor ... qué pasaría si tuviésemos la siguiente estructura:


Aquí la cosa se complica ... pero no por dificultad, sino por Tiempo de procesamiento.


Conclusiones Iniciales

Hadoop es un Framework muy potente y realmente sencillo de utilizar, sin embargo, debemos tener muy claro Cuál es la problemática que resuelve y no intentar resolver todos nuestros problemas con él.

Para ello, debemos analizar si el problema a resolver cumple con los principios de:

“WriteOne, ReadMany” → Escribir una vez, Leer muchas

“Vast Amount Data” → Cantidad Ingente de datos (TB, PB)

Si nuestro problema no cumple con estas condiciones, entonces no estamos hablando de una aplicación Hadoop “pura” y el problema ha de resolverse utilizando otro “tipo de tecnología de Cluster”.

Espero haber puesto algo de "luz" en el oscuro mundo de Hadoop y en los próximos posts hablaremos de la instalación sobre Sun Solaris 10 y nuestros primeros pasos.

UPDATED: Cómo Instalar Hadoop sobre Solaris 10

lunes, 24 de septiembre de 2007

Solaris ForceDirectIO y Sistemas de Backup para Oracle - Parte I

Oracle 8i ya es una "reliquia" aunque para muchos todavía nos encontramos muy contentos con esta versión, sin embargo, ... debemos "OraclEvolucionar"

Uno de los consejos que se daban por el mundo de los DBA's sobre Solaris + Oracle8i era el uso de ForceDirectIO en el montaje de los discos para hacer que Oracle no usase los buffers del sistema de archivos.

Esto ha sido optimizado en las versiones 9i y 10g, sin embargo todavía podemos utilizar, sobre todo en la 9i, la opción ForceDirectIO para obtener un beneficio extra en el rendimiento. El problema era que si se utilizaban las herramientas del sistema para realizar las copias de seguridad el impacto era realmente elevado. Esto hacía que la copia de seguridad se alargase en el tiempo de forma alarmante.

Para ello, podemos realizar las pruebas con los parámetros genéricos (mount -F ufs, mount -F ufs -o logging) y los opcionales (mount -F ufs -o forcedirectio) ForceDirectIO. Si nos fijamos y hacemos de las configuraciones básicas nuestra líneas base tenemos los siguientes datos:


Como podemos observar al utilizar forcedirectio con archivos grandes, el rendimiento de cp es realmente pésimo (esto también se refleja en rsync), sin embargo cp8m (GNU cp con modificaciones) realiza la copia en prácticamente la mitad de tiempo.

Si esto lo extrapolamos a una copia de 70 Gb estaríamos hablando de copiar en 2h lo que antes lo hacíamos en 8h.


Qué modificaciones Tiene CP8M

cp8m incluye una pequeña modificación en el tamaño del buffer, pasando de 512 Kb a 8 Mb, de esta forma se consigue un aumento de rendimiento.

Vamos a modificar el código de GNU Core Utils.

1.- Debemos bajarnos la versión de GNU Core Utils
2.- Descomprimimos el tar y editamos el archivo
/coreutils-6.9/src/copy.c

Sobre la línea 349 debemos sustituir
size_t buf_size = ST_BLKSIZE (sb);
por
size_t buf_size = 8388608;

3.- Compilamos con SunCC (Podemos utilizar -fast -native siempre que estemos en la misma arquitectura que producción)
4.- Instalamos el paquete en /usr/local/bin
5.- Copiamos /usr/local/bin/cp a /usr/sbin/cp8m

Con esto ya hemos concluido con la primera parte viendo como el impacto de forcedirectio sobre las herramientas del sistema puede hacer que nuestras tareas de copia de seguridad se vean realmente afectadas.

En la segunda parte, veremos como podemos hacer que cp8m + nfs sean muy buenos aliados para el sistema de backup.

Un Saludo,
Urko

martes, 18 de septiembre de 2007

Almacenamiento y Disponibilidad - Parte I

Hace mucho tiempo que se sabe del almacenamiento en Red, es cierto, sin embargo cada día nos damos cuenta de la importancia de tener nuestros datos disponibles desde cualquier punto en cualquier momento.

Una de las opciones que me ha gustado siempre ha sido iDisk por su simplicidad y su rendimiento. Esto unido a un diseño innovador (cuando se empezó a promocionar pocos usaban más allá del WWW en Internet) hizo que se ganara mis respetos.

Si trasladamos esto a un entorno profesional/semi-profesional vemos que existen algunas arquitecturas (desde tiempo memorables) que ya lo facilitan, nfs, cifs, entre otros.

Sin embargo, por qué ese resurgir del Almacenamiento en Red?
Por la movilidad! Ese nuevo concepto de todo debe estar conectado (sin cables) y todo debe estar disponible en cualquier momento y desde cualquier dispositivo.

Ahora las PDA, BlackBerry y sucedáneos son nuestros mejores amigos (oh dios! cómo he vivido sin mi correo push) y nuestros datos deben ser accesibles (aunque no los use) . Todo esto hace que nuestros requisitos y debamos volver a aquellos que durante muchos años se tachó como incorrecto: Centralización

Durante estos días continuaré con el artículo de "Opinión" sobre NAS y las nuevas problemáticas.

Un Saludo,
Urko