Project Full Title: Cloud based Simulation platform for Manufacturing and Engineering. Project Acronym: CloudSME Project Number:

Transcription

1 Project Full Title: Cloud based Simulation platform for Manufacturing and Engineering Project Acronym: CloudSME Project Number: Programme: Cooperation Themes: Information and Communication Technologies; Nanosciences, Nanotechnologies, Materials and new Production Technologies - NMP Call Identifier: FP NMP-ICT-FOF ( Factories of the Future ) Funding Scheme: Collaborative Project Start date of project: 01/07/2013 Duration: 30 months Deliverable: D5.2 Test bed of the cloud infrastructure for simulation Due date of deliverable: 31/12/2013 Actual submission date: 31/12/2013 WPL: SZTAKI Dissemination Level: PU Version: 1.0 Workpackage WP5 Page 1

2 1 Table of Contents 1 Table of Contents List of Figures and Tables Status and Change History Glossary Introduction Test Bed Resources Test Bed Architecture (The big picture) guse/ws-pgrade Concept Implementation CloudBroker Platform Concept Servers Configurations and deployments IaaS Clouds BIFI Cloud SZTAKI Cloud infrastructures The University of Westminster Cloud CloudSigma Commercial cloud service rental Issue tracking and ticketing system Infrastructure testing Test image Testing with guse/ws-pgrade Concept Testing procedure Conclusion and next steps Workpackage WP5 Page 2

3 2 List of Figures and Tables Figures Figure 1. Components of the CloudSME test bed... Error! Bookmark not defined. Figure 2 The entry point of the scientific gateway... 8 Figure 3 Disk usage of the test bed portal... 9 Figure 4 Memory caches and buffers of the test bed portal... 9 Figure 5 - CloudSME server architecture Figure 6 - Architecture of the preproduction UNIZAR-BIFI cloud Figure 7 - Horizon OpenStack grizzly dashboard to manage VMs and storage in the cloud 14 Figure 8 - Architecture of the production UNIZAR-BIFI cloud Figure 9 - Zabbix Map of BIFI cloud resources Figure 10 - Cores and RAM used by different nodes Figure 11 - Total used and free cores in the cloud infrastructure Figure 12 - Progress of the startup of VMs Figure 13 - Architecture of the LPDS cloud Figure 14 - Architecture of the SZTAKI cloud Figure 15 - Monitoring the CNs and the number of the running VMs Figure 16 - Number of running VMs Figure 17 - Power Consumption / VM Figure 18 - Cloud Dashboard at SZTAKI LPDS Figure 19 - Architecture of the UoW cloud Figure 20 - Qualys monitoring Figure 21 - Investigating the test results Figure 22 The CloudSigma stack Figure 23 The CloudSigma dashboard to manage VMs and storage in the cloud Figure 24 Zabbix data centre deployment example, as deployed in CloudSigma Figure 25 Central ticketing system and issue tracking system Figure 25 The test workflow Figure 26 Configuration of the test job Figure 27 Details of the job instance Tables Table 1 - Status Change History... 4 Table 2 - Deliverable Change History... 4 Table 3 Glossary... 5 Table 4 - Cloud configurations in the CloudSME CloudBroker Platform servers Table 5 - Application deployments in the CloudSME CloudBroker Platform servers Workpackage WP5 Page 3

4 3 Status and Change History Status: Name: Date: Signature: Draft: Sandor Acs, Dina Komarova, Wibke Sudholt 11/11/2013 n.n. electronically Table 1 - Status Change History Version Date Pages Author Modification /11/2013 All section SA First draft version /11/2013 guse/ws- PGRADE related section SA guse/ws-pgrade added /12/2013 Test bed architecture section SA Test bed architecture added /12/ , DK Updates on sections 6.3, Review, improvements and extensions /12/ , WS of the CB sections /12/ SA Versions merged and created section /12/2013 All section SA Figures and captions fixed /12/2013 All section TK, SA Some clarification /12/ SA Updated picture and description /12/2013 All section SA Some clarification Table 2 - Deliverable Change History Workpackage WP5 Page 4

5 4 Glossary AWS Amazon Web Services CN DNS EC2 FTP IaaS KVM OCCI PaaS QoS RT S3 Compute Nodes Domain Name System Elastic Compute Cloud File Transfer Protocol Infrastructure as a Service Kernel-based Virtual Machine Open Cloud Computing Interface Platform as a Service Quality of Service Request Tracker is an issue tracking system which thousands of organizations use for bug tracking, help desk ticketing, customer service, workflow processes, etc Simple Storage Service SaaS SLA SSH VLAN VM VPS ZABBIX Software as a Service Service Level Agreement Secure Shell Virtual Local Area Network Virtual Machine Virtual Private Server An enterprise-class open source software for monitoring of networks and applications. Table 3 Glossary Workpackage WP5 Page 5

6 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 the cloud test bed. The report will outline the architecture of the cloud infrastructure test bed, its components and how they work together and how to deploy the cloud infrastructure. 6 Test Bed Resources 6.1 Test Bed Architecture (The big picture) Figure 1 Components of the CloudSME test bed Error! Reference source not found. shows the core components of the test bed architecture. This infrastructure consists of the: academic (BIFI, UoW and SZTAKI) and commercial (CloudSigma) cloud resources; test CloudBroker Platform (available at and the AppCenter; ticketing and issue tracking system (available at Scientific Gateway based on WS-PGRADE/gUSE (available at The CloudBroker Platform collects the IT resources that are provided by the connected clouds. The guse/ws-pgrade based scientific gateway connects the user and developers to the CloudBroker Platform. Moreover, users and developers can directly reach the CloudBroker Platform and AppCenter as well. In case of issues, the project partners can create tickets in the central ticketing system and the corresponding technology provider gets the notifications automatically. Workpackage WP5 Page 6

7 6.2 guse/ws-pgrade Concept The guse/ws-pgrade is an open source science gateway (SG) framework developed by SZTAKI that enables users the convenient and easy access to cloud and grid infrastructures. It has been developed to support a large variety of user communities. It provides a generic purpose, workflow-oriented graphical user interface to create and run workflows on various distributed computing infrastructures (DCIs) including clouds, grids and clusters. There are many user communities who would like to access several DCIs in a transparent way however they do not want to learn the peculiar features of the used DCIs. They want to concentrate their scientific application - for them using an SG is the solution. An SG provides an interface between a community (or scientist) and the DCIs. An SG framework provides a specific set of enabling technologies as well as frontend and backend services that together build a generic gateway. SG frameworks are not specialized for a certain scientific area and hence communities from many different areas can use them. An enabling technology such as guse/ws-pgrade provides the required software stack to develop SG frameworks and SG instances (provide a simplified user interface that is highly tailored to the needs of the given community). Typical examples of such enabling technologies are: web application containers (Tomcat, Glassfish, etc.), portal or web application frameworks (Liferay, Spring, etc.), database management systems (MySQL, etc.), workflow management systems (guse/ws-pgrade, MOTEUR, etc.) SGs can have varying goals. In general, communities who use gateways can focus on their own goals and less on assembling the e-infrastructure that is required Implementation In the project, WP5 are going to set up two SG. One of them is available in the test bed that was created for developing and testing purposes. The other serves the production system and it will be released in the following period. The guse/ws-pgrade based scientific gateway of the test bed is available at (Figure 23). Workpackage WP5 Page 7

8 Figure 2 The entry point of the scientific gateway In this Portal, we registered and configured the CloudBroker Platform and the available cloud resources. The testing procedure is presented in Section 8.2. This service is running as a VM on the cloud infrastructure of SZTAKI. The VM consist of 4 virtual CPU cores, 4GB of memory and it has more than 100 GB of storage capacity. These resources can be resized on-demand. Workpackage WP5 Page 8

9 Figure 34 and Figure 45 present some monitored metrics from the last month of the running portal VM. Figure 3 Disk usage of the test bed portal Figure 4 Memory caches and buffers of the test bed portal More information about the scientific gateway services will be delivered by WP9. Workpackage WP5 Page 9

10 6.3 CloudBroker Platform Concept As described in detail in deliverable D8.1, CB and ST provide two main components to the CloudSME test bed: The CloudBroker Platform The AppCenter (previously commercial components ) Furthermore, during the kick-off meeting of the CloudSME project in London in July 2013, the requirement was expressed to have separate installations of the CloudBroker components for both testing and production in the project, respectively. In addition, also installations for internal development and testing at CB and ST are necessary. This leads to the following different installation levels: Production final versions, maintained in a stable way, to be used for serious deployments, testing and usage of the applications, to be made accessible for the outside at a later stage of the project Project testing alpha/beta versions, might change without notice, to be used for development of interfaces and tryout purposes in CloudSME, accessible only for project members Internal testing development versions, changing whenever there is a new implementation, for initial testing by CB and ST only, accessible only for the latter two companies Overall, this results in six CloudSME component installations to be performed and maintained by CB and ST for the project. In addition to these, also general facilities of the two companies as well as of the CloudSME project are utilized (e.g., monitoring, issue tracking, file storage, etc.) Servers For the purpose of the CloudSME project, CB rented a dedicated physical server located in France from its project budget. This was then successfully set up by the CB and ST teams, and three virtual machines for the CloudSME project were placed there. All these servers are currently restricted in access to the CloudSME project only (no external people will be allowed unless otherwise agreed upon in the project). Here are descriptions of each of the virtual machines: First virtual machine for the CloudSME CloudBroker Platform and AppCenter production servers. The CloudSME CloudBroker Platform and AppCenter production servers will be maintained in a stable way. They are meant as production servers for CloudSME. Their main goal is to enable usage of the software and cloud resources in the project. Any serious installations, tests and usage should be done here. Second virtual machine for the CloudSME CloudBroker Platform internal and project test servers. The CloudSME CloudBroker Platform project test server is a development version of the platform, and is for development and tryout purposes only. It might change or be interrupted anytime without notice. However, it will have the latest features. Its main purpose is to give other developers in the project a chance to try these out before they go into production. This server is not meant for any serious usage. Any Workpackage WP5 Page 10

11 production installations of software and cloud resources should be done on the production server above. The CloudSME CloudBroker Platform internal test server is the internal development version for the CB and ST teams. Third virtual machine for the AppServer internal and project test servers. The third virtual machine has the same role as the second one, only for the AppCenter instead of the CloudBroker Platform. It includes AppServer development versions for internal and project testing. Figure 56 displays the CloudSME server architecture. Here CloudSME stands for the CloudBroker Platform for the CloudSME project: Figure 5 - CloudSME server architecture Configurations and deployments After the setup of the CloudBroker Platform and AppCenter servers by CB and ST, it is now the task of the various cloud and application providers within CloudSME to set up their Workpackage WP5 Page 11

12 infrastructure and software in these test bed components on both the project testing and production levels. This is usually performed either by the corresponding organizations themselves with support by CB and ST, or initially by CB and ST and then taken over by the corresponding cloud or application provider. It should be noted here that at the moment it is only possible to set up infrastructure and software in the CloudBroker Platform. The platform already existed in production form independently from and far before the beginning of the CloudSME project (see After its installation on the CloudSME servers as explained above, it can now also be fully utilized by the other project members inside of CloudSME, and only needs some further adaptations to accommodate all cloud and application requirements in the project. The AppCenter, on the other hand, is still too early in development, and thus only available in a prototype version for demoing at this point. The status of the configuration and testing of the various CloudSME academic and commercial cloud resources on the CloudBroker Platform servers for the project is currently as follows: Cloud Server Organization Status Remarks BIFI OpenStack CloudSME project test UNIZAR Available CloudSME production UNIZAR Available MTA SZTAKI OpenNebula CloudSME project test MTA SZTAKI Available CloudSME production MTA SZTAKI Available UoW OpenStack CB / ST In preparation Issues with file deletion CloudSigma CloudSME project test CloudSME production CB / ST Available Needs to be maintained by CloudSigma CB / ST Available Needs to be maintained by CloudSigma Amazon CloudSME project test CB / ST Available CloudSME production CB / ST Available Table 4 - Cloud configurations in the CloudSME CloudBroker Platform servers The status of the deployment and testing of the various CloudSME application software for simulations in manufacturing and engineering on the CloudBroker Platform servers for the project is currently as follows: Application Server Organization Status Remarks Workpackage WP5 Page 12

13 Application Server Organization Status Remarks SIMUL8 CloudSME project test SIMUL8 Initial version CloudSME production CB / ST Initial version Needs to be maintained by SIMUL8 ASCOMP TransAT CloudSME project test ASCOMP Initial version Missing features to be implemented Rhino and plugins Ingecon In design phase BFly 2MoRO In design phase Table 5 - Application deployments in the CloudSME CloudBroker Platform servers 6.4 IaaS Clouds In our previous deliverable (D5.1), we have already described the IaaS cloud resources. However, we present the information in this deliverable as well for sake of completeness BIFI Cloud BIFI contributes with two different infrastructures to the CloudSME project. The first infrastructure is 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 2.27GHz) Memory: 16GB RAM Storage : 250GB per node. Workpackage WP5 Page 13

14 Figure 6 - Architecture of the preproduction UNIZAR-BIFI cloud 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 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 Workpackage WP5 Page 14

15 Figure 7 - Horizon OpenStack grizzly dashboard to manage VMs and storage in the cloud Opposed to the preproduction test bed 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 89, all the computing nodes have their own public IP and thus Internet connectivity, 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. Workpackage WP5 Page 15

16 Figure 8 - 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. ). Workpackage WP5 Page 16

17 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 9 - Zabbix Map of BIFI cloud resources Workpackage WP5 Page 17

18 Figure 10 - Cores and RAM used by different nodes Figure 11 - Total used and free cores in the cloud infrastructure Figure 12 - Progress of the startup of VMs Workpackage WP5 Page 18

19 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 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 1314 describes the current LPDS production cloud infrastructure. It consist of a frontend 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. Figure 13 - Architecture of the LPDS cloud Workpackage WP5 Page 19

20 The SZTAKI Cloud Figure 1415 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 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 KVM (based virtualization) Available interfaces: OCCI EC2 compatible interfaces SunStone WEB frontend Figure 14 - Architecture of the SZTAKI cloud Monitoring, testing and maintenance SZTAKI maintains its cloud infrastructures in production level and uses ZABBIX for monitoring purposes. Figure 15 - Monitoring the CNs and the number of the running VMs Workpackage WP5 Page 20

21 Figure 1516 shows that ZABBIX provides current information about the physical infrastructure (e.g network, compute nodes, etc). Figure 16 - Number of running VMs Figure 17 - 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 1819 shows. Workpackage WP5 Page 21

22 Figure 18 - Cloud Dashboard at SZTAKI LPDS These infrastructures are available at and at 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. Workpackage WP5 Page 22

23 6.4.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 19 - Architecture of the UoW cloud Workpackage WP5 Page 23

24 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 tests 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 2021 and Figure 2122 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 tests 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. We have identified and patched dozens of security leaks in VPS running in our cloud. Figure 20 - Qualys monitoring Workpackage WP5 Page 24

25 Figure 21 - Investigating the test results 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. Workpackage WP5 Page 25

26 6.4.4 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 22 The CloudSigma stack Workpackage WP5 Page 26

27 Figure 23 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. Workpackage WP5 Page 27

28 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 , 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. Workpackage WP5 Page 28

29 Figure 24 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. The database used in CloudSigma s case to hold Zabbix data, is MySQL. Workpackage WP5 Page 29

30 6.4.5 Commercial cloud service rental Cloud adapters in the CloudBroker Platform The central tool for connecting the application software to the IaaS (Infrastructure as a Service) 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, CB and ST have also already implemented adapters to the CloudSigma compute cloud and OpenStack Swift storage resources. CB and ST themselves typically only provide access to commercial IaaS clouds such as Amazon Web Services and IBM SmartCloud Enterprise in the platform installations they operate. 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. The currently available cloud configurations in the CloudBroker Platform servers for the CloudSME project have already been described in chapter Within CloudSME, while CB (with support of ST) is responsible for operating the CloudBroker Platform installations, ST (with support of CB) is responsible for setting up the necessary IaaS cloud accounts. In the following, we describe the corresponding status. 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. ( 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. ( 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. ( Amazon Web Services ( 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. Workpackage WP5 Page 30

31 For these reasons, ST created a standard Amazon Web Services account for CloudSME, including access to the Amazon EC2 and S3 services. It is maintained by ST and booked from the ST CloudSME budget. This Amazon account has then been configured on both the production and project testing CloudBroker Platforms for CloudSME under CB (see chapter 6.3.3). To make sure that the limited budget reserved for these purposes in CloudSME is used in the most efficient way for the project, prices for the Amazon CloudSME resource were added to the CloudSME CloudBroker Platform servers. The following procedure was then set up to manage the budget: Each organization can use Amazon resources for up to USD 100 initially. If an organization is registered on both CloudSME servers (production and project test), USD 50 were added for this organization account on each server. If the organization is registered on only one server, USD 100 were added to the corresponding organization account. In case the organization also registers an organization account on the second server, USD 50 will be transferred from the remaining amount to the new organization account. Depending on the chosen machine size, USD 100 should already allow for many core hours of testing. If an organization needs to perform Amazon usage which goes beyond that, it has to contact ST and CB in advance, so that the budget to apply for this can be agreed upon. The Amazon account has already been successfully used for the initial porting and testing of the SIMUL8 and ASCOMP TransAT simulation software on the CloudBroker Platform. 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. ( 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. ( IBM s IaaS cloud computing solution that is most similar to Amazon Web Services is called IBM Smart Cloud Enterprise ( It included among other offerings on-demand compute and storage resources. However, the corresponding Nirvanix-based object storage was already discontinued on October 15, IBM also announced that from January 31, 2014, SmartCloud Enterprise will no longer be available. Instead, SoftLayer ( will become the foundation of IBM s cloud portfolio, and future capabilities will be provided by IBM SoftLayer only. Therefore, IBM SmartCloud Enterprise will not be usable in the CloudBroker Platform and for the CloudSME project anymore. If it is necessary for the project, an IBM SoftLayer adapter could be implemented into the platform in the future. However, currently it does not look like that there is a need for a further standard commercial cloud beyond CloudSigma and Amazon that are already available in CloudSME. Workpackage WP5 Page 31

32 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, before. MTA SZTAKI even operates a connection to their cloud in the public CloudBroker Platform at on production level. UNIZAR and MTA SZTAKI have thus successfully configured their clouds in the CloudBroker Platform production and project test servers for CloudSME (see chapter 6.3.3). Further improvements in the platform to optimize the SSH connections through the proxy at MTA SZTAKI are on the way. A corresponding setup for the University of Westminster cloud (OpenStack) is also in progress. The main issue here turned out to be the very restrictive firewall settings at UoW, which required very specific configuration settings and implementations. With the support of CB and ST, it should though be possible to also provide access to the UoW cloud for CloudSME in the CloudBroker Platform servers soon. For the CloudSigma setup in the CloudBroker Platform within CloudSME, a first CloudSigma adaptor version was developed and first tests were performed. A CloudSigma account was requested by ST and used for the registration of this cloud in the CloudSME CloudBroker Platform production and project test servers under CB. However, this is only an intermediate solution, as CloudSigma needs to maintain its cloud in the platform itself. Service level agreements (SLAs) 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 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. Basically, for the CloudBroker Platform and AppCenter within CloudSME, at the moment CB and ST can only provide support and maintenance on a best effort basis, and as far as covered by the project budget. For all commercial and academic clouds, CB and ST refer to the published general (Amazon) or CloudSME-specific (UNIZAR, MTA SZTAKI, UoW, CloudSigma) SLAs. Workpackage WP5 Page 32

33 7 Issue tracking and ticketing system During the project, we use a central ticketing and issue tracking software. Therefore, we set up and maintain a Request Tracker (RT) tool. The RT is an issue tracking system which thousands of organizations use for bug tracking, help desk ticketing, customer service, workflow processes, change management, etc. ( Figure 25 Central ticketing system and issue tracking system In this tool, we have registered the cloud resources and other technology providers (BIFI, CloudBroker Platform, CloudSigma, UoW, SZTAKI). The project partners can access the central RT via the website at Workpackage WP5 Page 33

34 8 Infrastructure testing 8.1 Test image In order to standardize the testing procedure in the project, we implemented a test VM disk image that can be initiated on the cloud resources of the project partners. This image consists of Debian Linux operating system with integrated standard cloud contextualization methods and a wrapper script that can run jobs coming from guse/ws-pgrade scientific gateways. Due to the diversity of clouds in the projects, which is an added value to it because this way we demonstrate the interoperability among the different infrastructures (Amazon EC2, OpenNebula, OpenStack, Cloud Sigma), the testing image has been adapted and ported to all of them providing the same features. Each partner in charge of OpenNebula, OpenStack or Cloud Sigma based cloud test beds has ensured that all key cloud features related to instances as are flavour-based disk resizing, automatic SSH key instance injection to provide user access and also the size of the image has been reduced as much as possible to provide a very fast monitoring deployment and interfere as less as possible with the normal operation of each cloud infrastructure. 8.2 Testing with guse/ws-pgrade Concept Our users will access the whole infrastructure via the SGs (SG->CloudBroker Platform- >Cloud resource) hence we have to test the infrastructure from the users point of view as well. In the current period, we run the functionality test manually as the following section describes however WP5 will automate these tests in the next periods Testing procedure Testing steps: The tester (SG administrator) has prepared test workflows as Figure 2627 shows. Figure 2728 presents that the SG admin configures - choose the CloudBroker Platform and a cloud site as a testing target and submit the test job. After a while, the job will be succeeded or failed as Figure 2829 demonstrates. In case of failure, the administrator creates a ticket about the issue into the central ticketing system. Workpackage WP5 Page 34

35 Figure 26 The test workflow Figure 27 Configuration of the test job Workpackage WP5 Page 35

36 Figure 28 Details of the job instance Workpackage WP5 Page 36

37 9 Conclusion and next steps During the current period, we set up CloudBroker Platform and guse/ws-pgrade services and we integrate these components with cloud resources. WP5 still have some pending task as Table 4 summarizes. However, these issues are not blocking the infrastructure progress and our new ticketing and issue tracking system monitor them. In the next period, WP5 partners are going to solve pending issues, set up a central monitoring system and continue support other WPs. Workpackage WP5 Page 37