Lead Image © Greg Epperson, Photocase.com

Extending OpenNebula with hooks

Action on the Hook

Article from ADMIN 18/2013

By Nils Magnus

Savvy OpenNebula users can attach their shell programs to hooks and thus automatically trigger actions when the status of a virtual machine changes.

Virtualization speeds up the pace of a system administrator's life. With KVM, Xen, and VMware, admins can provision systems far more quickly than they could have procured and installed new hardware back in the days of dedicated servers. You can use the extra time for cloning image configurations, copying directories, and mounting storage resources. However, things get tricky when hardware issues mean you need to shut down, migrate, and restart virtual machines.

If you want to reduce the tedium of working with virtual machines, you could resort to an Infrastructure-as-a-Service (IaaS) cloud solution. The cloud handles the most important tasks of server virtualization, manages the basic infrastructure (e.g., DNS and DHCP), and provides a web interface. Admins can choose from a gallery of open source products, such as OpenStack [1], openQRM [2], Eucalyptus [3], or Ganeti [4], each with its specific functionality and concepts.

Because of the diversity of scenarios, most cloud stacks behave in a complex way and require a lengthy learning curve. OpenNebula [5], which originated in Spain, sets out to prove that things can happen more quickly, if your users have typical requirements.

Lean Cloud Management

OpenNebula spent its childhood in the academic field of grid computing and is now considered a lightweight enterprise solution. The Fermilab particle accelerator uses OpenNebula to manage hundreds of virtual machines, and industrial customers include Telefonica and Akamai. The main developer from C12G Labs offers commercial support and is currently establishing an international network of partners [6].

OpenNebula is characterized by its simple elegance. Whereas other IaaS competitors prompt you to install and configure half a dozen services and components, OpenNebula manages with only a few components and with a single front end for controlling and configuring the private cloud, OpenNebula Sunstone. The "OpenNebula Installation" box outlines the setup, and Figure 1 shows the architecture.

Figure 1: Admins manage and configure OpenNebula mainly with the Sunstone web browser-based interface. The front end uses the API to connect with the OpenNebula server, which in turn controls the virtualization hosts. OpenNebula only requires its hosts to run an SSH server.

OpenNebula Installation

The OpenNebula project delivers complete packages for a variety of distributions, including CentOS, Arch, and Gentoo. To launch OpenNebula on openSUSE, you need to add both the Packman repository and the project repositories and then install the software:

zypper addrepo --no-gpgcheck --refresh -t YUM http://opennebula.org/repo/ openSUSE/12.3/stable/x86_64 opennebula
zypper refresh
zypper install opennebula
zypper install opennebula-sunstone

For Debian and Ubuntu, a tarball is available with several custom Debian packages, of which you need to install opennebula-common, libopennebula-ruby, and their dependencies. The tutorial [7] provides competent help if Ruby warnings happen to stop the installation process.

The installation creates a oneadmin Linux user account, which must exist with the same UID on all OpenNebula hosts, also known as compute nodes. Apart from a running OpenSSH server, the system administrator does not need to install any software there. You just need to make sure that the public SSH key of the oneadmin user is listed in the authorized_keys for this account on all compute nodes and that the cloud service can thus log in everywhere.

Hypervisor-Agnostic Virtualization

Virtualization software is still missing on the hosts because it is not part of OpenNebula. That said, the IaaS stack supports most hypervisors, including KVM, Xen, and VMware, and can also control libvirt.

On the front end, the installation routine creates an application account below ~oneadmin/.one/one_auth. Working as oneadmin, the system administrator can now start the OpenNebula server with the one start command and then issue onevm list to check whether the server's internal API can be reached without error messages. To access the web front end from any host, just add the desired IP address or the following entry:

:host = 0.0.0.0

to the /etc/one/sunstone-server.conf configuration file. Without further changes, Sunstone (Figure 2) only binds to localhost and is accessible on http://localhost:9869/ after running sunstone-server start. In case of problems, you need to check /var/log/one/sunstone.log and the associated error file in the same directory.

By the way, services only run permanently on the front end: OpenNebula's management server is joined by the scheduler, which optionally moves virtual machines from one host to another; the Sunstone web interface; and the API, which developers can use to access cloud functions via OCCI or EC2 APIs. On the hosts themselves, no service runs permanently, except the VMs and the OpenSSH server.

Figure 2: The dashboard displaying important system parameters at the top, such as a simple monitoring view of the hosts (left) and virtual machines (right). Via the menu bar (left), administrators – and users – can create and manage systems in the OpenNebula cloud.

Versions and Features

OpenNebula names its releases after interstellar nebulae. Stable version 4.0, published in May 2013, was named "Eagle" – after the Eagle Nebula (a star cluster discovered in the mid-18th century that is about 7,000 light years from Earth). Compared with the 3.x series, which is roughly two years older, it mainly fixes bugs but also revamps the Sunstone web interface. The changes affected, for example, VNC access to virtual machines.

The latest version 4.2, code-named "Flame," was released in early August 2013. (The eponymous Flame Nebula lies in the Orion constellation; its light takes about 1,000 years to reach earth.) The creators of the project have smoothed off the rough edges in the Sunstone interface for Flame. One new feature is a simplified view that explicitly addresses users who only want to provision one VM – not set up an entire cluster. Admins can now monitor image sizes in an improved way and intervene if a VM is threatening to spiral out of control. To do this, OpenNebula now monitors this resource.

The developers have written the back end for VMware virtualization, which can now be installed easily and has fewer dependencies. The Xen driver now uses the xl-style commands available with version 4.0 of the hypervisor.

OpenNebula users have become accustomed to running the latest version in test environments, while relying on the penultimate version for production operation. Although the programming interface described below existed in version 3, its entire functionality was only reached in version 4.0.

On the Hook

An important reason for virtualizing servers is the pursuit of automation. If your own development department has built a new release of its PHP, Perl, Ruby, or Java application using the Jenkins CI server [8], for example, it can automatically generate a stage VM with the necessary packages and frameworks. Once the requesting department has tested and approved the application, you just need one click to release the associated resources in an ideal world.

The glossy brochures on cloud computing fail to mention that the devil again lies in the details. In many cases, you'll need to update a database schema or start a particular service on a virtual machine. Fortunately, OpenNebula provides hooks for such tasks [9]. The software uses them on many occasions to call external programs that admins can compose in the programming or scripting language of their own choice.

1 2 3 Next »