Configuration and Management

The first step after installing the system is to add the required hypervisor to provide virtual systems. Xen, KVM, and VMware are currently supported. Depending on the selected hypervisor, you still need to extend the configuration in the central configuration file /etc/one/oned.conf to ensure correct control of the host system. In the case of KVM, the communication is handled by libvirt; it handles both the management and monitoring functions as an interface.

Although OpenNebula 4.2 comes with a very nice new web console (Figure 2) and a self-service portal, you can still manage all components using the command line. Most commands work with host and VM IDs to identify and control these components safely.

Figure 2: The new web interface in OpenNebula 4.2.

Integrating OpenNebula with a configuration management database is a breeze – you can then automatically generate VMs after they have been created in the administration interface. Also, Puppet, Chef, and CFEngine can be used to control the cloud environment.

The available feature set provides all the functionality you will need, although you will need some training for the procedures and functions of the various subsystems, which can take some time. OpenNebula also supports hybrid operations with different host operating systems or outsourcing of resources to other private zones or to public cloud providers; all of these tasks can be managed in a single administrative console.

Cloud Shaping

As the size of a cloud environment grows, dependencies relating to users, locations, and system capabilities increasingly must be taken into account. OpenNebula offers three basic concepts: groups, virtual data centers (VDCs), and zones.

Groups let you join systems with similar capabilities to form logical units. Thus, you can define conditions for the operation of certain systems and group systems that access the same sub-infrastructure, such as the datastore, VLANs, and hypervisors. As a simple example, a KVM system with GlusterFS storage can, of course, only be run on servers with a KVM hypervisor and GlusterFS access. Groups ensure that exactly these conditions are met.

If you need to provide a collection of resources to a number of users or a customer, without relying on groups, then the use of VDC is the solution. Arbitrary resources can be grouped to form virtual data centers and for access authorized via ACLs. These cross-zone arrays not only let you isolate noisy neighbors and support partial allocation of resources, they also are a very good basis for individual billing of resources. Additionally, the subdivision of all resources into individual private clouds can easily be reverted using VDCs.

As a third concept for grouping large installations, OpenNebula provides zones. Zones (oZones) allow central monitoring and configuration of individual OpenNebula installations. This setup allows complete isolation of individual areas across version borders and simultaneous central control of the environment.

This separation may take the application profile into consideration but also the location or customer. Even if you group together a large number of OpenNebula installations, independent control of the individual systems is possible. Thus, maximum freedom is guaranteed in the individual environment while allowing central aggregation and monitoring.

New in Version 4.2

Version 4.0 already introduced many new features to OpenNebula. Especially in the area of the virtualization layer, OpenNebula is capable of holding sway with commercial solutions thanks to features such as real-time snapshots and capacity resizing. The web interface revamp that I already mentioned is certainly the most obvious change; it now combines the previously separate views for admin and self service in a single interface.

Particularly noteworthy are the two new components: OpenNebula Gate and OpenNebula Flow. Gate allows users to share information between VMs and OpenNebula using a security token. A URL created during template generation can thus transfer application metrics to OpenNebula and visualize them using Sunstone. An example would be periodically transferring the active connections of a virtualized load balancer to OpenNebula.

It makes sense to leave the subsequent processing of information to the new Flow component. Flow, which was previously available as the AppFlow extension, has been an integral part since version 4.2 and has been greatly expanded in the scope of the acquisition. With the help of Flow, you can apply both static and dynamic rules based on OpenNebula Gate values.

OpenNebula separates actions into Scheduled Policies and Elasticity Policies (Figure 3). Scheduled Policies allow, as the name suggests, scheduled changes to resource pools. Thus, application servers will shut down at night or on the weekend when their performance is not needed, based on static rules.

Figure 3: OpenNebula supports Scheduled and Elasticity Policies for the automatic adjustment of resources.

Elasticity Policies can make changes to pools based on rules and taking Gate values into consideration. After defining the minimum and maximum size of a virtual machine pool, virtual machines are restarted or shut down on the basis of rules. Using expressions and period rules, you can then modify the available resources at variable intervals.

Listing 1 shows the use of a dynamic rule based on connections. The number of active connections passed in by OpenNebula Gate is checked and – in the first sub-rule – results in two new systems being started after the rule has been exceeded three times. The second part of rule allows the reduction of the pool after the number of connections has dropped by a certain percentage.

01 {
02   "name": "ONE-SCALE",
03   "deployment": "none",
04   "roles": [
05     {
06       "name": "appserver",
07       "cardinality": 2,
08       "vm_template": 0,
09
10       "min_vms" : 5,
11       "max_vms" : 10,
12
13       "elasticity_policies" : [
14         {
15           // +2 VMs when the exp. is true for 3 times in a row,
16           // separated by 10 seconds
17           "expression" : "CONNECTION > 2000",
18
19           "type" : "CHANGE",
20           "adjust" : 2,
21
22           "period_number" : 3,
23           "period" : 10
24         },
25         {
26           // -10 percent VMs when the exp. is true.
27           // If 10 percent is less than 2, -2 VMs.
28           "expression" : "CONNECTION < 2000",
29
30           "type" : "PERCENTAGE_CHANGE",
31           "adjust" : -10,
32           "min_adjust_step" : 2
33         }
34       ]
35     }
36   ]
37 }

By combining dynamic application information with the capabilities of the OpenNebula Core, the management of complex application scenarios has no limits. The syntax is self-explanatory, and rules can be used for a variety of scenarios in a short time. Thus, OpenNebula meets critical application requirements stipulated by providers and supports demand-driven resource allocation. Because OpenNebula also has an interface to AWS, systems can also be outsourced to AWS in a hybrid cloud model.