BLOGS: My COW Blog Adobe Blog Editing Technology After Effects Final Cut Entertainment

Final Cut Server - XSAN redux

COW Blogs : 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.

Posted by: Jeff Handy on Jan 29, 2010 at 9:02:12 amComments (1) final cut server, post production workflow


The LAN isolation has to deal
by Paolo Ciccone
The LAN isolation has to deal with the way Ethernet works. Having smaller traffic, lower number of packets on the net creates better response. If your machines have one network card and they both access the world at large and the xsan then your xsan is competing with the high outside traffic. One way to solve this is to install two cards in each machine and set your routing tables carefully so that one card serves the xsan and doesn't get involved with the outside traffic.

Of course you need also to have the server isolated on its own physical network but I assume that that is already the case.

Good luck.

Editing, managing and innovating media for higher education.
© 2020 All Rights Reserved