Inicio
Contacto
Área privada
Sobre ES-NGI ES-NGI@EGI Centros de Recursos Portal de Usuarios Proyectos de investigación soportados Formación

Herramientas Avanzadas

Dashboard

Para llevar a cabo las tareas de producción y análisis a través de un sistema altamente distribuido cruzando varios dominios de gestión, son claramente necesarios sistemas de control potentes y flexibles. El Experiment Dashboard monitoring system fue desarrollado originalmente para apoyar a los cuatro principales experimentos del LHC (LHCb, CMS, ATLAS, ALICE). Este framework no sólo es compatible con múltiples Grids / colas de middleware, incluyendo gLite (EGI), VDT (OSG) y ARC (NDGF), sino también es lo suficientemente genérico como para atender las necesidades de las comunidades de usuarios múltiples, no limitado a HUCs.

Además, el sistema cubre toda la gama de las actividades informáticas de los experimentos (control de trabajos, la transferencia de datos, puesta en marcha del sitio, etc) y responde a las necesidades de las diferentes categorías de usuarios (equipos de computación del LHC VOs, VO y la gestión de WLCG, los administradores del site y el apoyo a las VO en sus sites, los usuarios que ejecutan sus tareas de cómputo en la infraestructura Grid, etc).

Experiment Dashboard applications son ampliamente utilizadas por los experimentos del LHC para su trabajo diario y recibir más de un millar de visitantes únicos cada día y este número sigue creciendo constantemente.

Dashboard Framework

Todas las aplicaciones de escritorio experimento se desarrolló utilizando el marco Dashboard, que es implementado en Python. El marco Panel define la estructura de los módulos de panel. Que proporciona el sistema de generación y una aplicación común de los principales componentes de las aplicaciones de monitorización y los servicios. La estructura típica de una aplicación de escritorio se compone de recolectores de información, un repositorio de datos, normalmente implementado usando la tecnología de Oracle de base de datos, e interfaces de usuario. Información de las fuentes de datos pueden ser transmitidos a la aplicación Dashboard a través de protocolos diversos. En la mayoría de los casos, la aplicación Dashboard utiliza la comunicación asíncrona entre las fuentes de datos y el repositorio de datos. Agentes tablero son los componentes que tienen que realizar las tareas habituales. Ejemplos de tales tareas son: la recopilación de datos de monitoreo, las estadísticas de la agregación, el análisis de las estadísticas, alarmas de envío, etc El marco proporciona todas las herramientas necesarias para gestionar y controlar a los agentes Dashboard.

Site Monitoring

Las Organizaciones Virtuales del LHC representan una de las principales comunidades de usuarios de la infraestructura Grid y por lo tanto, las actividades informáticas de vigilancia del LHC proporciona la mejor estimación de la fiabilidad y el rendimiento del Grid. La mejora continua de la calidad de la infraestructura Grid se consigue gracias a la actividad del site y los cambios en la puesta en marcha del LHC Computing. Una de las funciones más importantes del Experiment Dashboards es proporcionar la información necesaria para realizar los cambios en LHC computing y el resto de sites que trabajan en el LHC. Los cambios en LHC Computing permite seguir el estado de los sites de distribución, servicios y su capacidad para realizar las tareas de las organizaciones virtuales del LHC. El resultado de la mejora de la calidad visible de los sites de distribución se mide y se muestra en el Dashboard Site Usability Monitor.

El Site Status Board (SSB) es otro ejemplo de una aplicación de Dashboard que se elaboran para el seguimiento de los sites distribuidos y los servicios desde la perspectiva de una organización virtual en particular. SSB proporciona un marco muy flexible que permite almacenar métricas personalizables en la interfaz de usuario y la exposición de los datos de seguimiento en tiempo de ejecución e históricos.

Para los usuarios avanzados (por ejemplo, los gerentes de las principales actividades tales como campañas de simulación de HEP ​​o búsquedas de drogas en comunidades LS) una característica muy importante es ser capaz de controlar este comportamiento de los recursos para detectar el origen de los fallos y optimizar el sistema. También se benefician de la posibilidad de medir la eficiencia y la evaluación de la calidad del servicio prestado por la infraestructura.

Monitorización de aplicaciones

La importancia de las herramientas de monitoreo flexible centrado en aplicaciones ha demostrado ser esencial no sólo para los usuarios avanzados, sino también para los usuarios individuales. Usuarios individuales son típicamente los científicos que utilizan Grid para el análisis de datos y verificación de hipótesis sobre conjuntos de datos que no se puede lograr con otras plataformas informáticas. En este caso, el seguimiento, proporcionado por Experiment Dashboards, es una guía para entender la evolución de su actividad, e identificar y resolver problemas relacionados con su aplicación.

Esto es esencial para permitir un soporte de usuario eficiente mediante la potenciación de los usuarios de tal manera que sólo los problemas no triviales se escalan para apoyar a los equipos (por ejemplo, los jobs en espera debido a un mantenimiento programado del site puede ser identificado como tal y el usuario puede decidir esperar o volver a reenviarlo. La aplicación Task monitoring se desarrolló con el fin de facilitar el análisis de los usuarios en la infraestructura de distribución, proporcionando información sobre el seguimiento necesario del análisis del usuario y del equipo de apoyo.

Dashboards de construcción genérica [BGD]

Las Experiment Dashboard para obtener información de fuentes que no son específicas de una VO se puede usar por VOs fuera del alcance del LHC y HEP. Entre esas aplicaciones estan la Site Status Board y la Site Usability interface. Está en fase de proyecto Messaging System for the Grids (MSG) que es una aplicación de monitorización de un job genérico para la visualización del estado de cada job. El Dashboard proporciona métodos genéricos que permitan la instrumentación de frameworks para VOs específicos para la presentación de informes en MSG.

En el futuro se centrará esfuerzos en las aplicaciones más comunes que son compartidas por múltiples VOs del LHC, pero que también podría ser utilizado fuera del alcance del LHC y HEP. Más información se puede encontrar en la [REVISTA DE GRID COMPUTING].

Ganga y DIANE [G & D]

Ganga es una herramienta fácil de usar que define una interfaz de trabajo y de gestión que proporciona de manera uniforme a través de múltiples sistemas de computación distribuida. Ganga ha sido desarrollado para satisfacer las necesidades de los usuarios de las comunidades ATLAS y LHCb y se utiliza mucho y con el apoyo de estos usuarios. Incluye soporte integrado para configurar y ejecutar aplicaciones basadas en el framework de Gaudí / Athena que es común a los dos experimentos. Sin embargo, también ofrece funcionalidades para la ejecución de una gama más amplia de aplicaciones, incluyendo ejecuciones arbitrarias. Ganga se ha diseñado de una manera que hace que sea muy fácil de usar para aplicaciones de barridos de parámetros, y realizar casos de aplicación más complejos. Permite cambiar entre las pruebas en un sistema discontinuo local y un tratamiento a gran escala sobre los recursos Grid y ofrece una capa de abstracción simple pero potente para entornos de computación distribuida. Ya que se basa en un sistema de plugins, que es fácilmente extensible y personalizable para satisfacer las necesidades de diferentes comunidades de usuarios, también se ha utilizado en EGI tutorials para introducir a nuevos usuarios al Grid.

La funcionalidad proporcionada por Ganga incluye una interfaz de línea de comandos para el trabajo de configuración, presentación y gestión de la configuración automática de aplicaciones complejas, manejo automático de grandes conjuntos de datos como las entradas y salidas de jobs, división de jobs para el procesamiento paralelo y su posterior fusión de las salidas. Los soportes backend para el uso general son los siguientes: Portable Batch System (PBS), Load Sharing Facility (LSF), and Sun Grid Engine (SGE), Condor, gLite WMS/CREAM-CE, ARC, Globus/GRAM, GridWay and the SAGA API standard.

El uso de Ganga se ha incrementado en los últimos años y como promedio existen más de 500 usuarios cada mes utilizando la herramienta para su trabajo diario.

Distributed Analysis Environment (DIANE) es un framework de procesamiento ligero que permite una ejecución más eficiente y robusto de un gran número de tareas de cómputo en las infraestructuras informáticas fiables y heterogéneos. Se aprovecha el método de enlace tardío (late-binding) y ofrece un scheduler, que puede ser aumentado por un sistema de plugins, para mejorar a master/worker la carga de trabajo en granjas y bolsas de tareas. Plugins for Direct Acyclic Graph (DAG) y data-oriented workflows se han implementado por las contribuciones de terceros por un número de comunidades de usuarios interesados. El framework también puede adaptar, aplicación de las métodos específico de procesamiento y gestionar las estrategias ante fallos. Los workers DIANE son a menudo presentadas mediante Ganga. Esta integración de las herramientas permite una combinación dinámica de recursos a través de varias infraestructuras de computación distribuida de recursos, incluyendo High Performance Computing (HPC).

A modo de ejemplo, Ganga / DIANE fue la interfaz con el motor de flujo de trabajo MOTEUR y se ejecuta como un servicio a la comunidad biomedicina en el contexto de aplicaciones de imágenes médicas GATE. Entre julio de 2009 y agosto de 2010 más de 360 ​​casos DIANE se activaron en la columna vertebral de servicio que maneja 58 mil puestos de trabajo para completar más de 113 mil tareas de simulación.

Además de las comunidades del LHC, el uso de las herramientas Ganga/DIANE se ha informado de las aplicaciones de UNOSAT, Geant4 medical, simulaciones espaciales y pruebas de grid de regresión, AvianFlu Drug Search, la UIT de planificación digital de difusión, las simulaciones de LatticeQCD, Fusion, EnviroGrids y simulación de detectores de gases (Garfield).

Ganga y Diane incluyen plugins para el Dashboard que proporcionan las comunidades de usuarios con el monitoreo en línea de los jobs ejecutados.

Grid Relational Catalog [GReIC]

El Proyecto Grid Relational Catalog (GRelC) proporciona un conjunto de servicios avanzados de datos Grid para manejar bases de datos en el Grid de una manera transparente, fácil de usar, eficiente y seguro.

Por el momento GRelC Data Access and Integration Service (GRelC DAIS) permite a los usuarios acceder e interactuar con diferentes DBMSs, tanto relacional (PostgreSQL, MySQL, SQLite, etc) y no relacionales (eXist, Xindice, XML flat files, etc), proporcionando una interfaz de acceso uniforme a fuentes de datos heterogéneas.

Funciona correctamente en combinación con el software de gLite mediante la ampliación de la funcionalidad de la infraestructura Grid y dispone de 2 tipos diferentes de clientes: la interfaz de línea de comandos (CLI), disponible en un solo RPM, y el Portal GRelC. El Portal GRelC (disponible en el "Portal GRelC" en la página web GRelC [GW] ofrece todas las funcionalidades proporcionadas por el CLI de forma directa:

· Enviar consultas.
· Gestionar la red de la empresa.
· Administrar usuarios y sus privilegios.
· Definir los espacios virtuales y sus propiedades.
· Gestionar VOs.
· Administrar varias DAISs GRelC al mismo tiempo.
· Ver la información de metadatos sobre el esquema de la base de datos/tablas.

El GRelC DAIS está integrada en la GII (Infraestructura Grid Italiana) y desde 2008 se ha incluido en el RESPECT Program.

El software GRelC ha sido explotado en varios proyectos Grid de investigación para apoyar experimentos de bioinformática en los bancos de datos distribuidos, así como la gestión de metadatos en dominios de Ciencias de la Tierra y del Medio Ambiente.

El servicio GRelC está adoptado como el servicio Grid de gestión de metadatos en el banco de pruebas Climate-G para el intercambio de datos geográficos, de búsqueda y descubrimiento. Por otra parte se utiliza actualmente en el Euro-Mediterranean Centre for Climate Change para gestionar los metadatos del clima a través de la infraestructura Grid de datos CMCC a través del portal CMCC Data Distribution Centre.

Finalmente, un amplio conjunto de [GREIC TUTORIAL] están disponibles para los usuarios finales para aprender más sobre el Portal GRelC, la CLI y el JDK.

Kepler

Kepler está diseñado para ayudar a los científicos y los desarrolladores a crear, ejecutar, compartir modelos y análisis a través de una amplia gama de disciplinas científicas y de ingeniería. Los buques de Kepler con una biblioteca de búsqueda que contiene más de 350 listas para el uso de componentes de procesamiento ('actors') que puede ser fácilmente personalizado, conectado y luego ejecutar desde un entorno de escritorio para realizar un análisis, automatizar la gestión de datos e integrar aplicaciones de manera eficiente. Los Flujos de trabajo de Kepler se pueden anidar, lo que las tareas complejas se dividen en componentes más simples, y permitiendo a los "workflow designers" construir código reutilizable y modular sub-workflows que pueden ser guardados y utilizados para muchas aplicaciones diferentes.

El proyecto EUFORIA (EU Fusion for ITER applications) ha ampliado el repositorio de componentes para Kepler lo que ha permitido dar múltiples Grids/colas middleware, incluyendo gLite (EGI), UNICORE (access to HPC resources) y I2G (int.eu.grid). Las extensiones abarcan diversas actividades como: el envío de jobs, supervisión, manejo de datos y acceso interactivo a los jobs en ejecución.

Todos los "actors" son genéricos y pueden ser reutilizados por varias comunidades. Hay también un número de diferentes casos de uso predefinidos que pueden ser personalizados fácilmente y reutilizados por las distintas aplicaciones.

MOTEUR

El MOTEUR workflow manager fue desarrollado para hacer frente a las necesidades para la descripción y la promulgación de uso intensivo de datos de imagenes de análisis médicos en la infraestructura Grid de EGEE. Esta herramienta no es específica de esta área de aplicación y si se pueden reutilizar en una amplia categoría de aplicaciones que cubren las necesidades de muchas áreas científicas uso de la red por su capacidad de computación de alto rendimiento.

Flujos de trabajo de MOTEUR se describen a través de un editor gráfico. Su representación interna es un lenguaje específico basado en los principios de programación de matriz que hace que sea bien adaptado para representar los flujos de datos paralelos y complejas construcciones de manipulación de datos, que son comunes en aplicaciones basadas en datos científicos. Este lenguaje es muy compacto y tiene un paralelismo implícito en su representación y es muy adecuado para usuarios no expertos. Además, tiene más carácter expresivo que el lenguaje Scufl con Taverna workbench y son compatibles. Puede representar todas las formas de los datos paralelos de construcciones tales como estudios de barrido de parámetro, reducir mapas de operaciones y casos de uso mucho más complejos.

MOTEUR workflow enactor es una organización independiente de gLite con una interfaz capaz de explotar los máximos datos y el paralelismo de servicios, mientras utilizamos la explotación de los recursos Grid para aprovechar su carga de cálculo. Fue diseñado para funcionar en un contexto de ejecución Grid. Puede acomodar las cargas pesadas necesarias para aplicaciones Grid a gran escala. Además, incluye una línea de comandos de la aplicación de herramientas que facilita el proceso de empaquetado y la conexión de una interfaz de línea de comandos basada en herramienta para el middleware gLite.

MOTEUR es un motor de flujo de trabajo de código abierto disponible online [MOTEUR].

HammerCloud [HAMMERCLOUD]

HammerCloud es un sistema distribuido de análisis de pruebas entorno a Ganga. Fue realizado por una necesidad de la colaboración ATLAS para el sitio y administradores centrales-para poner a prueba fácilmente un conjunto de puntos de Grid con un número arbitrariamente grande de puestos de trabajo de análisis real. Estas pruebas son útiles durante la puesta en marcha del site para validar y ajustar las configuraciones, y también durante las operaciones normales para comparar el funcionamiento periódico del site. HammerCloud genera un informe de pruebas, incluyendo parámetros como la tasa de procesamiento de eventos, la utilización de la CPU media, y los tiempos relacionados con las distintas etapas de los trabajos de análisis del usuario. El informe se presenta en una interfaz web que hace que sea sencillo comparar los sites y observar las tendencias en el tiempo. El sistema ha sido utilizado en el experimento ATLAS para ejecutar más de 200.000 CPU/día en los análisis de la prueba. HammerCloud se implementa como una aplicación web Django, los estados se mantienen en una base de datos MySQL y administración de jobs en torno a Ganga realizado en Python. Los trabajos pueden ser presentados a los sites de WLCG utilizando la interfaz de usuario y gLite a todos los sitios ATLAS con Panda. Están en desarrollo diversos Plugins prototipo para los experimentos CMS y LHCb.

Gestión de Datos

DPM

WLCG Disk Pool Manager (DPM) - está basado en el sistema CASTOR de almacenamiento del CERN - Storage Resource Management (SRM) es ligero pero totalmente funcional con capacidad storage element (SE) que es utilizado actualmente por las LHC VOs y otras 60 más. Como se ha mencionado, DPM ofrece SRMv2 como interfaz de gestión, mientras que los archivos se puede acceder tanto a través de la GridFTP (ideal para una amplia transferencia en la red) y los protocolos RFIO (para el acceso local). Ambos protocolos compatibles con la autenticación mediante certificados X509 GSI. El DPM namespace ofrece autenticación flexible y configurable y la capacidad de la autorización, tales como el apoyo a grupos y roles VOMS, las asignaciones de IDs virtuales y las ACLs a nivel de directorio y archivo. Mientras DPM se ha desarrollado inicialmente para los almacenamientos en el orden de 100TBs, tenemos ejemplos de implementaciones exitosas en los sites grandes en la escala de PBs, mientras que no hay que olvidar las ventajas principales como la facilidad de despliegue y gestión.

LFC

LCG File Catalogue (LFC) reemplaza los catálogos European Data Grid file (pre- EGEE), ofreciendo más características y mejoras en el rendimiento y la escalabilidad. Comparte una base de código común con el DPM, que también ofrece la facilidad de despliegue y gestión. Algunas de las características que ofrece son el uso de espacio de nombres jerárquico y las operaciones de espacio de nombres, una función de seguridad y la posibilidad de utilizar los métodos bulk para evitar largos tiempos de ida y vuelta. LFCs se utilizan en más de 60 puntos de Grid y por algunas decenas de VOs, entre ellos dos de los experimentos del LHC, ATLAS y LHCb. LHCb despliega un catálogo global con leer réplicas sólo en el Tier0 y Tier1. ATLAS actualmente despliega LFCs en los sites de Tier1 al catálogo datos en el Tier1 y Tier2 asociados, pero también se está moviendo para tener un catálogo global en el Tier0 con una segunda réplica de sólo lectura a uno de los Tier1. La sincronización se mantiene usando Oracle Streams. Para tener una idea de las escalas administradas por LFC, en el caso de ATLAS casi 250 millones de archivos se registran entre 11 instancias LFC.

FTS

El File Transfer Service (FTS) de gLite es un scheduler punto a punto para la transferencia de datos a través de la red. Los canales Grid Storage Element endpoints quedan emparejados de una manera similar a la topología de la red entre los sites y asegura el equilibrio y el límite de las solicitudes de movimiento de datos a través de la infraestructura. Los canales FTS se pueden configurar con el fin de garantizar una participación mínima del ancho de banda a cada organización virtual habilitada en cada canal. El servicio de FTS puede negociar con los criterios de valoración de almacenamiento a través del protocolo SRM, mientras que se utiliza en el tercer modo de GridFTP para la transmisión real de bytes streaming. Una interfaz de servicios web permite al usuario enviar los jobs de transferencia (que consta de muchos archivos), para sondear su estado y cancelar jobs. Los estados de todas las transferencias (tanto los actuales y la historia) se almacenan en una base de datos ORACLE, junto con la información de monitorización. En WLCG, el despliegue de FTS se distribuye en muchos sites (Tier0 y Tier1). El servidor de FTS en el CERN regula el tráfico desde el CERN a todos los Tier1 (y viceversa), mientras que cada servidor FTS en un Tier1 están reguladas por el tráfico de entrada a la Tier1 (aparte de la que proviene de la Tier0) y todas las asociaciones Tier2 el Tier 1.

Future Data Management Developments

Después de la primera experiencia con los datos reales del LHC, la producción y el análisis se ha hecho evidente que algunos de los supuestos del modelo actual no serán exactos. Por ejemplo, la "pre-colocación" de los datos para el análisis de los sites de Tier1 y Tier2 ha mostrado que una gran parte de los datos nunca se accede. Recientemente se han propuesto para su evaluación modelos alternativos, tales como el almacenamiento en caché dinámico de datos y/o de acceso remoto. Como con la mayoría de los desarrollos en esta área, las estrategias podrían ser igualmente beneficioso para otras comunidades y podría resultar en una mejor utilización de los recursos (tráfico potencialmente más bajos de la red, ya que sólo los datos necesarios se transfieren y se mejora la gestión del almacenamiento a través de un número menor de copias de datos). Otros temas actualmente en estudio incluyen la posibilidad de utilizar componentes estándar para la gestión de almacenamiento y/o acceso a los datos - probablemente de interés probable para todas las comunidades.

Hydra

Como parte de los servicios prestados a la Life Sciences HUC, el CNRS desplegará un servicio de archivos sensibles basado en encryption/decryption en el servicio de Hydra, una solución de almacenamiento de claves basado en claves de cifrado que se almacenan en un almacén de claves distribuidas, garantizando la seguridad y la tolerancia al fallo. El software de Hydra se ha desarrollado en el CERN y en la actualidad se migró a gLite 3.2.

El despliegue consiste en la instalación y configuración de software en tres almacenes de claves separados y la publicación del servicio en el BDII, la pre-instalación del software del lado del cliente en todos los sites en el ámbito de las LS HUC VOs, así como en los usuarios escritorios, y la puesta en marcha de un sistema para monitorizar la calidad del servicio.

El servicio de Hydra es una solución de cifrado que habilita el cifrado de los archivos almacenados en los recursos de almacenamiento. La información sensible - las claves de cifrado y descifrado - se almacenan en el almacén de claves Hydra que asegura un acceso seguro y controlado a ellos. Hydra se divide y distribuye piezas clave para varios almacenes de claves (por ejemplo, tres), de acuerdo con el principio de compartir el secreto del algoritmo de Shamir. Las piezas clave son los siguientes:

· Parcialmente redundantes (por ejemplo, 2 de cada 3 piezas son necesarias para reconstruir una clave de cifrado)
· Siempre incompleta (por ejemplo, por lo menos dos piezas son necesarias).
· Así, incluso si un servidor falla o se ve comprometida, las claves siguen siendo accesibles y protegidas.

VisIVO [VISIVO]

VisIVO proporciona un conjunto integrado de herramientas y servicios que se pueden utilizar en muchos campos de la ciencia (química, física nuclear, biomédica, etc). Permite a los usuarios visualizar highly-complex datasets y crear movies de estas visualizaciones basandose en infraestructuras distribuidas. Su característica peculiar es que no hay límite para lo que se refiere al tamaño de las tablas de entrada que contiene los datos para ser procesados, por lo tanto son capaces de soportar bases de datos a muy gran escala (decenas de terabytes y más).

VisIVO Server consta de tres componentes principales: VisIVO Importer, VisIVO Filter and VisIVO Viewer. Para crear vistas personalizadas de representaciones en 3D de las tablas de datos astrofísicos, es necesario un proceso de dos etapas.

En primer lugar, VisIVO Importer se utiliza para convertir bases de datos de usuario en VisIVO Binary Tables (VBTs). A continuación, se invoca VisIVO Viewer para mostrar vistas personalizadas de representaciones en 3D. VisIVO Filter es una colección de módulos de procesamiento de datos capaz de explorar conjuntos de datos y poner de relieve la mejora de sus propiedades ocultas.

VisIVO Importer soporta la conversión de varios formatos más populares de la siguiente manera: ASCII y tablas CSV, VOTables FITS Tables, Gadget dataset (Gadget es de código de libre disposición para las simulaciones cosmológicas N-body/SPH), Raw Binary (volcado de memoria binaria). La operación del VisIVO Importer está altamente optimizado para la mayoría de los casos, un período corto de tiempo (unos segundos), incluso para grandes conjuntos de datos.

VisIVO Filter es un conjunto de módulos de procesamiento de datos para modificar un VBT o para crear una nueva VBT de otros VBTs existentes. Los filtros soportan una serie de operaciones tales como la distribución de escalares, operaciones matemáticas, selección de las regiones, destrucción, la asignación al azar y así sucesivamente. Las operaciones de selección y la asignación al azar son de particular importancia, ya que suelen ser empleados para la construcción de VBTs reducidos para que puedan ser utilizados directamente por VisIVO Viewer.

VisIVO Viewer se basa en la librería Visualization ToolKit para la visualización multidimensional y en Splotch, una herramienta ray tracing de renderizado desarrollada por el Instituto Max Planck que crea imágenes 3D a partir de conjuntos de datos. VisIVO Viewer puede hacer puntos, volúmenes y iso-surfaces de una caja de selección que se utiliza para la representación del sistema de coordenadas utilizado. Además, el soporte es proporcionado por las tablas de aspecto personalizado que permite visualizaciones que hacen uso de una variedad de glifos, como cubos, esferas o conos.

El software está diseñado para crear imágenes y películas de los archivos de usuario. Actualmente están soportados varios formatos. El proceso de creación de la película puede durar varias horas.

El primer objetivo fundamental de portar VisIVO a Grid es que las películas e imágenes están almacenadas directamente en Grid y para reducir el tiempo total de producción de la película.

Capacidades del servicio WLCG

El servicio WLCG puede ser consideradas como "high end" de la computación Grid. En términos de número de usuarios únicos, el númerojobs por día, volúmenes de datos y los ratios de acceso, número de núcleos disponibles, el volumen y el crecimiento de datos que es bastante mayor que cualquier otra comunidad en el uso de Grid Computing y su gran compromiso. WLCG optó por alinearse en mayor medida posible con EGEE desde sus primeros días y este compromiso sigue con EGI con el uso de las operaciones clave y herramientas de apoyo, junto con unas colas middleware que se basa principalmente en gLite (WLCG sites también existen en el países nórdicos, ARC plus funciona con Glite además de algunos componentes como la LFC y FTS, y EE.UU. sobre la base de OSG. Aunque sujeto a un Memorandum of Understanding (MoU), WLCG trabaja principalmente como un esfuerzo de colaboración entre los sites, los proveedores de servicios y los experimentos. WLCG ha desarrollado un pequeño número de procedimientos operativos, algunos de los cuales ya han sido adoptadas por EGEE (y por tanto EGI). Otros procedimientos son totalmente genéricos y puede ser fácilmente adoptados por las diferentes comunidades, a medida que crecen sus necesidades de producción. Esto incluye estrategias para implementar y ejecutar servicios robustos y resistentes, así como las políticas para hacer frente a los interrupciones de un site o de la infraestructura (por ejemplo, GGUS).

Las nuevas grandes comunidades podrían adoptar algunas de estas estrategias desde el principio - todos están ampliamente documentados y otros detalles se pueden obtener de los puntos de contacto de la MS610 [MS610].

El objetivo del proyecto WLCG es permitir la explotación del potencial de la máquina LHC en sí. Desde el comienzo real de los datos del LHC, WLCG ha proporcionado una infraestructura de computación de calidad para la colocación de los datos y la contabilidad, procesamiento de datos y análisis de datos. Dicha infraestructura se ha enfrentado hasta ahora con gran contingente de problemas por las actividades diferentes de los experimentos, que por naturaleza son a veces explosivas y difíciles de predecir. En la conferencia internacional European Physics Society en julio de 2011, varios experimentos informaron de que la actividad de la computación ha estado funcionando sin problemas durante todo el año, lo que permite a los físicos llevar a cabo un análisis importante a su debido tiempo.

Los experimentos CMS y ATLAS, en particular, deberán ejecutar en cientos de miles de workernodes cada día y esta carga de trabajo se extiende por más de 60 sites en los que los dos experimentos se pueden beneficiar de los mismos recursos. Los dos experimentos han de competir por los recursos en muchos sites (especialmente en Tier1) y el sistema ha demostrado ser capaz de entregar las acciones adecuadas según lo acordado en el WLCG MoU.

2017 © Spanish National GRID Iniciative Aviso legal