Cómo construir un clúster Hadoop optimizado
En este artículo, analizaremos la instalación y configuración de estos componentes: Arquitectura de red Sistema operativo Requisitos de hardware Instalación/configuración del software Hadoop
Arquitectura de red
Según la documentación que hemos podido obtener hasta ahora, podemos suponer que cuanto más cerca estén físicamente los nodos de la nube, mejor será el rendimiento. Como regla general, cuanto menor sea la latencia de la red, mejor será el rendimiento.
Para minimizar el tráfico backend, creamos una red privada virtual para la nube. Además, creamos una subred para que el servidor de aplicaciones sirva como punto de entrada a la nube.
La latencia esperada para esta red privada virtual es de aproximadamente 1-2 milisegundos. De esta manera, la distancia física ya no es un problema y deberíamos verificarlo mediante pruebas ambientales.
Arquitectura de red recomendada: conmutadores TOR (parte superior del bastidor) dedicados Utilice conmutadores o blades de conmutación de núcleo dedicados Asegúrese de que los servidores de aplicaciones estén "cerca" de Hadoop Considere la conexión Ethernet
Sistema operativo
Elegimos un sistema operativo
Elegimos utilizar un sistema operativo "cercano" a Hadoop.
Elegimos Linux como sistema operativo, que está disponible en muchas distribuciones diferentes, incluidas Ubuntu, RedHat y CentOS, entre otras. Finalmente elegimos CentOS 5.7 debido a los costos de soporte y licencia. Una buena práctica es preinstalar todo el software necesario en una imagen personalizada de CentOS para que todas las máquinas contengan el mismo software y herramientas.
Según las recomendaciones de Cloudera, se deben utilizar las siguientes configuraciones en la capa del sistema operativo: Sistema de archivos
Sistema de archivos Ext3
Eliminar Atime
No usar administración de volúmenes lógicos Usar métodos alternativos para administrar enlaces Usar sistemas de administración de configuración (Yum, Permission, sudoers, etc.) Reducir el intercambio de kernel Deshabilitar el acceso normal de los usuarios a estas máquinas en la nube No usar virtualización Al menos los siguientes comandos de Linux son requerido:
/etc/ alternativas
ln, chmod, chown, chgrp, mount, umount, kill, rm, yum, mkdir
Requisitos de hardware
Dado que solo hay dos tipos de nodos de clústeres de Hadoop (Namenode/Jobtracker y Datanode/Tasktracker), no configure más de dos o tres nodos.
Recomendaciones de hardware: Namenode/Jobtracker: 1 Gb /s Puerto Ethernet x2, 16 GB de memoria, 4 CPU, disco de 100 GB Datanode: Puerto Ethernet de 1 Gb/s x2, 8 GB de RAM, 4 CPU, varios discos, 500 GB o más de capacidad total
La configuración real del hardware puede diferir. de lo que recomendamos, dependiendo de la cantidad de datos que necesite almacenar y procesar. Sin embargo, recomendamos encarecidamente no mezclar diferentes configuraciones de hardware en el clúster para evitar que esas máquinas más débiles se conviertan en el cuello de botella del sistema. >Conocimiento del rack de Hadoop
Hadoop tiene una función "consciente del rack". Los administradores pueden definir manualmente el número de rack de cada nodo de datos esclavo. Hay dos razones: para evitar la pérdida de datos y mejorar el rendimiento de la red.
Para evitar la pérdida de datos, Hadoop copia cada bloque de datos en varias máquinas.
Imagínese lo trágico que sería si todas las copias de un bloque de datos en particular estuvieran en diferentes máquinas en el mismo rack y ese rack fallara (falla en el interruptor o corte de energía). Para evitar que esto suceda, alguien tiene que recordar las ubicaciones de todos los nodos de datos de la red y utilizar este conocimiento para determinar qué nodos son los lugares más inteligentes para colocar copias de todos los datos. Esta "persona" es el nodo de nombre.
Otro supuesto es que hay más ancho de banda y menos latencia entre máquinas en el mismo rack que entre máquinas en diferentes racks. Esto se debe a que el ancho de banda ascendente de un conmutador en rack suele ser menor que el ancho de banda descendente. Además (networkworldweixin), la latencia dentro del rack suele ser (pero no definitivamente) menor que la latencia entre racks.
La desventaja del conocimiento del rack es que necesitamos configurar manualmente el número de rack para cada nodo de datos y actualizar constantemente esta información para garantizar su exactitud. Sería bueno si el conmutador de rack pudiera proporcionar automáticamente al Namenode una lista de nodos de datos en ese rack.