Data Center Federation in OpenNebula

Data Center Federation in OpenNebula

In the latest versions of OpenNebula, has been added a functionality which is really interesting for us: the Data Center Federation.

We have already spoken several times in the past about OpenNebula, an OpenSource software to manage cloud infrastructures based on Xen, KVM or VMWare. A few days ago was released the version 4.8 that significantly improves the user interface further perfecting the functionality of Data Center Federation.
But what is it?

The data center federation allows you to connect all the instances of OpenNebula in more data centers, so you can use a single entry point (via console or via sunstone web interface) to control all the data centers. To use this feature, is required that all instances of OpenNebula are configured to use MySQL as a backend, not SQLite selected by default.

You must elect an installation of OpenNebula as “Master”, and at that site, the MySQL database will be configured as master asynchronous replication; all other installations of OpenNebula will be considered “Slave”, and likewise, the configuration of the MySQL replication in these will be as Slave. The replica will not affect all tables in the MySQL database, but only those relating to the list of users, groups, permissions and zones of data center federation.

OpenNebula side, in the configuration file oned.conf should be declared if it is the master or a slave and, in the latter case, what is the URL of the RPC API of the master; also you need to configure through Sunstone or command line, the list of the OpenNebula servers that are part of the federation.

At this point, operatively, what happens:

if you run a transaction involving the local OpenNebula data center (eg. creating a template, a network, a VM, etc..), it is done locally and the local DB is used to keep the informations;

if you perform an operation that affects users, groups, permissions, or zones, we distinguish two cases:

if the operation is performed on OpenNebula “Master”, it is performed directly and then is replicated to all data center via asynchronous replication of MySQL;

if the operation is performed on one of the OpenNebula “Slave”, it is intercepted by local OpenNebula daemon and it launches an API that executes the command on the master as if it is local; then, as in case 1, the result is written to the local Master MySQL database and then is propagated to the whole federation.

Since version 4.8, this is added another useful feature: the log messages contain the OpenNebula ID which performed the operation. Therefore, it is possible to use a central syslog to collect all the log messages, but they can be easily distinguished by the ID of the server.

In the case of update of OpenNebula, of course you have to run it manually in all data centers of the federation, but this approach makes it possible to still maintain control even during the upgrade: in fact the replicated tables are backward compatible, so multiple versions of OpenNebula can all coexist inside a federation.

So in summary, the data center federation allows you to use a single installation of Sunstone to operate multiple data centers with OpenNebula, simply switching the data center to control through a popup. The use of asynchronous replication systems as the RPC API and MySQL asynchronous replication, makes this system also suitable in case of distant data centers with high latency.

Leave a Reply

Your email address will not be published. Required fields are marked *

nineteen + 6 =