Skip to content

Introducción

La materia Sistemas Distribuidos busca que los estudiantes comprendan los fundamentos de la computación distribuida a través de experiencias prácticas. En este marco, se propone la instalación y configuración de un clúster de 3 Raspberry Pi, que permitirá experimentar con conceptos de paralelismo, planificación de tareas y administración de recursos.

Objetivos de la Práctica

Al finalizar la práctica, los estudiantes deberán ser capaces de:

  • Instalar y configurar un sistema operativo en Raspberry Pi.

  • Configurar la red y asignar hostnames e IPs fijas.

  • Instalar y configurar servicios básicos de cluster: NFS, Munge y Slurm.

  • Verificar la comunicación entre nodos mediante Slurm.

  • Ejecutar un programa paralelo simple (MPI u OpenMP).

  • Documentar el proceso técnico de forma clara y precisa.

Duración y Organización

Esta práctica se desarrollará en el laboratorio, en el horario habitual de la materia. Los estudiantes trabajarán divididos en dos grupos :

  • Grupo A: Nodo Master (nodo00).

  • Grupo B: Nodos esclavos (nodo[01-03]

  • Documentación: ambos grupos

Metodología de Trabajo Colaborativo

Se recomienda que dentro de cada grupo se definan roles: equipo técnico (ejecución de comandos), equipo de investigación (consulta de documentación) y equipo de documentación (registro de pasos, problemas y soluciones).

Parte 1: NODO maestro nodo0

Fases de la Práctica

Fase 1: Preparación de la microSD

1. Descargar e instalar Raspberry Pi Imager desde (hacer esto para todos los nodos) https://www.raspberrypi.com/software/.

2. Grabar Raspberry Pi OS Lite (64-bit).

3. Configurar ajustes básicos: hostname, usuario, contraseña, SSH, zona horaria y teclado.

{width="5.999998906386701in" height="4.235879265091864in"}

Fase 2: Configuración inicial y red

1. Conectar la Raspberry Pi al switch del laboratorio.

2. Encender y acceder por SSH desde una PC o notebook.

Se recomiendo utilizar en el caso de Windows utiliza PuTTY o KiTTY.

https://www.chiark.greenend.org.uk/~sgtatham/putty/latest.html

https://sourceforge.net/projects/kitty-ssh/

Recomiendo instalar los dos, pero utilizar KiTTy, tiene algunas caracteristcas que aceleran el flujo de trabajo.

Para descubrir que ip dinámica se la asignó al RPI recién instalado se recomiendo usar el programa Advanced IP Scanner https://www.advanced-ip-scanner.com/es/ (Windows) o el programa Angry IP Scanner https://angryip.org/download/#linux (Linux).

3. Actualizar el sistema operativo:

sudo apt update && sudo apt upgrade -y

Editar\ sudo nano /boot/firmware/cmdline.txt

Agregar al final, un espacio, no dar enter!!!\ cgroup_enable=memory cgroup_memory=1 swapaccount=1

Sudo reboot

4. Configurar IP fija y editar /etc/hosts.

La herramienta a utilizar es nmtui

{width="2.6510345581802275in" height="2.484825021872266in"} Sudo nmtui

Cambiar a manual y show

{width="5.999998906386701in" height="2.9003313648293965in"}

Configuración de Red e Infraestructura

Para el desarrollo de esta práctica de despliegue de un clúster desde cero, disponemos de un switch Gigabit Ethernet (1 Gbps) de 5 puertos y un router inalámbrico Linksys E900. Esta infraestructura nos permitirá crear una subred aislada de \"alta velocidad\" dedicada exclusivamente al tráfico interno de los nodos del clúster (tráfico de interconexión y paso de mensajes).

El principal desafío técnico consiste en garantizar que los nodos tengan acceso saliente a Internet (para la instalación de paquetes, actualizaciones de repositorios y sincronización horaria), evitando al mismo tiempo que el tráfico externo no autorizado ingrese a la subred privada del clúster.

Para lograr este aislamiento perimetral, el router Linksys actuará como pasarela ejecutando NAT (Network Address Translation o Traducción de Direcciones de Red). Este mecanismo permite que todos los nodos de nuestra red privada compartan la dirección IP asignada por la red externa de la universidad (WAN) para comunicarse con el exterior, ocultando la topología interna y protegiendo (aislando el tráfico) el clúster.

Tabla de Direccionamiento IP

Toda la infraestructura del clúster se desplegará bajo la subred 192.168.1.0/24 utilizando direccionamiento estático. Deberán configurar cada interfaz de red siguiendo los parámetros de la siguiente tabla:

Ojo: como la dirección es clase C, no es necesario poner la máscara en la dirección ip, si fuera una subred si hay que poner /#mascara. En este caso no, cualquier duda preguntar ya que, si lo hacen mal, tienen que volver a grabar la imagen en la microsd.


Dispositivo / Dirección Máscara de Puerta de Servidores Rol IP Subred Enlace DNS (Gateway)


Router 192.168.1.254 255.255.255.0 Asignada por Provisto por Linksys E900 (/24) WAN ISP / Red Base

Nodo 0 192.168.1.190 255.255.255.0 192.168.1.254 192.168.1.254, (Master / (/24) 8.8.8.8 Login)

Nodo 1 192.168.1.191 255.255.255.0 192.168.1.254 192.168.1.254, (Worker) (/24) 8.8.8.8

Nodo 2 192.168.1.192 255.255.255.0 192.168.1.254 192.168.1.254, (Worker) (/24) 8.8.8.8

Nodo 3 192.168.1.193 255.255.255.0 192.168.1.254 192.168.1.254, (Worker) (/24) 8.8.8.8


Instrucciones para la Configuración en los Nodos

Para aplicar estos cambios de manera interactiva en la terminal de cada Raspberry Pi, utilizaremos la interfaz textual de NetworkManager ejecutando:

sudo nmtui

Luego de configurar la red

Sudo reboot

⚠️ Nota para el procedimiento: > 1. Seleccionen la opción \"Editar una conexión\" (Edit a connection) y elijan la interfaz de red cableada (usualmente eth0). 2. Cambien la configuración de IPv4 de Automático (DHCP) a Manual. 3. Completen los campos utilizando los valores indicados en la tabla superior. 4. Seleccionen () para guardar los cambios y asegúrense de reiniciar la interfaz o el servicio de red (sudo systemctl restart NetworkManager) para aplicar la nueva configuración. Una vez hecho, verifiquen la conectividad local con ping 192.168.1.254 y externa con ping 8.8.8.8.

{width="2.9906485126859144in" height="2.8031474190726158in"}

{width="5.999998906386701in" height="2.9003313648293965in"}

Fase 3: Instalación/configuración de sofware en nodo maestro

Nodo maestro (nodo0)

Sudo apt update

Sudo apt install fastfetch

Probamos la app

fastfetch

Verificar el nombre del nodo

Sudo hostname

Lista de hots locales

Editamos el archivos hosts para que cada nodo conozca a los demas por nombre en vez de dirección IP.

sudo nano /etc/cloud/cloud.cfg

busca y comenta la línea como en la figura: - update_etc_hosts

{width="4.9522058180227475in" height="4.677083333333333in"}

Sudo nano /etc/hosts

Agregamos lo siguiente:

{width="5.999998906386701in" height="2.1438670166229223in"}

Instalacion de NtpDate

ntpdate es un programa y comando de Linux utilizado para sincronizar rápidamente el reloj del sistema con un servidor remoto del Protocolo de Tiempo de Red (NTP). Es fundamental para evitar desajustes de tiempo que puedan causar fallos en los registros o en el intercambio de datos.

sudo apt update

sudo apt install ntpsec-ntpdate -y

Fase 4: Configuración de Almacenamiento Compartido distribuido: NFS

1. Introducción y Justificación

En un entorno de sistemas distribuidos y computación de alto rendimiento (HPC), la consistencia y la disponibilidad de los datos a través de todos los componentes de la infraestructura es un pilar fundamental. Cuando se ejecutan procesos en paralelo mediante herramientas como OpenMPI o se gestionan trabajos a través de un planificador de recursos como Slurm, es imprescindible que todos los nodos (Master y Workers) tengan acceso exacto, simultáneo e idéntico a los mismos archivos de código fuente, conjuntos de datos (datasets), librerías y configuraciones.

Sin un mecanismo de almacenamiento unificado, los administradores y usuarios se verían obligados a replicar manualmente cada archivo en el almacenamiento local de cada nodo individual. Esto no solo genera una ineficiencia crítica en el uso del espacio físico y del ancho de banda, sino que introduce un riesgo altísimo de inconsistencia de datos (desincronización de versiones), lo cual invalidaría los resultados de cualquier cómputo científico distribuido.

Para resolver esta problemática en nuestro clúster Cronos, implementaremos un Sistema de Archivos Redundante/Compartido basado en una arquitectura Cliente-Servidor. De esta manera, un nodo centralizado exportará un directorio de su almacenamiento local a través de la red local (LAN), y el resto de los nodos del clúster lo montarán de forma transparente en sus propios sistemas de archivos locales, operando como si se tratase de un disco rígido físico conectado directamente.

2. ¿Por qué elegimos NFS para el clúster Cronos?

Para nuestro proyecto, hemos seleccionado NFS (Network File System o Sistema de Archivos de Red) por sobre otras alternativas del mercado (como Samba/CIFS, GlusterFS o Ceph) debido a una serie de razones técnico-pedagógicas estratégicas:

  • Estándar Nativo en Entornos UNIX/Linux: NFS es el protocolo de almacenamiento en red nativo del ecosistema Linux. Su integración con el kernel es total, lo que garantiza una excelente estabilidad y compatibilidad con el sistema operativo Raspbian/Debian de nuestras Raspberry Pi, sin necesidad de sobrecargar los nodos con pesadas capas de traducción de software.

  • Eficiencia de Recursos (Ligereza): Las Raspberry Pi, si bien son extremadamente potentes para su formato, poseen recursos de cómputo limitados si se los compara con servidores de arquitectura x86 tradicionales. NFS es un protocolo de bajo impacto (low overhead); consume muy pocos ciclos de CPU y memoria RAM tanto en el servidor como en los clientes, dejando libre la mayor cantidad de hardware posible para el procesamiento de datos puro.

  • Preservación de Permisos POSIX: A diferencia de protocolos diseñados para entornos compartidos con Windows (como Samba), NFS respeta y mantiene de forma nativa la estructura de usuarios, grupos y permisos estándar de Linux (chmod, chown). Esto es un requisito crítico para que las claves SSH públicas/privadas de los usuarios del clúster mantengan sus permisos estrictos (600 o 700) y la ejecución distribuida funcione sin fallos de seguridad.

  • Simplicidad Operativa y Educativa: Sistemas de archivos distribuidos más complejos (como Ceph o GlusterFS) requieren clústeres de almacenamiento dedicados, configuraciones de red redundantes y un nivel de abstracción que escapa a los objetivos de esta práctica introductoria. NFS ofrece una curva de aprendizaje ideal: expone de manera transparente conceptos de red esenciales (puertos, RPC, montajes) permitiendo a los alumnos razonar el flujo del dato desde el cable hasta la aplicación.

La unidad compartida en nuestro caso es un pendrive, hay que enchufar el pendrive destinado al cluter en uno de los puertos usb del nodo0, recordar cual, porque una vez configurado no se puede cambiar de puerto usb.

En el nodo maestro: nodo0

  1. Enchufamos el pendrive que actuará como unidad compartida, recordar donde se enchufó, luego no se podrá cambiar de pueto usb

  2. Lsblk

{width="4.468503937007874in" height="2.3661417322834644in"}Ejemplo de salida

Identiticar cuál es el pendrive. En este ejemplo vamos a utilizar la partición /dev/sda1

  1. Formatear

Ejecutar

sudo mkfs.ext4 /dev/sda1

  1. Preparación de punto de montaje

Ejecutar en orden

sudo mkdir /clusterfs

sudo chown nobody:nogroup -R /clusterfs

sudo chmod 777 -R /clusterfs

  1. Preparar fstab para montaje automático al bootear

Reconocer UUID de la partición /dev/sda1 ejecutando

sudo blkid

Luego agregar la siguiente línea a /etc/fstab con

sudo nano /etc/fstab

UUID=\<el UUID obtenido> /clusterfs ext4 defaults 0 2

Ejemplo de configuración

{width="6.260415573053368in" height="1.09375in"}

Fase 4: Instalación de Munge y Slurm

1. Instalar Munge en todos los nodos, generar la clave en node01 y copiarla.

6. Montar todo con

sudo mount --a

OJO: mount: (hint) your fstab has been modified, but systemd still uses

the old version; use \'systemctl daemon-reload\' to reload.

sudo systemctl daemon-reload

sudo mount --a

7. Establecer permisos

  1. sudo chown nobody:nogroup -R /clusterfs

  2. sudo chmod 777 /clusterfs --R

  3. Chequear si el usb quedó bien montado

findmnt /clusterfs

{width="3.739582239720035in" height="1.5312489063867016in"}

Instalar NFS server (nodo0)

Instalamos el servidor NFS para que todos los nodos vean la unidad compartida y así acceder a los mismos archivos binarios y datos. Posteriormente en los nodos workers se instalará el cliente nfs.

  1. Ejecutar

sudo apt install nfs-kernel-server

2. Configurar NFS server

Modificar el archivo /etc/exports

Sudo nano /etc/exports

Agregar este contenido

/clusterfs 192.168.1.0/24(rw,sync,no_root_squash,no_subtree_check)

{width="5.999998906386701in" height="2.7917727471566054in"}

{width="5.999998906386701in" height="1.225913167104112in"}

3. Aplicar cambios

sudo exportfs --a

Instalar y Configurar SLURM en el nodo maestro:

  1. Instalar Slurm

sudo apt install slurm-wlm -y

  1. Configuramos el server

Sudo nano /etc/slurm/slurm.conf

{width="5.999998906386701in" height="4.6851060804899385in"}

Pedir el archivo de ejemplo, para configurar la partición y los recursos del cluster.

Una partición en Slurm es una agrupación lógica de nodos de cómputo que funciona de manera similar a una cola de trabajos, permitiendo administrar y categorizar los recursos del clúster de forma eficiente. Cada partición puede configurarse con restricciones y reglas específicas, tales como límites de tiempo de ejecución, límites de memoria, prioridades, o restricciones de acceso para usuarios y grupos determinados. Esto permite organizar cargas de trabajo con diferentes necesidades dentro de una misma infraestructura, facilitando, por ejemplo, que los estudiantes tengan una partición rápida para pruebas de código y otra partición separada (con nodos más potentes o GPUs) para ejecuciones de producción pesadas.

3. Configurar Cgroups

Crear o editar el archivo /etc/slurm/cgroup.conf

Pedir al docente y copiar el archivo cgroup.conf

Chequear el contenido del archivo

Sudo nano /etc/slurm/cgroup.conf

El archivo cgroup.conf en Slurm sirve para habilitar y configurar los \"Control Groups\" (cgroups) del kernel de Linux, actuando como un mecanismo estricto de contención para los recursos de hardware de cada nodo. Su función principal es garantizar que un trabajo (job) se ejecute utilizando única y exclusivamente los recursos físicos que se le asignaron (como núcleos de CPU específicos, un límite máximo de memoria RAM y, en un futuro, el acceso a tu GPU NVIDIA), evitando que un proceso consuma más de lo solicitado e interfiera con otros trabajos que comparten la misma máquina. En resumen, mientras que el planificador lógicamente asigna los recursos, el cgroup.conf obliga al sistema operativo a hacer respetar esos límites, siendo vital para prevenir que una Raspberry Pi colapse por quedarse sin memoria (OOM) debido a la ejecución de un código mal optimizado.

  1. Copiar el archivo de configuración dado para la práctica:

/etc/slurm/cgroup_allowed_devices_file.conf

Chequear contenido con el archivo copiado

El archivo cgroup_allowed_devices_file.conf actúa como una estricta \"lista blanca\" (whitelist) de seguridad a nivel de hardware administrada por el subsistema de Control Groups de Linux. Su función es declarar exactamente qué archivos de dispositivos ubicados en el directorio `/dev/` (como los esenciales `/dev/null`, `/dev/urandom` o, de cara a tu próxima expansión, los nodos de la tarjeta gráfica como `/dev/nvidia0`) tienen permiso de ser accedidos por los trabajos de los usuarios. Puesto que el plugin `task/cgroup` bloquea por defecto la visibilidad de todos los dispositivos físicos para evitar que un proceso malicioso o mal programado corrompa el sistema, cualquier hardware que tus alumnos necesiten utilizar durante sus ejecuciones debe estar explícitamente autorizado en este archivo; de lo contrario, el sistema operativo abortará el acceso con un error de permisos (Permission denied), garantizando así el aislamiento absoluto entre los procesos y la integridad del clúster.

No hacer, es solo para tener en cuenta que el historial de Jobs se debe guardar en una base de datos.

Para instalar la base de datos. En nuestro caso no lo hacemos por las limitaciones del hardware del nodo0, estamos muy limitados con la memoria Ram.

sudo apt update

sudo apt install mariadb-server slurmdbd -y

Preparar configuración para sincronizar en nodo esclavos

  1. Copiar los archivos a la carpeta NFS. Esto facilita luego incorporar estos archivos a cada nodo esclavo

cd /etc/slurm

sudo cp slurm.conf cgroup.conf cgroup_allowed_devices_file.conf /clusterfs

sudo cp /etc/munge/munge.key /clusterfs

Levantar servicios en el nodo maestro

Iniciar Munge

1) sudo systemctl enable munge

2) sudo systemctl start munge

Iniciar el Demonio de Slurm

  1. sudo systemctl enable slurmd

  2. sudo systemctl start slurmd

Reiniciar

Es conveniente reiniciar al instalar los servicios, pero es más conveniente reiniciar por segunda vez, al incorporar los nodos esclavos.

Preparar configuración para sincronizar con los nodos esclavos

  • cd /etc/slurm

  • sudo cp slurm.conf cgroup.conf cgroup_allowed_devices_file.conf /clusterfs

  • sudo cp /etc/munge/munge.key /clusterfs

Parte 2: Preparar los nodos esclavos o workers

Instalación/configuración de sofware en nodos esclavos

Leer con cuidado, hay partes parecidas al nodo maestro, pero no todas. En los demás nodos vamos a flashear la SD, configurar el S.O. y copiar el /etc/host casi igual, pero teniendo cuidado con el nombre de cada host.

Los pasos son diferentes en cuestiones como que en los nodos esclavos NO vamos a configurar el servidor NFS, ni SLURM como servidor.

Nodo esclavos (nodo1 ,2, 3)

Sudo apt update

Sudo apt install fastfetch

Probamos la app

fastfetch

Verificar el nombre del nodo

Sudo hostname

Editar (ojo, es superimportante hacer esto, porque rpi3 tiene recursos limitados)\ sudo nano /boot/firmware/cmdline.txt

Agregar al final, un espacio, no dar enter!!!\ cgroup_enable=memory cgroup_memory=1 swapaccount=1

Sudo reboot

Lista de hots locales

Editamos el archivos hosts para que cada nodo conozca a los demas por nombre en vez de dirección IP.

sudo nano /etc/cloud/cloud.cfg

busca y comenta la línea como en la figura: - update_etc_hosts

{width="4.9522058180227475in" height="4.677083333333333in"}

sudo nano /etc/hosts

Agregamos lo siguiente, en este ejemplo seria el nodo esclavo nodo1, en los demás nodos es un poco diferente:

{width="4.608333333333333in" height="3.3333333333333335in"}

Instalacion de NtpDate

ntpdate es un programa y comando de Linux utilizado para sincronizar rápidamente el reloj del sistema con un servidor remoto del Protocolo de Tiempo de Red (NTP). Es fundamental para evitar desajustes de tiempo que puedan causar fallos en los registros o en el intercambio de datos.

sudo apt update

sudo apt install ntpsec-ntpdate -y

Instalar Slurm cliente

sudo apt install slurmd slurm-client -y

Montar unidad de red

sudo apt install nfs-common -y

crear punto de montaje

sudo mkdir -p /clusterfs

Incorporar en fstab

Sudo nano /etc/fstab

Agregar la línea (ojo va con tab)

192.168.1.190:/clusterfs /clusterfs nfs defaults 0 0

Montar la unidad compartida

sudo mount --a (quizás deben ejcutarlo dos veces)

Obtener configuración de slurm y munge para el nodo esclavo

sudo cp /cluterfs/munge.key /etc/munge/munge.key

sudo cp /clusterfs/slurm.conf /etc/slurm/slurm.conf

sudo cp /clusterfs/cgroup* /etc/slurm\ \ Si les da error al copier es por los permisos, tienen que ser root, para ello primero cambian el pass de root con el comando:

sudo passwd root (anotar, porque este password debe ser el mismo en todos los nodos)

Iniciar munge:

sudo systemctl enable munge

sudo systemctl start munge

Iniciar el Demonio de Slurm

sudo systemctl enable slurmd

sudo systemctl start slurmd

Iniciar el Demonio de Control de Slurm

sudo systemctl enable slurmctld

sudo systemctl start slurmctld

Reiniciar

Es conveniente reiniciar al instalar los servicios, pero es más conveniente reiniciar por segunda vez, al incorporar los nodos esclavos.

Parte 3: Probar el cluster

Validación con pruebas

1. Ejecutar: srun --nodes=2 hostname.

srun --nodes=3 hostname

srun --ntasks=3 hostname

srun --nodes=4 --ntasks-per-node=4 hostname

Instalación bibliotecas de programación

Entrega del Informe

Cada grupo deberá entregar un informe con la siguiente estructura:

  • Título de la práctica y nombres del grupo.

  • • Resumen general.

  • • Descripción detallada de los pasos realizados.

  • • Comandos utilizados (explicados).

  • • Problemas encontrados y cómo se resolvieron.

  • • Capturas de pantalla de consola y salidas de Slurm.

  • • Conclusiones: qué aprendieron, qué dudas quedaron.

Evaluación

El docente evaluará:

  • • Participación activa y colaboración en el grupo.

  • • Comprensión de los conceptos y comandos aplicados.

  • • Claridad y calidad del informe entregado.

  • • Resolución de problemas y actitud crítica frente a las dificultades.

Ejercicios Prácticos de Verificación y Troubleshooting

Además de completar las fases de instalación y configuración, cada grupo deberá realizar los siguientes ejercicios para comprobar el funcionamiento del clúster y documentar posibles fallos:

  1. Verificar conectividad de red:

  2. Ejecutar ping entre los tres nodos (ping node01, ping node02, ping node03).

  3. Capturar salida y confirmar que no hay pérdida de paquetes.

  4. Validar autenticación SSH:

  5. Desde node01 conectarse por SSH sin contraseña a node02 y node03.

  6. Si se solicita contraseña, revisar configuración de claves SSH.

  7. Comprobación de NFS:

  8. En node02 y node03 ejecutar: mount | grep /shared/home.

  9. Crear un archivo de prueba en /shared/home desde node01 y verificar que aparezca en los otros nodos.

  10. Verificación de Munge:

  11. En cada nodo ejecutar: munge -n | unmunge.

  12. Confirmar que la salida es válida y consistente.

  13. Verificación de Slurm:

  14. En node01 ejecutar: sinfo -N -l y comprobar que los tres nodos figuran como disponibles (STATE=IDLE).

  15. Enviar un trabajo interactivo: srun -N2 hostname.

  16. Troubleshooting frecuente:

  17. Nodo DOWN en sinfo → revisar slurmd.log y conectividad de red.

  18. Munge no responde → confirmar que la munge.key es idéntica en todos los nodos y permisos 400.

  19. Problemas con NFS → revisar /etc/exports en node01 y usar exportfs -v.

  20. Error de configuración de Slurm → verificar que el slurm.conf sea idéntico en todos los nodos (usar md5sum).