Archivo por meses: mayo 2013

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.

 

Nueva política de colas en ctcomp2

Para realizar un aprovechamiento eficiente de los recursos del clúster de computación ctcomp2, se ha modificado la política de gestión de colas. El objetivo es que los trabajos enviados sean compatibles, simultáneamente, con el planificador y con el sistema de gestión de energía.

Las colas se usuario siguen siendo las mismas: batch, short, interactive y bigmem, pero han cambiado los parámetros que determinan el comportamiento de estas colas. Los cambios más substanciales son:

  • Solo se permiten trabajos con 1, 2, 4, 8, 16, 32 y 64 núcleos (nodes x ppn). Los trabajos que requieran un número diferente de núcleos deberán seleccionar el número superior más proximo de entre los valores permitidos. Para trabajos que necesiten más de 64 núcleos es necesario contactar con la unidad de gestión de infraestructuras.
  • El valor de memoria asignado a cada trabajo se determina automáticamente a partir del número de núcleos que se soliciten: la memoria, en gigabytes, es dos veces el número de núcleos solicitados. Por lo tanto, si la memoria es crítica en la ejecución de un trabajo es necesario solicitar el número adecuado de núcleos. Por ejemplo, si se desea ejecutar un trabajo con 4 procesos pero son necesarios 12 GB de memoria, es necesario solicitar 8 núcleos para garantizar el límite máximo de memoria:
    #PBS -l nodes=1:ppn=8
  • El tiempo de ejecución máximo de un trabajo también es dependiente del número de cores solicitado. Estos límites se pueden consultar en la Guía de usuario de ctcomp2. El usuario puede modificar (reducir) este tiempo a través de la variable walltime de la opción -l de qsub. Por ejemplo, para solicitar dos núcleos durante como máximo una hora:
    #PBS -l nodes=1:ppn=2,walltime=1:00:00

    Esta variable es opcional ya que el valor de tiempo indicado solo se utiliza para que el planificador pueda cubrir eficientemente los recursos que no estén ocupados pero respetando las prioridades de espera en cola. El beneficio que se obtiene ajustando este tiempo es que aumentan las posibilidades de que un trabajo adelante su ejecución. En cualquier caso, obviamente, si la estimación realizada es escasa el trabajo se cancela, por lo que se RECOMIENDA dejar un margen de tiempo suficiente para que el trabajo termine correctamente.

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

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.

Servizo de cloud IaaS para investigadores

Neste momento estamos completando a adquisición de dez novos servidores en formato blade. A metade estarán destinados a ampliar o cluster de computación, algo do que xa daremos conta máis adiante, pero o resto adicaranse a implementar un novo servizo de cloud IaaS para os usuarios do centro.

Estes novos servidores contan cada un con:

  • Un dobre procesador Intel Xeon E5-2650L de 8 núcleos
  • 64 GB de memoria RAM
  • 4 interfaces de rede a 10Gb

O servizo cloud atópase xa en fase de probas dende fai un par de meses, e está sendo avaliado por un grupo de cinco investigadores. Unha vez pase a produción nos novos servidores, este novo servizo permitirá ós usuarios do CiTIUS a creación das súas propias máquinas virtuais en Linux e Windows, sobre as que terán todo o control para instalar servizos como servidores web, de aplicacións, contornos de desenvolvemento e probas, etc.

A posta en marcha do servizo dependerá en grande medida de dous factores: a chegada dos novos servidores, e a data da publicación da versión final de Apache Cloudstack 4.1, xa que esta versión contén algunhas características esenciais para poder integralo coa autenticación do centro.

Melloras na wiki do centro

Nos últimos meses vimos de realizar unha serie de melloras na wiki do centro, xunto coas labores de mantemento habituais que realizamos cada seis meses. Queremos presentarvos ditas melloras:

wikimelloras1

A mellora máis evidente é un cambio de tema visual, de acordo co novo logotipo do centro. Este cambio no tema ven tamén con algunhas melloras funcionais:

wikimelloras2

Unha das cousas que máis confusión lle provocaba a xente era o trazado de navegación que aparecía ó pé da páxina, similar a unhas migas de pan (breadcrumbs) pero sendo unha cousa rara. Agora na parte superior do artigo aparecen unhas migas de pan de verdade.

wikimelloras3

O formulario de edición de páxina ten un novo botón de pantalla completa, que leva o cadro de edición a ocupar toda a pantalla. Esta funcionalidade utiliza a API de Fullscreen xa soportada por gran parte dos navegadores. Aínda non forma parte de ningún estándar, pero está previsto que se inclúa en HTML5 ou se cadra na seguinte versión.

wikimelloras4

Agora o wiki adáptase a dispositivos con un ancho pequeno, como poden ser os smartphones, algúns tablets e dispositivos con pantallas pequenas en xeral. Nesta vista pérdese algunha funcionalidade, como o botón de discusión e o menú lateral.

wikimelloras5

A outra mellora destacable é o apartado e discusión, que por fin está dispoñible para todos os investigadores. Calquera usuario rexistrado pode participar nas discusións. Se algún usuario desexa discusións completamente privadas, debe solicitar modificar estes permisos de acceso para o seu espazo.

Agardamos que as melloras sexan ben recibidas, e por suposto seguimos atentos ós vosos comentarios e suxestións para facer máis cómodo e útil este e outros servizos.