Analysis and comparison of Open source IaaS cloud Platform

As an important form of cloud computing, IaaS services have a wide range of open source and commercial cloud platform scenarios. This article is based on the use of open source IaaS cloud platform to develop public and private cloud management platform perspective, introduced and compared eucalyptus, Opennebula, Cloudstack and OpenStack, such as open source IaaS cloud platform.

The characteristics of successful cloud platform viewed from AWS

AWS is currently the most successful cloud computing platform, its system architecture is the most characteristic of the Web service interface to open data and functionality, all with service first, and through the architecture of SOA to make the system loose coupling.

The Web service stack provided by AWS, by the access layer (API, management console and various command lines, etc.), the common service layer (identity authentication, monitoring, deployment, automation, etc.), PAAs layer services (parallel processing, content transfer and messaging services, etc.), IaaS layer Services (compute EC2, storage s3/ EBS, Network Service VPC/ELB, and database services) are composed of several parts. User applications use IAAS infrastructure IT resources to build their own services as components in the application architecture. In a comprehensive perspective, the core idea of the system architecture in AWS ecosystem is SOA, tiering and service composition.

Private Cloud requirements

In addition to the common cloud platform such as AWS, private clouds and mixed clouds are also important forms of IaaS. There are usually several requirements for a private cloud platform for an enterprise.

Compute multiple options for virtual technology (KVM, XEN, ESX, ESXi, Hyper-V, XenServer, etc.).

Diverse storage Technology/equipment support (switches, routers, firewalls, etc.).

Multiple support for network technology/equipment (NAS, Ip-san, Fc-san, etc.).

Support for multiple APIs.

The top three requirements require the IaaS platform to shield the underlying specific technology/equipment from the difference of the ability and interface to present the basic consistency. This is generally to use the abstract framework and plug-in design to achieve. In addition, based on the system of Computing virtualization, network and storage, the whole architecture design should consider the independence of computing virtualization, network and storage into three subsystems or services.

Therefore, the cloud platform should contain at least three layers: the API or Access layer provides a variety of different APIs or access methods, and core virtualization management consolidates the underlying services to provide IAAS services, computing/storage/Network Service layer shielding technology differences.

Technical Team Development Requirements

The small technical team is elitist and everyone can participate in the overall design. Large teams are pyramid structures, and only a few can participate in the overall design, and most people have access to a single function or module for their abilities and responsibilities.

To meet the requirements of both teams, the overall software architecture of the cloud platform must be loosely coupled to form the entire system by combining components, modules, and services, while requiring components, modules, and service functions to be assembled to facilitate the independent maintenance of small teams and facilitate independent design, development and evolution.

In addition, the cloud platform needs to consider providing the underlying shared components for reuse in each service. Typical reusable components are database ORM, message communication, service-side infrastructure, configuration management system, log system, and error location system. Many large teams consolidate these basic shared services and automate the generation of basic framework code through Domain Description language, enabling developers to focus on specific service implementations and key technology research.

Introduction and comparison of cloud Platform

The following are layered and modular from the system architecture, using SOA to achieve loose coupling of the system, Component Services using framework plug-in design, and development platform to compare 4 open source IaaS cloud platforms.

Eucalyptus

Eucalyptus is the first open source IaaS cloud platform to attempt to clone AWS, as shown in the left half of Figure 1. Eucalyptus consists of a cloud controller (CLC), a Walrus, a cluster controller (CC), a storage controller (SC), and a node controller (NC) that collaborate with each other to provide the required cloud services. A secure communication is implemented between components using a SOAP message that supports WS. Eucalyptus provides a SOAP and query interface that is compatible with AWS and does not provide additional APIs.

Figure 1 Eucalyptus system architecture and CLC logical architecture

From a tiered perspective, Eucalyptus lacks API layer design, CLC is the global resource management layer, and cluster services (CC and SC) are the underlying resource management layers. The CLC, CC, and NC three-tier architecture is not layered at the software architecture level, but as an engineering method for managing larger clusters.

From the Component Services perspective, computing and storage services are designed as stand-alone services in each cluster, and the network is still part of the computing service. Although eucalyptus in the code implementation is the network part of the independent, but the overall does not follow the independent service to design, the overall design decoupling is not enough.

CLC is the core of eucalyptus, including virtual machine control, storage volume management, network resource (address) management, mirroring management, snapshot management, keypair management and metadata Management services modules. Open Source ESB Mule all services and provides EC2 and EBS services externally through Eucalyptus services, as shown in the right half of Figure 1. As you can see, Eucalyptus is doing well at the SOA level. However, the high threshold of ESB technology requires a high level of design and development personnel. At the same time because eucalyptus only in very few places to support plug-ins (such as multiple hypervisor supported plug-ins), so the overall design of the abstract framework and plug-ins do not much.

From the perspective of development platform, the main development language of Eucalyptus is to use open source ESB Mule as core orchestration service for Java and C;CLC, the architecture is newer, but CC and NC adopt Apache +CGI Software Architecture and implement Web service based on AXIS/C. Overall, Eucalyptus has not yet developed a platform for the trend.

Opennebula

Opennebula is part of the reservoir project, an Open-source implementation of the virtualization management of virtual infrastructure and cloud computing programs launched by the European Institute of Research in 2005. The core part of Opennebula is the front end, one. Its architecture is shown in Figure 2.

Opennebula is clearly divided into three layers, namely interface layer, core layer and drive layer. Interface layer provides native XML-RPC interface, simultaneously implements the EC2, Occi and Opennebula Cloud API (OCA) and so on various APIs, has provided the user various choices.

The core layer of Opennebula core provides a unified hook plug-in management, request management, VM Lifecycle management, hypervisor management, network resource management, and storage resource management. Core with scheduler provides computing and storage network resource management services.

At the bottom is a variety of driver-composed drive layers that interact with virtualization software (KVM, XEN) and physical infrastructure. What needs to be explained is that the drive layer in Figure 2 does not draw a plurality of datastore, NetworkManager and so on. Some front-end modules such as monitoring, user interface (Sunstone portal and self Service portal) are also not drawn in Figure 2. It is clear that Opennebula is doing well at two points in the layered and framed plug-in design.

Figure 2 Opennebula System architecture

In Opennebula, the computing, storage, and networking sections are separate modules in one, and resource scheduling is also separated to support multiple alternative policy and resource management through requirement and matcher. Scheduling engine Haizer is also supported to provide advanced resource scheduling capabilities for lease (leases).

Obviously, Opennebula did not use SOA design, did not design computing, storage and network as stand-alone components, decoupling did not do enough. Notably, Opennebula uses the interface provided by Libvirt to remotely invoke the Virtualization Control command on the compute node. This agentless design in the system installation and deployment phase will reduce a lot of software installation configuration work, is a design highlights.

From the perspective of development platform, Opennebula uses C + + to implement the core one, using various driver developed by Ruby to realize the specific functions. The whole system has only one core component, so it does very little on the development platform.