Posts Tagged ‘fibre channel’

Unity Best Practices In AVID Environments

Thursday, September 6th, 2012

Avid Unity environments are still common these days because the price for Avid’s ISIS SAN is tremendously high. While a Unity typically started anywhere from $50,000 to $100,000, a typical ISIS starts around the same price even though the ISIS is based on more typical, less expensive commodity hardware. The ISIS is based on common gigabit networking, whereas the Unity is based on fibre channel SCSI.

Avid Unity systems come in two flavors. Both can be accessed by fibre channel or by gigabit ethernet. The first flavor is all fibre channel hardware. The second uses a hardware RAID card in a server enclosure with a sixteen drive array and shares that storage over fibre channel and/or gigabit ethernet.

Components in a fibre channel only Unity can be broken down so:

  • Avid Unity clients
  • Fibre channel switch
  • Fibre channel storage
  • Avid Unity head

Components in a chassis-based Unity are:

  • Avid Unity clients
  • Fibre channel switch
  • Avid Unity controller with SATA RAID

The fibre channel only setup can be more easily upgraded. Because such setups are generally older, they typically came with a 2U rackmount dual Pentium 3 (yes, Pentium 3!) server. They use a 2 gigabit ATTO fibre channel card and reliability can be questionable after a decade.

The Unity head can be swapped for a no-frills Intel machine (AMD doesn’t work, and there’s not enough time in the world to figure out why), but one must take care to be careful about video drivers. Several different integrated video chips and several video cards have drivers which somehow conflict with Unity software, so sometimes it’s easier to simply not install any drivers since nothing depends on them. The other requirements / recommendations are a working parallel port (for the Unity dongle), a PCIe slot (for a 4 gigabit ATTO fibre channel card) and 4 gigs of memory (so that Avid File Manager can use a full 3 gigabytes).

The fibre channel switch is typically either a 2 gigabit Vixel switch or a 4 gigabit Qlogic 5200 or 5600 switch. The older Vixel switches have a tendency to fail because there are little heat sinks attached to each port chip which face downward, and after a while sometimes a heat sink or two fall off and the chip dies. Since Vixel is not in business, the only replacement is a Qlogic.

The fibre channel storage can be swapped for a SATA-fibre RAID chassis so long as the chassis supports chopping up RAID sets into many smaller logical drives on separate LUNs. Drives which Avid sells can be as large as 1 TB if using the latest Unity software, so dividing up the storage into LUNs no larger than 1 TB is a good idea.

Changing storage configuration while the Unity has data is typically not done due to the complexity and lack of proper understanding of what it entails. If it’s to be done, it’s typically safer to use a client or multiple clients to back up all the Unity workspaces to normal storage, then reconfigure the Unity’s storage from scratch. If that is what is done, that’s the best opportunity to add storage, change from fibre channel drives to RAID, take advantage of RAID-6, et cetera.

Next up is how Avid uses storage. The Unity essentially thinks that it’s given a bunch of drives. Drives cannot easily be added, so the only time to change total storage is when the Unity will be reconfigured from scratch.

The group of all available drives is called the Data Drive Set. There is only one Data Drive Set and it has a certain number of drives. You can create a Data Drive Set with different sized drives, but there needs to be a minimum of four drives of the same size to make an Allocation Group. Spares can be added so that detected disk failures can trigger a copy of a failing drive to a spare.

Once a Data Drive Set is created, the File Manager can be started and Allocation Groups can be created. The reasoning behind Allocation Groups is so that groups of drives can be kept together and certain workspaces can be put on certain Allocation Groups to maximize throughput and/or I/O.

There are pretty much two different families of file access patterns. One is pure video streaming which is, as one might guess, just a continuous stream of data with very little other file I/O. Sometimes caching parameters on fibre-SATA RAID are configured to have large video-only or video-primary drive sets (sets of logical volumes cut up from a single RAID set) are set to optimize streams. The other file access pattern would be handling lots of little files such as audio, stills, render files and project files. Caching parameters set for optimizing lots of small random file I/O can show a noticeable improvement, particularly for the Allocation Group which has the workspace on which the projects are kept.

Workspaces are what they sound like. When creating a workspace, you decide which Allocation Group that workspace will exist. Workspaces can be expanded and contracted even while clients are actively working in that workspace. The one workspace which matters most when it comes to performance is the projects workspace. Because Avid projects tend to have hundreds or thousands of little files, an overloaded Unity can end up taking tens of seconds to simply open a bin in Media Composer which will certainly affect editors trying to work. The Attic is kept on the projects workspace, too, unless explicitly set to a different destination.

Although Unity systems can have ridiculously long uptimes, like any filesystem there can be problems. Sometimes lock files won’t go away when they’re supposed to, sometimes there can be namespace collisions, and sometimes a Unity workspace can simply become slow without explanation. The simplest way to handle filesystem problems, especially since there are no filesystem repair tools, is to create a new workspace, copy everything out of the old workspace, then delete the old workspace. Fragmentation is not checkable in any way, so this is a good way to make a heavily used projects workspace which has been around for ages a bit faster, too.

Avids have always had issues when there are too many files in a single directory. Since the media scheme on Avids involves Media Composer creating media files in workspaces on its own, one should take care to make sure that there aren’t any single directories in media workspaces (heck, any workspaces) which have more than 5,000 files. Media directories are created based on the client computer’s name in the context of the Unity, so if a particular media folder has too many items, that folder can be renamed to the same name with a “-1″ at the end (or “-(n+1)”).

Avid has said that the latest Media Composer (6.0.3 at the time of this writing) is not compatible with the latest Unity client (5.5.3). This is not true and while certain exotic actions might not work well (uncompressed HD, large number of simultaneous multicam, perhaps), all basic editing functions work just fine.

Finally, it should be pointed out that when planning ways to back up Unity workspaces, Windows clients are bad candidates. Because of the limitation on the number of simultaneously mounted workspaces being dependent on the number of drive letters available, Windows clients can only back up at most 25 workspaces at a time. Macs have no limitation on the number of workspaces they can mount simultaneously, plus Macs have rsync built in to the OS, so they’re a more natural candidate for performing backups.

The All New Promise x30

Wednesday, April 13th, 2011

Yesterday, we mentioned Thunderbolt adapters for Xsan. But NAB 011 isn’t over and we have more announcements to bring up. Promise has announced their all new x30 series. With a spiffy new chassis design, these things now sport 8Gbps controllers, up to 48TB of space and up to 8 in a stack (that’s 7 expansion per chassis).

Oh, and we’d be remiss not to mention the redesigned management screen, a massive improvement over the command and control pane of glass we had before! A web-based management tool, by the way, that works on iPad! And management is easier now that you don’t have to restart the units every time you need to make a software update.

For more information on the new Promise x30, see:

http://www.promise.com/storage/raid_series.aspx?region=en-US&m=1053&sub_m=sub_m_8&rsn1=40&rsn3=48

To discuss how 318 can assist your organization in leveraging these new tools from Promise, from integrating a fleet of MacBook Pros with Xsan to bolting on additional storage for the always-full Xsan, contact your 318 Professional Services Manager, or sales@318.com if you do not yet have one!

Thunderbolt Adapters for Xsan

Tuesday, April 12th, 2011

As usual, there’s plenty to talk about after NAB. One of 2011′s favorites for us so far is the ability to attach a MacBook Pro to an Xsan using one of the newly introduced Thunderbolt -> Fibre Channel adapters.

The above adapter, from Promise, allows for 4Gbps and is “Fully Qualified” for Xsan. This allows the mobile user to be a first class citizen in a fibre channel SAN environment, not having to go through slow NAS heads to access large files, but instead connecting directly to Xsan or other fibre channel solutions!

For more, see http://www.promise.com/storage/raid_series.aspx?region=en-US&m=1054⊂_m=sub_m_8&rsn1=40&rsn3=49

Troubleshooting AFP Performance on Xsan

Wednesday, August 29th, 2007

Troubleshooting steps for an Xsan volume acting as an AFP Bridgehead:
1. Fragmentation – Run the SNFS defrag utilities per the article on Xsanity that I referenced earlier. This will most likely give the biggest bang for the buck in terms of troubleshooting time.
2. DNS – Rule out DNS by using IP address for all users. This is basically not a DNS issue, but we need to be sure.
3. Number of files and size of files. Try to limit each folder to 100 files for now just to see if there is an issue with 1000 vs 100 files (and keep in mind that subfolders count for file sizes).
4. 3rd party indexing applications. Try to temporarily not use any 3rd party indexing applications.
5. Backups during the day. Try to verify that Atempo is not running during the heavy utilization of the SAN (during the day).
6. Encryption. Do not use AFP over SSH (Secure AFP).
7. Switching. Review the switching infrastructure and disable all features that could be limiting bandwidth.
8. DAS. Test using a little Direct Attached Storage where possible to verify that issues are definitely related to resharing of the SAN as opposed to using DAS.
9. AFP Tuning. Consider enabling Jumbo frames. This likely will not net a performance gain but it’s always worth a shot.
10. Network Home Folders. If you’re trying to run any network home folders off the SAN try disabling this for the initial roll out.
11. Wiring. Verify that all wiring is clean Cat 5e or Cat6 cables. I realize this is kinda’ stupid considering you were using all new patch cables that I pulled out of the bags, but please just look through them and make sure they’re good.
12. Infrastructure. From a switching perspective make sure that there aren’t any bottlenecks along the way where there is a switch feeding another switch with a 100MB or sole gigabit cable stacking the two. If you need to stack, use a real stacking cable (typically giving a 10GB backplane link between switches)
13. LUNS. Make sure you have enough LUNs to provide the bandwidth. I believe we’re at 2GB per Volume, so you should be good here, but just wanted to mention that.

These steps should at a minimum help us to narrow down what issues you are running into. You can also use the debugger in Xsan, and get very verbose logs. With these logs we might be able to find some more issues, but make sure to disable this feature shortly after enabling it as it will fill up your boot volume of the machine running it.

Also, Kerberos and LDAP issues are likely not going to net any bang for the buck in terms of troubleshooting. Can you mount the volume for clients? Yes, which likely rules out any OD issues. Just an FYI to help conserve valuable time in isolating your bandwidth issues.

We have seen fragmentation cause this a few times and this may resolve the issue. If so, it will reoccur and when it does you will need to defrag again. Due to the effect that a defrag has you will likely find you need to rebuild the volume from scratch to clear up the orphaned iNodes caused by the defrag process.