Aug 26

StorFirst EAS vs. Centera Universal Access (CUA)

Engineering No Comments »

And here’s the next edition in our series “StorFirst EAS Takes On the World!” Kidding aside, the past few weeks we have been exploring the differentiating factors between StorFirst EAS and other products on the market to which EAS is often compared.  Archiving software, tiering, policy-based data management – Seven10 understands that this can appear to be a crowded market place. It’s important for customers to know how these products differ, so they  can ensure that they are purchasing the product that best solves their individual problem.

Today, we’ll be talking about Centera Universal Access (CUA). CUA was designed as a file caching product developed by an EMC acquired start-up. EMC began to market the technology as an add-on feature that makes Centera accessible to applications unwilling or unable to engineer around Centera API’s. CUA enables very basic access to Centera for non-integrated applications by allowing Linux, UNIX or Windows applications to store and retrieve content from Centera using standard CIFS, NFS & FTP protocols. Most CUA clients today have received the software as part of a Centera bundle.

Seven10 has had a longstanding partnership with EMC’s Centera platform, having been one of the first vendors in the Centera development program.  StorFirst EAS will not only integrate directly into the Centera API, but will also archive data to a wide range of other storage platforms, including FC disk, cloud storage, SATA, NAS, tape, and VTL.

CUA does not have data movement policies and does not have tiering; CUA only supports Centera. CUA is limited to 200 million objects per install and multiple CUA’s are needed to synchronize content addresses across a LAN or WAN.

StorFirst EAS offers nearly unlimited scale, into the exabyte range. EAS will write to multiple platforms simultaneously.  Seven10 will also deploy smart policies that help the user manage data on Centera and other storage platforms in the tiered infrastructure.

Tagged with: •
Aug 06

EMC DiskXtender vs. Seven10 StorFirst EAS

Engineering No Comments »

It appears that customers, partners, and the general storage community are fairly familiar with EMC’s DiskXtender product. At Seven10, we’re getting asked a lot: “How is Seven10’s StorFirst EAS different than DX? From what you’re saying, I can’t really tell the difference.”

StorFirst EAS and DiskXtender are both archiving products. But that’s where the similarities stop and the differences begin. Let’s review the major differences that set us apart.

IMPLEMENTATION

DX is a file system filter driver (FSFD) on Windows NTFS.
EAS is a file system driver (FSD) and uses a 100% virtual file system.

SCALE

DX uses the Windows registry to save links between archived file stubs and the archived data on the secondary media.
EAS uses an embedded, highly scalable Oracle Berkeley Database for configuration, file system addressability, and file location data for secondary media.

DX has a hard limit of 20 to 25 million files per file system.
EAS has a soft limit of billions of files, limited only by the amount of disk space used to house its database.

DX has to perform a time consuming background scan of the entire file system to determine what to migrate.
EAS uses a proactive intelligent index of the database by date the file was closed and locked down so that only new files are archived to secondary storage.

STORAGE

DX migrates files to locations by jobs for an archived file and requires additional agent programs (MediaStor) for certain types of media.
EAS proactively places files in up to 3 long term locations for an archived file and requires no additional components.

DX keeps stubs on the primary file system.
EAS uses its own virtual file system, there is no such things as stubs.

DX supports only 1 disk LUN per file system extended drive.
EAS aggregates an unlimited number of disk LUNs into one unified drive.

DX is a legacy product which supports only Centera, NAS and Tape Media as targets.
EAS is a next generation product which supports all of those and next generation storage devices like Data Domain and Cloud.

Any further questions we can clarify? Any DX users out there that are looking for a more scalable way to archive?

Tagged with: • • •
Mar 24

What Happened to XAM?

Engineering No Comments »

A few years ago, the Storage Networking Industry Association (SNIA) set out to create an open standard for archiving fixed content data. The initiative was led by major software and hardware vendors that focused on archiving. XAM, short for eXtensible Access Method, included goals that were quite noble, if not lofty. The idea was to create an interface, or API, that most major hardware vendors would support as a means to get data in and out of archiving platforms.

Today, there is no denying that EMC’s Centera platform is the market leader in this segment and it’s no surprise that EMC provided the biggest push for adoption. EMC wants to grow the market for these devices and providing an open standard API would be just the right trick. Even if this decreased EMC’s percentage of market share in the segment, the market would still grow with regards to the total amount of data under management. Lots of data = lots of dollars, so EMC would still win.

The argument for adoption of this sort of API is that fixed content rarely, if ever, changes. Therefore, the API should provide software vendors with ways to: 1) ensure indelibility and 2) avoid the pains of secondary indexing. The first point makes a lot of sense for compliance reasons. The second point can be accomplished by providing flexibility (in terms of metadata) in describing objects sent to the storage. This is currently a big ticket item in the cloud storage arena since most vendors support custom metadata for objects, a place where normal file system interfaces like CIFS or NFS don’t hold up well.

Seven10 integrated XAM into our StorFirst EAS product, and found the process to be very easy and straightforward, likely because it resembles the older Centera API. We are wondering, however, when and if widespread adoption will come. We have partnerships with many of the vendors listed as part of the XAM Initiative, but as far as we know, less than a handful actually have plans to integrate XAM as a connector, never mind actually begin shipping with one.

How long does it take for a standard to become widespread? Is XAM the right tool for archiving, compared to other methods available? Does fixed content archiving necessarily have to be CAS? Lots of questions and few answers at this point. If you have any questions or comments, specifically about XAM or more broadly about fixed content archiving, please post them in our comments section.

- Adam Marcionek, Principal Engineer at Seven10

UPDATE: Today Dell announced they are developing an object-based storage device that will support XAM as an interface. There is mention of communication over HTTP, but no specifics as to whether that will be a RESTFUL API interface. Announcements like this bode well for XAM’s future.

Tagged with: •
preload preload preload