Archivo por meses: octubre 2013

Controlar aplicaciones en remoto usando screen y xpra

Normalmente, lo que se hace para ejecutar aplicaciones en un equipo remoto es conectarse mediante SSH (y si la aplicación utiliza ventanas gráficas, activando el X11 Forwarding con la opción -X). Esto es ampliamente conocido por los usuarios de GNU/Linux.

Pero esto obliga a mantener la conexión abierta, corriendo el riesgo además de que, si se corta, la aplicación reciba una señal HUP, que normalmente hace que se cierre. En cualquier caso, no es posible volver a interactuar con la aplicación.

nohup

Una primera aproximación puede ser utilizar nohup para que la aplicación ignore las señales HUP y no se cierre aunque la conexión se corte. Así no es posible recuperar su control más adelante, pero si no se trata de un trabajo interactivo es suficiente.

nohup trabajo &

screen

Screen es un gestor de sesiones de consola, que permite lanzar una sesión y recuperarla más adelante, si la conexión se corta o no queremos mantener el equipo conectado y encendido permanentemente.

Su uso es muy sencillo, basta con ejecutar este comando, con lo que se abrirá la sesión existente de haberla, o en caso contrario se creará una nueva:

screen -x -R

Una vez dentro de la sesión, puede controlarse con los siguientes atajos de teclado:

  • Control + A + D : Separarse sin cerrar la sesión (se podrá recuperar más adelante).
  • Control + D : Cerrar la sesión definitivamente.

Esto permite iniciar una sesión en un equipo, conectarse desde otro y recuperarla (interactuando incluso desde ambos equipos al mismo tiempo). O bien cerrar la conexión y recuperar la sesión más tarde.

El problema aparece cuando una aplicación utiliza ventanas gráficas, ya que, aunque se utilice el X11 forwarding combinado con screen, no es posible recuperar las ventanas más adelante tan solo usando screen.

Xpra

Xpra puede entenderse como un análogo de screen para ventanas. Es un servidor de X11 que permite conectarse a él desde diferentes lugares (eso sí, no al mismo tiempo) y así recuperar las ventanas de las aplicaciones ejecutándose en remoto.

En el equipo en el que va a estar ejecutándose la aplicación, se debe iniciar un servidor de xpra con el siguiente comando:

xpra start :100

Con esto, se iniciará un servidor X en el display número 100. A partir de entonces, solo hay que dirigir las aplicaciones a ese display para poder recuperarlas más adelante.

DISPLAY=:100 firefox

Para recuperar la ventana, sea desde el mismo o desde otro equipo conectándose por SSH con X11 Forwarding, basta con ejecutar el siguiente comando:

xpra attach :100

Hay que tener en cuenta que, al cerrar esa ventana recuperada, la aplicación recibe las señales habituales y terminará. Para desconectar de la ventana sin cerrar la aplicación, basta con pulsar Control + C en la terminal.

screen + Xpra

Si la aplicación es lanzada desde la propia sesión SSH, Xpra no impide que la aplicación se cierre al cortar la conexión SSH, por lo que lo habitual es combinar el uso de Xpra y screen:

xpra start :100 
DISPLAY=:100 screen -x -R

A partir de entonces, las aplicaciones lanzadas dentro de la sesión de screen se redirigirán al servidor Xpra, y podrán ser recuperadas en cualquier momento. Para hacerlo dentro de la sesión de screen, se debe especificar el display correcto.

firefox &
DISPLAY=:10.0 xpra attach :100

No es necesario conectarse por SSH previamente para recuperar una ventana, ya que Xpra puede hacerlo directamente con el siguiente comando:

xpra attach ssh:usuario@equipo:100

En la página de manual de Xpra hay mucha más información interesante, ya que permite hacer muchas más cosas. Además, en la wiki del centro hay un tutorial sobre el uso de screen.

Hardware para GPU computing

Hace unos días considerábamos la posibilidad de ampliar las capacidades de GPU computing del CITIUS, que en este momento consisten en dos servidores dedicados: ctgpgpu1 y ctgpgpu2.

El primero es un Supermicro X8DTG-D con 2 procesadores de 4 cores ,10 GB de RAM y 2 slots PCIe x16 Gen 2.0 con dos tarjetas gráficas: una NVidia Tesla S2050 [GF100] en PCIe y una Matrox MGA G200eW WPCM450 integrada.

El segundo es un Dell Precision Workstation R5400 con 2 procesadores de 4 cores, 8 GB de RAM y 2 slots PCIe x16 Gen 1.0 con una GeForce 8500 GT [G86] y una GTX 680  (GK104).

Aunque ambos servidores siguen funcionando bien y las tarjetas se renuevan con cierta frecuencia, el problema que tienen es que el bus PCIe de sus placas base es antiguo y empieza a ser un cuello de botella. En el caso de ctgpgpu2 es de primera generación (PCIe v1.0) y proporciona un máximo teórico de 4 GB/s (en slot 16x). En el caso de ctgpgpu1 es segunda generación (PCIe v2.0) y el máximo teórico es de 8 GB/s.

La tercera generación de PCIe (v3.0) se hizo pública en noviembre de 2011 y la cuarta generación (v4.0) se espera que salga en 2014 o 2015. Proporcionan máximos teóricos de 16 y 32 GB/s respectivamente. La razón por la que la adopción de la v3.0 está siendo lenta es porque para las tarjetas de consumo el ancho de banda proporcionado por la v2.0 aún es suficiente y el hardware resulta más barato.

Otros factores muy relacionados entre sí a tener en cuenta son el consumo y el calor. A medida que las GPU aumentan su nivel de integración y se hacen más potentes cada vez consumen más electricidad y en consecuencia generan más calor. Esto hace que los disipadores/ventiladores cada vez sean más grandes y las tarjetas ocupen más. Si el tamaño puede ser un problema en un equipo de escritorio, lo es aún más cuando hablamos de servidores en formato rack que tienen que ocupar el menor espacio posible.

Todos estos factores hacen que la oferta de servidores para GPU computing sea bastante limitada, y en general poco flexible. Es por eso que empezamos a buscar alguna solución que se saliera un poco de lo habitual y encontramos el concepto de “caja externa para GPU”.

La idea es tener las tarjetas gráficas en una caja externa e independiente, con su propia alimentación y conectada al bus PCIe del servidor que se quiera mediante un conector de tipo External PCI Express. Al estar en su propia caja es más fácil ventilarlas ya que no hay más componentes produciendo calor, tienen alimentación dedicada y lo más importante, no tienen que compartir el espacio de la caja con nada más.

Por ejemplo, de este tipo de solución Dell tiene el PowerEdge c410x, con espacio para un total de 16 tarjetas de modo que se pueden conectar 4 servidores con hasta 4 tarjetas cada uno.

c410xSin embargo el tamaño reservado para cada tarjeta es bastante limitado, y como es un producto un tanto antiguo todavía usa PCIe v2.0.

La oferta entre los fabricantes más importantes para este tipo de productos es muy escasa o nula, así que buscamos entre fabricantes no tan conocidos y encontramos el Netstor NA255A, una caja externa con PCIe v3.0 y espacio suficiente para 4 tarjetas grandes. Además hay una review del producto en Tom’s Hardware en la que sale muy bien parada. (Para los que no lo sepan, Tom’s Hardware es una de las páginas de reviews y benchmarking de hardware más antiguas y con mejor reputación de internet).

Turbobox-interior

Y encima hay una versión de la caja en formato enrackable con fuentes de alimentación redundantes, la NA265A.

na265Cualquiera de estos dos modelos se conecta al slot PCIe v3.0 de un ordenador mediante una tarjeta y un par de cables External  PCIe que vienen incluidos, de forma que lo que el usuario ve es que el ordenador tiene hasta cuatro tarjetas gráficas como si las tuviera directamente conectadas en la placa base.

La pega es que al ser un producto de un fabricante pequeño su distribución es “pobre” por decirlo suavemente y puede resultar complicado conseguirlo, pero lo estamos intentando.

Una duda que nos surgió a la hora de pensar en preparar este setup es ¿cual es el número máximo de GPU que admite un único ordenador?

Evidentemente está el número de slots PCIe disponibles para enchufarlas, el espacio físico donde colocarlas, una fuente de alimentación lo bastante potente como para hacerlas funcionar y la refrigeración necesaria, pero si solucionas todos esos inconvenientes, ¿cuantas GPUS como mucho puedes hacer funcionar en un PC?

Buscando información sobre esta cuestión descubrimos un proyecto del Vision Lab de la Universidad de Antwerp llamado Fastra II. En este proyecto montaron un PC con 13 GPUS tras conseguir una BIOS modificada del fabricante de la placa y hacer un parche para kernel. El problema reside en que las BIOS son de 32 bits y por lo tanto solo direccionan memoria por debajo de los 4 GB. Cada GPU requiere mapear unos 300 MB de memoria para inicializarse, y el resto del sistema también tiene sus requisitos. Esto hace que en la práctica un sistema no arranque con más de 8 o 9 GPUS. Este límite probablemente desaparecerá con los arranques de tipo UEFI.

Una vez solucionado el problema de la bios está el tema de los límites que te pueda imponer la combinación de controlador/sistema operativo, pero eso ya es un problema particular de cada fabricante y desarrollador.

Revisitando modules en ctcomp2

El clúster de computación ctcomp2 utiliza modules para la gestión del software. Aunque pueda parecer una opción ineficaz e incómoda, en comparación con las herramientas de gestión de paquetes en sistemas de sobremesa (como, por ejemplo, apt en GNU/Debian), lo cierto es que, desde el punto de vista del administrador, facilita la gestión de un sistema con muchos usuarios que, a su vez, tienen muchas y muy variadas necesidades. En este post repasamos algunos conceptos de modules y os explicaremos la política de ctcomp2 para utilizar software que incorpore un gestor de paquetes propio.

Básicamente, el comando modules maneja las variables de entorno para modificar los PATHs en los que el sistema operativo busca los ficheros ejecutables, las librerías… Cada nueva versión del software que se instale en el sistema se encapsula dentro de un módulo que contiene toda la información necesaria para ejecutar adecuadamente el software. De este modo, es posible mantener software incompatible dentro de un mismo sistema o varias versiones diferentes de un mismo programa: el usuario es quien decide el módulo que debe utilizar en cada momento.

El uso de modules facilita la gestión de software instalado en un sistema distribuido, ya que no es necesario instalar el software en todos los nodos del clúster, sino que directamente el nuevo software/versión se instala en un sistema de ficheros compartido por todos los componentes del sistema. Por otro lado, el uso de modules es potencialmente incompatible con la instalación de software precompilado disponible a través del gestor de paquetes, ya que las versiones en ambos espacios pueden ser inconsistentes. Estos motivos nos han llevado a establecer una política de uso para aquellas herramientas que dispongan de un instalador de paquetes propio integrado (R, Python o Octave, por ejemplo). La instalación de paquetes asociados a estos programas la realizará el usuario a través del propio programa, instalando los paquetes en un directorio de su propio HOME, en vez de utilizar los directorios del sistema. Es decir, siempre que sea posible, el usuario deberá realizar la instalación de software. Puede parecer cómodo administrativamente… y sí, lo es, ¡pero es por el bien común, para garantizar la estabilidad del sistema! En el Repositorio de documentación podéis encontrar un pequeño manual con ejemplos de cómo utilizar los instaladores integrados para los programas instalados en ctcomp2.

Para finalizar, hagamos un pequeño repaso a los comandos básicos de modules.

  1. Ver el listado de módulos disponibles en el sistema:
    module avail
  2. Cargar un módulo:
    module load modulo/version

    A partir de este instante, ya podremos utilizar el software asociado a ese módulo.

  3. Eliminar un módulo:
    module unload modulo/version

    A partir de este instante ya no se puede acceder al software asociado a ese módulo.

Teneis más información el la Guía de usuario del clúster ctcomp2.