The Building Blocks of a PaaS

Usually, cloud computing is divided in three distinct logic layers that are dependent of their main function. These are infrastructure, platform and service. Any of these layers can be publicly available to the end-user, according to its needs. Figure 2 graphically presents the three-layer vision on the cloud computing architecture. Next, sub-sections briefly describe each layer, with a special focus on the infrastructure as a service stratum that PaaS, the main motivation of this paper, relies on.

Cloud computing abstracts resources and facilitates its usage seamlessly. Going one step further, the same principle applies to a group of clouds where several building blocks underpin the creation of a sky environment [18]. By blending resources on public and private clouds, the Sky Cloud can make intensive computing efficiently, mitigate bottlenecks, and keep sensitive data protected.

A decisive factor in favor of sky computing is the alleged freedom of choice for developers and customers alike. Using this paradigm, applications will be able to move freely among cloud providers, with no need for rewrites or code changes. The big challenge here is managing the combined resources of available clouds, public or private, and interoperating between them [19].

Because of deficient standardization, several projects try to solve the interoperating problem through middleware. In [20], authors go through the specifics of projects like libcloud, DeltaCloud, jclouds, fog and Altocumulus. A proposed architecture, using a middleware API to interoperate between clouds is depicted in Fig. 3.

On a sky computing architecture, users try to take the maximum advantage of the better (and less expensive) cloud providers available. In such scenarios, the ultimate goal is the development of a PaaS able to abstract the different cloud providers and give the user a single interface with all systems. Such a layer would certainly pass the frontier of its definition and would mix with some upper layer services (management, accounting, etc.).

In the last couple of years, the PaaS layer has seen a major boost in terms of solutions and efforts of standardization. For application development (where developers are familiar with middleware, frameworks, SDKs and APIs that solve most of the platform dependency issues), the PaaS model presents itself as the natural development environment.

The criteria for electing the following PaaS solutions for review are based on the solution’s maturity level and functional similarities with the proposed goals for our PaaS implementation.

Despite our efforts, most of the research done is based on the providers white papers (pure commercial providers) and open-source projects (mixture of commercial providers and technology enforcers) readings.

Management nodes write to the main cloud management databases and run one or more of the components described below.

Processing nodes are the main worker nodes. These nodes run a modified web server instance, along with the management application described below. Within the web server instance, each node may deploy an assorted number of virtual hosts, one for each deployed application. If required, applications may store and retrieve information from a central application database.

Each node hosts a set of services that allow monitoring and secure deployment of applications. These services run on the web server instance and store all sessions on a central database. For security measures, access to these services is SSL protected, requiring the authentication of the invoking client.

Load balancing in this scenario is complex, since not all the application servers host the same set of applications. This means that the load balancer must be designed in terms of sets of application/host instead of simple host availability. The application/host availability information is acquired from a central database. All of the incoming traffic routes through the load balancer.

For security reasons, a DNS server is required to ensure the SSL based establishment of the trust relations between the processing nodes and the management nodes. It is imperative that both nodes have their DNS entries updated before attempting to perform the SSL handshake.

Almost every component of this PaaS uses a database. For convenience, an SQL server was used throughout this project, but a close analysis of the data stored on each database may prove that some of the data are better suited for storage on other types of databases. Examples of such data are the HTTP sessions that can easily be migrated to a key-value store such as redis [43].

One security issue present in this architecture is the possibility of attacks against the central session database. On a final product, the database containing the session data should be replaced, and most likely, an abstraction layer should be used to store and retrieve sessions from the central repository.

There is no sharing of the application server’s context among instances. This is probably easy to solve by storing the context properties along with the session on the central database. No attempt was made to do so since the session is usually the only place used to store application state.

Storage is also not shared among instances. This requires that the applications are aware of that, and do not try to store files locally. Some practices, such as creating a cached version of the html output for a file may prove to be counterproductive in this scenario as such a cache would exist on a single node and could be invalidated by updates performed on a different node. The same is valid for user uploads, which would be saved to a single node, and therefore would not be accessible from other nodes. This can be solved by using a simple storage service that allows a distributed storage to be seamlessly integrated with the application. However, that was not the scope of this project.

Concerning latency, each request answered on this platform involves a few mandatory round trips to one or more databases. The load balancer performs at least one request, and another request originates from the application to fetch any session information required to serve the request (even if the application itself requires no data from the database). As long as the database can perform, latency is expected to be constant regardless of the number of running nodes and application requests.

Finally, all the application requests are bound to go through the load balancer. When on heavy loads, this may represent a bottleneck. Even on more conservative load usage, if the load balancer becomes unresponsive, the entire solution comes to a halt. To better deal with this unresponsive load balancer, redundant load balancer nodes could be implemented. To better deal with heavy loads, another possible solution would be the deployment of a set of load balancers per application, thus minimizing the overall risks of load balancer failure.

Despite some architectural issues, there are also some benefits from such architecture. The most important is the central session storage that does not suffer from the problems that replicated sessions usually suffer, e.g., a high level of chatter between the cluster nodes or missing some session data if the data is modified directly.

Regardless of the session’s centralization contribution to latency, storing the session always after serving a request (or a set of requests) is a simple solution to a complicated problem. Traditional replication techniques require that the server nodes communicate with each other. This architecture removes this requirement as the only time a session is requested from central storage is when one of the processing nodes needs to access that session to output the HTTP response. This enables the cluster size to grow far past the point where the traditional cluster container starts spending more time coordinating than serving requests.

In terms of scalability, the proposed architecture should be able to scale applications horizontally. In an application server cluster, the number of requests answered should scale almost linearly with the addition of more nodes to the pool of nodes running the same application. Since this architecture is based on the same principles of the traditional clusters, this rule should also apply. This potential benefit will be monitored closely during the performance tests.

Considering the developed PaaS model, there is no need to change or rewrite code that already runs on a standard web server. The only exception would be the use of local resources, as explained previously. Even so, this model ensures no vendor lock-in.

Despite clear differences in terms of maturity levels, an architectural comparison between the proposed solution and the most relevant PaaS presented in the state of the art is mandatory.

As most of the solutions presented, we propose the sharing of execution servers by several applications. It is up to the overall system to minimize the running execution servers. OpenShift, WSO2 Stratos, COSCA, Cloudify and Cumulogic also present a shared environment along with a truly vendor lock-in free PaaS solution, just as our proposal does.

As with AppScale, COSCA and most PaaS solutions, we enable the commission and decommission of execution nodes on demand.

The proposed PaaS solution is not as generic as the Carbon based model presented by WSO2 Stratos or as the cartridges model of OpenShift. It is, in fact very similar to COSCA’s proposal. Despite that, it holds pretty much the same components and possibilities as the rest of the pack, even though in a less flexible composition approach. This is related with the initial goal set: to provide a PaaS capable of deploying web applications that were not developed for the cloud. In such a scenario, most of the presented PaaS flexibility is not required at the application level, being something handled during deployment.

Another important goal is related to the previous work presented in [11, 13], where we discuss the incorporation of off-premises computers (personal computers or servers—user nodes) into the cloud’s resources to be managed by the PaaS. In this case, the user nodes are incorporated (in some extent, user configured) into the cloud’s available resources and may be used to host and run third party web applications. Therefore, this PaaS has to handle the process of registering the user nodes into the available resource pool, by means of a secure automatic enrollment process initiated by the execution node. This idea resembles (for its use of off-premises resources) the Program Ultra-Dispatcher (PROUD) approach. PROUD [44], despite not being a PaaS solution, clearly provides the means for users to take advantage of both the clouds’ resources and underused resources of nearby computers. However, and contrary to our concept, these resources are controlled (and owned) by the user; regardless of being physical computers or virtual computers. The PROUD focuses on enabling a given user to execute their applications on the most convenient location, based on preset rules that are based on computer CPU usage, memory usage, etc. The results of running the application are seen just as if they were being executed locally, thanks to the feedback of the remote desktop. In our approach, we provide the PaaS and computing nodes (regardless of the nodes’ actual ownership) to support the developers’ applications. The typical output is only seen using a web browser to access the deployed application.

Finally, in terms of cloud usage, our approach enables sky computing usage, along with the user node providers.

Table 1 provides a brief comparison among the different PaaS presented in the state of the art and our approach.

The testbed runs in a group of physical machines each one with one or more virtual machines. The physical machines run Scientific Linux 5.5, with the Xen hypervisor, and work as virtualization nodes for an OpenNebula based IaaS. The virtual machines run the last beta release of Red Hat Enterprise Linux Version 6 (RHEL 6).

During the initial testing phase, the available hardware was two “long-past-their-half-life-expectancy” servers. By using aged hardware and proving that this PaaS scenario could function on this configuration, we could take advantage of this obsolete equipment to perform tasks that they were no longer able to perform. The best server (Server 1) is a Dell PowerEdge 2850 with two Xeon CPU’s @2.8 GHz with hyperthreading, 2 GB of ECC RAM, and 33 GB of disk space. This host runs its software on 250 MB of RAM, the remainder is left for the virtual machines. The other server (Server 2) is a Dell PowerEdge 4400 with two Pentium III Coppermine@800 MHz CPUs, 1 GB of RAM with only 250 MB for the system and about 100 GB of storage. Server 1’s disk space was used for operating system images’ storage. Server 2’s storage is composed of slow disk space that was used for backups and source code repositories.

The tests performed with this hardware configuration did not show a linear relation with the increase of the number of nodes. Given the two physical server deployments with a high number of virtual machines running from the same disk, the observed bottleneck was both on CPU and on the heavy IO performed on the disk and network interface on the same host. In fact, all of the hosts (virtual and physical) were swapping out part of their main memory, and all the swap files and partitions were on the same disk.

This minimal hardware setup enabled us to prove that there is no need for high-end hardware requirements to successfully validate a PaaS architecture under low and moderate loads. However, the original goal was to assess the scalability and performance of the PaaS under heavy loads.

Considering the findings in [30], regarding the similar results of executing tests on physical machines or on virtual machines running on the same physical host, we set up a new hardware testbed with a single physical host: a twin six-core Intel Xeon @2,667 GHz CPU with hyperthreading and 98 GB of ECC RAM, backed by a 1 TB fibre channel storage unit.

The testing was performed over a set of 18 virtual machines, each running Scientific Linux 6. One of the VMs was set aside to run the management services, the MySQL database, and the load balancer, while the remaining VMs were left as processing nodes. Each VM was allocated one CPU core and 4 GB of memory. All virtual machines were running SNMP and were monitored by an external system while the tests were performed. The virtual machines were managed using OpenNebula.

The setup environment uses NAT networking instead of bridged networking. Because of the NAT networking, the virtual instances are not accessible from the outside world. However, such access is not required; the only service that absolutely needs to be accessible from the outside world is the load manager that may run directly on one of the physical hosts.

Throughout the testing, one virtual machine instance was used to run all of the management services and the other instances were reserved to be used as processing nodes. The virtual machines were kept running throughout the whole test, but the services that composed the processing node were only started on an “as needed” basis.

As mentioned before, the Management Application will be used for testing purposes.

The reliability test results will indicate if the service is able to function for low loads, as long as at least one processing node runs the target application. This test started with the management node running, and two processing nodes running the same application on the same named virtual host. After deploying the application, the application code was manually modified (on each virtual host) to identify which of the hosts responded to a request. This helped on reinsuring that the requests were not all being sent to the same node.

A custom entry was added to the hosts’ file on a client desktop pointing to the selected name for the virtual host to the IP address of the load balancer. The application was then accessed using the laptop’s browser. The navigation was as follows: first, login as administrator; second, click once on each menu entry; third, update the user name; forth, logout.

This navigation sequence was repeated with different amounts of running nodes. Each sequence always worked as expected, showing little or no session stickiness, proving that the load balancer was not configured to stick each session to a server instance, and that the modifications made to the Tomcat server work at least under a light load. The navigation sequence was recorded using JMeter, which was later used to test the performance and scalability of the system.

Additionally, one of the nodes was shut down, leaving only one of the initial nodes running. A new node was booted, the application was deployed on that node and it was added to the load balancer. Finally, the remaining original node was shut down, leaving none of the original nodes running. As long as at least one node is running the requested application, the system will keep the application state.

The performance tests were made using JMeter-2.0.1, running on a different physical computer. It simulated the workflow described above for a consecutively higher number of users (threads). Each thread executes the workflow 20 times. Each workflow consists of 13 requests, 11 of which require application database access and one is a static image. JMeter was configured with a Gaussian timer with a 300 ms delay and 100 ms of deviation.

We set a maximum response time on 500 ms and tracked individual response times. For each number of active nodes we calculated the 90th percentile of the time of the response for a given amount of threads. The usage of a high percentile instead of the simple average enables us to best cope with network fluctuations and other random abnormalities. By plotting the information of each amount of threads per each number of nodes, we calculated the real number for the 90th percentile for each number of nodes. Figure 8 summarizes results along with a trend line and associated equation.

Analyzing the number of threads per number of nodes, there is a performance cost of roughly 2.5 % per increased node, adding about 30 % of theoretical performance loss when comparing the throughput of 3 nodes with 17 nodes.

An analysis of the monitoring data collected while testing shows that there is a possible performance bottleneck on the PaaS: the MySQL server. With the higher numbers of processing nodes, MySQL was using about 80–90 % of its available processing power. This behavior is easily explained by the amount of database requests being made: at least one for each request (caused by the application state being stored in a database) and on most cases another access for application specific data.

Despite the overall 30 % performance loss reported, the results are encouraging when compared with others: Aneka [25] running on Windows Azure reported about a 68 % theoretical performance loss on 16 nodes, which translates into a 47.4 % loss when scaling from 4 to 16 nodes. With our approach, the same scaling (from 4 to 16 nodes) sets the performance back by 27.6 %.