lunes, 1 de octubre de 2012

Una forma de tolerancia a fallos, como se replica HDFS en Hadoop

En un contexto de alto volumen de procesamiento de datos, el factor limitante es la velocidad que se consume al transferir los  datos entre los nodos(ancho de banda), por consiguiente se hace necesario poder realizar medidas de este consumo en los sistema de almacenamiento distribuido como los sistemas de archivos distribuidos para definir las politicas de replicación.
Una de las formas  mas comunes es medir el ancho de banda  entre dos nodos, como una medida de la distancia para la replicación, la cual es muy difícil de hacer en la práctica, otra manera es la que utiliza  el sistemas de archivo de Hadoop, el HDFS,  que en lugar de medir el ancho de banda entre los nodos,  adopta un enfoque sencillo en el que el red se representa como un árbol donde los niveles en el árbol se describen como el centro de datos, el rack , y el nodo o equipo, y define las distancias para la ubicación de bloques  utilizando la jerarquía del árbol. Con este enfoque tipo árbol el HDFS busca  un equilibrio en la colocación del bloque y sus replicas para obtener el menor consumo de ancho de banda, el menor retardo en las trasferencias de bloques , la maxima velocidad de lectura( Utilizando el paralelismo consultando las diferentes replicas), y la mayor tolerancia a fallos por bloque.

Por consiguiente Hadoop utiliza la siguiente estrategia por defecto con base en el enfoque anterior  para la distribución de replicas, la cual proporciona al HDFS un buen equilibrio entre la disponibilidad   y el ancho de banda por transferencia, y es la siguiente; la primera réplica de un bloque se ubica en el mismo nodo donde se almacena , la segunda copia se sitúa  en un equipo o nodo que este fuera del rack de la primera replica  y la tercera réplica se dispone en el mismo rack donde se ubica la segunda replica pero en un equipo o nodo diferente. Esta estrategia es una experiencia que se deriva de los siguiente extremos que ocurren en una configuración de replicas distribuidas:
  • Cuando  toda las replicas se ubican en el mismo rack,  se disminuye el "ancho de banda"  pero aumenta la probabilidad de fallo,  además,  las operaciones de lecturas o balanceo de carga son mas lentas ante clientes concurrentes.
  •  Cuando se desea una altísima redundancia se ubica cada replica de bloque en diferentes  centros de datos. El tener este tipo de configuración aumenta el consumo de ancho de banda de manera exponencial.
El sistema HDFS  se ejecuta  en un clúster de equipos que esta disperso por varios racks y en muchos casos en diferentes  centros de datos, donde la comunicación entre nodos debe pasar en muchos casos por varios equipos activos como swiches de red, esto hace de la replicación un tema de constante afinamiento, al cual se le deben definir políticas que permitan una buena distribución y optimización  de las replicas de bloques que contiene los datos. Estas políticas a su vez se deben adaptar a los cambios de infraestructura que tiene el clúster, es por esto que HDFS tiene un sistema de comunicación donde  cada DataNode envía pulsaciones (heartbeats) periódicamente al NameNode, estas pulsaciones son mensaje con información el nombre del nodo , la cantidad de bloques que contiene. Cuando  estos mensajes se dejan de trasmitir   permite detectar la perdida de conectividad de un DataNode, con el fin de que el NameNode pueda empezar  una re-replicación de bloques.

El NameNode en  el sistema HDFS maneja un factor de replicación que el sistema  constantemente le  realiza un  seguimiento, en caso de que el factor este en su nivel mínimo para un DataNode o no se reciben mensajes de un DataNode, el HDFS  inicia una replicación adicional de los bloques que tenia este DataNode en otro  nodo DataNode, esto es con el fin de estabilizar el factor de replicación, y así mantener la disponibilidad de datos.

Aunque Hadoop es un sistema que aplica la gran mayoría de los avances en sistemas distribuidos y computación en paralelo para el manejo de grandes volúmenes de información, su desarrollo aún no esta terminado y la administración de sus metadatos son su punto de fallo más visible. 

Otros Posts:

Por José A. Cuartas M. con No comentarios

0 comentarios:

Publicar un comentario

  • Popular
  • Categorias
  • Archivo