Do we want to continue using a SAN in our future fileserver design?

September 25, 2015

Yesterday I wrote that we're probably going to need a new Linux iSCSI target for our next generation of fileservers, which I optimistically expect us to begin working on in 2018 (when the current ones will be starting to turn four years old). But as I mentioned in an aside, there's a number of things up in the air here and one of them is the big question of whether we want to keep on using any sort of SAN at all or move to entirely local storage.

We had a number of reasons originally for using an iSCSI SAN, but in practice many of them never got used much. We've made minimal use of failover, we've never expanded a fileserver's storage use beyond the pair of backends that 'belong' to it, and while surviving single backend failures was great (cf), a large part of those backend failures was because we bought inexpensive hardware. If our current, significantly better generation of hardware survives to 2018 without similar large scale failures, I think there could be a real question about carrying on the model.

I've written about our general tradeoffs of a SAN versus disk servers and they remain applicable. However, two things have changed since writing that last year. The first is that we now have operational experience with a single fileserver that has a pile of disk space and a pile of load on it, and our experience overall is that we wish it was actually two fileservers instead. Even when we aren't running into OmniOS issues, it is the fileserver that is most prone to have problematic load surges and so on, simply because it has so much disk space and activity on it. One thing this has done is change my opinion about how big a disk server we'd want to have; instead of servers as big as our current fileservers with their paired backends, I now think that servers roughly half the size would be a good choice (ie, with 8 pairs of data disks).

The second is that I now believe we're going to have a real choice of viable OSes to run ZFS on in 2018, and specifically I expect that to include Linux. If we don't need iSCSI initiator support, need only a medium number of disks, and are willing to pay somewhat extra for good hardware (as we did this generation by avoiding ESATA), then I think hardware support in our OS of choice is likely to be much less of an issue. Put bluntly, both Linux and FreeBSD should support whatever disk controller hardware we use and it's reasonably likely that OmniOS will as well.

There are unquestionably downsides to moving away from a SAN (as I covered, and also). But there are also attractive simplifications, cost savings, and quite possibly performance increases (at least in an all-SSD environment). Moving away from a SAN is in no way a done deal (especially since we like the current environment and it's been quite good for us) and a lot can (and will) change between now and 2018, but the thought is now actively in my mind in a way that it wasn't before.

(Of course, part of this is that occasionally I play around with crazy and heretical what-if thoughts about our architecture and systems. 'What if we didn't use a SAN' is just one iteration of this.)

Comments on this page:

By Robert Sander <> at 2015-09-25 08:44:11:

Have you thought about a Ceph cluster as your backend storage for the fileservers?

You would present RBD (rados block devices) to your fileservers like you would do it with iSCSI LUNs.

By cks at 2015-09-25 15:05:43:

We very specifically want ZFS to be handling the storage redundancy, because we feel it is going to do this better than anything else. Given this I don't think a Ceph cluster or the like is going to be particularly better at presenting remote disk space to ZFS, especially given that iSCSI initiator drivers are likely to be more generally available than RBD drivers. iSCSI provides a very direct, accessible, and understandable mapping of disk space here to disk space there, after all.

(A while back I wrote about other aspects of this in DismissingISCSIAlternatives.)

Written on 25 September 2015.
« We're probably going to need new Linux iSCSI target software
I've decided I'll port DWiki to Python 3, but not any time soon »

Page tools: View Source, View Normal, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Fri Sep 25 01:20:47 2015
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.