Minding the Store

German-based IT-Novum caused much excitement in 2013 when it announced a tool that gives almost anyone the ability to manage versatile storage: openAttic [1]. The first version 1.0 of openAttic clearly demonstrated that the manufacturer has an excellent understanding of the main problem facing storage admins: configuration. The first edition, however, still had many rough edges, which IT-Novum has now smoothed.

Although version 1.1 was officially available for download at CeBIT back in March 2014, IT-Novum did not deliver the matching documentation in the current form until July.

Given the scope of the change, the new openAttic version could easily be called 2.0 instead of 1.1. OpenAttic 1.1 is clearly more than a development of the first version, with many features that will make openAttic interesting and attractive for many companies.

More on openAttic

IT-Novum advertises openAttic as a comprehensive tool for centralized control of storage services; the aim is to merge all the typical storage tools into a single IT installation. The scope of openAttic's responsibilities includes managing physical storage devices, as well as supporting additional services for high availability and export via iSCSI connections. The design that was characteristic of openAttic from the beginning once again proves to be very robust.

The tool is completely modular. The core itself is fairly lean; almost all the functions come from modules that openAttic loads after launching. This modular design makes it possible to replace individual openAttic components without the need for a complete upgrade. The plugin interface makes it easy to install a new module that provides additional functionality.

Packages

Packages in .deb format are available for Debian Wheezy and Ubuntu 12.4, and you can install them using apt. On the whole, the installation on Debian and Ubuntu (Figure 1) runs more smoothly than the installation for openAttic 1.0, which should make version 1.1 accessible to a far larger group of users.

IT-Novum still has some work to do with the package system; for example, the Deb Directory of openAttic contains a package that was specifically backported for Ubuntu 12.04 but does not have a version number that makes it identifiable as a backport. Oversights like this can cause problems with distribution upgrades.

It is a little disappointing that no packets are available for Ubuntu 14.04 LTS, which was released in April 2014. Although openAttic 1.1 had already been released when Ubuntu 14.04 saw the light of day, it should not be such a huge hassle to provide packages for the newer version of Ubuntu. Anyone starting with openAttic, will definitely want to use the LTS version, with its five-year support window.

Things look far less rosy for companies that rely on Red Hat. Anyone who uses RHEL, CentOS, Scientific Linux, or another derivative of RHEL is still left out in the cold. RPM packages of software are nowhere to be seen, and the project lacks a guide that describes the manual setup.

OpenAttic is apparently tied to some mechanisms that are specific to Debian and Ubuntu, and replacing them with generic constructs will cost too much time.

A Change of Scenery

When the previous openAttic 1.0 version came out, it was anything but enterprise-ready. In openAttic 1.1, however, the developers mostly achieved what they set out to do. If you run openAttic 1.1 on a Debian or Ubuntu system and are already familiar with version 1.0, you are initially in for an eye-opening experience. The new version differs quite visibly from its predecessor. IT-Novum explains in the company's blog that they received many requests and complaints from users after the first release, and they took this feedback to heart.

Most of the improvements only become apparent when you look at the details: users will find numerous improvements that make openAttic 1.1 far more attractive. The openAttic 1.1 web interface looks a whole lot more up market. The basic principle of the GUI has not changed much; in fact, the top-level menu is still on the left; to the right are the properties you selected in the left-hand part of the front-end. You can even create a dashboard (Figure 2) to keep an eye on your systems.

Far more important than the dialog changes are the changes that the new features in the 1.1 edition introduce.

The most prominent new release in the module category is a module that configures the Linux kernel iSCSI target, LIO [2]. Thus far, openAttic has used the fairly ancient IET iSCSI target.

Rising Tide Systems [3] and Nicholas Bellinger made a name for themselves in the Linux scene by designing LIO as a universal target that does not only understand iSCSI. LIO itself can act as an iSCSI target, but it is also suitable for Fibre Channel connections with a matching HBA, because it is itself designed flexibly.

Version 1.1 can set up a LIO target and also integrate it seamlessly with the other parts of openAttic; it is thus possible, for example, to export a LVM2 Logical Volume that you created via LIO and then via iSCSI to another host.

OpenAttic comes with modules for ZFS and Btrfs. Although basic ZFS and Btrfs functionality was already in place in openAttic, the new version offers better filesystem configuration through openAttic's graphical front end.

Version 1.1 offers separate menus for both ZFS and Btrfs that take the configuration up to the same level as configuring other services in openAttic. The functional integration of ZFS and Btrfs has also improved significantly; snapshots of the two filesystems are no longer a problem. Also, it is now possible to define quotas for ZFS, even directly from the web interface.

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.

Other Corrections

Of course, openAttic 1.1 also includes bugfixes for issues in the previous version. LVM snapshots now work far more reliably, and enlarging the XFS filesystem will also work reliably in the future. Version 1.1.2 even came with a small surprise – with the openAttic team unceremoniously removing support for Oracle's OCFS2 [5]. Considering the fact that the number of OCFS2 users is relatively low, this is unlikely to have practical consequences.

Conclusions: On the Right Track

OpenAttic 1.1 gets many things right; the improved installation process and the fact that packages are now available for Debian Wheezy and Ubuntu 12.04 are significant improvements. Unfortunately, openAttic still lacks any kind of support for RPM-based distributions such as SUSE or RHEL.

OpenAttic 1.1 is far more capable than the previous version. New functions such as ZFS, Btrfs, and LIO significantly boost the software's appeal. If you want to take a closer look at openAttic, the developers offer an ISO [6], which gives you a ready-made openAttic installation. You can also participate in openAttic development if you are interested – the project relies exclusively on open source components. For more details, check out the openAttic website [7].