Archivo de la categoría: Anuncios e novas

Actualización de Gitlab a la versión 7.2

Acabamos de actualizar la instalación de Gitlab del centro a la última versión disponible. En esta ocasión, hemos pasado de la versión 6.8 a la 7.2. Las principales novedades son estas:

Gitlab

  • Se pueden asignar colores a las etiquetas del gestor de issues (7.2).
  • Se pueden agrupar los repositorios con el mismo milestone, de forma que es más sencillo trabajar con las milestones en proyectos que utilizan varios repositorios (7.1).
  • Nueva página de login (7.1).
  • Al gestionar milestones, se puede cambiar el estado de los issues arrastrando y soltando en su columna correspondiente (7.0).
  • Hay algunos cambios sutiles de permisos en los roles developer y master (7.0).

Gitlab publica una nueva versión cada mes y en el CiTIUS actualizamos Gitlab con frecuencia, especialmente si hay algún problema de seguridad que se solucione con una actualización.

El sistema de integración continua Gitlab CI no se actualiza con tanta frecuencia. La última versión data de mayo de 2014 y desde que lanzamos el servicio no ha salido ninguna versión nueva.

Actualización del cloud IaaS a Cloudstack 4.3

La semana pasada actualizamos el cloud a Cloudstack 4.3, que soluciona muchos problemas que teníamos con la versión 4.1 que lanzamos como servicio el año pasado.

cloudmonkey-fp

  • Ahora es posible cambiar la cuenta de las máquinas virtuales desde la interfaz, así que se pueden asignar a un proyecto o a otro usuario después de crearse.
  • Además de añadir más discos secundarios para datos, se puede ampliar el tamaño de los discos de datos existentes (pero no del principal).
  • Las plantillas se asocian correctamente a las cuentas de los proyectos, así que ya no es necesario que sean públicas para poder utilizarlas, o borrarlas.
  • Ahora es posible añadir varias IPs a una misma interfaz de red y asignar varias redes a una misma máquina virtual.

Se pueden consultar las notas de la versión 4.2.0 y la versión 4.3.0, aunque están dirigidas a administradores.

Además, hemos ampliado el almacenamiento secundario, que es el espacio en el que se guardan las plantillas y las ISOs, con 2TB más, para evitar los problemas de escasez que había hasta ahora.

Heartbleed en el CiTIUS y recomendaciones de seguridad

heartbleedA estas alturas todo el mundo estará al tanto de uno de los agujeros de seguridad más graves, por lo menos en cuanto a su impacto, que ha afectado a Internet en los últimos años: Heartbleed.

El problema es que ha estado presente durante más de un año y hasta que ha sido desvelado, cualquiera que tuviera de su conocimiento ha podido usarlo para obtener datos muy sensibles, como los certificados de servidores, cookies de sesión o contraseñas de usuarios, y es prácticamente imposible saber si ha sido así o no.

Lamentablemente, los servidores web y VPN del CiTIUS estaban afectados por dicho fallo de seguridad.

Fuimos rápidos parcheando el problema en ambos servicios, la misma mañana del 8 de abril, pocas horas después de que se hiciera público. Es poco probable que atacantes malintencionados, más allá de aquellos privilegiados que tuvieran el conocimiento antes del bombazo mediático, recuperasen datos sensibles. Y es difícil de creer que pudiésemos ser objetivo de los ataques de alguien así.

En nuestro caso, el disponer de un servidor Nginx que distribuye las peticiones hacia otros servidores internos a modo de pasarela ha jugado a nuestro favor: Ha permitido parchear el problema con mayor rapidez. En el improbable caso de que alguien consiguiese explotar el problema a tiempo, tan solo podría obtener datos en la memoria de ese servidor pasarela (aunque es cierto que al pasar todas las peticiones por allí, son muchos, pero son menos).

Recomendaciones para usuarios del Cloud IAAS

Algunas de las plantillas disponibles en el cloud IAAS están afectadas por este fallo de seguridad, por lo que los usuarios que hayan desplegado servicios que estén utilizando OpenSSL deben asegurarse de que el paquete OpenSSL está actualizado. Las versiones vulnerables son todas las de la rama 1.0.1 hasta la 1.0.1f. La versión 1.0.1g es la que incluye el parche de seguridad. En las próximas horas actualizaremos las plantillas para que las nuevas máquinas virtuales desplegadas no tengan este problema.

Recomendaciones de seguridad generales

Todos los usuarios deberían cambiar ahora todas sus contraseñas más sensibles, especialmente si las comparten entre varios servicios. Mashable ha publicado un listado de servicios afectados. Se debe comprobar antes si el servicio aún está afectado por el problema, aunque a estas alturas es poco probable.

En el caso de las cuentas del CiTIUS, recomendamos cambiarlas a través de este formulario a aquellos que se hayan identificado en la página web del centro desde el lunes por la tarde hasta que se parchearon los servidores, el martes a primera hora.

Hasta donde sabemos, los servidores de la USC no estaban funcionando con la versión de OpenSSL afectada, por lo que las cuentas de la USC no corren ningún peligro.

Es importante que todo el mundo comprenda que, aunque no sean tan mediáticos o tan graves, problemas de seguridad que pueden llevar a un robo de información sensible no son nada infrecuentes. Por ello, os damos una recomendaciones generales de seguridad que ayudarán a mantener a salvo vuestras credenciales y otros datos importantes:

  • Utilizar contraseñas diferentes en cada servicio, especialmente en aquellos que manejen o contengan información sensible, como el correo electrónico, servicios de banca, etc.
  • Utilizar contraseñas fuertes, que sean suficientemente largas, compuestas por símbolos y combinaciones de letras mayúsculas y minúsculas y que no tengan un significado que pueda llevar a su adivinación (acrónimos, fechas, diminutivos, palabras reales, etc.).
  • Tener la costumbre de cambiar las contraseñas cada cierto tiempo, una buena práctica es hacerlo de forma anual.
  • Mantener los sistemas y todo el software actualizados, especialmente en aquellos dispositivos que se utilizan para realizar compras, conectarse a banca electrónica, etc.
  • Evitar, si es posible, utilizar puntos de conexión a Internet públicos, especialmente si son abiertos, como los disponibles en aeropuertos, estaciones de autobuses o algunas cafeterías.

Más información:

Adquisición de una tarjeta Xeon PHI

El CiTIUS ha adquirido recientemente una tarjeta modelo Xeon PHI 7120P (características) para computación paralela. Se trata de un coprocesador en formato PCI Express, algo similar a lo que ofrece NVidia Tesla pero desarrollado por Intel bajo su arquitectura Intel MIC (Many integrated Core) Básicamente son 61 núcleos Xeon integrados en una tarjeta PCI Express que funciona como un ordenador complementario con su propio sistema operativo empotrado (BusyBox) y que son capaces de llegar al teraflop. Para hacerse una idea de lo que representa esto hay que tener en cuenta que el primer ordenador de Intel capaz de llegar al Teraflop se construyó en 1997, tenía 9298 procesadores y ocupaba 72 armarios en un cpd.

xeon-phi-7120p

xeon-phi-7120p

A día de hoy Intel cuenta con tres gamas de tarjetas Xeon PHI: la 3100, la 5100 y la 7100, a la que pertenece la que hemos adquirido.

3100 5100 7100
Operaciones en coma flotante 1 teraflops 1.01 teraflops 1.2 teraflops
Ancho de banda de la memoria 240 GB/sec 320 GB/sec 352 GB/sec
TDP 300 W 225 W 300 W

La gama Xeon PHi es el intento de Intel de competir en el mercado de la computación paralela con Nvidia y su CUDA. La ventaja de la Xeon Phi frente a las tarjetas de nVidia es que se basa en una arquitectura multiprocesador compatible con x86, por lo que debería ser posible reutilizar las herramientas de paralelización preexistentes.
Una búsqueda simple en Google (aquí, aquí o aquí) parece insinuar que esto aún no se ha conseguido del todo, pero también es cierto que CUDA lleva más tiempo en el mercado y por lo tanto es posible que las Xeon Phi aún no estén lo bastante maduras. En todo caso ahora en el CIITIUS será posible hacer nuestras propias pruebas ya que disponemos de ambas alternativas.

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…).

Nuevo servicio de Cloud IaaS para los investigadores

Ya está operativo el nuevo servicio de Cloud IaaS del CITIUS. En mayo en esta misma bitácora adelantábamos que se habían adquirido nuevos servidores para prestar este servicio y después de un tiempo de instalación, documentación y pruebas ya está en producción para el uso y disfrute de todos los investigadores del CITIUS.

¿Qué permitirá este nuevo servicio? Las posibilidades más relevantes son:

  • Crear máquinas virtuales con diferentes configuraciones de hardware y software a partir de plantillas predefinidas o partiendo de cero.
  • Crear redes virtuales entre las máquinas o mantenerlas aisladas.
  • Crear grupos de trabajo con otros investigadores de modo que los recursos virtuales sean comunes.

Las ventajas de crear máquinas y redes en un entornos virtualizados son múltiples, destacando la rapidez con la que se hace el despliegue comparado con máquinas físicas; además tanto las máquinas como las redes están controladas por cada investigador, sin intervención de los administradores.

Esperamos que este nuevo servicio facilite la creación de entornos de desarrollo y pruebas que faciliten a los investigadores su labor investigadora.

Todo eso es genial, pero… ¿cómo puedo empezar a usarlo?

Para poder utilizar el cloud hay que solicitar la activación del servicio mediante el formulario de incidencias de la web del centro.

Una vez activado el servicio, este se gestiona a través de una interfaz web. El nombre de usuario y la contraseña serán las mismas que las de cualquier otro servicio del CiTIUS.

Todo el proceso y utilización posterior del Cloud están explicados como siempre en la wiki del centro. Recomendamos encarecidamente su lectura, porque aunque no es un servicio difícil de usar, sí es bastante complejo en cuanto al número de opciones y posibilidades que ofrece.

Una breve descripción del entorno.

En este momento el Cloud pone a disposición de los investigadores un total de 170 GHz de procesador y 190 GB de memoria RAM para la creación de máquinas virtuales. Esta capacidad es ampliable en un futuro, si fuera necesario. Además contamos con un almacenamiento de 7 TB para los discos de dichas máquinas.

Esto significa que ahora mismo el Cloud tiene capacidad para crear, por ejemplo, 170 máquinas virtuales con un procesador de 1GHz, 1GB de RAM y 40 GB de disco duro.

Todo el entorno está instalado sobre Centos 6.4 y usa KVM como única solución de virtualización. Por encima de esto está instalado Cloudstack 4.1.1, que sirve para orquestar todos los recursos y ofrecer la gestión a los usuarios.

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.

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.

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.