Red Hat Storage Server 2.1
Spartan Camp
Software Defined Storage (SDS) is gaining popularity within the IT community. An SDS system is similar to a Storage Area Network (SAN) system, except, rather than operating on specialized, proprietary hardware systems, an SDS uses software to handle the storage on commodity hardware.
This emphasis on commodity hardware – and more transparent software systems – means the customer can avoid the expense and annoyance of the vendor lock-in associated with so many SAN solutions. In 2013, Red Hat introduced an SDS product designed to give users a viable alternative to a SAN: Red Hat Storage Server (RHSS – see Figures 1 and 2) [1].
Functionally, RHSS is oriented on classic storage systems – in the background, data resides in block storage, although the device exports data on the customer-facing side via different interfaces, such as Fibre Channel, I-SCSI, NFS, or Samba. Of course, you can easily implement all of these functions based on free software.
OpenStack Cloud Storage
Red Hat must have clearly understood that it would be very difficult to earn a penny on yet another SAN-like product without touting some kind of additional benefits. The company says RHSS actually extends the capabilities of classical storage systems, pointing to "seamless scalability" and "perfect connections to the cloud."
If you read between the lines of the marketing bulletins, you will recognize the customer pool Red Hat intends to fish in with RHSS: big data, massively scalable storage – in short, cloud storage. Red Hat's PR apparatniks place special emphasis on the good OpenStack connectivity of RHSS version 2.1, which was released in September.
This turn toward OpenStack is interesting because Red Hat seemed to sleep through the OpenStack hype for a long time and did not enter the OpenStack development scramble until late in the game. Red Hat has apparently seen the light, and the company now claims to be the "top committer" to OpenStack.
Old Friends on the RHEL Base
When we looked at RHSS 2.1 in the lab, we quickly recognized it as a collection of old friends. Red Hat's own operating system for enterprise customers, RHEL, provides the underpinnings for the system.
This stands to reason because Enterprise Linux forms the basis of almost all of Red Hat's enterprise products. However, an additional component is needed to make RHSS into a modern and powerful tool.
Enter GlusterFS (Figures 3 and 4). Red Hat acquired Gluster late in 2011 and assimilated its only product, GlusterFS. Shortly after, Red Hat revamped many parts of the project, added release and feature management, and set its own developers to working on new features for distributed storage.
At first glance, the GlusterFS in RHSS seems to be a standard version, in other words, the version that is also publicly available on the GlusterFS website. But, you can assume that RHSS will take priority in internal development, and that fixes will appear in RHSS before they trickle down into the official GlusterFS tree.
RHSS inherits all the features of GlusterFS: At least two nodes are necessary for redundant storage, and redundant storage allows for many storage scenarios.
GlusterFS can use translators to manage replicated (i.e., mirrored) volumes and volumes with striping. Last but not least, GlusterFS also supports distributed storage. You can even combine storage modes; for instance, a distributed, replicated volume is no problem for GlusterFS.
Client Front Ends
Red Hat GlusterFS has seen some major developments in recent months. In addition to the native FUSE driver, GlusterFS also offers an NFS front end that supports NFSv3 access. In RHSS, Red Hat offers also the possibility to export existing GlusterFS volumes via a pre-installed Samba, so that even Windows hosts can access them.
Unfortunately, Red Hat has not integrated the Samba VFS module (of which a beta version already exists) into Gluster [2] for RHSS. This potential improvement would give the GlusterFS filesystem itself the ability to generate Samba exports without being dependent on Samba.