While none of Apple's IT offerings are suitable for cases where you need ''five 9's'' of reliability, they are all solid tools for any IT manager. Their latest offering is the company's initial entry into the Storage Area Network (SAN) Market -- Xsan.
As advertised, Xsan is ''The SAN File System for Mac OS X.'' It is Apple's OEM version of ADIC's StorNext File System, which is designed to be used in a SAN environment. One thing to note here, Xsan is not a ''SAN in a box'' solution that other vendors, such as HP or EMC, offer. Xsan is a file system and basic management software only.
So, if you're buying Xsan with an eye on using it as part of an Information Life Management(ILM) solution, you're going to have to pony up more budget and resources for additional components, such as ADIC's StorNext Storage Manager, or some other solution.
However, one thing to remember with Mac OS X and SAN is that for the moment, XSAN/StorNext is really the only SAN product that Mac OS X machines can participate directly in. While this will hopefully change soon, for now, if you don't go with Xsan/StorNext, Mac OS X machines can only talk to other SANs via Windows/Linux/Unix servers acting as Network Attached Storage (NAS) heads. Fortunately, Apple has made this less painful than it could be, by charging a rather low per-machine price for Xsan. Per-machine pricing retails for $999US at the Apple Online Store, but discounts kick in at the 10-seat level, and further discounts may be obtained depending on what kind of relationship you have with Apple.
By comparison, StorNext licenses cost in the $3,000 to $4,000 range per machine for Windows, and around $2,500 for Linux boxes, not including maintenance and installation costs. With the improved Windows integration and ACL support that have arrived with Mac OS X 10.4 ''Tiger'', the cost savings of Xsan make a compelling case for using Macs as the front-end servers for a SAN, particularly if you don't have a specifc platform need.
Since Xsan/StorNext supports a wide range of operating systems and environments, you can set up the basic SAN with Xsan, and then add in other features as needed, giving you the flexibility and management advantages of a SAN, and the cost savings that Xsan provides. Hopefully, Xsan will increase the downward pressure on SAN licensing costs just as Apple's Airport did with wireless networking at the turn of the century.
Now, while Apple would like everyone to think that Xsan is the last word in storage management, there are some things that it's not really well suited for. Some of these are limitations in Apple's hardware that can be worked around. Others are limitations of Xsan/StorNext or SANs in general.
First, Xsan/StorNext are highly optimized for serving large files, such as video and audio. If you're running a video server farm, or have a video production/audio production department, running Xsan/Stornext is a no-brainer.
The next best usage for Xsan/StorNext is for managing file serving tasks. However, if you need to have a large amount of clients talking to the SAN front ends, you're going to need to plan your SAN setup carefully. Otherwise, you're going to find that while manageability has gone up, speed has dropped.
This potential speed drop is due to how Xsan/StorNext work.
In an Xsan/StorNext system, you have a machine, (preferably multiples) acting as Metadata Controllers. Since an Xsan/StorNext implementation can have multiple platforms all trying to access the same data, the Metadata Controllers, or MDCs manage file locking, space allocation, and data access authorization. While almost any computer that can run Xsan/Stornext can be an MDC -- since they are literally controlling every access to the SAN -- you want to make sure your MDCs are not lacking in speed or RAM. They really want to be on their own dedicated gigabit Ethernet network, so as to not tie up your main network with the amount of data they're pushing. Since Apple only supports the MDC's private data storage on the Xsan they're administering, you'll need to factor in that space when setting up your SAN. As the MDCs are the primary controllers for the SAN, if they die, the SAN becomes non-functional, so at the very least, you'll want two dedicated MDCs, so one can be a failover.
With the MDC issue, putting things like email and databases on Xsan/Stornext become a not-so-great idea, due to the fact that these uses create a near constant stream of requests to the MDCs, which can bog them, and the SAN, down. Apple actively discourages using Xsan for email or database function, although they don't exactly point that out in bold letters on the Xsan product site. But in conversations with Apple engineers, they were up front with this fact, and able to come up with practical ways to integrate email/databases into the overall SAN implementation, even if they aren't directly working with the SAN.
Another problem can be reliability.
Xsan/Stornext can only stripe multiple RAID LUNs into a storage pool. So, for example, if you have three of Apple's Xserve RAIDs in an Xsan implementation, and you have a storage pool that uses LUNs from each of the RAIDs. If one of those RAIDs dies, your storage pool is just as dead. For the moment, Xsan/StorNext aren't able to mirror LUNs in a storage pool, so if you need that kind of reliability, you're going to have to buy RAID hardware that will support mirroring LUNs.
(While Apple's Xserve RAID is an excellent RAID solution, it's really best to think of it as two separate RAIDs in a single cabinet. Since the current Xserve RAID version can't mirror both sides of itself in hardware, if you need that kind of featureset, you're going to have to look elsewhere for your RAID hardware.) This problem can be fixed by using different RAID hardware in the Xsan/StorNext implementation, which is easier to do since Xsan/StorNext don't force a particular RAID on you.
Obviously, Apple wants you to buy Xserve RAIDs, but thanks to the flexible architecture of Xsan/StorNext, you can use RAIDs from other manufacturers if you need higher speed and/or more reliability than Apple's RAID offering gives you.
Finally, while Xsan can be quite a bit cheaper than other SAN implementations, you have to factor in hardware costs that some SAN-in-a-box products take care of for you, such as Fiber Channel (FC) interface cards for your servers, FC switches, cabling, support, space, etc. Even a relatively small Xsan implementatio can approach the $100,000 range with great speed and enthusiasm.
So while it's not the ''perfect storage solution'', Xsan is, if used correctly, a solid entry into the midrange SAN field, and a compelling product for SMBs, especially those doing multimedia work, or for any company with a multimedia department.