Catalyst
Organisations demand higher levels of system and network availability, and cost effective business continuity; however, all this must be managed and maintained by one department with one IT budget, creating tensions between conflicting demands and priorities of production requirements and Business Continuity (BC) / Disaster Recovery (DR) requirements.

Virtual Disaster Recovery is seen as an on-ramp for many organisations to greater use of virtualisation technologies

The terms Continuous Availability (CA), High Availability (HA), Fault Tolerant (FT), and Disaster Recovery (DR) have been used by the x86 virtualisation vendors as potential added-benefits from using the technology.

Today there are many more products on the market offering solutions that address the issues surrounding the question of how to provide a differentiated level of service availability based on business priority; the solutions nearly all operate across both the physical and virtual environments. However, traditional availability solutions were not designed for virtualised environments, and the biggest issue for these traditional approaches when they are applied to virtual environments is the use of a rudimentary heartbeat ping, which provides information only to the point that it can detect a failure, it cannot determine if the failure is an I/O, complete server, or just a lack of resource issue. Another issue is these traditional approaches are trying to use techniques, such as clustering, based on a hardware perspective to the problem of providing different levels of service availability, but these techniques need to be administered and configured correctly to provide solutions to the different requirements of the organisation.

The different terms (CA, HA, FT, and DR) all have different meanings, and for many organisations wanting to provide a cost effective solution to increasing service availability these terms can appear to be just marketing slogans designed to get them (the end-user organisation) to trade-up solutions with a vendor. However, there are subtle, yet significant, differences between the terms, and before any organisation embarks on deploying any of these they should ensure that it’s (the end-user organisation) definition of requirements is aligned with the relevant terminology used by the Independent Software Vendors (ISVs).

Ovum categorises these as follows:

Continuous Availability: - CA is a term that implies the provision of a non-stop service, with no lapse in service availability.

High Availability: - HA is the most widely used term among the ISVs and is used to imply that the service is available for most of the time. Therefore, it is important that end-users understand HA can mean the service is lost, albeit for only a few seconds.

Fault Tolerant: - A fault tolerant system has the ability to continue service despite hardware or a software failure, and is characterised by redundancy in hardware, including CPU, memory, and I/0 subsystems.
Disaster Recovery and Business Continuity: - DR/BC is a term used to provide an insurance policy for any organisation, it does not provide instantaneous protection, but it can be designed to provide near instantaneous, rather it provides an off-site recovery solution that implies the use of redundant equipment and a separate location.

Selecting an approach is more about understanding the organisation’s particular needs

With the growth of x86 virtualisation many organisations are asking which solution do I need, and how do I choose the technology to provide it effectively. To begin to answer this question the first step is to separate the physical infrastructure from the services, and then decide what is being protected and why.

Virtualisation has provided the CIO with a wealth of different approaches, and the task is to navigate through the potential solutions. Ovum considers a useful tool is for CIOs to consider the benefits and then compare these to the added cost the complexity, or simplification, of the options provide. Ovum believes that a simple framework model, which can be used as a basis for CIOs to map their actual costs and benefits will help in any decision making process. While this model will not provide an absolute answer, it does enable the CIO to see the whole picture and make any decision from a position of strength and knowledge.

While virtualisation does provide many options it is also worth noting that in Ovum’s opinion due consideration should be given to both the physical and virtual environments. In fact Ovum believes that a hybrid solution that operates across both environments provides the most comprehensive and flexible approach; however, this may also be the most complex.

Cluster technologies are very vendor specific, which is also true for virtualisation Hypervisor vendors, so is not a real point of difference. The main difference between these technologies is clusters are complex to manage, in fact many reports indicate that administrator error is a major contributor to many faults, and clusters rely on a single point of failure as the clusters do not implicitly protect the data on shared disks. Another element against the traditional cluster is the applications require modifications to enable them to operate in clustered environments, which adds to the complexity.

On the other hand, the virtualisation solutions suffer from a different type of complexity, while for clusters the focus is on the application in Hypervisors the focus is on the hardware. Some of the advanced capabilities used in virtualised solutions require the organisation to have compatible hardware. For example, the live migration – the ability to move a running virtual machine between different physical servers without any loss of service – requires the target and host server have the same CPU chip set manufacturer as well as being on a shared SAN. A further restriction, which until recently was universally applied, is the CPU chip sets must also be the same generation; however, the Intel 7400 series chip set now enables live migration between chip sets of different generations, but only Intel chip sets obviously.

Ovum believes that having the correct approach for the correct reasons should be the overriding factor, which may mean a mixed traditional and virtual approach. In fact, these hybrid solutions are increasingly become popular, as they effectively enable organisations to identify those services it considers critical, those considered important, and those considered as not operationally significant. These lists may change according to time of the month or even day of the week; consider month-end processing in most organisations, this is important, but only at month-end and not at any other time.
 
About the author
Roy Illsley is a Principal Analyst covering IT Software at OVUM. He has more than 23 years of IT experience, working for a variety of consultancy and end-user companies with experience in the defence, utilities, automotive, retail, and fast-moving consumer goods (FMCG) industries. He works in the IT Solutions team and is recognised as Ovum’s expert on virtualization and infrastructure management. He also has experience of cloud computing, data centre technologies, and IT strategy and policy.

APPENDIX
Disclaimer
All Rights Reserved.
No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior permission of the publisher, Ovum (an Informa business).
The facts of this report are believed to be correct at the time of publication but cannot be guaranteed. Please note that the findings, conclusions, and recommendations that Ovum delivers will be based on information gathered in good faith from both primary and secondary sources, whose accuracy we are not always in a position to guarantee. As such Ovum can accept no liability whatever for actions taken based on any information that may subsequently prove to be incorrect.