Today I’ve been reading from “Tsunamis and Virtual Disaster Recovery”. With the increase in violent weather around the world in the last few years, this is a subject that bears thinking about.
Obviously, the most effective way to deal with a disaster is to avoid the effects of it. What does this mean? Don’t build your data center in a flood plain, avalanche area, tornado area, etc. If you invite disaster, disaster will come knocking.
But what about the unanticipated ones? The better question would be the unanticipatable ones. Tsunamis on the coast of any country bordering the Indian and Pacific oceans are perfectly anticipatable, just like earthquakes are perfectly anticipatable on the US Pacific coast or tornadoes in the US midwest.
The nature of virtual machines and the fact that they aren’t locked to physical hardware makes the idea of shifting them from a vulnerable data center to a data center that isn’t at risk a very reasonable idea. If you can’t move the data center, move the work.
The problem I have with this idea is, what happens when you have a truly unanticipatable disaster and there simply isn’t time to relocate large numbers of virtual machines? We solve that issue here by mirroring virtual private servers and virtual private workstations between our primary and secondary data centers. This allows us to relocate the virtual machines in circumstances when time allows but also gives protection against the sudden catastrophe. Granted, there is some impact since the mirroring isn’t real time, but it’s far, far less than commissioning replacement hardware servers and restoring backups that are a LOT less than real time.
When it all comes right down to it, the data center disaster recovery plan comes down to the smartest way to insure the business continuity of the customers. Avoid the disaster if you can, minimize the effects if you can’t, and have another basket and a way to get the eggs to it BEFORE things go catastrophic if you can’t avoid or minimize.
Don’t contribute to the disasters, they don’t need any help!
Vern, SwiftWater Telecom