Revisión de 17:45 2 jun 2024

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

Consideraciones iniciales

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

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
$

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

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.

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.

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:

• $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 simulado, con bastante capacidad, sin copia de seguridad y con límite de tiempo (1 mes)
• $STOREDIR: lugar de almacenaje, con mucha capacidad, sin copia de seguridad y sin límite de tiempo

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.

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]

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

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.

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

Distribución espacios de almacenaje

Sistema de colas

Todo trabajo en una máqiuna en remoto y multi-procesador tiene que ser ejecutado dentro de un trabajo del servidor de colas