Solución de HDFS HA
Fondo de HDFS HA
En versiones anteriores a Hadoop 2.0.0, SPOF se produce en el clúster HDFS. Cada clúster tiene un solo NameNode. Si el host donde se encuentra el NameNode es defectuoso, el clúster HDFS no se puede utilizar a menos que el NameNode se reinicie o se inicie en otro host. Esto afecta a la disponibilidad general de HDFS en los siguientes aspectos:
- En el caso de un evento no planificado, como la avería del host, el clúster no estará disponible hasta que se reinicie el NameNode.
- Las tareas de mantenimiento planificadas, como la actualización de software y hardware, harán que el clúster deje de funcionar.
Para resolver los problemas anteriores, la solución HDFS HA permite una copia de respaldo de NameNode de intercambio en caliente para NameNodes en un clúster en modo automático o manual (configurable). Cuando un equipo falla (debido a un fallo de hardware), el NameNode activo/en espera cambia automáticamente en poco tiempo. Cuando es necesario mantener el NameNode activo, el administrador del clúster de MRS puede realizar manualmente una conmutación NameNode activa/en espera para garantizar la disponibilidad del clúster durante el mantenimiento.
Para obtener más información sobre la migración por falla automática de HDFS, consulte
Implementación de HDFS HA
En un clúster de HA típico (como se muestra en Figura 1), dos NameNodes deben configurarse en dos servidores independientes, respectivamente. En cualquier punto de tiempo, un NameNode está en el estado activo, y el otro NameNode está en el estado de espera. El NameNode activo es responsable de todas las operaciones del cliente en el clúster, mientras que el NameNode en espera mantiene la sincronización con el nodo activo para proporcionar conmutación rápida si es necesario.
Para mantener los datos sincronizados entre sí, ambos nodos se comunican con un grupo de JournalNodes. Cuando el nodo activo modifica los metadatos de cualquier sistema de archivos, almacenará el registro de modificación en la mayoría de estos JournalNodes. Por ejemplo, si hay tres JournalNodes, entonces el registro se guardará en dos de ellos al menos. El nodo en espera supervisa los cambios de JournalNodes y sincroniza los cambios del nodo activo. Basado en el registro de modificaciones, el nodo en espera aplica los cambios a los metadatos del sistema de archivos local. Una vez que se produce una conmutación, el nodo en espera puede garantizar que su estado es el mismo que el del nodo activo. Esto asegura que los metadatos del sistema de archivos están sincronizados entre los nodos activo y en espera si la conmutación se produce por la falla del nodo activo.
Para garantizar una conmutación rápida, el nodo en espera necesita tener la información de bloque más reciente. Por lo tanto, los DataNodes envían información de bloque y mensajes de latidos a dos NameNodes al mismo tiempo.
Es vital para un clúster de HA que solo uno de los NameNodes esté activo en cualquier momento. De lo contrario, el estado del espacio de nombres se dividiría en dos partes, arriesgando la pérdida de datos u otros resultados incorrectos. Para evitar el llamado "escenario de split-brain", el JournalNodes solo permitirá que un solo NameNode le escriba datos a la vez. Durante la conmutación, el NameNode que se activará asumirá el papel de escribir datos en JournalNodes. Esto evita eficazmente que el otro NameNodes esté en el estado activo, permitiendo que el nuevo nodo activo proceda con seguridad con la conmutación.
Para obtener más información acerca de la solución HDFS HA, visite el siguiente sitio Web:
