Red Hat Storage Server 2.1

Spartan Camp

Object Access

Red Hat says its Storage Server has an object access feature. The term is quite cloudy and refers to the trend of storage services natively providing a RESTful interface through which users can upload files.

In other words, object access is designed to make RHSS a full-fledged alternative to Amazon's S3 or Google Drive by letting users upload files via a web interface. Again, Red Hat sticks to its GlusterFS guns and relies on the UFO approach: Unified File and ObjectStore describes a technique in which the Swift proxy from OpenStack's Swift object store (Figure 5) stores data on GlusterFS in the background, instead of on Swift's own ring servers. Red Hat claims to have contributed significantly to this patch and helped to make it stable and integrate the required functionality into GlusterFS.

Figure 5: GlusterFS relies on the Swift proxy, which is actually part of OpenStack and not Gluster, to provide object access to users.

In RHSS, Red Hat supplies a suitably patched GlusterFS and a prepared OpenStack Swift module. It is possible for users to use the OpenStack Swift protocol to access data directly with a client such as Cyberduck [3].

Geo-Replication

Red Hat goes to great lengths in its advertising to emphasize the geo-replication feature. Geo-replication is intended to expand GlusterFS, adding an option for multiple site failover scenarios. If a complete data center fails, say, because of flooding, the data remains available, because the software has already used geo-replication to copy everything at Gluster level to another data center.

A simple failover would ensure that incoming requests are forwarded to the backup data center, where a setup based on the current data would carry on serving up the platform's capabilities as if nothing had happened.

Again, geo-replication is a GlusterFS kernel function that RHSS has just inherited. Unfortunately, the geo-replication feature has an unpleasant side effect: A follow-the-sun scenario is not possible in geo-replication with GlusterFS.

After the data center fails over to a new location, the storage at the old site needs to be completely synchronized with the new site – as if the data at the "old" site had become physically unusable, even if that is not the case. Despite this problem, geo-replication is a useful feature for preventing disaster scenarios.

People disagree on the crucial issue of whether colorful GUIs are necessary or merely annoying. The management tools of classical SAN storage systems are very popular; in fact, the vendors of these devices cite their sophisticated management tools as an argument for the superiority of their own technology.

Hardcore admins, however, are most likely to feel at home at the command line and have very little use for graphical tools. For them, RHSS is the perfect solution; a graphical configuration tool is not included with the storage server out the box. The Administration Guide for RHSS is almost 200 pages long and explains in detail how to use and configure certain functions; however, all of this happens exclusively at the command line. The RHSS is thus targeted at experienced storage professionals who prefer to use the keyboard.

OpenStack Compatibility

Red Hat has pushed on with the development of various OpenStack components in the past few months, so they also support GlusterFS. GlusterFS integration in Nova, OpenStack's computing component, for example, originated in Raleigh, as did the patch for Qemu, which allows for GlusterFS as a storage back end for virtual machines without complex mount operations. Then there's Cinder, which now also has a GlusterFS back end. You'll find more about the modules and their Gluster-integration on the OpenStack website http://6.

Thanks to all these features, Gluster acts as a storage jack-of-all-trades for OpenStack with direct access to the major components. Red Hat's commitment to OpenStack integration is evidenced by the detailed documentation on the topic of "RHSS and OpenStack" in the RHSS guide (Figure 6).