Xsan and Youby Scott Murphy
This is a great time to be a part of the video-production/post-production industry, and one of the most exciting aspects of production-house technology is Xsan (storage area network).
Why, you ask? I asked the same thing: What's so exciting about the ability to share files with everyone in my facility? I can do that now, right? I just connect my FireWire hard drive to my computer, copy the files, walk to the other machine, and copy the files back. Wait, that just took me an hour. What if I could just save those files to a volume that everyone has access to? A volume that behaved almost exactly like direct attached storage? That's Xsan. This product will change the way many of us work, and save us money while doing so.
A Practical Example of Xsan at Work
Just for a moment, imagine you work at a really kick-ass, medium-size post house. Let's say you have four edit suites, with each of them set up to do uncompressed SD from Betacam SP, Digital Betacam, and DVCam. So, each suite has three video tape recorders (VTR), a really nice capture card, and a directly attached Xserve RAID. Yes, you have a few dollars invested here.
Imagine now that you have that same medium-size post house, but with Xsan too. You still have four edit suites. But instead of 12 VTR's, four really nice capture cards, and four Xserve RAIDs, you have three VTR's, one really nice capture card, three decent capture cards used solely for monitoring, and three Xserve RAIDs. As you'll see later in the article, the efficiency Xsan brings to the production system allows you to save money on hardware.
Xsan is not just about saving money, it's about saving time. Work smarter, not harder. In our kick-ass, medium-size post house, Kick Ass Post, we sometimes have multiple editors working on the same project, and in its current state we have the intern running around copying files to the systems. (Poor intern. What a pain, copying files all the time. Never getting a chance to even use Final Cut Pro (FCP)--not to mention ever having time to get us coffee.) Anyway, what if this intern sat in Kick Ass Post's core, ingesting footage onto the Storage Area Network (SAN)? This solves a ton of problems in one fell swoop. No replication of data, the intern learns how to log and capture in FCP, and he has time to get us coffee. Not only that, but we can store more than just new raw footage on the SAN.
Let's say we are cutting an Acme Widgets spot, and we need some stock footage. Normally, we would go get one of our Thinkstock DVDs and copy the files onto the system. If we have a SAN, we could put all of our most used stock footage onto the SAN in a special stock footage directory. We could even set up that directory as read only, and more than that, we could store that directory on a set of drives in RAID 0--fast performance, but no redundancy. Do we care about redundancy when it comes to stock footage? No, we have the DVD. This goes for anything like stock footage, music, stock graphics, anything that we use frequently but don't have to change very often.
OK, now that you've seen a practical example of Xsan in the production environment, let's talk numbers. The first number is 64. Xsan is a 64-bit file system. It takes advantage of all of the power of the G5 processor. You can connect up to 64 nodes to one Xsan system. What's a node? A node is a computer connected to the SAN, whether it's the metadata controller or a client. Wait, what's a metadata controller? I'll get to that in a minute.
More numbers: Xsan can have volumes up to 16 terabytes in size in Panther; once we make it up to Tiger we will be able to have volumes up to 2 petabytes--that's over 52,000 40GB iPods. Another important number: 20. Xsan operates at speeds 20 times faster than typical network storage, since it uses 2 gigabit per second Fibre Channel protocol for its data transfer. And now for the number you've all been waiting for: 999. Each license of the Xsan software costs $999. You will need a copy for each node.
Let me cover a few more terms. We already know that a node is a computer connected to the SAN. The metadata controller (MDC) is the SAN file traffic cop. It controls the read and write access for the files. If you want to save a file, your computer has to ask the MDC for a token that allows it to have write access. Once you have this token you can write the file, and when you're done writing, your computer returns the token.
Xsan uses a separate Ethernet network to pass these tokens, so that the Fibre Channel network is free to just pass the file data back and forth. In most cases, this means that you'll be hooking up two Ethernet networks with your Xsan nodes, one for metadata and one for general IP networking, such as web and email access.
An Xsan volume is made up of storage pools. A storage pool is made up of a group of LUNs that have the same size and RAID level. What is a LUN? A LUN is a group of drives, which are RAIDed together. Another important concept to understand is affinities. An affinity allows you to specify the routing of data to specific LUNs in the storage pool. Like our stock footage, this allows data to have the best performance and the most practical security level.
Quotas are also a part of Xsan: you can set hard and soft quotas for every user on the SAN. A quota is basically how much space a user can take up on the SAN. A soft quota lets the user continue to save files but warns them that they are over their limit. When they reach the hard quota they will not be able to save any more data until the SAN administrator gives them more space. Or they delete some files.
Whoa, that's a lot of new terms. Does this seem a bit overwhelming? Just wait; it gets worse before it gets better. Implementing an Xsan system most certainly means that you are going to have to set up a centralized directory, which for small systems, can be hosted on the MDC. This is a fairly straightforward process as long as you know what you're doing.
You also have the option of binding your Xsan nodes to a preexisting directory, either Apple's Open Directory, or a Windows Active Directory. Once you have your directory running and each user has a unique user ID, things will run smoothly. This is because Xsan identifies the user based on his or her numerical UID. When you buy a new Mac and create the first user, its UID is automatically set to 501. Imagine you buy five new G5s to plug into your SAN and you don't have a centralized directory running. All of the users could have the same UID and that could really mess things up.
OK, this gives you a pretty good idea of what Xsan can do and how it will change the way you work. If you glean one thing from this article, besides how cool Xsan is, it should be that you will need the guidance of someone who is not only an expert in the video realm, but someone who also knows a lot about Ethernet and Fibre Channel networking, OS X Server, and Unix in general. Once you have people with this kind of knowledge in place you could be humming along just like Kick Ass Post. If you have any questions about Xsan systems or integration, just post it in the talkbacks below.
Return to MacDevCenter.com.
- Trackback from http://www.treffend.com/archives/48932.html
Adventures in Troubleshooting: Xsan and You
2005-08-03 04:45:49 [View]
2005-08-01 13:40:30 BrianTomas [View]
2005-08-02 02:42:40 BrianTomas [View]
2005-04-11 13:53:59 bforcier [View]
2005-04-09 09:40:43 MacDave [View]
2005-04-08 08:21:42 omerine [View]
2005-04-07 00:55:25 anonymousone [View]
2005-04-08 16:33:17 austinwallender [View]
2005-04-06 16:04:31 DylanM [View]
To be an XSan client...
2005-04-06 16:27:39 ScottMurphy [View]
2005-04-06 05:42:48 SteveDuncan [View]