Análisis de desempeño de arquitecturas x86-64 y ARM para ...software para construir y evaluar la...

Universidad Técnica Federico Santa María

Departamento de Informática

Magíster en Tecnologías de la Información

–––

1

Análisis de desempeño de arquitecturas x86-64 y ARM para sistemas de

archivos distribuidos, empleando Apache Hadoop (HDFS).

Rodolfo Sánchez García1

Consultor Independiente en Tecnologías de la Información

Calle 61 9-23 Bucaramanga, Colombia

[email protected]

Resumen: Este trabajo de investigación tiene por objeto demostrar que el uso de clústeres de arquitectura

ARM de tamaño reducido puede proporcionar ventajas en cuanto a menor consumo eléctrico, menor tiempo

de procesamiento, menor costo de infraestructura y menor espacio físico que un clúster de arquitectura x86,

que son comúnmente usados para tareas de procesamiento de archivos distribuidos. La propuesta de

investigación contiene una breve descripción de la plataforma Hadoop como gestor del clúster y de qué

manera puede ser implementado en estas arquitecturas. De forma muy puntual, luego de hallar el

procedimiento de implementación tanto de hardware como de software, se realizaron pruebas iterativas de

lectura de archivos y se midieron tiempos y consumo energético, que dan información suficiente para

establecer una comparación objetiva. El análisis de los resultados permitió destacar que la arquitectura x86-

64 virtualizada, es más eficiente energéticamente y en tiempo con respecto a la arquitectura ARM por la

razón que ambos espacios de cómputo propuestos para esta investigación distaban de su capacidad de

memoria disponible, pero con una inversión de infraestructura de aproximadamente tres veces más. Se

espera que este trabajo sea el inicio en la motivación del uso de esta arquitectura de bajo costo, para reducir

el consumo eléctrico y a su vez, contribuir con iniciativas como Green Computing en la reducción de la

huella de carbono en centros de cómputo.

Palabras Clave: Big Data, Apache Hadoop, HDFS, Raspberry PI.

1 Introducción

1.1 Motivación

Un estudio de noviembre del 2018 estimaba que la cantidad de datos a nivel mundial, creados, capturados o

replicados en dispositivos finales de usuario (móviles inteligentes, computadores y dispositivos para Internet

de las cosas) y en centros de datos (tradicionales y de computación en la nube), se incrementará de 33 ZB2 en

2018 a 175 ZB en 2025.

Los sistemas y metodologías de inteligencia de negocio tienen como objetivo reunir, depurar y transformar

datos, para su análisis y obtención de conocimiento, que permita dar soporte a la toma de decisiones en empresas

y corporaciones. Para realizar esto, es importante tener una infraestructura de cómputo adecuada, para poder

procesar todos los datos.

A mayor cantidad de datos y dependiendo del desempeño de la infraestructura de cómputo (tradicional o de

computación en la nube), la obtención de conocimiento se tendrá disponible en un tiempo determinado. La

1 Ingeniero de Telecomunicaciones, con 15 años de experiencia en empresas de tecnologías de la información en áreas de

operación, finanzas y soporte de infraestructura, en Colombia y Chile. 2 1 Zettabyte = 1021 Bytes



Programa de Magíster en Tecnologías de la Información

2

criticidad del negocio y el riesgo expuesto ante las decisiones tomadas dependerá si el tiempo de procesamiento

es el necesario.

Para reducir el tiempo de procesamiento y obtención de conocimiento a partir de los datos, es necesario

aumentar la capacidad de la infraestructura de cómputo, bien sea incrementando el número de servidores y

dispositivos del centro de cómputo o empleando tecnología que permita ejecutar mayor cantidad de

instrucciones por unidad de tiempo. En ambos casos, implica hacer un incremento de consumo eléctrico para

el funcionamiento de dicha infraestructura.

Según datos del banco mundial, el porcentaje de energía producida por combustibles fósiles alcanzó el 80% en

2015. Esta producción impacta en forma negativa al medio ambiente debido a las emisiones de gases de efecto

invernadero. Para contrarrestar esto, la iniciativa conocida como Green Computing, busca que se establezca

una práctica amigable con el medio ambiente para llevar a cabo procesos sustentables en tecnologías de la

información.

1.2 Problema

El incremento de los datos y la necesidad de procesamiento para obtener información requiere de equipos de

cómputo más poderosos que puedan entregar dicha información en el menor tiempo posible. El costo de menor

tiempo de procesamiento implica un mayor consumo energético de servidores y supercomputadores y poder

emplear el conocimiento obtenido por lo datos a la toma de decisiones en los negocios y empresas, sin importar

su rubro.

El aumento de consumo energético implica un mayor impacto al medio ambiente, ya que la producción de

energía a nivel mundial se hace por medio de combustible fósil. Con la incursión de minicomputadores, es

posible implementar soluciones tipo clúster con pequeños dispositivos que tienen bajo costo, bajo consumo y

alto rendimiento. El desafío es configurar e implementar esta solución teniendo en cuenta los conceptos de

HDFS3, MapReduce y YARN4 que establecen una arquitectura de software para el manejo de archivos de

grandes volúmenes de datos y su procesamiento apropiado.

En síntesis, la búsqueda de otras alternativas sustentables de computación para sistemas de archivos distribuidos

permite reducir la huella de carbono y contribuir con el concepto de Green Computing, impulsado

principalmente por la EPA5 y la EEA6.

1.3 Objetivos del trabajo

El objetivo general del desarrollo de este trabajo de investigación se describe como:

• Evaluar el desempeño de arquitecturas x86-64 y ARM para el desempeño de archivos distribuidos,

empleando Apache Hadoop (HDFS) según su tiempo de procesamiento y el consumo energético.

Los objetivos específicos que delimitan la investigación realizada son:

• Identificar los componentes de software que hacen parte de un clúster Apache Hadoop, para definir la

estructura lógica del prototipo de la arquitectura ARM.

• Proponer una estrategia de implementación de clúster Apache Hadoop empleando arquitectura ARM, como

una opción de cómputo distribuido de bajo consumo energético.

3 Hadoop Distributed File System 4 Yet Another Resource Manager 5 U.S. Environmental Protection Agency (https://www.epa.gov) 6 European Environment Agency (https://www.eea.europa.eu)

https://www.epa.gov/

https://www.eea.europa.eu/




–––

3

1.4 Hipótesis

El presente trabajo pretende realizar una comparación de consumo eléctrico y tiempo de procesamiento, para

un servicio de conteo de palabras a un archivo de gran tamaño, ejecutado desde un computador virtualizado de

arquitectura x86 y luego ejecutado desde un clúster de tres minicomputadores de arquitectura ARM7-Córtex, y

proponer esta última arquitectura como solución ante ciertos escenarios de procesamiento de grandes

volúmenes de información, empleando bajo consumo eléctrico y manteniendo un tiempo de procesamiento

aceptable. En este contexto, la hipótesis de trabajo es la siguiente:

• El uso de clúster de ordenadores de placa reducida de arquitectura ARM-Córtex, permitirá un menor

consumo de energía eléctrica y un menor tiempo de procesamiento de grandes volúmenes de

información, en comparación con arquitectura computacional x86, causando así una menor inversión

de infraestructura tecnológica y una menor inversión en costos de operación.

1.5 Metodología

La experimentación consistirá en realizar varios intentos en cada arquitectura, variando el tamaño del archivo

a analizar y midiendo el desempeño en tiempo y en consumo energético, esto con el fin de validar y comparar

la eficiencia en uso entre una arquitectura y otra.

La metodología de esta investigación ha sido estructurada por cinco fases que permitirán un acercamiento

descriptivo y escalonado para inicialmente, fundamentar la investigación a realizar y posterior a ello mostrar

los resultados y las conclusiones del trabajo realizado. Estas fases son la siguientes:

• Implementar los prototipos de arquitectura x86 y ARM, configurando Apache Hadoop y validando su

funcionamiento.

• Tomar las variables de la hipótesis e implementar las pruebas que serán validadas para cada arquitectura.

• Efectuar y documentar las pruebas para cada arquitectura, revisando que la obtención de mediciones sea

muestras válidas para cada una de ellas.

• Reconstruir y documentar las pruebas consideradas como fallidas y validar nuevamente que esté en los

valores normales de la medición.

• Construir un cuadro comparativo con las mediciones y obtener los aspectos más destacados de cada medición

para validar la hipótesis.

1.6 Organización del informe

El presente informe está estructurado de la siguiente manera:

Capítulo 2. En este capítulo se presenta el marco conceptual y teórico que encierra la temática de la

investigación y que dará al lector la posibilidad de ubicarse en el entorno del desarrollo, que fundamenta la

solución propuesta.

Capítulo 3. En este capítulo se presenta en forma detallada cómo se prepararon los recursos de hardware y de

software para construir y evaluar la solución propuesta, previo a la etapa de pruebas que permitieron validar la

hipótesis de esta investigación.

Capítulo 4. En este capítulo se describen los resultados de las pruebas efectuadas que entregarán información

necesaria a la evaluación y validación de la propuesta de solución de esta investigación.

7 Advanced RISC Machines




4

Capítulo 5. En este capítulo se presenta al lector las conclusiones obtenidas a partir de los datos recopilados en

los resultados de las pruebas y se adicionan los subcapítulos de lecciones aprendidas y de trabajo futuro como

complemento a la propuesta de investigación aquí presentada.

2 Marco teórico referencial

2.1 Big Data

Según el ciclo de conferencias Strata del año 2013, el concepto de Big Data8 hace referencia a aquellos datos

que exceden la capacidad de procesamiento de las bases de datos convencionales, es decir, al volumen de datos

que ocupan grandes cantidades de gigabytes, cuyos datos de entrada fluyen a un ritmo masivo y continuo, y que

no se ajustan a los controles de diseño de las arquitecturas de bases de datos tradicionales. Para poder obtener

valor agregado de estos datos, se debe seleccionar una forma alternativa de cómo procesarlos.

Para el autor Mike Loukides [4], una definición más coloquial para Big Data es cuando el tamaño de los datos

en sí comienza a ser parte del problema. Aquí, se refiere a la forma como los almacenes de datos comienzan a

incrementar su tamaño por diversas entradas de datos. Los casos más comunes son por ejemplo para compañías

petroleras, de telecomunicaciones, entre otros, su actividad depende de tener amplios almacenes de datos por

un tiempo prolongado.

Por otra parte, para el autor Edd Dumbill [2], en el año 2012, el Big Data se convirtió en la tendencia en

tecnologías de la información. Hasta hoy, esta tendencia ha pasado a ser ampliamente relevante debido a que

los enfoques de costo-beneficio han permitido controlar el volumen, la velocidad y la variabilidad de estos datos

masivos. Además, dentro de estos datos yacen valiosos patrones e información, aunque para obtenerlos hay que

desarrollar un gran trabajo computacional.

Allí el autor aclara además que, para grandes compañías de tecnología, este poder ha estado a su alcance por un

buen tiempo a un costo razonable. Para el hardware disponible de hoy, las arquitecturas de nube computacional

y el software disponible de tipo open source puede procesar grandes volúmenes de datos a un bajo costo.

Incluso, es tan práctico que, hasta un simple startup de garaje, puede fácilmente alquilar tiempo de servidor en

la nube.

El documento además apunta que el valor del Big Data para una organización cae en dos categorías: como uso

analítico y posibilitando la creación de productos nuevos. La analítica de Big Data permite revelar información

oculta proveniente de datos que son difíciles de procesar en forma tradicional; por ejemplo, aplicando analítica

de datos podemos predecir la inclinación y preferencia de compra de productos de los clientes, a partir del

análisis de transacciones de clientes, junto con sus datos de tendencia social y su ubicación geográfica y

responder al cliente con un nuevo producto que se ajuste a sus necesidades.

Si se es capaz de procesar múltiples variables de los datos en un tiempo razonable, evitaremos la complicada

necesidad de realizar una investigación de mercados, por medio de una tradicional encuesta para obtener datos,

en contraste con la simpleza de ejecutar un par de reportes predeterminados para obtener un análisis requerido,

de un set de datos considerablemente grande.

2.2 Green Computing

Es una iniciativa mundial que apunta a emplear métodos eficientes para el uso de recursos computacionales,

minimizando el impacto ambiental, comúnmente medido como “huella de carbono”. La huella de carbono se

8 También conocidos como macrodatos, datos masivos, grandes volúmenes de datos o datos a gran escala, en español.




–––

5

define como un indicador ambiental que busca mostrar la cantidad de gases de efecto invernadero emitidos

directa o indirectamente por una persona, una organización o un producto específico.

Alguno de los métodos empleados para minimizar esta huella de carbono y proveer eficiencia en el uso de

recursos computacionales, son la computación en la nube, la computación en malla, la virtualización en centros

de datos y el teletrabajo.

En algunos centros de cómputo como los de la compañía Google, han sido diseñados para consumir la mitad

de energía eléctrica que un centro de datos común. En mediciones de energía, cada consulta que realiza un

usuario en el buscador consume 0,0003 kWh de energía o el equivalente de 0,2 gramos de CO2 o dióxido de

carbono. Para efectos de referencia, un kilómetro recorrido por un automóvil de combustión a gasolina9 produce

alrededor de 70 kilogramos de CO2 al año.

2.3 Apache Hadoop

Apache Hadoop es un marco de referencia que permite el procesamiento distribuido de grandes volúmenes de

datos empleando clúster de computadores, usando modelos de programación como MapReduce. Este software

está diseñado para aumentar proporcionalmente el trabajo de cómputo, desde un servidor local hasta miles de

máquinas interconectadas, cada una ofreciendo su desempeño y almacenamiento de cómputo propio. El

software además ofrece una alta disponibilidad de los recursos de hardware, gestionando propiamente fallos en

la capa de aplicación.

El soporte de computación paralela es provisto por MapReduce, que como se mencionó anteriormente es un

modelo de programación para procesamiento distribuido de datos. Para el caso de Hadoop, este puede ejecutar

MapReduce escrito en diferentes lenguajes de programación. MapReduce trabaja separando el procesamiento

de datos en dos fases: la fase de búsqueda (conocida en inglés como map) y la fase de reducción (conocida en

inglés como reduce). Cada fase tiene una tupla compuesta por llave-valor como entrada y salida, que pueden

ser configurados según las características de los datos y el requerimiento del cómputo a realizar.

Para la configuración de especificaciones de Hadoop, es importante tener en cuenta las características físicas

del clúster (velocidad de procesamiento, almacenamiento, memoria disponible), la configuración lógica del

clúster, la configuración del Sistema Distribuido de Archivos de Hadoop (HDFS10) y el administrador de

recursos (YARN11).

El sistema distribuido de archivos de Hadoop es un sistema de gestión de archivos diseñado para almacenar

archivos de gran volumen por medio de un patrón de acceso de datos, que se ejecutan en el clúster. Este sistema

de archivos, opera con dos tipos de nodos siguiendo el patrón de maestro-esclavo. Se denomina namenode, al

nodo maestro, quien es el encargado de gestionar qué actividades está desarrollando cada nodo esclavo; por

otra parte, se denomina datanode, al nodo esclavo, de los cuales existen varios de ellos quienes ejecutarán las

actividades y tareas.

Por otra parte, el administrador de los recursos del clúster provee la interfaz de programación de aplicaciones

(API) para solicitar y trabajar con las características y recursos del clúster, para así soportar a otros marcos de

referencia de computación distribuida (como Spark, MapReduce, entre otros).

9 https://www.terra.org/calc/ 10 HDFS – Hadoop Distributed File System 11 YARN – Yet Another Resource Negotiator

https://www.terra.org/calc/




6

2.4 Arquitectura ARM

La arquitectura ARM es una arquitectura RISC12 desarrollada por Advanced RISC Machines, fundada en

noviembre de 1990. Inicialmente, en 1983 la compañía se denominó Acorn Computers y liberaría en 1987 el

primer computador para el hogar basado en RISC. Años más tarde, a finales de los años 80 se asociaría con

Apple Computer y VLSI Technologies para el desarrollo de nuevas generaciones de procesadores para Apple;

éste lo incluyó para la construcción del Apple Newton en 1991.

Entre 1993 y 1994 existió una fuerte competencia por parte de otras compañías de microprocesadores tales

como Texas Instruments, Samsung, Digital Equipment Corporation y Sharp, que formalizaron al igual que

ARM el licenciamiento de sus productos. En principio, esto causó confusión en el desarrollo de productos

existente en cada compañía, pero al final ARM pudo consolidarse exitosamente debido a las oportunidades de

mejoramiento y desarrollo de una tecnología RISC de menor tamaño, de mejor tiempo de respuesta y a la

creación de un nuevo producto personalizado de 16 bits por conjunto de instrucciones que reduciría la demanda

de memoria.

Esto se demuestra ante el acuerdo con Nokia en 1994 para formar parte del proyecto del primer teléfono GSM,

con un masivo éxito. Desde ese año, la compañía ha producido hasta el 2015 más de 10 mil millones de chips

ARM y ha sido usado por más de 165 licencias.

Actualmente, ARM sigue con el desarrollo de tecnologías de herramientas de software, tarjetas electrónicas,

arquitecturas de bus de comunicaciones, periféricos, que son empleados en aplicaciones como medidores de

consumo de servicios, detectores de incendios, máquinas de ejercicios, gestión eficiente de dispositivos

electrónicos, computadores, televisores inteligentes, smartphones, módems, entre otros dispositivos de tamaño

reducido.

2.5 Raspberry PI

Es un dispositivo de placa simple de arquitectura RISC, construido y comercializado por la Fundación

Raspberry Pi. Esta fundación es una institución de caridad localizada en el Reino Unido, creada en 2009. Su

principal objetivo en sus inicios era ayudar a los jóvenes a descubrir y motivarse por los computadores, a un

bajo costo para resolver el principal problema de las escuelas en la adquisición de equipos a costos elevados.

En 2011, el equipo de desarrollo ya tenía un primer prototipo del que se produjeron 20 unidades. Una vez que

el dispositivo superó las pruebas de funcionamiento, en febrero de 2012 salió a la venta la Raspberry Pi 1

Modelo B, consiguiendo más de 100.000 órdenes de compra en su día de lanzamiento. Durante el año 2018, la

fundación registró ingresos por ventas por más de 27 millones de libras esterlinas y un capital neto de 25

millones.

12 RISC, del inglés Reduced Instruction Set Computer, Computador con Conjunto Reducido de Instrucciones.




–––

7

Para el caso de esta investigación se decidió trabajar con el

dispositivo Raspberry PI 3B/3B+, el cual es una de las últimas

versiones disponibles de esta arquitectura y con mayor

disponibilidad en el mercado, a octubre de 2019 (ver Figura

1).

La placa (como también se le conoce) Raspberry PI 3B/3B+

fue puesta a disposición del público en febrero del 2016, tiene

un tamaño de 85 milímetros de ancho y 56 milímetros de

largo. Este tamaño le permite ser parte de aplicaciones

portátiles o que requieran gran capacidad de procesamiento

con una mínima presencia de hardware. Normalmente, al

dispositivo se le adapta un teclado, un mouse y conectividad a

un monitor por medio de cable HDMI para ser operado. Esta configuración puede ser reemplazada si se

configura un servidor remoto por medio de protocolo SSH (línea de comandos) o con aplicaciones como VNC

Connect (interface gráfica).

Una vez se enciende el dispositivo, éste solicita autenticación con usuario y contraseña, que por defecto es pi

y raspberry. Cuenta con un menú inicial para configuración por medio del comando raspi-config.

3 Conceptualización de la solución

3.1 Infraestructura de hardware para cada arquitectura

Inicialmente, la solución propuesta se basa en comparar dos infraestructuras de hardware que permitan validar

su consumo eléctrico ante la ejecución de tareas sobre archivos de diferentes tamaños. Con esta comparación

se analizarán las variables de tiempo, tamaño del archivo analizado y el consumo durante el tiempo de ejecución.

3.1.1 Infraestructura de arquitectura ARM

La primera infraestructura se basa en un clúster de dispositivos de arquitectura ARM, conocidos

comercialmente como Raspberry PI 3B. Las características de estos dispositivos de hardware pueden verse en

detalle en la Tabla 1.

Tabla 1. Especificaciones de hardware Raspberry PI 3B

Característica Descripción

Sistema de Chip Broadcom BCM2837

CPU 4 cores ARM Cortex-A53 (ARMv8-A) 64-bit @1.2 GHz

GPU Broadcom VideoCore IV – 400MHz

RAM 1GB LPDDR2 (900 MHz)

Conectividad 10/100 Ethernet, 2.4 GHz 802.11n inalámbrica

Bluetooth Bluetooth 4.0 Classic, Bluetooth de bajo consumo

Storage MicroSD

GPIO 40-pines

Puertos HDMI, 3.5mm conector analógico audio-video, 4 puertos USB 2.0, Ethernet,

Camera Serial Interface (CSI), Display Serial Interface (DSI)

Alimentación 5 VDC a 2A

Figura 1. Raspberry PI 3B




8

Para el caso de este proyecto, el clúster está conformado por tres dispositivos Raspberry PI y la conectividad se

logra por medio de conexión inalámbrica.

3.1.2 Infraestructura de arquitectura x86-64

La segunda infraestructura se basa en un clúster de dispositivos con arquitectura x86-64. Estos equipos son:

Tabla 2. Especificaciones de hardware equipos desktop

Característica Descripción

Fabricante Hewlett Packard – HP Compaq dc5800 SFF

Sistema de Chip Intel

CPU 4 cores Intel Core 2 Duo 32-bit @ 2.4 GHz

GPU AMD Graphics

RAM 2 GB

Conectividad 10/100 Ethernet

Storage 250 GB HDD

Puertos 3.5mm conector analógico entrada y salida de audio, salida VGA video, puerto

serial teclado y mouse, 6 puertos USB 2.0, Ethernet.

Alimentación 110-220 VAC a 5A a 50-60 Hz

Para el caso de este proyecto, el clúster está conformado por tres máquinas virtuales, implementadas con un

software de virtualización open source.

3.2 Estructura lógica para cada arquitectura

Para la construcción de la estructura lógica de cada arquitectura, se tiene contemplado tener tres dispositivos

por clúster de cada una de ellas.

Para el caso de la arquitectura ARM, se realizará el montaje físico y la conectividad será inalámbrica para

facilidad de movilidad de los equipos. Por otra parte, para la arquitectura x86-64, el montaje será por medio de

virtualización y cada equipo estará conectado por medio de la opción NAT.

Actualmente, existen varios sitios web como Linode13, Cloudera14, DigitalOcean15, entre otros, que dentro del

soporte que ofrecen a los servicios de alquiler de espacio en la nube, también cuentan con instructivos para la

implementación y configuración de Apache Hadoop, según la versión, el alcance y la aplicación que se desee

implementar. Dentro de los sitios revisados y junto con la literatura expuesta en las referencias de este

documento, se presenta de forma ordenada cómo hacer la configuración de cada clúster y para posterior a ello

validar su desempeño.

Basado en lo anterior, se describen cada uno de los pasos para construir la estructura lógica que permitirá

configurar cada clúster. Esta descripción es la misma para cada arquitectura, salvo ciertas especificidades que

se mencionarán en caso de requerirlo.

13 https://www.linode.com 14 https://www.cloudera.com 15 https://www.digitalocean.com

https://www.linode.com/

https://www.cloudera.com/

https://www.digitalocean.com/




–––

9

3.2.1 Instalación y configuración del sistema operativo

Las distribuciones de Linux que deben ser instaladas en cada arquitectura son Raspbian Buster16 para los

dispositivos Raspberry PI y Ubuntu 16.0.4 LTS para las máquinas virtuales. Luego de la instalación, se debe

configurar en cada dispositivo la distribución del teclado, información de red inalámbrica para la conectividad

y habilitar el protocolo SSH para conexión remota para el caso de las Raspberry.

El aspecto más importante en materia de seguridad del clúster está en configurar el usuario hadoop. Este usuario

tendrá privilegios de administrador y es quien establecerá la comunicación entre los nodos. Se debe hacer la

creación de este usuario y acceder al sistema empleando las credenciales respectivas.

Una vez realizado el acceso, se deben actualizar los paquetes de software del sistema operativo en cada

arquitectura, haciendo uso de los comandos upgrade y update desde la línea de comandos. Esto permite

que cada nodo tenga las mismas características de sistema operativo. Como ya hemos mencionado, el clúster

de esta solución propuesta está conformado por un nodo principal y por dos nodos esclavos.

3.2.2 Configuración básica en cada nodo

Cada nodo debe tener una dirección IP (en inglés, ip address) y un nombre de equipo (en inglés, hostname).

Como notación, el nodo principal se nombra master y los nodos esclavos se nombran como slave01 y

slave02. Este nombre se modifica, editando el archivo hostname para cada nodo.

Las direcciones IP de los nodos son asignadas por DHCP del access point al cual están conectados

inalámbricamente para las Raspberry o por el software de virtualización para las máquinas virtuales. Para

obtener esta información se usa el comando ifconfig desde la línea de comandos, para cada nodo.

Cada nodo debe tener la información de los equipos del clúster, incluyendo su propia información. Esto se hace

editando el archivo hosts de cada nodo, escribiendo en la misma línea la dirección IP y el nombre de equipo.

Se debe instalar además en cada nodo la versión 8 de Java JDK, ya que es el paquete que actualmente soporta

Apache Hadoop 3.1.2, usado en este desarrollo17.

Finalmente, se instala el paquete openssh-server en cada nodo para el soporte de comunicación y seguridad

entre nodos del clúster.

3.2.3 Configuración del sistema de autenticación

Para la comunicación de los dispositivos en forma transparente y segura, una vez se instala el openssh-server,

se debe crear las llaves privadas y públicas para la autenticación del nodo principal, y compartir esta

información con los nodos esclavos.

3.2.4 Instalación de Apache Hadoop

En el nodo principal, se hace la descarga y descompresión de Apache Hadoop. Como una segunda parte, se

debe realizar la configuración del directorio de Hadoop como una variable de entorno, agregando la ruta al

PATH del sistema operativo. También se configura la variable de entorno JAVA_HOME con la ubicación del

JRE activo en el sistema operativo.

16 Se puede obtener de https://www.raspberrypi.org/downloads/raspbian/ 17 Compatibilidad actual a octubre 2019 https://cwiki.apache.org/confluence/display/HADOOP/Hadoop+Java+Versions

https://www.raspberrypi.org/downloads/raspbian/

https://cwiki.apache.org/confluence/display/HADOOP/Hadoop+Java+Versions




10

3.2.5 Configuración del sistema Hadoop

La configuración de Hadoop se inicia con incluir la ruta JAVA_HOME como una variable de entorno dentro del

archivo hadoop-env.sh. Esto se hace para indicarle a Hadoop dónde ubicar los recursos del JDK al

momento de establecer la conectividad entre nodos y para realizar la ejecución de tareas de MapReduce.

Luego, para indicar la ubicación y roles del nodo principal y de los nodos esclavos del clúster, se realiza la

edición de archivos XML core-site, hdfs-site, mapred-site y yarn-site, indicando la rutas a

las carpetas y archivos dentro del entorno Hadoop, número de replicaciones que tendrá el clúster, dónde quedará

establecido el entorno HDFS y la ubicación del sistema de gestión del clúster YARN , que se configura para

proporcionar información sobre el framework a utilizar para MapReduce.

También en este paso, se configuran los nombres de los nodos esclavos dentro del archivo workers, haciendo

referencia a ellos con el hostname asignado anteriormente.

3.2.6 Configuración de memoria disponible del clúster

Una última configuración, es asignar los recursos de cada dispositivo o máquina virtual en los archivos XML

yarn-site y mapred-site. Esta información dependerá exclusivamente de la memoria RAM disponible

y el número de cores de cada nodo.

3.2.7 Replicación de Hadoop en los nodos esclavos

Ya teniendo la configuración del clúster, se procede con la instalación de Apache Hadoop en cada nodo esclavo

y desde el nodo principal, se hace la copia de los archivos de configuración XML mencionados anteriormente

dentro de la carpeta hadoop del usuario hadoop.

3.3 Diseño de pruebas para cada arquitectura

Los clústeres configurados previamente tienen incluido en su sistema de archivos de Hadoop, un algoritmo

implementado en Java que permite hacer conteo de palabras de archivos de texto plano. Un repositorio de texto

plano muy usado para aplicaciones de NLP18 es conocido como el proyecto Gutenberg19. Este repositorio cuenta

con una biblioteca de más de 60.000 libros de acceso gratuito, principalmente en inglés y con variedad de

idiomas como portugués, alemán y francés.

Dentro de este repositorio, se han agrupado diferentes archivos de texto en carpetas que sumen tamaños de 10,

50, 100, 150 y 200 MB, los cuales serán analizados por cada uno de los clústers. Cada grupo de archivos poseen

32, 122, 231, 335 y 451archivos respectivamente.

Para validar el tiempo de procesamiento de cada clúster, cada grupo de archivos será analizado 10 veces por

cada clúster. Esto permitirá determinar un valor promedio y, por ende, un consumo energético promedio. Al

final, se analizará la duración y consumo por tamaño de archivos al que cada clúster debe realizar el conteo de

palabras.

18 Neuro-Linguistic Programming, Programación Neuro-Lingüística. 19 http://www.gutenberg.org

http://www.gutenberg.org/




–––

11

4 Resultados

4.1 Resultados por arquitectura

Una vez culminadas las pruebas se

recogieron las siguientes gráficas que

muestran el desempeño individual para

cada arquitectura y el desempeño

comparativo entre ellas mismas, teniendo

en cuenta los tiempos de procesamiento

promedio y el consumo de energía

promedio por volumen de información.

En la figura 2, se muestra el tiempo (en

segundos) de análisis de los archivos

mencionados, durante los 10 experimentos

para la arquitectura x86-64.

Para este caso, la arquitectura x86-64 muestra

un comportamiento uniforme para los volúmenes de 50 MB y 150 MB, cuyas desviaciones estándares son las

más bajas (3,4 segundos y 5,5 segundos). Mientras que el volumen de 200 MB presenta la desviación estándar

mayor de todos los experimentos (11,8 segundos).


segundos) de análisis de los archivos

mencionados, durante los 10 experimentos

para la arquitectura ARM.

Mientras que para la arquitectura ARM, la

gráfica muestra un comportamiento

medianamente uniforme para los volúmenes

de 10 MB y 50 MB, cuyas desviaciones

estándares son las más bajas (26,5 segundos

y 82,4 segundos). Para los otros casos se

tienen desviaciones estándares altas y en

aumento (192,6 segundos, 226 segundos y

541 segundos, respectivamente).

Figura 2. Tiempos de experimentos para arquitectura x86-64.

Figura 3. Tiempos de experimentos para arquitectura ARM.




12


segundos) de análisis promedio de los

archivos mencionados, para ambas

arquitecturas.

Para este caso, la tendencia es que con el

clúster de arquitectura x86-64 el tiempo es

mucho más bajo que con la arquitectura

ARM.

En la figura 5, se muestra el consumo

promedio de energía (en kWh) para el

análisis de los archivos mencionados, para

ambas arquitecturas, según el volumen de

archivos a analizar.

Figura 5. Comparación de consumo promedio de energía por experimento para ambas arquitecturas.

La tendencia en este caso es que ambos presentan un incremento proporcional en consumo eléctrico a medida

que aumenta el volumen de los datos a analizar. Sin embargo, sigue siendo notorio que los dispositivos ARM

tienen mayor consumo.

4.2 Cuadro comparativo y aspectos más destacados

Un resumen de los resultados relevantes obtenidos anteriormente se presenta en la tabla 3.

Tabla 3. Comparación de desempeño entre arquitecturas

Criterio Arquitectura x86-64 Arquitectura ARM

Capacidad Total 6 GB 3 GB

Tiempo promedio para archivos 10 MB 1 minuto 14 segundos 6 minutos 21 segundos

Tiempo promedio para archivos 50 MB 4 minutos 14 segundos 18 minutos 6 segundos



Tiempo promedio para archivos 200 MB 15 minutos 28 segundos 1 hora 16 minutos 3 segundos

Figura 4. Comparación de tiempo promedio por volumen de

datos para ambas arquitecturas.




–––

13

A pesar de las pruebas y al observar que estos resultados no ayudan en la validación de la hipótesis, se puede

resaltar lo siguiente:

• A medida que el volumen de datos se incrementa para ambas tecnologías, el tiempo de procesamiento

aumenta al mantener el mismo esquema de clúster (un maestro y dos esclavos).

• Para la arquitectura ARM, se evidencia que el tiempo de análisis en comparación con la arquitectura x86-

64 es ineficiente, debido a que en promedio se multiplica por un factor de cinco en cada iteración.

• Durante el desarrollo de las pruebas se evidenció que a medida que se incrementaba en la cantidad de datos

a analizar en la arquitectura ARM, el clúster producía mayor número de descarte de contenedores,

contabilizados por el sistema como contenedores fallidos (fails) o contenedores cancelados (killed). Esto

obedece por la capacidad reducida en RAM entre arquitecturas (3 GB en el clúster ARM contra 6 GB en

el clúster x86-64) y la imposibilidad del sistema de asignar trabajo a un contenedor si no tiene un mínimo

de memoria para su procesamiento. Cada vez que hay un contenedor fallido, el sistema debe esperar a

reunir los recursos necesarios para la asignación y esto suma tiempo al procesamiento total.

• El análisis anterior explica también el porqué de los valores irregulares y el alto valor de desviación

estándar en cada experimento en el clúster de arquitectura ARM.

• Para la arquitectura x86-64 resulta más eficiente el manejo de consumo eléctrico en comparación con la

arquitectura ARM. Sin embargo, se quiere mencionar que en el desarrollo de este trabajo se indicó que la

construcción del clúster de arquitectura x86-64 sería mediante un entorno virtualizado, limitando el

consumo eléctrico de las tres máquinas virtuales (menos de 45 watts en total del clúster) a un valor muy

por debajo que una estación de trabajo (entre 45 y 60 watts por nodo, sin contar periféricos de entrada y

salida) de las características mencionadas de hardware detalladas inicialmente.

• En cuanto a costos de infraestructura, el clúster de arquitectura ARM tiene un costo aproximado de 150

USD, mientras que un el clúster x86-64 con características similares a las presentadas en este trabajo, de

máquinas sin virtualizar, tiene un costo de 450 USD; además, las capacidades entre ellos difieren de 3 GB.

Con esto se puede inferir, que al aumentar la capacidad del clúster ARM en dos veces más, puede igualar

el presupuesto, pero se incrementaría la capacidad de memoria a 9 GB. Con este hipotético aumento de

capacidad se podría pensar en un aumento en el desempeño del clúster ARM.

5 Conclusiones

La hipótesis del trabajo proponía en que el uso de clúster de ordenadores de placa reducida de arquitectura

ARM, permitiría un menor consumo de energía eléctrica y un menor tiempo de procesamiento de grandes

volúmenes de información, en comparación con arquitectura computacional x86, causando así una menor

inversión de infraestructura tecnológica y una menor inversión en costos de operación. En el análisis y

comparación de las arquitecturas implementadas, esta hipótesis no se cumple debido a que el clúster de

arquitectura ARM luego de las pruebas realizadas consume más energía y analiza los archivos en un mayor

tiempo en comparación con la arquitectura x86-64.

Sin embargo, se debe tener en cuenta que a pesar de que el número de dispositivos por arquitectura era el mismo,

la capacidad del clúster era mayor para la arquitectura x86. Además, como se mencionó en el capítulo anterior

el costo de infraestructura sí es menor para la arquitectura ARM, hasta tal punto de poder ampliar la capacidad

del clúster con un presupuesto inferior de la arquitectura x86-64.

Un análisis más profundo sobre estas conclusiones se detalla en el siguiente subcapítulo.




14

5.1 Inconvenientes presentados

A continuación, se resumen los inconvenientes presentados durante el desarrollo del trabajo de investigación:

• Durante la etapa temprana en el armado del clúster de arquitectura ARM, se tomó más tiempo del previsto

para la selección del sistema operativo, debido a que se probaron alrededor de 6 distribuciones diferentes

de Linux y no había la posibilidad de desarrollar un único procedimiento para la implementación del clúster

que fuese único a todos por el tipo de distribución, las características y prestaciones de hardware, entre

otros.

• En complemento con el ítem anterior, la distribución de Hadoop de 32 y 64 bits presenta mensajes de

advertencia y errores al ser implementado en la arquitectura ARM, debido a la naturaleza de los archivos

fuente de Hadoop compilados en 32 bit (binary files). El instructivo presentado en los anexos muestra cuál

fue la configuración usada y probada que ya no presenta este problema mencionado.

• Durante la ejecución de las pruebas, dos nodos del clúster ARM sufrieron fallos eléctricos y debieron ser

reemplazados, ya que se habían completado más de 16 horas de pruebas continuas en encontrar la

configuración más estable. Se presume que el daño tiene que ver con tiempo extendido de trabajo,

sobrecarga eléctrica y aumento de temperatura del hardware.

• Las pruebas en el clúster ARM debieron efectuarse varias veces debido a fallos en la ejecución que

obedecen a la poca capacidad y a la configuración de los parámetros en el administrador de recursos de

memoria. Esto llevó un mes adicional para encontrar los valores adecuados y que permitieran realizar

pruebas con muestras válidas.

5.2 Lecciones aprendidas

Luego del desarrollo del trabajo, se puede encontrar como enseñanza lo siguiente:

• Aún existe suficiente literatura para aprender sobre el funcionamiento de los sistemas clúster sin importar

su naturaleza o arquitectura de implementación. No solamente Hadoop permite la administración de este

tipo de estructuras, sino que también hay otros entornos que pueden aprovechar mejor las prestaciones de

hardware de estos sistemas como Spark, Hive, Pig, entre otros. Se implementó Hadoop por ser el más

básico de todos.

• Basado en la experiencia de trabajo en empresas de tecnologías de la información, cada cierto periodo se

da de baja numerosos equipos de cómputo como chatarra por desactualización que pudiesen ser

aprovechados en la implementación de clústers para tareas específicas dentro del importante campo de la

analítica de datos y el manejo de grandes volúmenes de datos.

• El impacto del trabajo realizado permite dejar más preguntas que respuestas, ya que si bien no se pudo

validar que este conjunto de tres dispositivos de arquitectura ARM pudiera ser más eficiente en tiempo que

uno de arquitectura x86-64, sí se deja en evidencia que en cuanto al consumo energético está muy por

debajo del consumo de un clúster armado con equipos de escritorio. Se considera como una buena

oportunidad ampliar la cantidad de los nodos del clúster de arquitectura ARM y validar el rendimiento en

tiempo de los dos sistemas.

• Una de las ventajas notorias en términos de eficiencia, está dada en la alta densidad de procesamiento de

la arquitectura ARM en cuanto al tamaño que puede ocupar este tipo de arreglos de infraestructura.




–––

15

5.3 Trabajo futuro

El trabajo de los clústers construidos a partir de computadores de placa reducida, ha permitido a startups como

BitScope20, PicoCluster21, entre otras, ofrecer hardware a partir de la construcción de estos supercomputadores

bajo la premisa de alta densidad (mayor procesamiento, en espacio reducido), bajo costo, bajo consumo

eléctrico y bajo requerimiento de refrigeración. Incluso, en ciertos casos al ser comparados con el costo que

implica adquirir un servicio cloud en cuanto a accesos, transacciones, alquiler mensual, entre otros, resulta

mucho más económico poseer la infraestructura de este tipo de clúster en sitio.

Sin embargo, la complejidad en la construcción, conectividad y recursos disponibles hace que éstos sean de

difícil mantenimiento, están sujetos a fallos de hardware por la cantidad de partes del sistema y su costo sea

únicamente apropiado para grandes compañías.

Los resultados y conclusiones arrojados por esta investigación motivan a continuar con la comparación en

tiempo de procesamiento y consumo de energía, pero ahora considerando un número mayor de nodos en el

clúster e incluyendo la medición de tiempos de respuesta a requerimientos, que permita ser una solución de

apoyo a empresas de menor tamaño, en cuanto a inversión tecnológica. Vale la pena resaltar que, en Colombia

para el año 2017, las pequeñas y medianas empresas representaban el 90% del sector productivo nacional, eran

responsables del 35% del producto interno bruto y generaban el 80% del empleo en el país22.

Actualmente, en la universidad donde laboro un grupo de estudiantes liderados por mi gestión de docente de

semillero de investigación, pasaron un proyecto de investigación para ser desarrollado durante 10 meses en el

año 2020, con un rubro máximo de 1,500 dólares para la implementación de un clúster compuesto por 10

dispositivos de arquitectura ARM que permita el uso en actividades de procesamiento de archivos distribuidos,

simulación de algoritmos de codificación de datos y medios de transmisión y solución de algoritmos

matemáticos aplicados para análisis de datos.

Referencias

[1] White, T., "Hadoop The definitive guide", O'Reilly Media Inc., 2015, ISBN: 978-1-491-90163-2.

[2] Dumbill, E., "Big Data Now: 2012 Edition", O'Reilly Media Inc., 2012, pp. 3-17, ISBN: 978-1-449-35671-2.

[3] Dumbill, E., "Planning for Big Data", O'Reilly Media Inc., 2012, pp. pp. 17-21, ISBN: 978-1-449-32967-9.

[4] Loukides, M., "What is Data Science?", O'Reilly Media Inc., 2011, ISBN: 978-1-491-91186-0.

[5] Miner, D., "Hadoop: What you need to know", O'Reilly Media Inc., 2016, ISBN: 978-1-491-93730-3.

20 http://cluster.bitscope.com 21 https://www.picocluster.com 22 Tomado de la revista Dinero https://bit.ly/2rSr9Ke

http://cluster.bitscope.com/

https://www.picocluster.com/

https://bit.ly/2rSr9Ke




16

Anexo 1: Configuración del clúster de arquitectura x86-64

La siguiente configuración se realizó en una máquina virtual con las siguientes características:

• Sistema Operativo Ubuntu 16.0.4 LTS

• Máquina virtual con dos procesadores, disco duro de 20 GB, almacenado en múltiples archivos y memoria

RAM de 2 GB.

Se deben tener tres máquinas idénticas a esta configuración. Por el momento los parámetros de usuario y

hostname no importan ya que el siguiente instructivo mostrará como configurar todo lo que se requiere para su

funcionamiento.

Es importante realizar la siguiente configuración básica para todos los nodos. En este caso se mostrará como

configurar los nodos: un nodo maestro y dos nodos esclavos.

La información contenida a continuación es recopilación de foros, información de portales de servicios cloud,

blogs y contribuciones de la comunidad entusiasta de Hadoop. Entre otras cosas, lo que se realizó fue pruebas

de la configuración, modificaciones entre varias opciones de configuración y este es el resultado de la

personalización que funcionó y se validó en la infraestructura.

Creación Usuario Hadoop

Inicialmente, se debe crear un usuario que permitirá la conexión entre dispositivos. Para esto, se creará un

usuario Hadoop que tendrá privilegios de administrador. Por lo tanto, desde una ventana de terminal o línea de

comandos en Linux se escribe:

$ sudo -i

# sudo adduser hadoop

# usermod -aG sudo hadoop

# exit

$

Cambiar nombre de host

Luego de la creación del usuario, se modificará el nombre de la máquina virtual. Este nombre o hostname

permitirá asociar con el nombre al dispositivo en el clúster.

$ sudo nano /etc/hostname

Al abrirse el entorno de edición, se borra cualquier nombre que esté en el espacio de trabajo y se reemplazará

por master. Para guardar cambios, se presiona simultáneamente la tecla Ctrl y la tecla de la letra O.

Con Enter, aceptamos los cambios realizados.

Para salir del entorno de edición, se presiona simultáneamente la tecla Ctrl y la tecla de la letra X.

Una vez creado el usuario hadoop, procedemos a reiniciar la máquina virtual y hacer login con el usuario

hadoop.




–––

17

Configuración de red

También es necesario fijar la dirección IP de cada máquina virtual. Como se mencionó en el documento, en el

entorno de virtualización se asigna automáticamente por DCHP, pero es importante fijar la dirección IP para

evitar que se asigne otra dirección luego de algún reinicio del entorno de virtualización.

Para saber qué dirección IP tiene la máquina virtual y cuál es el segmento que asigna el entorno de

virtualización, se usa el comando ifconfig. Este permite ver el nombre de la interfaz, dirección IP asignada,

puerta de enlace, entre otros valores importantes.

Como el entorno virtualizado está empleando emulación de una conexión tipo Ethernet, se usa entonces la

interface eth0 de cada máquina virtual.

$ sudo nano /etc/network/interfaces

Y en el entorno de configuración se escribe:

auth eth0

iface eth0 inet static

address 192.168.192.130

netmask 255.255.255.0

network 192.168.192.0

broadcast 192.168.192.255

gateway 192.168.192.1

Nota: el segmento de dirección IP usado es 192.168.192.0/24 ya que esta es la porción entregada por el

DHCP del entorno de virtualización. En caso particular que sea distinto en la implementación, se debe revisar

y asignar correctamente.

Al terminar, guardar cambios y salir del entorno de edición.

Cada máquina virtual debe tener su dirección IP. Para este caso se asigna la dirección .130 en el nodo master.

Para los nodos esclavos se debe asignar la dirección .131 y .132, respectivamente.

Configuración de la tabla de hosts

Para la comunicación del clúster, es importante que cada máquina virtual tenga creada la tabla de hosts todos

los dispositivos. Para esto se modifica el archivo hosts.

$ sudo nano /etc/hosts

En el entorno de edición, se debe borrar cualquier información que aparezca allí, incluyendo la dirección de

loopback (127.0.0.1), y se reemplaza por la dirección IP de cada máquina seguido del nombre del host,

separado por un tabulador.

192.168.192.130 master

192.168.192.131 slave01

192.168.192.132 slave02




18


Instalación de SSH y Java 8

El sistema de archivos distribuidos que implementa Hadoop emplea tanto SSH como Java. Con SSH permite la

conexión segura entre el nodo maestro y los nodos esclavos, autenticándose con el usuario hadoop,

previamente creado.

El entorno de implementación de las tareas de distribución de archivos y los métodos de búsqueda (map) y

reducción (reduce), se ejecutan scripts o programas en lenguaje en Java, Kotlin, Scala y Python, principalmente.

Para este caso, emplearemos lenguaje Java versión 8.

Para instalar estos paquetes, primero se actualiza la lista de paquetes y las versiones más recientes de los

paquetes que deben ser actualizados.

$ sudo apt-get update

Luego, se instalan los dos paquetes que se requieren como base en la implementación del clúster.

$ sudo apt install openjdk-8-jdk -y

$ sudo apt-get install openssh-server

Configuración de autenticación SSH

Como ya menciona anteriormente, SSH asegura la conexión entre el nodo master y los nodos esclavos. Para

esto se debe crear las llaves (o claves) de autenticación del nodo master y replicarlo a sí mismo y a los nodos

esclavos.

$ ssh-keygen -b 4096

Para cualquier información adicional que solicite el comando, se debe dejar en blanco presionando Enter.

Se crean entonces dos archivos. La llave privada es id_rsa y la llave pública es id_rsa.pub. Estos archivos

se almacenan en el directorio /home/hadoop/.ssh. Para replicarlos a los nodos esclavos se realiza:

$ ssh-copy-id -i /home/hadoop/.ssh/id_rsa.pub hadoop@master

Nota: La porción de código hadoop@master hace referencia al usuario hadoop, en el nodo master.

Luego de la ejecución de la línea, se debe ingresar la contraseña del usuario hadoop. Si es correcto, el sistema

mostrará que se ha agregado una nueva llave. Para comprobar si esto fue posible, se debe ingresar:

$ ssh hadoop@master




–––

19

Con esto, se puede ingresar al nodo master. Para volver a la sesión original, basta con emplear el comando

exit en la consola. Esta configuración debe hacerse desde master y replicarse a cada nodo esclavo;

posteriormente, se debe comprobar si es posible el acceso desde el nodo master empleando SSH.

$ ssh-copy-id -i /home/hadoop/.ssh/id_rsa.pub hadoop@slave01

$ ssh-copy-id -i /home/hadoop/.ssh/id_rsa.pub hadoop@slave02

$ ssh hadoop@slave01

$ exit


$ exit

Finalmente, las llaves deben concatenarse con el archivo repositorio de llaves autorizadas y proveer los

permisos de acceso al usuario hadoop.

$ cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys

$ chmod 0600 ~/.ssh/authorized_keys

Instalación y configuración de Hadoop

Esta instalación debe hacerse únicamente en el nodo maestro. La instalación en los nodos esclavos se realizará

en los siguientes pasos.

Para la instalación de Hadoop, se debe descargar la distribución 3.2.1 localizada en el repositorio de Apache.

Es importante aclarar que, para esta instalación los archivos de Hadoop se instalarán en la carpeta

/home/hadoop/hadoop.

$ cd

$ wget http://archive.apache.org/dist/hadoop/common/hadoop-

3.2.1/hadoop-3.2.1.tar.gz

La descarga tomará algún tiempo, según la velocidad de Internet que se tenga.

Una vez descargado se hace la extracción de los archivos. En forma automática, se crea la carpeta hadoop-

3.2.1, que luego se renombrara por hadoop.

$ tar -xzf hadoop-3.2.1.tar.gz

$ mv hadoop-3.2.1 hadoop

Para la ejecución de archivos de Hadoop desde cualquier directorio, se debe modificar el archivo .profile

de la carpeta /home/hadoop e incluir la ruta del directorio hadoop como una variable de entorno.

$ sudo nano /home/hadoop/.profile

En el entorno de edición, agregamos la ruta de las subcarpetas /bin y /sbin.




20

PATH=/home/hadoop/hadoop/bin:/home/hadoop/hadoop/sbin:$PATH


Para que la ruta tome efecto en el sistema operativo, se debe ejecutar el archivo como tal. Para esto, se escribe:

$ source ~/.profile

Es necesario también, crear en el archivo .bashrc un alias para la carpeta de hadoop, denominada

$HADOOP_HOME.

$ sudo nano /home/hadoop/.bashrc

En el entorno de edición se agregan las siguientes líneas:

export HADOOP_HOME=/home/hadoop/hadoop

export PATH=${PATH}:${HADOOP_HOME}/bin:${HADOOP_HOME}/sbin


Igualmente, se debe ejecutar el archivo para que los cambios tomen efecto.

$ source /home/hadoop/.bashrc

En cuanto a la configuración del sistema de Hadoop, se debe configurar inicialmente el archivo de variables de

entorno de Hadoop (hadoop-env.sh). Para esta configuración, se debe incluir la ruta de Java.

Para obtener la ruta de instalación de Java, se debe escribir:

$ update-alternatives --display java

La respuesta de esta línea de comandos será la ubicación de todas las distribuciones de Java que están instaladas

en la máquina virtual. Si se ha realizado el paso a paso desde el principio, sólo aparecerá una. La información

que se debe copiar está en la línea link currently, eliminando la última parte de la ruta /bin/java.

En este caso la ruta es /usr/lib/jvm/java-8-openjdk-amd64/jre/.

$ sudo nano ~/hadoop/etc/hadoop/hadoop-env.sh

En el entorno de edición, se debe buscar la siguiente línea y quitar el comentario (símbolo #).

# export JAVA_HOME=${JAVA_HOME}

Se debe reemplazar el ${JAVA_HOME} por la ruta encontrada anteriormente. Finalmente, la línea debe quedar:




–––

21

export JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64/jre/


El siguiente archivo que se debe modificar es el core-site.xml; este archivo le indica al sistema Hadoop

qué dispositivo será el nodo maestro, identificado por el hostname; el nodo maestro tendrá el rol de coordinador

de los trabajos que se repartirán a los nodos esclavos.

$ sudo nano ~/hadoop/etc/hadoop/core-site.xml

Este archivo (junto con los otros que siguen a continuación) están codificados en lenguaje XML. Estas etiquetas

son reconocidas por el sistema durante la ejecución y transfieren los datos para su funcionamiento.

La estructura de cada archivo está conformada por una etiqueta raíz

<configuration></configuration>. Dentro de ésta debe existir una o varias etiquetas “hijo”

<property></property>, que a su vez contienen dos etiquetas <name></name> y

<value></value>.

En el entorno de edición, se debe incluir los siguientes comandos:

<property>

<name>fs.default.name</name>

<value>hdfs://master:9000</value>

</property>


El siguiente archivo que se debe modificar es el hdfs-site.xml; este archivo le indica al sistema Hadoop

cómo será la distribución de los archivos, cuáles serán los nodos principales (namenode) y los nodos

secundarios (datanode) y el número de nodos esclavo (replication) que, para este ejemplo, son dos

(slave01 y slave02).

$ sudo nano ~/hadoop/etc/hadoop/hdfs-site.xml


<property>

<name>dfs.namenode.name.dir</name>

<value>/home/hadoop/data/nameNode</value>

</property>

<property>

<name>dfs.datanode.data.dir</name>

<value>/home/hadoop/data/dataNode</value>

</property>

<property>

<name>dfs.replication</name>

<value>2</value>

</property>




22

Sin importar que estas carpeta y subcarpetas no existan aún, cuando se ejecute el clúster por primera vez, se

crearán automáticamente.


El siguiente archivo que se debe modificar es el mapred-site.xml; este archivo le indica al sistema Hadoop

cuál será el tipo de administrador de recursos y cuál es su ubicación dentro de la carpeta Hadoop. Para este

caso, Apache Hadoop emplea YARN como administrador de recursos del clúster.

$ sudo nano ~/hadoop/etc/hadoop/mapred-site.xml


<property>

<name>mapreduce.framework.name</name>

<value>yarn</value>

</property>

<property>

<name>yarn.app.mapreduce.am.env</name>

<value>HADOOP_MAPRED_HOME=$HADOOP_HOME</value>

</property>

<property>

<name>mapreduce.map.env</name>


</property>

<property>

<name>mapreduce.reduce.env</name>


</property>


Otro archivo que se debe modificar es el yarn-site.xml; este archivo le indica al sistema la ubicación del

administrador de recursos y si existen restricciones entre los nodos para distribuir los archivos.

$ sudo nano ~/hadoop/etc/hadoop/yarn-site.xml


<property>

<name>yarn.acl.enable</name>

<value>0</value>

</property>

<property>

<name>yarn.resourcemanager.hostname</name>

<value>192.168.192.130</value>

</property>

<property>

<name>yarn.nodemanager.aux-services</name>

<value>mapreduce_shuffle</value>

</property>




–––

23


Para finalizar, se deben actualizar dos archivos: master y workers. El primero debe ser creado y contiene

la información del hostname de la máquina que tendrá el rol de nodo maestro. El segundo archivo, debe ser

editado y contiene la lista de hosts que hacen parte de los nodos esclavos. Para ambos casos, se emplea el

comando nano, como entorno de edición.

$ sudo nano /home/hadoop/hadoop/etc/hadoop/master

En el entorno de edición, únicamente se incluye el hostname master. Al terminar, guardar cambios y salir del

entorno de edición.

$ sudo nano /home/hadoop/hadoop/etc/hadoop/workers

En el entorno de edición, se agregan dos líneas con la información de los hostname de cada uno de los esclavos.

slave01

slave02


Configuración de memoria y recursos disponibles del clúster

Para el desarrollo de las actividades de búsqueda (map) y reducción (reduce), se realizan acciones que luego se

almacenan en la memoria disponible que de cada esclavo. Es importante definirle al sistema Hadoop cómo será

la configuración de memoria para cada tarea a desarrollar.

Para esto, se empleó la función yarn-utils.py que proporciona la web de servicios en la nube Cloudera23,

para determinar la configuración que debe llevar YARN.

Para cada máquina virtual de 2 GB en RAM, se tiene la siguiente configuración. Estas configuraciones deben

hacerse modificando los archivos yarn-site.xml y mapred-site.xml.

$ sudo nano /home/hadoop/hadoop/etc/hadoop/yarn-site.xml

En el entorno de edición se agregan las siguientes líneas, después de la configuración que ya se había agregado

antes:

<property>

<name>yarn.nodemanager.resource.memory-mb</name>

<value>1536</value>

</property>

<property>

<name>yarn.scheduler.maximum-allocation-mb</name>

23 https://bit.ly/33Hn1gY

https://bit.ly/33Hn1gY




24

<value>1536</value>

</property>

<property>

<name>yarn.scheduler.minimum-allocation-mb</name>

<value>128</value>

</property>

<property>

<name>yarn.nodemanager.vmem-check-enabled</name>

<value>false</value>

</property>


$ sudo nano /home/hadoop/hadoop/etc/hadoop/mapred-site.xml

En el entorno de edición se agregan las siguientes líneas, después de la configuración que ya se había agregado

antes:

<property>

<name>yarn.app.mapreduce.am.resource.mb</name>

<value>512</value>

</property>

<property>

<name>mapreduce.map.memory.mb</name>

<value>256</value>

</property>

<property>

<name>mapreduce.reduce.memory.mb</name>

<value>256</value>

</property>


Instalación de hadoop en nodos esclavos y replicación de archivos de configuración

Ya la configuración del nodo maestro está lista. Por consiguiente, se debe instalar la distribución de Hadoop en

cada nodo esclavo. Para esto, se transfiere el archivo comprimido de Hadoop a cada uno de ellos.

$ cd /home/hadoop/

$ scp hadoop-*.tar.gz slave01:/home/hadoop

$ scp hadoop-*.tar.gz slave02:/home/hadoop

Se debe luego conectar a cada esclavo por medio de SSH, para descomprimir cada uno de los archivos.


$ tar -xzf hadoop-3.2.1.tar.gz

$ mv hadoop-3.2.1 hadoop

$ exit




–––

25

Repetir para el nodo slave02.

Una vez instalado, se debe volver al nodo master y desde ahí hacer la copia de los archivos de configuración

que se han modificado previamente (el archivo de entorno .sh, los archivos .xml, la creación de master y

la edición de workers).

$ for node in slave01 slave02; do

> scp ~/hadoop/etc/hadoop/* $node:/home/hadoop/hadoop/etc/hadoop/;

> done

Formateo del clúster y comandos básicos

Ya con la configuración terminada, se debe dar formato al clúster para que todas los comandos y los archivos

reconozcan quién será el nodo maestro, cuantos nodos esclavos hay configurados y cuantos recursos disponibles

de memoria hay en el clúster.

$ hdfs namenode -format

Una vez terminado el proceso, se deben iniciar los servicios de hdfs y de yarn.

$ start-dfs.sh && start-yarn.sh

En forma paulatina se muestra en pantalla que los servicios están iniciando. Deberá mostrarse que tanto el

namenode y los datanodes están iniciando. Para visualizar los procesos activos de cada clúster se puede

ejecutar el comando jps.

También se puede validar la existencia y funcionamiento de los nodos por medio de:

$ yarn node -list

Para detener los servicios, se emplean los comandos:

$ stop-dfs.sh && stop-yarn.sh

Para obtener información de los nodos esclavos activos y la capacidad del clúster, estos pueden ser visualizados

mediante:

$ hdfs dfsadmin -report

Desde un dispositivo incluido en la misma red, se puede visualizar el funcionamiento del clúster con las

siguientes direcciones:

http://192.168.1.81:9870

http://192.168.1.81:8088




26

El primero, muestra el estado de los nodos y su capacidad, mientras que el segundo es el entorno de monitoreo

para las actividades y aplicaciones que se están ejecutando en el clúster, que para este caso particular es el de

conteo de palabras.




–––

27

Anexo 2: Configuración del clúster de arquitectura ARM

La siguiente configuración se realizó en tres dispositivos Raspberry PI 3B:

• Sistema Operativo Raspbian Buster Lite (sin interfaz gráfica/desktop)

• Procesador 32 bit, 1 GB de RAM, tarjeta SD de 16 GB.

Se deben tener tres dispositivos iguales a esta configuración. Para facilidad de uso y por propósitos de la

investigación, se empleará el usuario pi que viene en los dispositivos por defecto, únicamente modificando la

contraseña a una más corta: pi. Este parámetro, el hostname y otras consideraciones iniciales, se configurarán

en con el archivo raspi-config del dispositivo.

Es importante realizar la siguiente configuración básica para todos los nodos. En este caso se mostrará como

configurar los nodos: un nodo maestro y dos nodos esclavos.

La información contenida a continuación es recopilación de foros, información de portales de servicios cloud,

blogs y contribuciones de la comunidad entusiasta de Hadoop. Entre otras cosas, lo que se realizó fue pruebas

de la configuración, modificaciones entre varias opciones de configuración y este es el resultado de la

personalización que funcionó y se validó en la infraestructura.

Configuración inicial en las Raspberry PI

Una vez conectada a la corriente, a un teclado por puerto USB y a una pantalla por el puerto HDMI, se ingresa

al sistema operativo empleando el usuario y contraseña por defecto: pi y raspberry.

Luego, se debe ingresar a la configuración inicial del sistema, escribiendo:

$ sudo raspi-config

Aparecerá un entorno amigable visualmente, cuya navegación puede hacerse por medio de los cursores del

teclado y la tecla tabuladora.

En primera instancia, se debe modificar en el primer ítem del menú la contraseña del usuario pi. Se configura

para que la contraseña sea pi.

Seguido a esto, en opciones de red se modifican los valores de hostname. Será ahora pi1 para el nodo maestro,

pi2 para un esclavo y pi3 para el otro esclavo, y se configura la red WiFi. Inicialmente, el sistema pide

configurar el país del que se selecciona de una lista y seguido a esto se configura el SSID de la red y la

contraseña.

En el siguiente menú, se configura la ubicación para una correcta visualización de la hora y fecha al momento

de actualizarse con Internet. Además, para efectos de aprovechar completamente el teclado español empleado

en esta configuración, se selecciona tipo de teclado español (Latinoamérica) y se selecciona el tipo específico

de teclado. En este caso se ha empleado un teclado genérico de 105 teclas.

En la opción de interfaces, se debe habilitar el protocolo SSH que permite la conexión remota empleando Solar-

PuTTy.

Para finalizar, en las opciones avanzadas, se amplía el uso de la capacidad de la tarjeta SD para ser ocupada por

el sistema operativo y luego se reduce la memoria empleada para la visualización gráfica de 64 a 16. Al salir

del menú, se selecciona la opción de reiniciar el dispositivo.




28

Configuración de red

Los dispositivos se interconectarán por medio de red WiFi, ya que la distancia entre ellas y el enrutador

inalámbrico es mínima. El enrutador entrega direcciones IP versión 4 por medio de DHCP en el segmento de

red 192.168.1.0/24. Para este caso, se seleccionan tres direcciones IP para ser asignadas en forma estática:

.81 (dispositivo pi1), .82 (dispositivo pi2) y .83 (dispositivo pi3).

En cada dispositivo debe hacerse la configuración como sigue:

$ sudo nano /etc/dhcpcd.conf

Para el dispositivo maestro, al final del entorno de edición, se agregan las siguientes líneas:

interface wlan0

static ip_address=192.168.1.81/24 #direccion IP

static routers=192.168.1.1 #direccion IP Puerta de enlace

static domain_name_servers=8.8.8.8 #direccion IP del DNS


Configuración de la tabla de hosts

Para la comunicación del clúster, es importante que cada nodo tenga creada la tabla de hosts todos los

dispositivos. Para esto se modifica el archivo hosts en cada uno de ellos.

$ sudo nano /etc/hosts

En el entorno de edición, se debe borrar cualquier información que aparezca allí, incluyendo la dirección de

loopback (127.0.0.1), y se reemplaza por la dirección IP de cada máquina seguido del nombre del host, separado

por un tabulador.

192.168.1.81 pi1

192.168.1.82 pi2

192.168.1.83 pi3


Configuración de autenticación SSH

Con SSH, se asegura la conexión entre el nodo master (pi1) y los nodos esclavos (pi2 y pi3). Para esto se

debe crear las llaves (claves) de autenticación en todos los nodos y posteriormente, replicarlo a sí mismo y a

los demás nodos.

$ ssh-keygen –t ed25519

Para cualquier información adicional que solicite el comando, se debe dejar en blanco presionando Enter.




–––

29

Se crean entonces dos archivos. La llave privada es id_ed25519 y la llave pública es id_ed25519.pub.

Estos archivos se almacenan en el directorio /home/pi/.ssh. Para replicarlos a todos los nodos se realiza:

$ ssh-copy-id -i /home/pi/.ssh/ id_ed25519.pub pi@pi1

Nota: La porción de código pi1@pi hace referencia al usuario pi, en el nodo pi1.

Luego de la ejecución de la línea, se debe ingresar la contraseña del usuario hadoop. Si es correcto, el sistema

mostrará que se ha agregado una nueva llave. Para comprobar si esto fue posible, se debe ingresar:

$ ssh pi@pi1

Con esto, se puede ingresar al nodo pi1. Para volver a la sesión original, basta con emplear el comando exit

en la consola.

Esta configuración debe hacerse desde todos los nodos y replicarse a cada nodo; posteriormente, se debe

comprobar si es posible el acceso desde cada nodo empleando SSH.


$ ssh pi@pi2

$ exit


$ ssh pi@pi3

$ exit

Finalmente, las llaves deben concatenarse con el archivo repositorio de llaves autorizadas en cada nodo y

proveer los permisos de acceso al usuario hadoop.

$ cat ~/.ssh/id_ed25519.pub >> ~/.ssh/authorized_keys

$ chmod 0600 ~/.ssh/authorized_keys

Crear scripts en ~/.bashrc

Es cierto que se deben hacer replicaciones y validaciones en cada uno de los nodos, una y varias veces. Por lo

tanto, por facilidad se emplean scripts que permiten hacer varias ejecuciones al mismo tiempo en cada nodo,

sin necesidad de ingresar individualmente y aprovechando la implementación de SSH.

$ sudo nano /home/pi/.bashrc

En el entorno de edición agregamos las siguientes líneas:

# Obtiene info de host de los nodos, sin incluir el mismo nodo.

function otherpis {

grep "pi" /etc/hosts | awk '{print $2}' | grep -v $(hostname)




30

}

# Envia ejecucion de un comando a todos los nodos del cluster

function clustercmd {

for pi in $(otherpis); do ssh $pi "$@"; done

$@

}

# Reinicia todos los nodos del cluster

function clusterreboot {

clustercmd sudo shutdown -r now

}

# Copia archivos simultáneamente a todos los nodos el cluster

function clusterscp {

for pi in $(otherpis); do

cat $1 | ssh $pi "sudo tee $1" > /dev/null 2>&1

done

}

Al terminar, guardar cambios y salir del entorno de edición. Adicionalmente, para actualizar los cambios sin

reiniciar y replicar a todos los nodos, es importante ejecutar el archivo:

$ source ~/.bashrc && clusterscp ~/.bashrc

Finalmente, se reinician todos los nodos del cluster:

$ clusterreboot

Actualizar paquetes e instalar Java 8

Para la instalación de Java 8, primero se actualiza la lista de paquetes y las versiones más recientes de los

paquetes que deben ser actualizados en todos los nodos. Para esto se emplea la función clustercmd.

$ clustercmd sudo apt-get update

Una vez finalizado, se debe instalar Java 8.

$ clustercmd sudo apt-get install openjdk-8-jdk -y

Instalación y configuración de Hadoop

Esta instalación debe hacerse únicamente en el nodo pi1. La instalación en los nodos pi2 y pi3, se realizará

en los siguientes pasos.

Para la instalación de Hadoop, se debe descargar la distribución 3.2.0 localizada en el repositorio de Apache.

Es importante aclarar que, para esta instalación los archivos de Hadoop se instalarán en la carpeta /opt/.




–––

31

$ cd

$ wget http://archive.apache.org/dist/hadoop/common/hadoop-

3.2.0/hadoop-3.2.0.tar.gz

La descarga tomará algún tiempo, según la velocidad de acceso a Internet que se tenga.

Una vez descargado se hace la extracción de los archivos en la carpeta /opt/. En forma automática, se crea la

carpeta hadoop-3.2.1, que luego se renombrara por hadoop.

$ sudo tar -xvf hadoop-3.2.0.tar.gz -C /opt/

$ rm hadoop-3.2.0.tar.gz && cd /opt

$ sudo mv hadoop-3.2.0 hadoop

Luego, se otorgarán los permisos sobre la carpeta y subcarpetas de /opt/hadoop al usuario pi.

$ sudo chown pi:pi -R /opt/hadoop

Es necesario también, crear en el archivo .bashrc un alias para la carpeta de Hadoop, denominada

$HADOOP_HOME e indicarle al sistema donde encontrar la ruta de los archivos de Java, creando un alias

$JAVA_HOME.

Para obtener la ruta de instalación de Java se debe ejecutar primero:

$ update-alternatives --config java

La información aparece en la línea current link. Se debe descartar de esa ruta lo que aparezca después de

/jre/. Para este caso la ruta es /usr/lib/jvm/java-8-openjdk-armhf/jre/.

$ sudo nano /home/hadoop/.bashrc

En el entorno de edición se agregan las siguientes líneas:

export JAVA_HOME=/usr/lib/jvm/java-8-openjdk-armhf/jre/

export HADOOP_HOME=/opt/hadoop

export PATH=$PATH:$HADOOP_HOME/bin:$HADOOP_HOME/sbin


Igualmente, se debe ejecutar el archivo para que los cambios tomen efecto.

$ source /home/pi/.bashrc

En cuanto a la configuración del sistema de Hadoop, se debe configurar inicialmente el archivo de variables de

entorno de Hadoop (hadoop-env.sh). Para esta configuración, se debe incluir la ruta de Java.




32

$ sudo nano /opt/hadoop/etc/hadoop/hadoop-env.sh

En el entorno de edición, se debe buscar la siguiente línea y quitar el comentario (símbolo #).

# export JAVA_HOME=${JAVA_HOME}

Se debe reemplazar el ${JAVA_HOME} por la ruta encontrada anteriormente. Finalmente, la línea debe quedar:

export JAVA_HOME=/usr/lib/jvm/java-8-openjdk-armhf/jre/


Para validar si la instalación de Hadoop fue exitosa, se escribe:

$ cd

$ hadoop version | grep Hadoop

Deberá aparecer:

Hadoop 3.2.0

Configuración de archivos de sistema de Hadoop

Para el desarrollo de las actividades de búsqueda (map) y reducción (reduce), se realizan acciones que luego se

almacenan en la memoria disponible que de cada esclavo. Es importante definirle al sistema Hadoop cómo será

la configuración de memoria para cada tarea a desarrollar.

Para esto, se empleó la función yarn-utils.py que proporciona la web de servicios en la nube Cloudera24,

para determinar la configuración que debe llevar YARN.

El primer archivo que se debe modificar es el core-site.xml; este archivo le indica al sistema Hadoop qué

dispositivo será el nodo maestro, identificado por el hostname; el nodo maestro tendrá el rol de coordinador de

los trabajos que se repartirán a los nodos esclavos.

$ sudo nano /opt/hadoop/etc/hadoop/core-site.xml

Este archivo (junto con los otros que siguen a continuación) están codificados en lenguaje XML. Estas etiquetas

son reconocidas por el sistema durante la ejecución y transfieren los datos para su funcionamiento.

La estructura de cada archivo está conformada por una etiqueta raíz

<configuration></configuration>. Dentro de ésta debe existir una o varias etiquetas “hijo”

<property></property>, que a su vez contienen dos etiquetas <name></name> y

<value></value>.


24 https://bit.ly/33Hn1gY

https://bit.ly/33Hn1gY




–––

33

<property>

<name>fs.default.name</name>

<value>hdfs://pi1:9000</value>

</property>


El siguiente archivo que se debe modificar es el hdfs-site.xml; este archivo le indica al sistema Hadoop

cómo será la distribución de los archivos, cuáles serán los nodos principales (namenode) y los nodos

secundarios (datanode) y el número de nodos esclavo (replication) que, para este ejemplo, son dos (pi2 y

pi3).

$ sudo nano /opt/hadoop/etc/hadoop/hdfs-site.xml


<property>

<name>dfs.datanode.data.dir</name>

<value>/opt/hadoop_tmp/hdfs/datanode</value>

</property>

<property>

<name>dfs.namenode.name.dir</name>

<value>/opt/hadoop_tmp/hdfs/namenode</value>

</property>

<property>

<name>dfs.replication</name>

<value>2</value>

</property>

Sin importar que estas carpeta y subcarpetas de datanode y namenode no existan aún, más adelante se hará

la creación y se otorgarán los permisos para el usuario pi.


El siguiente archivo que se debe modificar es el mapred-site.xml; este archivo le indica al sistema Hadoop

cuál será el tipo de administrador de recursos y cuál es su ubicación dentro de la carpeta Hadoop. Para este

caso, Apache Hadoop emplea YARN como administrador de recursos del clúster.

$ sudo nano /opt/hadoop/etc/hadoop/mapred-site.xml


<property>

<name>mapreduce.framework.name</name>

<value>yarn</value>

</property>

<property>

<name>yarn.app.mapreduce.am.env</name>

<value>HADOOP_MAPRED_HOME=${HADOOP_HOME}</value>




34

</property>

<property>

<name>mapreduce.map.env</name>


</property>

<property>

<name>mapreduce.reduce.env</name>


</property>

<property>

<name>mapreduce.map.memory.mb</name>

<value>682</value>

</property>

<property>

<name>mapreduce.map.java.opts</name>

<value>-Xmx545m</value>

</property>

<property>

<name>mapreduce.reduce.memory.mb</name>

<value>1364</value>

</property>

<property>

<name>mapreduce.reduce.java.opts</name>


</property>

<property>

<name>mapreduce.task.io.sort.mb</name>

<value>272</value>

</property>


Otro archivo que se debe modificar es el yarn-site.xml; este archivo le indica al sistema la ubicación del

administrador de recursos y si existen restricciones entre los nodos para distribuir los archivos.

$ sudo nano /opt/hadoop/etc/hadoop/yarn-site.xml


<property>

<name>yarn.acl.enable</name>

<value>0</value>

</property>

<property>

<name>yarn.resourcemanager.hostname</name>

<value>pi1</value>

</property>




–––

35

<property>

<name>yarn.nodemanager.aux-services</name>

<value>mapreduce_shuffle</value>

</property>

<property>

<name>yarn.nodemanager.auxservices.mapreduce.shuffle.class</name>

<value>org.apache.hadoop.mapred.ShuffleHandler</value>

</property>

<property>

<name>yarn.scheduler.minimum-allocation-mb</name>

<value>682</value>

</property>

<property>

<name>yarn.scheduler.maximum-allocation-mb</name>

<value>2046</value>

</property>

<property>

<name>yarn.nodemanager.resource.memory-mb</name>

<value>2046</value>

</property>

<property>

<name>yarn.app.mapreduce.am.resource.mb</name>

<value>1364</value>

</property>

<property>

<name>yarn.app.mapreduce.am.command-opts</name>


</property>

<property>

<name>yarn.nodemanager.vmem-check-enabled</name>

<value>false</value>

</property>


Había quedado pendiente la creación de las carpetas datanode y namenode. Entonces, desde el host pi1:

$ sudo mkdir -p /opt/hadoop_tmp/hdfs/datanode

$ sudo mkdir -p /opt/hadoop_tmp/hdfs/namenode

Igualmente, para los nodos pi2 y pi3 se debe hacer la creación y además asignar los privilegios de acceso al

usuario pi:

$ clustercmd sudo mkdir -p /opt/hadoop_tmp/hdfs

$ clustercmd sudo chown pi:pi –R /opt/hadoop_tmp

$ clustercmd sudo mkdir -p /opt/hadoop

$ clustercmd sudo chown pi:pi /opt/hadoop




36

Deshabilitar mensajes de warning e incompatibilidad del sistema Hadoop

Si bien no afectan en nada, son mensajes molestos que, al ser inofensivos y repetitivos, generan algo de pánico

innecesario. Como primera medida, se debe modificar el archivo de variables de entorno de Hadoop.

$ sudo nano /opt/hadoop/etc/hadoop/hadoop-env.sh

En el entorno de edición se debe cambiar la línea:

# export HADOOP_OPTS="-Djava.net.preferIPv4Stack=true"

Por…

export HADOOP_OPTS="-XX:-PrintWarnings –Djava.net.preferIPv4Stack=true"


Luego, se debe modificar el archivo de variables de entorno del sistema operativo.

sudo nano ~/.bashrc

En el entorno de edición, se debe agregar las siguientes líneas:

export HADOOP_HOME_WARN_SUPPRESS=1

export HADOOP_ROOT_LOGGER="WARN,DRFA"

Al terminar, guardar cambios y salir del entorno de edición. Adicionalmente, se ejecuta el archivo para que

toman efecto los cambios.

source ~/.bashrc

Instalar Hadoop y copiar los archivos de configuración

Ya la configuración del nodo maestro está lista. Por consiguiente, se debe instalar la distribución de Hadoop en

cada nodo esclavo. Para esto, se transfieren los archivos desde el nodo pi1, a pi2 y pi3.

$ for pi in $(otherpis); do

> rsync –avxP $HADOOP_HOME $pi:/opt

> done

Luego de la copia, se debe verificar la instalación de Hadoop en cada nodo.

clustercmd hadoop version | grep Hadoop




–––

37

Se debe recibir entonces…

Hadoop 3.2.0

Finalmente, en el nodo pi1 se crea el archivo master y se edita el archivo workers. El primero contiene el

nombre de host del dispositivo que tomará el rol de maestro del clúster y en el otro se incluirán los hosts de los

nodos que serán los que ejecuten las actividades.

$ sudo nano /opt/hadoop/etc/hadoop/master

En el entorno de edición, se incluye:

pi1


$ sudo nano /opt/hadoop/etc/hadoop/workers

En el entorno de edición, se incluye:

pi2

pi3


Formateo del clúster y comandos básicos

Ya con la configuración terminada, se debe dar formato al clúster para que todas los comandos y los archivos

reconozcan quién será el nodo maestro, cuantos nodos esclavos hay configurados y cuantos recursos disponibles

de memoria hay en el clúster.

$ hdfs namenode -format -force

Una vez terminado el proceso, se deben iniciar los servicios de hdfs y de yarn.

$ start-dfs.sh && start-yarn.sh

En forma paulatina se muestra en pantalla que los servicios están iniciando. Deberá mostrarse que tanto el

namenode y los datanodes están iniciando. Para visualizar los procesos activos de cada clúster se puede

ejecutar el comando jps.

También se puede validar la existencia y funcionamiento de los nodos por medio de:

$ yarn node -list




38

Para detener los servicios, se emplean los comandos:

$ stop-dfs.sh && stop-yarn.sh

Para obtener información de los nodos esclavos activos y la capacidad del clúster, estos pueden ser visualizados

mediante:

$ hdfs dfsadmin -report

Desde un dispositivo incluido en la misma red, se puede visualizar el funcionamiento del clúster con las

siguientes direcciones:

http://192.168.1.81:9870

http://192.168.1.81:8088

El primero, muestra el estado de los nodos y su capacidad, mientras que el segundo es el entorno de monitoreo

para las actividades y aplicaciones que se están ejecutando en el clúster, que para este caso particular es el de

conteo de palabras.

Anexo 3: Comandos para carga y ejecución del proceso WordCount

En el sistema de archivos HDFS se crea una carpeta “home” en la que se cargarán los trabajos o archivos a

analizar. Generalmente, esta carpeta se forma con el usuario que se está trabajando en el cluster.

$ hdfs dfs -mkdir -p /user/pi

Luego, se crea la carpeta para recibir los archivos que se van a analizar:

$ hdfs dfs -mkdir test10

Se debe ir a la carpeta fuente para extraer los archivos y ser transferidos al destino test10.

$ cd /media/usb/txt/10MB

$ hdfs dfs -put d* test10

Una vez que se cargan los archivos, se debe ejecutar la tarea de WordCount, indicando el archivo .jar a

invocar, la carpeta fuente de los archivos y la carpeta destino donde irá el resultado del conteo de palabras.

Para el caso del clúster x86-64:

$ yarn jar /home/hadoop/hadoop/share/hadoop/mapreduce/hadoop-mapreduce-

examples-3.2.1.jar wordcount "test10/*" output




–––

39

Para el caso del clúster ARM:

$ yarn jar /opt/hadoop/share/hadoop/mapreduce/hadoop-mapreduce-

examples-3.2.0.jar wordcount "test10/*" output10

Se puede visualizar el desarrollo de ejecución de la aplicación en la dirección url

http://192.168.192.130:8088 para el caso del clúster x86-64 y http://192.168.1.81:8088

para el caso del clúster ARM.

Al finalizar, se debe eliminar la carpeta output para correr un nuevo experimento

$ hdfs dfs -rm -r /user/pi/output

http://192.168.192.130:8088/

http://192.168.1.81:8088/

Análisis de desempeño de arquitecturas x86-64 y ARM para ...software para construir y evaluar la...

Documents

Transcript of Análisis de desempeño de arquitecturas x86-64 y ARM para ...software para construir y evaluar la...