Posts Tagged ‘Axxana’
Amazon has built a fantastic reputation as a provider of cloud services. With multiple data centers, service availability levels at 99.9% and integrated data backup services, Amazon’s EC2 makes perfect sense for new companies that want to build software applications and deliver them as a service. By delivering applications as a service, emerging companies can be a disruptive force competing against established packaged-application vendors. And Amazon EC2 enables these Application-as-a-Service suppliers to avoid the up-front capital costs associated with building multiple, redundant data centers. It doesn’t mean, however, that Amazon EC2 is perfect and without risk.
A look at the Amazon Web Services Service Health Dashboard today showed a number of service interruptions and performance issues in Amazon’s Northern Virginia facility on April 21 – 24. Henry Blodget of Business Insider reported that Amazon had a cloud crash and the “cloud crash destroyed many customers’ data.”
It would take a lot of digging to get to the bottom of why data was lost. The Business Insider article refers to a letter from Amazon to a customer that discusses “an inconsistent data snapshot” and Amazon’s inability to recover the data. Unfortunately, corrupted data which has been carefully copied to another location is still corrupted. That’s why it is important to keep a series of application-consistent snapshots together with transaction journals, so that application-data can be restored to its last known good state and updates can be applied to bring the data back to RPO=0. This is precisely what is done with the EMC RecoverPoint/Axxana Phoenix System RP solution. RecoverPoint maintains application-consistent snapshots, and Axxana stores the changed data, protected from fire, smoke, flood, shock, earthquakes, and building collapse.
As the cloud services become increasingly adopted for mission critical applications, perhaps it is time to consider a zero-data-loss solution.
About thirty years ago, IBM announced the IBM 3380 Direct Access Storage Device. It had a capacity of 2.52GB and a price that began at $81,000 without the controller. At the time, successful storage solution providers like IBM made their storage systems out of high-quality, high-cost components and charged a premium. The design goal was to prevent failures, because there weren’t a lot of ways to survive failures.
Given the volume of data now created, today’s storage systems are by necessity very different. They are designed with the expectation that components will fail and fail frequently, but that the data will survive. In order to achieve acceptable levels of data availability and data protection, storage system suppliers overcome the component failures through software, through redundant components, and through redundant copies.
It’s not surprising that companies worry a lot about cyber-attacks and computer viruses. These are daily occurrences. Companies tend to pay attention to the things that happen on a frequent basis, and don’t spend a lot of time thinking about events that are rare, even if the rare events can be disastrous.
During the past year have you had a fire in your data center? Have you had a flood? Has your data center had to survive a hurricane? A tsunami? An earthquake? A bombing? In any single year, all of these are relatively low-probability events. So why spend the money to protect against them, right?
The problem with this kind of thinking is that when looking across multiple years, they are actually high-probability events.
Check out slide 22 of this presentation: Symantec 2010 Disaster Recovery Study
There are three things every company’s disaster recovery planner should know:
- The communications costs for the current data replication approach
- The communications costs when using Axxana’s Phoenix System RP
- The cost of the Axxana Phoenix System RP
I thought I should share with you at little known secret. One of Axxana’s first installations of the Phoenix System RP was done at no cost to the customer. That’s right. No cost. And it wasn’t because we gave the customer the system for free. We didn’t.