StorNext 4.0, announced on January 20, implements a number of new features that are particularly tailored to the media and post-production industries. Shawn Klein, director of software partner development and Chris Duffy, StorNext’s product marketing manager, helped break down the key points of the new release for StudioBytes’ readers.
1. Data Replication
This is a key feature for us that was actually driven by a lot of our media and entertainment customers. It does what it sounds like. We’re capable now of having customers set policies in the file system to be able to replicate from many-to-one, one to one, or one to many environments.
 
EX. Let’s say that you create a policy in the file system: you create a folder called “The StudioBytes Movie,” where all the production files for “The StudioBytes Movie” are kept. Underneath that folder you could have a sub folder called “Replicate to NY.” Any files you drop into the sub-folder will be run against the policy engine and will be replicated to the NY office.
 
The policy engine is a lot like what we have in Quantum’s StorNext Storage Manager, but with 4.0, the key difference is that we now have a policy engine in the file system, which is very unique. With that policy engine, it gives the flexibility of being able to replicate a lot of different ways depending upon what your needs are. Whether you’re replicating many remote offices into one central location or from a central location, you want to push data out to multiple remote locations. The flexibility is there for you to do whatever you want-and that policy engine makes it tick.
 
2. Deduplication
This is another very unique capability in StorNext. Past versions of StorNext have had deduplication technology embedded, but it was in the StorNext Storage Manager.  That meant that if you wanted to deduplicate data, you would pass it to the Storage Manager for data movement into a different location where the deduplication would occur.
 
What’s different with 4.0 is that we’ve moved that deduplication engine into the same file system policy engine as replication. So now you can deduplicate data placed in the file system without using Storage Manager.  This creates a powerful combination. You could actually deduplicate data and then replicate it. So you’re only moving small chunks of data as opposed to big chunks of data. Say you’re moving data from LA to NY: this feature could potentially reduce the size of the pipe you need. In another use for this feature, you may replicate the data to an off-site location and then deduplicate it once it gets there. Maybe when you first sent it to the remote location, you needed it in its raw form because you’ll have an editor working on it, but when he’s done he can deduplicate to save space and move on to the next project.
 
Overall, it allows you flexibility to move and store data in smaller quantities.
3. Distributed Data Mover (DDM)
This feature is more about performance and scalability than anything. Some of our biggest customers, especially in broadcast, have multiple petabyte-sized archives, which usually means they have tiered storage and massive tape libraries attached. They want to be able to push fresh data into the archive and pull older data out of the archive at high speeds.  Distributed Data Mover allows that ingest and retrieval to be distributed across multiple servers for optimum I/O performance.
 
Ex. Let’s say there’s a big international news company that has multiple petabytes of news clips spread across many LTO tapes inside a Quantum library with many tape drives. With DDM they can be storing new video of Shawn attending a local car show at the same time they are retrieving a large video segment of a forest fire.  These large video streams can be simultaneously and transparently stored and retrieved via a set of load-balanced DDMs.

 
For news agencies, they’re not just ingesting a lot of data at one time; they want to be able to pull that data whenever they want. Distributed data retrieval helps clients distribute the retrieves and the stores across multiple servers, which makes it perform way better than it did in the past.
 
4. Time Code-based Partial File Retrieval
This feature enables you to retrieve a segment of a video and not the entire video.
 
Ex. Going back to the example above, say Shawn wins the lottery and your asset manager finds the 5 minute clip of Shawn at the car show.  For the news broadcast announcing Shawn won the lottery, you want to pull out the quote from the long video where he says, “Gosh if I ever win the lottery, I’m going to go and buy that Ferrari I always wanted.” Instead of retrieving the entire 5 minute video clip and having to edit it onto the news that night, the asset manager would send StorNext only the timecode that you want for the video. Then, we would pull only that small segment from the archives-not the whole file.
 
Another Ex. What if you have a 1 TB size movie and you want to tear just one small snippet of the movie to create the trailer. Now you don’t have to pull back the 1TB file to disk. We can just hand over the 13 seconds you need.
 
This feature is focused mostly on tape. It can be used for disk, but disk is usually fast enough: you would just edit the file in StorNext. But, for tape, there’s value in being able to retrieve just a piece of information rather than the whole file.
 
5. StorNext Management Console
The last important piece is the StorNext Management Console, our GUI. We’ve optimized this to make it more user-friendly. We’ve reduced the number of pages to make it easier to administer and set-up the StorNext software. We’ve improved the visual reports for what’s going on in the storage, how it’s being utilized, where’s the greatest capacity, etc. And then we opened up the architecture for 3rd party products via web-services APIs if they need to write specific calls or code to integrate their application more closely with StorNext.