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
-
Enchufamos el pendrive que actuará como unidad compartida, recordar donde se enchufó, luego no se podrá cambiar de pueto usb
-
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
- Formatear
Ejecutar
sudo mkfs.ext4 /dev/sda1
- Preparación de punto de montaje
Ejecutar en orden
sudo mkdir /clusterfs
sudo chown nobody:nogroup -R /clusterfs
sudo chmod 777 -R /clusterfs
- 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
-
sudo chown nobody:nogroup -R /clusterfs
-
sudo chmod 777 /clusterfs --R
-
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.
- 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:
- Instalar Slurm
sudo apt install slurm-wlm -y
- 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.
- 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
- 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
-
sudo systemctl enable slurmd
-
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:
-
Verificar conectividad de red:
-
Ejecutar ping entre los tres nodos (ping node01, ping node02, ping node03).
-
Capturar salida y confirmar que no hay pérdida de paquetes.
-
Validar autenticación SSH:
-
Desde node01 conectarse por SSH sin contraseña a node02 y node03.
-
Si se solicita contraseña, revisar configuración de claves SSH.
-
Comprobación de NFS:
-
En node02 y node03 ejecutar: mount | grep /shared/home.
-
Crear un archivo de prueba en /shared/home desde node01 y verificar que aparezca en los otros nodos.
-
Verificación de Munge:
-
En cada nodo ejecutar: munge -n | unmunge.
-
Confirmar que la salida es válida y consistente.
-
Verificación de Slurm:
-
En node01 ejecutar: sinfo -N -l y comprobar que los tres nodos figuran como disponibles (STATE=IDLE).
-
Enviar un trabajo interactivo: srun -N2 hostname.
-
Troubleshooting frecuente:
-
Nodo DOWN en sinfo → revisar slurmd.log y conectividad de red.
-
Munge no responde → confirmar que la munge.key es idéntica en todos los nodos y permisos 400.
-
Problemas con NFS → revisar /etc/exports en node01 y usar exportfs -v.
-
Error de configuración de Slurm → verificar que el slurm.conf sea idéntico en todos los nodos (usar md5sum).