: Jeff Handy's Blog
: Final Cut Server - XSAN redux
Our XSAN volumes are set up all wrong, unfortunately. Apparently the person put in charge of our XSAN implementation has had no training and now we're faced with some pretty major roadblocks. I had previously purchased a book on XSAN and he's studying it now. I also found some very helpful info on the xsanity wiki page which has some sample diagrams of some install examples. We have a few serious flaws in our layout that will cause us quite a bit of pain. However, if we don't suffer through the process of reconfiguring XSAN, we will certainly be on a path for failure with Final Cut Server. It is a bandwidth hog if being used properly. And we cannot afford many hiccups in production.
First off, each RAID is it's own volume and contains and controls its own metadata. I can see from the examples, that we should have built our raids (aka LUNs) so they were grouped into same-sized sets (aka Pools) over different controllers. XSAN treats the same-sized LUNs in a Pool as disks and writes to them in parallel - emulating the same effect as a type zero striped RAID. As they are configured, we are getting about 120MB-150MB/sec. If properly configured, we should be getting 2-3 times that performance.
I think what we'll try to do is to move as much media as we can to as few volumes as possible. Then, when we get our new RAID in a few weeks, build a new single volume using the techniques outlined in the XSAN documentation. I expect this entire process will take about a week in all, once the new system is here. The order was made for the same sized drives and all, so at least it will match what we already have. I guess we need to be sure to earmark part of each raid for metadata. According to Apple's documentation, we need about one gig per terabyte. We are using way more than that on our current configuration. So between that change plus consolidating the drives, we stand to regain a major amount of usable space.
These changes will be a great deal of work, but will net us much better performance and about one extra terabyte of space. On top of that, I'm not about to build an entirely new database and add tons of files to a much less than optimal infrastructure. I take the perspective that you cannot build a house atop shifting foundation.
Another flaw that I'm unsure of is that our Macs are not on an isolated LAN. I have seen folks argue, and the documentation supports, that SAN systems need to be on a LAN separate from the rest of the company. I don't see any particular cases of what this recommendation is based upon. And our MIS director seems to think such a construction would be excess. I admit that I cannot argue decisively on this issue. If anyone has some documentation, other than what I mentioned here, please do pass it along.