Oldie but Goldie: DRBD

Although the DRBD cluster storage tools has dropped behind GlusterFS and Ceph in the PR battle, it has a permanent place to this day for supporting simple setups with two nodes. In such installations, DRBD takes over the task of copying data in the background from a block device on computer 1 to a block device on computer 2.

OpenAttic 1.0 already had support for DRBD, but openAttic 1.1 offers a separate DRBD module, which makes controlling the parameters of DRBD resources much easier.

You can easily create a DRBD resource on an LVM or launch an iSCSI target. If you are used to working with many storage pools and local hard drives, you will find that openAttic makes your admin work much easier.

Absolutely Cloud-Ready

Of course, openAttic 1.1 can't ignore the overwhelming dominance of the cloud. Although the developers were very careful in their statements about version 1.0's cloud capabilities, it's full speed ahead into the cloud for openAttic 1.1. The latest version supports more cloud storage technologies and also offer a programmable interface for provisioning cloud storage directly in openAttic.

As a management solution for various storage types, openAttic must inevitably deal with different storage back ends that might not even have been on the scene when the developers started their work two years ago. Although the modular structure of openAttic makes it easier for developers to adapt the system, the basic functionality still has to come from somewhere. The documentation of openAttic clearly the developers are focused on Ceph, OpenStack Swift, and Hadoop.

You will find no more than the names of the solutions in the manual at present, however, and given the fact that we failed to find references to these storage back ends in openAttic anywhere else to date, support for them is likely to be rudimentary.

In defense of openAttic, it should also be mentioned that Ceph, Swift, and Hadoop are highly complex. Integrating them with an environment like IT-Novum's openAttic is therefore certainly not trivial; even continuing the development of these functions in the next openAttic versions would show great commitment.

Developers currently are taking more seriously the question of how openAttic itself integrates as a storage service in cloud and virtual environments. The project's focus is quite obviously a tandem of two different projects: the OpenQRM platform ([4]) on the one hand, and OpenStack on the other. In the notes for version 1.1, openAttic points out that the new version can connect to both solutions, because openAttic itself offers corresponding connector plugins. Basically, the solution devised by the developers consists of two components: an API and drivers that use this API.

To get the ball rolling, the openAttic developers have made their product more accessible from the outside by means of a programmable interface. OpenAttic version 1.1 is thus just as readily accessible as many OpenStack components have proved to be in the past. The API in line with the XML-RPC standard allows external applications to directly send commands to openAttic. This, in turn, is of great importance for other components that want to control openAttic from the outside.

As an example, the developers cite Cinder, which is responsible for block devices in OpenStack. If the storage system you use provides an API, and the storing service can use drivers to call this API, cloud admins have exactly the kind of communication they want.

The API is Ready

The documentation for version 1.1 promises more than openAttic currently delivers. It is a fact that IT-Novum is currently working on drivers for OpenStack Cinder and for OpenQRM. On the other hand, it is also a fact that the driver for Cinder is on its way to being adopted into the official source code for OpenStack. Just before this issue went to press, the first blueprint became available. Whether or not the driver will make it into the Juno release of OpenStack is at least doubtful.

This is not a real show stopper, however, if IT-Novum succeeds in providing a suitable replacement solution by then – for example, in the form of an optional package that integrates the driver with Cinder using a kind of sideloading method. It is far more important, against the background of long-term development, that openAttic recognizes the need for an API and has presented an initial version of the API.

Incidentally, the openAttic developers have once again tackled the subject of Windows; although fundamental domain support already existed in openAttic 1.0, the new version of openAttic can directly join a Windows domain as a member. It is thus possible to upload files to an openAttic installation using the typical mechanisms found on Windows hosts.

Basically, the protocol support is already complete thanks to the introduction of LIO and Samba referred to earlier on. An openAttic system can be accessed via all the major protocols, regardless of which OS you use.