Content from ¿Por qué utilizar un clúster?

Última actualización: 2025-08-04 | Mejora esta página

Hoja de ruta

Preguntas

  • ¿Por qué me interesa la computación de alto rendimiento (HPC)?
  • ¿Qué puedo esperar aprender de este curso?

Objetivos

  • Describa qué es un sistema HPC
  • Identifique cómo podría beneficiarle un sistema HPC.

Con frecuencia, los problemas de investigación que utilizan la computación pueden superar las capacidades del ordenador de sobremesa o portátil en el que comenzaron:

  • Un estudiante de estadística quiere validar un modelo de forma cruzada. Para ello, debe ejecutar el modelo 1.000 veces, pero cada ejecución tarda una hora. Ejecutar el modelo en un ordenador portátil llevaría más de un mes En este problema de investigación, los resultados finales se calculan después de ejecutar los 1000 modelos, pero normalmente sólo se ejecuta un modelo a la vez (en serie) en el portátil. Dado que cada una de las 1000 ejecuciones es independiente de las demás, y si se dispone de suficientes ordenadores, en teoría es posible ejecutarlas todas a la vez (en paralelo).
  • Un investigador en genómica ha estado utilizando pequeños conjuntos de datos de secuenciación, pero pronto recibirá un nuevo tipo de datos de secuenciación que es 10 veces más grande. Abrir los conjuntos de datos en un ordenador ya supone un reto; analizar estos conjuntos de datos más grandes probablemente lo colapsará. En este problema de investigación, los cálculos necesarios podrían ser imposibles de paralelizar, pero se necesitaría un ordenador con más memoria para analizar el futuro conjunto de datos mucho mayor.
  • Un ingeniero está utilizando un paquete de dinámica de fluidos que tiene una opción para ejecutarse en paralelo. Hasta ahora, esta opción no se utilizaba en un ordenador de sobremesa. Al pasar de simulaciones 2D a 3D, el tiempo de simulación se ha más que triplicado. Podría ser útil aprovechar esa opción o característica. En este problema de investigación, los cálculos en cada región de la simulación son en gran medida independientes de los cálculos en otras regiones de la simulación. Es posible ejecutar los cálculos de cada región simultáneamente (en paralelo), comunicar los resultados seleccionados a las regiones adyacentes según sea necesario y repetir los cálculos para converger en un conjunto final de resultados. Al pasar de un modelo 2D a un modelo 3D, tanto la cantidad de datos como la cantidad de cálculos aumentan enormemente, y en teoría es posible distribuir los cálculos entre varios ordenadores que se comunican a través de una red compartida.

En todos estos casos, se necesita acceso a más ordenadores (y más grandes). Esos ordenadores deben poder utilizarse al mismo tiempo, resolviendo en paralelo los problemas de muchos investigadores.

Presentación de Jargon Busting

Abra el HPC Jargon Buster en una nueva pestaña. Para presentar el contenido, pulse C para abrir un clone en una ventana separada, después pulse P para cambiar el modo de presentación.

Nunca he usado un servidor, ¿verdad?

Tómese un minuto y piense cuáles de sus interacciones diarias con un ordenador pueden requerir un servidor remoto o incluso un clúster para proporcionarle resultados.

  • Comprobación del correo electrónico: su ordenador (posiblemente en el bolsillo) se pone en contacto con una máquina remota, se autentica y descarga una lista de mensajes nuevos; también carga los cambios en el estado del mensaje, como si lo ha leído, marcado como basura o borrado. Como la suya no es la única cuenta, el servidor de correo es probablemente uno de tantos en un centro de datos.
  • Buscar una frase en Internet implica comparar el término de búsqueda con una base de datos masiva de todos los sitios conocidos, en busca de coincidencias. Esta operación de “consulta” puede ser sencilla, pero construir esa base de datos es una tarea monumental Los servidores intervienen en cada paso.
  • Buscar direcciones en un sitio web de mapas implica conectar los puntos (A) inicial y (B) final recorriendo un grafo en busca del camino “más corto” por distancia, tiempo, gasto u otra métrica. Convertir un mapa en la forma correcta es relativamente sencillo, pero calcular todas las rutas posibles entre A y B es costoso.

Consultar el correo electrónico podría ser en serie: su máquina se conecta a un servidor e intercambia datos. La búsqueda en la base de datos del término de búsqueda (o puntos finales) también podría ser en serie, ya que una máquina recibe la consulta y devuelve el resultado. Sin embargo, montar y almacenar la base de datos completa supera con creces la capacidad de una sola máquina. Por lo tanto, estas funciones se realizan en paralelo mediante una gran colección de servidores [“hiperescala”][hiperescala] que trabajan juntos.

Puntos Clave

  • La computación de alto rendimiento (HPC) suele implicar la conexión a sistemas informáticos muy grandes de otras partes del mundo.
  • Estos otros sistemas pueden utilizarse para realizar tareas que serían imposibles o mucho más lentas en sistemas más pequeños.
  • Los recursos HPC son compartidos por múltiples usuarios.
  • El método estándar de interacción con estos sistemas es a través de una interfaz de línea de comandos.

Content from Conexión a un sistema HPC remoto

Última actualización: 2025-08-04 | Mejora esta página

Hoja de ruta

Preguntas

  • ¿Cómo me conecto a un sistema HPC remoto?

Objetivos

  • Configure el acceso seguro a un sistema HPC remoto.
  • Conéctate a un sistema HPC remoto.

Conexiones seguras

El primer paso para utilizar un cluster es establecer una conexión desde nuestro portátil al cluster. Cuando estamos sentados frente a un ordenador (o de pie, o sosteniéndolo en nuestras manos o en nuestras muñecas), hemos llegado a esperar una pantalla visual con iconos, widgets, y quizás algunas ventanas o aplicaciones: una interfaz gráfica de usuario, o GUI. Dado que los clusters de ordenadores son recursos remotos a los que nos conectamos a través de interfaces lentas o intermitentes (WiFi y VPNs especialmente), es más práctico usar una interfaz de línea de comandos, o CLI, para enviar comandos como texto plano. Si un comando devuelve una salida, también se imprime como texto plano. Los comandos que ejecutaremos hoy no abrirán una ventana para mostrar resultados gráficos.

Si alguna vez has abierto el Símbolo del sistema de Windows o el Terminal de macOS, habrás visto una CLI. Si ya has tomado los cursos de The Carpentries sobre UNIX Shell o Version Control, has usado el CLI en tu máquina local extensivamente. El único salto a dar aquí es abrir un CLI en una máquina remota, tomando algunas precauciones para que otras personas en la red no puedan ver (o cambiar) los comandos que estás ejecutando o los resultados que la máquina remota envía de vuelta. Utilizaremos el protocolo Secure SHell (o SSH) para abrir una conexión de red encriptada entre dos máquinas, permitiéndote enviar y recibir texto y datos sin tener que preocuparte de miradas indiscretas.

Conectarse al clúster

Los clientes SSH suelen ser herramientas de línea de comandos en las que el único argumento necesario es la dirección de la máquina remota. Si tu nombre de usuario en el sistema remoto difiere del que utilizas localmente, debes proporcionarlo también. Si tu cliente SSH tiene un front-end gráfico, como PuTTY o MobaXterm, establecerás estos argumentos antes de hacer clic en “conectar” Desde el terminal, escribirás algo como ssh userName@hostname, donde el argumento es igual que una dirección de correo electrónico: el símbolo “@” se utiliza para separar el ID personal de la dirección de la máquina remota.

Al iniciar sesión en un ordenador portátil, tableta u otro dispositivo personal, normalmente se requiere un nombre de usuario, una contraseña o un patrón para evitar el acceso no autorizado. En estas situaciones, la probabilidad de que alguien intercepte tu contraseña es baja, ya que para registrar tus pulsaciones de teclas se requiere un exploit malicioso o acceso físico. Para sistemas como login1 que ejecutan un servidor SSH, cualquiera en la red puede iniciar sesión, o intentarlo. Dado que los nombres de usuario suelen ser públicos o fáciles de adivinar, la contraseña suele ser el eslabón más débil de la cadena de seguridad. Por lo tanto, muchos clusters prohíben el inicio de sesión basado en contraseña, requiriendo en su lugar que generes y configures un par de claves pública-privada con una contraseña mucho más fuerte. Incluso si tu cluster no lo requiere, la siguiente sección te guiará a través del uso de claves SSH y un agente SSH para reforzar tu seguridad y hacer más conveniente el inicio de sesión en sistemas remotos.

Mejor seguridad con claves SSH

La Lesson Setup proporciona instrucciones para instalar una aplicación shell con SSH. Si aún no lo ha hecho, abra esa aplicación shell con una interfaz de línea de comandos tipo Unix en su sistema.

Las claves SSH son un método alternativo de autenticación para obtener acceso a sistemas informáticos remotos. También se pueden utilizar para autenticarse al transferir archivos o para acceder a sistemas remotos de control de versiones (como GitHub). En esta sección crearás un par de claves SSH:

  • una clave privada que guardas en tu propio ordenador, y
  • una clave pública que puedes colocar en cualquier sistema remoto al que vayas a acceder.

Las claves privadas son tu pasaporte digital seguro

Una clave privada que sea visible para cualquiera excepto para ti debe considerarse comprometida y debe ser destruida. Esto incluye tener permisos inadecuados en el directorio en el que está almacenada (o una copia), atravesar cualquier red que no sea segura (encriptada), adjuntarla en un correo electrónico no encriptado, e incluso mostrar la clave en la ventana de tu terminal.

Protege esta clave como si abriera la puerta de tu casa. En muchos sentidos, lo hace.

Independientemente del software o sistema operativo que utilices, por favor elige una contraseña o frase de contraseña segura que actúe como otra capa de protección para tu clave SSH privada.

Consideraciones sobre las contraseñas de las claves SSH

Cuando se le solicite, introduzca una contraseña segura que pueda recordar. Hay dos enfoques comunes para esto:

  1. Crea una frase de contraseña memorable con algunos signos de puntuación y sustituciones de números por letras, de 32 caracteres o más. Las direcciones funcionan bien, pero ten cuidado con los ataques de ingeniería social o de registros públicos.
  2. Utiliza un gestor de contraseñas y su generador de contraseñas integrado con todas las clases de caracteres, de 25 caracteres o más. KeePass y BitWarden son dos buenas opciones.
  3. Nada es menos seguro que una clave privada sin contraseña. Si se ha saltado la introducción de la contraseña por accidente, vuelva atrás y genere un nuevo par de claves con una contraseña segura.

Claves SSH en Linux, Mac, MobaXterm y Windows Subsistema para Linux

Una vez que haya abierto un terminal, compruebe si existen claves SSH y nombres de archivo, ya que las claves SSH existentes se sobrescriben.

BASH 

[you@laptop:~]$ ls ~/.ssh/

Si ~/.ssh/id_ed25519 ya existe, tendrá que especificar un nombre diferente para el nuevo par de claves.

Genera un nuevo par de claves pública-privada usando el siguiente comando, que producirá una clave más fuerte que la ssh-keygen por defecto invocando estas banderas:

  • -a (por defecto es 16): número de rondas de derivación de la frase de contraseña; aumentar para ralentizar los ataques de fuerza bruta.
  • -t (por defecto es rsa): especifica el “tipo” o algoritmo criptográfico. ed25519 especifica EdDSA con una clave de 256 bits; es más rápido que RSA con una fuerza comparable.
  • -f (por defecto es /home/usuario/.ssh/id_algorithm): nombre de archivo para almacenar tu clave privada. El nombre de archivo de la clave pública será idéntico, con una extensión .pub añadida.

BASH 

[you@laptop:~]$ ssh-keygen -a 100 -f ~/.ssh/id_ed25519 -t ed25519

Cuando se le solicite, introduzca una contraseña segura teniendo en cuenta las consideraciones anteriores. Ten en cuenta que el terminal no parecerá cambiar mientras escribes la contraseña: esto es deliberado, por tu seguridad. Se le pedirá que la escriba de nuevo, así que no se preocupe demasiado por los errores tipográficos.

Echa un vistazo en ~/.ssh (utiliza ls ~/.ssh). Debería ver dos archivos nuevos:

  • su clave privada (~/.ssh/id_ed25519): *no la compartas con nadie
  • la clave pública compartible (~/.ssh/id_ed25519.pub): si un administrador del sistema te pide una clave, ésta es la que debes enviar. También es segura para subir a sitios web como GitHub: está pensada para ser vista.

Usar RSA para sistemas antiguos

Si la generación de claves falló porque ed25519 no está disponible, intenta usar el criptosistema más antiguo (pero aún fuerte y confiable) RSA. De nuevo, primero comprueba si existe una clave:

BASH 

[you@laptop:~]$ ls ~/.ssh/

Si ~/.ssh/id_rsa ya existe, tendrás que especificar elegir un nombre diferente para el nuevo par de claves. Genérelo como arriba, con las siguientes banderas adicionales:

  • -b establece el número de bits de la clave. El valor predeterminado es 2048. EdDSA utiliza una longitud de clave fija, por lo que esta bandera no tendría ningún efecto.
  • -o (no por defecto): utiliza el formato de clave OpenSSH, en lugar de PEM.

BASH 

[you@laptop:~]$ ssh-keygen -a 100 -b 4096 -f ~/.ssh/id_rsa -o -t rsa

Cuando se le solicite, introduzca una contraseña segura teniendo en cuenta las consideraciones anteriores.

Echa un vistazo en ~/.ssh (utiliza ls ~/.ssh). Debería ver dos archivos nuevos:

  • su clave privada (~/.ssh/id_rsa): *no la compartas con nadie
  • la clave pública compartible (~/.ssh/id_rsa.pub): si un administrador del sistema te pide una clave, ésta es la que debes enviar. También es segura para subir a sitios web como GitHub: está pensada para ser vista.

Claves SSH en PuTTY

Si utiliza PuTTY en Windows, descargue y utilice puttygen para generar el par de claves. Consulte la documentación de PuTTY para más detalles.

  • Selecciona EdDSA como tipo de clave.
  • Seleccione 255 como tamaño o fuerza de la clave.
  • Haz clic en el botón “Generar”.
  • No es necesario introducir un comentario.
  • Cuando se le solicite, introduzca una contraseña segura teniendo en cuenta las consideraciones anteriores.
  • Guarda las claves en una carpeta que ningún otro usuario del sistema pueda leer.

Echa un vistazo a la carpeta que has especificado. Debería ver dos archivos nuevos:

  • su clave privada (id_ed25519): *no la compartas con nadie
  • la clave pública compartible (id_ed25519.pub): si un administrador del sistema te pide una clave, ésta es la que debes enviar. También es segura para subir a sitios web como GitHub: está pensada para ser vista.

Agente SSH para facilitar el manejo de claves

Una clave SSH es tan fuerte como la contraseña utilizada para desbloquearla, pero por otro lado, escribir una contraseña compleja cada vez que te conectas a una máquina es tedioso y envejece muy rápido. Aquí es donde entra el Agente SSH.

Usando un Agente SSH, puede escribir su contraseña para la clave privada una vez, y luego hacer que el Agente la recuerde durante un número de horas o hasta que cierre la sesión. A menos que algún actor nefasto tenga acceso físico a su máquina, esto mantiene la contraseña segura, y elimina el tedio de introducir la contraseña varias veces.

Recuerda tu contraseña, porque una vez que caduque en el Agente, tendrás que escribirla de nuevo.

Agentes SSH en Linux, macOS y Windows

Abre tu aplicación de terminal y comprueba si se está ejecutando un agente:

BASH 

[you@laptop:~]$ ssh-add -l

  • Si obtiene un error como el siguiente,

    ERROR 

    Error connecting to agent: No such file or directory

    … entonces necesitas lanzar el agente como sigue:

    BASH 

    [you@laptop:~]$ eval $(ssh-agent)

    ¿Qué hay en $(...)?

    La sintaxis de este comando de Agente SSH es inusual, basado en lo que hemos visto en la lección de UNIX Shell. Esto es porque el comando ssh-agent crea abre una conexión a la que sólo usted tiene acceso, e imprime una serie de comandos shell que pueden ser usados para alcanzarla – ¡pero no los ejecuta!

    BASH 

    [you@laptop:~]$ ssh-agent

    SALIDA 

    SSH_AUTH_SOCK=/tmp/ssh-Zvvga2Y8kQZN/agent.131521;
export SSH_AUTH_SOCK;
SSH_AGENT_PID=131522;
export SSH_AGENT_PID;
echo Agent pid 131522;

    El comando eval interpreta esta salida de texto como comandos y le permite acceder a la conexión del Agente SSH que acaba de crear.

    Puede ejecutar cada línea de la salida ssh-agent usted mismo y obtener el mismo resultado. El uso de eval facilita las cosas.

  • De lo contrario, su agente ya se está ejecutando: no se meta con él.

Añade tu clave al agente, con expiración de sesión después de 8 horas:

BASH 

[you@laptop:~]$ ssh-add -t 8h ~/.ssh/id_ed25519

SALIDA 

Enter passphrase for .ssh/id_ed25519:
Identity added: .ssh/id_ed25519
Lifetime set to 86400 seconds

Mientras dure (8 horas), siempre que utilices esa clave, el Agente SSH proporcionará la clave en tu nombre sin que tengas que teclear ni una sola tecla.

Agente SSH en PuTTY

Si utiliza PuTTY en Windows, descargue y utilice pageant como agente SSH. Consulte la documentación de PuTTY.

Transfiere tu clave pública

BASH 

[you@laptop:~]$ scp ~/.ssh/id_ed25519.pub yourUsername@cluster.hpc-carpentry.org:~/

Entrar en el Cluster

Abre tu terminal o cliente gráfico SSH, e inicia sesión en el clúster. Sustituye yourUsername por tu nombre de usuario o el suministrado por los instructores.

BASH 

[you@laptop:~]$ ssh yourUsername@cluster.hpc-carpentry.org

Es posible que se te pida la contraseña. Atención: los caracteres que escriba después de la solicitud de contraseña no se mostrarán en pantalla. La salida normal se reanudará cuando pulse Enter.

Puede que haya notado que el prompt cambió cuando se conectó al sistema remoto usando el terminal (si se conectó usando PuTTY esto no se aplicará porque no ofrece un terminal local). Este cambio es importante porque puede ayudarte a distinguir en qué sistema se ejecutarán los comandos que escribas cuando los pases a la terminal. Este cambio es también una pequeña complicación que tendremos que sortear a lo largo del taller. Exactamente lo que se muestra como prompt (que convencionalmente termina en $) en la terminal cuando está conectada al sistema local y al sistema remoto será típicamente diferente para cada usuario. Aún así, necesitamos indicar en qué sistema estamos introduciendo comandos, por lo que adoptaremos la siguiente convención:

  • [you@laptop:~]$ cuando el comando deba introducirse en un terminal conectado a su ordenador local
  • [yourUsername@login1 ~] cuando el comando deba introducirse en un terminal conectado al sistema remoto
  • $ cuando realmente no importa a qué sistema está conectado el terminal.

Echando un vistazo a tu home remoto

Muy a menudo, muchos usuarios se ven tentados a pensar que una instalación de computación de alto rendimiento es una máquina gigante y mágica. A veces, la gente asume que el ordenador en el que han iniciado sesión es todo el clúster de computación. Pero, ¿qué ocurre realmente? ¿En qué ordenador hemos iniciado sesión? El nombre del ordenador en el que hemos iniciado sesión se puede comprobar con el comando hostname. (¡También puedes notar que el nombre de host actual es también parte de nuestro prompt!)

BASH 

[yourUsername@login1 ~] hostname

SALIDA 

login1

Ya estamos en la máquina remota. A continuación, vamos a averiguar dónde estamos ejecutando pwd para printar el directorio de trabajo (print working directory).

BASH 

[yourUsername@login1 ~] pwd

SALIDA 

/home/yourUsername

¡Genial, ya sabemos dónde estamos! Veamos qué hay en nuestro directorio actual:

BASH 

[yourUsername@login1 ~] ls

SALIDA 

id_ed25519.pub

Es posible que los administradores del sistema hayan configurado tu directorio de inicio con algunos archivos, carpetas y enlaces (accesos directos) útiles al espacio reservado para ti en otros sistemas de archivos. Si no lo han hecho, tu directorio personal puede aparecer vacío. Para volver a comprobarlo, incluya los archivos ocultos en su listado de directorios:

BASH 

[yourUsername@login1 ~] ls -a

SALIDA 

  .            .bashrc           id_ed25519.pub
  ..           .ssh

En la primera columna, . es una referencia al directorio actual y .. una referencia a su padre (/home). Puede que veas o no los otros ficheros, o ficheros como ellos: .bashrc es un fichero de configuración del shell, que puedes editar con tus preferencias; y .ssh es un directorio que almacena claves SSH y un registro de conexiones autorizadas.

Instale su clave SSH

Puede haber una manera mejor

Las políticas y prácticas para el manejo de claves SSH varían entre clusters HPC: siga cualquier guía proporcionada por los administradores del cluster o la documentación. En particular, si existe un portal en línea para la gestión de claves SSH, utilícelo en lugar de las instrucciones descritas aquí.

Si transfirió su clave pública SSH con scp, debería ver id_ed25519.pub en su directorio personal. Para “instalar” esta clave, debe aparecer en un archivo llamado authorized_keys en la carpeta .ssh.

Si la carpeta .ssh no aparece en la lista anterior, es que aún no existe: créala.

BASH 

[yourUsername@login1 ~] mkdir ~/.ssh

Ahora, utiliza cat para imprimir tu clave pública, pero redirige la salida, añadiéndola al archivo authorized_keys:

BASH 

[yourUsername@login1 ~] cat ~/id_ed25519.pub >> ~/.ssh/authorized_keys

¡Eso es todo! Desconéctese e intente conectarse de nuevo al remoto: si su clave y agente han sido configurados correctamente, no se le pedirá la contraseña de su clave SSH.

BASH 

[yourUsername@login1 ~] logout

BASH 

[you@laptop:~]$ ssh yourUsername@cluster.hpc-carpentry.org

Puntos Clave

  • Un sistema HPC es un conjunto de máquinas conectadas en red.
  • Los sistemas HPC suelen proporcionar nodos de inicio de sesión y un conjunto de nodos trabajadores.
  • Los recursos que se encuentran en los nodos independientes (trabajadores) pueden variar en volumen y tipo (cantidad de RAM, arquitectura del procesador, disponibilidad de sistemas de archivos montados en red, etc.).
  • Los archivos guardados en un nodo están disponibles en todos los nodos.

Content from Trabajar en un sistema HPC remoto

Última actualización: 2025-08-04 | Mejora esta página

Hoja de ruta

Preguntas

  • “¿Qué es un sistema HPC?”
  • “¿Cómo funciona un sistema HPC?”
  • “¿Cómo me conecto a un sistema HPC remoto?”

Objetivos

  • “Conectarse a un sistema HPC remoto”
  • “Comprender la arquitectura general del sistema HPC”

¿Qué es un sistema HPC?

Las palabras “nube”, “clúster”, y la frase “computación de alto rendimiento” o “HPC” se utilizan mucho en diferentes contextos y con varios significados relacionados. ¿Qué significan? Y lo que es más importante, ¿cómo los utilizamos en nuestro trabajo?

La nube es un término genérico comúnmente utilizado para referirse a los recursos informáticos que son a) proporcionados a los usuarios bajo demanda o según sus necesidades y b) representan recursos reales o virtuales que pueden estar localizados en cualquier lugar de la Tierra. Por ejemplo, una gran empresa con recursos informáticos en Brasil, Zimbabue y Japón puede gestionar esos recursos como su propia nube interna y esa misma empresa puede utilizar también recursos comerciales en la nube proporcionados por Amazon o Google. Los recursos en la nube pueden referirse a máquinas que realizan tareas relativamente sencillas como servir sitios web, proporcionar almacenamiento compartido, proporcionar servicios web (como correo electrónico o plataformas de medios sociales), así como tareas más tradicionales de computación intensiva como ejecutar una simulación.

El término sistema HPC, por otro lado, describe un recurso independiente para cargas de trabajo computacionalmente intensivas. Suelen estar compuestos por una multitud de elementos integrados de procesamiento y almacenamiento, diseñados para manejar grandes volúmenes de datos y/o grandes números de operaciones en coma flotante (FLOPS) con el mayor rendimiento posible. Por ejemplo, todas las máquinas de la lista Top-500 son sistemas HPC. Para soportar estas limitaciones, un recurso HPC debe existir en una ubicación específica y fija: los cables de red sólo pueden estirarse hasta cierto punto, y las señales eléctricas y ópticas sólo pueden viajar a cierta velocidad.

La palabra “clúster” se utiliza a menudo para recursos HPC de escala pequeña a moderada menos impresionantes que el Top-500. Los clústeres suelen mantenerse en centros de cálculo que soportan varios sistemas de este tipo, todos ellos compartiendo redes y almacenamiento comunes para soportar tareas comunes de cálculo intensivo.

Inicio de sesión

El primer paso para utilizar un clúster es establecer una conexión entre nuestro portátil y el clúster. Cuando estamos sentados frente a un ordenador (o de pie, o sosteniéndolo en la mano o en la muñeca), esperamos ver una pantalla con iconos, widgets y quizás algunas ventanas o aplicaciones: una interfaz gráfica de usuario o GUI. Dado que los clústeres informáticos son recursos remotos a los que nos conectamos a través de interfaces a menudo lentas o con retardo (WiFi y VPN, especialmente), es más práctico utilizar una interfaz de línea de comandos, o CLI, en la que los comandos y los resultados se transmiten únicamente a través de texto. Todo lo que no sea texto (imágenes, por ejemplo) debe escribirse en disco y abrirse con un programa aparte.

Si alguna vez has abierto el símbolo del sistema de Windows o el terminal de macOS, habrás visto una CLI. Si ya has tomado los cursos de Las Carpinterías sobre la Shell UNIX o el Control de Versiones, has usado la CLI en tu máquina local algo extensamente. El único salto a dar aquí es abrir un CLI en una máquina remota, tomando algunas precauciones para que otras personas en la red no puedan ver (o cambiar) los comandos que estás ejecutando o los resultados que la máquina remota envía de vuelta. Usaremos el protocolo Secure SHell (o SSH) para abrir una conexión de red encriptada entre dos máquinas, permitiéndote enviar y recibir texto y datos sin tener que preocuparte de miradas indiscretas.

Conectarse al clúster
Conectarse al clúster

Asegúrese de que tiene un cliente SSH instalado en su portátil. Consulte la sección setup para más detalles. Los clientes SSH suelen ser herramientas de línea de comandos, donde se proporciona la dirección de la máquina remota como único argumento requerido. Si tu nombre de usuario en el sistema remoto difiere del que usas localmente, debes proporcionarlo también. Si tu cliente SSH tiene un front-end gráfico, como PuTTY o MobaXterm, establecerás estos argumentos antes de hacer clic en “conectar” Desde el terminal, escribirás algo como ssh userName@hostname, donde el símbolo “@” se utiliza para separar las dos partes de un único argumento.

Sigue adelante y abre tu terminal o cliente gráfico SSH, luego inicia sesión en el cluster usando tu nombre de usuario y el ordenador remoto al que puedes acceder desde el mundo exterior, cluster.hpc-carpentry.org.

BASH 

[you@laptop:~]$ ssh yourUsername@cluster.hpc-carpentry.org

Recuerda sustituir yourUsername por tu nombre de usuario o el que te proporcionen los instructores. Es posible que te pidan tu contraseña. Atención: los caracteres que escriba después de la solicitud de contraseña no se mostrarán en pantalla. La salida normal se reanudará cuando pulse Enter.

¿Dónde estamos?

Muy a menudo, muchos usuarios se ven tentados a pensar que una instalación de computación de alto rendimiento es una máquina gigante y mágica. A veces, la gente asume que el ordenador en el que han iniciado sesión es todo el clúster de computación. Pero, ¿qué ocurre realmente? ¿En qué ordenador hemos iniciado sesión? El nombre del ordenador en el que hemos iniciado sesión se puede comprobar con el comando hostname. (¡También puedes notar que el nombre de host actual es también parte de nuestro prompt!)

BASH 

[yourUsername@login1 ~] hostname

SALIDA 

login1

¿Qué hay en tu directorio de inicio?

Es posible que los administradores del sistema hayan configurado su directorio personal con algunos archivos, carpetas y enlaces (accesos directos) útiles a espacios reservados para usted en otros sistemas de archivos. Eche un vistazo a ver qué encuentra. Sugerencia: Los comandos del shell pwd y ls pueden resultarle útiles. El contenido de los directorios personales varía de un usuario a otro. Por favor, comenta cualquier diferencia que encuentres con tus vecinos.

La capa más profunda debe diferir: yourUsername es exclusivamente suya. ¿Hay diferencias en la ruta en los niveles superiores?

Si ambos tienen directorios vacíos, se verán idénticos. Si tú o tu vecino habéis usado el sistema antes, puede haber diferencias. ¿En qué estás trabajando?

Utilice pwd para imprimir la ruta del directorio de trabajo:

BASH 

[yourUsername@login1 ~] pwd

Puede ejecutar ls para listar el contenido del directorio, aunque es posible que no aparezca nada (si no se han proporcionado ficheros). Para estar seguro, utilice también el indicador -a para mostrar los archivos ocultos.

BASH 

[yourUsername@login1 ~] ls -a

Como mínimo, esto mostrará el directorio actual como ., y el directorio padre como ...

Nodos

Los ordenadores individuales que componen un clúster se suelen llamar nodos (aunque también se les llama servidores, ordenadores y máquinas). En un clúster, hay distintos tipos de nodos para distintos tipos de tareas. El nodo en el que te encuentras en este momento se llama nodo de cabecera, nodo de inicio de sesión, almohadilla de aterrizaje o nodo de envío. Un nodo de inicio de sesión sirve como punto de acceso al clúster.

Como pasarela, es muy adecuada para subir y descargar archivos, configurar software y realizar pruebas rápidas. En general, el nodo de acceso no debe utilizarse para tareas que consuman mucho tiempo o recursos. Deberías estar atento a esto, y comprobar con los operadores o la documentación de tu sitio los detalles de lo que está y no está permitido. En estas lecciones, evitaremos ejecutar trabajos en el nodo principal.

Nodos de transferencia dedicados

Si desea transferir grandes cantidades de datos hacia o desde el clúster, algunos sistemas ofrecen nodos dedicados sólo para transferencias de datos. La motivación de esto radica en el hecho de que las transferencias de datos más grandes no deben obstruir el funcionamiento del nodo de inicio de sesión para nadie más. Comprueba en la documentación de tu clúster o con su equipo de soporte si existe un nodo de transferencia de este tipo. Como regla general, considere todas las transferencias de un volumen superior a 500 MB a 1 GB como grandes. Pero estos números cambian, por ejemplo, en función de la conexión de red propia y de su clúster u otros factores.

El verdadero trabajo en un cluster lo hacen los nodos de trabajo (o computación). Los nodos de trabajo tienen muchas formas y tamaños, pero generalmente se dedican a tareas largas o difíciles que requieren muchos recursos computacionales.

Toda la interacción con los nodos trabajadores es manejada por una pieza especializada de software llamada planificador (el planificador utilizado en esta lección se llama Slurm). Aprenderemos más sobre cómo usar el planificador para enviar trabajos a continuación, pero por ahora, también puede darnos más información sobre los nodos trabajadores.

Por ejemplo, podemos ver todos los nodos trabajadores ejecutando el comando sinfo.

BASH 

[yourUsername@login1 ~] sinfo

SALIDA 

PARTITION          AVAIL  TIMELIMIT  NODES  STATE NODELIST
cpubase_bycore_b1*    up   infinite      4   idle node[1-2],smnode[1-2]
node                  up   infinite      2   idle node[1-2]
smnode                up   infinite      2   idle smnode[1-2]

También hay máquinas especializadas que se utilizan para gestionar el almacenamiento en disco, la autenticación de usuarios y otras tareas relacionadas con la infraestructura. Aunque no solemos iniciar sesión o interactuar con estas máquinas directamente, permiten una serie de características clave como asegurar que nuestra cuenta de usuario y archivos están disponibles en todo el sistema HPC.

¿Qué hay en un Nodo?

Todos los nodos de un sistema HPC tienen los mismos componentes que su propio ordenador portátil o de sobremesa: CPUs (a veces también llamados procesadores o cores), memoria (o RAM) y espacio de disco. Las CPU son la herramienta de un ordenador para ejecutar programas y cálculos. La información sobre una tarea en curso se almacena en la memoria del ordenador. Disco se refiere a todo el almacenamiento al que se puede acceder como un sistema de archivos. Por lo general, se trata de un almacenamiento que puede guardar datos de forma permanente, es decir, los datos siguen ahí aunque se reinicie el ordenador. Aunque este almacenamiento puede ser local (un disco duro instalado en su interior), es más común que los nodos se conecten a un servidor de archivos compartido y remoto o a un clúster de servidores.

Anatomía del nodo
Anatomía del nodo

Explore su ordenador

Intenta averiguar el número de CPUs y la cantidad de memoria disponible en tu ordenador personal. Ten en cuenta que, si has iniciado sesión en el clúster de ordenadores remotos, primero tienes que cerrar la sesión. Para ello, escriba Ctrl+d o exit:

BASH 

[yourUsername@login1 ~] exit
[you@laptop:~]$

Hay varias maneras de hacer esto. La mayoría de los sistemas operativos tienen un monitor gráfico del sistema, como el Administrador de tareas de Windows. A veces se puede encontrar información más detallada en la línea de comandos. Por ejemplo, algunos de los comandos utilizados en un sistema Linux son:

Ejecutar utilidades del sistema

BASH 

[you@laptop:~]$ nproc --all
[you@laptop:~]$ free -m

Lectura de /proc

BASH 

[you@laptop:~]$ cat /proc/cpuinfo
[you@laptop:~]$ cat /proc/meminfo

Utilizar un monitor del sistema

BASH 

[you@laptop:~]$ htop

Explorar el nodo de acceso

Ahora compara los recursos de tu ordenador con los del nodo principal.

BASH 

[you@laptop:~]$ ssh yourUsername@cluster.hpc-carpentry.org
[yourUsername@login1 ~] nproc --all
[yourUsername@login1 ~] free -m

Puedes obtener más información sobre los procesadores usando lscpu, y muchos detalles sobre la memoria leyendo el fichero /proc/meminfo:

BASH 

[yourUsername@login1 ~] less /proc/meminfo

También puedes explorar los sistemas de ficheros disponibles usando df para mostrar el espacio disk free. La opción -h muestra los tamaños en un formato amigable, es decir, GB en lugar de B. La opción type -T muestra qué tipo de sistema de ficheros es cada recurso.

BASH 

[yourUsername@login1 ~] df -Th

Discusión

Los sistemas de ficheros locales (ext, tmp, xfs, zfs) dependerán de si estás en el mismo nodo de login (o nodo de computación, más adelante). Los sistemas de ficheros en red (beegfs, cifs, gpfs, nfs, pvfs) serán similares — pero pueden incluir yourUsername, dependiendo de cómo esté montado.

Sistemas de archivos compartidos

Es importante recordar que los archivos guardados en un nodo (ordenador) suelen estar disponibles en cualquier parte del clúster

Explore a Worker Node

Finally, let’s look at the resources available on the worker nodes where your jobs will actually run. Try running this command to see the name, CPUs and memory available on one of the worker nodes:

BASH 

[yourUsername@login1 ~] sinfo -o "%n %c %m" | column -t

Compare su ordenador, el nodo de inicio de sesión y el nodo de cálculo

Compara el número de procesadores y memoria de tu portátil con los números que ves en el nodo cabeza del cluster y en el nodo trabajador. Discute las diferencias con tu vecino.

¿Qué implicaciones crees que pueden tener las diferencias a la hora de ejecutar tu trabajo de investigación en los distintos sistemas y nodos?

Diferencias entre nodos

Muchos clusters HPC tienen una variedad de nodos optimizados para cargas de trabajo particulares. Algunos nodos pueden tener una mayor cantidad de memoria, o recursos especializados como Unidades de Procesamiento Gráfico (GPUs).

Con todo esto en mente, ahora veremos cómo hablar con el planificador del clúster y utilizarlo para empezar a ejecutar nuestros scripts y programas

Puntos Clave

  • “Un sistema HPC es un conjunto de máquinas conectadas en red”
  • “Los sistemas HPC suelen proporcionar nodos de inicio de sesión y un conjunto de nodos trabajadores”
  • “Los recursos que se encuentran en nodos independientes (trabajadores) pueden variar en volumen y tipo (cantidad de RAM, arquitectura del procesador, disponibilidad de sistemas de ficheros montados en red, etc.).”
  • “Los archivos guardados en un nodo están disponibles en todos los nodos”

Content from Fundamentos del programador

Última actualización: 2025-08-04 | Mejora esta página

Hoja de ruta

Preguntas

  • ¿Qué es un planificador y por qué un clúster necesita uno?
  • ¿Cómo lanzo un programa para que se ejecute en un nodo de cálculo del clúster?
  • ¿Cómo puedo capturar la salida de un programa que se ejecuta en un nodo del clúster?

Objetivos

  • Envía un script simple al cluster.
  • Supervisar la ejecución de los trabajos mediante herramientas de línea de comandos.
  • Inspeccione los archivos de salida y error de sus trabajos.
  • Encontrar el lugar adecuado para colocar grandes conjuntos de datos en el clúster.

Programador de trabajos

Un sistema HPC puede tener miles de nodos y miles de usuarios. ¿Cómo decidimos quién recibe qué y cuándo? ¿Cómo nos aseguramos de que una tarea se ejecuta con los recursos que necesita? De esta tarea se encarga un software especial llamado programador. En un sistema HPC, el programador gestiona qué tareas se ejecutan, dónde y cuándo.

La siguiente ilustración compara las tareas de un programador de tareas con las de un camarero en un restaurante. Si puede relacionarlo con un caso en el que tuvo que esperar un rato en una cola para entrar en un restaurante popular, entonces ahora puede entender por qué a veces su trabajo no se inicia instantáneamente como en su ordenador portátil.

Compara un programador de tareas con un camarero en un restaurante

El planificador utilizado en esta lección es Slurm. Aunque Slurm no se utiliza en todas partes, la ejecución de trabajos es bastante similar independientemente del software que se utilice. La sintaxis exacta puede cambiar, pero los conceptos siguen siendo los mismos.

Ejecución de un trabajo por lotes

El uso más básico del planificador es ejecutar un comando de forma no interactiva. Cualquier comando (o serie de comandos) que desee ejecutar en el cluster se denomina job, y el proceso de utilizar un planificador para ejecutar el trabajo se denomina sometimiento de trabajo por lotes.

En este caso, el trabajo que queremos ejecutar es un script de shell – esencialmente un archivo de texto que contiene una lista de comandos UNIX para ser ejecutados de manera secuencial. Nuestro script de shell tendrá tres partes:

  • En la primera línea, añada #!/bin/bash. El #! (pronunciado “hash-bang” o “shebang”) indica al ordenador qué programa debe procesar el contenido de este fichero. En este caso, le estamos diciendo que los comandos que siguen están escritos para la shell de línea de comandos (en la que hemos estado haciendo todo hasta ahora).
  • En cualquier lugar debajo de la primera línea, añadiremos un comando echo con un saludo amistoso. Cuando se ejecute, el script de shell imprimirá lo que venga después de echo en el terminal.
    • echo -n imprimirá todo lo que sigue, sin terminar la línea imprimiendo el carácter de nueva línea.
  • En la última línea, invocaremos el comando hostname, que imprimirá el nombre de la máquina en la que se ejecuta el script.

BASH 

[yourUsername@login1 ~] nano example-job.sh

BASH 

#!/bin/bash

echo -n "This script is running on "
hostname

Creación de nuestro trabajo de prueba

Ejecuta el script. ¿Se ejecuta en el clúster o sólo en nuestro nodo de inicio de sesión?

BASH 

[yourUsername@login1 ~] bash example-job.sh

SALIDA 

This script is running on login1

Este script se ejecutó en el nodo de inicio de sesión, pero queremos aprovechar los nodos de computación: necesitamos que el planificador ponga en cola example-job.sh para ejecutarse en un nodo de computación.

Para enviar esta tarea al planificador, usamos el comando sbatch. Esto crea un job que ejecutará el script cuando sea despachado a un nodo de computación que el sistema de colas haya identificado como disponible para realizar el trabajo.

BASH 

[yourUsername@login1 ~] sbatch  example-job.sh

SALIDA 

Submitted batch job 7

Y eso es todo lo que tenemos que hacer para enviar un trabajo. Nuestro trabajo está hecho – ahora el programador toma el relevo e intenta ejecutar el trabajo por nosotros. Mientras el trabajo espera a ejecutarse, entra en una lista de trabajos llamada cola. Para comprobar el estado de nuestro trabajo, comprobamos la cola utilizando el comando squeue -u yourUsername.

BASH 

[yourUsername@login1 ~] squeue -u yourUsername

SALIDA 

JOBID PARTITION     NAME     USER ST       TIME  NODES NODELIST(REASON)
    9 cpubase_b example-   user01  R       0:05      1 node1

Podemos ver todos los detalles de nuestro trabajo, lo más importante es que está en el estado R o RUNNING. A veces nuestros trabajos pueden necesitar esperar en una cola (PENDING) o tener un error (E).

¿Dónde está la salida?

En el nodo de inicio de sesión, este script imprimió la salida en el terminal – pero ahora, cuando squeue muestra que el trabajo ha finalizado, no se imprimió nada en el terminal.

La salida del trabajo de cluster se redirige normalmente a un archivo en el directorio desde el que se lanzó. Utilice ls para buscar y cat para leer el archivo.

Personalización de un trabajo

El trabajo que acabamos de ejecutar utilizaba todas las opciones por defecto del planificador. En un escenario del mundo real, eso no es probablemente lo que queremos. Las opciones por defecto representan un mínimo razonable. Lo más probable es que necesitemos más núcleos, más memoria, más tiempo, entre otras consideraciones especiales. Para tener acceso a estos recursos debemos personalizar nuestro script de trabajo.

Los comentarios en los scripts de shell UNIX (denotados por #) son normalmente ignorados, pero hay excepciones. Por ejemplo, el comentario especial #! al principio de los scripts especifica qué programa debe usarse para ejecutarlo (normalmente verá #!/usr/bin/env bash). Los programadores como Slurm también tienen un comentario especial que se utiliza para indicar opciones específicas del programador. Aunque estos comentarios difieren de un programador a otro, el comentario especial de Slurm es #SBATCH. Todo lo que sigue al comentario #SBATCH se interpreta como una instrucción para el programador.

Vamos a ilustrarlo con un ejemplo. Por defecto, el nombre de un trabajo es el nombre del script, pero se puede utilizar la opción -J para cambiar el nombre de un trabajo. Añade una opción al script:

BASH 

[yourUsername@login1 ~] cat example-job.sh

BASH 

#!/bin/bash
#SBATCH -J hello-world

echo -n "This script is running on "
hostname

Envía el trabajo y supervisa su estado:

BASH 

[yourUsername@login1 ~] sbatch  example-job.sh
[yourUsername@login1 ~] squeue -u yourUsername

SALIDA 

JOBID PARTITION     NAME     USER ST       TIME  NODES NODELIST(REASON)
   10 cpubase_b hello-wo   user01  R       0:02      1 node1

¡Fantástico, hemos cambiado con éxito el nombre de nuestro trabajo!

Solicitudes de recursos

¿Qué pasa con los cambios más importantes, como el número de núcleos y memoria para nuestros trabajos? Una cosa que es absolutamente crítica cuando se trabaja en un sistema HPC es especificar los recursos necesarios para ejecutar un trabajo. Esto permite al programador encontrar el momento y el lugar adecuados para programar nuestro trabajo. Si no especifica los requisitos (como la cantidad de tiempo que necesita), es probable que se quede con los recursos predeterminados de su sitio, que probablemente no es lo que desea.

A continuación se muestran varias solicitudes de recursos clave:

  • --ntasks=<ntasks> o -n <ntasks>: ¿Cuántos núcleos de CPU necesita su trabajo, en total?

  • --time <days-hours:minutes:seconds> o -t <days-hours:minutes:seconds>: ¿Cuánto tiempo real (walltime) tardará en ejecutarse tu tarea? La parte <days> puede omitirse.

  • --mem=<megabytes>: ¿Cuánta memoria en un nodo necesita su trabajo en megabytes? También puede especificar gigabytes añadiendo una pequeña “g” después (ejemplo: --mem=5g)

  • --nodes=<nnodes> o -N <nnodes>: ¿En cuántas máquinas distintas debe ejecutarse su trabajo? Tenga en cuenta que si establece ntasks en un número superior al que puede ofrecer una máquina, Slurm establecerá este valor automáticamente.

Tenga en cuenta que el simple hecho de solicitar estos recursos no hace que su trabajo se ejecute más rápido, ni significa necesariamente que vaya a consumir todos estos recursos. Sólo significa que se ponen a su disposición. Tu trabajo puede terminar usando menos memoria, o menos tiempo, o menos nodos de los que has solicitado, y aún así se ejecutará.

Lo mejor es que tus solicitudes reflejen fielmente los requisitos de tu trabajo. Hablaremos más acerca de cómo asegurarse de que está utilizando los recursos de manera efectiva en un episodio posterior de esta lección.

Envío de solicitudes de recursos

Modifique nuestro script hostname para que se ejecute durante un minuto y, a continuación, envíe un trabajo para él en el clúster.

BASH 

[yourUsername@login1 ~] cat example-job.sh

BASH 

#!/bin/bash
#SBATCH -t 00:01 # timeout in HH:MM

echo -n "This script is running on "
sleep 20 # time in seconds
hostname

BASH 

[yourUsername@login1 ~] sbatch  example-job.sh

¿Por qué el tiempo de ejecución Slurm y el tiempo sleep no son idénticos?

Las solicitudes de recursos suelen ser vinculantes. Si las excedes, tu trabajo será eliminado. Usemos el tiempo de muro como ejemplo. Solicitaremos 1 minuto de tiempo de muro, e intentaremos ejecutar un trabajo durante dos minutos.

BASH 

[yourUsername@login1 ~] cat example-job.sh

BASH 

#!/bin/bash
#SBATCH -J long_job
#SBATCH -t 00:01 # timeout in HH:MM

echo "This script is running on ... "
sleep 240 # time in seconds
hostname

Envía el trabajo y espera a que termine. Una vez que haya terminado, compruebe el archivo de registro.

BASH 

[yourUsername@login1 ~] sbatch  example-job.sh
[yourUsername@login1 ~] squeue -u yourUsername

BASH 

[yourUsername@login1 ~] cat slurm-12.out

SALIDA 

This script is running on ...
slurmstepd: error: *** JOB 12 ON node1 CANCELLED AT 2021-02-19T13:55:57
DUE TO TIME LIMIT ***

Nuestro trabajo ha sido cancelado por exceder la cantidad de recursos solicitados. Aunque esto parece duro, en realidad es una característica. El cumplimiento estricto de las solicitudes de recursos permite al planificador encontrar el mejor lugar posible para sus trabajos. Aún más importante, asegura que otro usuario no pueda usar más recursos de los que se le han dado. Si otro usuario mete la pata y accidentalmente intenta utilizar todos los núcleos o la memoria de un nodo, Slurm restringirá su trabajo a los recursos solicitados o matará el trabajo directamente. Otros trabajos en el nodo no se verán afectados. Esto significa que un usuario no puede estropear la experiencia de los demás, los únicos trabajos afectados por un error en la programación serán los suyos propios.

Cancelación de un trabajo

A veces cometeremos un error y necesitaremos cancelar un trabajo. Esto se puede hacer con el comando scancel. Vamos a enviar un trabajo y luego cancelarlo usando su número de trabajo (¡recuerda cambiar el tiempo de ejecución para que se ejecute el tiempo suficiente para que puedas cancelarlo antes de que se mate!)

BASH 

[yourUsername@login1 ~] sbatch  example-job.sh
[yourUsername@login1 ~] squeue -u yourUsername

SALIDA 

Submitted batch job 13

JOBID PARTITION     NAME     USER ST       TIME  NODES NODELIST(REASON)
   13 cpubase_b long_job   user01  R       0:02      1 node1

Ahora cancele el trabajo con su número de trabajo (impreso en su terminal). Un retorno limpio de su símbolo del sistema indica que la solicitud de cancelación del trabajo se ha realizado correctamente.

BASH 

[yourUsername@login1 ~] scancel 38759
# It might take a minute for the job to disappear from the queue...
[yourUsername@login1 ~] squeue -u yourUsername

SALIDA 

JOBID PARTITION     NAME     USER ST       TIME  NODES NODELIST(REASON)

Cancelación de múltiples trabajos

También podemos cancelar todos nuestros trabajos a la vez utilizando la opción -u. Esto borrará todos los trabajos de un usuario específico (en este caso, usted mismo). Tenga en cuenta que sólo puede eliminar sus propios trabajos.

Pruebe a enviar varios trabajos y luego cancélelos todos.

En primer lugar, envíe un trío de trabajos:

BASH 

[yourUsername@login1 ~] sbatch  example-job.sh
[yourUsername@login1 ~] sbatch  example-job.sh
[yourUsername@login1 ~] sbatch  example-job.sh

A continuación, cancélelos todos:

BASH 

[yourUsername@login1 ~] scancel -u yourUsername

Otros tipos de trabajos

Hasta ahora, nos hemos centrado en la ejecución de tareas por lotes. Slurm también ofrece la posibilidad de iniciar una sesión interactiva.

Con mucha frecuencia hay tareas que deben realizarse de forma interactiva. Crear un script de trabajo completo puede ser excesivo, pero la cantidad de recursos requeridos es demasiado para que un nodo de inicio de sesión pueda manejarlo. Un buen ejemplo de esto podría ser la construcción de un índice del genoma para la alineación con una herramienta como HISAT2. Afortunadamente, podemos ejecutar este tipo de tareas de una sola vez con srun.

srun ejecuta un único comando en el cluster y luego se cierra. Demostremos esto ejecutando el comando hostname con srun. (Podemos cancelar un trabajo srun con Ctrl-c)

BASH 

[yourUsername@login1 ~] srun hostname

SALIDA 

smnode1

srun acepta las mismas opciones que sbatch. Sin embargo, en lugar de especificarlas en un script, estas opciones se especifican en la línea de comandos al iniciar un trabajo. Para enviar un trabajo que utilice 2 CPUs, por ejemplo, podríamos utilizar el siguiente comando:

BASH 

[yourUsername@login1 ~] srun -n 2 echo "This job will use 2 CPUs."

SALIDA 

This job will use 2 CPUs.
This job will use 2 CPUs.

Normalmente, el entorno de shell resultante será el mismo que el de sbatch.

Trabajos interactivos

A veces, necesitaremos muchos recursos para un uso interactivo. Quizás es la primera vez que ejecutamos un análisis o estamos intentando depurar algo que salió mal en un trabajo anterior. Afortunadamente, Slurm facilita el inicio de un trabajo interactivo con srun:

BASH 

[yourUsername@login1 ~] srun --pty bash

Aparecerá un prompt bash. Tenga en cuenta que el prompt probablemente cambiará para reflejar su nueva ubicación, en este caso el nodo de computación en el que estamos conectados. También puedes verificarlo con hostname.

Creación de gráficos remotos

Para ver la salida gráfica dentro de tus trabajos, necesitas usar X11 forwarding. Para conectarse con esta característica activada, utilice la opción -Y cuando se conecte con el comando ssh, por ejemplo, ssh -Y yourUsername@cluster.hpc-carpentry.org.

Para demostrar lo que ocurre cuando creas una ventana gráfica en el nodo remoto, utiliza el comando xeyes. Debería aparecer un par de ojos relativamente adorables (pulse Ctrl-C para parar). Si utiliza un Mac, debe haber instalado XQuartz (y reiniciado su ordenador) para que esto funcione.

Si su cluster tiene instalado el plugin slurm-spank-x11, puede asegurar el reenvío X11 dentro de los trabajos interactivos utilizando la opción --x11 para srun con el comando srun --x11 --pty bash.

Cuando haya terminado con el trabajo interactivo, escriba exit para salir de la sesión.

Puntos Clave

  • El planificador gestiona cómo se comparten los recursos informáticos entre los usuarios.
  • Un trabajo no es más que un script de shell.
  • Solicita ligeramente más recursos de los que necesitará.

Content from Variables de entorno

Última actualización: 2025-08-04 | Mejora esta página

Hoja de ruta

Preguntas

  • ¿Cómo se establecen y acceden a las variables en el intérprete de comandos Unix?
  • ¿Cómo puedo utilizar variables para cambiar la forma en que se ejecuta un programa?

Objetivos

  • Comprender cómo se implementan las variables en el shell
  • Leer el valor de una variable existente
  • Crear nuevas variables y cambiar sus valores
  • Cambiar el comportamiento de un programa mediante una variable de entorno
  • Explica cómo el shell utiliza la variable PATH para buscar ejecutables

Procedencia del episodio

Este episodio ha sido remezclado del episodio Shell Extras sobre Variables del Shell y del episodio HPC Shell sobre scripts.

El shell es sólo un programa, y como otros programas, tiene variables. Esas variables controlan su ejecución, de modo que cambiando sus valores puedes cambiar cómo se comporta el shell (y con un poco más de esfuerzo cómo se comportan otros programas).

Las variables son una buena forma de guardar información bajo un nombre al que puedas acceder más tarde. En lenguajes de programación como Python y R, las variables pueden almacenar prácticamente cualquier cosa que se te ocurra. En el shell, normalmente sólo almacenan texto. La mejor manera de entender cómo funcionan es verlas en acción.

Empecemos ejecutando el comando set y observando algunas de las variables en una sesión típica de shell:

BASH 

set

SALIDA 

COMPUTERNAME=TURING
HOME=/home/vlad
HOSTNAME=TURING
HOSTTYPE=i686
NUMBER_OF_PROCESSORS=4
PATH=/Users/vlad/bin:/usr/local/git/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin
PWD=/home/vlad
UID=1000
USERNAME=vlad
...

Como puedes ver, hay bastantes - de hecho, cuatro o cinco veces más de las que se muestran aquí. Y sí, usar set para mostrar cosas puede parecer un poco extraño, incluso para Unix, pero si no le das ningún argumento, bien podría mostrarte cosas que podrías configurar.

Cada variable tiene un nombre. Todos los valores de las variables del shell son cadenas, incluso aquellas (como UID) que parecen números. Depende de los programas convertir estas cadenas a otros tipos cuando sea necesario. Por ejemplo, si un programa quisiera averiguar cuántos procesadores tiene el ordenador, convertiría el valor de la variable NUMBER_OF_PROCESSORS de una cadena a un número entero.

Mostrar el valor de una variable

Mostremos el valor de la variable HOME:

BASH 

echo HOME

SALIDA 

HOME

Esto sólo imprime “HOME”, que no es lo que queríamos (aunque es lo que pedimos). Intentemos esto en su lugar:

BASH 

echo $HOME

SALIDA 

/home/vlad

El signo de dólar indica al shell que queremos el valor de la variable en lugar de su nombre. Esto funciona igual que los comodines: el shell realiza la sustitución antes de ejecutar el programa que le hemos pedido. Gracias a esta expansión, lo que realmente ejecutamos es echo /home/vlad, que muestra lo correcto.

Creación y modificación de variables

Crear una variable es fácil - simplemente asignamos un valor a un nombre usando “=” (¡sólo tenemos que recordar que la sintaxis requiere que no haya espacios alrededor de =!)

BASH 

SECRET_IDENTITY=Dracula
echo $SECRET_IDENTITY

SALIDA 

Dracula

Para cambiar el valor, basta con asignar uno nuevo:

BASH 

SECRET_IDENTITY=Camilla
echo $SECRET_IDENTITY

SALIDA 

Camilla

Variables de entorno

Cuando ejecutamos el comando set vimos que había muchas variables cuyos nombres estaban en mayúsculas. Esto es porque, por convención, las variables que también están disponibles para ser usadas por otros programas reciben nombres en mayúsculas. Tales variables se llaman variables de entorno ya que son variables del shell que se definen para el shell actual y son heredadas por cualquier shell o proceso hijo.

Para crear una variable de entorno necesitas export una variable del shell. Por ejemplo, para hacer que nuestra SECRET_IDENTITY esté disponible para otros programas que llamemos desde nuestra shell podemos hacer:

BASH 

SECRET_IDENTITY=Camilla
export SECRET_IDENTITY

También puede crear y exportar la variable en un solo paso:

BASH 

export SECRET_IDENTITY=Camilla

Uso de variables de entorno para cambiar el comportamiento del programa

Establece una variable de shell TIME_STYLE para que tenga un valor de iso y comprueba este valor usando el comando echo.

Ahora, ejecuta el comando ls con la opción -l (que da un formato largo).

export la variable y vuelve a ejecutar el comando ls -l. ¿Notas alguna diferencia?

La variable TIME_STYLE no es vista por ls hasta que es exportada, momento en el cual es utilizada por ls para decidir qué formato de fecha utilizar al presentar la marca de tiempo de los ficheros.

Puedes ver el conjunto completo de variables de entorno en tu sesión de shell actual con el comando env (que devuelve un subconjunto de lo que nos dio el comando set). El conjunto completo de variables de entorno se denomina entorno de ejecución y puede afectar al comportamiento de los programas que ejecutas.

Variables de entorno de trabajo

Cuando Slurm ejecuta un trabajo, establece una serie de variables de entorno para el trabajo. Una de ellas nos permitirá comprobar desde qué directorio se envió nuestro script de trabajo. La variable SLURM_SUBMIT_DIR se establece en el directorio desde el que se envió nuestro trabajo. Usando la variable SLURM_SUBMIT_DIR, modifica tu tarea para que imprima la ubicación desde la que se envió la tarea.

BASH 

[yourUsername@login1 ~] nano example-job.sh
[yourUsername@login1 ~] cat example-job.sh

SALIDA 

#!/bin/bash
#SBATCH -t 00:00:30

echo -n "This script is running on "
hostname

echo "This job was launched in the following directory:"
echo ${SLURM_SUBMIT_DIR}

Para eliminar una variable o variable de entorno puede utilizar el comando unset, por ejemplo:

BASH 

unset SECRET_IDENTITY

Variable de entorno PATH

Del mismo modo, algunas variables de entorno (como PATH) almacenan listas de valores. En este caso, la convención es utilizar dos puntos ‘:’ como separador. Si un programa quiere los elementos individuales de una lista de este tipo, es responsabilidad del programa dividir el valor de la cadena de la variable en trozos.

Echemos un vistazo más de cerca a la variable PATH. Su valor define la ruta de búsqueda de ejecutables del intérprete de comandos, es decir, la lista de directorios en los que el intérprete de comandos busca programas ejecutables cuando se escribe el nombre de un programa sin especificar en qué directorio se encuentra.

Por ejemplo, cuando escribimos un comando como analyze, el intérprete de órdenes tiene que decidir si ejecuta ./analyze o /bin/analyze. La regla que utiliza es simple: el intérprete de comandos comprueba cada directorio de la variable PATH por turnos, buscando un programa con el nombre solicitado en ese directorio. En cuanto encuentra una coincidencia, deja de buscar y ejecuta el programa.

Para mostrar cómo funciona, aquí están los componentes de PATH listados uno por línea:

SALIDA 

/Users/vlad/bin
/usr/local/git/bin
/usr/bin
/bin
/usr/sbin
/sbin
/usr/local/bin

En nuestro ordenador, en realidad hay tres programas llamados analyze en tres directorios diferentes: /bin/analyze, /usr/local/bin/analyze, y /users/vlad/analyze. Como el shell busca en los directorios en el orden en que están listados en PATH, encuentra /bin/analyze primero y lo ejecuta. Observa que nunca encontrará el programa /users/vlad/analyze a menos que introduzcamos la ruta completa al programa, ya que el directorio /users/vlad no está en PATH.

Esto significa que puedo tener ejecutables en un montón de lugares diferentes, siempre y cuando recuerde que tengo que actualizar mi PATH para que mi shell pueda encontrarlos.

¿Qué pasa si quiero ejecutar dos versiones diferentes del mismo programa? Como comparten el mismo nombre, si añado ambos a mi PATH el primero que encuentre siempre ganará. En el próximo episodio aprenderemos a utilizar herramientas de ayuda para gestionar nuestro entorno de ejecución y hacer que esto sea posible sin tener que hacer un montón de contabilidad sobre cuál es o debería ser el valor de PATH (y otras variables de entorno importantes).

Puntos Clave

  • Las variables del intérprete de órdenes se tratan por defecto como cadenas de caracteres
  • Las variables se asignan utilizando “=” y se recuperan utilizando el nombre de la variable precedido por “$”
  • Utilice “export” para poner una variable a disposición de otros programas
  • La variable PATH define la ruta de búsqueda de la shell

Content from Acceso al software a través de módulos

Última actualización: 2025-08-04 | Mejora esta página

Hoja de ruta

Preguntas

  • ¿Cómo se cargan y descargan los paquetes de software?

Objetivos

  • Carga y utiliza un paquete de software.
  • Explique cómo cambia el entorno del intérprete de órdenes cuando el mecanismo de módulos carga o descarga paquetes.

En un sistema informático de alto rendimiento, rara vez ocurre que el software que queremos utilizar esté disponible cuando nos conectamos. Está instalado, pero tendremos que “cargarlo” antes de que pueda ejecutarse.

Sin embargo, antes de empezar a utilizar paquetes de software individuales, deberíamos entender el razonamiento que hay detrás de este enfoque. Los tres factores más importantes son:

  • incompatibilidades de software
  • versionado
  • dependencias

La incompatibilidad de software es un gran dolor de cabeza para los programadores. A veces la presencia (o ausencia) de un paquete de software rompe otros que dependen de él. Dos ejemplos bien conocidos son las versiones de Python y del compilador de C. Python 3 proporciona un comando python que entra en conflicto con el que proporciona Python 2. El software compilado con una versión más reciente de las librerías C y ejecutado en una máquina que tiene instaladas librerías C más antiguas producirá un desagradable error 'GLIBCXX_3.4.20' not found.

El versionado de software es otro problema común. Un equipo puede depender de una determinada versión de un paquete para su proyecto de investigación - si la versión del software cambiara (por ejemplo, si se actualizara un paquete), podría afectar a sus resultados. Tener acceso a varias versiones de software permite a un conjunto de investigadores evitar que los problemas de versiones de software afecten a sus resultados.

Las dependencias se dan cuando un paquete de software concreto (o incluso una versión concreta) depende de tener acceso a otro paquete de software (o incluso a una versión concreta de otro paquete de software). Por ejemplo, el software de ciencia de materiales VASP puede depender de tener disponible una versión concreta de la biblioteca de software FFTW (Fastest Fourier Transform in the West) para funcionar.

Módulos de entorno

Los módulos de entorno son la solución a estos problemas. Un módulo es una descripción autocontenida de un paquete de software – contiene las configuraciones necesarias para ejecutar un paquete de software y, normalmente, codifica las dependencias necesarias de otros paquetes de software.

Hay un número de implementaciones de módulos de entorno diferentes comúnmente usadas en sistemas HPC: los dos más comunes son TCL modules y Lmod. Ambos usan una sintaxis similar y los conceptos son los mismos, por lo que aprender a usar uno te permitirá usar el que esté instalado en el sistema que estés usando. En ambas implementaciones se utiliza el comando module para interactuar con los módulos de entorno. Normalmente se añade un subcomando adicional al comando para especificar lo que se quiere hacer. Para obtener una lista de subcomandos puede utilizar module -h o module help. Como para todos los comandos, puede acceder a la ayuda completa en las páginas man con man module.

Al iniciar la sesión puede que empiece con un conjunto de módulos cargados por defecto o puede que empiece con un entorno vacío; esto depende de la configuración del sistema que esté utilizando.

Listado de módulos disponibles

Para ver los módulos de software disponibles, utilice module avail:

BASH 

[yourUsername@login1 ~] module avail

SALIDA 

~~~ /cvmfs/pilot.eessi-hpc.org/2020.12/software/x86_64/amd/zen2/modules/all ~~~
  Bazel/3.6.0-GCCcore-x.y.z              NSS/3.51-GCCcore-x.y.z
  Bison/3.5.3-GCCcore-x.y.z              Ninja/1.10.0-GCCcore-x.y.z
  Boost/1.72.0-gompi-2020a               OSU-Micro-Benchmarks/5.6.3-gompi-2020a
  CGAL/4.14.3-gompi-2020a-Python-3.x.y   OpenBLAS/0.3.9-GCC-x.y.z
  CMake/3.16.4-GCCcore-x.y.z             OpenFOAM/v2006-foss-2020a

[removed most of the output here for clarity]

  Where:
   L:        Module is loaded
   Aliases:  Aliases exist: foo/1.2.3 (1.2) means that "module load foo/1.2"
             will load foo/1.2.3
   D:        Default Module

Use "module spider" to find all possible modules and extensions.
Use "module keyword key1 key2 ..." to search for all possible modules matching
any of the "keys".

Listado de módulos cargados actualmente

Puede utilizar el comando module list para ver qué módulos tiene cargados actualmente en su entorno. Si no tiene ningún módulo cargado, verá un mensaje indicándoselo

BASH 

[yourUsername@login1 ~] module list

SALIDA 

No Modulefiles Currently Loaded.

Carga y descarga de software

Para cargar un módulo de software, utilice module load. En este ejemplo utilizaremos Python 3.

Inicialmente, Python 3 no está cargado. Podemos comprobarlo usando el comando which. which busca programas de la misma forma que lo hace Bash, así que podemos usarlo para que nos diga dónde está almacenado un software en particular.

BASH 

[yourUsername@login1 ~] which python3

Si el comando python3 no estuviera disponible, veríamos una salida como

SALIDA 

/usr/bin/which: no python3 in (/cvmfs/pilot.eessi-hpc.org/2020.12/compat/linux/x86_64/usr/bin:/opt/software/slurm/bin:/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/opt/puppetlabs/bin:/home/yourUsername/.local/bin:/home/yourUsername/bin)

Observe que este muro de texto es en realidad una lista, con valores separados por el carácter :. La salida nos está diciendo que el comando which buscó python3 en los siguientes directorios, sin éxito:

SALIDA 

/cvmfs/pilot.eessi-hpc.org/2020.12/compat/linux/x86_64/usr/bin
/opt/software/slurm/bin
/usr/local/bin
/usr/bin
/usr/local/sbin
/usr/sbin
/opt/puppetlabs/bin
/home/yourUsername/.local/bin
/home/yourUsername/bin

Sin embargo, en nuestro caso tenemos una python3 existente disponible, así que vemos

SALIDA 

/cvmfs/pilot.eessi-hpc.org/2020.12/compat/linux/x86_64/usr/bin/python3

Sin embargo, necesitamos un Python diferente al proporcionado por el sistema, así que carguemos un módulo para acceder a él.

Podemos cargar el comando python3 con module load:

BASH 

[yourUsername@login1 ~] module load Python
[yourUsername@login1 ~] which python3

SALIDA 

/cvmfs/pilot.eessi-hpc.org/2020.12/software/x86_64/amd/zen2/software/Python/3.x.y-GCCcore-x.y.z/bin/python3

¿Qué acaba de ocurrir?

Para entender la salida, primero necesitamos entender la naturaleza de la variable de entorno $PATH.$PATH es una variable de entorno especial que controla dónde busca software un sistema UNIX. Específicamente $PATH es una lista de directorios (separados por :) en los que el sistema operativo busca un comando antes de rendirse y decirnos que no puede encontrarlo. Como con todas las variables de entorno podemos imprimirla usando echo.

BASH 

[yourUsername@login1 ~] echo $PATH

SALIDA 

/cvmfs/pilot.eessi-hpc.org/2020.12/software/x86_64/amd/zen2/software/Python/3.x.y-GCCcore-x.y.z/bin:/cvmfs/pilot.eessi-hpc.org/2020.12/software/x86_64/amd/zen2/software/SQLite/3.31.1-GCCcore-x.y.z/bin:/cvmfs/pilot.eessi-hpc.org/2020.12/software/x86_64/amd/zen2/software/Tcl/8.6.10-GCCcore-x.y.z/bin:/cvmfs/pilot.eessi-hpc.org/2020.12/software/x86_64/amd/zen2/software/GCCcore/x.y.z/bin:/cvmfs/pilot.eessi-hpc.org/2020.12/compat/linux/x86_64/usr/bin:/opt/software/slurm/bin:/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/opt/puppetlabs/bin:/home/user01/.local/bin:/home/user01/bin

Notará una similitud con la salida del comando which. En este caso, sólo hay una diferencia: el directorio diferente al principio. Cuando ejecutamos el comando module load, se añadió un directorio al principio de nuestro $PATH. Examinemos lo que hay allí:

BASH 

[yourUsername@login1 ~] ls /cvmfs/pilot.eessi-hpc.org/2020.12/software/x86_64/amd/zen2/software/Python/3.x.y-GCCcore-x.y.z/bin

SALIDA 

2to3              nosetests-3.8  python                 rst2s5.py
2to3-3.8          pasteurize     python3                rst2xetex.py
chardetect        pbr            python3.8              rst2xml.py
cygdb             pip            python3.8-config       rstpep2html.py
cython            pip3           python3-config         runxlrd.py
cythonize         pip3.8         rst2html4.py           sphinx-apidoc
easy_install      pybabel        rst2html5.py           sphinx-autogen
easy_install-3.8  __pycache__    rst2html.py            sphinx-build
futurize          pydoc3         rst2latex.py           sphinx-quickstart
idle3             pydoc3.8       rst2man.py             tabulate
idle3.8           pygmentize     rst2odt_prepstyles.py  virtualenv
netaddr           pytest         rst2odt.py             wheel
nosetests         py.test        rst2pseudoxml.py

Llevando esto a su conclusión, module load añadirá software a su $PATH. Carga” software. Una nota especial sobre esto - dependiendo de la versión del programa module que esté instalado en su sitio, module load también cargará las dependencias de software necesarias.

Para demostrarlo, utilicemos module list.module list muestra todos los módulos de software cargados.

BASH 

[yourUsername@login1 ~] module list

SALIDA 

Currently Loaded Modules:
  1) GCCcore/x.y.z                 4) GMP/6.2.0-GCCcore-x.y.z
  2) Tcl/8.6.10-GCCcore-x.y.z      5) libffi/3.3-GCCcore-x.y.z
  3) SQLite/3.31.1-GCCcore-x.y.z   6) Python/3.x.y-GCCcore-x.y.z

BASH 

[yourUsername@login1 ~] module load GROMACS
[yourUsername@login1 ~] module list

SALIDA 

Currently Loaded Modules:
  1) GCCcore/x.y.z                    14) libfabric/1.11.0-GCCcore-x.y.z
  2) Tcl/8.6.10-GCCcore-x.y.z         15) PMIx/3.1.5-GCCcore-x.y.z
  3) SQLite/3.31.1-GCCcore-x.y.z      16) OpenMPI/4.0.3-GCC-x.y.z
  4) GMP/6.2.0-GCCcore-x.y.z          17) OpenBLAS/0.3.9-GCC-x.y.z
  5) libffi/3.3-GCCcore-x.y.z         18) gompi/2020a
  6) Python/3.x.y-GCCcore-x.y.z       19) FFTW/3.3.8-gompi-2020a
  7) GCC/x.y.z                        20) ScaLAPACK/2.1.0-gompi-2020a
  8) numactl/2.0.13-GCCcore-x.y.z     21) foss/2020a
  9) libxml2/2.9.10-GCCcore-x.y.z     22) pybind11/2.4.3-GCCcore-x.y.z-Pytho...
 10) libpciaccess/0.16-GCCcore-x.y.z  23) SciPy-bundle/2020.03-foss-2020a-Py...
 11) hwloc/2.2.0-GCCcore-x.y.z        24) networkx/2.4-foss-2020a-Python-3.8...
 12) libevent/2.1.11-GCCcore-x.y.z    25) GROMACS/2020.1-foss-2020a-Python-3...
 13) UCX/1.8.0-GCCcore-x.y.z

En este caso, al cargar el módulo GROMACS (un paquete de software bioinformático), también se han cargado GMP/6.2.0-GCCcore-x.y.z y SciPy-bundle/2020.03-foss-2020a-Python-3.x.y. Intentemos descargar el paquete GROMACS.

BASH 

[yourUsername@login1 ~] module unload GROMACS
[yourUsername@login1 ~] module list

SALIDA 

Currently Loaded Modules:
  1) GCCcore/x.y.z                    13) UCX/1.8.0-GCCcore-x.y.z
  2) Tcl/8.6.10-GCCcore-x.y.z         14) libfabric/1.11.0-GCCcore-x.y.z
  3) SQLite/3.31.1-GCCcore-x.y.z      15) PMIx/3.1.5-GCCcore-x.y.z
  4) GMP/6.2.0-GCCcore-x.y.z          16) OpenMPI/4.0.3-GCC-x.y.z
  5) libffi/3.3-GCCcore-x.y.z         17) OpenBLAS/0.3.9-GCC-x.y.z
  6) Python/3.x.y-GCCcore-x.y.z       18) gompi/2020a
  7) GCC/x.y.z                        19) FFTW/3.3.8-gompi-2020a
  8) numactl/2.0.13-GCCcore-x.y.z     20) ScaLAPACK/2.1.0-gompi-2020a
  9) libxml2/2.9.10-GCCcore-x.y.z     21) foss/2020a
 10) libpciaccess/0.16-GCCcore-x.y.z  22) pybind11/2.4.3-GCCcore-x.y.z-Pytho...
 11) hwloc/2.2.0-GCCcore-x.y.z        23) SciPy-bundle/2020.03-foss-2020a-Py...
 12) libevent/2.1.11-GCCcore-x.y.z    24) networkx/2.4-foss-2020a-Python-3.x.y

Así que usar module unload “descarga” un módulo, y dependiendo de cómo esté configurado un sitio puede que también descargue todas las dependencias (en nuestro caso no lo hace). Si quisiéramos descargar todo a la vez, podríamos ejecutar module purge (descarga todo).

BASH 

[yourUsername@login1 ~] module purge
[yourUsername@login1 ~] module list

SALIDA 

No modules loaded

Tenga en cuenta que module purge es informativa. También nos permitirá saber si un conjunto predeterminado de paquetes “pegajosos” no puede ser descargado (y cómo descargarlos si realmente lo deseamos).

Tenga en cuenta que este proceso de carga de módulos se produce principalmente a través de la manipulación de variables de entorno como $PATH. Normalmente hay poca o ninguna transferencia de datos implicada.

El proceso de carga de módulos manipula también otras variables de entorno especiales, incluyendo variables que influyen en dónde busca el sistema las bibliotecas de software, y a veces variables que indican a los paquetes de software comercial dónde encontrar los servidores de licencias.

El comando module también restaura estas variables de entorno del shell a su estado anterior cuando se descarga un módulo.

Versiones de software

Hasta ahora, hemos aprendido cómo cargar y descargar paquetes de software. Esto es muy útil. Sin embargo, aún no hemos abordado la cuestión del versionado de software. En un momento u otro, te encontrarás con problemas en los que sólo una versión concreta de algún software será adecuada. Puede que un error clave sólo se haya corregido en una versión determinada, o que la versión X haya roto la compatibilidad con un formato de archivo que utilizas. En cualquiera de estos casos, ayuda ser muy específico sobre el software que se carga.

Examinemos la salida de module avail más de cerca.

BASH 

[yourUsername@login1 ~] module avail

SALIDA 

~~~ /cvmfs/pilot.eessi-hpc.org/2020.12/software/x86_64/amd/zen2/modules/all ~~~
  Bazel/3.6.0-GCCcore-x.y.z              NSS/3.51-GCCcore-x.y.z
  Bison/3.5.3-GCCcore-x.y.z              Ninja/1.10.0-GCCcore-x.y.z
  Boost/1.72.0-gompi-2020a               OSU-Micro-Benchmarks/5.6.3-gompi-2020a
  CGAL/4.14.3-gompi-2020a-Python-3.x.y   OpenBLAS/0.3.9-GCC-x.y.z
  CMake/3.16.4-GCCcore-x.y.z             OpenFOAM/v2006-foss-2020a

[removed most of the output here for clarity]

  Where:
   L:        Module is loaded
   Aliases:  Aliases exist: foo/1.2.3 (1.2) means that "module load foo/1.2"
             will load foo/1.2.3
   D:        Default Module

Use "module spider" to find all possible modules and extensions.
Use "module keyword key1 key2 ..." to search for all possible modules matching
any of the "keys".

Uso de módulos de software en scripts

Crea un trabajo capaz de ejecutar python3 --version. Recuerde, ¡no se carga ningún software por defecto! Ejecutar un trabajo es como iniciar sesión en el sistema (no debe asumir que un módulo cargado en el nodo de inicio de sesión está cargado en un nodo de computación).

BASH 

[yourUsername@login1 ~] nano python-module.sh
[yourUsername@login1 ~] cat python-module.sh

SALIDA 

#!/bin/bash
#SBATCH
r config$sched$comment` -t 00:00:30

module load Python

python3 --version

BASH 

[yourUsername@login1 ~] sbatch  python-module.sh

Puntos Clave

  • Cargar software con module load softwareName.
  • Descargar software con module unload
  • El sistema de módulos gestiona automáticamente las versiones de software y los conflictos entre paquetes.

Content from Transferencia de archivos con ordenadores remotos

Última actualización: 2025-08-04 | Mejora esta página

Hoja de ruta

Preguntas

  • ¿Cómo transfiero archivos a (y desde) el cluster?

Objetivos

  • Transfiere archivos hacia y desde un clúster informático.

Realizar trabajo en un ordenador remoto no es muy útil si no podemos obtener ficheros hacia o desde el cluster. Existen varias opciones para transferir datos entre recursos informáticos utilizando utilidades CLI y GUI, algunas de las cuales veremos a continuación.

Descargar archivos de lecciones de Internet

Una de las formas más sencillas de descargar archivos es utilizar curl o wget. Uno de ellos suele estar instalado en la mayoría de los shells de Linux, en el terminal de Mac OS y en GitBash. Cualquier archivo que pueda descargarse en su navegador web a través de un enlace directo puede descargarse utilizando curl o wget. Esta es una forma rápida de descargar conjuntos de datos o código fuente. La sintaxis de estos comandos es

  • wget [-O new_name] https://some/link/to/a/file
  • curl [-o new_name] https://some/link/to/a/file

Pruébalo descargando algún material que usaremos más adelante, desde un terminal en tu máquina local, usando la URL de la base de código actual:

https://github.com/hpc-carpentry/amdahl/tarball/main

Descarga el “Tarball”

La palabra “tarball” en la URL anterior se refiere a un formato de archivo comprimido comúnmente utilizado en Linux, que es el sistema operativo que ejecutan la mayoría de las máquinas de clúster HPC. Un tarball es muy parecido a un archivo .zip. La extensión real del archivo es .tar.gz, que refleja el proceso en dos etapas utilizado para crearlo: los archivos o carpetas se fusionan en un único archivo utilizando tar, que luego se comprime utilizando gzip, por lo que la extensión del archivo es “tar-dot-g-z” Es un trabalenguas, así que la gente suele decir “el tarball xyz” en su lugar.

También puede ver la extensión .tgz, que no es más que una abreviatura de .tar.gz.

Por defecto, curl y wget descargan los archivos con el mismo nombre que la URL: en este caso, main. Utilice uno de los comandos anteriores para guardar el tarball como amdahl.tar.gz.

BASH 

[you@laptop:~]$ wget -O amdahl.tar.gz https://github.com/hpc-carpentry/amdahl/tarball/main
# or
[you@laptop:~]$ curl -o amdahl.tar.gz -L https://github.com/hpc-carpentry/amdahl/tarball/main

La opción -L para curl le dice que siga las redirecciones URL (lo que wget hace por defecto).

Después de descargar el archivo, utilice ls para verlo en su directorio de trabajo:

BASH 

[you@laptop:~]$ ls

Archivar ficheros

Uno de los mayores retos a los que nos enfrentamos a menudo cuando transferimos datos entre sistemas HPC remotos es el de un gran número de archivos. Hay una sobrecarga en la transferencia de cada archivo individual y cuando estamos transfiriendo un gran número de archivos estas sobrecargas se combinan para ralentizar nuestras transferencias en gran medida.

La solución a este problema es archivar múltiples ficheros en números más pequeños de ficheros más grandes antes de transferir los datos para mejorar nuestra eficiencia de transferencia. A veces combinaremos el archivado con la compresión para reducir la cantidad de datos que tenemos que transferir y así acelerar la transferencia. El comando de archivado más común en un cluster HPC (Linux) es tar.

tar puede utilizarse para combinar ficheros y carpetas en un único fichero de archivo y, opcionalmente, comprimir el resultado. Veamos el archivo que descargamos del sitio de la lección, amdahl.tar.gz.

La parte .gz significa gzip, que es una biblioteca de compresión. Es común (¡pero no necesario!) que este tipo de archivo pueda interpretarse leyendo su nombre: parece que alguien tomó archivos y carpetas relacionados con algo llamado “amdahl”, los envolvió todos en un único archivo con tar, y luego comprimió ese archivo con gzip para ahorrar espacio.

Veamos si es el caso, sin descomprimir el archivo. tar imprime el “table de contenidos” con la bandera -t, para el fichero especificado con la bandera -f seguido del nombre del fichero. Tenga en cuenta que puede concatenar las dos banderas: escribir -t -f es intercambiable con escribir -tf juntas. Sin embargo, el argumento que sigue a -f debe ser un nombre de fichero, por lo que escribir -ft no funcionará.

BASH 

[you@laptop:~]$ tar -tf amdahl.tar.gz
hpc-carpentry-amdahl-46c9b4b/
hpc-carpentry-amdahl-46c9b4b/.github/
hpc-carpentry-amdahl-46c9b4b/.github/workflows/
hpc-carpentry-amdahl-46c9b4b/.github/workflows/python-publish.yml
hpc-carpentry-amdahl-46c9b4b/.gitignore
hpc-carpentry-amdahl-46c9b4b/LICENSE
hpc-carpentry-amdahl-46c9b4b/README.md
hpc-carpentry-amdahl-46c9b4b/amdahl/
hpc-carpentry-amdahl-46c9b4b/amdahl/__init__.py
hpc-carpentry-amdahl-46c9b4b/amdahl/__main__.py
hpc-carpentry-amdahl-46c9b4b/amdahl/amdahl.py
hpc-carpentry-amdahl-46c9b4b/requirements.txt
hpc-carpentry-amdahl-46c9b4b/setup.py

Este ejemplo muestra una carpeta que contiene algunos archivos, donde 46c9b4b es un hash de confirmación git de 8 caracteres que cambiará cuando se actualice el material fuente.

Ahora vamos a descomprimir el archivo. Ejecutaremos tar con algunas banderas comunes:

  • -x para extraer el archivo
  • -v para una salida verbosa
  • -z para compresión gzip
  • -f «tarball» para el fichero a descomprimir

Extraer el archivo

Usando las banderas de arriba, desempaquete el tarball del código fuente en un nuevo directorio llamado “amdahl” usando tar.

BASH 

[you@laptop:~]$ tar -xvzf amdahl.tar.gz

SALIDA 

hpc-carpentry-amdahl-46c9b4b/
hpc-carpentry-amdahl-46c9b4b/.github/
hpc-carpentry-amdahl-46c9b4b/.github/workflows/
hpc-carpentry-amdahl-46c9b4b/.github/workflows/python-publish.yml
hpc-carpentry-amdahl-46c9b4b/.gitignore
hpc-carpentry-amdahl-46c9b4b/LICENSE
hpc-carpentry-amdahl-46c9b4b/README.md
hpc-carpentry-amdahl-46c9b4b/amdahl/
hpc-carpentry-amdahl-46c9b4b/amdahl/__init__.py
hpc-carpentry-amdahl-46c9b4b/amdahl/__main__.py
hpc-carpentry-amdahl-46c9b4b/amdahl/amdahl.py
hpc-carpentry-amdahl-46c9b4b/requirements.txt
hpc-carpentry-amdahl-46c9b4b/setup.py

Observe que no necesitamos teclear -x -v -z -f, gracias a la concatenación de banderas, aunque el comando funciona de forma idéntica de cualquier forma – siempre que la lista concatenada termine con f, porque la siguiente cadena debe especificar el nombre del fichero a extraer.

La carpeta tiene un nombre desafortunado, así que cambiémoslo por algo más conveniente.

BASH 

[you@laptop:~]$ mv hpc-carpentry-amdahl-46c9b4b amdahl

Comprueba el tamaño del directorio extraído y compáralo con el tamaño del archivo comprimido, utilizando du para “disk usage”.

BASH 

[you@laptop:~]$ du -sh amdahl.tar.gz
8.0K     amdahl.tar.gz
[you@laptop:~]$ du -sh amdahl
48K    amdahl

Los archivos de texto (incluido el código fuente de Python) se comprimen muy bien: ¡el “tarball” es una sexta parte del tamaño total de los datos en bruto!

Si desea invertir el proceso – comprimir los datos en bruto en lugar de extraerlos – establezca una bandera c en lugar de x, establezca el nombre del fichero de archivo, y luego proporcione un directorio para comprimir:

BASH 

[you@laptop:~]$ tar -cvzf compressed_code.tar.gz amdahl

SALIDA 

amdahl/
amdahl/.github/
amdahl/.github/workflows/
amdahl/.github/workflows/python-publish.yml
amdahl/.gitignore
amdahl/LICENSE
amdahl/README.md
amdahl/amdahl/
amdahl/amdahl/__init__.py
amdahl/amdahl/__main__.py
amdahl/amdahl/amdahl.py
amdahl/requirements.txt
amdahl/setup.py

Si das amdahl.tar.gz como nombre de fichero en el comando anterior, tar actualizará el tarball existente con cualquier cambio que hayas hecho en los ficheros. Eso significaría añadir la nueva carpeta amdahl a la carpeta existente (hpc-carpentry-amdahl-46c9b4b) dentro del tarball, ¡duplicando el tamaño del archivo!

Trabajando con Windows

Cuando transfieres ficheros de texto de un sistema Windows a un sistema Unix (Mac, Linux, BSD, Solaris, etc.) esto puede causar problemas. Windows codifica sus ficheros de forma ligeramente diferente a Unix, y añade un carácter extra a cada línea.

En un sistema Unix, cada línea de un archivo termina con una \n (nueva línea). En Windows, cada línea de un archivo termina con \r\n (retorno de carro + nueva línea). Esto a veces causa problemas.

Aunque la mayoría de los lenguajes de programación y software modernos manejan esto correctamente, en algunos casos raros, puede encontrarse con un problema. La solución es convertir un archivo de Windows a la codificación Unix con el comando dos2unix.

Puede identificar si un fichero tiene terminaciones de línea Windows con cat -A filename. Un fichero con terminaciones de línea Windows tendrá ^M$ al final de cada línea. Un fichero con terminaciones de línea Unix tendrá $ al final de cada línea.

Para convertir el archivo, basta con ejecutar dos2unix filename. (A la inversa, para volver a convertirlo al formato de Windows, puede ejecutar unix2dos filename)

Transferencia de archivos y carpetas con scp

Para copiar un único fichero hacia o desde el cluster, podemos utilizar scp (“copia segura”). La sintaxis puede resultar un poco compleja para los nuevos usuarios, pero vamos a desglosarla. El comando scp es un pariente del comando ssh que utilizamos para acceder al sistema, y puede utilizar el mismo mecanismo de autenticación de clave pública.

Para cargar a otro ordenador, el comando de plantilla es

BASH 

[you@laptop:~]$ scp local_file yourUsername@cluster.hpc-carpentry.org:remote_destination

en el que @ y : son separadores de campo y remote_destination es una ruta relativa a su directorio personal remoto, o un nuevo nombre de fichero si desea cambiarlo, o ambos una ruta relativa y un nuevo nombre de fichero. Si no tiene una carpeta específica en mente, puede omitir remote_destination y el archivo se copiará a su directorio personal en el ordenador remoto (con su nombre original). Si incluye remote_destination, tenga en cuenta que scp lo interpreta de la misma forma que cp cuando hace copias locales: si existe y es una carpeta, el fichero se copia dentro de la carpeta; si existe y es un fichero, el fichero se sobrescribe con el contenido de local_file; si no existe, se asume que es un nombre de fichero de destino para local_file.

Sube el material de la lección a tu directorio personal remoto de esta forma:

BASH 

[you@laptop:~]$ scp amdahl.tar.gz yourUsername@cluster.hpc-carpentry.org:

¿Por qué no descargar en HPC Carpentry’s Cloud Cluster directamente?

La mayoría de los clusters de ordenadores están protegidos de la Internet abierta por un firewall. Para mejorar la seguridad, algunos están configurados para permitir el tráfico entrante, pero no saliente. Esto significa que un usuario autentificado puede enviar un fichero a una máquina del cluster, pero una máquina del cluster no puede recuperar ficheros de la máquina de un usuario o de la Internet abierta.

Intente descargar el archivo directamente. Tenga en cuenta que puede fallar, ¡y no pasa nada!

BASH 

[you@laptop:~]$ ssh yourUsername@cluster.hpc-carpentry.org
[yourUsername@login1 ~] wget -O amdahl.tar.gz https://github.com/hpc-carpentry/amdahl/tarball/main
# or
[yourUsername@login1 ~] curl -o amdahl.tar.gz https://github.com/hpc-carpentry/amdahl/tarball/main

¿Por qué no descargar en HPC Carpentry’s Cloud Cluster directamente? (continued)

¿Funcionó? Si no, ¿qué te dice la salida del terminal sobre lo que ha pasado?

Transferir un directorio

Para transferir un directorio entero, añadimos la bandera -r para “recursivo”: copia el elemento especificado, y cada elemento por debajo de él, y cada elemento por debajo de esos… hasta que llegue al fondo del árbol de directorios enraizado en el nombre de carpeta que proporcionaste.

BASH 

[you@laptop:~]$ scp -r amdahl yourUsername@cluster.hpc-carpentry.org:

Precaución

Para un directorio grande – ya sea en tamaño o en número de ficheros – copiar con -r puede tardar mucho tiempo en completarse.

Cuando utilice scp, habrá notado que : siempre sigue al nombre del ordenador remoto. Una cadena después de : especifica el directorio remoto al que desea transferir el archivo o carpeta, incluyendo un nuevo nombre si desea renombrar el material remoto. Si deja este campo en blanco, scp por defecto será su directorio personal y el nombre del material local a transferir.

En los ordenadores Linux, / es el separador en las rutas de archivos o directorios. Una ruta que comienza con / se llama absoluta, ya que no puede haber nada por encima de la raíz /. Una ruta que no empieza por / se llama relativa, ya que no está anclada a la raíz.

Si quiere subir un fichero a una ubicación dentro de su directorio personal – lo que suele ser el caso – entonces no necesita un / líder. Después de :, puede escribir la ruta de destino relativa a su directorio personal. Si su directorio personal es el destino, puede dejar el campo de destino en blanco, o escribir ~ – la abreviatura de su directorio personal – para completar.

Con scp, una barra al final del directorio de destino es opcional y no tiene ningún efecto. Una barra al final del directorio de origen es importante para otros comandos, como rsync.

Nota sobre rsync

A medida que adquiera experiencia en la transferencia de archivos, puede que el comando scp le resulte limitante. La utilidad rsync proporciona características avanzadas para la transferencia de archivos y es normalmente más rápida comparada con scp y sftp (ver más abajo). Es especialmente útil para transferir archivos grandes y/o numerosos y para sincronizar el contenido de carpetas entre ordenadores.

La sintaxis es similar a scp. Para transferir a otro ordenador con opciones de uso común:

BASH 

[you@laptop:~]$ rsync -avP amdahl.tar.gz yourUsername@cluster.hpc-carpentry.org:

Las opciones son:

  • -a (archivo) para preservar las marcas de tiempo de los archivos, los permisos y las carpetas, entre otras cosas; implica recursión
  • -v (verbose) para obtener una salida detallada que le ayude a monitorizar la transferencia
  • -P (partial/progress) para preservar los archivos parcialmente transferidos en caso de interrupción y también muestra el progreso de la transferencia.

Para copiar recursivamente un directorio, podemos utilizar las mismas opciones:

BASH 

[you@laptop:~]$ rsync -avP amdahl yourUsername@cluster.hpc-carpentry.org:~/

Tal y como está escrito, esto colocará el directorio local y su contenido bajo tu directorio personal en el sistema remoto. Si se añade una barra al final del origen, no se creará un nuevo directorio correspondiente al directorio transferido, y el contenido del directorio de origen se copiará directamente en el directorio de destino.

Para descargar un archivo, simplemente cambiamos el origen y el destino:

BASH 

[you@laptop:~]$ rsync -avP yourUsername@cluster.hpc-carpentry.org:amdahl ./

Las transferencias de ficheros utilizando tanto scp como rsync utilizan SSH para encriptar los datos enviados a través de la red. Por lo tanto, si puede conectarse a través de SSH, podrá transferir archivos. Por defecto, SSH utiliza el puerto de red 22. Si se está utilizando un puerto SSH personalizado, tendrá que especificarlo utilizando la bandera apropiada, a menudo -p, -P, o --port. Comprueba --help o la página man si no estás seguro.

Cambiar el puerto Rsync

Supongamos que tenemos que conectarnos a rsync a través del puerto 768 en lugar del 22. ¿Cómo modificaríamos este comando?

BASH 

[you@laptop:~]$ rsync amdahl.tar.gz yourUsername@cluster.hpc-carpentry.org:

Pista: consulte la página man o la “ayuda” para rsync.

BASH 

[you@laptop:~]$ man rsync
[you@laptop:~]$ rsync --help | grep port
     --port=PORT             specify double-colon alternate port number
See http://rsync.samba.org/ for updates, bug reports, and answers
[you@laptop:~]$ rsync --port=768 amdahl.tar.gz yourUsername@cluster.hpc-carpentry.org:

(Tenga en cuenta que este comando fallará, ya que el puerto correcto en este caso es el predeterminado: 22.)

Transferencia interactiva de archivos con FileZilla

FileZilla es un cliente multiplataforma para descargar y subir archivos a y desde un ordenador remoto. Es absolutamente infalible y siempre funciona bastante bien. Utiliza el protocolo sftp. Puede leer más sobre el uso del protocolo sftp en la línea de comandos en la discusión de la lección.

Descargue e instale el cliente FileZilla desde https://filezilla-project.org. Tras instalar y abrir el programa, debería aparecer una ventana con un explorador de archivos de su sistema local en la parte izquierda de la pantalla. Cuando te conectes al cluster, los archivos de tu cluster aparecerán en la parte derecha.

Para conectarnos al cluster, sólo tendremos que introducir nuestras credenciales en la parte superior de la pantalla:

  • Host: sftp://cluster.hpc-carpentry.org
  • Usuario: Su nombre de usuario del cluster
  • Contraseña: Su contraseña del clúster
  • Puerto: (déjelo en blanco para usar el puerto por defecto)

Pulsa “Quickconnect” para conectarte. Deberías ver tus archivos remotos aparecer en la parte derecha de la pantalla. Puedes arrastrar y soltar archivos entre los lados izquierdo (local) y derecho (remoto) de la pantalla para transferir archivos.

Por último, si necesita mover archivos grandes (normalmente de más de un gigabyte) de un ordenador remoto a otro remoto, acceda mediante SSH al ordenador que aloja los archivos y utilice scp o rsync para transferirlos al otro. Esto será más eficiente que usar FileZilla (o aplicaciones relacionadas) que copiarían de la fuente a su máquina local, y luego a la máquina de destino.

Puntos Clave

  • wget y curl -O descarga un archivo de Internet.
  • scp y rsync transfieren archivos desde y hacia su ordenador.
  • Puede utilizar un cliente SFTP como FileZilla para transferir archivos a través de una GUI.

Content from Ejecutar un trabajo paralelo

Última actualización: 2025-08-04 | Mejora esta página

Hoja de ruta

Preguntas

  • ¿Cómo se ejecuta una tarea en paralelo?
  • ¿Qué ventajas aporta la ejecución en paralelo?
  • ¿Cuáles son los límites de las ganancias de la ejecución en paralelo?

Objetivos

  • Instale un paquete Python usando pip
  • Prepara un script de envío de trabajos para el ejecutable paralelo.
  • Lanzar trabajos con ejecución paralela.
  • Registrar y resumir el tiempo y la precisión de los trabajos.
  • Describa la relación entre el paralelismo de trabajos y el rendimiento.

Ahora tenemos las herramientas que necesitamos para ejecutar un trabajo multiprocesador. Este es un aspecto muy importante de los sistemas HPC, ya que el paralelismo es una de las principales herramientas que tenemos para mejorar el rendimiento de las tareas computacionales.

Si se desconectó, vuelva a conectarse al clúster.

BASH 

[you@laptop:~]$ ssh yourUsername@cluster.hpc-carpentry.org

Instalar el programa Amdahl

Con el código fuente de Amdahl en el cluster, podemos instalarlo, lo que nos dará acceso al ejecutable amdahl. Muévete al directorio extraído, y luego utiliza el Instalador de Paquetes para Python, o pip, para instalarlo en tu directorio personal (“usuario”):

BASH 

[yourUsername@login1 ~] cd amdahl
[yourUsername@login1 ~] python3 -m pip install --user .

Amdahl es código Python

El programa Amdahl está escrito en Python, e instalarlo o utilizarlo requiere localizar el ejecutable python3 en el nodo de inicio de sesión. Si no puede encontrarlo, intente listar los módulos disponibles usando module avail, cargue el apropiado, e intente el comando de nuevo.

MPI para Python

El código Amdahl tiene una dependencia: mpi4py. Si aún no ha sido instalado en el cluster, pip intentará recoger mpi4py de Internet e instalarlo por ti. Si esto falla debido a un cortafuegos unidireccional, deberás recuperar mpi4py en tu máquina local y subirlo, tal y como hicimos para Amdahl.

Recuperar y Subir mpi4py

Si la instalación de Amdahl falló porque mpi4py no pudo ser instalado, recupere el tarball de https://github.com/mpi4py/mpi4py/tarball/master luego rsync al cluster, extraiga, e instale:

BASH 

[you@laptop:~]$ wget -O mpi4py.tar.gz https://github.com/mpi4py/mpi4py/releases/download/3.1.4/mpi4py-3.1.4.tar.gz
[you@laptop:~]$ scp mpi4py.tar.gz yourUsername@cluster.hpc-carpentry.org:
# or
[you@laptop:~]$ rsync -avP mpi4py.tar.gz yourUsername@cluster.hpc-carpentry.org:

BASH 

[you@laptop:~]$ ssh yourUsername@cluster.hpc-carpentry.org
[yourUsername@login1 ~] tar -xvzf mpi4py.tar.gz  # extract the archive
[yourUsername@login1 ~] mv mpi4py* mpi4py        # rename the directory
[yourUsername@login1 ~] cd mpi4py
[yourUsername@login1 ~] python3 -m pip install --user .
[yourUsername@login1 ~] cd ../amdahl
[yourUsername@login1 ~] python3 -m pip install --user .

If pip Raises a Warning…

pip puede advertir que los binarios de su paquete de usuario no están en su PATH.

ADVERTENCIA 

WARNING: The script amdahl is installed in "${HOME}/.local/bin" which is
not on PATH. Consider adding this directory to PATH or, if you prefer to
suppress this warning, use --no-warn-script-location.

Para comprobar si esta advertencia es un problema, utilice which para buscar el programa amdahl:

BASH 

[yourUsername@login1 ~] which amdahl

Si el comando no devuelve ninguna salida, mostrando un nuevo prompt, significa que no se ha encontrado el fichero amdahl. Debe actualizar la variable de entorno llamada PATH para incluir la carpeta que falta. Edite el archivo de configuración de su shell de la siguiente manera, luego cierre la sesión en el cluster y vuelva a iniciarla para que surta efecto.

BASH 

[yourUsername@login1 ~] nano ~/.bashrc
[yourUsername@login1 ~] tail ~/.bashrc

SALIDA 

export PATH=${PATH}:${HOME}/.local/bin

Después de volver a entrar en cluster.hpc-carpentry.org, which debería ser capaz de encontrar amdahl sin dificultades. Si ha tenido que cargar un módulo de Python, vuelva a cargarlo.

¡Ayuda!

Muchos programas de línea de comandos incluyen un mensaje de “ayuda”. Pruébelo con amdahl:

BASH 

[yourUsername@login1 ~] amdahl --help

SALIDA 

usage: amdahl [-h] [-p [PARALLEL_PROPORTION]] [-w [WORK_SECONDS]] [-t] [-e] [-j [JITTER_PROPORTION]]

optional arguments:
  -h, --help            show this help message and exit
  -p [PARALLEL_PROPORTION], --parallel-proportion [PARALLEL_PROPORTION]
                        Parallel proportion: a float between 0 and 1
  -w [WORK_SECONDS], --work-seconds [WORK_SECONDS]
                        Total seconds of workload: an integer greater than 0
  -t, --terse           Format output as a machine-readable object for easier analysis
  -e, --exact           Exactly match requested timing by disabling random jitter
  -j [JITTER_PROPORTION], --jitter-proportion [JITTER_PROPORTION]
                        Random jitter: a float between -1 and +1

Este mensaje no nos dice mucho sobre lo que el programa hace, pero sí nos dice las banderas importantes que podríamos querer usar al lanzarlo.

Ejecutando el Trabajo en un Nodo de Computación

Crear un archivo de envío, solicitando una tarea en un único nodo, y luego lanzarla.

BASH 

[yourUsername@login1 ~] nano serial-job.sh
[yourUsername@login1 ~] cat serial-job.sh

BASH 

#!/bin/bash
#SBATCH -J solo-job
#SBATCH -p cpubase_bycore_b1
#SBATCH -N 1
#SBATCH -n 1

# Load the computing environment we need
module load Python

# Execute the task
amdahl

BASH 

[yourUsername@login1 ~] sbatch serial-job.sh

Como antes, utilice los comandos de estado Slurm para comprobar si su trabajo se está ejecutando y cuándo finaliza:

BASH 

[yourUsername@login1 ~] squeue -u yourUsername

Utilice ls para localizar el fichero de salida. La bandera -t ordena en orden cronológico inverso: el más reciente primero. ¿Cuál fue la salida?

La salida del cluster debe escribirse en un fichero en la carpeta desde la que lanzaste el trabajo. Por ejemplo,

BASH 

[yourUsername@login1 ~] ls -t

SALIDA 

slurm-347087.out  serial-job.sh  amdahl  README.md  LICENSE.txt

BASH 

[yourUsername@login1 ~] cat slurm-347087.out

SALIDA 

Doing 30.000 seconds of 'work' on 1 processor,
which should take 30.000 seconds with 0.850 parallel proportion of the workload.

  Hello, World! I am process 0 of 1 on smnode1. I will do all the serial 'work' for 4.500 seconds.
  Hello, World! I am process 0 of 1 on smnode1. I will do parallel 'work' for 25.500 seconds.

Total execution time (according to rank 0): 30.033 seconds

Como vimos antes, dos de las banderas del programa amdahl establecen la cantidad de trabajo y la proporción de ese trabajo que es de naturaleza paralela. Basándonos en la salida, podemos ver que el código utiliza por defecto 30 segundos de trabajo que es 85% paralelo. El programa se ejecutó durante algo más de 30 segundos en total, y si hacemos números, es cierto que el 15% del mismo se marcó como ‘serie’ y el 85% como ‘paralelo’.

Como sólo le dimos una CPU al trabajo, este trabajo no fue realmente paralelo: el mismo procesador realizó el trabajo “en serie” durante 4,5 segundos, y luego la parte “paralela” durante 25,5 segundos, y no se ahorró tiempo. El clúster puede hacerlo mejor, si se lo pedimos.

Ejecutando el Trabajo Paralelo

El programa amdahl utiliza la Interfaz de Paso de Mensajes (MPI) para el paralelismo - ésta es una herramienta común en los sistemas HPC.

¿Qué es MPI?

La interfaz de paso de mensajes es un conjunto de herramientas que permiten que varias tareas que se ejecutan simultáneamente se comuniquen entre sí. Normalmente, un único ejecutable se ejecuta varias veces, posiblemente en máquinas diferentes, y las herramientas MPI se utilizan para informar a cada instancia del ejecutable sobre sus procesos hermanos y de qué instancia se trata. MPI también proporciona herramientas que permiten la comunicación entre instancias para coordinar el trabajo, intercambiar información sobre elementos de la tarea o transferir datos. Una instancia MPI suele tener su propia copia de todas las variables locales.

Mientras que los ejecutables compatibles con MPI pueden ejecutarse generalmente como programas independientes, para que puedan ejecutarse en paralelo deben utilizar un entorno de ejecución MPI, que es una implementación específica del estándar MPI. Para activar el entorno MPI, el programa debe iniciarse mediante una orden como mpiexec (o mpirun, o srun, etc. dependiendo del entorno de ejecución MPI que necesite utilizar), que asegurará que se incluya el soporte de tiempo de ejecución apropiado para el paralelismo.

Argumentos de ejecución MPI

Por sí solos, comandos como mpiexec pueden tomar muchos argumentos que especifican cuántas máquinas participarán en la ejecución, y puede que los necesite si desea ejecutar un programa MPI por su cuenta (por ejemplo, en su portátil). En el contexto de un sistema de colas, sin embargo, es frecuente que el tiempo de ejecución MPI obtenga los parámetros necesarios del sistema de colas, examinando las variables de entorno establecidas cuando se lanza el trabajo.

Modifiquemos el script de trabajo para solicitar más núcleos y utilizar el tiempo de ejecución MPI.

BASH 

[yourUsername@login1 ~] cp serial-job.sh parallel-job.sh
[yourUsername@login1 ~] nano parallel-job.sh
[yourUsername@login1 ~] cat parallel-job.sh

BASH 

#!/bin/bash
#SBATCH -J parallel-job
#SBATCH -p cpubase_bycore_b1
#SBATCH -N 1
#SBATCH -n 4

# Load the computing environment we need
# (mpi4py and numpy are in SciPy-bundle)
module load Python
module load SciPy-bundle

# Execute the task
mpiexec amdahl

A continuación, envíe su trabajo. Tenga en cuenta que el comando de envío no ha cambiado realmente con respecto a cómo enviamos el trabajo serie: todos los ajustes paralelos están en el archivo por lotes en lugar de en la línea de comandos.

BASH 

[yourUsername@login1 ~] sbatch parallel-job.sh

Como antes, utiliza los comandos de estado para comprobar cuándo se ejecuta tu trabajo.

BASH 

[yourUsername@login1 ~] ls -t

SALIDA 

slurm-347178.out  parallel-job.sh  slurm-347087.out  serial-job.sh  amdahl  README.md  LICENSE.txt

BASH 

[yourUsername@login1 ~] cat slurm-347178.out

SALIDA 

Doing 30.000 seconds of 'work' on 4 processors,
which should take 10.875 seconds with 0.850 parallel proportion of the workload.

  Hello, World! I am process 0 of 4 on smnode1. I will do all the serial 'work' for 4.500 seconds.
  Hello, World! I am process 2 of 4 on smnode1. I will do parallel 'work' for 6.375 seconds.
  Hello, World! I am process 1 of 4 on smnode1. I will do parallel 'work' for 6.375 seconds.
  Hello, World! I am process 3 of 4 on smnode1. I will do parallel 'work' for 6.375 seconds.
  Hello, World! I am process 0 of 4 on smnode1. I will do parallel 'work' for 6.375 seconds.

Total execution time (according to rank 0): 10.888 seconds

¿Es 4× más rápido?

El trabajo paralelo recibió 4× más procesadores que el trabajo en serie: ¿significa eso que terminó en ¼ del tiempo?

El trabajo en paralelo tardó menos tiempo: ¡11 segundos es mejor que 30! Pero sólo es una mejora de 2,7×, no de 4×.

Mira la salida del trabajo:

  • Mientras el “proceso 0” hacía el trabajo en serie, los procesos del 1 al 3 hacían su trabajo en paralelo.
  • Mientras el proceso 0 se ponía al día en su trabajo paralelo, el resto no hacía nada.

El proceso 0 siempre tiene que terminar su tarea en serie antes de poder empezar con el trabajo en paralelo. Esto establece un límite inferior en la cantidad de tiempo que este trabajo va a tomar, no importa cuántos núcleos que lanzar en él.

Este es el principio básico de la Ley de Amdahl, que es una forma de predecir mejoras en el tiempo de ejecución para una carga de trabajo fija que puede subdividirse y ejecutarse en paralelo hasta cierto punto.

¿Cuánto mejora el rendimiento la ejecución en paralelo?

En teoría, dividir un cálculo perfectamente paralelo entre n procesos MPI debería producir una disminución del tiempo total de ejecución en un factor de n. Como acabamos de ver, los programas reales necesitan cierto tiempo para que los procesos MPI se comuniquen y coordinen, y algunos tipos de cálculos no pueden subdividirse: sólo se ejecutan eficazmente en una única CPU.

Además, si los procesos MPI operan en diferentes CPUs físicas en el ordenador, o a través de múltiples nodos de computación, se requiere incluso más tiempo para la comunicación del que se necesita cuando todos los procesos operan en una única CPU.

En la práctica, es habitual evaluar el paralelismo de un programa MPI mediante

  • ejecutar el programa en un rango de CPUs,
  • registrando el tiempo de ejecución en cada ejecución,
  • comparando cada tiempo de ejecución con el tiempo cuando se utiliza una única CPU.

Dado que “más es mejor” (la mejora es más fácil de interpretar a partir de aumentos en alguna cantidad que de disminuciones), las comparaciones se realizan utilizando el factor de aceleración S, que se calcula como el tiempo de ejecución en una sola CPU dividido por el tiempo de ejecución en varias CPU. Para un programa perfectamente paralelo, un gráfico del aumento de velocidad S frente al número de CPUs n daría una línea recta, S = n.

Vamos a ejecutar un trabajo más, para que podamos ver lo cerca de una línea recta que llega nuestro código amdahl.

BASH 

[yourUsername@login1 ~] nano parallel-job.sh
[yourUsername@login1 ~] cat parallel-job.sh

BASH 

#!/bin/bash
#SBATCH -J parallel-job
#SBATCH -p cpubase_bycore_b1
#SBATCH -N 1
#SBATCH -n 8

# Load the computing environment we need
# (mpi4py and numpy are in SciPy-bundle)
module load Python
module load SciPy-bundle

# Execute the task
mpiexec amdahl

A continuación, envíe su trabajo. Tenga en cuenta que el comando de envío no ha cambiado realmente con respecto a cómo enviamos el trabajo serie: todos los ajustes paralelos están en el archivo por lotes en lugar de en la línea de comandos.

BASH 

[yourUsername@login1 ~] sbatch parallel-job.sh

Como antes, utiliza los comandos de estado para comprobar cuándo se ejecuta tu trabajo.

BASH 

[yourUsername@login1 ~] ls -t

SALIDA 

slurm-347271.out  parallel-job.sh  slurm-347178.out  slurm-347087.out  serial-job.sh  amdahl  README.md  LICENSE.txt

BASH 

[yourUsername@login1 ~] cat slurm-347178.out

SALIDA 

which should take 7.688 seconds with 0.850 parallel proportion of the workload.

  Hello, World! I am process 4 of 8 on smnode1. I will do parallel 'work' for 3.188 seconds.
  Hello, World! I am process 0 of 8 on smnode1. I will do all the serial 'work' for 4.500 seconds.
  Hello, World! I am process 2 of 8 on smnode1. I will do parallel 'work' for 3.188 seconds.
  Hello, World! I am process 1 of 8 on smnode1. I will do parallel 'work' for 3.188 seconds.
  Hello, World! I am process 3 of 8 on smnode1. I will do parallel 'work' for 3.188 seconds.
  Hello, World! I am process 5 of 8 on smnode1. I will do parallel 'work' for 3.188 seconds.
  Hello, World! I am process 6 of 8 on smnode1. I will do parallel 'work' for 3.188 seconds.
  Hello, World! I am process 7 of 8 on smnode1. I will do parallel 'work' for 3.188 seconds.
  Hello, World! I am process 0 of 8 on smnode1. I will do parallel 'work' for 3.188 seconds.

Total execution time (according to rank 0): 7.697 seconds

Salida no lineal

Cuando ejecutamos el trabajo con 4 trabajadores paralelos, el trabajo en serie escribió su salida primero, luego los procesos paralelos escribieron su salida, con el proceso 0 llegando primero y último.

Con 8 trabajadores, este no es el caso: como los trabajadores paralelos tardan menos que el trabajo en serie, es difícil decir qué proceso escribirá su salida primero, ¡excepto que no será el proceso 0!

Ahora, vamos a resumir la cantidad de tiempo que tardó cada trabajo en ejecutarse:

Number of CPUs Runtime (sec)
1 30.033
4 10.888
8 7.697

Entonces, utilice la primera fila para calcular los speedups \(S\), utilizando Python como calculadora de línea de comandos y la fórmula

\[ S(t_{n}) = \frac{t_{1}}{t_{n}} \]

BASH 

[yourUsername@login1 ~] for n in 30.033 10.888 7.697; do python3 -c "print(30.033 / $n)"; done
Number of CPUs Speedup Ideal
1 1.0 1
4 2.75 4
8 3.90 8

Los archivos de salida del trabajo nos han estado diciendo que este programa está realizando el 85% de su trabajo en paralelo, dejando el 15% para ejecutarse en serie. Esto parece razonablemente alto, pero nuestro rápido estudio del aumento de velocidad muestra que para obtener un aumento de velocidad de 4×, tenemos que utilizar 8 o 9 procesadores en paralelo. En los programas reales, el factor de aumento de velocidad está influido por

  • Diseño de la CPU
  • red de comunicación entre nodos de cálculo
  • Implementaciones de bibliotecas MPI
  • detalles del propio programa MPI

Usando la Ley de Amdahl, puedes probar que con este programa es imposible alcanzar 8× de velocidad, sin importar cuántos procesadores tengas a mano. Los detalles de ese análisis, con resultados que lo respalden, se dejan para la siguiente clase del taller HPC Carpentry, HPC Workflows.

En un entorno HPC, intentamos reducir el tiempo de ejecución de todo tipo de trabajos, y MPI es una forma extremadamente común de combinar docenas, cientos o miles de CPUs en la resolución de un único problema. Para aprender más sobre paralelización, vea la lección parallel novice lesson.

Puntos Clave

  • La programación paralela permite a las aplicaciones aprovechar las ventajas del hardware paralelo.
  • El sistema de colas facilita la ejecución de tareas paralelas.
  • Las mejoras de rendimiento de la ejecución paralela no escalan linealmente.

Content from Uso eficaz de los recursos

Última actualización: 2025-08-04 | Mejora esta página

Hoja de ruta

Preguntas

  • ¿Cómo puedo revisar trabajos anteriores?
  • ¿Cómo puedo utilizar estos conocimientos para crear un script de envío más preciso?

Objetivos

  • Consulta las estadísticas de los trabajos.
  • Realiza peticiones de recursos más precisas en los scripts de trabajo basándose en datos que describen el rendimiento pasado.

Hemos tocado todas las habilidades necesarias para interactuar con un clúster HPC: iniciar sesión a través de SSH, cargar módulos de software, enviar trabajos paralelos y encontrar la salida. Vamos a aprender a estimar el uso de recursos y por qué puede ser importante.

Estimación de Recursos Requeridos Usando el Planificador

Aunque antes hemos cubierto la solicitud de recursos al planificador con el código π, ¿cómo sabemos qué tipo de recursos necesitará el software en primer lugar, y su demanda de cada uno? En general, a menos que la documentación del software o los testimonios de los usuarios nos den alguna idea, no sabremos cuánta memoria o tiempo de computación necesitará un programa.

Leer la documentación

La mayoría de las instalaciones HPC mantienen documentación en forma de wiki, sitio web o documento que se envía al registrarse para obtener una cuenta. Echa un vistazo a estos recursos y busca el software que piensas utilizar: puede que alguien haya escrito una guía para sacarle el máximo partido.

Una forma conveniente de averiguar los recursos necesarios para que un trabajo se ejecute con éxito es enviar un trabajo de prueba, y luego preguntar al planificador sobre su impacto utilizando sacct -u yourUsername. Puede utilizar este conocimiento para configurar el siguiente trabajo con una estimación más cercana de su carga en el sistema. Una buena regla general es pedir al programador entre un 20% y un 30% más de tiempo y memoria de lo que espera que necesite el trabajo. Esto garantiza que las pequeñas fluctuaciones en el tiempo de ejecución o en el uso de memoria no provoquen la cancelación del trabajo por parte del programador. Ten en cuenta que si pides demasiado, puede que tu trabajo no se ejecute aunque haya suficientes recursos disponibles, porque el programador estará esperando a que los trabajos de otras personas terminen y liberen los recursos necesarios para igualar lo que has pedido.

Estadísticas

Como ya hemos enviado amdahl para que se ejecute en el cluster, podemos consultar el planificador para ver cuánto tiempo ha tardado nuestro trabajo y qué recursos se han utilizado. Usaremos sacct -u yourUsername para obtener estadísticas sobre parallel-job.sh.

BASH 

[yourUsername@login1 ~] sacct -u yourUsername

SALIDA 

       JobID    JobName  Partition    Account  AllocCPUS      State ExitCode
------------ ---------- ---------- ---------- ---------- ---------- --------
7               file.sh cpubase_b+ def-spons+          1  COMPLETED      0:0
7.batch           batch            def-spons+          1  COMPLETED      0:0
7.extern         extern            def-spons+          1  COMPLETED      0:0
8               file.sh cpubase_b+ def-spons+          1  COMPLETED      0:0
8.batch           batch            def-spons+          1  COMPLETED      0:0
8.extern         extern            def-spons+          1  COMPLETED      0:0
9            example-j+ cpubase_b+ def-spons+          1  COMPLETED      0:0
9.batch           batch            def-spons+          1  COMPLETED      0:0
9.extern         extern            def-spons+          1  COMPLETED      0:0

Muestra todos los trabajos ejecutados hoy (tenga en cuenta que hay varias entradas por trabajo). Para obtener información sobre un trabajo específico (por ejemplo, 347087), cambiamos ligeramente el comando.

BASH 

[yourUsername@login1 ~] sacct -u yourUsername -l -j 347087

Mostrará mucha información; de hecho, cada pieza de información recopilada sobre su trabajo por el planificador aparecerá aquí. Puede ser útil redirigir esta información a less para facilitar su visualización (utilice las teclas de flecha izquierda y derecha para desplazarse por los campos).

BASH 

[yourUsername@login1 ~] sacct -u yourUsername -l -j 347087 | less -S

Discusión

Esta vista puede ayudar a comparar la cantidad de tiempo solicitado y realmente utilizado, la duración de la residencia en la cola antes del lanzamiento, y la huella de memoria en el nodo(s) de computación.

¿Hasta qué punto fueron precisas nuestras estimaciones?

Mejora de las solicitudes de recursos

A partir del historial de trabajos, vemos que los trabajos amdahl terminaron de ejecutarse en unos pocos minutos como máximo, una vez despachados. La estimación de tiempo que proporcionamos en el script del trabajo era demasiado larga Esto hace que sea más difícil para el sistema de colas estimar con precisión cuándo los recursos quedarán libres para otros trabajos. En la práctica, esto significa que el sistema de colas espera para despachar nuestro trabajo amdahl hasta que se abre todo el espacio de tiempo solicitado, en lugar de “colarlo” en una ventana mucho más corta en la que el trabajo podría realmente terminar. Especificar el tiempo de ejecución esperado en el script de envío con mayor precisión ayudará a aliviar la congestión del cluster y puede conseguir que su trabajo se despache antes.

Reducir la estimación de tiempo

Edita parallel_job.sh para establecer una mejor estimación del tiempo. ¿Qué tan cerca puedes estar?

Sugerencia: utilice -t.

La siguiente línea indica a Slurm que nuestro trabajo debe terminar en 2 minutos:

BASH 

#SBATCH -t 00:02:00

Puntos Clave

  • La precisión de los guiones de trabajo ayuda al sistema de colas a asignar eficazmente los recursos compartidos.

Content from Uso responsable de los recursos compartidos

Última actualización: 2025-08-04 | Mejora esta página

Hoja de ruta

Preguntas

  • ¿Cómo puedo ser un usuario responsable?
  • ¿Cómo puedo proteger mis datos?
  • ¿Cuál es la mejor forma de obtener grandes cantidades de datos de un sistema HPC?

Objetivos

  • Describe cómo las acciones de un único usuario pueden afectar a la experiencia de otros en un sistema compartido.
  • Discutir el comportamiento de un ciudadano considerado del sistema compartido.
  • Explica la importancia de hacer copias de seguridad de los datos críticos.
  • Describa los retos que plantea la transferencia de grandes cantidades de datos fuera de los sistemas HPC.
  • Convierte muchos ficheros en un único archivo comprimido utilizando tar.

Una de las principales diferencias entre utilizar recursos HPC remotos y tu propio sistema (por ejemplo, tu portátil) es que los recursos remotos se comparten. El número de usuarios que comparten el recurso en un momento dado varía de un sistema a otro, pero es poco probable que usted sea el único usuario conectado o utilizando un sistema de este tipo.

El uso generalizado de sistemas de programación en los que los usuarios envían trabajos a recursos HPC es un resultado natural de la naturaleza compartida de estos recursos. Hay otras cosas que usted, como miembro honrado de la comunidad, debe tener en cuenta.

Sea amable con los nodos de inicio de sesión

El nodo de inicio de sesión suele estar ocupado gestionando todos los usuarios conectados, creando y editando archivos y compilando software. Si la máquina se queda sin memoria o capacidad de procesamiento, se volverá muy lenta e inutilizable para todos. Aunque la máquina está pensada para ser utilizada, asegúrate de hacerlo de forma responsable, de manera que no afecte negativamente a la experiencia de los demás usuarios.

Los nodos de inicio de sesión son siempre el lugar adecuado para lanzar trabajos. Las políticas de clúster varían, pero también pueden utilizarse para probar flujos de trabajo y, en algunos casos, pueden albergar herramientas avanzadas de depuración o desarrollo específicas del clúster. El cluster puede tener módulos que necesitan ser cargados, posiblemente en un cierto orden, y rutas o versiones de librerías que difieren de tu portátil, y hacer una prueba interactiva en el nodo principal es una forma rápida y fiable de descubrir y arreglar estos problemas.

Los nodos de inicio de sesión son un recurso compartido

Recuerda que el nodo de inicio de sesión se comparte con todos los demás usuarios y tus acciones podrían causar problemas a otras personas. Piensa detenidamente en las posibles implicaciones de emitir comandos que puedan utilizar grandes cantidades de recursos.

¿No está seguro? Pregunte a su amable administrador de sistemas (“sysadmin”) si lo que está contemplando es adecuado para el nodo de inicio de sesión, o si existe otro mecanismo para hacerlo de forma segura.

Siempre puede utilizar los comandos top y ps ux para listar los procesos que se están ejecutando en el nodo de inicio de sesión junto con la cantidad de CPU y memoria que están utilizando. Si esta comprobación revela que el nodo de inicio de sesión está algo inactivo, puede utilizarlo con seguridad para su tarea de procesamiento no rutinaria. Si algo va mal – el proceso tarda demasiado, o no responde – puede usar el comando kill junto con el PID para terminar el proceso.

Etiqueta del nodo de inicio de sesión

¿Cuál de estos comandos sería una tarea rutinaria a ejecutar en el nodo login?

  1. python physics_sim.py
  2. make
  3. create_directories.sh
  4. molecular_dynamics_2
  5. tar -xzf R-3.3.0.tar.gz

Construir software, crear directorios y desempaquetar software son tareas > comunes y aceptables para el nodo de inicio de sesión: las opciones #2 (make), #3 (mkdir) y #5 (tar) probablemente estén bien. Tenga en cuenta que los nombres de los scripts no siempre reflejan su contenido: antes de lanzar #3, por favor less create_directories.sh y asegúrese de que no es un troyano.

No está bien visto ejecutar aplicaciones que consumen muchos recursos. A menos que esté seguro de que no afectará a otros usuarios, no ejecute trabajos como #1 (python) o #4 (código MD personalizado). Si no está seguro, pida consejo a su administrador de sistemas.

Si experimenta problemas de rendimiento con un nodo de inicio de sesión, debe informar de ello al personal del sistema (normalmente a través del servicio de asistencia) para que lo investiguen.

Prueba antes de escalar

Recuerde que generalmente se le cobra por el uso en sistemas compartidos. Un simple error en un script de trabajo puede acabar costando una gran cantidad de presupuesto de recursos. Imagina un script de trabajo con un error que hace que se quede sin hacer nada durante 24 horas en 1000 núcleos o uno en el que has solicitado 2000 núcleos por error y ¡sólo utilizas 100 de ellos! Este problema puede agravarse cuando la gente escribe scripts que automatizan el envío de trabajos (por ejemplo, cuando se ejecuta el mismo cálculo o análisis sobre muchos parámetros o archivos diferentes). Cuando esto ocurre, te perjudica tanto a ti (ya que desperdicias muchos recursos cargados) como a otros usuarios (que ven bloqueado su acceso a los nodos de cálculo ociosos). En recursos muy ocupados puedes esperar muchos días en una cola para que tu trabajo falle a los 10 segundos de empezar debido a un error tipográfico trivial en el script del trabajo. Esto es extremadamente frustrante

La mayoría de los sistemas proporcionan recursos dedicados para pruebas que tienen tiempos de espera cortos para ayudarte a evitar este problema.

Probar scripts de envío de trabajos que utilizan grandes cantidades de recursos

Antes de enviar una gran cantidad de trabajos, envíe primero uno como prueba para asegurarse de que todo funciona como se espera.

Antes de enviar un trabajo muy grande o muy largo envíe una pequeña prueba truncada para asegurarse de que el trabajo se inicia como se espera.

Tener un plan de copias de seguridad

Aunque muchos sistemas HPC guardan copias de seguridad, no siempre cubren todos los sistemas de ficheros disponibles y puede que sólo sean para fines de recuperación de desastres (es decir, para restaurar todo el sistema de ficheros en caso de pérdida en lugar de un fichero o directorio individual que hayas borrado por error). Proteger los datos críticos de la corrupción o el borrado es principalmente tu responsabilidad: mantén tus propias copias de seguridad.

Los sistemas de control de versiones (como Git) suelen tener ofertas gratuitas basadas en la nube (por ejemplo, GitHub y GitLab) que se utilizan generalmente para almacenar el código fuente. Incluso si no estás escribiendo tus propios programas, estos pueden ser muy útiles para almacenar scripts de trabajo, scripts de análisis y pequeños archivos de entrada.

Si está creando software, es posible que tenga una gran cantidad de código fuente que compila para crear su ejecutable. Dado que estos datos generalmente se pueden recuperar volviendo a descargar el código o volviendo a ejecutar la operación de comprobación desde el repositorio de código fuente, también es menos importante proteger estos datos.

Para grandes cantidades de datos, especialmente resultados importantes de sus ejecuciones, que pueden ser irremplazables, debe asegurarse de que dispone de un sistema robusto para sacar copias de los datos del sistema HPC siempre que sea posible a un almacenamiento de copia de seguridad. Herramientas como rsync pueden ser muy útiles para esto.

Su acceso al sistema HPC compartido estará generalmente limitado en el tiempo, por lo que debe asegurarse de tener un plan para transferir sus datos fuera del sistema antes de que termine su acceso. No subestime el tiempo necesario para transferir grandes cantidades de datos y asegúrese de planificarlo con suficiente antelación (idealmente, antes de empezar a utilizar el sistema para su investigación).

En todos estos casos, el servicio de asistencia del sistema que esté utilizando debería poder proporcionarle orientación útil sobre las opciones de transferencia de datos para los volúmenes de datos que vaya a utilizar.

Tus datos son tu responsabilidad

Asegúrate de que entiendes cuál es la política de copias de seguridad de los sistemas de archivos del sistema que estás utilizando y qué implicaciones tiene para tu trabajo si pierdes tus datos en el sistema. Planifica tus copias de seguridad de los datos críticos y cómo transferirás los datos fuera del sistema a lo largo del proyecto.

Transfiriendo datos

Como se mencionó anteriormente, muchos usuarios se encuentran con el reto de transferir grandes cantidades de datos fuera de los sistemas HPC en algún momento (esto es más frecuente en la transferencia de datos fuera que dentro de los sistemas, pero los consejos a continuación se aplican en ambos casos). La velocidad de transferencia de datos puede estar limitada por muchos factores diferentes, por lo que el mejor mecanismo de transferencia de datos que se puede utilizar depende del tipo de datos que se transfieren y a dónde van los datos.

Los componentes entre el origen y el destino de tus datos tienen diferentes niveles de rendimiento y, en particular, pueden tener diferentes capacidades con respecto al ancho de banda y la latencia.

El ancho de banda es generalmente la cantidad bruta de datos por unidad de tiempo que un dispositivo es capaz de transmitir o recibir. Es una métrica común y generalmente bien entendida.

La latencia es algo más sutil. Para las transferencias de datos, se puede considerar como la cantidad de tiempo que se tarda en sacar los datos del almacenamiento y ponerlos en una forma transmisible. Los problemas de latencia son la razón por la que es aconsejable ejecutar las transferencias de datos moviendo un pequeño número de archivos grandes, en lugar de lo contrario.

Algunos de los componentes clave y sus problemas asociados son:

  • Velocidad del disco: Los sistemas de archivos de los sistemas HPC suelen ser altamente paralelos y constan de un gran número de unidades de disco de alto rendimiento. Esto les permite soportar un ancho de banda de datos muy elevado. A menos que el sistema remoto tenga un sistema de ficheros paralelo similar, la velocidad de transferencia puede verse limitada por el rendimiento del disco en ese extremo.
  • Rendimiento de los metadatos: Las operaciones de metadatos, como abrir y cerrar archivos o listar el propietario o el tamaño de un archivo, son mucho menos paralelas que las operaciones de lectura/escritura. Si tus datos consisten en un gran número de archivos pequeños, puede que la velocidad de transferencia se vea limitada por las operaciones de metadatos. Las operaciones de metadatos realizadas por otros usuarios del sistema también pueden interactuar fuertemente con las que tú realizas, por lo que reducir el número de operaciones de este tipo que utilizas (combinando varios archivos en uno solo) puede reducir la variabilidad en tus tasas de transferencia y aumentar la velocidad de transferencia.
  • Velocidad de red: El rendimiento de la transferencia de datos puede verse limitado por la velocidad de la red. Más importante aún, está limitado por la sección más lenta de la red entre el origen y el destino. Si está transfiriendo a su ordenador portátil/estación de trabajo, es probable que ésta sea su conexión (ya sea a través de LAN o WiFi).
  • Velocidad del cortafuegos: La mayoría de las redes modernas están protegidas por algún tipo de cortafuegos que filtra el tráfico malicioso. Este filtrado tiene cierta sobrecarga y puede reducir el rendimiento de la transferencia de datos. Las necesidades de una red de uso general que aloja servidores web o de correo electrónico y equipos de sobremesa son muy distintas de las de una red de investigación que necesita transferir grandes volúmenes de datos. Si intentas transferir datos a o desde un host en una red de propósito general, puede que el cortafuegos de esa red limite la velocidad de transferencia que puedes alcanzar.

Como se ha mencionado anteriormente, si tienes datos relacionados que consisten en un gran número de archivos pequeños, se recomienda encarecidamente empaquetar los archivos en un archivo archive más grande para su almacenamiento y transferencia a largo plazo. Un único archivo grande hace un uso más eficiente del sistema de archivos y es más fácil de mover, copiar y transferir porque se requieren muchas menos operaciones de metadatos. Los ficheros de archivo pueden crearse con herramientas como tar y zip. Ya conocimos tar cuando hablamos anteriormente de la transferencia de datos.

¡Diagrama esquemático de ancho de banda y latencia para E/S de disco y red. Cada uno de los componentes de la figura está conectado por una línea azul de anchura proporcional al ancho de banda de la interfaz. Los pequeños laberintos en los puntos de enlace ilustran la latencia del enlace, con laberintos más tortuosos que indican una latencia mayor.

Considere la mejor forma de transferir datos

Si vas a transferir grandes cantidades de datos, tendrás que pensar en qué puede afectar al rendimiento de la transferencia. Siempre es útil realizar algunas pruebas que puedas utilizar para extrapolar el tiempo que tardará la transferencia de tus datos.

Supongamos que tienes una carpeta “data” que contiene unos 10.000 archivos, una buena mezcla de pequeños y grandes datos ASCII y binarios. ¿Cuál de las siguientes opciones sería la mejor para transferirlos a HPC Carpentry’s Cloud Cluster?

  1. scp -r data yourUsername@cluster.hpc-carpentry.org:~/

  2. rsync -ra data yourUsername@cluster.hpc-carpentry.org:~/

  3. rsync -raz data yourUsername@cluster.hpc-carpentry.org:~/

  4. tar -cvf data.tar data;

    rsync -raz data.tar yourUsername@cluster.hpc-carpentry.org:~/

  5. tar -cvzf data.tar.gz data;

    rsync -ra data.tar.gz yourUsername@cluster.hpc-carpentry.org:~/

  1. scp copiará recursivamente el directorio. Esto funciona, pero sin compresión.
  2. rsync -ra funciona como scp -r, pero conserva la información del archivo, como las horas de creación. Esto es ligeramente mejor.
  3. rsync -raz añade compresión, lo que ahorrará algo de ancho de banda. Si tienes una CPU potente en ambos extremos de la línea, y estás en una red lenta, ésta es una buena opción.
  4. Este comando utiliza primero tar para unir todo en un único archivo, y luego rsync -z para transferirlo con compresión. Con este número tan grande de ficheros, la sobrecarga de metadatos puede dificultar la transferencia, por lo que es una buena idea.
  5. Este comando utiliza tar -z para comprimir el archivo y luego rsync para transferirlo. Puede tener un rendimiento similar a #4, pero en la mayoría de los casos (para grandes conjuntos de datos), es la mejor combinación de alto rendimiento y baja latencia (aprovechando al máximo el tiempo y la conexión de red).

Puntos Clave

  • Ten cuidado con el uso del nodo login.
  • Tus datos en el sistema son tu responsabilidad.
  • Planifica y prueba grandes transferencias de datos.
  • A menudo es mejor convertir muchos ficheros en un único archivo antes de transferirlos.