OpenNebula internal architecture can be divided into three layers:
This layer contains tools shipped with OpenNebula, such as the CLI or the scheduler, but also 3rd party tools that can be easily created using the XML-RPC interface or the ONE client API.
A command line interface is provided with OpenNebula to manually manipulate the virtual infrastructure under ONE. For more information about the CLI (command line interface) go here.
The Scheduler is an independent entity in the OpenNebula architecture, so it can be easily tailored or changed since it is decoupled from the rest of the components. It uses the XML-RPC interface provided by ONE to invoke actions on virtual machines. The scheduler distributed in the Technology Preview provides the following functionality:
The core consists of a set of components to control and monitor virtual machines and hosts. The core performs its actions (e.g. monitor a host, or cancel a VM) by invoking a suitable driver. The main functional components of OpenNebula core are:
The Request Manager exposes a XML-RPC Interface, and then depending on the invoked method a given component is called internally. The XML-RPC decouples most of the functionality in the OpenNebula core, from external components i.e. the Scheduler.
More information about the XML-RPC methods and parameters can be found here.
This component is responsible for the management and monitoring of VMs. The operations of the VM Manager are abstracted from the underlying hypervisor the use of plugable drivers.
This component manages and monitors the physical hosts. Monitor and management actions are performed also through a suitable driver. The host monitoring infrastructure is flexible and can be extended to include any attribute (see the Install and Configuration Guide for more details.
A persistent generic pool based on a SQLite3 backend is the core component of the OpenNebula internal data structures. This component provides ONE with the scalability and reliability (in case of failure the state of OpenNebula is automatically recovered) needed in the management VMs.
Note that this information can be accessed through the SQLite3 interface to develop custom accounting applications.
OpenNebula has a set of pluggable modules to interact with specific middleware (e.g. virtualization hypervisor, file transfer mechanisms or information services), these modules are called Middleware Access Drivers (MAD). The communication between the core and the drivers is performed using a simple ASCII Protocol, which simplifies the development of new drivers. The ASCII MAD Protocol is like following:
ACTION RESULT ... INFO
where:
MUST
be in the form:INIT FINALIZE