1. Ciencia

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
Resumen1— 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.
E
INTRODUCCIÓN
n 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), e-mail: [email protected]
2
Dpto. de Estructura y Constituyentes de la Materia (UB),
e-mail:[email protected]
3
Dpto. de Sistemas, Centro de Supercomputación de Galicia
(CESGA), e-mail: [email protected]
4
Dpto. de Sistemas, Centro de Supercomputación de Galicia
(CESGA), e-mail: [email protected]
5
Dpto. Electrónica y Computación, Universidad de Santiago de
Compostela, e-mail: [email protected]
2
Grupo de Física de Partículas, Universidad de Santiago de
Compostela (USC), e-mail: [email protected]
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 max Tij + t i
i ∈ ND
j ∈ Si
ND = {1,2…,M}
Si = {1,2…,Ni}
Ni = Número máximo de trabajos en el nodo i
Tij = Tiempo de ejecución del trabajo j en el nodo i
ti = 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
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.
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 E6750 @ 2.66GHz, siendo
las máquinas virtuales de 2 Cores, con 1GB de RAM
y 5GB de disco.
Universidad de Barcelona: Dual Core AMD
Opteron(tm) Processor 256 @ 1,7 GHz, 2 GB de
RAM y 4 Cores.
3)
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
A TAMAÑO Y CANTIDAD DE ARCHIVOS
Versión
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
ROOT
v.5.28
Caché
CVMFS
v.0.2.61
Tamaño
total
en MB
Número de
archivos
Tamaño medio
de los archivos
en KB
218
(56 tar.gz)
4630
2.5
69
628
4.0
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,
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
set env
time B ← run rf202_extendedmkfit
else
ejecutar una iteración en cada nodo
time A ← mount CVMFS
set env
time B ← run rf202_extendedmkfit
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
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.
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
set env
time B ← run rf202_extendedmkfit
else
ejecutar una iteración en cada nodo
time A ← download root
set env
time B ← run rf202_extendedmkfit
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. 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
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.
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
[1]
[2]
[3]
[4]
[5]
[6]
Fig. 9. Distintas pruebas del tiempo de ejecución de un trabajo desde la
Universidad de Barcelona.
[7]
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.
[8]
[9]
VI.
CONCLUSIONES
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
[10]
[11]
[12]
[13]
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:
10.1109/ICCCN.2010.5560054, 2010
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
A Harutyunyan et al., ―Dynamic virtual AliEn Grid sites on
Nimbus with CernVM‖, J. Phys, 2010
P Buncic et al., ―CernVM – a virtual software appliance for LHC
applications‖, J. Phys. , 2010
P Buncic et al., "A practical approach to virtualization in HEP",
The European Physical Journal Plus, 2011
Portable Analysis Environment using Virtualization Technology,
Jakob Blomer,December 2010
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
Jeffrey Katcher, PostMark:File System Benchmark, 2008
Don Capps, Analyzing NFS Client Performance with IOzone,
2009
CloudStack, http://www.cloud.com
IOzone Filesystem Benchmark, http://www.iozone.org
LHC Grid http://lcg.web.cern.ch/lcg/
CernVM http://cernvm.cern.ch/portal/