Q&A: XenData Co-founder/CEO Phillip Storey

Phil Storey: The archive process is sending files to a Windows server running our software with some built-in RAID storage. There’s a Windows share sitting on the network, either using CIFS/SMB Windows network protocol or FTP, and they’re actually putting files onto a [network] share. Our software completely manages that share. A policy set up by the user of the system might say, “Any files written to this folder will go to this pool of tapes.” That policy might specify that, for every tape, a duplicate will be made so you’re writing to two tapes. As soon as the file is on the designated tapes, the policy might be to replace the file on disk cache, on the RAID, with a sparse file – commonly called a stub file. The file is not actually on the RAID, and it will take a couple of minutes for the start of the restore to happen when you get a standard read request.

It depends on what the policies are. The RAID might be as small as 2 TB. The tape that goes with that could be hundreds of terabytes. But the RAID is essential to overcome the limitations of tape. Tape is great because it’s really fast once you’re at the right point on the tape, whether’re you’re writing or restoring, and by using RAID we’re able to overcome the wait times, certainly while you’re writing to tape. You just need enough RAID to act as a buffer.

But in the other direction, restoring from tape, that’s still going to take some time.

There’s no way around that, but you can set policies with our software and say that you want to keep everything written in the last week on the RAID, for example.

When you have a really busy system, you need to make sure your RAID is fast enough for your archive process. On restore, there are two elements. You can design system with enough raid for 30-day retention or something like that, but then you get into figuring out how many tape drives you need if you’ve got masses of restores coming. That’s part of sizing the system, really.

What makes your system especially suited for video libraries?

One reason is that we use the tar tape format. LTO tapes have a 30-year life, so if you are putting together an archive that needs to last a very long time, you want to have a format written on tape. From that tape you might have an MOV or AVI that needs to be restored, but historically companies have used proprietary formats for headers written on tape. We just use the standard tar format, which is an open standard that can be used to restore the file if we’re not around in 25 years. You could just connect up an LTO-5 drive to a Linux machine and you could restore our files.

Another reason we’re especially good for service organizations that store data on behalf of their clients is our X1500, which was announced at NAB last year. It’s a relatively low-cost system that makes it easy for an end user to restore files on a Windows 7 machine. The customer just hooks up an LTO-4/5 drive to a Windows 7 tower or desktop, takes the tape that comes from the service organization, and within a couple of minutes they can be dragging and dropping files using explorer onto their own network. That’s $5200 for an LTO-5 system. It’s an archive system in its own right, but it works very well with a service organization having a tape library and XenData server software system, because they can send out tapes to their customers, who can then restore them very easily.

How scalable is the system?

Just put in more servers and partition up a big library. That’s re:fine’s intention. They’re just using one at the moment, but they’ll add in additional servers and partition their library into logical libraries, and they’ll be able to scale that throughput. But even with one server, they can set up folders, which are then made shares with particular permissions, and then they can map those to their own pools of tapes. Again, if you’re a service organization with a lot of customers and you want to make sure there’s no mixing of material, that’s a great way to avoid it.

Can you talk more about how the operations of your typical customers and how specifically they use your software?

Well, we’re just one component within an often-complicated infrastructure. Modern Video Film basically takes in video material from a client, checks it for quality, archives it, and makes it available for download. A lot of TV stations simply use the product to move files from their video servers to the archive and back. But the fundamental functionality is the same – making tape appear like a standard share on the network.

Earlier, you mentioned using partitions and extra servers to scale throughput. Can you explain that process in more detail?

If you’ve got so much throughput that a single Windows server isn’t gong to be fast enough for it, all of the larger LTO tape libraries support partitioning, which is a function of the smarts of the firmware in the tape library, allowing the library to be partitioned into multiple logical libraries. If you have a 3000-slot tape library, as they do at Re:fine, as they expand they can say, I’ve got 500 slots and four LTO drives associated with one logical library controlled by one server running XenData software. And then I’m going to create another five that are just the same, each with their own server. You would go that route to scale up the throughput of the system. You’d have fibre-channel connection between the servers and each of these logical libraries.

Can you give us a preview of anything else we’ll be seeing from XenData in the near future?

We will be making an announcement in March about online archives. Traditionally our business has been using RAID to enhance storage to LTO tape. We’ve got something coming out in March kind of using LTO tape to enhance high-capacity RAID storage. I’ve probably said enough already – but we will be showing that at NAB.

For more information: www.xendata.com.