Project Full Title:
Cloud based Simulation platform for Manufacturing and
Engineering
Project Acronym: CloudSME
Project Number: 608886
Programme: Cooperation
Themes: Information and Communication Technologies; Nanosciences, Nanotechnologies, Materials and new Production Technologies - NMP
Call Identifier: FP7-2013-NMP-ICT-FOF (“Factories of the Future”) Funding Scheme: Collaborative Project
Start date of project: 01/07/2013 Duration: 30 months
Deliverable:
D5.1 Academic and commercial IaaS cloud services
Due date of deliverable: 30/09/2013 Actual submission date: 30/09/2013 WPL: SZTAKI
Dissemination Level: PU Version: 1.2
1 Table of Contents
1 Table of Contents ... 2
2 List of Figures and Tables ... 3
3 Status and Change History ... 4
4 Glossary ... 5
5 Introduction ... 6
6 Cloud Resources ... 6
6.1 Academic Partners... 6
6.1.1 BIFI Cloud ... 6
6.1.2 SZTAKI Cloud infrastructures ... 11
6.1.3 The University of Westminster Cloud ... 14
6.2 Commercial Partner ... 17
6.2.1 CloudSigma ... 17
6.3 Commercial cloud service rental ... 22
6.3.1 Cloud adapters in the CloudBroker Platform ... 22
6.3.2 Amazon Web Services ... 22
6.3.3 IBM SmartCloud Enterprise ... 23
6.3.4 Integration of other clouds into the CloudBroker Platform ... 23
6.3.5 Service level agreements ... 23
2 List of Figures and Tables
Figures
Figure 1 - Architecture of the preproduction UNIZAR-BIFI cloud ... 6
Figure 2 - Horizon OpenStack grizzly dashboard to manage VMs and storage in the cloud .. 7
Figure 3 - Architecture of the production UNIZAR-BIFI cloud ... 8
Figure 4 - Zabbix Map of BIFI cloud resources ... 9
Figure 5 - Cores and RAM used by different nodes ... 10
Figure 6 - Total used and free cores in the cloud infrastructure ... 10
Figure 7 - Progress of the startup of VMs ... 10
Figure 8 - Architecture of the LPDS cloud ... 11
Figure 9 - Architecture of the SZTAKI cloud ... 12
Figure 10 - Monitoring the CNs and the number of the running VMs ... 12
Figure 11 - Number of running VMs ... 13
Figure 12 - Power Consumption / VM ... 13
Figure 13 - Cloud Dashboard at SZTAKI LPDS... 14
Figure 14 - Architecture of the UoW cloud ... 15
Figure 15 - Qualys monitoring ... 16
Figure 16 - Investigating the test results ... 16
Figure 17 – The CloudSigma stack ... 18
Figure 18 – The CloudSigma dashboard to manage VMs and storage in the cloud ... 19
Figure 19 – Zabbix data centre deployment example, as deployed in CloudSigma ... 21
TablesTable 1 - Status Change History ... 4
Table 2 - Deliverable Change History ... 4
Table 3 – Glossary ... 5
3 Status and Change History
Status: Name: Date: Signature:
Draft: Sandor Acs 27/09/2013 n.n. electronically
Reviewed: Rubén Vallés 27/09/2013 n.n. electronically
Approved: Stephen Winter 30/09/2013 n.n. electronically Table 1 - Status Change History
Version Date Pages Author Modification
0.1 09/09/2013
All
section SA First draft version
0.2 10/09/2013
Section
6.1.2 SA
Documentation of SZTAKI cloud infrastructures added
0.3 18/09/2013
6.3 and related
sections DK, WS
Addition of CloudBroker and ScaleTools contributions
0.4 20/09/2013
Section
6.1.3 DFF Draft of UoW related part added 0.5 23/09/2013
Section
6.1.1 RVP Addition of BIFI Cloud related section 0.6
23/09/2013
Section
6.1.3 DFF Improved documentation on testing 0.7 26/09/2013
Section
6.1.1 RVP
New monitoring graphs and description added.
1.0 26/09/2013
ALL
section AS Technical improvements (typo and layout) 1.1 27/09/2013
ALL
section RVP Internal Review
1.2 27/09/2013 6.2 AG Addition of CloudSigma related part Table 2 - Deliverable Change History
4 Glossary
AWS Amazon Web Services
CN Compute Nodes
DNS Domain Name System
EC2 Elastic Compute Cloud FTP File Transfer Protocol IaaS Infrastructure as a Service KVM Kernel-based Virtual Machine OCCI Open Cloud Computing Interface PaaS Platform as a Service
QoS Quality of Service
S3 Simple Storage Service
SaaS Software as a Service SLA Service Level Agreement
SSH Secure Shell
VLAN Virtual Local Area Network
VM Virtual Machine
VPS Virtual Private Server
ZABBIX An enterprise-class open source software for monitoring of networks and applications.
5 Introduction
The WP5 will set up the cloud simulation test bed and the prototype simulation platform. It will integrate the academic and commercial clouds provided by the project partners, and it will enable access to further cloud resources via the CloudBroker access platform.
This deliverable will incorporate a report and cloud resources. The report will describe the established university and commercial IaaS cloud services and their operational parameters.
6 Cloud Resources
6.1 Academic Partners
6.1.1 BIFI Cloud
BIFI contributes with two different infrastructures to the CloudSME project.
A very small preproduction one, which will only be used as a testbed for new releases and testing unstable features which could disturb the normal operation of the infrastructure. This will be composed by three servers, a central one containing the core services and two computing nodes which will host the virtual machines.
The characteristics of the physical nodes used by the virtual machines are:
1 x HEAD NODE + 2 x computing nodes with CPU: Dual quadcore (Intel(R) Xeon(R) CPU E5520 @ 2.27GHz) Memory: 16GB RAM Storage : 250GB per node.
The production testbed is currently formed by 4 servers and 36 computing nodes which host 482 cores in total.
Computing: The description of each computing node is as follows:
CPU: Dual Hexacore ( Intel(R) Xeon(R) CPU X5650 @ 2.67GHz)
Memory: 24 GB RAM
Storage 500GB
- The OpenStack release is Grizzly and the hypervisor to manage VMs is KVM. Storage:
Object storage based on CEPH has already been deployed counting with 5TB SATA from iSCSI cabin. It is compatible with SWIFT interface and it is being tested its S3 compatibility.
Block Storage Networking:
Inbound and outbound network connectivity is 1Gb. Interfaces:
OpenStack API
Compatible with EC2 API
SWIFT storage API
S3 API compatibility in testing phase
Horizon OpenStack dashboard
Figure 2 - Horizon OpenStack grizzly dashboard to manage VMs and storage in the cloud
Opposed to the preproduction testbed which is only for testing purposes, the production one has been deployed with High Availability using multihost OpenStack option.
As it can be seen in Figure 3, all the computing nodes have their own public IP and thus internet conectivity, so in the case of a host failure only the virtual machines inside that node
will be affected. With the previous version, in which a central node was the network gateway for all the virtual machines, it was a bottleneck and a single point of failure.
Figure 3 - Architecture of the production UNIZAR-BIFI cloud
BIFI manages its monitoring tool based on Zabbix, which allows a fine grained check of the computing resources.
Zabbix provides a lot of different sensors out of the box allowing you to send alarms when something is not working properly (CPU overloaded, machine running out of RAM or hard disk is getting full etc. ).
Furthermore, the great power in cloud management comes with the easiness to define new triggers to monitor whatever measure you can get from your system or the services that are running in your system.
Here you can find different graphics which monitor the usage and the health of the cloud infrastructure.
Figure 5 - Cores and RAM used by different nodes
Figure 6 - Total used and free cores in the cloud infrastructure
Testing
In this first deployment phase, although we do not have yet a global tool in the project to test the infrastructure, local tests have been carried out in our site to check:
Cloud computing resources
Cloud storage ( block storage via iscsi and object storage via SWIFT )
VMs deployment and management
Network ( internal and external connectivity ).
Continuous monitoring which performs periodic tests of the most critical triggers for the correctness of the cloud infrastructure.
6.1.2 SZTAKI Cloud infrastructures
SZTAKI contributes with resources of two different cloud infrastructures to the project: the LPDS cloud (local to the Laboratory of Parallel and Distributed Systems), and the SZTAKI cloud, that can be used on demand to extend the available capacities when needed.
The LPDS Cloud
Figure 8 describes the current LPDS production cloud infrastructure. It consist of a front-end machine, 2 storage servers, 10 cloud nodes (for hosting virtual machines (VMs)), a switch and networking. This Infrastructure-as-a-Service (IaaS) can provide 176 CPU cores and more than 32 TB storage for its users. We use OpenNebula 4.2 for managing the cloud (CPU, storage, network) and KVM for the virtualization in the node machines.
The SZTAKI Cloud
Figure 9 presents the current SZTAKI cloud infrastructure that has a 2 fully redundant front-end machine, 2 storage servers, 7 cloud nodes (for hosting virtual machines (VMs)), two switches and redundant networking. This Infrastructure-as-a-Service (IaaS) can provide 448 CPU cores and about 100 TB storage for its users. OpenNebula 3.8.3 is used for managing the cloud (CPU, storage, network) and KVM for the virtualization in the node machines.
Total:
7 Cloud Node (hosts) 448 CPU cores 1792GB RAM 66TB shared and 35 TB local storage Softwares: OpenNebula 3.8.1 KVM (based virtualization) Available interfaces: OCCI
EC2 compatible interfaces SunStone WEB frontend
Figure 9 - Architecture of the SZTAKI cloud Monitoring, testing and maintenance
SZTAKI maintains its cloud infrastructures in production level and uses ZABBIX for monitoring purposes.
Figure 10 shows that ZABBIX provides current information about the physical infrastructure (e.g network, compute nodes, etc).
Figure 11 - Number of running VMs
Figure 12 - Power Consumption / VM
In the SZTAKI, we monitor the power consumption of infrastructure elements (e.g servers, storages, switches) and we estimate the power consumption per VM as well. Active testing mechanism will be implemented in the next period of the project.
Availability
The SZTAKI infrastructures are up and running as the already presented charts and Figure 13 shows.
Figure 13 - Cloud Dashboard at SZTAKI LPDS
These infrastructures are available at http://cfe2.lpds.sztaki.hu and at http://cloud.sztaki.hu. SZTAKI resources are reliable and may provide high availability (~99,5%), however this infrastructure do not guarantee SLA like commercial cloud providers. It works on best effort basis.
6.1.3 The University of Westminster Cloud
The University of Westminster operates an IaaS (infrastructure as a service) cloud computing cluster intended for research use and teaching services provision. The cluster is an OpenStack Folsom based infrastructure. The underlying software is based on LibVirt as virtualizing API and KVM as hypervisor technology. This technology has been proven to be stable for several years and has become one of the virtualization standards in the industry and the academy sectors.
Managing is done using the concept of tenants or projects defined by the cloud administrator, each tenant can use a defined number of resources set by the administrator. These resources include number of CPUs, GB of RAM memory, disk space and Public IPs. Users manage the cloud resources either via EC2 and S3 APIs (Amazon compatible), NOVA API or Horizon web interface. Security is based on security groups that isolate the cloud instances (virtual machines running) from each other based on the users and/or project they belong to. Inside each project, users can also define their own firewall rules and as many security rules as the administrator has defined for them.
Computer force is based on 5 Dell C6105 doing a total of:
• 160 CPUs (AMD Opteron 4122 Processor (2.2GHz, 4C, 4x512K L2/6M L3 Cache, 75W ACP), DDR3- 1333MHz).
• 1920GB RAM memory (Dual Rank LV RDIMMs 1333MHz) Storage force is based on:
• 5 TB RAID1 based, local storage, 40 x (SATA 7.2k 2.5" HD Hot Plug)
• 12 TB RAID1 based, (PowerVault MD3620i External 10Gb iSCSI + PowerVault MD1220 Base extension)
Networking is based on:
• PowerConnect 8024F 10GbE optical fibre switches for vlan and storage connectivity. • Standard 100M ethernet switches for administration and live migration purposes.
Figure 14 - Architecture of the UoW cloud Testing procedures and results
The cloud testing environment is formed from a number of procedures and infrastructures. Currently an external very sophisticated testing tool is used to check every instance routed to the Internet. The name of the tool is Qualys.
Each time a virtual instance is launched, Qualys test it externally and internally. Externally it tries systematically one by one each possible attack discovered to the moment for any particular web or application server/s running on the VPS as Figure 15 and Figure 16 show. This huge test takes long time and use to overload the machine during such time, but lets us ensure there is no any public vulnerability running in the VPS. The check also includes all the typical external services, such as SSH, telnet, FTP, DNS, etc.
Apart from the external check, we also create an account in the VPS and the tool checks every single executable and library, looking for out of date versions with known vulnerability issues.
Once such test are passed we proceed to open the machine to the public on the Internet. Then, we repeat the test regularly to be aware about when we have to upgrade the underlying operative system, tools, libraries, etc.
Figure 15 - Qualys monitoring
On the network side, the whole network is monitored through the firewall alert system. This is a Palo Alto appliance able to discover unusual traffic on the network, differentiate between applications by reading the ip packets, etc. These are not checks that we perform to specific VPS in the net, but a constant check in the entire cloud network.
By using this tool we have successfully identified and stopped two denial-of-service attacks coming from machines in the network, such as an augmenting DNS attack.
There is a third procedure that we also apply to each service running in our cloud. This is a custom functional check that goes point by point checking all the service aspects from the user perspective.
This check is based on the service provider specification and lets us now if there is any problem on the VPS, due to the deployment in the cloud, firewalling, networking, etc.
Using this technique we have identified and reported lots of bugs to the service providers. And also we have identified a few but important number of bugs of the OpenStack cloud environment itself that have been all solved.
This process is feed-backing itself and we are generating better services tests from time to time and also best expertise in cloud operations and networking.
UoW’s testing infrastructure is strong and reliable and every service in its cloud is being considered as a truly production service.
6.2 Commercial Partner
6.2.1 CloudSigma
Stack:
CloudSigma's entire stack runs on a single machine and can be replicated, hence scaled and load balanced virtually infinitely. It requires a database server, which is mirrored off-site for redundancy. It could be compared against CloudStack in the sense that it easily scales and load balances, additionally providing HA. CloudSigma’s stack runs exclusively on KVM. The approach to house the entire stack on a single machine has the benefit of mitigating the failure of a single server housing a specific component of the cloud stack resulting in functionality outages within the stack, as would be the case in OpenStack.
Every instantiated VM is given their own public IP address, making it accessible outside the data centre where it is hosted. Should the CloudStack API server fail completely, despite its HA design, the VMs will be completely unaffected, as they are directly accessible by their public IP addresses.
Figure 18 – The CloudSigma dashboard to manage VMs and storage in the cloud Compute:
A small pre-production compute set-up consisting of a 16 and a 24 core machine, each with 20 GB RAM each is used to test API developments, prior to them being deployed to the production API servers. A single storage node is used in combination with the above nodes. The Las Vegas data centre consists of 19 compute nodes running 24 core Opteron 6174 or 6176 CPUs running at 2.2 GHz with 128 GB RAM each. The total coming to 456 cores and 2432 GB RAM.
The Zurich data centre has 4 of the above compute nodes, as well as 10 compute nodes running 64 core 6380 Opterons at 2.5 GHZ with 512 GB RAM each. The total coming to 736 cores and 5632 GB RAM.
Storage:
CloudSigma’s block storage solution is a mixture of SSD based SolidFire storage boxes, as well as CloudSigma’s Solaris / ZFS based SSD storage boxes, known as Qnez. A total of 68 TB are deployed in the Zurich data centre on the Qnez, with approximately 50 TB deployed in the Las Vegas data centre. The SolidFire storage boxes add another 21 and 27 TB to each respective data centre.
Networking:
CloudSigma have 10 Gbit inbound and outbound connectivity to and from both data centres.
Monitoring:
CloudSigma makes extensive use of Zabbix to monitor their cloud infrastructure. Zabbix can collect data from infrastructure (and other supported components) in 3 ways;
Via a deployed Zabbix client
Via SNMP polls
Via Traps from supporting infrastructure components
Using SNMP, specific data objects can be polled from the network hardware. An Object can be for example a port status or a port uplink throughput value. Each Object in SNMP has an
Object ID, known as OID. The return values of OID polls, known as Items in Zabbix, can then be pooled together to form aggregate Items using mathematical equations. Zabbix can assign Triggers to Items, which can take action once the trigger threshold has been
breached. Examples include sending an email, sms, running a shell script or any other user defined action when e.g. a router port is transmitting a higher than user-specified level of traffic. This can then be used to e.g. track down the failure of a routing path.
All routers based on the Linux kernel have Zabbix agents deployed on them to report metrics to their respective Zabbix servers. Network devices which do not support Zabbix agent deployment are either polled periodically via SNMP by the Zabbix server, or are configured to fire off Traps when a pre-defined state is reached, providing they support such
functionality.
The database for each Zabbix server can be MySQL, PostgreSQL, MS SQL Server, IBM DB2, amongst others and can be hosted on the same machine or externally. It is
recommended to host the database externally where heavy load is to be expected from a large number of Zabbix clients.
Figure 19 – Zabbix data centre deployment example, as deployed in CloudSigma
In this scenario, we consider CloudSigma’s data centre with the Compute Nodes hosting the VMs and being interconnected through the data centre network.
The CloudSigma stack is installed on the CS API server, which can be scaled and load balanced on several machines, if need be. Zabbix clients are deployed on each physical compute node atop the OS and run alongside the NPax client, which is analogous to the Nova client found in OpenStack.
A number of Zabbix servers are deployed and provisioned to collect specific metrics from the data centre infrastructure. These can be physical, as can be seen in the Master Zabbix Server found in the diagram above, or virtual.
In the case of CloudSigma, the Zabbix master server collects metrics from the bare metal compute nodes and storage infrastructure. It also hosts the Zabbix web front-end. The secondary and tertiary Zabbix servers are used to monitor network equipment and (CS Infrastructure related) virtual machines, respectively.
6.3 Commercial cloud service rental
6.3.1 Cloud adapters in the CloudBroker Platform
The central tool for connecting the application software to the IaaS cloud resources in the CloudSME project is the CloudBroker Platform. It supports commercial and open source resource types such as Amazon EC2, IBM SmartCloud Enterprise, Eucalyptus, OpenStack EC2 and Nova, and OpenNebula for compute as well as Amazon S3, IBM Nirvanix, Eucalyptus Walrus, OpenStack S3 and Ceph RADOS S3 for storage clouds. Within the CloudSME project, CloudBroker is also implementing an adapter to the CloudSigma cloud. CloudBroker itself typically only provides access to commercial IaaS clouds such as Amazon Web Services and IBM SmartCloud Enterprise in the platform installations it operates. However, other resource providers, such as those within CloudSME, can add their own public (i.e., offered by partner organizations or cloud providers) or private (i.e., in-house or hosted) resources of the supported types easily. All what is needed are credentials for the corresponding cloud resources.
Within CloudSME, while CloudBroker is responsible for operating the CloudBroker Platform installation(s), ScaleTools is responsible for setting up the necessary IaaS cloud account(s). In the following, we describe the corresponding status.
6.3.2 Amazon Web Services
According to Wikipedia, “Amazon Web Services (abbreviated AWS) is a collection of remote computing services (also called web services) that together make up a cloud computing platform, offered over the Internet by Amazon.com. The most central and well-known of these services are Amazon EC2 and Amazon S3. The service is advertised as providing a large computing capacity (potentially many servers) much faster and cheaper than building a physical server farm.” (http://en.wikipedia.org/wiki/Amazon_Web_Services)
Amazon describes Amazon EC2 (Elastic Compute Cloud) as “a web service that provides resizable compute capacity in the cloud. It is designed to make web-scale computing easier for developers. […] Amazon EC2 presents a true virtual computing environment, allowing you to use web service interfaces to launch instances with a variety of operating systems, load them with your custom application environment, manage your network’s access permissions, and run your image using as many or few systems as you desire.” Using Amazon EC2, you “pay only for the resources that you actually consume, like instance-hours or data transfer.” (http://aws.amazon.com/ec2/)
Amazon S3 (Simple Storage Service), on the other hand, “is storage for the Internet. It is designed to make web-scale computing easier for developers. Amazon S3 provides a simple web services interface that can be used to store and retrieve any amount of data, at any time, from anywhere on the web. It gives any developer access to the same highly scalable, reliable, secure, fast, inexpensive infrastructure that Amazon uses to run its own global network of web sites. The service aims to maximize benefits of scale and to pass those benefits on to developers. […] Amazon S3 is intentionally built with a minimal feature set.” (http://aws.amazon.com/s3/)
Amazon Web Services (http://aws.amazon.com) is a pioneer of IaaS and probably the most widely known and basically a de-facto standard of such cloud offerings. Therefore it is highly desirable to have Amazon EC2 and S3 services included in CloudSME as a reference. For these reasons, ScaleTools created a standard Amazon Web Services account for CloudSME, including access to the Amazon EC2 and S3 services. It is maintained by
ScaleTools and will be booked from the ScaleTools CloudSME budget. This account has already been successfully used for the initial porting and testing of the SIMUL8 software through the CloudBroker Platform.
6.3.3 IBM SmartCloud Enterprise
According to Wikipedia, “IBM cloud computing consists of cloud computing solutions for enterprises as offered by the global information technology company, IBM. All offerings are designed for business use, marketed under the name IBM SmartCloud. IBM cloud includes infrastructure as a service (IaaS), software as a service (SaaS) and platform as a service (PaaS) offered through public, private and hybrid cloud delivery models, in addition to the components that make up those clouds.” (http://en.wikipedia.org/wiki/IBM_cloud_computing) Webopedia adds, “IBM Cloud refers to a collection of enterprise-class technologies and services developed to help customers assess their cloud readiness, develop adoption strategies and identify business entry points for a cloud environment. IBM's cloud computing strategy is based on a hybrid cloud model that focuses on integrating the private cloud
services of a company with the public cloud.”
(http://www.webopedia.com/TERM/I/ibm_cloud.html)
IBM’s IaaS cloud computing solution that is most similar to Amazon Web Services is called IBM Smart Cloud Enterprise (
http://www-935.ibm.com/services/us/en/cloud-enterprise/index.html). It includes among other offerings on-demand compute resources and
a Nirvanix-based object storage.
Although it would be technically possible, no IBM cloud account was created for CloudSME yet. The reasons are that a separate written contract would be required for ScaleTools, and that there is currently no need for a further commercial cloud beyond CloudSigma and Amazon in CloudSME. However, IBM SmartCloud Enterprise could be added later in the project, if required.
6.3.4 Integration of other clouds into the CloudBroker Platform
Access to the clouds at University of Zaragoza BIFI (OpenStack) and MTA SZTAKI (OpenNebula) within the CloudBroker Platform has already been successfully tested in another EU FP7 project, SCI-BUS (SCIentific gateway Based User Support,
http://www.sci-bus.eu). MTA SZTAKI even operates a connection to their cloud in the public CloudBroker
Platform at https://platform.cloudbroker.com on production level. A corresponding setup for the University of Westminster cloud is also already in progress. With the support of CloudBroker and ScaleTools, the listed resource providers should thus be able to provide similar configurations also for CloudSME.
For the CloudSigma setup in the CloudBroker Platform within CloudSME, ScaleTools initially created CloudSigma trial accounts. Using these, a first CloudSigma adaptor version was developed and first tests were performed. To continue with the integration, a full account has been requested from CloudSigma.
6.3.5 Service level agreements
Neither Amazon Web Services nor the CloudBroker Platform provide special SLAs (Service Level Agreements) for the CloudSME project. For Amazon Web Services, the corresponding general legal agreements, terms, policies and guidelines listed under http://aws.amazon.com/legal/, respectively for the individual services such as Amazon EC2 and S3, apply. For the CloudBroker Platform, the terms that are displayed during the registration process and that after login can be found under the "Information / Terms" tab apply. Both can change during the runtime of the project.
7 Conclusion and next steps
In the Q1, all of the partners prepared their cloud infrastructures to connect it to the CloudBroker Platform. The following table summarizes the available and the dedicated resources (in terms of CPU cores, storage capacity and the amount of memory).
Cloud provider Type of cloud Cloud middleware Dedicated / Overall cores Dedicated / overall RAM [GB] Dedicated / Overall storage [TB]
CloudSigma Commercial KVM/Qemu Custom Proprietary stack
24/240 64/1920 6/180
SZTAKI Academic OpenNebula
4.2
32 / 624 64 / 2252 4 / 138
UoW Academic OpenStack
Folsom
32 / 160 192 / 1920 3 / 17
UNIZAR Academic OpenStack
Grizzly 50 / 480 50/864 3/15 Amazon Web Services (via ScaleTools account)
Commercial Amazon EC2 and S3 Only on demand and pay-per-use Only on demand and pay-per-use Only on demand and pay-per-use Table 4 - Infrastructure resources
In WP5, the next step will be the establishment of the test bed and the prototype infrastructure by connecting the resources into the CloudBroker Platform and WS-Pgrade/gUSE.