Alta disponibilidad de Hadoop con Linux HA

1 Diamun Fikri Solissa, 2 Maman Abdurohman

Escuela de computacion
Universidad de Telkom
Bandung, Indonesia
1 diamun.fs@gmail.com, 2 abdurohman@telkomuniversity.ac.id
Resumen - Este artículo propone el método de alta disponibilidad.
utilizando Heartbeat y DRBD en Hadoop Namenode Failover.
Implementación de Hadoop como marco de procesos informáticos y
el almacenamiento de medios debe ser soportado por la disponibilidad en caso de
fracaso. Utilización del sistema de clúster en Hadoop con muchos
Datanode es uno de los puntos fuertes. El archivo almacenado será
replicado en datanode distribuido como bloques que hacen si uno el
El servidor de datanode falla, el otro servidor de datanodes todavía tiene
bloques duplicados El problema en el sistema hadoop, hay solo
un Namenode que es el comunicador entre usuarios y
Datanodes. Mientras Namenode cae, los usuarios no pueden acceder
Archivos almacenados en Datanode. Este método propuesto cumple con las
Proceso de conmutación por error de nombre de nodo. El uso de este método es muy
Efectivo porque puede acelerar el tiempo de inactividad con automático.
Failover formado por Heartbeat y reflejo en tiempo real formado por
DRBD. Los resultados indican que el uso de DRBD y Heartbeat
Puede acelerar el tiempo de conmutación por error de menos de 10 segundos.
Palabras clave: Hadoop, Namenode, Alta disponibilidad, conmutación por error,
falta del tiempo
I. I NTRODUCCIÓN
Según una investigación realizada por Gantz et al., Electrónica.
las estimaciones de datos alcanzaron 0.18 zetabyte en 2006 y se pronostica que
Alcanzar 1.8 zetabyte en 2011, esta gran cantidad de datos electrónicos necesita
ser procesado para obtener más beneficios [1].
A veces, las aplicaciones requieren una computadora con alto
recurso como el entorno de implementación, pero por lo general el
El precio para una computadora con alto recurso no es barato, mientras que
para computadoras con bajas especificaciones será menos confiable en
manejo de datos de gran tamaño. La utilización de Hadoop como marco para
proceso de computación y medios de almacenamiento es precisamente porque
Hará el proceso como computación distribuida, lo que no es
solo confiando en un servidor que funciona relacionalmente, pero por
Utilizando procesos de computación con mucho trabajo distribuido.
servidores Hay YARN como la nueva plataforma de Hadoop [2]. En
Además de la computación rápida, el servidor Hadoop también se enfrenta a varios
Interferencia potencial con el sistema que podría causar
Pérdida de datos y retrasos que son perjudiciales para los procesos de negocio.
Con la conciencia de la necesidad de desarrollo de
Sistemas para mantener la continuidad de los procesos de negocio.
Requisitos, y almacenamiento de seguridad de la información, realizamos.
El análisis y diseño de los sistemas de alta disponibilidad de Hadoop.
La debilidad del sistema de archivos distribuidos de Hadoop (HDFS)
es cuando Master Server, que incluye NameNode y
JobTracker estaba fuera de servicio, entonces el sistema de archivos no podrá
Sirve a los usuarios [3]. De hecho, en HDFS el llamado Secundario
Namenode a menudo hay una idea mal entendida de que si primaria
Namenode die it será reemplazado por Secondary Namenode
inmediatamente. Aunque este es un nombre de nodo secundario, solo
mantiene la última información de la estructura de directorios en el
Namenodo primario. La manera de anticipar el Punto Único de
Los problemas de falla (SPOF) en el NameNode primario se deben realizar
clonación de este servidor NameNode en una máquina diferente, por lo que
que si el servidor primario de NameNode está teniendo problemas, puede ser
Sustituido por su clon, pero es necesario también failover automático.
método, si el servidor primario falla, entonces el servidor que
actúa como un clon automáticamente actuará como el servidor primario y
todos los servicios existentes del servidor primario de Hadoop se ejecutarán sin
Configuración manual por el administrador de inmediato. Proceso de failover
que se produce se puede dividir en tiempo de inactividad planificado y
tiempo de inactividad no planificado. Planificado tiempo de inactividad experimentado
maestro
servidor al actualizar hardware, a saber, los servicios de Hadoop
apagar antes de apagar el servidor maestro. No planeado
el tiempo de inactividad es un método cuando Master Server muere repentinamente
sin planear
Por lo tanto, necesitamos un método para mantenerse al día cuando el principal
el servidor está inactivo y ese método puede minimizar el tiempo de inactividad, por lo que
Que el nivel de disponibilidad de este sistema sea mayor.
El dispositivo de bloque replicado distribuido (DRBD) es un dispositivo de bloque
aplicación de replicación de almacenamiento entre 2 piezas de un servidor,
que permite sincronizar 2 servidores [4], mientras que Heartbeat es un
Aplicación que puede detectar cuando el servidor primario se cae.
entonces redirigirá la función del servidor principal al servidor de respaldo
automáticamente [5]. En este documento, propusimos Linux-HA como una
Solución para alta disponibilidad de Hadoop.
II. H ADOOP Y L INUX HA UNA CONFIGURACIÓN
A. Hadoop
Hadoop es un framework de software basado en Java y abierto.
fuente. Sirve para procesar datos muy grandes con datos distribuidos.
Método y ejecutar en la parte superior de un clúster que consta de varios
ordenadores conectados entre sí. Las características de MasterNode son
Consiste en Namenode y Job tracker, Save HDFS
espacio de nombres, gráficos del sistema de archivos y metadatos, mapeo de historias
de cada ID de bloque de lista, guarda la ubicación de memoria de cada bloque,
Da órdenes en el Datanode SlaveNode existente para crear,
replicado, y eliminar bloques y punto único de falla

La función principal de Namenode es gestionar el archivo.

espacio de nombres del sistema. Mantiene metadatos y sistema de archivos para.
todos los directorios Los archivos que se guardaron en HDFS serán tomados y
almacenado en metadatos de namenode antes de almacenado en datanodes. Mientras
en el proceso de recolección de datos, el cliente le pedirá al namenode primero que
averigüe la ubicación de los bloques de datos que se almacenaron en datanode.
Las características del nodo esclavo consisten en datanode y
TaskTracker, realizar el almacenamiento de datos en forma de bloques de datos,
No hay metadatos, Reporting to Namenode blocks en
Inicio, Ejecutar comandos (crear, replicar y eliminar) bloques de
Namenode.
1) Proceso de escritura Hadoop
En primer lugar, después de que el servidor maestro recibe datos de los usuarios,
will toma el nombre del archivo que se almacenará en la base de datos. Entonces
El usuario HDFS le dará a Namenode solicitud para escribir datos.
Namenode organizará Datanode para guardar el archivo. Namenode
almacenar los metadatos del archivo enviado a Datanode en forma de
nombre, tamaño, permisos, bloque de datos de archivos y actualizaciones de la
Espacio de nombres HDFS. Datanode recibirá directamente los datos para ser
almacenado en HDFS sin pasar Namenode y almacenado en el
Forma de bloques de 64 MB (por defecto). Si el tamaño del archivo
excede el tamaño del bloque de datos, entonces el Datanode restante se guardará
Archivos en otros bloques de datos.
2) Proceso de lectura de Hadoop
El servidor recibirá una cadena seleccionada por los usuarios en el
solicitud. El usuario HDFS enviará una solicitud a Namenode
cuyos nombres han sido usuario. Entonces Namenode comprueba su
existencia al espacio de nombres. Después de que Namenode obtenga los datos.
bloques, desde Datanode, entonces el servidor responde al usuario que los datos
está listo para su descarga. La Fig. 1 muestra la arquitectura HDFS [6].
B. DRBD
DRBD (Distributed Replicated Block Device) es el
Desarrollo de tecnologías RAID 1 (reflejo en el mismo
disco duro). La diferencia se duplica a través de la red.
La duplicación se produce mediante la copia de los dispositivos de bloque de datos,
No en la forma de los datos intactos. DRBD tiene ventajas
en comparación con RAID 1, que refleja un servidor diferente con un
fuente de copia de seguridad. El servidor de separación tiene la ventaja de que si hay
son problemas o mueren en el servidor principal, entonces el servidor espejo
Actuará como el servidor primario.
Método de duplicación DRBD
• Tiempo de actividad: la replicación se realiza continuamente cuando
La aplicación modifica los datos en los dispositivos de bloque.
• Sincrónico: Al realizar la duplicación síncrona, Archivo
Sistema en el nodo activo fue informado de que la escritura
proceso ha tenido éxito cuando la escritura ha sido
Hecho en el segundo dispositivo de bloque de cada nodo.
La duplicación síncrona es la opción de la red local.
con el fin de no perder una sola transacción si el accidente
Ocurrió durante la escritura del nodo activo.
• Asíncrono: se le informará al sistema de archivos que la escritura es
completado cuando los datos se escriben en el disco local. Esta
Asíncrono necesario al hacer espejos remotos [7].
Fig. 1. Arquitectura HDFS [6].
C. latido del corazón
Heartbeat es un demonio en * nix que proporciona cluster
infraestructura. Heartbeat requiere combinación con CRM
(Cluster Resource Manager) a cargo de iniciar y finalizar
Servicio (TCP IP, Web, Base de datos, etc.), en el lanzamiento de la versión
2.xx CRM está incluido en él. Latidos del corazón realiza
Comunicación entre dos o más servidores que tiene como objetivo
verifique si el servidor está activo o inactivo [8]. La figura 2 muestra que
El grupo izquierdo en un estado activo. Caso en punto: cuando nodo 1
activo, el usuario se comunicará con el nodo 1 (izquierda). Entonces cuando
Los servicios son atendidos por el nodo 1 que tiene problemas, entonces el
El servicio fue tomado por otros nodos.
Proceso de traslado del nodo de servicio primario al esclavo.
Los nodos cuando se produce una falla se llama Failover, luego lo contrario
proceso también se llama recuperación y cuando el proceso de migración
Es realizado por el administrador llamado conmutación. Tareas de latido
son: Para la comunicación entre ordenadores o servidores a través de LAN.
Red o a través de un puerto serie que tiene como objetivo realizar Failover.
Realice la eliminación de IP (IP flotante) en el servidor a otro servidor
en el cluster. Los servicios de carrera están registrados a Heartbeat
automáticamente cuando se ejecuta Heartbeat. La figura 3 muestra el
Conceptos de latidos del corazón.
Fig. 2. Arquitectura DRBD [9]
67
 Página 3
Fig. 3 . Conceptos de latidos del corazón [9].
D. Alta disponibilidad
Clúster de alta disponibilidad, que también se conoce como conmutación por error
Cluster, generalmente se implementa para aumentar los servicios.
Disponibilidad por parte del cluster. Uso de elementos de cluster redundantes.
nodos, que se utilizan para reemplazar cuando uno de los clústeres
Los elementos están abajo. El tamaño más común de este concepto es
dos nodos Las implementaciones de este cluster intentan evitar
Punto único de fallo.
Usando el mismo modelo, el servidor de alta disponibilidad puede ser
Desarrollado en áreas geográficas separadas, por ejemplo, hay
Un sistema de respaldo en la ciudad o isla u otro país. Esta
La topología se llama recuperación de desastres.
III. L INUX HA SOLUTION PARA ALTA DISPONIBILIDAD DE HADOOP
El diseño de este sistema consta de tres etapas, Hadoop.
Etapa de desarrollo del sistema, antes de la etapa de conmutación por error, y después
Etapa de conmutación por error. El sistema Hadoop fue construido para trabajar con Master
y el sistema de esclavos. En la primera etapa, los datos del cliente serán
almacenado en HDFS. HDFS almacenará los datos en forma de bloques
que se replican 3 partes por datanode según el número
previsto. El cliente se pondrá en contacto con Namenode en Master Server para
almacenar los metadatos. Los datos reales serán almacenados en Datanode.
Segunda etapa, en el escenario antes de la conmutación por error, Master Node tiene
una función como un servidor maestro que consiste en Namenode,
Secundario Namenode y Jobtracker, mientras que 3 piezas de esclavo
El servidor es datanode_1, datanode_2 y datanode_3.
Tasktracker Datanode y se conectará al estado de
Nodo maestro porque el nodo maestro está activo como maestro
Servidor. Mientras tanto, Mirror Node servirá como un servidor en espera
no está ejecutando los servicios de Hadoop, pero solo recibe actualizaciones
y la sincronización desde el nodo maestro. En el escenario después de un
Failover, la función de Master Server se moverá a Mirror.
El nodo y su estado cambiaron a Master Server, que se ejecutará
El servicio del servidor maestro (Namenode, Namenode secundario
y Jobtracker) previamente realizado por Master Node. En este
etapa, el tercer servidor esclavo y los usuarios estarán conectados a
Nodo espejo automáticamente.
A. Proceso de conmutación por error
Una vez finalizada la construcción, se instalará Hadoop.
componentes que soportan alta disponibilidad en DRBD y
Heartbeat en Master Server y Mirror Server.
B. DRBD
Al principio, hubo un proceso de sincronización.
entre el disco virtual en Master Server y Mirror Server. Esta
Es una función del servidor de sincronización para conocer a cada socio.
y determinar qué servidor será el servidor primario y un
servidor secundario El tiempo de sincronización inicial depende de la
Tamaño de la asignación de disco virtual proporcionada por la velocidad de sincronización.
10240 kb / s (DRBD por defecto). Una vez realizada la sincronización
El proceso está completo, la próxima comunicación entre la
el disco duro virtual utilizará TCP en el puerto 7789 de cada servidor.
Se implementa el proceso de replicación DRBD en este documento.
utilizando un método síncrono llamado DRBD protocolo C. El
El método tiene las ventajas del proceso de replicación síncrona.
Se realiza en tiempo real y los procesos de escritura en el servidor serán
informado al cliente completado solo si se ha hecho escribir
en el segundo nodo. Esto puede ser comprobado por cada actualización en
El servidor primario se replicará perfectamente en el espejo.
servidor.
C. latido del corazón
Hay 3 componentes que afectan el tiempo de conmutación por error de Heartbeat,
es decir, keepalived, warntime y deadtime. Heartbeat es enviado por
El servidor espejo al servidor maestro, ese intervalo de tiempo se establece en
La configuración ha.cf de keepalived para conocer las características del servidor maestro.
estado en vivo Durante el intervalo de aviso, el servidor Mirror
Decide que el servidor maestro falla. Cuando el servidor maestro
es un error, Mirror Server enviará una solicitud al Maestro
Servidor durante el intervalo de tiempo muerto. La función más importante.
de Heartbeat es crear y ejecutar el servicio virtual de IP después de la conmutación por error
Procesar automáticamente. Así que después de que surgió que el Maestro
El servidor estaba completamente muerto, entonces la IP virtual se movió a Standby
Servidor, la tarea de Heartbeat es montar un disco virtual DRBD.
que en el servidor en espera a un disco duro físico al que accede el
usuario, y luego activar el servicio Hadoop automáticamente.
IV. E XPERIMENTO Y UN NÁLISIS
Usamos 6 computadoras, donde 1 computadora está activa
namenode, 1 computadora es namenode en espera, 3 computadoras como
datanodes, y 1 usuario con especificaciones de hardware Core (TM) Intel (R)
i3 CPU@2.3GHz, 2 GB de RAM y un disco duro de 250 GB.
El software específico utilizado es CDH3, Ubuntu 10.04, DRBD, Fuse
y el latido del corazón. La primera prueba es la medición para obtener una
Combinación del tiempo de conmutación por error más rápido entre los planificados.
tiempo de inactividad y tiempo de inactividad no planificado. Combinacion de prueba
Los resultados obtenidos se conservan, el tiempo de advertencia y el tiempo muerto son los
mejor cuando se conservan 125 ms, 250 ms tiempo de aviso y tiempo muerto
1 s, es decir, 3.02 s es igual a la conmutación por error planificada y no planificada.
La tabla I muestra la combinación de ajustes de HA.CF. y Fig. 4
Muestra el cuadro comparativo planificado y el failover no planificado.
tiempo de inactividad
La segunda prueba se refiere a Feng Wang, et al [10] realizado
Para determinar el efecto del número de bloques que se almacenan.
en el datanode afecta el tiempo de failover o no. Esta prueba
utiliza una combinación de tiempo el primero de la segunda prueba basada en
Primera prueba, porque tiene el menor tiempo de inactividad. Los resultados
muestran que el número de bloques se almacenan en el datanode hace
no afecta ni al tiempo de conmutación por error cuando el tiempo de inactividad planificado
o
tiempo de inactividad no planificado.
68

Página 4
0
1
2
3
4
5
6
7
8
5000
10000
50000 100000
tim
e (s)
Número de bloque
Series1
Series2
Serie 3
0
5
10
15
20
25
30
35
1
2
3
4
5
6
7
tim
mi
(s
)
Combinación
Tiempo de inactividad planificado (s)
Tiempo de inactividad no planificado (s)
Fig. 4. Tabla comparativa Tiempo de conmutación de tiempo planificado y no planificado.
TABLA I. S ONFIGURACIÓN C OMBINATION HA.CF
Combinación Warntime
Mantener viva
Tiempo muerto
1
250 ms
125 ms
1 segundo
2
500 ms
250 ms
2 segundos
3
1 segundo
500 ms
4 segundos
4
2 segundos
1 segundo
8 segundos
5
4 segundos
2 segundos
16 segundos
6
6 segundos
3 segundos
24 segundos
7
8 segundos
4 segundos
32 segundos
El segundo experimento es conocido por la influencia de
keepalived, warntime y su deadtime. Tanto planeado como
el tiempo de inactividad no planificado alcanza igualmente 3.02 segundos. Es
Demostró que el uso de Heartbeat High Availability y DRDB.
Puede mejorar en Hadoop que tiene menos de 10 segundos de prueba
basado en Feng Wang, et al [10]. Los resultados del experimento se muestran en
Tabla II y Fig. 5.
Como tiempo de failover con DRDB y Heartbeat y metadatos.
replicación. Mientras que la Fig. 5 muestra la comparación del tiempo de conmutación por
error
con DRBD y Heartbeat en comparación con los metadatos
Replicación. Basado en el resultado, se muestra que propuso
El método ha manejado efectivamente el proceso de conmutación por error en menos de 10
s tanto para el tiempo de inactividad planificado y no planificado.
Fig. 5. Comparación de la conmutación por error de tiempo con DRBD y Heartbeat en
comparación con
Replicación de metadatos.