Home | Uncategorized | EMC World 2009: Day 2 – Axxana

EMC World 2009: Day 2 – Axxana

0 Flares Twitter 0 Facebook 0 Google+ 0 StumbleUpon 0 Buffer 0 LinkedIn 0 Filament.io 0 Flares ×

Day 2 of EMC World is here.  The weather is awful – thunderstorms and lots of water everywhere.  On the news this morning, they’d positioned a reporter by a large puddle, filming vehicles as they tried to get through a mere 6 inches of water.  At least it was better than normal US TV.

So, back to the technology.  Yesterday I swung by the Axxana booth to have a look at their Phoenix data recovery product.  Anyone who’s read my posts will know I’ve been following these guys for a while and that I believe they have an intruiging proposition to offer.


Here’s the idea.  Many storage users want a Recovery Point Objective (RPO) of zero.  This means that data as it is recovered, is achieved in a DR scenario without any loss whatsoever.  Typically synchronous replication achieves this; think SRDF/S and TrueCopy.  Unfortunately these technologies suffer a latency penalty; data must be written – and confirmed – remotely before the host I/O can be acknowledged.  As users look to move their datacentres further apart, then the latency hit increases and can be intolerable in some applications.  Stretching distances requires a move to asynchronous replication in order to retain response time.  Now imagine you have a large number of servers and applications, all with complicated dependencies.  Synchronous replication removes the need to understand and manage these dependencies.  Moving to asynchronous replication may be complex or technically impossible.

Axxana’s Phoenix product enables users to achieve the integrity of synchronous replication without the latency penalty.  

How It Works

DSC_3044OK, so the obvious question is, how to overcome the speed of light?  Latency exists because data travels as a fixed speed, whether over copper or fibre.  Repeaters and other interim hardware add in more delay.  Phoenix overcomes the physics headache by moving the RPO synchronisation until after a recovery event starts.

The Phoenix device uses RecoverPoint to asynchronously replicate data to a remote array.  At the same time, a copy of the latest write updates is stored synchronously in the Phoenix in the local site.  If the local array is lost, then the latest updates can be obtained from the Phoenix and applied to the remote array to bring the data fully up to date.  

Now, you may be asking “Surely the Phoenix would be lost in a DR scenario?”.  Have a look at the picture on the right.  This shows the Phoenix, which is encased in a fireproof jacket.  It also has its own battery power supply and cellular modems.  Even in the event of a fire where the local site is inaccessible, data can still be obtained by remotely contacting the Phoenix and uploading the data over the air.

At first glance Phoenix looks like a heavyweight solution to the RPO=0 problem, however I anticipate that over time, the device will be reduced in size and incorporated into the array itself.  After all, arrays already contain batteries.  It’s a logical step to include a fireproof chassis for holding the Phoenix electronics.  By the way, I have no inside knowledge here, only my own speculation.

If you get time, go and have a look at the product and the demo.  Tell Alex, Dan, Eli, Gil or Liat that I sent you… :-)

About Chris M Evans

Chris M Evans has worked in the technology industry since 1987, starting as a systems programmer on the IBM mainframe platform, while retaining an interest in storage. After working abroad, he co-founded an Internet-based music distribution company during the .com era, returning to consultancy in the new millennium. In 2009 Chris co-founded Langton Blue Ltd (www.langtonblue.com), a boutique consultancy firm focused on delivering business benefit through efficient technology deployments. Chris writes a popular blog at http://blog.architecting.it, attends many conferences and invitation-only events and can be found providing regular industry contributions through Twitter (@chrismevans) and other social media outlets.
  • Brian

    Maybe IBM buys this as well…Moshe is 2 for 2 and all :-) Integrate it into the XIV array, A-sync issue solved.

  • bill bloom

    How does this solution address a 9/11 catastrophe? Even if Axxanna is encased in cement and has its blankey, there still has to be a link to the outside world to the DR site. I don’t see where this solution addresses that.

    The only reason the 9/11 terrorists were unsuccessful in their attempt to cripple US financial markets was because they did not understand the data protection schemes Wall Street CIO’s put into place.

    Now, years later, Wall Street Greed has done what the terrorists could not do!

    Bill Bloom Sends–

  • Chris Evans

    Bill, the Phoenix has battery backup and mobile/cell connectivity so assuming the mobile network base stations are still contactable, the device can upload data. I think disaster scenarios need to be thought through. 9/11 was a disaster scenario we will hopefully never see again. In this instance, having data a few minutes out of date would have been acceptable. There are many other scenarios where arrays go down – power, fire, flooding, which aren’t as catastrophic. Phoenix provides the ability to move from async to sync over long distances for these failures. Also, consider the scenario where there moving from sync to async is so complex to understand, that having a way to retain sync is more desirable or cost effective.


0 Flares Twitter 0 Facebook 0 Google+ 0 StumbleUpon 0 Buffer 0 LinkedIn 0 Filament.io 0 Flares ×