Introducción del módulo

En los módulos anteriores se desarrollaron las destrezas fundamentales de la programación paralela a nivel de código y algoritmos: OpenMP para memoria compartida en CPUs multinúcleo (M2), MPI para memoria distribuida en clústeres físicos o virtuales (M3), y CUDA para aceleración masiva en procesadores gráficos (M4). Sin embargo, en el ejercicio profesional contemporáneo de la ingeniería de software y la infraestructura computacional, el software paralelo no se ejecuta de forma aislada en máquinas individuales configuradas a mano.

La supercomputación y el procesamiento masivo de datos modernos operan sobre infraestructuras complejas, dinámicas y frecuentemente multiusuario: centros de datos científicos, nubes públicas elásticas y entornos perimetrales (Edge Computing). Coordinar eficientemente estas infraestructuras exige dominar los sistemas de orquestación, gestión de colas, empaquetamiento portable en contenedores y plataformas cloud.

El Módulo 5 cierra el proyecto formativo de Sistemas Paralelos dotando al estudiante de una perspectiva pragmática, arquitectural y económica. Se analizan desde los gestores clásicos de HPC como Slurm hasta la contenerización con Docker y Singularity/Apptainer, la orquestación distribuida con Kubernetes, los paradigmas de Big Data con Apache Spark, y los modelos de despliegue en la nube pública frente a la realidad y necesidades productivas de la región del Gran Chaco y Bolivia.

Competencia que se desarrolla (EC5). Evaluar y seleccionar infraestructuras computacionales para sistemas paralelos, considerando clústeres de alto rendimiento, plataformas de computación en la nube y requerimientos del mercado regional y nacional.

5.1 Gestión de recursos en clusters: Slurm y Rocks

5.1.1 La necesidad de un gestor de recursos en entornos multiusuario

En un centro de supercomputación o clúster de investigación, decenas de investigadores y equipos necesitan ejecutar trabajos computacionalmente intensivos sobre los mismos nodos físicos. Si los usuarios ejecutaran sus programas directamente por SSH, ocurrirían colisiones catastróficas: saturación de CPU, agotamiento de memoria RAM y degradación de la red.

Un gestor de recursos y programador de trabajos (Workload Manager & Job Scheduler) resuelve este problema actuando como la autoridad central del clúster:

• Monitorea la disponibilidad de CPU, memoria, almacenamiento y GPUs en cada nodo.
• Mantiene una cola priorizada de trabajos solicitados por los usuarios.
• Asigna recursos exclusivos o compartidos según políticas justas (Fairshare).
• Despacha los trabajos cuando los recursos están libres y limpia el entorno al finalizar.

5.1.2 Arquitectura de Slurm (Simple Linux Utility for Resource Management)

Slurm es el estándar dominante en más del 60 % de los supercomputadores del ranking TOP500. Su arquitectura se compone de tres demonios principales:

1. slurmctld (Controlador central): Se ejecuta en el nodo maestro (Head Node). Administra las colas, evalúa las prioridades y programa los trabajos.
2. slurmd (Demonio de nodo de cómputo): Se ejecuta en cada nodo de cómputo (Worker Node). Monitorea el hardware local, recibe órdenes del controlador y ejecuta las tareas.
3. slurmdbd (Base de datos de contabilidad): Registra el consumo histórico de tiempo de CPU/GPU y uso de recursos por usuario y proyecto para auditoría.

       [ Cliente / Usuario ]
                 │
       ( sbatch / srun / squeue )
                 ▼
+─────────────────────────────────+
|      NODO MAESTRO (HEAD)        |
|  - slurmctld (Programador)      |
|  - slurmdbd (Contabilidad)      |
|  - NFS Server (/shared/hpc)     |
+─────────────────────────────────+
        │       │        │
    (Red de Gestión / Red de Cómputo)
        ▼       ▼        ▼
+──────────+ +──────────+ +──────────+
|  NODO 1  | |  NODO 2  | |  NODO 3  |
|  slurmd  | |  slurmd  | |  slurmd  |
|  4 cores | |  4 cores | |  4 cores |
+──────────+ +──────────+ +──────────+

5.1.3 Ciclo de trabajo con scripts sbatch

Los usuarios envían trabajos no interactivos mediante scripts en Bash que contienen directivas #SBATCH:

#!/bin/bash
#SBATCH --job-name=simulacion_mpi
#SBATCH --nodes=2
#SBATCH --ntasks-per-node=4
#SBATCH --time=01:00:00
#SBATCH --output=salida_%j.log
#SBATCH --error=error_%j.log

module load openmpi/4.1.5
mpirun ./mi_programa_mpi

Comandos cotidianos del operador de Slurm:

• sinfo: Muestra el estado operativo de los nodos y particiones.
• squeue: Lista los trabajos en cola, en ejecución o pendientes.
• sbatch script.sh: Envía un trabajo a la cola por lotes.
• scancel <job_id>: Cancela un trabajo en ejecución.

5.2 Contenerización: Docker y Singularity para HPC

5.2.1 El problema de la reproducibilidad en HPC

Tradicionalmente, compilar software científico en clústeres requería instalar manualmente decenas de bibliotecas (BLAS, LAPACK, MPI, CUDA, HDF5) con versiones de compiladores específicas (gcc-9, gcc-11). Esto generaba el infierno de dependencias (Dependency Hell) y hacía casi imposible reproducir un experimento científico en otra máquina.

Los contenedores empaquetan la aplicación junto con todo su espacio de usuario: binarios, bibliotecas del sistema, configuraciones y variables de entorno, garantizando ejecución idéntica en cualquier sistema Linux.

5.2.2 Docker frente a Singularity / Apptainer en HPC

Aunque Docker es el estándar indiscutible en la industria web y de microservicios, presenta limitaciones críticas de seguridad y arquitectura en clústeres científicos:

En la práctica moderna, se combinan ambos: los desarrolladores construyen y prueban la imagen en su estación local con Docker, y el clúster HPC ejecuta la imagen convertida a formato SIF con Apptainer.

5.3 Orquestación: Kubernetes y contenedores

5.3.1 Arquitectura de Kubernetes (K8s)

Mientras que Slurm está diseñado para trabajos por lotes que corren hasta completarse y luego mueren (batch jobs), Kubernetes nació para orquestar servicios resilientes y aplicaciones distribuidas que deben mantenerse vivas indefinidamente (long-running services).

Componentes clave de Kubernetes:

• Control Plane: API Server, etcd (almacén de estado distribuido), Scheduler y Controller Manager.
• Worker Nodes: Ejecutan el agente kubelet, el proxy de red kube-proxy y el motor de contenedores (containerd).
• Pod: La unidad mínima de despliegue, compuesta por uno o más contenedores que comparten red (localhost) y almacenamiento.

5.3.2 HPC nativo en la nube (Cloud-Native HPC)

En los últimos años, la frontera entre HPC y Kubernetes se ha estrechado mediante operadores especializados:

• Volcano: Programador de trabajos por lotes para Kubernetes que soporta gang scheduling (garantizar que todos los pods de un trabajo MPI arranquen simultáneamente o ninguno).
• KubeFlow / Ray on K8s: Orquestación distribuida de entrenamiento de modelos de Machine Learning y aprendizaje por refuerzo a gran escala.

5.4 MapReduce y Apache Spark

5.4.1 La transición del cómputo intensivo (HPC) al dato intensivo (Big Data)

HPC tradicional se enfoca en problemas con alta intensidad de cómputo sobre conjuntos de datos estructurados y compactos, donde la comunicación de baja latencia por red es vital. Por el contrario, los problemas de Big Data se caracterizan por procesar terabytes o petabytes de datos no estructurados (logs, texto web, transacciones) distribuidos en miles de discos duros comerciales.

El principio fundacional de Big Data es llevar el cómputo hacia el dato (Data Locality), en lugar de mover inmensos volúmenes de datos por la red hacia los procesadores.

5.4.2 El modelo MapReduce

Popularizado por Google y materializado en Hadoop:

1. Fase Map: Aplica una función de transformación sobre cada registro independiente, produciendo pares clave-valor (clave, valor).
2. Fase Shuffle & Sort: La plataforma redistribuye y agrupa todos los valores asociados a una misma clave a través de la red.
3. Fase Reduce: Agrega y sintetiza los valores asociados a cada clave única.

5.4.3 Apache Spark y los RDDs (Resilient Distributed Datasets)

Hadoop MapReduce escribía los resultados intermedios de cada etapa en disco duro (HDFS), haciéndolo lento para algoritmos iterativos (como Machine Learning o grafos).

Apache Spark revolucionó el procesamiento masivo al mantener los datos intermedios en la memoria RAM distribuida del clúster mediante la abstracción RDD:

• Estructura de datos inmutable, particionada y tolerante a fallos.
• Evaluación perezosa (Lazy Evaluation): las transformaciones (map, filter, join) no se ejecutan hasta que se invoca una acción (count, collect, save).
• Soporte para DataFrames, SQL distribuido, streaming en tiempo real y bibliotecas de ML (MLlib).

5.5 Modelos de computación en la nube: IaaS, PaaS, SaaS

5.5.1 Definición y taxonomía del NIST

La computación en la nube (Cloud Computing) es un modelo que permite el acceso bajo demanda a un fondo compartido de recursos computacionales configurables (redes, servidores, almacenamiento, aplicaciones y servicios), aprovisionables con mínimo esfuerzo de gestión.

+─────────────────────────────────────────────────────────────+
|  SaaS (Software as a Service)                               |
|  El usuario solo consume la aplicacion (Google Drive, Gmail)|
+─────────────────────────────────────────────────────────────+
|  PaaS (Platform as a Service)                               |
|  El usuario gestiona el codigo; la nube la infra (Heroku)   |
+─────────────────────────────────────────────────────────────+
|  IaaS (Infrastructure as a Service)                         |
|  El usuario gestiona SO, red y almacenamiento (AWS EC2, GCE)|
+─────────────────────────────────────────────────────────────+

5.5.2 HPC en IaaS: Instancias elásticas de cómputo

En el modelo IaaS, las organizaciones no compran racks de servidores físicos; alquilan máquinas virtuales o servidores dedicados (bare metal) por segundo o por hora. Esto permite:

• Elasticidad instantánea: Levantar un clúster de 128 nodos durante 3 horas para una simulación urgente y destruirlo al terminar, pagando solo por el tiempo consumido.
• Acceso a hardware de vanguardia: GPUs de última generación (NVIDIA H100 / Blackwell) sin inversión inicial de capital (CapEx frente a OpEx).

5.6 Proveedores cloud: AWS, Azure, GCP y alternativas locales

5.6.1 Los tres gigantes de la nube pública

• Amazon Web Services (AWS): Ofrece AWS ParallelCluster (herramienta que levanta clústeres Slurm en minutos sobre instancias EC2 con interconexión EFA — Elastic Fabric Adapter de baja latencia) y AWS Batch.
• Microsoft Azure: Fuerte presencia en HPC empresarial con instancias equipadas con tarjetas de red InfiniBand nativas de 200 Gbps y orquestación con Azure CycleCloud.
• Google Cloud Platform (GCP): Líder en infraestructura de datos, Kubernetes administrado (GKE) y hardware acelerador especializado en IA (TPUs, Tensor Processing Units).

5.6.2 Comparativa técnica y económica para HPC

Aunque la nube ofrece flexibilidad inigualable, mantener un clúster corriendo las 24 horas del día durante todo el año en la nube pública es sustancialmente más costoso que operar hardware propio en un centro de datos local (On-Premise). La decisión ingenieril óptima suele ser una arquitectura híbrida: una base local estable para la carga regular y desbordamiento (cloud bursting) a la nube pública ante picos de demanda.

5.7 Edge computing y computación en el borde

5.7.1 La necesidad del cómputo en el borde

En muchas aplicaciones de ingeniería en campo (monitoreo ambiental, estaciones meteorológicas rurales, agricultura de precisión o sensores en gasoductos), enviar terabytes de datos crudos hacia un centro de datos en la nube es inviable debido a:

• Ancho de banda de red limitado, costoso o intermitente en áreas rurales.
• Requerimientos de latencia ultrabaja para respuestas en tiempo real (milisegundos).
• Privacidad y soberanía de los datos locales.

5.7.2 Arquitectura Cloud-to-Edge

Edge Computing despliega capacidad de cómputo paralelo en dispositivos cercanos a la fuente generadora del dato (procesadores embebidos con aceleradores como NVIDIA Jetson, Raspberry Pi con NPU, o servidores de borde industriales). El dispositivo procesa, filtra y toma decisiones localmente, enviando a la nube únicamente resúmenes compactos o alertas anómalas.

5.8 Aplicaciones en contexto local: GIS, simulaciones, IA/ML

5.8.1 Oportunidades de impacto en el Gran Chaco y Tarija

El departamento de Tarija y la región del Gran Chaco presentan desafíos estratégicos donde los sistemas paralelos y distribuidos ofrecen soluciones transformadoras:

1. Monitoreo hídrico y ambiental de la cuenca del Río Pilcomayo: Procesamiento en tiempo real de caudales, transporte de sedimentos y calidad del agua para alerta temprana de inundaciones en comunidades ribereñas.
2. Detección y modelado de focos de calor e incendios forestales: Análisis distribuido de imágenes satelitales (Sentinel-2, Landsat) combinadas con variables climáticas (temperatura, viento, humedad) para predecir la propagación de fuego en el bosque chaqueño.
3. Optimización de la cadena vitivinícola en los valles de Tarija: Simulación microclimática y modelos de estrés hídrico mediante procesamiento paralelo de redes de sensores agrícolas.
4. Logística de transporte y comercio transfronterizo en Yacuiba: Sistemas de visión artificial acelerada por GPU para control y optimización del tráfico de carga en el paso fronterizo con Argentina.

El ingeniero informático formado en TEL-420 posee las herramientas conceptuales y prácticas para articular estas tecnologías, diseñando sistemas paralelos eficientes, reproducibles y económicamente sostenibles para la región.