Hivext Cloud Platform - Low-Level Architecture

In this article, the architectural solution of the low level of the Hivext cloud platform will be described, namely the level of data centers and the interaction between each server type.
Recall that the Hivext project is designed for more efficient use of resources (temporary and financial) in the development of “rich” Internet applications (Rich Internet Application) and provides a wide range of ready interconnected services.
Thanks to IT-GRAD, we were able to deploy an additional copy of the platform in St. Petersburg data center (DC) for free. We have been allocated virtual hosting based on VMware vSphere 4. You can work with such hosting through both the web interface and the desktop client, everything is quite convenient.

At the moment, Hivext is deployed in 3 geographically distributed DCs: Kiev (Ukraine), Zhytomyr (Ukraine) and St. Petersburg (Russia). The configuration of the platform within each DC is built according to a specific structure.

I suggest, so to speak, to look under the hood of our platform.

')
So, in connection with the victory in the competition of IT start-ups, the latest copy of our platform is located on the equipment, which is located on the site in DC IT Grad with a high level of reliability TIER3. This ensures the availability of 99.95%, backup diesel generator, water cooling, gas fire extinguishing system, twenty-four-hour support service. All together creates a failsafe platform where banks, telecommunication companies and our platform are located.

DC Interaction Scheme

All requests from customers come to the general site http://api.hivext.com/ , which is located in the central DC. In this site there is information about the location of each specific application to which the request goes. If the application is in another DC, the current DC works as a proxy. In most cases, client-sided SDKs (JavaScript, ActionScript, j2me, j2se, Qt) are used to work with the platform API, and when they first access it, they ask exactly which DC the application is in and all subsequent requests go directly to the desired DC. Thus, two issues are solved - client balancing and painless migration of applications between DCs.

The interaction of computers within one DC

Four different types of computers are used to provide the necessary functionality.

1. Balancer
2. Application Server (Cloudlets)
3. File server
4. Database server

In the ideal case, the general scheme will work according to the mixed principle of HA (High Available) + LB (Load Balancing). In the real case (at the moment of development), HA is used in a limited mode, the backup server is used only for the application server.
In the field of cloud platforms, we introduce a new concept of Cloudlet - this is one instance of a web server (in this case, tomcat) with a fixed memory size of 1 GB.
Below is a schematic representation of the interaction of different types of platform computers in one of the DCs.


In the IT-GRAD data center, we were allocated free of charge the amount of resources from which we managed to assemble the following configuration:
Balancer - 1 vCPU, 1Gb Memory, 8 Gb HDD - Apache 2 + AJP (modified mod_jk)
Node1 - 3 vCPU, 4Gb Memory, 52 Gb HDD - (Master) tomcat 6 (3pcs) + NIS + NFS + FTP
Node2 - 3 vCPU, 4Gb Memory, 36 Gb HDD - tomcat 6 (3pcs)
DB - 2 vCPU, 8Gb Memory, 200 Gb HDD - MySQL 5.1

Unfortunately, we did not have enough resources won in the competition to organize a separate File Storage server, so it was temporarily combined with one of the nodes.

The balancer is implemented on the basis of Apache 2 + AJP (modified mod_jk) using “sticky” sessions (stiky session). Apache 2 is configured so that all static files are given to them directly, and the rest of the requests are transferred to the application server. Adding a new application and selecting a domain name is done without restarting Apache 2.

Cloudlet (application server) is implemented on the basis of tomcat 6, which is deployed in the amount of 6 pieces on Node1 and Node2 and is configured in 3 separate clusters using DeltaManager + SimpleTcpCluster (replication in memory). Balancing is done between these three clusters.

The file server stores static files. Static files are directly accessible via the web and are available to application scripts within the application server. Availability of files on other servers is ensured through the use of NFS 4 . These files can be accessed using FTP.
NIS is used to synchronize users between computers.

The database server is based on MySQL 5.1 using master-slave replication. Under each application is allocated a separate database. Access to the application databases is available from application scripts, as well as through the web interface PhpMyAdmin.

The organization of the platform at the software level is shown below.

The core of the platform uses two whales, the Spring Framework and Hibernate.

In this article, we briefly reviewed the low-level architecture of the Hivext cloud platform.

-
In the following articles: opening of PHP based on Quercus , description of working with client SDKs.

Previous articles about Hivext

• Hivext: Web services platform ( part 1 and part 2 )
• Hivext cloud platform for web development
• Hivext Platform - a cloud platform for developing Internet applications. Beta testing

Online Cloud Development Environment
Our forum

Any questions or comments on the merits are welcome.