Marc-Elian Bégin

Konstantin Skaburskas

Louise Merifield

Charles Loomis

Eduardo Huedo

Stuart Kenny

Henar Muñoz Frutos

Enhancing Grid Infrastructures with Virtualization and Cloud Technologies Reference Architecture for StratusLab Toolkit 2

à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

List of Figures

Executive Summary

This document presents the StratusLab reference architecture for v2.0. This document builds on the document D4.1 -Reference Architecture for StratusLab Toolkit 1.0, focusing on the updated architecture that guides work towards v2.0. The overall goal of producing an open source IaaS distribution that can be easily installed and configured remains central to the development of the v2.0 release.

Compared to v1.0, the v2.0 architecture is rationalized and consolidated. For example, the policy validation, caching and cloud storage are integrated as default features, where they were optional in v1.0. The Appliance Repository is replaced by the Cloud Storage service. Several services are also added or significantly augmented, such as Cloud Storage, virtual network provisioning and inter-cloud connectivity. This is also a client for the Service Manager, such that users can interact with this service remotely and securely.

Performance is also improved through integration of the Caching Service which interacts with Cloud Storage, allowing for a scalable solution with minimal VM start times.

The higher-level architecture is described, focusing on the main layers and of the StratusLab architecture as well as groups or categories of services and components. The main groups are: compute, storage, network, Marketplace (or image management), monitoring and billing and finally inter-cloud connection. This description also identifies the main interfaces and protocols used. Most the the users will interact with StratusLab using standard interfaces, e.g. OCCI, CDMI, OVF, TCloud, or popular access mechanisms such as jClouds. When such standards are not available or not appropriate, then RESTful web services are used, with the exception of OpenNebula (providing the function of VM manager) which is accessed via XML-RPC.

The services and components composing the high-level architecture are shown in a decomposition diagram, with a focus on the main interfaces between these elements, such that the main control and data flows are clear. This diagram shows that all user access is performed via proxies, to harmonize access and protect the underlying services. Another noticeable architectural strategy is the central role the new Collector Service plays in v2.0. This aggregator service collects data from different services and components and also provides this data to any service or component, via simple, secured access. Further, the integration of all data persistence requirements are consolidated into a Persistence Storage Service, based on iSCSI or NFS.

Each service and component is described in more detail, including the interactions between the elements composing the architecture. Also described for each element is its internal composition, focusing on what is reused, adapted and/or newly developed to deliver the required functionality. The license of each service and component is also provided for each element. All elements in the architecture are released under the Apache 2.0 license, with the exception of Claudia, which is released under the Affero GPL license.

From v1.0 to v2.0, incremental versions of the StratusLab distribution are being built and released to provide an increasing amount of the functionality identified in this document, alongside further improvements to the robustness of the distribution.

The ultimate aim of this document is to provide high-level information regarding the architecture of the StratusLab distribution v2.0, such that readers have a better grasp of how the system is structured, how it is integrated, and from where do the different components and services come.

Introduction

This document is a complement to D4.1 -Reference Architecture for StratusLab Toolkit 1.0, where it updates the architecture of the system such that StratusLab can successfully support the 'Hybrid Infrastructure' use case identified in D4.1.

The following chapters from D4.1 are directly applicable to this document:

• Chapter 3: Requirements This document introduces the updated architecture by showing the high-level composition of the system; then each service and component in this high-level view is described in detail. The section with the details serves a double purpose, on one hand providing more clarity as to what was reused and integrated versus newly developed software, and on the other hand providing more information such that users can more easily understand the different components and services of the StratusLab system. This information will be converted to pages on the website to make it more accessible to the StratusLab users and administrators.

From v1.0 to v2.0, incremental versions of the StratusLab distribution are being built and released to provide an increasing amount of the functionality identified in this document, while also further improving the robustness of the distribution.

This document describes a complete and ambitious architecture for an IaaS cloud distribution. Given time and resource constraints, the project will concentrate on the most important elements of this architecture; consequently, some elements may be developed during the evolution of the StratusLab distribution after the project ends. It is a roadmap that guides the project's developments to enable to deliver software with relevant cloud functionality. As we realize this architecture, gather further feedback, and investigate new cloud innovations, we may find alternative and potentially better ways of accomplishing our goals and may consequently alter the development priorities and architecture.

Architecture Overview

The StratusLab reference architecture can be viewed as a layered model, grouping of the main components and services composing the system. Figure 3.1 identifies two main blocks: 'Image Management' and 'IaaS Cloud'. The same figure also identifies the main interactions users have with the system. Since image management is not required to be co-hosted with the IaaS cloud service, these are represented in separated high-level blocks. Figure 3.1 also identifies the main protocols and standards that StratusLab aims to support for v2.0.

A pattern in newer services (e.g. Persistent Disk Manager, Marketplace, Dashboard) is that they favor custom RESTful web service interfaces. The rational for this design decision is to be able to deliver functionality immediately (without depending on future standards) while allowing easy adaptation as we go forward.

New for v2.0, are the persistent disk manager, network manager and a control dashboard. The dashboard is an upgrade of the web monitor service, with the important addition of accounting/billing functionality. In order to deliver this feature however, another service, the collector, is required to transversally collect data from several other services and components. Alongside the collector service is an archiver service, which is responsible for archiving all relevant information for later querying and/or (re)processing.

The network manager provides added features such that users can more dynamically create and configure deployment specific virtual networks, in order to provide finer control and isolation of their system deployed in the cloud. The persistent disk manager provides Amazon EBS-like functionality, such that persistent disk devices can be used in conjunction with running virtual machines, either as the main boot device, or as extra data stores that can be attached to virtual machines.

Another important new component is the 'Inter-Cloud Connector', which is responsible for interfacing a given cloud site with another. At the time of writing, we have not completed the design of this important element. It it therefore left at a high-level, while the exact use cases are developed which will allow the detailed design to be done.

Another way of looking at the reference architecture is to represent the different services and components, identifying the main interactions between them. Figure 3.2 does just that. Here we can see that for v2.0, the 'Collector Service' plays a large role in gathering data from several elements, providing a central location from which to query the state of different services and components in the StratusLab v2.0 gives a larger role to the Marketplace to identify virtual machines and disks to instantiate at a given cloud site. In this context, the appliance repository functionality is absorbed in the Cloud Storage Service. Since in the Marketplace each entry is digitally signed including a digital checksum of the virtual image it represents, this approach promotes security and trust, no matter from where the raw files are sourced.

The goal of this tighter integration between the Marketplace and the IaaS layers is to provide a mechanism where trust can be built between the system administrators and users. For this we use cryptographically signed virtual image manifests (or metadata documents) to ensure that we can associate VMs to real users, as well as ensuring that VMs were not modified after creation. This functionality is provided by the Marketplace, together with extended command-line tools. A policy engine and a set of black and white lists related to VM heuristics, integrated at the IaaS VM management level, provide system administrators and users with an automated mechanism to build trust.

Figure 3.2 shows also the facade role that the command-line client plays in abstracting the service interfaces of the system for end-users. The same is true for the dashboard, which abstracts the monitoring and billing services. In v2.0, the Service Manager (Claudia) is also available via a remote command-line client, which will allow users to control and monitor the service from outside the cloud site, as is already available for several other services.

SlipStream has also been added to the overall architecture decomposition. Slip-Stream is a service providing virtual machine factory functionality and multi-machine deployment orchestration. While this service is not part of the StratusLab distribution, it leverages a significant number of StratusLab services and components. It is a commercial product now available as a SaaS and turn key solution, and part of the StratusLab sustainability and exploitation strategy.

VM Manager (OpenNebula) Authentication Proxy

Overview

The VM Manager (OpenNebula) Authentication Proxy provides a secure, authenticated bridge between external users and the OpenNebula daemon. The service authenticates users based on its configuration, inserts this information into the XML-RPC call to OpenNebula, forwards the modified request to OpenNebula, and then passes the response back to the user.

The service takes advantage of the Java Authentication and Authorization Service (JAAS) implementation with the Jetty web application container, providing a flexible and extensible set of authentication methods. By default, the service is configured to allow authentication with 1) username/password pairs obtained through a simple configuration file or through an LDAP server or 2) digital certificates (e.g. grid credentials in the form of certificates or short-lived proxies).

Main Interfaces with Other Services/Components

Users access the VM Manager (OpenNebula) service via the authentication proxy. The authentication proxy is accessed programmatically through an XML-RPC interface that mirrors the underlying OpenNebula XML-RPC interface. The only difference is that authentication is handled by the proxy, with this information inserted into the XML-RPC calls passed to the OpenNebula daemon.

The workflow for accessing OpenNebula via the authentication proxy is shown in Figure 4.1. The small core of the service has been developed by the Stratus-Lab project. Standard authentication plugins are used for username/password authentication mechanisms. The plugin supporting grid certificates was created by StratusLab using the cryptographic tools provided by gLite.

The direct software dependencies of the service are listed in Table 4.1. Relevant standards used or supported by the service are shown in Table 4.2.

License

Overview

The Persistent Disk Service provides users with persistent storage with a diskbased (or block device) abstraction. The service allows users to create disks, to mount/unmount them on machine instances, and to destroy them. This lifecycle is independent of any particular machine instance, allowing persistent storage of data.

Main Interfaces with Other Services/Components

The core of the service is a Java-based, RESTful application presenting a proprietary API. Users can access this service via a web browser (HTML representation) or programmatically via the StratusLab command line client (JSON representation).

The service creates user-accessible disks on storage directly attached to the machine running the service. This storage can be accessed via LVM or as a normal file system. LVM-based storage is preferred as this allows faster creation of disks and snapshotting of volumes.

The disks are shared with virtual machines running on the compute hosts either via an iSCSI server or via a shared file system. The iSCSI mechanism is preferred because it provides better performance. Remote access to the defined disks can be provided via HTTP or gsiftp protocols, if they are public and the associated servers are properly configured and running.

This service was entirely developed within the project, although has significant dependencies on other services to provide the complete functionality.

License

License Apache 2

Git repository stratuslab-storage.git 6 Registration Service

Overview

The Registration Service provides a web interface that allows new users to register with the infrastructure, or existing users to update their registration information.

The service also provides cloud policy documentation that users must comply with as part of the registration process.

Main Interfaces with Other Services/Components

Users access this service primarily via a web broswer, although the service could also be accessed programmatically because of the RESTful nature of the interface.

The service keeps all of the user registration information in an LDAP server, running separately from the Registration Service. The StratusLab installation uses the ApacheDS LDAP server implementation, but any other LDAP implementation could also be used.

Interaction with the cloud infrastructure happens through the various authentication proxies for the cloud services, which must be properly configured to access the information in the LDAP server.

Internal Composition

This service has been entirely developed within the StratusLab project, making use of the software listed in Table 6.1. The service requires access to an external LDAP server to manage the user registration information. The ApacheDS implementation is installed by default, but any other standard LDAP service could be used.

See Table 6.2 for the relevant standards supported or used by the service.

Main Interfaces with Other Services/Components

The network manager component interacts with the underlying networking fabric and services to create and manage VLANs. The service is interfaced with the VM management components.

Internal Composition

This component integrates the work of the Mantychore project into a new service, interfaced with the VM manager.

License

Apache 2.0.

Marketplace

Overview

StratusLab provides a complete, open-source solution for deploying an "Infrastructure as a Service" cloud infrastructure. Use of the cloud requires the use of prepared machine and disk images. Although StratusLab provides tools to simplify the creation of these images, the procedure for doing so remains a significant hurdle for use of a cloud. Consequently, StratusLab encourages the sharing and reuse of existing images to reduce this barrier.

The Marketplace is at the center of the image handling mechanisms in the StratusLab cloud distribution. It contains metadata about images and serves as a registry for shared images. The Marketplace allows:

1. Users to browse for relevant, pre-existing virtual machine images, 2. System administrators to evaluate virtual machine images against their security policies, 3. Machine creators to publish their work to a larger audience.

Main Interfaces with Other Services/Components

The core of the service is a Java-based, RESTful application presenting a proprietary API. Users can access this service via a web browser (HTML representation) or programmatically via the StratusLab command line client (XML representation).

Internal Composition

This service has been entirely developed within the StratusLab project, making use of the software listed in Table 8.1. See Table 8.2 for the relevant standards supported or used by the service.

License

License Apache 2

Git repository stratuslab-marketplace.git 9 Image Manager

Overview

The Image Manager Service is responsible for resolving Marketplace unique identifiers to physical image files, stored in the Persistent Storage service / Image Repository. For v2.0, we aim to simplify and streamline the VM submission chain, where the caching, policy validation and image retrieval are integrated into a more coherent and better performing system. The Image Manager provides this functionality, in collaboration with the Image Repository and the Persistent Storage service. This service also absorbs v1.0 services such as the Appliance Repository and several ad-hoc scripts that were integrated with OpenNebula drivers and extension mechanisms.

Main Interfaces with Other Services/Components

The Image Manager component interacts with the Image Repository, which sits on top of the Persistent Storage Service.

Internal Composition

This component is developed from scratch, reusing command-line client logic and REST interfaces to other services.

License

Apache 2.0.

VM Manager (OpenNebula) 10.1 Overview

The VM Manager is the core of the system. It orchestrates requests and manages the allocation of resources, as well as the life-cycle of running virtual images. This functionality is provided by OpenNebula, an open-source toolkit for on-premises IaaS cloud computing, offering a comprehensive solution for the management of virtualized data centers to enable private, public and hybrid (cloud bursting) clouds. OpenNebula includes enhancements to address the requirements of the StratusLab project, such as integration with Ganglia, fault tolerance functionality, and virtual network improvements.

Main Interfaces with Other Services/Components

OpenNebula is a core component of the StratusLab distribution and interfaces with most of the other StratusLab components, mainly: Marketplace, Persistent Disk Service, Authentication Proxy, Network Manager and Service Manager (Claudia). Additionally, OpenNebula interacts with the underlying physical infrastructure (servers, networking fabric and services, storage etc.) to manage virtualized infrastructures.

Internal Composition

We can distinguish three different areas related to StratusLab in the VM Manager:

• VM Management: It interfaces with physical resource hypervisor, such as KVM, to control (e.g. boot, stop or shutdown) the VMs. It also provides access control to virtual resources and provides fault tolerance.

• Image/Volume Management: Through extended hooks and in collaboration with other services such as the persistent storage and the Marketplace, it transfers the VM images from an image repository to the selected resource and creates on-the-fly temporary images. These also provide caching policies.

• Network Management: Also through hooks, allows each user (or group) to have access to a set of isolated LANs (VLAN) that may be dynamically created. Additionally, this component will allow filtering of virtual machine • Authentication Driver

• Image Downloader • Quarantine Manager • Caching Manager • Policy Validator
Here is an overview of these extensions:

Authentication Driver StratusLab has a unified authentication mechanism, provided by the Authentication Proxy. This means that we require OpenNebula not to perform its normal authentication logic, but trust the proxy. In order for this mechanism to be safe, the StratusLab installation procedure ensures that the OpenNebula daemon cannot be access from outside the machine running it.

Image Downloader StratusLab uses a sophisticated mechanism to allow users to specify which virtual machine they require to be instantiated on the cloud. This feature works in conjunction with the Marketplace service. For this to work, Stra-tusLab also ships with enhanced 'clone' scripts, which provides the logic for accessing the Marketplace to retrieve metadata required to find the physical virtual machine image file, and create a cloned persistent device from which to instantiate the VM.

Quarantine Manager StratusLab supports a quarantine feature, such that system administrators can define a quarantine time during which all terminated machines are kept. This allows them to perform forensic analysis on faulty or abusive virtual machines and to take appropriate actions.

Enhanced Logging To further improve forensic analysis and troubleshooting, improved logging of key events are provided such that, for example, event time correlation can be performed by extracting relevant data from logs. Caching Manager To boost performance, StratusLab supports a caching mechanism, such that the usually large virtual machine image files are not downloaded across the WAN on every request and also are not moved unnecessarily inside the cloud site. By default this is implemented using copy-on-write functionality.

Policy Validator

The Marketplace provides rich metadata for each virtual machine and disk image registered with it. This metadata includes digital endorsement and other information on which validation logic can be built. The Policy Validator is integrated as an extension to OpenNebula such that system administrators can have fine control over which virtual machine and disk users are authorized to run on their cloud. This is made possible using a set of black and white lists based on a number of configurable parameters.

Main Interfaces with Other Services/Components

All of the extensions elements integrate with OpenNebula, but have little or no interaction with OpenNebula.

Authentication Driver None.

Image Downloader Communicates with the Marketplace to retrieve metadata.

Once the final endpoint is resolved, it will retrieve (possibly via the caching mechanism) the images and request a clone to be created as a bootable device from the Persistence Service.

Quarantine Manager Persistent storage in which to move the terminated images for a configurable amount of time.

Caching Manager Volatile storage for retrieving cached images.

Policy Validator

Communicates with the Marketplace in order to retrieve metadata on which to apply the locally configured policy.

License

License Apache 2

Git repository stratuslab-one.git 12 Collector Service

Overview

Different types of information are produced across the StratusLab system. For example, information regarding the physical nodes, the virtual machines and the state of the instances from a virtual machine manager.

The Collector Service aggregates the information from these different sources, such that they can be accessed and consumed via a central interface.

To this effect, for example, virtual machine usage information is obtained from OpenNebula information drivers for physical hosts and virtual machines. This information is stored in the OpenNebula database with a proprietary format not necessarily suitable for accounting or billing processing purposes. Therefore, the data is either published or queried in order for the collector service to provide its clients with a uniform REST and/or messaging interface to retrieve the data. This allows high-level services, such as the monitoring and billing service to provide higher value products to the users.

Main Interfaces with Other Services/Components

The collector is designed as an autonomous component that either periodically extracts information, or better registers with services to be called on important state changes or event triggers.

For example, in the case of OpenNebula, usage information from a running OpenNebula instances can be pushed to the collector service using custom drivers and extensions.

A similar adapter is required for each service from which the collector collects information.

Internal Composition

This component is developed from scratch making use of existing REST services (e.g. Marketplace, Storage Service) and messaging frameworks (e.g. RabbitMQ or ActiveMQ) and protocols (e.g. Stomp, XMPP, JMS). Other standards such as OGF Usage Record1 are also used.

The different collector modules are developed based on existing interfaces and extensibility mechanisms. For example, the OpenNebula APIs are used.

License

Apache 2.0.

Archivers

Overview

The archivers are components providing persistence storage for collector service. This can take the form of databases and/or flat files. At the time of writing, this component is still to be better defined and designed.

Main Interfaces with Other Services/Components

The main provider and consumer of the archivers is the collector service.

Internal Composition

The archivers are implemented reusing standard database technology, such MySQL, or flat files.

License

Apache 2.0.

Inter-cloud Connector

Overview

The Inter-cloud Connector allows instantiation of VMs on public clouds (like Amazon EC2 or Flexiscale) as well as partner clouds (other StratusLab clouds). The component will abstract the external clouds' APIs by providing a common interface to them that can be plugged into the VM Manager component allowing a hybrid cloud approach (where the VM manager decides to outsource computation to another cloud) or the Service Manager component with a cloud brokering approach (when the VM is deployed in different cloud providers according to users' policies).

Main Interfaces with Other Services/Components

The component interfaces with OpenNebula and exposes a public cloud interface to create, manage and monitor VMs on StratusLab sites. The Inter-cloud Connector will be used through OpenNebula, the VM Manager, by means of virtualization and image transfer drivers. These drivers will also interface with Amazon-EC2 compatible clouds.

The component will also interface with Claudia which exposes a TCloud API, considered as an aggregated API, that incorporates different drivers for different Cloud providers (StratusLab-based clouds, Amazon, Flexiscale etc.).

Internal Composition

For the public cloud interface, a new binding for the jclouds API will be developed. The drivers for StratusLab and Flexiscale clouds are developed from scratch, while the EC2 ones will reuse exiting OpenNebula and Claudia EC2 drivers. These drivers will use the libraries needed to interface each cloud, i.e. the OpenNebula OCA API, the OCCI interface, the Amazon EC2 API or the Flexiscale API.

New functionality for image management will be integrated in order to import disk images from external storage providers, and adapting them so they can benefit from StratusLab's contextualization. For example, an Amazon EBS driver will allow importing Amazon EC2 AMIs into StratusLab sites. And in the other direction, the ability to convert StratusLab images into EC2 compatible images and contextualization will be integrated.

15 End-User Command-Line Client

Overview

The user command-line client is the main user interface for controlling and monitoring StratusLab cloud resources. It allows users to start, stop and query the state of their resources. This remote client also supports a number of authentication mechanisms.

Most StratusLab services provide commands, packaged with this component, such that the user is presented with a uniform mechanism for interacting with the cloud.

The starting point of this component was reused from proprietary code transferred to the StratusLab project from SlipStream by SixSq, with all permissions.

This component is written in portable Python (requires version 2.6 or higher) such that it can be simply installed on a wide range of user machines.

The component was entirely developed within the project, although it has significant dependencies on other services to provide the complete functionality.

A simple configuration file allows the user to configure defaults, which are used by most commands.

Main Interfaces with Other Services/Components

This component communicates through the proxy services and the Marketplace, using the appropriate protocols, e.g. REST, XML-RPC.

License

License

Apache 2

Git repository stratuslab-client.git The system administration command-line client is one of the two supported mechanisms to configure and install StratusLab.

A single configuration file is used to capture an entire StratusLab installation, from which the system administrator command-line client take configuration information.

Main Interfaces with Other Services/Components

This component installs and configures all the StratusLab services and components.

License

License

Apache 2

Git repository stratuslab-client.git The Service Manager, provided by Claudia, Authentication Proxy provides a secure, authenticated bridge between external users and Claudia. The service authenticates users based on its configuration, interact with the Claudia API server and then passes the response back to the user. The service takes advantage of the Java Authentication and Authorization Service (JAAS) implementation with the Jetty web application container, providing a flexible and extensible set of authentication methods. By default, the service is configured to allow authentication with 1) username/password pairs obtained through a simple configuration file or through an LDAP server or 2) grid credentials (certificates or short-lived proxies).

Main Interfaces with Other Services/Components

In a public infrastructure, users access Claudia via the authentication proxy. The authentication proxy is accessed programmatically through an HTTP interface.

License

License Apache 2 18 Service Manager (Claudia)

Overview

The Service Manager is provided by Claudia. The Claudia platform is an advanced service management toolkit that allows service providers to dynamically control the service provisioning and scalability in an IaaS cloud. Claudia manages services as a whole, controlling the configuration of multiple VM components, virtual networks and storage support by optimizing their usage and by dynamically scaling up/down services applying elasticity rules, SLAs and business rules. Claudia can deploy services in a public cloud (Amazon, Flexiscale, GoGrid, etc.) or in a private cloud using a Virtual Infrastructure Manager (such as OpenNebula, Eucalyptus, etc.) through a plug-in driver mechanism that will orchestrate virtual resource allocation.

Claudia has evolved in StratusLab to address the requirements of the Stratus-Lab project, such as the provision and usage of hardware information integration for scalability, scalability and management for grid services, authentication, etc.

Main Interfaces with Other Services/Components

Claudia, as service manager, can interact with other Cloud providers, like Open-Nebula by using an aggregated API, this is the TCloud API. Thus, Claudia can deploy networks or virtual machines. Moreover, other components can interact with Claudia by also using TCloud. Monitoring systems provide monitoring events to Claudia for scalability.

Internal Composition

The main component in Claudia is Clotho, which includes the Service Lifecycle Manager (which handles service application instantiation and management of services) and the Scalability and Optimization Module (responsible for managing monitoring events and scalability rules). In order to interact with cloud providers, there is an aggregated API implementation, which provides the translations to the cloud providers' APIs. This is an implementation of the TCloud API, aimed to serve as an interface for cloud systems based on Claudia's Service Lifecycle Manager. This application is modular, so it can be tailored to work with any other provider of TCloud services, by creating and using a customized driver.

Main Interfaces with Other Services/Components

This is a python application, developed from scratch in StratusLab, which it is integrated with the the System Administrator Command Line Client (see chapter 16) for manual installation. It also interacts with the TCloud client for invoking Claudia API and instantiating services, undeploying and so on.

License

Apache 2.0.

User Dashboard

Overview

The user dashboard allows end-users to monitor their virtual machines, and eventually control them. This dashboard requires authentication such that users only see their own resources (e.g. virtual machines, virtual disks).

Main Interfaces with Other Services/Components

The user dashboard interfaces with the monitoring service, for monitoring, and eventually with the control services (e.g. VM manager, persistent service, network service).

Internal Composition

Different options exist for this implementation of this web application.

1. The dashboard can either extends the current web monitor, which is a simple set of CGI scripts implemented in Python. This extended functionality builds on the existing logic of the core of the command-line clients (end-user and system administrator tools).

2. Extend the OpenNebula Sunstone application to cover the other StratusLab services, such as network manager, persistence storage and image management.

3. Simply provide javascript-based monitor that interacts directly with the different services (including monitoring).

License

Apache 2.0.

Probes

Overview

Monitoring probes are the software, installed in the virtual and/or physical machine, which are responsible for measuring metrics. They are the key component in the data gathering mechanisms of the monitoring system. Monitoring information can be obtained from the virtual infrastructure, physical infrastructure, software metrics or KPIs. There are different monitoring probes specialized for each type of metric, and the data they provide is in different formats and offered though different interfaces. Ultimately, the data collected by the probes are collected and pushed to the collector service. Physical machine probes are installed on the physical machine hosts. These provide the the system monitoring and state transition information required by other services and components to perform their work.

The VM probes, as opposed to the physical machine probes, collect data at the level of the hypervisor, for each virtual machine deployed on the node.

Software probes gather metric information about the software installed in the virtual machine, and are used to monitor this software. For instance, it is possible to measure the number of transactions in a database or the active sessions in a web server.

Finally, the Key Performance Indicators provide metrics related the service, which indicate the status of the service.

Main Interfaces with Other Services/Components

The probes push data to the collector service. This data is then used by several other services to perform their business.

Internal Composition

The physical probes are typically written as Nagios/Ganglia scripts, with dependencies corresponding to the transport and protocol used to push the data to their consumer.

The VM probes are highly dependent on the hypervisor used on the physical nodes. StratusLab standardizes on libvirt and KVM, which reduces complexity and dependencies.

Conclusion

This document describes a complete and ambitious architecture for an IaaS cloud distribution, building on the services provided as part of the v1.0 release delivered in the summer of 2011. From v1.0 to v2.0, incremental versions of the StratusLab distribution will be built and released, providing an increasing amount of the functionality described in this document as well as changes to existing services that improve their robustness and performance.

Given time and resource constraints, the project will concentrate on the most important elements of this architecture; consequently, some elements may be developed during the evolution of the StratusLab distribution after the project ends. It is a roadmap that guides the project's developments to enable to deliver software with relevant cloud functionality. As we realize this architecture, gather further feedback, and investigate new cloud innovations, we may find alternative and potentially better ways of accomplishing our goals and may consequently alter the development priorities and architecture.

3. 1

 1 Architecture Overview . . . . . . . . . . . . . . . . . . . . . 3.2 Service and component decomposition . . . . . . . . . . . . . 4.1 OpenNebula Authentication Proxy Workflow . . . . . . . . . .

Figure 3

 3 Figure 3.1: Architecture Overview

Modified XML-RPC request with authentication information 4. Response from OpenNebula 5. Unmodified response from OpenNebula passed back to user Figure

		User
			Username/Password
	1. Initial XML-RPC		Jetty Plugin
	Request
	2. Authenticate 5 Persistent Disk Service
			user based on
			provided credentials	LDAP
		OpenNebula	Jetty Plugin
	Authentication Proxy
	OpenNebula 3. JAAS Java Authentication and Authorization Grid Authentication Plugin
		Service
	GSI	Grid Security Infrastructure for grid
		credentials
		License	Apache 2
		Git repository stratuslab-authn.git

4.1: OpenNebula Authentication Proxy Workflow

Table 4.1: Dependencies for OpenNebula Authentication Proxy Jetty Java application server XML-RPC Apache implementation of XML-RPC protocol Table 4.2: Relevant Standards for OpenNebula Authentication Proxy

Table 5 . 1 :

 51 Dependencies for Persistent Disk Service

	Jetty	Java application server
	Restlet Java framework for RESTful applications

Table 6

 6

		.1: Dependencies for Registration Service
	Jetty	Java application server
	Restlet Java framework to simplify development
		of RESTful applications

StratusLab v1.0 only supports three networks (public, private and local), which does not provide isolation between virtual machines in the multi-tenancy (multimachine) cloud environment. This component allows each user (or group) to create, manage and remove sets of isolated LANs (VLAN). Additionally this component allows filtering of virtual machine traffic based on simple rules, e.g. TCP ports.

Table 10 .

 10

	1: Relevant Standards for VM Manager
	IEEE 802.1Q Used for network isolation.
	traffic based on simple rules, e.g. TCP ports. These integrate with the Net-
	work Manager service.
	The components provided for building hybrid or federated clouds are described
	as part of the Inter-cloud Connector (Chapter 14). Also, OpenNebula provides
	support for the monitoring and accounting needed in StratusLab.
	This component has been extended by the StratusLab project. Specific func-
	tionality developed to address StratusLab requirements are:
	• VM Management:
	-User groups
	-Access control lists
	-Ganglia information drivers
	-Fault tolerance for virtual machines
	-VM Template repository
	• Image/Volume Management:
	-Improved image management
	-Volume management
	-Caching
	• Network Management
	-New networking model
	-Dynamic firewalls
	-Network isolation
	-Elastic IPs
	See Table 10.1 for the relevant standards supported or used by the VM Man-
	ager.
	10.4 License
	License	Apache 2
	Git repository git://git.opennebula.org/one.git

StratusLab extends OpenNebula through its driver extensibility mechanism. To this effect, StratusLab ships with a number of upgraded/replaced standard driver and scripts. Here is the list of such extensions:

Table 11 . 1 :

 111 Dependencies for OpenNebula Driver/Extensions

	Ruby Ruby version supported by OpenNebula
	Bash Standard scripting language

Table 15

 15

	.1: Dependencies for End-User Command-Line Client
	Python Python language, version greater or equal
	to 2.6

Table 16 .

 16

	1: Dependencies for System Administration Command-Line
	Client
	Python Python language, version greater or equal
	to 2.6

Table 18 . 1 :

 181 Relevant Standards for Service Manager

	TCloud Cloud service API for Claudia
		component
	OVF	Service Manifest Format
	This component has been extended by the StratusLab project. Specific func-
	tionality developed to address StratusLab requirements are:
	• Scalability:
	-New policies for scaling according to grid service requirements
	-Expand/Contract a grid site
	-Deployment of a grid site (including grid services, certificates, scripts)
	-Scalability considering VM metrics
	• Monitoring:
	-Monitoring at service layer
	-Claudia subscription to services KPI values
	• Cloud brokering
	-New Cloud providers drivers
	-Placement Decision Module
	See Table 18.1 for the relevant standards supported or used by the Service
	Manager.
	18.4 License
	License	Affero GPL
	Git repository stratuslab-claudia.git

More information about Usage Record WG (UR-WG) http://www.ogf.org/gf/group info/view. php?group=ur-wg.

StratusLab is co-funded by the European Community's Seventh Framework Programme (Capacities) Grant Agreement INFSO-RI-261552.

License

License Apache 2

Git repository stratuslab-one.git and stratuslab-claudia.git 20 System Administrator Dashboard

Overview

The system administrator dashboard allows system administrators to monitor their infrastructure, both at the level of the physical machines and the level of the virtual machines. Since this dashboard displays data that should be restricted to only site administrators, this dashboard either requires authentication or can only be access from within the organization's network.

Main Interfaces with Other Services/Components

The system administrator dashboard interfaces with the monitoring service.

Internal Composition

The dashboard extends the current web monitor, which is a simple set of CGI scripts implemented in Python. This extended functionality builds on the existing logic of the core of the command line clients (end-user and system administrator tools).

License

Apache 2.0.

License

Probes License

Physical and VM Apache 2.0 Software and KPI Affero GPL

Monitoring

Overview

Every distributed system needs to incorporate monitoring mechanisms in order be able to check the health and performance of the system. This is especially true in cloud services that are governed by Service Level Agreements (SLAs) and so the system needs to be able to constantly check that the level of service adheres to the terms of the agreement. As different types of monitoring information are required (e.g. physical, virtual hardware, software, KPIs), corresponding probes (see Section 22), are available to provide this information. Thus, the monitoring service is a RESTful service providing aggregation of monitoring data for system administrators and end-users consumption.

Monitoring differs from accounting and billing, in that it provides a current, real-time view of the cloud service and its main components and services. In comparison, accounting and billing provides aggregated information, over time, on key items.

Main Interfaces with Other Services/Components

The monitoring service consumes data from the collector service.

Internal Composition

The monitoring service is composed of a set of components:

• Data Collector and Aggregator: It gathers monitoring information from the collector service, aggregating information according to the data model and storing it in the database.

• Monitoring database: This is a database containing history metrics. These metrics are organized according to a data model, including aggregated information, such as service layer or virtual data center layer.

• API: It is the REST monitoring API implementation which allows querying monitoring information. This service will be implemented in the project, although has significant dependencies on other services to provide the complete functionality.

Billing

Overview

The billing service provides consolidated information on the consumption of resources on the cloud. This data includes compute, storage and network resources. The end-users can generate their own billing statement, and the service can send via email, on a regular basis, billing statements. Eventually, the billing service could include SLA violations and/or other byproducts of resource utilization.

Main Interfaces with Other Services/Components

The billing service interfaces with the collector services to retrieve consumption data.

Internal Composition

Like all the web services in StratusLab, the billing service will expose a RESTful web service. In terms of implementation, we are hopeful to be able to reuse results from other projects, such as VENUS-C, in order to reduce development effort.

License

Apache 2.0.


Enhancing Grid Infrastructures with Virtualization and Cloud Technologies Infrastructure Specifications

This document presents the computing infrastructure deployed in the context of StratusLab project, details the configuration of the computing resources used and the commitments made from the project partners to contribute with computing resources in the project. During the first months of operation this infrastructure has already been significantly exploited to deliver the first results towards the project's goals. The OpenNebula virtual management software has been used to install private clouds on different OS platforms. Two pre-production grid sites have been deployed in the private cloud and are used to test the implications of providing grid services in cloud environments. Experience from the deployment and operation of the above sites will help us identify the required tools and procedures for offering grid production sites over computing clouds. Finally the document presents related work, relevant to infrastructure operations, taking place in other projects and initiatives.

List of Figures

Executive Summary

This document presents the computing infrastructure deployed in the context of StratusLab project, details the configuration of the computing resources used and the commitments made from the project partners to contribute with computing resources in the project. This infrastructure is an important tool for the project and provides the resources required for the deployment of the project's private cloud, the provision of grid services on top of this cloud, for performing various tests and benchmarks and for the provision of auxiliary computing services needed internally by the project.

During the first months of operation this infrastructure has already been significantly exploited to deliver the first results towards the project's goals. The Open-Nebula [START_REF]OpenNebula[END_REF] virtual management software has been used to install private clouds on different OS platforms (namely Ubuntu and CentOS). Two pre-production grid sites have been deployed in the private cloud and are used to test the implications of providing grid services in cloud environments. The installations were performed either manually or using the Quattor [START_REF]Quattor Community[END_REF] toolkit. The latter has been also used to implement various proof-of-concepts relating to the management of grid services and of the WNs (Worker Nodes) in particular. A core component of the infrastructure architecture is the appliance repository which is used to host and provide virtual machine images to be used in the context of the above private clouds. A first version of the repository has been deployed and a set of images is available for usage facilitating the fast deployment of gLite [START_REF]Lightweight Middleware for Grid Computing[END_REF] based grid sites.

Taking into account this experience the project is already starting to investigate requirements stemming from the fusion of grid and cloud technologies. For example the impact on grid operations are considered. This is expected to affect the tools and procedure used currently in large scale grid computing infrastructures like EGI [START_REF] Egi | European Grid Initiative[END_REF]. Aspects to be affected are for example the Service Level Agreements of cloud resources, the monitoring tools used in grid operations and the accounting policies applied to grid resource providers and end users.

Finally, the project is keeping an eye to other relevant activities taking place in the context of other national or international projects and initiatives. For instance, CERN has used OpenNebula to virtualize and manage part of its large computing infrastructure used in various experiments. Elasticity of grid sites has been also investigated by INFN in the context of their Worker Node on Demand initiative. Also, NIIF in Hungary has used OpenNebula to deploy a national cloud service, with significant contribution in the development of virtualized storage capabilities. StratusLab has already initiated contact with some of these activities and is aiming to re-use and expand their findings.

Introduction

The StratusLab project started in June 2010 with the goal to investigate the potential benefits and possible implications stemming from the fuse of cloud and grid technologies. This goal is twofold: on one hand grid services can be deployed and provided on top of computing clouds exploiting the inherent capabilities of virtualization, such as the on-demand provision of resources, resource elasticity, remote management and optimal usage of computing resources based on workload demands. On the other hand grids can be extended to offer cloud-like interfaces and thus advanced processing and storage capabilities to the end users. Apparently, in order to pursue the above goals the project should deploy and manage its own physical computing infrastructure.

This document presents the computing infrastructure deployed in the context of of the project's WP5 activity during the first three months of the project. The concrete goals of this infrastructure is:

• to provide a testing platform for the project,

• to demonstrate production use by running grid services with the StratusLab distribution, and

• to host various project services

The document is organized as follows: In Section 3, we detail the technical specifications of the computing resources committed by various partners of the project. During the first three months of operation already there has been significant progress towards the project goals. The operation of this infrastructure has given us a better insight on the implications of deploying and providing private cloud services and their usage for hosting grid sites. A first set of tools and procedures has been set (Section 4) which will further be elaborated in the coming months. Section 5 provides more details on the initial results achieved during the first months of cloud infrastructure setup and operation. The usage of cloud technologies for the provision of grid computing capabilities is a hot topic and is currently being pursued also in other contexts and projects. Awareness of such activities is important for StratusLab in order to avoid duplicated effort and also investigate the possibilities of collaborations. The most significant of these activities are briefly presented in Section 6.

Physical Infrastructure

One of the main goals of the StratusLab project is the installation and provision of a computing infrastructure, able to efficiently host cloud computing services, capable of hosting production level grid computing sites. Apart from that many of the service and research activities of the project will require computing resources for various purposes: hosting of development and collaboration tools, testing, benchmarking etc. In this section we describe the computing resources that the partners participating in WP5 have committed to provide, for the aforementioned purposes. In particular we differentiate between the infrastructure committed for hosting of cloud services and the infrastructure allocated for the virtual appliance repository, an integral component of StratusLab toolkit architecture.

Cloud Services

Two sites have been committed to the provision of the required physical infrastructure for hosting the StratusLab cloud distribution. These sites are operated by GRNET and CNRS. The main purpose of this sites is to provide the computing resources needed for the deployment of OpenNebula [START_REF]OpenNebula[END_REF] virtual machine manager which sits at the core of the StratusLab toolkit. At these early stages of the project this infrastructure is used for various test installations of OpenNebula in different platforms. The results of these early tests are presented in more detail in Section 5

GRNET infrastructure

GRNET is a key partner of WP5 being the leader of the activity as well as the provider of the largest part of the StratusLab project computing infrastructure. GRNET is interested to investigate on the emerging paradigm of cloud computing and capitalize on the novel capabilities related to the efficient infrastructure management and on-demand provision of elastic computing capabilities, which is an integral part of cloud computing. For this reason GRNET has constructed a new datacenter dedicated to cloud computing applications. The datacenter is located in the central building of the Ministry of Education (YPEPTH), is equipped with cloud-optimized hardware and is used for various activities related related to cloud services either in a research or production level. A subset of this infrastructure has been allocated for the purposes of StratusLab and is described in detail in following paragraphs. The topology of the datacenter is depicted in Figure 3.1

Computing hosts

On the GRNET infrastructure, 26 physical hosts have been assigned for use by StratusLab, organized in two separate computing clusters. All nodes are Fujitsu RX200S5 1U rack servers, with 2 quad core Xeon 5500 series with the ability to run 2 threads per core through hyper-threading. The nodes reside inside the same rack ensuring optimal communication latencies. In total the above setup provides 208 physical cores, which are able to host a maximum of 416 single-core virtual machines. Each node has 48 GB of RAM, allowing for high performance VMs that can cope with memory intensive workloads. Each host is also provided with a 146 GB HD SAS 3G hard disk, for hosting the OS root and for the VM cache space.

Storage

Storage is provided by an EMC Cellera NS-480 Cloud/NS-480 storage server. The total capacity of the system is 280 TB. From them, 20 TB have been initially been allocated for the requirements of StratusLab infrastructure, made available through NFS over the resident networking infrastructure. Alternative file access protocols will also be investigated (e.g. iSCSI).

Network

The Networking infrastructure consists of 3x10 GbE (Gigabit Ethernet) switches. Each of the physical hosts has 3 GbE interfaces plus a management interface for access through IPMI. The relevant traffic (host/VM/IPMI management) is isolated using separate VLANs. The connectivity between the servers rack and the storage server is provided by a fiber channel bridge which connects the 2x4 Gb FC storage link with the 10 Gb servers link.

The datacenter is connected through 2x10 GbE links with the GRNET network backbone. GRNET is the Greek NRN (National Research Network) offering data connections up to 10 GbE with the GEANT network.

Management software

The nodes' management is accomplished through IPMI, using either a web or command line interface. Host OS installation on the nodes is automated through PXE. A central management server provides the host OS repository (currently Debian Lenny, Ubuntu 10.04 and CentOS 5.5) for network installation and a DHCP server for host IP address allocation. Monitoring of the physical nodes is provided using Ganglia scalable distributed monitoring system.

CNRS infrastructure

CNRS/LAL is the second resource provider in WP5. LAL will offer a cloud test bench for testing the installation and performance of the StratusLab cloud distribution. Once the StratusLab cloud distribution is stable, LAL will gradually migrate its production grid infrastructure to it, starting with the grid Worker Nodes and progressing to other services as confidence increases. Although technically not part of WP5 activities, the Institut de Biologie et Chimie des Protéines (IBCP) will also run a test bench and production infrastructure over the StratusLab distribution.

Computing Hosts

The test bench at LAL currently consists of five 1U, rack-mounted machines. These are dual processor IBM x3550 machines with Intel E5345, 2.33 GHz, 4 core processors for 8 cores in total. Each machine has 16 GB of RAM and 150 GB of local disk space. These machines allow hardware virtualization; correspondingly, LAL has decided to use KVM [START_REF]KVM: Kernel-based Virtual Machine[END_REF] as our standard hypervisor technology. Although acceptable for deployment and small-scale tests, the test bench will have to grow to accommodate larger and more diverse tests. Internal funding requests have been made to double the size of the test bench.

Storage

A Storage Area Network (SAN) provides large-scale storage, accessible to all machines at LAL, including specifically all of the grid and cloud machines. A DDN 6620 connects to controllers via double Fibre Channel connections. The controllers are then connected to the LAL's primary network switch via 10 Gb/s connections.

Currently, the cloud test bench has no allocated storage; however, internal fund-ing requests have been made for providing dedicated storage for the StratusLab activities. Regardless of the outcome of those requests, an allocation of 5-10 TB from the current storage resources can be easily and immediately provided when the need arises.

Network

All of the machines connect to the local network via 1 Gb/s network connectors. Typically each rack of machines has a dedicated network switch, operating at 10 Gb/s, which is in turn connected to the wide area network by RENATER [START_REF] Renater | [END_REF].

The cloud machines have a dedicated range of IP addresses which are isolated from other nodes at LAL with a VLAN. RENATER currently provides a 10 Gb/s link which is shared by LAL and several other surrounding laboratories. The network supports teaching and research activities in France; current policies prohibit commercial use of the network.

Management Software

LAL uses the Quattor Toolkit [START_REF]Quattor Community[END_REF] to manage all of the machines in the LAL machine room as well as the services provided by those machines. Quattor permits centralized, shared management of the installation, configuration, and maintenance of a large number of machines. As for all other machines and services, the cloud test bench is installed, configured, and maintained via Quattor. This demonstrates the compatibility of the StratusLab distribution with automated site management tools and serves as a continuous verification of that compatibility as the StratusLab distribution evolves.

Virtual Appliances Repository

An Apache web-server, hosted by Trinity College Dublin (TCD), provides the initial virtual appliances repository. The web-server is accessed using WebDAV (Web-based Distributed Authoring and Versioning), with authentication via the StratusLab central LDAP server. A single virtual machine is used to host the webserver, with an initial storage allocation of 200 GB. As the number of appliances increases, and the average size of appliance is better known, this allocation will be reviewed and increased as required.

Support Services

To maintain core support services, a host similar to the computer nodes has been allocated for use by the project. Currently, this server runs the Hudson integration server, and has the same management and monitoring utilities as are available for the computing hosts (outlined in Section 3.1.1). More services can be collocated or supported on new hosts as the need arises, as GRNET's infrastructure provides the flexibility and processing power necessary for the project's purposes.

Tools and Procedures

Operation of a large scale computing infrastructure requires the utilization of a number of specialized tools and the establishment of a set of formal procedures for the provision of the underlying computing resources. Typically in a grid environment these tools and procedures are imposed by a centralized authority responsible for their definition, installation and proper operation. For example in the context of EGI, all sites have to adhere to a specific Operational Level Agreement (OLA) for what concerns the availability of the site's resources. Also the sites have to install a specific set of monitoring clients in order to enable centralized visual monitoring of the sites status for the various provided services. Obviously, the grid sites installed in the context of StratusLab, once scheduled for going through the official certification process defined by EGI, will adopt the set of tools and procedures that will be put in place by the organization.

On the other hand, for what concerns the cloud services, no standardized process or tools are available, and no specific SLA has to be followed. All these will be one of the main outcomes of WP5 activity. Indeed, the above will be one of the main subjects of Deliverable D5.2 scheduled for M6 of the project. Meanwhile, the activity has adopted some simple procedures for the provision of infrastructure services. For the time being such services are available only internally to the project members. Project members can apply for a certain resource (e.g. a physical node, storage, a VM running a specific image, the creation of a specific image, the setup of a grid site) by simply sending an email to WP5.

As mentioned in the previous section, a set of tools is already in place and are used for managing the infrastructure on the physical level, and the monitoring of physical hosts. These tools in some cases have been imposed by the vendor (e.g the online monitoring offered by the Fujitsu servers) and in other they have been selected due to their popularity (e.g. Ganglia [START_REF]Ganglia Monitoring System[END_REF] for host status monitoring, Nagios [START_REF] Nagios | The Industry Standard In Open Source Monitoring[END_REF] for overall system monitoring and service availability). In the coming months the evaluation of more operational tools will be intensified in order to cover all aspects of infrastructure service provision.

For what concerns Service Level Agreements in particular, obviously it is very pre-mature to consider it this moment. A simple approach will be for cloud services to offer such a level of service that will enable the provision of grid sites that can satisfy the EGI OLAs. This rather generic requirement can serve as a good starting point. Certainly the provision of cloud services has much more implications com-paring with a grid site where site availability is the main metric for assessing the site's quality.

For example in the context of EGI two are the basic metrics used to ensure the adherence of a certain site to the OLA: Site Availability and Site Reliability. The first metric refers to the percentage of time the the site is on-line and available. The former metric reflects the percentage of jobs submitted to the site and complete successfully. Certified grid site should demonstrate at least 70% availability and 75% reliability in order to retain their operational status.

In cloud environments we will consider additional metrics for SLAs such as:

• Availability and reliability of VM hosting environments and virtualized data storage

• Minimum time between requesting a VM instantiation and the time the VM is available

• Overall availability of service for accessing through the relevant cloud API Security of data is also crucial in a cloud environment. Thus, SLAs should cover provisioning of security services, like encryption of data (with a choice of cryptographic algorithm strength used) and overall data integrity.

Preliminary Results

Activity has already started for the various tasks of WP5. In the paragraphs we report on the preliminary findings and the early results already available from these activities.

Installation of OpenNebula

Once the physical infrastructure was put into place it was decided that the activity should start exploiting the capabilities of offered cloud services using the current version of various StratusLab components and in particular of OpenNebula which is the core of the project's distribution. For this purpose two clusters have been installed in the GRNET infrastructure. Namely, an Ubuntu-based cluster and the CentOS-based cluster, each of them consisting of eleven physical nodes. The choice of Ubuntu Server 10.04 and CentOS Operating Systems for the clusters, amongst the ones supported by OpenNebula, was based on their popularity for use in datacenters and ease of use. There is an OpenNebula 1.4 deployment on each cluster.

The procedure of the OpenNebula installation was more or less the same for both clusters. The option of building from source seems to be the most appropriate. In both clusters the first node is the OpenNebula front-end node, where the management of the Virtual Machines (VMs) takes place, and the rest are added as host nodes in the private cloud. OpenNebula uses virtualization drivers to create, control and monitor VMs on the cluster nodes and offers support both for Xen and KVM (Kernel-based Virtual Machine) virtualization technologies. Both clouds were configured to use KVM, taking into consideration the facts that beta support is provided under Ubuntu and CentOS and that KVM is under active development. The management of the VM images is handled by transfer drivers that are used to transfer, clone, remove and create images. If the option of saving a VM image when the VM is stopped is enabled, the modified image is saved, so that in subsequent uses of the VM any configuration done or data stored in it are available. The decision for which of the transfer drivers to use is made according to the storage configuration of the cluster. The available options for the storage configuration are shared using NFS, non-shared using SSH and LVM (Logical Volume Manager) storage model. In the shared arrangement the cost of copying the images between the nodes of the cluster is minimized and allows live migrations of virtual machines between the host nodes. In the non-shared case, the images are copied to host nodes through ssh and are transferred back on the front-end node if the option of saving the VM image is enabled. The LVM (Logical Volume Manager) storage model is not fully supported and needs to be configured for the specific use case, however it provides the snapshot feature which instantly creates disk devices that can be assigned to the VM. At the moment the ssh transfer driver is used, but that will change to using NFS, as it is more effective. In addition OpenNebula provisions for the creation of virtual networks, in order for the virtual machines to acquire network access.

There are two virtual networks defined for each cloud deployment, a private and a public one. The mapping of the virtual networks on top of the physical ones is done by a network bridge set up over the physical public network of the cluster nodes. All virtual networks used are fixed, which means that a fixed set of IP-MAC pair of addresses is defined for the virtual machines.

LAL uses the Quattor Toolkit for the automated installation, configuration, and management of machines. To ensure that the cloud test bench at LAL can be similarly managed, LAL has developed Quattor configuration components for OpenNebula (ncm-oned) and for libvirt (ncm-libvirtd). In addition, a complete set of configuration templates have been developed to allow an entire OpenNebula system (front-end and hosts) to be installed automatically from bare metal. Documentation (http://stratuslab.eu/doku.php?id=quattorinstall) on the StratusLab internal wiki explains how to use the configuration as well as the current limitations.

Grid Services on Virtual Resources

Two grid sites have been deployed on top of the respective cloud sites in GRNET's infrastructure, using the above pre-configured images. The first site, named GR-42-STRATUSLAB (GR-42 for short), comprises of a CE, SE and 2 WNs. The second site, named GR-43-STRATUSLAB (GR-43) comprises of a CE, SE and 5 WNs. Both sites are in pre-production phase and are monitored by the SAM-tests (Service Availability Monitoring) running in NGI-GRNET (https://sam.athena. hellasgrid.gr). Both sites support MPI (MPICH2 and OpenMPI). Currently they don't provide shared folders among the WNs and the execution of MPI code is facilitated with the usage of MPI-START [START_REF]MPI-Start[END_REF] tool.

For the deployment of grid sites over OpenNebula, we generated pre-configured images for each type of Grid node, i.e. CREAM (Computing Resource Execution And Management) Computing Element (CE), Storage Element (SE), Worker Node (WN) and User Interface (UI), using the gLite middleware version 3.2. The pre-configured images are running Scientific Linux 5.5 with all the appropriate packages of glite installed according to the grid node type. By creating a virtual machine with a pre-configured image for e.g. a Computing Element node, a fully functional Computing Element grid node is created. The configuration of the node using the yaim tool is done by a script that needs to be run once the virtual machine is up.

On LAL's site, the Quattor Toolkit is used to bootstrap machine installation via PXE. LAL has verified that PXE images can be started via OpenNebula and that they can be used to install grid Worker Nodes via the standard Quattor installation mechanism. This is a first indication that automated site management tools can be used with little or no modification to control grid services running on a StratusLab cloud infrastructure.

Virtual Appliances Repository

The initial prototype of the virtual appliance repository is deployed as a WebDAVenabled Apache webserver. The repository is intended for use by both system administrators and end-users. StratusLab tools that interact with the repository have already been developed and are in active use. It is possible to customize an image and subsequently upload the resulting appliance to the repository using a single command-line tool. Appliances can be retrieved during deployment simply by specifying the URL of the required appliance contained in the repository.

Currently only a limited number of base OS images are available in the repository. This will be extended to include pre-configured appliances with core grid services, such as Computing Element and Storage Element. It is expected that the availability of these appliances will significantly simplify the task of grid site setup for system administrators.

A limitation of the initial service is that upload and download of appliances is only possible through the use of standard tools such as cURL [START_REF] Haxx | cURL[END_REF]. The use of Maven as a front-end for uploading/downloading appliances from the repository is to be evaluated, and it is for this reason that the structure of the repository has been designed to mirror that of a Maven repository. Appliances are organized by type and operating system, for example:

grid | -ce | -sl-5.5-x86_64-grid.ce | -1.0 | -sl-5.5-x86_64-grid.ce-1.0.img
Although initial tests using Maven have proven unsuccessful with the large file sizes of the currently available appliances, use of this technology is desirable, and further testing is planned.

Related Activities

In this section, we describe relevant European activities which are good candidates for collaboration with StratusLab. They are also good candidates for being early adapters of the StratusLab distribution, since they also deal with grid-over-cloud provisioning.

CERN

CERN is experimenting with various VM provisioning systems in order to build its own private cloud. In the lxcloud [START_REF]Details of CERNs OpenNebula deployment[END_REF] project, OpenNebula (ONE), along with various other commercial solutions are used to manage a large number of hardware resources. The high level architecture of lxcloud is presented in Figure 6.1. In the current setup, ONE is installed on 500 servers, and each server has 8 CPUs, 24GB of RAM and two 500GB hard disks. Concerning scalability, ONE was able to easily manage up to 8.000 concurrent virtual machine instances. What is more, ONE scheduler was able to dispatch virtual machines at a high rate of around 1 VM per second (machines were pre-staged in the file systems of the host machines). Currently, lxcloud virtual machine images are replicas of lxbatch worker nodes (batch cluster at CERN). Each dispatched virtual machine joins the batch cluster and accepts a part of the total workload. According to the size of the batch queue, virtual machines are initiated or destroyed.

Since lxcloud is also using the ONE platform, it could benefit from the automatic creation and maintenance of grid sites that StratusLab offers. Therefore, the lxcloud project is a perfect candidate for collaboration with StratusLab.

BiG Grid

The BiG Grid project [START_REF] Grid | the dutch e-science grid[END_REF] (led by NCF, Nikhef and NBIC) aims to set up a grid infrastructure for scientific research. This research infrastructure contains compute clusters, data storage, combined with specific middleware and software to enable research which needs more than just raw computing power or data storage.

The BiG Grid project, through its Virtual Machine working group, is investigating the use of fully virtualized grid sites. In a recently published report [START_REF]BiG Grid Virtual Machine working group progress report[END_REF], the results of the group's feasibility study to provide virtualized worker nodes on BiG Grid resources are briefly presented. After a thorough examination through numerous use cases such as High Energy Physics or Bioinformatics applications, the What is more, the group has decided to create a number of "precooked" virtual machine images that could be used to automatically create a grid site. Therefore, the BiG Grid project could benefit from the StratusLab results that have to do with the automatic setup, deployment and configuration of grid sites through the use of OpenNebula technologies.

D-Grid

The D-Grid Resource Center Ruhr (DGRZR) (http://gridatdortmund.blogspot. com/) was established in 2008 at Dortmund University of Technology as part of the German Grid initiative D-Grid (http://www.d-grid.de/index.php?id=1&L=1). Different from other grid sites, the DGRZR has utilized virtualized resources from the beginning of its operation.

DGRZR consists of 256 HP blade servers with eight CPU cores (2,048 cores in total) and 1 GB RAM each. The disk space per server is about 150 Gigabytes. Half of this space is reserved for virtual machine images. Physical servers run SUSE Enterprise Linux (SLES) 10 Service Pack 3 and will be changed to SLES 11 in the near future. D-Grid users are provided with roughly 100 terabytes of central storage, mainly for home directories, experiment software and for the dCache grid Storage Element. In 2009, the mass storage was upgraded by adding 25 TB of HP Scalable File Share 3.1 (a Lustre-like file system). Typically, 250 of the 256 blade servers will typically be running virtual worker nodes. The remaining servers run virtual machines for the grid middleware services (gLite, Globus Toolkit and UNICORE), the batch system server, and other management services.

In 2010, DGRZR was extended by the installation of OpenNebula as the cloud middleware to manage its virtual machines as a private cloud [START_REF]OpenNebula at the D-Grid Resource Center Ruhr[END_REF]. In Figure 6.2 the DGRZR OpenNebula architecture is summarized. StratusLab could collaborate with DGRZR and provide its technical knowledge in building fully automated grid sites using virtualization technologies.

INFN Worker Nodes on Demand Service

The INFN (National Institute of Nuclear Physics -http://www.infn.it/indexen. php) is an organization dedicated to the study of the fundamental constituents of matter, and conducts theoretical and experimental research in the fields of subnuclear, nuclear, and astroparticle physics.

INFN is currently developing a service called WNoDeS (Worker Nodes on Demand Service) [START_REF] Salomoni | Gridification of a cloud infrastructure through virtualization technologies and related security challenges[END_REF] in order to provide on demand grid worker nodes through a cloud computing management tool. The overall architecture of WNoDeS is presented in Figure 6.3. WNoDeS is build around a tight integration with LSF [START_REF]Platform. Load Sharing Facility (LSF)[END_REF] and is running in production at the INFN Tier-1 Computing Center. It currently hosts 4,000 on-demand Virtual Machines, O(10) supported Virtual Images, serving 20 different user communities; on average, more than 20,000 jobs are executed each day through WNoDeS. Its main characteristics are: • On-demand virtual resource provisioning and VLAN support to dynamically isolate Virtual Machines depending on service type / customer requests.

• Support for users to select and access WNoDeS-based resources through grid, cloud interfaces, or also through direct job submissions.

INFN's WNoDeS project is also a good candidate for collaboration with Stra-tusLab, as they both deal with grid-over-cloud technologies.

Hungarian National Initiative in NIIF

NIIF (http://www.niif.hu) is the Hungarian NRN. In the context of a national cloud project, NIIF has investigated the capabilities of deploying large-scale cloud infrastructures using OpenNebula middleware. At the end of this one year project, NIIF achieved to deliver some very interesting results especially related with the storage management over clouds. During this process NIIF also contributed to the OpenNebula development in the above area of storage management. StratusLab has already made contacts with NIIF with the potential to reuse the findings for the above mentioned project and generally collaborate in various levels.

Conclusions

The StratusLab computing infrastructure is an important tool in order to successfully pursue the various goals of the project. During the first months of execution the project managed to deploy a significant number of computing resources committed by two partners (CNRS an GRNET). A third partner (TCD) has allocated storage resources and is providing a first version of the appliance repository, hosting virtual machine images to be used in the project private cloud. Table 7.1 summarizes the resources currently committed for the infrastructure.

This infrastructure has already started delivering results. Two pre-production grid sites have been deployed with support for parallel MPI applications. These sites are used for testing and benchmarking purposes. In various cases, the Quattor toolkit is used to manage the deployment of cloud sites as well as the dynamic management of Worker Nodes (WNs) in grid sites.

The operation of grid sites in production environments are expected to impose new requirements for what concerns monitoring, management and accounting tools as well as procedures for the provision of such services. The project is already considering these implications and will further elaborate on them in the context of Deliverable D5.2 planned for month M6 of the project.

StratusLab is wishing to capitalize on the work done in related projects and activities in the area of virtualized grid services and the utilization of cloud computing for hosting production level grid sites. The project has a already identified a number of significant activities in this area, and in some cases has made first contacts seeking further collaboration. More results are expected to come available towards this direction during the lifetime of the project and as the relevant requirements are slowly becoming clearer and concrete.

Figure 3 . 1 :

 31 Figure 3.1: Bird's eye view of GRNET's infrastructure

Figure 6 . 1 :

 61 Figure 6.1: High level architecture of lxcloud

Figure 6 . 2 :

 62 Figure 6.2: OpenNebula at D-Grid Resource Center Ruhr

Figure 6 . 3 :

 63 Figure 6.3: WNoDeS overall architectural framework

  3.1 Bird's eye view of GRNET's infrastructure. . . . . . . . . . . .

6.1 High level architecture of lxcloud . . . . . . . . . . . . . . . . 6.2 OpenNebula at D-Grid Resource Center Ruhr . . . . . . . . . 6.3 WNoDeS overall architectural framework . . . . . . . . . . . .

Table 7 . 1 :

 71 Committed resources per partner

	Resource	GRNET CNRS	Total
	Computing nodes	26	5	31
	CPU Cores	208	40	248
	Storage	20 TB	5-10 TB 25-30 TB

StratusLab is co-funded by the European Community's Seventh Framework Programme (Capacities) Grant Agreement INFSO-RI-261552.

The information contained in this document represents the views of the copyright holders as of the date such views are published.

List of Tables