Comments on: Obligatory Atmos Post

By: EMC Changes the Rules with Atmos Compute – Gestalt IT

EMC Changes the Rules with Atmos Compute – Gestalt IT — Wed, 19 Aug 2009 14:00:30 +0000

[...] and Atmos onLine storage products in November of 2008 with a marketing splash. Many observers were puzzled at the time, trying to figure out how Atmos fit with VMware, Centera, and the storage products in [...]

By: Steve

Steve — Fri, 14 Nov 2008 14:18:00 +0000

Chris,
That’s right, this solution is not meant to be deployed as “one array”. It is meant to globally span data centers. Your use of the word “array” conjures up images (for me) of our Symm/CX-style products; Atmos is a different mindset.
Steve

By: Stephen Foskett

Stephen Foskett — Thu, 13 Nov 2008 22:16:00 +0000

Great questions! Despite the voluminous posts by all the usual EMC folks, we still have a lot to learn about Atmos.

By: Chris M Evans

Chris M Evans — Thu, 13 Nov 2008 21:21:00 +0000

Steve

Thanks for the clarification. It seems to me to be a bit of a risk – you can’t deploy one array on its own without the risk of losing data. Am I missing something here? I realise Atmos is meant to be a scalable solution and its targeted at large customers who will deploy multi-petabyte installations. Perhaps future explanations will help make this more clear.

By: Steve

Steve — Thu, 13 Nov 2008 18:20:00 +0000

Hi Chris,

There is no "array-based replication" in Atmos. As new data gets written into the Atmos infrastructure it gets synchronously mirrored to N locations (depending on the policy). Any async mirroring is done later (and also does not rely on array-based replication).

You raise a lot of good issues in your post; I am sure that over time myself and others will do our best to answer them thoroughly, which is better done in a new post (as opposed to commenting here).

Steve

By: Chris M Evans

Chris M Evans — Thu, 13 Nov 2008 15:29:00 +0000

…and another thing – say I am relying on array-to-array replication to protect me from data loss and I lose a disk – I then have to re-create that data from the replica – preferably as quickly as possible – how long will it take to replicate a 1TB drive over IP? 2.7hours at full 1Gb/s if I am lucky. Is it really the best approach to use expensive network bandwidth to protect against disk failure?

By: Chris M Evans

Chris M Evans — Thu, 13 Nov 2008 15:26:00 +0000

Rob

I see what you mean – however I also raised the issue of replication connectivity – which appears to be all IP. There’s no documentation to indicate whether replication is sync, async or otherwise. So assume sync exists – on the basic model it will be achieved over 1Gb IP. Is 1Gb/s enough to replicate my data to a remote site synchronously? If not, how much cache is there in each node? Is this all battery backed write cache in case I experience a hardware failure? I’m not trying to be awkward – there are lots of assumptions being made here – I want to understand how it all works to help me see how I’d be exposed in the case of component failure.

By: Rob

Rob — Thu, 13 Nov 2008 15:16:00 +0000

You picked up on Steve Todd’s explanation of Policies and then state:

“So, does that mean Atmos is relying on replication of data to another node as a replacement for hardware protection? I would feel mighty uncomfortable to think I needed to wait for data to replicate before I had some form of hardware-based redundancy – even XIV has that. Worse still, do I need to buy at least 2 arrays to guarantee data protection?”

You missed his overview of a gold policy where it is synchronous in 2 places and asynch to shanghai. I’d think that would more than make up for hardware failures. Still paranoid and rich? Make up your own Platinum policy. Synchronous in 4 sites. I’ve seen that discussed elsewhere.