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
OK, 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…