Comparativa y estudio de distribución de software de cálculo científico en entornos cloud con CVMFS

Transcripción

1 Comparativa y estudio de distribución de software de cálculo científico en entornos cloud con CVMFS Víctor Fernández-Albor 1, Ricardo Graciani 2, Javier López Cacheiro 3, Fernando Gomez-Folgar 4, Antonio García-Loureiro 5, Juan José Saborido 6 Resumen 1 En entornos de procesado de datos que usan sistemas distribuidos cada grupo de investigación suele necesitar un software específico para acceder y transformar los datos existentes. Ello necesita a menudo ser descargado e instalado en el propio sistema para poder hacer frente a la correcta ejecución del trabajo. Tiene, por tanto, mucho interés el despliegue de una infraestructura que automatice la descarga de software, que asegure su presencia en todos los nodos de ejecución con la posibilidad de ser gestionado externamente por un administrador de versiones, que sea auto-actualizable y que se pueda aplicar también a entornos virtualizados. Todo ello permitiría acelerar la ejecución de trabajos, especialmente cuando éstos son cortos, y además reducir el consumo de ancho de banda de la subred correspondiente. CVM File System (de aquí en adelante CVMFS) es un sistema de archivos compatible con tales escenarios. Es un software diseñado para recuperar fácilmente archivos desde un servidor HTTP, y que ha sido diseñado por el CERN para dar acceso al software de los experimentos de LHC en máquinas virtuales. Posee la peculiaridad de que se puede montar como un sistema de archivos normal a través de archivos en espacio de usuario (FUSE). Debido a que los archivos se comparten a través de un servidor web, puede hacer uso de servidores proxy Squid para reducir la latencia dentro de una misma subred y redistribuir la carga del servidor central. CVMFS posee una cache propia que, añadida a la cache del servidor proxy HTTP, completa un sistema flexible de descarga de ficheros. A continuación se presenta la arquitectura, implementación y pruebas de esta solución basada en CVMFS. Palabras clave Distribución de software, CVMFS, Cálculo en la nube, Cloud Computing, Grid, Cálculo científico. I. INTRODUCCIÓN En la actualidad existe un gran número de grupos de investigadores que para poder ejecutar sus trabajos de cálculo, por medio de sistemas distribuidos, necesitan emplear software específico que normalmente no se encuentra instalado en los nodos de computación. 1 Grupo de Física de Partículas, Universidad de Santiago de Compostela (USC), victormanuel.fernandez@usc.es 2 Dpto. de Estructura y Constituyentes de la Materia (UB), graciani@ecm.ub.es 3 Dpto. de Sistemas, Centro de Supercomputación de Galicia (CESGA), jlopez@cesga.es 4 Dpto. de Sistemas, Centro de Supercomputación de Galicia (CESGA), fgfolgar@cesga.es 5 Dpto. Electrónica y Computación, Universidad de Santiago de Compostela, antonio.garcia.loureiro@usc.es 2 Grupo de Física de Partículas, Universidad de Santiago de Compostela (USC), Juan.Saborido@usc.es Habitualmente, es el propio usuario el encargado de efectuar la instalación y gestión de este software adicional, ya que es necesario para efectuar sus simulaciones, y ello repercute en el tiempo necesario para ejecutar sus tareas de cálculo que vendrá dado por el máximo de los tiempos tanto de instalación del software en los nodos, como de ejecución en los mismos: max i N D max j S i T ij + t i N D = {1,2,M} S i = {1,2,N i } N i = Número máximo de trabajos en el nodo i T ij = Tiempo de ejecución del trabajo j en el nodo i t i = Tiempo de instalación del software para ejecución de trabajos en el nodo i M = Número total de nodos i = Nodo en el que ha corrido un determinado trabajo j = Número de trabajos en un nodo Con lo cual con el incremento del tiempo de instalación del software, va a incrementarse el tiempo total de finalización de trabajos de usuarios. A partir de la colaboración con el proyecto Formiga, en el que varios grupos de usuarios van a ejecutar sus trabajos en un entorno virtualizado haciendo uso de recursos ociosos de aulas de informática, nace la necesidad de crear una infraestructura que permita que esos trabajos obtengan de forma dinámica y escalable el software que necesitan. La solución se encuentra en la herramienta CVMFS, que emplea catálogos de ficheros para establecer un sistema de archivos de solo lectura a través del protocolo HTTP. Los archivos se transfieren en primer lugar a la caché local del nodo. En CVMFS un volumen específico se identifica por su URL HTTP. El montaje de un volumen incluye la descarga del catalogo de archivos, que contiene la información global sobre que archivos son servidos a través de HTTP. Las versiones de software las mantiene inmutables, dándose lugar a nuevas versiones a partir de las actualizaciones y parches. Por otra parte, los archivos de catálogo de grandes volúmenes son divididos en múltiples subcatálogos creando así versiones más básicas. Actualmente, CVMFS provee el software a distintos grupos de usuarios del CERN, y está integrado en los

2 centros de procesos de datos del TIER-0 y TIER-1. La forma en la que CVMFS trabaja, permite que se pueda desplegar en cualquier tipo de entorno. Por lo tanto, a priori parece la herramienta idónea para que distintos grupos de usuarios, minimicen sus tiempos de ejecución permitiéndoles emplear el software que necesitan, sin la necesidad de descargarlo directamente. En este artículo se pretende analizar y comparar los resultados obtenidos empleando CVMFS frente a la descarga directa y la instalación del software por parte del usuario. El presente artículo está organizado de la siguiente forma: la segunda sección describe el CVMFS; en la tercera, se detalla la infraestructura y el despliegue de CVMFS; en la cuarta sección se describen las pruebas realizadas; en la quinta, los resultados; finalmente, las conclusiones se incluyen en la sexta sección. II. DESCRIPCIÓN DEL CERNVM FILE SYSTEM El sistema CVMFS ha sido optimizado para la distribución del software de los distintos grupos de trabajos del CERN, y ha sido implementado como un sistema de archivos en espacio de usuario (FUSE). CVMFS ha sido diseñado para crear un árbol de directorios en un servidor web de solo lectura, de tal forma que en el lado del cliente solo se requerirá conectividad HTTP/HTTPS al servidor web. CVMFS realiza un cacheado en distintos niveles, de tal forma que archivos y metadatos se almacenan en la caché del disco local así como en los servidores de respaldo HTTP intermedios, permitiendo que sea escalable hasta un gran número de clientes. El procedimiento de construir, instalar y validar las versiones de software es responsabilidad de un gestor de versiones. Una vez realizadas estas tareas, se recrea el árbol de directorios dentro del repositorio de CVMFS. Este repositorio posee un formato particular cuyo contenido es un almacenamiento direccionable denominado Shadow tree. La creación del repositorio incluye la creación de los catálogos de archivo, compresión de archivos, y cálculo de los hashes. Por otra parte, los archivos se almacenan de forma local, dentro de una caché en el servidor, como fragmentos de datos SHA1. Se hace esto con el fin de explotar la redundancia y utilizar el SHA1 como llave a la hora de descargar archivos. Esto permite evitar ciertas restricciones firewall, como por ejemplo, las prohibiciones de descarga de archivos root.exe. Una vez realizadas estas tareas, el nuevo software es publicado a través del servidor CVMFS. La publicación típica CVMFS sigue los siguientes pasos: Crear los cambios necesarios en el shadow tree, añadir nuevos directorios, path de binarios, etc. Probar la instalación de software. Ejecutar la opción de sincronización con los nuevos paquetes añadidos. Publicar a través del servidor web en el directorio público. Fig. 1. Proceso para la publicación de una nueva versión dentro del repositorio de software. Una vez finalizado el proceso de sincronización de CVMFS, está disponible a través de HTTP. III. INFRAESTRUCTURA Y DESPLIEGUE DEL REPOSITORIO DE CVMFS Para poseer una infraestructura de pruebas lo más realista posible, en la que poder comprobar tanto las escalabilidad de la solución, como el montaje rápido y dinámico de las versiones de software científico, y pensando en poder emplear la solución a un entorno de aulas virtualizado, hemos desplegado la infraestructura sobre un entorno heterogeneo de pruebas, donde, por un lado, se tiene un aula virtualizada en el Centro de Supercomputación de Galicia, por otro los nodos de un cluster local al repositorio en la Universidad de Santiago, y por último, nodos externos en la Universidad de Barcelona. A. Universidad de Santiago de Compostela Para poder poner en contexto las pruebas, vamos a explicar un poco la infraestructura con la que se cuenta. Por un lado, tenemos el repositorio CVMFS que es servido a través de Tomcat en una máquina perteneciente al clúster del TIER-2 de LHCb de la Universidad de Santiago de Compostela, dentro del mismo se desplegará un proxy HTTP Squid, con el objetivo de minimizar los tiempos de respuesta, en caso de saturación del servidor principal. Hay que tener en cuenta que toda la infraestructura va a tener un sistema cacheado que va a intentar minimizar los tiempos de descarga y montaje de los sistemas de ficheros. Este sistema de cachés estará integrado desde el propio repositorio o servidor HTTP, que tendrá su caché interna, pasando por el proxy, hasta el propio nodo con la caché local en donde también existirá un tiempo residual perteneciente, a la interacción con FUSE. La interconectividad de todos los nodos se realizará con Swichs de 100Mb/s.

3 B. Centro de Supercomputación de Galicia Por otra parte, en el Centro de Supercomputación de Galicia, se tendrá un aula con un máster del gestor de CloudStack, que permitirá levantar un sistema virtualizado en los nodos a través de una red de 1Gb/s, desde la cual, se habilita una de las máquinas con un servidor proxy para mejorar el escalado dentro de la misma subred. C. Universidad de Barcelona Contaremos con nodos de cálculo normales, que nos van a permitir comprobar escalado en largas distancias, donde la latencia de redes de área extensa, es un factor importante a tener en cuenta. El tipo de nodos con los que se va a trabajar son, listados en función del organismo al que pertenecen serán: 1) Universidad de Santiago: servidores DELL PowerEdge SC1425, con dos procesadores PIV Xeon a 2.8 Ghz y 1 GB de RAM por procesador (Fig.2.). 2) Centro de supercomputación: en el aula virtualizada, las máquinas anfitriones serán del tipo Intel(R) Core(TM)2 Duo 2.66GHz, siendo las máquinas virtuales de 2 Cores, con 1GB de RAM y 5GB de disco. 3) Universidad de Barcelona: Dual Core AMD Opteron(tm) Processor 1,7 GHz, 2 GB de RAM y 4 Cores. Fig. 2. Proceso para la publicación de una nueva versión dentro del repositorio de software. Una vez finalizado el proceso de sincronización de CVMFS, está disponible a través de HTTP. El modelo anterior (Fig.2.) tiene todos los elementos necesarios para asegurar una escalabilidad, soportando miles de clientes CVMFS con la fiabilidad exigida por un sistema de archivos, y el rendimiento sobre el tipo de red más común en redes de área local, como las de las aulas de informática. IV. DESCRIPCIÓN PRUEBAS REALIZADAS Las siguientes pruebas tienen la intención de medir la sobrecarga de CVMFS bajo las cargas de trabajo típicas en cálculo científico. Para la realización de estas pruebas se ha utilizado un programa de análisis de datos utilizado en grupos de Física de Altas energías denominado ROOT (TablaI). ROOT, que está formado por librerías de software y un programa orientado a objetos desarrollado por el CERN, y fue desarrollado para el análisis de física de partículas, conteniendo varias características específicas de este campo. Debido al amplio número de ficheros que utiliza ROOT, es la herramienta perfecta para utilizarla en las pruebas de software. El programa que se va a utilizar en ROOT rf202_extendedmkfit.c es un software de pruebas que va a permitir generar datos a partir de un modelo numérico, mediante una función con una serie de parámetros, la cual variará para ajustarlos a otro modelo completamente distinto. Esto nos permite modificar el número de eventos con el fin de ajustar mejor el modelo. La tabla I muestra algunas de las propiedades de CVMFS o ROOT, donde podemos ver, la cantidad de archivos con los que se va a trabajar o el tamaño de caché con el que vamos a contar. TABLA I CARACTERÍSTICAS DE LOS PROGRAMAS ROOT Y CVMFS EN CUANTO Versión A TAMAÑO Y CANTIDAD DE ARCHIVOS Tamaño total en MB ROOT v (56 tar.gz) Número de archivos Tamaño medio de los archivos en KB Caché CVMFS v En las pruebas que se realizarán, se hará la comparativa de CVMFS contra la descarga directa del software desde el mismo servidor HTTP. El servidor de archivos que se ejecuta es Apache 2.2.3, mientras que el servidor proxy HTTP es Squid en su versión 2.6, teniendo el repositorio CVMFS almacenado en una zona de solo lectura de los nodos, y utilizando la versión de Scientific Linux 5.5. Las máquinas virtuales utilizan hipervisores KVM, y se cuenta con la pérdida constante en la región del 5%. Para compararlo a partir de un estado conocido y de manera reproducible, todas las cachés serán borradas en cada una de las baterías de pruebas, obteniendo los resultados con la denominada caché fría, y eligiendo el peor de los resultados en cada caso. Con esto lo que queremos comprobar es la pérdida de rendimiento que existiría en un posible caso real, en donde un usuario, nunca haya lanzado sus trabajos en uno o varios nodos, esta parece la simulación más realista ya que se puede comparar a su vez con las pruebas de descarga directa,

4 en donde el usuario tampoco va a poseer el software cacheado cuando efectúa la descarga. Y para que las pruebas aún sean lo más realista posible, las primeras baterías de pruebas se realizarán lanzando primero un trabajo por nodo, mientras que las siguientes simulaciones se lanzará un trabajo por Core, para poder ver el incremento de carga en caso de ejecutar distintos trabajos diferentes sobre los nodos de cálculo. En todos los casos, las ejecuciones empezarán de forma simultánea en todos los nodos, por cada batería de pruebas que se realice. El algoritmo de ejecución para las pruebas se muestra en las tablas II y III. V. RESULTADOS Una vez realizadas las pruebas anteriormente descritas, procederemos a dividirlas en 2 tipos distintos, dependiendo de si se ejecuta ROOT como un proceso independiente en cada uno de los nodos de cálculo, o si se ejecuta como un proceso por el número de Cores que tenga el nodo sobre el que se desea ejecutar. Habrá que tener en consideración el impacto del ancho de banda en redes de área amplia, donde la latencia será más elevada que en redes de área local. TABLA II LÓGICA DEL PROGRAMA UTILIZADO PARA REALIZAR LAS PRUEBAS DE ENVÍO DE SOFTWARE A TRAVÉS DE CVMFS Test 1: Uso CVMFS Input: node list Output: time results if multicore execution then; ejecutar una iteración en cada core de un nodo time A mount CVMFS else ejecutar una iteración en cada nodo time A mount CVMFS if node execution finish then get_results() umount CVMFS borrar caché Squid en cada Subnet borrar caché cvmfs en cada nodo return worst_result; TABLA III LÓGICA DEL PROGRAMA UTILIZADO PARA REALIZAR LAS PRUEBAS DE ENVÍO DE SOFTWARE DESCARGADO DE UN SERVIDOR HTTP Test 2: Descarga directa Input: node list Output: time results if multicore execution then; ejecutar una iteración en cada core de un nodo time A download root else ejecutar una iteración en cada nodo time A download root if node execution finish then borrar caché Squid en cada Subnet return worst_result; Cada una de las pruebas se realizará varias veces para contrastar todos los resultados, y verificar que no hubiese ocurrido ningún tipo de error de saturación o picos de la red, que les pudiese haber afectado. Fig. 3. Comparativa del tiempo de ejecución de un trabajo por nodo en una red de área local, entre la descarga directa del software y el montaje de CVMFS. El tiempo real de CVMFS (Fig. 3.) es un poco más bajo en comparación con el tiempo de descarga e instalación directa de un usuario, hay que tener en cuenta que en este tipo de pruebas casi no se sufre sobrecarga HTTP, ya que éstas se realizan íntegramente en una red de baja latencia, dentro todo de la misma subred, siendo este un caso ideal de distribución de software. En un caso más realista, tanto la descarga directa, como el repositorio de software, necesitarán de servidores HTTP de respaldo para mejorar la escalabilidad. Fig. 4. Comparativa del tiempo de ejecución de un trabajo por core en una red de área local, entre la descarga directa del software y el montaje de CVMFS. En la Figura 4 se observa claramente, como al incrementar el número de peticiones de software, la saturación de la red aumenta, influyendo en el tiempo de

5 descarga, ya sea en CVMFS o en la descarga directamente del paquete. Por tanto, el incremento de tiempo en la ejecución de programas de cálculo científico, va a tener una relación directa con el número de envíos de trabajos simultáneos dentro de una misma subred. La escasa sobrecarga que se origina en CVMFS, al descargar la aplicación necesaria para ejecutar el trabajo del usuario, podría verse reducida en una situación realista. Si trabajos del mismo tipo, corriesen sobre el mismo nodo, ocasionaría que parte del software necesario ya estuviese cacheado localmente. En CVMFS, se controla por otro lado la descarga de múltiples copias del mismo archivo mediante un control seguro de su contenido (SHA1-Cache), evitando así la repetición de la descarga, debido a que los archivos duplicados se detectan automáticamente, lo que resulta en menos espacio consumido por la caché local, y menos tráfico de red. En estas pruebas, no se ha contemplado esa opción en CVMFS, ya que la caché se borra en cada una de las iteraciones de pruebas. En estos dos últimos casos no se contemplan ningún tipo de efectos externos sobre la latencia, ya que el entorno de pruebas está controlado y el repositorio de CERNVM, se encuentra dentro de la red de área local, sobre la cual se efectúan. Fig. 6. Comparativa del tiempo de ejecución de un trabajo por core en una red de área local virtualizada, entre la descarga directa del software y el montaje de CVMFS. En la Figura 6 se puede comprobar la saturación de descarga directa de archivos, incrementada por el número de nodos de la red, donde alcanza picos de 6 minutos en el peor de los casos, mientras que con el sistema de archivos CVMFS, el incremento es menos pronunciado. La suma de tiempos de redes de alta y baja latencia, sumado a la limitación de la red de 100Mb del repositorio de software, hacen que la descarga del software en los nodos virtuales sea un problema de escalado a la hora de ejecutar múltiples aplicaciones en nodos de cálculo científico. Fig. 5. Comparativa del tiempo de ejecución de un trabajo por nodo en una red de área local virtualizada, entre la descarga directa del software y el montaje de CVMFS. Se puede comprobar en la Figura 5 cómo los tiempos reales finales son sensiblemente mejores con el uso de CVMFS. El efecto del servidor HTTP de respaldo Squid reduce el tiempo y la sobrecarga de red de alta latencia a través de la que se obtiene el software de CVMFS. Este es producido en su mayor parte por la descarga de ficheros no cacheados en cada una de las repeticiones. En un entorno en el cual, la caché estuviese llena, en el caso de aplicaciones que utilizasen el mismo software, el contorno de la línea de la gráfica de CVMFS debería de ser más lineal, y no denotar un incremento tan pronunciado. Por otro lado, se ha podido comprobar, que el tiempo de descarga es sensiblemente mayor a los primeros casos de pruebas expuestos, pero el resultado final, la suma de todos los tiempos, se ve reducido debido al tiempo de ejecución del software en los nodos virtuales. Fig. 7. Comparativa del tiempo de ejecución de un trabajo por nodo en una red de área local virtualizada y sin virtualizar, entre la descarga directa del software y el montaje de CVMFS. En la Figura 7, se puede comprobar que el escalado es independiente de la mezcla de redes con nodos virtuales o nodos normales, habiéndose echo las pruebas aumentando en partes iguales el número de nodos a escalar, tanto virtuales como normales.

6 Fig. 8. Comparativa del tiempo de ejecución de un trabajo por core en una red de área local virtualizada y sin virtualizar, entre la descarga directa del software y el montaje de CVMFS. En la Figura 8, el incremento también va marcado por latencia en estas pruebas. En la descarga directa de archivos, ésta se ve incrementada por el número de nodos de la red, donde alcanza picos de 6 minutos en el peor de los casos, mientras que con el sistema de archivos CVMFS, el incremento es menos pronunciado, aunque existe un cierto repunte al final, originado por la saturación de la red, ya que el tiempo en la descarga de archivos se ha visto incrementado. usuario que a través de un único punto en común van a ser servidos de una forma fácil y dinámica, en donde el usuario, independientemente del grupo al que pertenezca, va a ver reducidos sus tiempos de finalización de trabajos, y tendrá la posibilidad de tener actualizado su software en todo momento. Al utilizar el protocolo estándar HTTP para todas las comunicaciones, se puede cachear eficientemente el software a distribuir, de tal forma que es indiferente la localización física de los nodos de cálculo, mostrando, así, una clara ventaja con respecto a la descarga e instalación del software por parte del usuario. Este estudio demuestra una clara superioridad competitiva en cuanto a tiempos totales, para un usuario que necesita enviar múltiples trabajos, en entornos virtuales o nodos normales, que verá reducido su tiempo si lo utiliza, en vez de descargarlo directamente al nodo desde el que se ejecute el trabajo. Con lo cual, la aplicación testeada favorece la mejora de tiempos para su utilización en entornos de aulas informáticas virtualizadas, de varios grupos de usuarios, que emplean software de instalación distinto entre ellos. AGRADECIMIENTOS Al proyecto y a la gente de Formiga-Cloud, a través del cual, se hizo necesario este estudio. Marcos A. Seco, por su colaboración en el desarrollo de las pruebas. REFERENCIAS Fig. 9. Distintas pruebas del tiempo de ejecución de un trabajo desde la Universidad de Barcelona. En la Figura 9, la latencia de las redes de área extensa vuelve a ser la causa del incremento en el tiempo de finalización de un trabajo. En comparación el tiempo se reduce a casi la mitad indiferentemente del número de trabajos a ejecutar en un nodo. VI. CONCLUSIONES [1] Jakob Blomer, T Fuhrmann, A Fully Decentralized File System Cache for the CernVM-FS, Proceedings of 19th International Conference on, vol., no., pp.1-6, 2-5 Aug. 2010, doi: /ICCCN , 2010 [2] B Segal et al., "LHC Cloud Computing with CernVM", Proceedings of the XIII. International Workshop on Advanced Computing and Analysis Techniques in Physics Research (ACAT10), Jaipur, 2010 [3] A Harutyunyan et al., Dynamic virtual AliEn Grid sites on Nimbus with CernVM, J. Phys, 2010 [4] P Buncic et al., CernVM a virtual software appliance for LHC applications, J. Phys., 2010 [5] P Buncic et al., "A practical approach to virtualization in HEP", The European Physical Journal Plus, 2011 [6] Portable Analysis Environment using Virtualization Technology, Jakob Blomer,December 2010 [7] An alternative model to distribute VO specific software to WLCG sites: a prototype at PIC based on CernVM file system, Cern, GDB meeting, Elisa Lanciotti, November 2010 [8] Jeffrey Katcher, PostMark:File System Benchmark, 2008 [9] Don Capps, Analyzing NFS Client Performance with IOzone, 2009 [10] CloudStack, [11] IOzone Filesystem Benchmark, [12] LHC Grid [13] CernVM En la ejecución de tareas de cálculo científico es importante la conclusión de aquellas en el menor tiempo posible, siendo la instalación del propio software para la ejecución por parte del usuario, uno de los factores que más pueden incrementar este tiempo. Con CVMFS, se ha demostrado tanto en entornos vitualizados como en nodos de cálculo reales, como se puede crear una infraestructura para varios grupos de