One of the differences I like to point out about Centera as a storage system has to do with the device driver paradigm. Many customers are used to the following process: (a) buy a peripheral, and (b) download and install the driver to talk to the peripheral. If the peripheral was a block device, a customer might download a SCSI device driver.
There are no industry standard “object” device drivers (XAM may change this!). You don’t buy a Centera as “raw storage” and download an object device driver.
So how does one write data to a Centera? How do you get data off of a Centera? How does one move data between Centera and other storage devices?
Let’s talk.
Applications, not Drivers
When a Centera is purchased by a customer, they typically have an application in mind that they would like to use. This application is likely generating a large amount of fixed content, or data that changes infrequently. The application may take advantage of many of Centera’s different features, such as retention, single-instancing, or location independence.
These applications ship with an object-based driver included. This driver is known as the Centera API or Centera SDK (software developers kit). The inputs to this driver are fixed content objects (e.g. an XRAY), and metadata about these objects (e.g. patient=”Steve Todd”). Now this “driver” is actually a library linked in by the application. But you get the point.
Therefore the “raw” interface for moving objects in and out of Centera is the Centera API. As I wrote in a recent post, the XAM API can be viewed as an industry standard “driver” for object-based storage. Once an application begins coding to the XAM API, they can seamlessly move objects between different vendor’s object-based storage systems.
Customers that buy Centera also buy an application that has already integrated with the Centera API.
Moving Data between Centera and Other Devices
There are many applications that have provided great value by integrating with the Centera API.
Some of them are file systems.
More and more file system technologies have been integrating with the Centera API. And one of the driving forces for this integration has been file system archiving. Consider a customer’s “home directory”, which is typically filled with files that are rarely modified. Full backups are often run weekly on these directories. The same files get backed up every time, even though the files are not changing (fixed content). And each weekly backup gets longer and longer as new content is added to these directories.
How do I avoid backing up fixed content over and over again? How do I shrink the amount of time it takes to do a full backup of my filesystem? Well, I automatically move old, large, inactive files to a Centera.
And I replace them with a stub that contains a Centera content address.
So now my large, fixed content files don’t get backed up over and over again. Only the stubs get backed up, and these are small (dozens of bytes). Anytime the migrated files get accessed or modified, they are re-staged back onto the file system.
And these file systems can exist on any vendor’s storage device. Here are some examples.
Host-based File Systems
EMC’s Legato Disk Extender (DX) product has integrated with the Centera API. Legato DX runs on a host and offers a policy engine that finds infrequently used files and moves them to Centera (leaving a Centera content address behind). Legato software intercepts file access requests and fetches data from the Centera if required. Note that this technology can sit on top of any vendor’s storage device.
Virtualizing NAS Appliances
EMC’s Rainfinity has integrated with the Centera API. Rainfinity is a virtualizing NAS appliance that can sit on top of a variety of NAS storage devices. Rainfinity also has a policy engine that can identify infrequently used files and move them to Centera. And when RainFinity is deployed in a Celerra environment it can use Celerra’s FileMover API. The use of this API allows for snap, backups, and anti-virus to function as advertised.
Celerra NAS Product
Finally, EMC’s Celerra product offers an option to move infrequently used content off of a Celerra and onto a Centera. This is done using the aforementioned FileMover API. This API provides a rich set of transparent migration utilities; integration of the FileMover API with Centera has resulted in an extremely successful product offering.
Centera As a Target
In summary, Centera often gets deployed as a target device for archiving infrequently used files. This is an attractive value proposition for customers for a number of reasons. First of all, they don’t have to configure the Centera. Once it has been installed and is visible on the network, the Centera API can begin storing the objects (files). Secondly, the network speed of accessing the Centera is fast enough for staging-in files that are being accessed or modified. Thirdly, customers are increasing the amount of available capacity on their primary store and decreasing backup times dramatically.
How about moving content OFF of a Centera? This is all up to the application. Any application that integrates with the Centera API has the option of moving their files off of a Centera and putting them onto another type of system. And as XAM becomes widely deployed, movement between Centera and other object-based systems can be accomplished while maintaining the same content address (known as a XUID in XAM-speak).
Sound cool? I haven’t even started talking about using Centera as a primary store (yet)……
Steve
