Disaster resilience A virtual reality
ANDREW BARNES SVP of Corporate Development at Neverfail
A key consideration in any BC/DR rollout should go beyond site recovery and address business resiliency, argues Andrew Barnes SVP of Corporate Development at Neverfail.
Due to the growing rise and deployment of virtualised servers in the datacentre and a continuing shift towards cloud, a reoccurring commentary from industry watchers has focused on the reliability and resiliency of new infrastructures. A common perception from end-users is that virtualisation brings disaster recovery with it by default. Yet unless resiliency requirements for critical applications are specifically addressed this can mean problems when creating disaster-proof business continuity (BC) plans. In this article, I will try and outline the importance of agile and flexible solutions when operating both physical and virtualised applications that are critical to daily business flows. Placing emphasis on why solutions must adapt to various disaster recovery and resiliency (DR) architectures, I’ll explain how virtualisation can be used to have positive implications on BC planning for both critical and non-critical applications.
For as long as we have been hearing about virtualisation, cost-savings, hardware reduction, simplified maintenance and enterprise efficiency levels have been cited as benefits. These benefits apply whether focussed on the primary datacentre, or in relation to the use of virtualised sites for DR. From a DR perspective, it is important to recognise that while virtualisation brings an inherent level of resiliency to the table from embedded availability functions, this doesn’t extend to protection against site wide issues, nor does it have any effect on the critical physical systems, which continue to serve the business. Depending on the size of the organisation and business dependency on critical applications, the challenges presented to IT managers when preparing for a disaster can vary. To ensure key business processes are continuously available, end-users should define what they believe DR to be. A good place to start is to think about the terminology itself. DR is widely accepted to mean Disaster Recovery, yet is a “recovery” process really serving the needs of the business? Even with automated workflow tools and online disk backups a recovery process
34
will be highly disruptive. With this perspective, plans can be drawn up to address specific business IT challenges. A common impression is that an “inconvenience” such as a power cut is addressed as a disaster, because technically it is an event from which a company needs to recover. Yet recovery from a backup is not a recommended approach to deal with such a situation. The general processes involved to gather necessary data after failure will be accessing information from back-up stores and then rebuilding failed applications in order to reinstate the data. These procedures are reliant on the agility of the organisation, and without the right planning, the business impact could result in downtime for a matter of hours or days, causing serious problems for the organisation. This is why many organisations just accept the pain of such an outage.
Invoking a Disaster Recovery plan in response to a power failure is not for the faint-hearted. Without the right infrastructure tools in place, if the power is down for a few hours it may be better to sit-out the disruption than live with the pain of recovery to a secondary site, and the subsequent switch back to the primary site.
Considering this, CIOs and IT and Virtualisation managers need to be mindful of the costs incurred when invoking a broader DR plan for virtualised servers, and instead consider the potential financial impact of hourly application downtime to the business. For example, VMware’s SRM offering is a very broad solution for protecting an entire datacentre against a serious and high- profile disaster, and can potentially “recover” applications within variable periods of time. Whether it can meet the operational needs for businesses to remain available 24/7 needs to be seriously considered; and this is exactly where a re-think in disaster recovery enters the mix.
When it comes to high profile applications, organisations should be talking about Disatser Resiliency instead of Disaster
Page 1 |
Page 2 |
Page 3 |
Page 4 |
Page 5 |
Page 6 |
Page 7 |
Page 8 |
Page 9 |
Page 10 |
Page 11 |
Page 12 |
Page 13 |
Page 14 |
Page 15 |
Page 16 |
Page 17 |
Page 18 |
Page 19 |
Page 20 |
Page 21 |
Page 22 |
Page 23 |
Page 24 |
Page 25 |
Page 26 |
Page 27 |
Page 28 |
Page 29 |
Page 30 |
Page 31 |
Page 32 |
Page 33 |
Page 34 |
Page 35 |
Page 36 |
Page 37 |
Page 38 |
Page 39 |
Page 40