The function of the private PaaS in this project is to provide a sort of test bed in which several hybrid deployment scenarios can be executed in order to test Cloud4SOA. The overall per- formance of the private cloud has to be acceptable and resemble, up to a certain point, a real production environment scenario. This way, its performance can be more accurately compared to the performance when using a public cloud.
The cloud will not be used in a real production environment and, therefore, it does not need to offer a full spectrum of capabilities (advanced user management, support for multi- tenant applications, auto scaling, etc.). It just needs to include enough capabilities to be able to integrate with Cloud4SOA. This includes the creation and deployment of small applications, basic governance operations, migration functions and monitoring functions. For this same reason, it is desirable that the platform has a monetary cost as low as possible. It needs to support at least Java applications and MySQL databases, since the test application that will be used for the hybrid deployment uses these technologies. The cloud, also, has to be able to run in the environment reserved for it which is formed by a set of machines with a UNIX based OS. It is also desirable that the cloud is as scalable as possible, so that it could be extended at some point to fit the requirements of the project or to improve its overall performance. In this direction, it is preferred that the cloud has a modular structure that permits the distribution and replication of components.
In summary, the selected platform should fulfill the following requirements:
• Support for all the main Cloud4SOA use cases:
– Match-making
– Deployment
– Governance
– Monitoring.
– Migration
• Support for Java and MySQL.
• Low monetary cost, optimally free.
• It has to be able to run in a UNIX based environment.
• Acceptable performance levels.
• Platform scalability, permitting its extension.
Taking into account these requirements and the evaluated PaaS (see table 8.1),CloudFoundry
is the platform that fits better: It offers support for practically all use cases of Cloud4SOA, including support for Java applications and MySQL databases, it is the only free platform, it runs in a Linux environment and it can achieve good performance and scalability levels depending on how it is deployed. Refer to section 9 for more details about the performance and scalability of Cloud Foundry.
Aneka has been discarded because it only supports .NET applications. Moreover, it fo- cuses on HPC applications, a field which is out of the scope of Cloud4SOA. In a similar way, Apprenda has been discarded for only supporting .NET.
Stackato has been discarded because, in the context of this project, it does not provide any additional benefit from CloudFoundry, but it has a remarkably large monetary cost.
Finally, CumuLogic has been discarded because its use is restricted to a set of IaaS, and the availability of these cannot be ensured in the reserved environment, and also because it has a commercial license.
Chapter 9
CloudFoundry Installation
We have chosen the Open Source project from CloudFoundry (cloudfoundry.org) to install the platform on the Atos infrastructure, since this project offers a complete private CloudFoundry deployment. This section gives an overview of the CloudFoundry architecture and details the installation environment and procedure.
9.1
CloudFoundry architecture overview
Since the CloudFoundry project was released as an Open Source project, it has undertaken ma- jor changes in its architecture driven by the community supporting it, both in the addition of features (such as support for the Python and PHP programming languages) and in the refactor- ing and improvement of the architecture. As one of the CloudFoundry engineers explains in a blog post1, efforts have been focused on developmentBelow the Water Line, meaning that they are not visible as features, but rather improve the inner architecture of the platform.
The components within the CloudFoundry architecture and their interactions are depicted in figure 9.1 and 9.2, showing the different components that form it and how they are accessed from the outside. The architecture has been designed so that different components can be deployed on different physical nodes by using a decoupled message bus.
The main component, and the main entry point to the platform, is the Cloud Controller. This component performs all required actions to handle incoming requests and orchestrates the other components in the architecture. This component is responsible for all state changes in the system by ensuring all dependencies are available and by binding applications to services and, in general, is responsible of all actions related to applications and services, such as create and scale an application or bind services to an application.
In the initial architecture, functionality regarding user management was embedded in the Cloud Controller; however, as a result of the refactoring process mentioned earlier, the User
Account and Authenticationcomponent has been created, and has been assigned all responsibil-
ities regarding user management. This component basically implements the OAuth22protocol to authenticate users. The protocol has been designed to provide a mechanism to authorize
Clients(for example, a web application) to use resources in a Resource Server (for example,
1The blog entry can be read at: http://blog.cloudfoundry.org/2012/04/27/cloud-foundry-roadmap-below-the-
water-line/
Figure 9.1: Components view of the CloudFoundry architecture and their interactions.
Figure 9.2: Interaction between users and a CloudFoundry platform.
the Cloud Controller, the UAA component itself or any other back-end application), on behalf
of End-Users, by providing access tokens to Clients. A high-level work-flow of the autho-
primarily as theAuthorization Server. The protocol allows for a Single Sign On (SSO) mech- anism by whichEnd-Usersonly need to log-in one time in applications on the Cloud Foundry platform. Moreover, it provides centralized identity management which provides a unique safe place in which to authenticate and avoids malicious applications to gather user credentials. It also provides other features such as user account management (for instance, to get information about a user) and client application registration.
Figure 9.3: 3 High-level view of the authorization workflow.
TheStageris another of the new components that has been detached from the Cloud Con-
troller as a result of the refactoring. It is basically responsible for staging jobs (applications) for execution. This process includes creating adroplet(a package with all the application code plus its dependencies) for an application and storing it for later retrieval by de DEA. To create a droplet, the Stager gets the objects that comprise an application plus its dependencies, refactors its configuration files to point to the appropriate services and then packages all together.
TheDroplet Execution Agent (DEA)is the component responsible for actually executing
applications at the VM level. When the DEA receives a droplet to execute, it first checks that is able to run it in its VM and then starts the droplet or rejects the petition if its configuration does not match the configuration required by the droplet. The DEA also monitors applications (CPU usage, memory usage, etc.) and reports changes in state of applications to the Health Manager.
TheHealth Managermonitors applications activity across all DEA containers and notifies
the Cloud Controller on actions to take. To check for inconsistencies, the Health Manager periodically scans the Cloud Controller database and compares it with the actual state of the world. This way it can detect, for instance, the loss of an app or a whole DEA container.
TheRouternot only routes incoming requests to either the Cloud Controller, the UAA or
a user app, but also listens for notifications of new or deleted apps from the DEA. The router also acts as a load balancer by evenly distributing requests when a component is replicated.
The platform also containsServices(data, messaging, caching, etc.). The Cloud Controller has a uniform API to provision services, so that an app can be bound to any service with the same commands. Moreover, services can be shared across multiple applications.
Finally, to connect all the pieces together, Cloud Foundry uses a Message Bus (NATS
Server). When a component starts, it subscribes to the “topics” of his interest on the message
bus and publishes messages to it. This way, each component receives the messages that it needs to process.
As a side note, it is curious to mention that the entire CloudFoundry platform has been coded in Ruby, using frameworks and libraries such as Rails and EventMachines.