Creative Communities of the World Forums

The peer to peer support community for media production professionals.

Activity Forums Apple Final Cut Pro Legacy 2 FCP stations on one Xserve RAID

  • Kim Rowley

    April 7, 2008 at 1:52 pm

    OK! I’ll look into the Metasan solution as well. I feel privileged to have gotten advice from some of the “top cows”. Thanks to all!

    Dual 2.7 GHz G5, 4GB RAM, ATI Radeon 9650, Xserve RAID, AJA IO, 2 20″ Cinema Display, FCP Studio 2 (6.02), OS X10.4.11

  • Matthew Nelson

    April 7, 2008 at 6:21 pm

    I’ve worked and managed MetaSAN and XSan systems and they each work well with FCP. I have not had the privilege to work with Editshare and their unity type sharing, which I find intriguing. MetaSAN would be my choice for small houses, ie 2-3 seats, and houses that have a heavy mix of platforms, because it is easier to set up, volume management is similar to direct attached volumes and it is much more agnostic then XSan.

    For a solid MetaSAN I would have 2 GigE switches one for corp LAN one for metadata with every seat issued a static IP, a fiber switch, I use a Qlogic SANBox 5600, that’s been properly zoned, a dual channel Fibre HBA for each seat, UPS’s for volumes and clients/controllers, a dedicated metadata controller, and of course a copy of metasan on each seat. MetaSAN is perfectly capable of using an edit station as a controller, as is XSan, however FCP is not the most stable of Apps and it takes about 30 sec for any backup meta controller to kick in. If someone is reading or writing to the volume during this period it can cause catalog tree problems, client crashes, and/or kernal panics to cascade through your clients.

    XSan is the better solution for larger mostly mac (Xsan can link with StoreNext windows clients) houses, 4+ seats or houses that foresee needing to grow. I say this because of the StoreNEXT file structure that XSan uses. Since metadata and storage are split, volume sizes, as well as bandwidth, can grow on the fly. Just add another RAID and it is absorbed into whatever volume(s) that are already running. Also the XSan volume itself, in my experience, is much more robust then MetaSAN, I have had major SAN meltdowns and when I got everything back online the volume itself was unaffected, no data corruption, no catalog errors. I have not had to fix my san volume in almost a year of nonstop uptime. Management does require a higher geek factor. XSan 1.4.x admin GUI is a joke I use command line for all San management. I am looking forward to implementing XSan 2 which promises a functional admin GUI.

    A solid XSan deployment has 2 dedicated meta-controllers, a primary and a backup, zoned fibre switch(s), 2 GigE switches, a meta LUN striped RAID1 with a hot spare, storage LUNs striped RAID5 with a hot spare, a climate controlled machine room, all clients bound to open directory, dual channel fibre HBA on all clients and controllers, an XSan license on all clients and controllers, UPSs for machine room and clients, and Apple remote desktop to manage everything.

    Both add more moving parts and naturally add more potential problems but despite the headaches I love having shared storage. Don’t forget cabling. I use CAT6 for ethernet, copper FC cables for connections within the machine rack and optical FC for the FCP clients.

    Matt

Page 2 of 2

We use anonymous cookies to give you the best experience we can.
Our Privacy policy | GDPR Policy