Information Playground

Replication and The Private Cloud

My last post about the new reality of shipping both storage hardware AND storage "files" (VMware virtual storage appliances) is a starting point for various conversations. I find replication to be one of the more interesting technologies to examine in the context of private clouds.

As a developer, I can build storage software and ship it as either a piece of hardware or as a file. A "file" can be "deployed as a storage system" in one of the flexible private cloud environments that Chuck keeps talking about.

This file, when "booted" in a vStorage operating environment,  could in theory represent a Symmetrix, a CLARiiON, a Centera, or a Celerra.

And, if you've been following Chad's posts on the subject, you'll notice that Celerra VSAs fully support replication to each other.

The replication possibilities with private clouds are numerous. Let's step through some of them.

Shipping Files to the Private Cloud?

As I mentioned in a previous post, developers have been laying the groundwork for private cloud rollout of our storage systems.

This new paradigm in which we are operating was a major paradigm shift.

For years the modus operandi has been to build storage software (microcode, firmware, whatever you want to call it) that is only embedded in a physical piece of hardware. Sure, we design our software to abstract out many of the hardware details. This allows agile deployment of the software onto new platforms. Hardware-based rollout will continue to be modus operandi for some time.

So in the end, we manufacture and ship a physical box. Because of the emergence of private clouds, however, we're being asked to ship something new as well.

A file.

MIT and Federated Archives

The first week in February can often be one of those weeks where we here in New England start asking ourselves "why do we live here"? Last week was freezing! Some of us make it through via our love of winter sports. I myself find pond hockey to be one of the greater experiences in life, but there's usually too much snow to shovel by the first week in February. 

During my visit to MIT recently the wind was whipping off the Charles river and into Cambridge. Across the river, however, the Massachusetts version of grounddog day would soon take place. Last Friday, Feb 6, "the truck" left.

Around here, when someone says "the truck" in February, it's obvious what they're talking about.

They're talking about the Red Sox equipment truck leaving for Fort Myers, Florida.

And that, my friends, is why I'm willing to stick things out for a few more months.

Val Was Right

I've been having a bit of a disagreement with several of my co-workers this week regarding the storage block smack-up started by Val over at NetApp.

A lot of assertions have been made, a lot of points have been proven wrong, and (sniff) I fear some feelings may have been hurt along the way.

But I do believe that Val was right about one thing.

My blog is a fraud.

Yes, it's true.  I don't know how he saw through me, but he did. What I've got going on here at the Information Playground is not really a blog at all.

It's a technical diatribe.

When Objects Collide

The conversation about collisions.

The object collision paper, published nearly four years ago, was referenced last year in a conversation between Alex McDonald and 'Zilla.

The paper was written during a swirl of FUD, press, research, and legitimate customer concern.

I remember participating in the conversations that were occuring right outside my cubicle (I sat next to the Centera CTO) regarding the probabilities of object collisions in Centera.  I remember the changes that the developers were making to the software (adding new naming schemes) as a result of the conversation.

The mathematical conclusions were quite compelling. Centera's engineering activity, however, was even more compelling.  The math argued that there was no cause for customers to worry. In spite of this, we enhanced the software.  Why?

Because the customer is always right.

XAM: From Bleeding to Cutting Edge

Centera and the Centera API have been in the middle of a storage blog smack-up.

I was surprised to read the claim that the Symantec/Centera integration had issues. First of all, they've been an integration partner for years. Secondly, their implementation is top-notch, given that their integration architect is one of the most well-respected Centera-API experts in the industry! Therefore it doesn't make sense that their developers would have a problem with the Centera API.

Symantec has confirmed that there are no data integrity issues with Centera. It was a false alarm.

At the heart of the supposed issue was the need for partners to integrate their applications with Centera's SDK. Hundreds of them have done so.

It's worth exploring the reasons why these partners decided to integrate with Centera in the first place. They chose to integrate with a technology (object-based storage) that was bleeding edge.

Issues arose during the integration. Bugs were found. Bugs were fixed. Workarounds were added. Requests for enhancements were made. Features were added. Best practices were advertised. Quality improved.

Customer adoption of the resulting applications legitimized object-based storage systems as a third category of system (alongside "block" and "file").

Customers. Partners. Storage system vendors. What would they come up with if they had a chance to build a new API from scratch? 

They already did. It's called XAM.