Archivo por meses: junio 2013

Entrevista a Félix Queiruga

Hoxe estreamos na bitácora un novo formato de entrada co que pretendemos achegarvos o traballo de aquelas persoas que, non formando parte do noso núcleo habitual de traballo, colaboran con nos dunha maneira ou outra.

Félix Queiruga está rematando o Grao en Enxeñería Informática na Escola Técnica Superior de Enxeñaría e, despois de realizar unhas prácticas connosco o pasado verán, está a realizar o Traballo Fin de Grao (TFG) co CiTIUS.

En que consiste o teu TFG?

O obxectivo do proxecto é implantar un servizo de monitorización dos sistemas informáticos do CiTIUS. Mediante a realización deste PFG preténdese cubrir unha necesidade da área de administración de sistemas que considero esencial para o mantemento da infraestrutura informática do centro.

En que resultan de axuda estes sistemas de monitorización?

Félix posando xunto a unha pantalla con gráficos e táboas xeradas polo sistema de monitorización, que permiten ver o estado dos sistemas en cada momento

Félix posando xunto a unha pantalla con gráficos e táboas xeradas polo sistema de monitorización, que permiten ver o estado dos sistemas en cada momento

Permiten coñecer en cada momento o estado dos distintos elementos da rede, tanto equipos de traballo, coma servidores ou impresoras. Datos coma o espazo libre no disco duro, o uso de memoria, ou a dispoñibilidade de servizos.

Estes sistemas de monitorización cumpren dúas funcións. A primeira é alertar dos posibles problemas, mellorando así o tempo de resposta dos administradores e minimizando o impacto destas incidencias. A segunda é facilitar un mantemento proactivo, co obxectivo de evitar a presenza de fallos a posteriori. Con esto se busca maximizar a dispoñibilidade dos servizos ofrecidos aos usuarios.

Por que te decantaches en facer un TFG de sistemas e non un proxecto software?

A administración de sistemas sempre foi a área de coñecemento da informática de maior interés para min. Mentres que un proxecto de software está xeralmente orientado á obtención dun produto, un de sistemas está baseado en proporcionar e garantir un servizo. A natureza deste tipo de traballo resúltame máis atractiva.

Por outro lado, os TFG de sistemas son pouco habituais entre os que se realizan na ETSE. Escoller un proxecto destas características dame a posibilidade de innovar nun terreo pouco explorado ata o momento.

Que foi o máis complicado á hora de abordar un TFG destas características?

A causa do maior problema co que me atopei foi, precisamente, a ausencia de TFG de sistemas: Os modelos e procesos de documentación ensinados durante a realización do Grado en Enxeñaría Informática, e en particular o modelos de memoria do TFG, están orientados á creación de software.

Así que, coa axuda dos meus directores de proxecto, creei unha nova estrutura de memoria aplicable ao meu TFG que consideramos é moito mellor aplicable co modelo habitual.

Se cadra nun futuro a ETSE podería proporcionar un modelo de memoria que fora aplicable tamén a TFG de sistemas, e así os alumnos animaríanse a realizar máis proxectos deste tipo.

Moitas gracias polo teu tempo, Félix. Agardamos que este traballo te permita acadar un éxito notable en canto ao resultado do TFG. En canto á súa utilidade para o centro, podemos dar fe de que xa o acadou.

Experiencias con SPDY y PageSpeed

Desde hace unas semanas, las páginas web del centro se sirven con una nueva versión del servidor Nginx con soporte para el nuevo protocolo SPDY y con el módulo PageSpeed activado.

Convencido por las pocas pero vistosas pruebas visuales y el whitepaper que publicó al respecto el artífice de dicho protolo, Google, esperaba poder obtener unas mejoras apreciables en los tiempos de carga de las páginas gracias al protocolo SPDY, pero no fue así.

Podéis leer pruebas de rendimiento más realistas en este paper de Microsoft en el que desmitifican el whitepaper de Google, intentando mejorar los tiempos de carga de HTTP sin recurrir a SPDY. Por ejemplo, con el módulo PageSpeed para Apache, también desarrollado por Google, o activando el HTTP pipelining en el navegador, que viene desactivado por defecto.

En esta tesis de la Aalto University se compara HTTP con SPDY en conexiones móviles (de muy alta latencia), sin hacer hincapié en otros métodos de mejorar los tiempos de carga, y en algunos escenarios alcanza una mejora de tiempo de carga de hasta el 20%, aunque no es lo habitual, y normalmente no alcanza el 10%.

La experiencia de estas semanas nos ha demostrado que, en general, en conexiones con menor latencia la mejora no es apreciable. Además, la implementación de SPDY de Nginx 1.4.1 funciona bien hasta que en algún momento deja de hacerlo y empieza a servir imágenes y otros recursos a medias. Por lo tanto, hemos deshabilitado el soporte de SPDY por ahora a la espera de una solución.

PageSpeed, por su parte, es un módulo bastante complejo, no es «activar y punto» sino que contiene una serie de filtros que se pueden activar o desactivar y configurar. Ofrece muchas posibilidades, entre las más interesantes:

  • Caché de recursos en memoria, a través de memcached.
  • Caché en archivos.
  • Optimizar el HTML, el CSS y el JavaScript comprimiéndolos y juntándolos en el menor número de archivos posible. Estos filtros deben utilizarse con cuidado, porque pueden romper algunas páginas.
  • Hacer Domain Sharding y otras optimizaciones pensadas para que HTTP o SPDY funcionen mejor.

En nuestro caso, estamos siendo bastante conservadores con los filtros de PageSpeed para intentar no romper nada y ya obtenemos una mejora considerable en el rendimiento, teniendo en cuenta además que nuestras páginas web se sirven desde otros servidores a través de Nginx actuando como un reverse proxy.

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.

Adquisición de dez novos servidores en formato blade

Fai unhas semanas comentamos que estabamos á espera de duas cousas para poñernos coa instalación do servizo do cloud IaaS: á chegada duns servidores, e á publicación de Apache Cloudstack 4.1. E traemos boas novas.

Esta semana recibimos por fin os novos servidores. Estes servidores en formato blade contan cun doble procesador Intel Xeon E5-2650L de 8 núcleos e 64 GB de memoria RAM, que fan un total de 160 núcleos repartidos nun total de 10 servidores.

Cinco dos novos servidores en formato blade

Cinco dos novos servidores en formato blade

Destes dez servidores, cinco adicaranse axiña ó cluster de computación. Diego ampliará detalles nas vindeiras semanas sobre como van a mellorar gracias a esta adquisición os servizos de cómputo do centro.

Os outros cinco servidores adicaranse ó cloud IaaS montado con Apache Cloudstack 4.1, que se deu a casualidade de que tamén foi publicado esta mesma semana, aínda que finalmente a característica pola que estabamos a agardar moveuse á versión 4.2. Para non seguir agardando, e agora que xa temos os servidores, tentaremos montalo sobre 4.1 aínda que o risco sexa maior. Se todo segue o curso previsto, o servizo de cloud IaaS debería poder comezar a utilizarse antes do mes de Agosto. Fernando ampliará esta información coas datas concretas cando considere prudente facelo.