X marks the sweet SAN spot

Apple Xsan offers industrial-strength performance and stability at a low, low price

In the mid-1980s, Apple took its first steps into the corporate technology market and stumbled so badly that it was more than a dozen years before the wounds could heal. In the past few years, however, the company has made significant strides toward becoming a player in enterprise computing: Apple’s rack-mount Xserve server and Xserve RAID array chassis can hold their own with anything in their class.

It’s taken until now, though, for the software to catch up with the hardware. In particular, sharing data volumes across OS platforms required administrators to use the Samba SMB implementation (ick) or NFS (double-ick). Fortunately, those are no longer the only options available, with Apple’s introduction of Xsan, which allows administrators to build SANs on what passes for the cheap.

At its simplest, Xsan is a port of the StorNext File System from Advanced Digital Information Corporation (ADIC) that sells for significantly less than the equivalent bits for Linux, Unix, and Windows systems. Apple’s base price is $999 per connected Mac OS X machine, whereas StorNext FX clients -- which ADIC markets for Xsan environments -- cost up to three times as much: $1,750 for Linux and Windows, and $3,000 for other Unix platforms.

This “simple port” doesn’t include any tools for managing the data itself, at least not in the way one might expect in a SAN environment, where terabytes of data are slung around. In particular, lifecycle management is left to ADIC’s own StorNext Storage Manager or similar products. But Xsan beats all comers in the game Apple knows best: adding an attractive and intuitive interface to powerful software.

A Winning Point

The first release of Xsan came out in early 2005. After using it in the lab for several weeks, it became clear to me that Xsan 1.0 wasn’t review worthy. That changed at the solstice, with the release of Xsan 1.1 and Mac OS X 10.4. Xsan 1.1 delivered a notable improvement in the stability of the SAN, and the OS upgrade expanded the maximum supported volume to 2 petabytes. Although upgrading my test bed was no picnic, I thankfully didn’t have to reformat any volumes in the process.

As recommended, I used the Xsan Admin tool to create storage pools to aggregate LUNs (logical unit numbers) of similar properties, and then to create volumes out of storage pools. In my case, I chose to create two single-pool volumes on my smaller Xserve RAID units, and a striped dual-pool volume on a 5TB Xserve RAID. Xsan can’t mirror LUNs or pools.

Xsan Admin also manages access control, monitoring, and notification; Apple’s RAID Admin tool and Fibre Channel Utility take care of lower-level processes. Xsan Admin relies upon Apple’s Open Directory implementation of LDAP to supply user and group information for Mac OS X clients, so Xsan MDCs can consume supported foreign directories, including Microsoft’s Active Directory.

SAN administrators will find, however, that their most frequent task in Xsan Admin will be mounting and unmounting volumes on Mac OS X clients; one can also monitor how long volumes have been mounted on each client. Because stability was such a problem in Xsan 1.0, I kept a close eye on that figure when testing Version 1.1; I finally stopped counting after two weeks. Unfortunately, the management is volume-by-volume; one can’t see at a glance to which volumes a given client is connected.

The Xsan Admin tool replicates many of the console commands that are common to Xsan and StorNext. Certain features such as defragmentation are only available from the command line, and rightfully so. I’m less convinced that fail-over belongs in this class, because I’ve noticed that backup controllers don’t always release volumes to higher priority controllers, as one would expect.

Good News, Bad News

One connects non-Apple clients to Xsan with ADIC’s own StorNext software. The bad news is that the StorNext clients and Xsan Admin don’t communicate. Period. Administrators have to go from one foreign client to the next to set up the initial volume mapping, and then troubleshoot. The good news is that the command-line tools function identically whether it’s StorNext or Xsan.

The worst news, though, is that Apple decided to modify the naming of volume hierarchy levels so that StorNext’s File System Server is Xsan’s Metadata Controller, Xsan’s storage pools are StorNext’s stripe groups, and Xsan’s volumes are StorNext’s file systems. Although the last makes sense from a classic Unix perspective, I have yet to discover a reason for the other examples of needless cruelty to administrators and field techs alike.

SAN administrators will welcome a utility that Apple released too late for me to test extensively: the Xsan Tuner application, which is more than just a front end for the Bonnie I/O-measurement tool. Xsan Tuner allows administrators to set up live workstation-to-SAN I/O scenarios with either classic Unix-style sequential blocks or multiple streams, as one would use with applications such as Final Cut Pro.

Although the $999 price tag might have been the initial eye-catcher, Xsan’s appeal is the ease of management. The most frustrating lapses are the inability to manage data itself and the lack of communication between the Xsan Admin and StorNext client, but fixing the first would add an extra “9” on the price tag, and the second is intractable, being rooted in the security models of the “alien” OSes.

No, Xsan’s not a SAN-in-a-box, nor is it meant to be. What it is, is a very good port of a powerful file system that brings smaller -- if deep-pocketed -- enterprises into the petabyte club. It’s not something to use for heavy-traffic situations, but when you have to move a lot of data in a hurry, it’s fast.

— Mario Apicella contributed to this review

InfoWorld Scorecard
Manageability (20.0%)
Value (10.0%)
Ease of use (10.0%)
Scalability (20.0%)
Setup (10.0%)
Interoperability (10.0%)
Performance (20.0%)
Overall Score (100%)
Apple Xsan 1.1 7.0 10.0 8.0 10.0 9.0 7.0 8.0 8.4