The cloud is best option for Disaster Recovery and this trend is convenient for all industry who are following any DR activity.
The conventional way to do the Disaster Recovery plan is cumbersome and comes with very high cost.
The key points for the conventional DR activity;
- High Cost to build the alternate location for Data Centre and Site.
- The cost may include the building infrastructure, IT setup, Internet, and Hardware.
- Very high Capital Expenditure (CapEx) of business to build as per demand of the project requirement.
- Keeping and maintain the storage, backup, archival and retrieval tools comes with high cost.
- Operational Expenditure (OpEx) to maintain alternate site is very high.
- Difficult to plan, execute, resource recruitment for the DR activity on short notice is seems difficult and time consuming, this may affect the business loss.
- Most critical part is to execute the DR activity timely to verify the data and restoration process.
To overcome the all these drawbacks, AWS Cloud seems best available solution for Disaster Recovery plan.
In this article we are considering to use the AWS Cloud in four scenarios followed in industry for Disaster Recovery. It all depend on the businesses how quickly a system need to be available to users after a DR event.
The four scenarios are;
1. Backup and Restore
There are multiple ways to do the backup of the data on Magnetic media, DLT, LTO, or DVDs and keep the data in safe off site location, till data needed for restoration process. This is preferred way to do the backup and restoration of the data, but it has the drawback of the time. To complete the process of Backup can take longer time, and restoration can take even longer time in the event of the disaster.
AWS S3 can turn out to be the ideal destination for the backup, so using the internet connectivity the restoration can be done on same or any other location as and when needed. There are many opensource and/or commercial version of the AWS S3 data backup solution available. You can find all the options here.
AWS has the feature like AWS Import/Export which can be used to transfer the large amount of the data in one go. Simply ship the storage media to nearest AWS hub and AWS support staff will transfer the data to AWS S3.
Using the AWS Direct Connect from on-premise data centre to AWS Region, the can be moved with dedicated bandwidth at higher speed. Find more about the
AWS Direct Connect.
AWS Storage Gateway can be used to copy or sync the on-premises data snapshot to AWS S3. While restoring the data from these snapshot, user can simply create the local volumes and connect to on-premises servers or creating volumes from snapshot to connect on AWS EC2. Both way data can be available easy and fast. There are other cost saving ways to move the data from on-premises to AWS Cloud. To get to know more, please do visit
AWS Storage Gateway.
Once you keep the data on AWS S3, and looking for longer data retention period then the data can be moved from AWS S3 to the less costly option to AWS Glacier. It provide the same durability of AWS S3, but comes with very low cost. Restoration from AWS Glacier may take longer time than AWS S3.
Here is an example of the Backup and Restoration scenario.
2. Pilot Light
The pilot light scenario used in Disaster Recovery to show the low cost but effectively fast recovery option compared with Backup and Restore option above.
The backup process can be used from the Backup and Restore scenario, but with minimal but most critical servers (EC2) running in the nearest AWS region. When the time needed or to activate the Disaster Recovery, EC2 (server or servers) can be run with full scale production server environment to support all on premise users.
The Pilot Light scenario can include the critical server/service like Database server using the AWS RDS or critical Application servers using AWS EC2 instances. The restoration can be happen from AWS S3 common point where backup usually kept.
To make the exact copy of the on-premises server configuration or OS, AMI can be used to keep the server updated with all software, tools and application. AMI (Amazon Machine Images) can be turn on or can be used to scale up as per demand to take the continue traffic in case of Disaster Recovery.
It would be useful to use the AWS Elastic IP address for critical EC2 servers or AWS Elastic Load Balance (ELB) which can be mapped with AWS Route 53 or can be bind with the DNS. In case of Disaster event AWS EC2 can be turn on with scale up infrastructure and with latest backup from AWS S3. To make the latest version available after Disaster incident AWS Route 53 and DNS can point to AWS infrastructure to make the Restoration work.
Here is the example diagram of the Pilot Light scenario
3. Warm Standby
The Warm Standby mode is step ahead of the Pilot Light DR scenario. In Warm Standby mode of the Disaster Recovery, all critical servers are running on the AWS cloud with lowest configuration possible. Though all servers are fully operated and functional but can handle minimalist load.
In case of the Database server, Database should be configured in Master and Salve mode, where master is on-premises location and Salve is in AWS Cloud. Application server or critical server are using the replication of each other to keep the data updated on both location. This help to transfer the incoming of the traffic to AWS Cloud whenever needed.
The AWS Route 53 can be configured using 'Failover Routing' policies to point the records to on-premises as well as AWS Cloud ELB. In the event of the Disaster, AWS Route 53 route the traffic to the AWS Cloud Infrastructure and using the AWS Auto Scale feature the whole EC2 servers can be scale up to support the incoming traffic.
Here is the example diagram of the Warm Standby scenario
4. Multi-Site
As name suggest, it deployed on both on-premises location as well as AWS Cloud. This Disaster Recovery scenario has the highest availability of the deployed application in event of the Disaster.
In Multi-Site scenario is step ahead version and last possible scenario in Disaster Recovery with AWS Cloud option. In this scenario all on-premises server and services must be configured on AWS cloud with equally same or lower valued configuration. DNS configuration should be done with AWS Route 53 in 'weighted routed' mode, so in event of the Disaster the traffic can be changed to AWS Cloud infrastructure to make all server and services up.
AWS AMI, ELB and Auto Scale will help to enhance the performance of the setup as and when the traffic increased to the AWS Cloud infrastructure. AWS Route 53 in weighted routed mode can understand the on-premises failure and route the traffic accordingly without facing any downtime to business or users.
The Data and Database must be sync from on-premises to AWS Cloud and vice versa to keep the updated information on both locations. This scenario will cost more but will provide highest availability and continues business activity.
The scenario diagram for Multi Site is same as Warm Standby scenario.
Comments
Post a Comment