Apple introduces Xsan Storage Area Network file system

Apple today introduced Xsan, a high-performance, enterprise-class Storage Area Network (SAN) file system priced at the industry

10 Comments

  1. This is good stuff. SANs are so useful for cutting your server support costs by consolidating onto less boxes. I can imagine a lot of univerisites and video or biotech houses are going to implement this very quickly. Might even be a way for Apple back into the enterprise server rooms.

  2. Apple Xserve RAID/Xsan: 42TB, dual metadata servers, fully-specced, 2 16-port Fiber switches. Price – $250,000.

    IBM FastStor: 42TB – $1,500,000 last time I did the sums.

    Neither includes racking, UPS, cabling etc, but I don’t see that as altering the overall picture.

  3. Tom:

    If you’re still interested, here’s the answer.

    Microsoft’s DFS (I can’t remember if it’s DfS or Dfs) allows an enterprise to present multiple virtual views of data, whilst maintaining data in only one physical location.

    For instance, a global marketing server cluster could present DFS shares that effectively ‘point’ at regional marketing data shares situated at a local levels. So far it sounds like an alias or link, except unlike an alias or a link, the DFS share contains a degree of in-built functionality and resilience i.e. if the primary target share fails, the DFS share can understand where to fail-over.

    Xsan does something completely different: if you buy an IBM FastStor 700 and load it, you get a 42U rack with a controller box (typically with two FC ports, and redundant power/fans) which then links to a maximum of 22 10-disk shelves, albeit not through FC. Therefore, in the IBM model, you get a maximum of 220 disks (I think they now ship 146GB) which gives a maximum of 32TB or thereabouts.

    Xsan appears to completely throw the concept of marketing-driven limitations (i.e. the maximum number of shelves) out of the window; this is made possible simply because so much of the intelligence is maintained within the Xserve RAID units which continues to be the basic building block of Apple’s SAN strategy.

  4. The simplest view of Xsan is that it is – to all intents – a storage traffic cop. What Apple is calling a NAS headend appears to make an initial request to an Xsan metadata server, and then gets directed as to which Xserve RAID unit(s) the data is situated on. The NAS headend then presumably manages the relationship with the nominated Xserve RAID units.

    So whilst DFS is maintaining a distributed view of data at the share/network OS level, Xsan appears to maintain the view at a lower storage block level.

  5. MCCFR:
    thanks very much for the explanation. i was under the impression that Dfs appeared to show data in one location to the user when, in fact, it was distributed among various sotrage devices. this would appear to be similar to Xsan, according to your explanation. why would Dfs make it look to the user that the data is in different places when it’s just in one? also, is it technically more advantageous to, as you say about Xsan, maintain the distributed view at a “lower storage block level”? would that make it more stable, secure or improve access? sorry for all the questions but my workplace is looking into Dfs and I’m just trying to understand it because we also have Macs on the network and I’m interested in it’s possible impact on them. If Xsan is, in any way, superior, it would be nice to investigate it also.

    again, thanks,
    tom

  6. Tom,

    Perhaps I wasn’t clear – Dfs does, as you say, make data appear as if it is in one location. However, what I was saying is that Dfs manages that process for Windows server operating systems since NT 4.0 as opposed to using ‘links’ which, in Windows, is fatally flawed anyway – create a link in Windows and then erase the original target, enjoy the ensuing confusion when you try to access the link.

    Xsan is acting as a storage manager and neither knows nor cares about security, whilst Dfs does. However, Dfs doesn’t care about RAID levels and physical storage locations whilst Xsan does, especially when combined with the ADIC product.

    In reality, the two things are actually complementary, as opposed to mutually exclusive so I hope that answers your question.

    However, a word of caution: I’m pretty sure that the Dfs database is actually run – as many MS products are – using the JET engine that has its origins in MS Access; it does work well, but it has limits and will need to be backed up in a disciplined way.

    I’m relatively certain that it will get changed to use a proper database over time, probably when MS implements all of the features in WinFs that were intended for Longhorn but will now follow in a later product.

Reader Feedback

This site uses Akismet to reduce spam. Learn how your comment data is processed.