The theme of the continuous provision of IT services is normally called with two terms: Business Continuity (BC) and Disaster Recovery (DR).
Business Continuity and Disaster Recovery, what are the differences?
Over time, these two types of service delivery continuity have been described in the most disparate and imaginative ways. In reality, the difference between these two terminologies is functional.
The first question we must ask ourselves when undertaking one of the two alternatives or leaning towards the choice of both is the following:
Does the service system of the company/body we want to safeguard end with the termination of the operating site from which the services are provided?
If the answer is yes, the type of business continuity to be undertaken is Business Continuity , if the answer is no, the service will need business continuity in a site geographically distant from the main datacenter to guarantee the provision of services. In the latter case, we will talk about Disaster Recovery .
The Business Continuity solution must have the main characteristic of the proximity to the production site of the service for it to be effective, in addition to having to provide two distinct but close places, such as for example the same building (suitably separated from the inside with fire walls, double power supplies and connectivity), or two separate buildings. The important thing to pay attention to is the proximity of the operational service because even in the absence of external connectivity of the telco operators (connectivity providers), it must always be possible to reach at least one of the two datacenters < / strong>.
For activities requiring continuity of Disaster Recovery services, the two datacenters must have a minimum distance which has commonly been estimated at around 70 km . This is the distance that allows, in most cases, to safeguard infrastructures as unfortunately already tested following natural or man-triggered events (earthquakes, the Fukushima nuclear power plant after the 2011 tsunami, Chernobyl in 1986, the whose forbidden zone still covers a radius of 40 km, etc.).
Examples of Business Continuity and Disaster Recovery: a hospital emergency room and an international courier
Starting from an example, we can hypothesize an ICT service for a hospital emergency room and an ICT service for an international courier.
If an event were to occur that would make the premises of a hospital emergency room totally unusable, such as a flood, earthquake or other event, with consequent non-access to the facility by health professionals, the alternative for users would turn to another emergency room nearby.
In this case it would make little sense to reactivate the emergency room IT services in a site located in another area, while a good local resilience of the IT services (Business Continuity) would allow business continuity even in the absence of external connectivity as the Emergency Department survived the event.
In the second case, we consider an International Courier , where in the event of a problem such as to make the headquarters no longer operational or unreachable, there should be no disservice such as to compromise branches, warehouses and logistics in general which must absolutely remain operational independently of the main site. On occasions like the latter, the Disaster Recovery site located at a safe distance, typically from 70Km upwards, is absolutely essential for the continuity of service delivery.
Only after answering this question, one can ask oneself about the Recovery Time Objective (which identifies the speed at which one is able to restore IT systems); on the Recovery Point Objective (which identifies the permissible data loss); latencies (response time), throughput (transmission capacity used) and anything else necessary for the realization of business continuity in particularly critical circumstances.
Cloud & Datacenter for business continuity
When we talk about Datacenter we mean both owned datacenter but also structures whose spaces are rented precisely to guarantee Business Continuity and Disaster Recovery. These can be market clouds or datacenters specialized in providing services to guarantee this operational continuity. In evaluating the opportunity of both, various factors come into play, including costs.
In both cases, careful management of data security copies is to be evaluated.
Business continuity and disaster recovery planning
When dealing with a Business Continuity or Disaster Recovery project, it is necessary to make some considerations: in this introductory document we will highlight the issues that in both cases must be taken into consideration and a list of priority actions to be taken to prepare for the project:
- Census of service entry points
- Census of application servers that enable services
- Census of structured databases
- Census of unstructured databases
Below is an image that visually summarizes the layers that service requests, represented by colored ribbons, have to go through in order to satisfy the requests in a typical Datacenter.
The transition from a Datacenter to multiple Datacenters with data replication and the possibility of operating from the secondary datacenter in critical moments must be accompanied by tools that facilitate its operations and make them as automatic as possible.
Each layer mentioned requires procedures and tools to allow the migration of services from one Datacenter to another , in whole or in part. Another important element is the test that must be carried out periodically in order to be sure that at the critical moment all the procedures have been updated and are operational.
All vendors in individual layers, web/application server manufacturers, databases, storage etc. They normally propose their own solution to achieve the single functionality. Therefore tools are needed to orchestrate activities and prepare services to be performed in secondary offices.
Tools for setting up services in a datacenter:
One of the indispensable tools on which all Business Continuity and Disater Recovery policies are based is LBL Application Delivery Controller (ADC). This element in fact concentrates the catalog of services and is therefore the entry point for any request that is made to the Datacenter. In the case of Disaster Recovery LBL DNS Global Load Balancer also comes into play which allows you to dynamically change the DNS responses based on the location of the service. It is therefore able to direct requests to the main site or to the secondary site which responds to a different IP address because it is located in another geographical area.
We have just begun a long journey on the policies of continuous service delivery.
We deliberately set up the initial discussion on the general aspects that must guide an informed choice of the most suitable tools for the needs, based on the type of service to be protected.
Further insights on the topic will follow, going to analyze the individual points in more detail with the architectural variants that can be adopted.