Xsan Xamination – 1
Apple’s new Xsan 2, launched on February 19th, is more than a standard SAN (storage area network) but does its stuff inside an Apple semi-walled garden. The basics, the hardware basics, are recognisable but the software layered on them is some way removed from a typical datacentre SAN. However there are doorways into and out of this walled Apple garden.
Starting at the far end of the SAN, with the disk drive arrays, Apple has recently discontinued its own Xserve RAID disk arrays in favour of Promise Technology’s VTrak arrays. These have up to 16 drives, 32 with an expansion cabinet, and performance that is markedly superior to the Xserve RAID. The VTrak just has a far superior RAID controller and dual 4Gbit/s FC ports. It screams whereas the older XServe RAID lags behind.
The VTrak is almost twice as as Xserve RAID with sequential writes and more than three times as fast with sequential reads. It is much faster than the XServe RAD for multiple video streams.
Next up the SAN stack is a Final Channel switch, one from Brocade, Cisco or QLogic, and offering 4Gbit/s performance.
So far so ordinary, but from here things start becoming different. The next item is a metadata controller, a dedicated Mac OS X server that stores the metadata for the Xsan software. This SAN is virtualised and all accesses to its block data come through this metadata controller, which is hooked into the switch.
There can be multiple metadata controllers with failover between them to ensure SAN availability. Each volume in the SAN can have a dedicated metadata controller. Failover completes in a seconds or possibly less than a second.
Think of a metadata controller it as being roughly equivalent to IBM’s SAN Volume Controller (SVC) in that it virtualises the SAN disks, but it does more than this. Through it the Xsan has a 64-bit clustered file system with volume sizes up to 2 petabytes and billions of files per volume.
The clustering refers to the clustering together of separate RAID arrays into one logical pool of storage. Other suppliers, such as HDS and IBM and EMC and DataCore, call this SAN storage virtualisation.
The Xsan file system is similar to SGI’s InfiniteStorage Filesystem (CXFS) and Symantec/Veritas’ Storage Foundation Cluster File System. Think of it as receiving file requests from servers which it translates to LUN and then block requests and maps these to actual drives.
Note, although this is a file system and the underlying Mac OS X does have AFS, CIFS or NFS capabilities; it is not recommended that it function as a network-attached storage (NAS) facility as well as a metadata controller for performance reasons. For NAS functionality a separate Xserve is suggested as we’ll see below.
One of Xsan 2′s capabilities is that multiple users can access storage volumes concurrently with read and write access. (To this extent it is NAS-like but it is not a NAS.) There is file locking and byte-level locking to manage this simultaneous access and preserve access while parts of a file are being written to.
Next up the stack we have 4Gbit/s FC links to accessing Apple servers and Mac clients, each of which is fitted with a dual- or quad-pathing Apple Fibre Channel PCI Express card, or, in common SAN parlance, HBA (host bus adapter). The multi-pathing is for protection against cable breaks. These HBAs are manufactured for Apple using an LSI Logic reference chipset.
The Xsan file system is journaled to help recovery from a metadata controller rash where there isn’t a backup metadata controller.
Now click here to go to Flowers in the garden.