Archivo de la categoría: Coñece os servizos

Estadísticas de uso del clúster

El sistema de colas PBS/Torque instalado en el clúster de computación ctcomp2 permite realizar una traza de cada trabajo enviado a las colas del sistema. Esta traza registra el Unix Time de todos los eventos relacionados con el sistema de colas (como, por ejemplo, el registro en las colas, el envío a los nodos de ejecución y la finalización del trabajo), así como otros parámetros no temporales (como el tipo de cola, el contenido del script o los recursos solicitados/consumidos). En este artículo os mostraremos un resumen de algunas de las estadísticas de uso del clúster en los últimos meses, a partir del momento en el que se instalaron los últimos nodos de computación adquiridos. En concreto, consideraremos el período 1/9/2013 a 15/11/2013.

Como sabéis, ctcomp2 dispone de un sistema de gestión de energía, CLUES, que permite apagar/encender los nodos computacionales en función de la demanda de recursos de los trabajos registrados en las colas PBS. En el período considerado, los nodos han estado, en media, un 38,55% del tiempo apagados y un 25,32% ociosos. Podéis ver los resultados por nodo en la siguiente imagen (tened en cuenta que los nodos node1, inode11 e inode20 están fuera del sistema CLUES, por lo que deberían estar siempre encendidos aunque no haya trabajos):

ctcomp2_usage

En este período se han contabilizado 36929 trabajos, con un tiempo de ejecución medio de 1 hora 20 minutos (siendo la mediana 3 minutos y el tiempo máximo de ejecución 280 horas). En esta métrica hay que tener en cuenta que se están contabilizando los trabajos que han fallado (es decir, que no han realizado las tareas que el usuario esperaba por algún tipo de error en la ejecución del script), pero que desde el punto de vista del sistema de colas se han ejecutado correctamente. El tiempo medio de espera en cola de los trabajos ha sido 4 minutos 27 segundos (siendo la mediana 44 segundos y el tiempo máximo de espera 43 horas 25 minutos). Curiosamente, el usuario que más ha esperado es el mismo que el que ostenta la ejecución más costosa temporalmente…

En cuanto a los usuarios, actualmente hay 35 usuarios activos en el clúster. Extraoficialmente, ya que no existen estadísticas oficiales, hay 6-8 usuarios muy activos. Técnicamente, sería posible realizar una estadística del consumo de recursos por usuario pero, por un lado, no me gusta “señalar” y, por otro lado, teniendo en cuenta las estadísticas de uso mostradas, no existe necesidad. En cualquier caso, desde un punto de vista global, la intensidad de uso del clúster en una semana sigue el patrón que se muestra en la siguiente figura (rojo: trabajos en cola, azul: trabajos en ejecución, negro: trabajos totales):

zabbix_colas

Simplemente destacar que, tal y como refleja la figura, los mayores picos de intensidad suelen ser los lunes a las 18:00 y los viernes a las 12:00.

Por último, en cuanto al tipo de trabajos, el que más recursos consume es, con diferencia, MATLAB: pbs_modulesEsta gráfica está generada a partir de los comandos ‘module’ que se utilizan en los scripts. El tipo de trabajos ‘none’ incluye a los trabajos que no utilizan módulos (C, Fortran, Python, Octave…).

Acceso remoto á rede do centro: ¿como e para que?

É posible acceder á rede do centro e ó teu equipo dende outros centros ou dende a casa, e non é moi complicado. O primeiro é conseguir acceso á rede do centro. Para facelo, hai dúas alternativas:

  • A VPN, ou rede privada virtual, unha tecnoloxía que permite extender a rede do centro a través de Internet. Unha vez configurada a VPN nun equipo, é coma si estivera conectado á mesma rede do centro, polo que pódese acceder a todos os recursos da rede.
  • A pasarela SSH, unha máquina que está na rede do centro á que se pode conectar un por SSH dende calquera sitio.

Acceder á rede do centro non só serve para acceder a recursos propios do CiTIUS. Tamén pode ser unha forma de acceder a recursos que normalmente só están accesibles dende a rede da universidade, como a información de nóminas ou o acceso a certos catálogos de publicacións. Ten en conta que o acceso ó exterior usando a VPN está restrinxido, e só se pode acceder ós sitios no Listado de sitios accesibles a través da VPN (require autenticación).

A pasarela SSH tamén pode ser moi útil para saltarse restriccións de redes con firewalls, que limitan o acceso a determinados portos ou de determinado tipo de tráfico. Por exemplo, dalgunhas redes públicas onde só é posible acceder a portos como o 80 e o 443. Usando un túnel inverso SSH, a información viaxa ata a rede da universidade en paquetes SSH, e dende aí ó destino.

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.

Sesiones gráficas en el clúster de computación

Como sabeis, el comportamiento normal de funcionamiento del clúster de computación ctcomp2 es mediante trabajos batch en el sistema de colas: los usuarios envían al sistema de colas un script con las instrucciones para ejecutar sus trabajos, que se ejecutará, de modo no interactivo, en los nodos computacionales cuando estén disponibles los recursos solicitados para su ejecución. Al margen de los trabajos batch, la cola interactive permite al usuario realizar una sesión interactiva con el mismo entorno de ejecución que el de los trabajos batch. El objetivo de esta cola es proporcionar un pequeño test de pruebas antes de enviar trabajos a las colas del sistema. Dado que en las colas batch no se pueden ejecutar aplicaciones gráficas, en la cola interactive no se ha habilitado esta característica.

Debido a una demanda de los usuarios del clúster, se han modificado las políticas de colas del clúster para admitir sesiones interactivas en las que se puedan ejecutar programas que requieran interfaz gráfica. Las sesiones interactivas serán invocadas a través del comando graphicX_session. Este comando realiza automáticamente una petición a una cola especial del sistema y se conecta automáticamente a esta nueva sesión interactiva. Al igual que la cola interactive, la sesión gráfica tiene un límite de tiempo de ejecución, pero en este caso es de 4 horas. Para una correcta ejecución del comando, es necesario habilitar la redirección de los gráficos, por lo que los usuarios deben conectarse a ctcomp2 activando esta característica (ssh -X).

El comando graphicX_session requiere obligatoriamente un argumento, para indicar el número de núcleos computacionales que queremos asociar a nuestra sesión interactiva. Así, por ejemplo, si queremos una sessión interactiva gráfica con 8 núcleos tendríamos que ejecutar:

graphicX_session 8

¿Por qué es necesario indicar el número de procesadores? El motivo de este argumento es en realidad establecer el tamaño de memoria asignada a la sesión, ya que, en ctcomp2, la memoria asignada a un trabajo (en GB) es dos veces el número de núcleos asignado. Por lo tanto, en el ejemplo anterior estaríamos solicitando una sesión interactiva, con capacidad de ejecutar gráficos, y con la posibilidade de utilizar 16 GB de memoria. Actualmente, solo se admiten como argumentos válidos los valores 1, 8 y 32.

Por último, hay que tener en cuenta que el clúster es un recurso compartido, por lo que la disponibilidad de este tipo de sesiones está limitada por la carga de trabajo del clúster y el número de sesiones gráficas activas de todos los usuarios. La carga del clúster se puede consultar con el comando pbsnodes: los nodos con un estado free admitirían, por lo menos, un trabajo de un proceso (un núcleo). Si se solicitan más procesos es posible que no se pueda asignar inmediatamente una sesión gráfica.

Máis información en la Guía de usuario del clúster ctcomp2.

Novo hardware no clúster de computación

Como anunciamos fai unhas semanas, gracias a unha recente adquisición o clúster de computación ctcomp2 ven de incorporar 5 novos servidores, equipados cada un con dous procesadores Intel Xeon E5-2650L, polo que o clúster está agora composto de 18 nodos, que suman un total de 832 núcleos computacionais, distribuidos do seguinte xeito:

  • node1…node8: servidores HP Proliant BL685c G7. Cada servidor está equipado con 4 procesadores AMD Opteron 6262HE (4×16 núcleos) e 128 GB RAM.
  • inode11…inode15: 5 servidores blade Dell PowerEdge M910. Cada servidor está equipado con dous procesadores Intel Xeon L7555 (2×16 núcleos) e 64 GB RAM.
  • inode16…inode20:5 servidores blade Dell PowerEdge M620. Cada servidor está equipado con dous procesadores Intel Xeon E5-2650L (2×16 núcleos) e 64 GB RAM.

A capacidade de procesamento do clúster aumentou sustancialmente, polo que se revisaron os límites establecidos na política de colas. En xeral, estos límites víronse incrementados. Os detalles poden consultarse na sección Envío de trabajos al sistema de colas Torque/PBS da Guía de usuario del clúster ctcomp2.

Aqueles usuarios ós que lle interese a execución dos seus traballos nun tipo de hardware específico deben especificalo explícitamente na opción -l do comando qsub, a través da correspondente propiedade dos nodos dexesados (amd, xeonl, ou xeone5). As propiedades de cada nodo do clúster poden consultarse co comando pbsnodes:

pbsnodes | grep -E '(^(inode|node)|properties)'

Por exemplo, se queremos executar un traballo (1 núcleo, 1 nodo, 1 hora) nun nodo Dell PowerEdge M910 (procesador Intel Xeon L), a correspondente líña #PBS do scrip debería ser:

#PBS -l nodes=1:ppn=1:xeonl,walltime=1:00:00

Namentres que se o hardware desexado é un nodo Dell PowerEdge M620 (procesador Intel Xeon E5), a liña será:

#PBS -l nodes=1:ppn=1:xeone5,walltime=1:00:00

Se polo contrario, queremos que se execute nun nodo HP Proliant (procesador AMD Opteron), a liña debería ser:

#PBS -l nodes=1:ppn=1:amd,walltime=1:00:00

Por último, recordade que, ainda que os novos procesadores incorporados son de última xeración, a execución de códigos secuenciais no clúster pode ser máis lenta que nun equipo de sobremesa. Tede en conta que todos os procesadores do clúster (incluso os novos Xeon) teñen unha frecuencia de funcionamente moi baixa. As vantaxes de utilizar o clúster para este tipo de códigos son principalmente dúas:

  • descargar de traballo ós vosos equipos de sobremesa cando as execucións son moi longas (así poderedes apagar os vosos equipos polas noites), e
  • ter a capacidade de executar moitos traballos simultaneamente (por exemplo, facendo estudos paramétricos): ainda que tardemos máis tempo en obter o primeiro resultado, o tempo preciso para obter todos os resultados pode reducirse considerablemente.

Máis información na Guía de usuario del clúster ctcomp2.

Limitaciones de Java y MATLAB en ctcomp2

En el clúster de computación ctcomp2 se han definido ciertas limitaciones para los programas JAVA y MATLAB, para regular el comportamiento de ciertas características de estos programas. Aunque estas características no suelen afectar a las ejecuciones en los sistemas de sobremesa, es importante tener en cuenta estas limitaciones para un aprovechamiento adecuado de los recursos computacionales del clúster.

Limitaciones de Java

En ctcomp2 el tamaño del heap de JAVA está limitado al 25% del límite de memoria asignado por el sistema de colas y, en cualquier caso, tiene un tamaño máximo de 8 GB. Esta limitación garantiza que las aplicaciones Java no consuman más recursos de los asignados.

Los usuarios pueden utilizar otros tamaños de heap en sus trabajos si modifican, antes de ejecutar Java, el valor de la opción -Xmx a través de la variable _JAVA_OPTIONS. Por ejemplo, si queremos que el heap tenga 16 GB, el comando sería:

export _JAVA_OPTIONS=-Xmx16777216K

Al modificar el tamaño del heap el usuario debe asegurarse, bajo su responsabilidad, que el conjunto de procesos que se estén ejecutando concurrentemente en su trabajo no sobrepase el límite de memoria establecido en la correspondiente cola, ya que en ese caso el trabajo será cancelado automáticamente.

Los usuarios que ejecuten en sus trabajos una solo instancia de Java (independientemente de los threads que ejecute) podrán aumentar el tamaño del heap, aunque se recomienda que no sea un valor cercano al límite de memoria asociado al número de núcleos solicitados.

Por ejemplo, si queremos reservar en exclusiva un nodo AMD y aumentar el heap a 32 GB:

#!/bin/bash
#PBS -l nodes=1:ppn=64:amd,walltime=1:00:00
cd $PBS_O_WORKDIR
module load jdk
export _JAVA_OPTIONS=-Xmx33554432K
java executable

Más información en la Guía de usuario del clúster ctcomp2.

Limitaciones de MATLAB

Desde la versión 2007, MATLAB emplea internamente, y de manera transparente al usuario, threads para acelerar ciertas operaciones. Sin embargo, en las versiones instaladas en ctcomp2 no es posible controlar esta característica, por lo que MATLAB utiliza todos los recursos del nodo asignado, independientemente de los recursos solicitados. Para evitar posibles cancelaciones debido a un uso indebido de los recursos asignados, se recomienda a los usuarios:

  • Utilizar el paralelismo implícito de MATLAB solo cuando se reserve en exclusividad un nodo del clúster. Por ejemplo, si reservamos en exclusiva un nodo Intel:
    #!/bin/bash
    #PBS -l nodes=1:ppn=32:intel,walltime=1:00:00
    cd $PBS_O_WORKDIR
    module load matlab
    matlab -r test -nodisplay -nojvm -nosplash
  • En cualquier otro caso, se recomienda solicitar un único núcleo (nodes=1:ppn=1) y utilizar la opción -singleCompThread, que desactiva el paralelismo implícito de MATLAB. Por ejemplo:
    #!/bin/bash
    #PBS -l nodes=1:ppn=1,walltime=1:00:00
    cd $PBS_O_WORKDIR
    module load matlab
    matlab -r test -nodisplay -nojvm -nosplash -singleCompThread

Más información en la Guía de usuario del clúster ctcomp2.

Nuevo sistema de copias de seguridad

Estas últimas semanas hemos preparado un nuevo sistema de copias de seguridad y queremos compartir con vosotros los motivos.

Tradicionalmente, las copias de seguridad del centro se hacían utilizando el software SimpleBackup. Este programa se ejecuta en cada servidor que desea hacer una copia, programado con cron y definiendo todos los parámetros necesarios en un archivo de configuración: periodicidad, tipo de copia, directorios a incluir, etc.

Este sistema tiene varios inconvenientes:

  • Si hay un fallo en el montaje del directorio NFS, la copia de seguridad se realiza igualmente pero queda almacenada en el disco local del servidor, lo que puede llenarlo y provocar fallos de funcionamiento.
  • En cada servidor se debe instalar SimpleBackup, que debe ser configurado individualmente, de forma descentralizada.
  • La restauración de archivos se hace manualmente mediante línea de comandos y el proceso es muy lento.
  • Solo funciona bajo GNU/Linux.

Por estos motivos, hemos instalado un nuevo sistema de copias de seguridad que utiliza Bacula en su versión de código abierto.

Bacula está formado por 5 componentes o servicios:

  1. Database server o Catalog: donde se almacena el catálogo de las copias de seguridad, en nuestro caso una base de datos postgresql. La existencia de este catálogo permite buscar y recuperar un archivo individual de forma rápida y sencilla.
  2. Storage server o Storage: controla el medio de almacenamiento empleado. Bacula fue diseñado originalmente para gestionar copias en cintas. En nuestro caso se realiza en discos duros.
  3. Command console o Console: una consola de gestión.
  4. Backup server o Director: el daemon principal, controla a todos los demás.
  5. File server o File: el cliente que se instala en cada ordenador en el que se vayan a hacer copias de seguridad. Es multiplataforma: funciona bajo GNU/Linux, Windows, MacOS X, varios BSD y Solaris.

Este sistema soluciona todos inconvenientes del antiguo:

  • La configuración y la gestión está centralizada, ya no depende de cada máquina el realizar sus propias copias de seguridad.
  • Es posible monitorizar los backups de forma rápida y sencilla.
  • El proceso de backup ya no falla de forma silenciosa porque falle el montaje de un directorio. El cliente de Bacula se ocupa de informar adecuadamente y reintentar la las veces que sea necesario.
  • El catálogo de Bacula permite la búsqueda y restauración de archivos de una copia de seguridad de una forma rápida y sencilla.
  • Bacula permite gestionar los volúmenes de copia, de modo que sólo borra copias antiguas cuando es necesario hacer más espacio para copias más recientes.

Este cambio nos permitirá tener un sistema de copia de seguridad mejor y más profesional y que escale correctamaente a medida que aumente el número de usuarios y servicios en el centro.

Hardware

Por si os preguntáis qué hardware se utiliza, hasta ahora las copias se almacenaban en una cabina de discos con 15 TB de espacio y discos en RAID 6, con un sistema de archivos ext3 que se exporta por NFS a través de un servidor dedicado. Tanto la cabina como el servidor están alcanzando el final de su vida útil y serán retirados pronto.

Ahora tenemos una nueva cabina de almacenamiento con 32TB, que es la que está utilizando ya Bacula. Esta cabina tiene configurados los discos también en RAID 6, con un sistema de archivos XFS, recomendado por Bacula por cuestiones de rendimiento. Todos los servicios de Bacula están instalados en otro servidor dedicado.

 

Transferencia de arquivos no servizo de mensaxería

¿Algunha vez tiveches problemas coa transferencia de arquivos utilizando o servizo de mensaxería do centro, ou esta funciona pero é moi lenta?

O servizo de mensaxería do centro permite a comunicación directa entre todos os investigadores do centro, ben sexa mediante mensaxes de texto, enviando arquivos ou por videoconferencia.

Este servizo está baseado en XMPP, un protocolo de mensaxería e presenza extensible, documentado e que vai evolucionando con novas extensións ó longo do tempo. Por iso, algúns clientes de mensaxería soportan algunhas características e outros non, e ás veces non é posible unha interoperabilidade completa ó utilizar distintos clientes.

A transferencia de arquivos en XMPP pode realizarse principalmente de dúas formas:

  • In-band (en liña): Os datos envíanse dentro de mensaxes a través do servidor, e van codificados en base64. Esta forma de transmisión é a primeira que foi definida (no XEP-0047) e tamén é a máis lenta.
  • Out-of-band (fora de liña): Os datos envíanse cunha conexión adicada entre os clientes, cun socket TCP. Esta forma de transmisión foi definida no XEP-0066 e é moito máis eficiente.

O principal problema é que a transmisión out-of-band non é posible se os clientes non se poden comunicar de forma directa (por estar tras un firewall, ou en distintas subredes), e a transmisión case sempre se acaba facendo in-band, provocando unhas transferencias de ficheiros moi lentas.

Unha alternativa para solucionar este problema é utilizar un proxy de transferencia de arquivos, un método definido no XEP-0065, e que permite usar un servidor como intermediario, o que segue sendo moito máis eficiente que usar transmisións in-band. Nalgúns casos, unha negociación usando este servidor intermedio incluso posibilita a transmisión de arquivos directa.

Dende fai uns días, o centro ten dispoñible o seu propio proxy de transferencia de arquivos para XMPP, de forma que podedes facer uso del estando nalgunha das redes do centro ou conectados a través da VPN.

pidgin_transferencia2

Para comezar a utilizar este proxy en Pidgin, basta con cubrir o campo Proxies de transferencia de ficheiros na pestaña Avanzado das preferencias da conta, poñendo proxy.citius.usc.es.

Agardamos que atopedes esta información útil, e recordamos que seguimos abertos a suxestións e comentarios de todo tipo.