Best Practices: 4

Planning

By far, the most important component of a great Xsan is great planning. Speak to people with experience. Use our forums to look for common problems and post questions. Find an similar configuration in our setup library, and ask the author for ideas. If you can, hire a consultant with experience (and great references).

Components

There is significant infrastructure in a typical Xsan installation. Please refer to our list of Xsan components to understand the pieces of the puzzle.

Ethernet networks

Metadata is used in every SAN transaction. Clients exchange metadata with the MDCs over Ethernet. This is the most latency-sensitive route in your SAN. Keep this channel completely separate from your "public" Ethernet traffic. Business-class (managed) switches have lower latency than consumer-class switches. On your MDCs, use "sudo lsof -ni4 | grep fsm" to see what networks your clients are really using to connect.

Fibre Channel network

• Use high-quality modern fibre channel switches. These are the basic plumbing of your network.
• If you use more than one switch, design your port layout to minimize latency. FC latency increases dramatically when jumping from switch-to-switch. MDCs need to communicate with MD LUNS, not with storage LUNs. Clients need to communicate with storage LUNs, not with MD LUNs. Keep MDCs and MD LUNs on the same switch, and clients and storage LUNs on the same switch.
• Set up single-host zoning to protect your SAN from rogue equipment

Single-task servers

As much as possible, keep a single server restricted to a single task. Several problems can happen when you mix services on a server. 

• One task can steal resources from another, increasing latency on your SAN (i.e., you drop frames)
• Tasks can interfere in odd ways
• Troubleshooting gets to be very hard

Directory Services

Xsan is a shared file system for an operating system that was intended for exclusive file systems. If you don't use directory services, you will have problems when the OS assumes it owns the disk. We've seem problems with trash cans misused, temporary files colliding, and even video capture problems.

Use a directory services system such as Open Directory or Active Directory to keep your users separate. Every user must connect to the Xsan volume using a unique user name and user ID.

DNS

• Run a DNS server. 
• Make sure your MDCs are listed correctly with both forward and reverse DNS records. 
• Make sure both your "public" and "metadata" IP subnets are listed in the DNS server. 
• Create a reverse domain for your private network. 
• Test your servers with "sudo changeip -checkhostname".

Metadata storage

Each Xsan volume should include a single LUN for metadata. While it is only a small amount of data, it must be on a very stable and low latency connection. Most commonly, the metadata LUN gets its own controller, not shared with other storage. It uses three disks: a RAID 1 mirror with a hot spare. The RAID controller should be on the same switch blade as the MDCs, to minimize intra-switch latency.

Backups

Creating a backup solution for an Xsan can be a greater task than creating the Xsan itself. But people in the Xsanity community have created several backup methods that work well. 

At a minimum, make sure you keep a current backup of your metadata controller's config folder in /Library/Filesystems/Xsan/config/. You will need these files in case your metadata controller is unavailable.

Final Cut scratch disks

Follow Matt's recommendations for setting up your FCP scratch disks.