Última revisión de 15:48 4 jun 2024

Algunas recomendaciones básicas de cómo manejarse con trabajo en un servidor compartido

[editar] Consideraciones iniciales

Cuando se trabaja desde un servidor el entorno gráfico NO EXISTE

[editar] Acceso

El acceso a los clúster de computación (HPC del Inglés) o servidores se realiza en la mayoría de los casos via ssh

$ ssh [NombreUsuarioenServidor]@[nombreServidor].[domino]

Por ejemplo, el CIMA dispone de un clúster de computación llamado hydra y con el domino cima.fcen.uba.ar. Si Juan Perez quiere acceder a Hydra usa el siguiente comando (al apretar enter, el sistema te pide la clave pero no aparece ningún cursor):

$ ssh juan.perez@hhydra.cima.fcen.uba.ar
juan.perez@hydra.cima.fcen.uba.ar's password:
[juan.perez@hydra ~]$

• Una vex en el servidor/clúster le usuarie tiene un entorno linux estándard. Al trabajar en un espacio compartido es necesario tener cuidado ya que los cambios podrían afectar a otras personas.
• Para salir, se usa la instrucción exit

[juan.perez@hydra ~]$ exit
$

[editar] vpn

La virtual private network o VPN nos permite conectarnos de forma segura a un servidor. En frente de la vulnerabilidad de la red, cada vez es más común conectarse a servidores a través de una VPN.

Para ello será necesario contar con una credencial de acceso (dada por la adminstración del recurso al cuál nos queremos conectar). Antes de conectarnos será necesario activar la VPN

[editar] Entorno de trabajo

En un servidor, se tendrá que hacer todo desde la terminal. Puesto que si queremos utilizar una interfaz gráfica (si es que es posible), seremos muy poco eficientes, porque a parte de mandarse las instrucciones por internet, también se tiene que mandar todos los gráficos.

Cuando se entra a un sevidor, se hace directamente al ${HOME} de cada usuarie.

En general, podemos encontrarnos con 2 tipos de servidores: datos, cálculo. Si bien conceptualmente son iguales, presentan distintas singularidades

Lo habitual es cada usuarie tenga una cantidad de recursos designados (espacio en disco, horas de cálculo, ...) si un usuarie supera estos límites, se imposibilita que continúe trabajando hasta que no se solucione el sobreuso.

[editar] Servidor de datos

Estos servidores suelen tener una jerarquía de directorios dentro de los cuáles están bien organizados los datos. Es necesario saber donde se encuentran los datos (desde una web, correo, ...) que queremos porque puede ser muy difícil encontrarnos.

[editar] Servidor de cálculo

Estos servidores suelen tener una jerarquía de directorios cada uno de los cuáles con distintas características y propósitos.

[editar] librerías sistema

Los servidores, suelen tener una gran batería de librerías ya pre instaladas llevado a cabo por los gestores del servidor. No es una tarea obvia, puesto que en un servidor, es clave la eficiencia, así que las librerías se suelen instalar desde los códigos fuentes y para distintas versiones y distintos compiladores. Además, si se escae, con flags de compilación específicos para el servidor. Toda esta complejidad está bien ordenada y hecha accesible para todes les usuaries. Se mantienen múltiples versiones (hasta un punto) para facilitar la reproducibilidad de experimentos antiguos.

[editar] module: gestor de librerías

En algunos servidores existe un software dedicado a la gestión de librerías llamado modules. Dicho sistema está diseñado para un manejo fácil y transparente. El sistema se encarga de definir las variables de compilación (ej. $LD_LIBRARY_PATH y de cargar los módulos dependientes necesarios (ej. compilador de fortran cuando cargando las librerías netCDF)

Se pueden listar las librerías existentes de una determinada librería con:

$ module avail [librería]

Y después se carga una determinada versión de la librería con

$ module load [librería]/[N].[M]

Se pueden cambiar las versiones con

$ module switch [librería]/[P].[Q]

[editar] entornos: anaconda, conda, miniconda

En un servidor no tenemos capacidad de instalación de nuevos programarios y/o librerías. Para eso es necesario recurrir a los gestores del servidor.

Para evitar este problema y dar libertad a les usuaries, aparecen los entornos tipo de la família conda (ej. anaconda). Con este gestor, se permite instalar programario y librerías directamente por el usuarie de un servidor.

Da mucha facilidad y flexibiliad y su uso es muy extendido y común, siendo a veces, incluso obligado. Ya que la gestión de librerías y programarios está personalizado por el propio usuario. Las personas a cargo del servidor, quedan liberadas de prestar servicio de apoyo y mantenimiento de librerías y software.

Aún así existen algunos inconvenientes:

• Pueden aparecer problemas de incompatibilidades entre paquetes y versiones de librerías
• Con un mal uso, se puede llegar a llenar el $HOME del usuario, llegando a duplicar en los peores casos todo el sistema operativo

[editar] Trabajo desde terminal

En un servidor lo más común es trabajar desde la terminal. Al principio puede ser bastante dificultoso. La edición de archivos de texto (ej. scripts y códigos) se tiene que hacer con editores de terminal (ej. vim, nano, emacs, ...).

El uso del entorno gráfico está altamante desaconsejado, puesto que el ancho de banda con el servidor, se llena con datos innecesarios, demorando la velocidad de trabajo y la eficiencia.

[editar] escritura de códigos

Una forma muy habitual de trabajar, es escribir los códigos a través de un repositorio. Esto nos facilita 2 cosas:

1. Copia de seguridad garantizada
2. Rápida y fácil actualización de códigos entre múltiplas computadoras

El desarrollo más grande de una script, se puede realizar desde una máquina en local (teniendo una copia en local reducida del trabajo a realizar). Una vez satisfechos, se traslada el trabajo al servidor donde se realizan los últimos retoques.

Por ejemplo, para post-procesar con python una salida de un modelo se puede trbajar:

1. Descarga en local de un par de archivos pequeños
2. Preparación del script en la máquina en local con los archivos descargados (ej. con spyder)
3. Actualización del repositorio una vez terminado
4. Ejecución de la script en el servidor desde la terminal

$ python3 [script].py

[editar] Distribución espacios de almacenaje

En un servidor, al ser un espacio compartido, es habitual que muchas de las componentes sean también compartidas.

La configuración estándar de espacios de almacenaje suele ser la siguiente:

• $HOME: punta de entrada al servidor, con poca capacidad, sin copia de seguridad y sin límite de tiempo
• $WORKDIR: lugar de los códigos y scripts con capacidad limitada y con copia de seguridad y sin límite de tiempo
• $SCRATCHDIR: lugar de trabajo, con bastante capacidad, sin copia de seguridad y con límite de tiempo (1 mes), el cuál pasado ese tiempo se borran automáticamente los archivos
• $STOREDIR: lugar de almacenaje, con mucha capacidad, sin copia de seguridad y sin límite de tiempo. En este espacio están los datos comunes y los resultados individuales

[editar] Sistema de colas

Todo trabajo en una máquina en remoto y multi-procesador tiene que ser ejecutado dentro de un trabajo del servidor de colas. Esto incluye desde un modelo a una script de shell/python/...

Archivo:Paralelizacion.pdf

Si bien un servidor puede tener múltiples procesadores, todes les usuaries, acceden a él, a través de un mismo acceso (ej. hydra en el CIMA). Esta máquina de acceso, maneja todo el servidor (colas, libreriías, compiladores, paralelización, ...). Si les usuaries ejecutan muchos programas en este acceso, relentizan su funcionamento, afectando a la totalidad del servidor.

Un gestor de colas nos garantiza:

• Uso igualitario entre usuaries
• Uso respetuoso
• Uso eficiente del servidor

Al ser un espacio de trabajo compartido, se tiene que garantizar que ningún usuarie entorpezca el trabajo de les otres. Si bien el servidor suele tener múltiple procesadores y gran memoria, los recursos siguen siendo limitados y su uso no puede ser un salvaje oeste. Para evitar esto se utiliza el servidor de colas.

El servidor de colas trabaja a partir del manejo de trabajos de colas. Estos trabajos contienen el programa que el usuario quiere utilizar y los recursos necesarios (memoria, cantidad de procesadores, tiempo de ejecución, ...) el flujo de trabajo es el siguiente:

1. El usuarie manda el trabajo de cola
2. El gestor de colas recibe el pedido
3. El gestor de colas determina:
   1. ejecución: Si el servidor tiene los recursos solicitados por el usuarie libres
   2. espera: Si el servidor no tiene los recursos solicitados, el tabajo se pone en modo esper (se manda ala cola)
4. El gestor de colas termina el trabajo si trasnscurrido el tiempo aún no terminado

Hay distintos gestores de colas: SLURM, PBS (versión libre no mantenida), ...

Archivo:SistemaColas.pdf

[editar] python

Mención especial para python, puesto que cada vez más existen paquetes paralelizados. Dicha paralelización está embebdia y el usuarie no suele prestar mucha atención a su configuración. En la mayoría de los casos (ej. dask), dicha paralelización está basada en threads (memoria compartida). Si no se configura, la script de python se ejectua en todos los cores disponibles.

Así que para evitar problemas con el equipo de entrada y manejo del servidor, las scripts de python también se tienen que ejecutar via una script de colas y nunca desde un entorno de programación (ej. spyder).