Contrario a la creencia popular, obtener acceso a un superordenador es la parte fácil; el verdadero desafío es evitar que su investigación se estanque por errores de software, gestión de datos y desconocimiento de la ‘etiqueta del clúster’.
- Los scripts de Python no se aceleran automáticamente y requieren un diseño de paralelismo consciente para superar limitaciones como el Global Interpreter Lock (GIL).
- La estimación de tiempos de ejecución y la gestión eficiente de archivos en sistemas paralelos son tan críticas como el algoritmo para que sus trabajos no sean cancelados y sus datos no creen cuellos de botella.
Recomendación: Trate el acceso a la supercomputación no como un recurso ilimitado, sino como una habilidad que se debe dominar, optimizando tanto el código como la interacción con el sistema para obtener resultados válidos y eficientes.
Para un investigador o un doctorando que trabaja con simulaciones complejas, la promesa de la supercomputación es inmensa. Acceder a miles de núcleos de procesamiento puede significar la diferencia entre una tesis completada a tiempo y un proyecto estancado por falta de capacidad de cómputo. En España, redes como la Red Española de Supercomputación (RES) ofrecen una puerta de entrada a estas infraestructuras de clase mundial, a menudo sin coste directo para la investigación académica. Sin embargo, la experiencia de muchos demuestra que conseguir las horas de cómputo es solo el primer paso de un camino lleno de obstáculos técnicos y conceptuales que rara vez se explican en las guías de solicitud.
El enfoque habitual se centra en el procedimiento: cómo rellenar los formularios de acceso o qué méritos científicos son necesarios. Se da por sentado que, una vez concedido el acceso, el investigador sabrá cómo transformar esos Teraflops en conocimiento científico. Pero, ¿qué ocurre cuando un script de Python, que funciona perfectamente en un portátil, se niega a escalar en un clúster de 1000 núcleos? ¿O cuando un trabajo es cancelado repetidamente por el planificador (scheduler) por exceder un tiempo de ejecución que era imposible de predecir? Estos problemas no son excepciones, sino la norma para quienes se inician en el High-Performance Computing (HPC).
Este artículo adopta una perspectiva diferente. En lugar de enfocarnos en el «cómo solicitar», nos centraremos en el «cómo utilizar eficazmente». La verdadera barrera no es burocrática, sino de conocimiento. La clave no reside únicamente en la potencia del hardware, sino en comprender las reglas no escritas del software, la gestión de datos y la propia arquitectura del sistema. Abordaremos los problemas prácticos que sabotean la productividad de la investigación, desde los cuellos de botella del software hasta el coste ambiental de una simulación ineficiente, ofreciendo estrategias concretas para que pueda convertir el potencial de la supercomputación en resultados tangibles y fiables para su proyecto.
A lo largo de las siguientes secciones, desglosaremos los desafíos más comunes y las soluciones prácticas que le permitirán navegar con éxito en el entorno de la supercomputación pública. Este es un manual de campo para el investigador que necesita resultados, no solo acceso.
Sumario: Claves para dominar el uso de clústeres de investigación
- ¿Por qué su script de Python no aprovecha los 1000 núcleos del clúster universitario?
- Cómo estimar el tiempo de ejecución para que el administrador del clúster no cancele su trabajo
- Sistemas de archivos paralelos: cómo leer Terabytes de datos sin crear un cuello de botella
- El coste ambiental de su simulación: cómo optimizar algoritmos para consumir menos energía
- Cuándo confiar en el modelo digital: validación de resultados en ingeniería de fluidos
- Hilos (Threads) o Procesos: ¿cuál aprovecha mejor los núcleos de un servidor moderno?
- Cómo configurar reglas automáticas para mover archivos antiguos a almacenamiento más barato
- Cómo reducir la factura de la nube un 40% al entrenar modelos propios
¿Por qué su script de Python no aprovecha los 1000 núcleos del clúster universitario?
Es uno de los escenarios más frustrantes para un investigador: después de obtener acceso a un potente clúster, ejecuta su script de Python y observa que el uso de CPU apenas supera un solo núcleo. La causa fundamental suele ser el Global Interpreter Lock (GIL), un mecanismo interno de Python que impide que múltiples hilos (threads) ejecuten código de Python en paralelo dentro de un mismo proceso. Aunque su intención es simplificar la gestión de memoria, en el contexto de HPC se convierte en un cuello de botella crítico, haciendo que el paralelismo basado en hilos sea ineficaz para tareas intensivas en CPU.
Para superar esta limitación, el enfoque debe cambiar del paralelismo de hilos al paralelismo de procesos. A diferencia de los hilos, cada proceso tiene su propio intérprete de Python y su propio GIL, lo que les permite ejecutarse en diferentes núcleos de forma verdaderamente simultánea. Sin embargo, gestionar múltiples procesos introduce su propia complejidad, especialmente en la comunicación y sincronización de datos. Afortunadamente, existen bibliotecas diseñadas específicamente para abstraer esta complejidad en entornos de HPC.
Una de las soluciones más potentes es el uso de bibliotecas como Dask. Dask es una biblioteca de código abierto que escala las herramientas familiares del ecosistema PyData (como NumPy y Pandas) para que funcionen en entornos distribuidos. Permite ejecutar computaciones de forma «diferida» (lazy), construyendo un grafo de tareas que luego un planificador optimiza y distribuye entre los procesos de trabajo disponibles en el clúster. Para la integración con gestores de trabajos como Slurm, paquetes como `dask-mpi` facilitan el lanzamiento del número correcto de procesos en múltiples nodos, permitiendo que su código finalmente aproveche los recursos asignados.
- Reconocer la limitación del GIL: Entender que el código Python puro no se paralelizará con hilos; sin embargo, las operaciones en librerías como NumPy o Pandas, que internamente usan código C, sí pueden hacerlo.
- Usar el planificador adecuado: Configurar el planificador para usar ‘processes’ en lugar de ‘threads’ para código Python que realiza cálculos intensivos.
- Implementar operaciones ‘lazy’: Utilizar las `futures` de Dask para que las operaciones se planifiquen antes de ejecutarse, permitiendo una optimización global del cómputo.
- Integrar con el clúster: Para trabajos multi-nodo, emplear herramientas como `dask-mpi` que actúan como puente entre Dask y el gestor de trabajos del clúster (ej. Slurm).
Cómo estimar el tiempo de ejecución para que el administrador del clúster no cancele su trabajo
En un entorno de supercomputación compartido, los recursos son gestionados por un planificador de trabajos (scheduler) cuyo objetivo es maximizar el uso del sistema y garantizar un acceso equitativo para todos los usuarios. Una de las directivas más importantes que un investigador debe proporcionar al enviar un trabajo es el tiempo de ejecución solicitado (wall-time). Si su trabajo excede este límite, el planificador lo cancelará sin previo aviso, provocando la pérdida de todo el cómputo realizado. Por el contrario, solicitar un tiempo excesivamente largo puede hacer que su trabajo permanezca en la cola durante días, esperando una ventana de disponibilidad lo suficientemente grande.
Estimar este tiempo con precisión es un arte que se perfecciona con la experiencia, pero existen estrategias sistemáticas para evitar conjeturas. Es un aspecto clave de la «etiqueta del clúster», ya que demuestra respeto por los recursos compartidos y por los demás usuarios. Las políticas de acceso, como las de la RES, donde las peticiones se evalúan cada cuatro meses, subrayan la importancia de planificar los proyectos a largo plazo y utilizar los recursos de manera eficiente desde el principio.
Para desarrollar estimaciones fiables, es fundamental adoptar un enfoque metódico. Ninguna estrategia es perfecta por sí sola, pero su combinación proporciona una red de seguridad robusta contra las cancelaciones inesperadas y las largas esperas en la cola.
| Estrategia | Descripción | Ventaja Principal | Cuándo Usar |
|---|---|---|---|
| Pruebas de escalabilidad | Ejecutar el trabajo con un subconjunto pequeño del dataset (ej. 1-5%) para extrapolar el tiempo total. | Proporciona una estimación rápida y de bajo coste para una primera aproximación. | Ideal para las primeras ejecuciones de un nuevo código o problema. |
| Checkpointing frecuente | Guardar el estado de la simulación a intervalos regulares (ej. cada hora). | Minimiza la pérdida de cómputo en caso de cancelación; se puede reanudar desde el último punto de control. | Esencial para trabajos largos, que se esperan que duren más de 24 horas. |
| Colas debug/interactive | Utilizar las colas de desarrollo, que tienen límites de tiempo cortos pero acceso casi inmediato. | Permite validar que el script se inicia correctamente y obtener un perfil de rendimiento inicial. | Imprescindible durante la fase de depuración y para pruebas rápidas de configuración. |
| Diario de rendimiento | Mantener un registro sistemático del tiempo de ejecución en función del tamaño del problema y el número de núcleos. | Genera un modelo predictivo preciso para futuras ejecuciones del mismo proyecto. | Recomendado para proyectos de investigación recurrentes y a largo plazo. |
Sistemas de archivos paralelos: cómo leer Terabytes de datos sin crear un cuello de botella
En la supercomputación, el rendimiento no solo depende de la velocidad de los procesadores, sino también de la capacidad del sistema para leer y escribir datos a gran velocidad. Cuando cientos o miles de procesos intentan acceder a los datos simultáneamente, un sistema de archivos convencional se convierte en un cuello de botella masivo. Para solucionar esto, los clústeres de HPC utilizan sistemas de archivos paralelos (como Lustre o GPFS), diseñados para manejar miles de operaciones de E/S (Entrada/Salida) concurrentes.
Estos sistemas distribuyen los datos a través de múltiples servidores de almacenamiento, permitiendo que diferentes partes de un archivo grande sean leídas o escritas en paralelo por diferentes procesos. Supercomputadores como el MareNostrum 4 ilustran esta escala, con una arquitectura que incluye 48 racks con 3,456 nodos de cómputo y cinco racks de almacenamiento con capacidad para 14 petabytes de datos. Sin embargo, para aprovechar esta capacidad, el investigador no puede tratar este sistema como el disco duro de su portátil. Acceder a él de forma ineficiente puede ralentizar no solo su propio trabajo, sino el de todos los usuarios del clúster.
La «etiqueta del sistema de archivos» es crucial. Una de las peores prácticas es crear millones de archivos pequeños. Cada operación de apertura y cierre de un archivo consume recursos del sistema de metadatos, que es un recurso centralizado y limitado. Comandos aparentemente inofensivos como `ls -l` en un directorio con millones de archivos pueden sobrecargar este sistema y causar una degradación del rendimiento para todos. La estrategia correcta es consolidar los datos en archivos grandes y estructurados, utilizando formatos optimizados para el acceso paralelo.
- Usar formatos de archivo paralelos: Formatos como HDF5 o NetCDF están diseñados para el acceso concurrente. Permiten que múltiples procesos lean o escriban en diferentes partes de un mismo archivo sin conflictos, e incluyen metadatos que describen la estructura de los datos.
- Evitar archivos pequeños: En lugar de guardar cada resultado en un archivo de texto separado, agrúpelos en un único archivo binario más grande.
- Limitar las operaciones de metadatos: Evite listar o realizar operaciones en directorios con un número masivo de archivos. Organice sus datos en una estructura de directorios jerárquica y profunda.
- Utilizar almacenamiento temporal (scratch): La mayoría de los clústeres ofrecen un espacio de ‘scratch’ de alta velocidad para los datos activos de un trabajo. Use este espacio para la E/S intensiva y mueva los resultados finales al almacenamiento permanente (‘home’ o ‘project’) al final del trabajo.
El coste ambiental de su simulación: cómo optimizar algoritmos para consumir menos energía
El poder de la supercomputación tiene un coste asociado que a menudo se pasa por alto: un enorme consumo de energía. Un solo superordenador puede consumir varios megavatios, el equivalente a la energía de una pequeña ciudad. Optimizar el código no es solo una cuestión de obtener resultados más rápido, sino también una responsabilidad ética y económica para reducir la huella de carbono de la investigación científica. La refrigeración de estos centros de datos puede suponer hasta el 40% de su consumo total, lo que ha llevado a innovaciones como la del superordenador Lumi en Finlandia, que utiliza su calor residual para la red de calefacción urbana de la ciudad.
Desde la perspectiva del investigador, la optimización energética se puede abordar a nivel de hardware y de software. A nivel de hardware, el uso de aceleradoras como las GPU (Unidades de Procesamiento Gráfico) en lugar de las CPU tradicionales puede ofrecer una eficiencia energética drásticamente mayor para ciertos tipos de algoritmos, especialmente en el campo del aprendizaje automático y las simulaciones con estructuras de datos regulares. De hecho, los fabricantes se han fijado metas ambiciosas; por ejemplo, AMD tiene el objetivo de aumentar la eficiencia energética de sus procesadores 30 veces entre 2020 y 2025.
A nivel de software, una de las palancas más efectivas y accesibles para el investigador es la elección de la precisión numérica. No todas las partes de una simulación requieren la máxima precisión. Reducir la precisión de los números de punto flotante no solo acelera los cálculos, sino que también disminuye significativamente el consumo de energía, ya que se mueven menos datos y las operaciones aritméticas son más simples.
| Precisión | Bits | Consumo Relativo | Velocidad Relativa | Aplicación Ideal |
|---|---|---|---|---|
| Doble precisión | 64-bit | 100% | 1x | Simulaciones científicas que requieren alta fidelidad y estabilidad numérica. |
| Simple precisión | 32-bit | ~50% | ~2x | Entrenamiento de modelos de Machine Learning, gráficos computacionales. |
| Media precisión | 16-bit | ~25% | ~4x | Inferencia de IA, entrenamiento de deep learning con técnicas de precisión mixta. |
Cuándo confiar en el modelo digital: validación de resultados en ingeniería de fluidos
Una simulación computacional, por muy compleja y visualmente impresionante que sea, no es más que un modelo matemático de la realidad. Su utilidad depende por completo de su capacidad para predecir con fiabilidad el comportamiento del sistema físico que representa. En campos como la ingeniería de fluidos (CFD), la astrofísica o el diseño de fármacos, donde las decisiones pueden tener consecuencias críticas, la pregunta «¿puedo confiar en estos resultados?» es primordial. La supercomputación permite realizar simulaciones de una complejidad antes impensable, pero también amplifica el riesgo de que errores sutiles en el modelo o en el código generen resultados fundamentalmente incorrectos.
Por esta razón, un proceso riguroso de Verificación y Validación (V&V) no es un paso opcional, sino una parte integral del método científico computacional. La verificación se ocupa de asegurar que el código resuelve correctamente las ecuaciones matemáticas del modelo («¿estoy resolviendo bien las ecuaciones?»). La validación, por otro lado, se encarga de determinar si el modelo matemático es una representación adecuada de la realidad física («¿estoy resolviendo las ecuaciones correctas?»). Esto se logra comparando los resultados de la simulación con soluciones analíticas conocidas o con datos experimentales.
Este proceso debe ser sistemático y multifacético, construyendo confianza en el modelo de manera incremental. No se trata de una única prueba, sino de una campaña de pruebas que examinan el comportamiento del modelo bajo diferentes condiciones. La capacidad de los superordenadores se utiliza en una amplia gama de investigaciones críticas, desde la investigación del genoma humano hasta la predicción meteorológica, lo que refuerza la necesidad de un marco de validación robusto para garantizar la fiabilidad de los hallazgos científicos. Implementar un protocolo de V&V es esencial antes de publicar resultados o tomar decisiones basadas en ellos.
Plan de acción para la Verificación y Validación (V&V) de su modelo
- Validación con casos canónicos: Comience por comparar los resultados de su simulación con problemas que tienen una solución analítica exacta conocida (ej. flujo de Couette, problema de Stokes). Esto verifica la corrección fundamental de su código.
- Comparación con benchmarks: Compare sus resultados con benchmarks experimentales bien documentados y aceptados por la comunidad científica (ej. flujo sobre un cilindro, cavidad de tapa móvil).
- Análisis de convergencia de malla: Realice la simulación con mallas de resolución progresivamente más finas. Los resultados deben converger hacia una solución estable, demostrando que no son un artefacto de la discretización.
- Análisis de sensibilidad: Varíe sistemáticamente los parámetros de entrada clave (ej. viscosidad, condiciones de contorno) en un pequeño rango (ej. ±10%) para asegurar que la respuesta del modelo es físicamente coherente y no caótica.
- Validación con datos experimentales propios: Si es posible, compare el modelo 3D completo con datos obtenidos de experimentos reales realizados en su laboratorio o por colaboradores. Esta es la prueba de validación definitiva.
Hilos (Threads) o Procesos: ¿cuál aprovecha mejor los núcleos de un servidor moderno?
En el corazón del paralelismo se encuentra una decisión fundamental: ¿debería mi aplicación utilizar hilos (threads) o procesos para distribuir el trabajo? Aunque ambos permiten la ejecución concurrente de tareas, su funcionamiento y sus implicaciones de rendimiento son drásticamente diferentes, especialmente en las arquitecturas de memoria de los servidores HPC modernos. La elección correcta depende de la naturaleza del problema a resolver y de cómo se comunican las diferentes partes del cómputo.
Los hilos son unidades de ejecución ligeras que operan dentro de un mismo proceso y, crucialmente, comparten el mismo espacio de memoria. Esto hace que la comunicación entre ellos sea extremadamente rápida, ya que pueden leer y escribir en las mismas variables. Sin embargo, esta ventaja es también su mayor riesgo: la necesidad de sincronizar el acceso a la memoria compartida para evitar condiciones de carrera (race conditions) puede introducir una sobrecarga significativa y errores complejos de depurar. Además, el paralelismo basado en hilos está, por lo general, limitado a los núcleos de un único nodo de cómputo.
Los procesos, por otro lado, son más pesados y cada uno tiene su propio espacio de memoria aislado. Esta separación los hace más robustos y seguros, ya que un error en un proceso no afecta a los demás. La comunicación entre ellos es más lenta, ya que debe realizarse a través de mecanismos explícitos de comunicación entre procesos (IPC), como pipes o sockets, o a través de bibliotecas estandarizadas como MPI (Message Passing Interface). La gran ventaja de los procesos es su escalabilidad: pueden distribuirse fácilmente a través de múltiples nodos del clúster, permitiendo un paralelismo masivo. Para las simulaciones más complejas, a menudo se emplean enfoques híbridos, usando MPI para la comunicación entre nodos y un modelo de memoria compartida como OpenMP dentro de cada nodo.
| Característica | Threads (Hilos) | Procesos | Híbrido MPI+OpenMP |
|---|---|---|---|
| Memoria | Compartida, rápida pero propensa a errores. | Aislada, más lenta pero más segura. | Mixta, optimizada por nivel de paralelismo. |
| Comunicación | Muy rápida (variables compartidas). | Lenta (IPC, MPI). | Optimizada para cada nivel (rápida dentro del nodo, explícita entre nodos). |
| Escalabilidad | Limitada a los núcleos de un único nodo. | Escala a través de múltiples nodos del clúster. | Máxima escalabilidad en sistemas a gran escala. |
| Overhead | Bajo (creación y gestión ligeras). | Alto (creación y gestión más costosas). | Medio, equilibrado según la tarea. |
| Uso ideal | Tareas pequeñas y acopladas dentro de un nodo (paralelismo de grano fino). | Tareas grandes e independientes (paralelismo de grano grueso). | Aplicaciones HPC a gran escala que requieren múltiples niveles de paralelismo. |
Cómo configurar reglas automáticas para mover archivos antiguos a almacenamiento más barato
El ciclo de vida de los datos en un proyecto de investigación es dinámico. Durante la fase activa de un trabajo, los datos deben residir en sistemas de almacenamiento de alto rendimiento (como el espacio ‘scratch’) para garantizar un acceso rápido. Sin embargo, una vez que el cómputo ha finalizado, estos datos de resultados, archivos intermedios y logs ocupan un espacio valioso y caro. Mantener gigabytes o terabytes de datos inactivos en el almacenamiento principal no solo es ineficiente, sino que a menudo va en contra de las políticas de uso del clúster, que pueden imponer cuotas estrictas o incluso eliminar archivos antiguos automáticamente.
Una práctica esencial de la «higiene de datos» en HPC es implementar una estrategia de gestión de almacenamiento por niveles (tiered storage). Esto implica mover automáticamente los archivos que ya no se necesitan para el cómputo activo desde el almacenamiento ‘caliente’ (rápido y caro) a un almacenamiento ‘frío’ o de archivo (más lento y barato), diseñado para la conservación a largo plazo. La potencia computacional de los sistemas modernos, como el clúster ALBAICÍN de la Universidad de Granada, que multiplica por 20 la capacidad de su predecesor, genera volúmenes de datos que hacen imprescindible una gestión automatizada.
En lugar de realizar esta tarea manualmente, lo cual es tedioso y propenso a errores, se pueden utilizar scripts sencillos y herramientas estándar de Linux para automatizar el proceso. Un script de `bash`, ejecutado periódicamente a través de un `cron job`, puede identificar, comprimir y mover archivos basándose en criterios como su fecha de último acceso (`atime`) o modificación (`mtime`). Esta automatización asegura que el espacio de trabajo se mantenga limpio, se respeten las cuotas y los datos importantes se archiven de forma segura para futuras referencias o publicaciones.
A continuación se presentan algunos comandos que pueden formar la base de un script de gestión de archivos:
- Identificar archivos no accedidos: `find /ruta/al/proyecto -type f -atime +90` lista todos los archivos que no han sido accedidos en los últimos 90 días.
- Comprimir archivos de datos antiguos: `find /ruta/al/proyecto -name ‘*.dat’ -mtime +30 -exec gzip {} ;` busca todos los archivos `.dat` modificados hace más de 30 días y los comprime.
- Mover a almacenamiento de archivo: `rsync -av –remove-source-files /ruta/origen/ /ruta/archivo/` sincroniza los datos al directorio de archivo y elimina los originales tras una copia exitosa.
- Limpiar el espacio ‘scratch’: `find /ruta/scratch -type f -atime +7 -delete` elimina automáticamente los archivos en el espacio temporal que no se han usado en una semana.
- Mantener un registro: Es una buena práctica registrar las operaciones en un archivo de log para poder rastrear qué se ha movido y cuándo.
Puntos clave a recordar
- El verdadero desafío de la supercomputación no es el acceso, sino el uso eficiente, que requiere entender el software, la gestión de datos y la ‘etiqueta del clúster’.
- El paralelismo no es automático: limitaciones como el GIL de Python exigen un diseño consciente con procesos y herramientas como Dask para escalar en múltiples núcleos.
- La gestión proactiva de recursos, estimando tiempos de ejecución, validando resultados y optimizando el consumo energético, es tan crucial como la propia ciencia para el éxito del proyecto.
Cómo reducir la factura de la nube un 40% al entrenar modelos propios
En la era del Big Data y la Inteligencia Artificial, el entrenamiento de modelos de aprendizaje profundo puede requerir una cantidad de cómputo inmensa. Si bien los servicios en la nube (como AWS, Google Cloud o Azure) ofrecen una flexibilidad y escalabilidad casi infinitas, esta comodidad tiene un precio que puede dispararse rápidamente, especialmente para proyectos de investigación con presupuestos limitados. Aquí es donde los recursos de supercomputación pública, como los ofrecidos por la RES, presentan una alternativa estratégica fundamental.
La principal ventaja de la HPC pública para la investigación es su modelo de acceso: los recursos se asignan en base al mérito científico y están destinados a fines de I+D sin ánimo de lucro, eliminando el coste directo por hora de cómputo. Para un doctorando o un grupo de investigación, esto puede significar la diferencia entre poder o no poder llevar a cabo un proyecto. La comparación no es solo económica; los clústeres de HPC suelen contar con redes de interconexión de muy alta velocidad y sistemas de archivos paralelos optimizados, lo que puede darles una ventaja de rendimiento para ciertos trabajos a gran escala en comparación con configuraciones de nube genéricas.
Sin embargo, hay situaciones en las que la nube sigue siendo la opción preferida, por ejemplo, para trabajos más cortos e intermitentes o cuando se necesita un ecosistema de software muy específico. En estos casos, es vital aplicar una estricta disciplina de optimización de costes para evitar sorpresas en la factura. Estrategias como el uso de instancias spot o preemptibles (máquinas virtuales ofrecidas con un gran descuento a cambio de que puedan ser interrumpidas) pueden reducir los costes drásticamente, siempre que se combinen con un sistema de checkpointing frecuente para no perder el trabajo. Otras tácticas clave incluyen la configuración de clústeres de tamaño variable (autoscaling), el procesamiento de datos en la misma región geográfica donde se almacenan para evitar costosas tarifas de transferencia (egress fees) y la implementación de políticas de apagado automático.
Para asegurar el éxito y la sostenibilidad de su investigación, el siguiente paso lógico es integrar estas estrategias en su flujo de trabajo diario. Comience por auditar sus scripts actuales en busca de oportunidades de paralelización y establezca un protocolo de gestión de datos y estimación de tiempos para su próximo envío de trabajos al clúster.