by James Keating III, Business Technology Architect, Evolving Solutions
Last week I was the speaker for an event on disaster recovery in the age of cloud infrastructure delivery. At the event I went over some high level concepts and a few sample use cases, however I didn’t go into details on what one would need to be successful in implementation of a cloud delivered disaster recovery or “Cloud Cluster”. I will now provide over the next two blog posts a bill of materials required to setup a cloud cluster.
Before I get into the first scenario, I will set the base by going over what cloud technology attributes can be looked at as key items in terms of enabling disaster recovery. This is one of the few times in IT, that one can potentially increase the overall ability of the business and lower IT costs in terms of existing disaster recovery strategies. The attributes of cloud that can be utilized for disaster recovery are as follows:
- On demand computing
- Containerized workload
- Location agnostic
- Speed of implementation
Each one of these attributes can lend itself nicely to improving disaster recovery abilities in terms of cost (both capital and labor), speed to recovery, ability to automate. The first scenario I will cover is the simple scenario of offsite backups with a side of disaster recovery.
The goals of the scenario are:
- Reduce complexity and manual labor involved in backups, including tape management and offsite shipment of tapes.
- Increase the speed at which backup data sets are fully offsite from primary data
- Ability to utilize offsite data for disaster recovery in terms of both times of a disaster, but also for testing of failover for disasters.
- Ability to have all of the above without investment in a second data center location infrastructure and management.
Items we will need for this scenario:
- Containerization of workload – for this we will choose VMware. This is the default standard in server virtualization and can be used in our case to enable the ability to encapsulate the data and workload in manageable chunks that will help us in terms of backup and disaster recovery.
- Backup software – for this we will choose VEEAM. VEEAM is a backup product that has a few features that enable our journey. The first is it is 100% VMware compatible and aware so it will work efficiently and effectively to back up the data contained in our VMware environment. Second it is optimized for disk based backups, this will allow us to remove dependence upon tape systems.
- Cloud Gateway – for this we will choose the Amazon Storage Gateway. This is a piece of software that sits in a VMware environment and allows for storage that is moved to it to be replicated securely to the cloud. This will work as our repository for our VEEAM backups and the method of transport to the cloud for the data.
- Cloud Provider – for this we will choose Amazon Web Services and primarily the Amazon S3 storage offering. This will be the location that our backup data will move to and be safely stored in the cloud. We chose this because of the gateway being integrated into Amazon and because we can use the VEEAM data to create Amazon EC2 instances when we need compute resources. The advantage of this model is we only pay for the S3 storage the majority of the time and can use “on demand” EC2 compute instances when we do tests or during a full disaster. This allows us to only pay for compute when we need it which can drastically reduce overall infrastructure costs, since in a DR scenario, we only need compute at times of tests or disaster.
So the overall thrust of this model is we will back up our VMware environment and have it migrate to the cloud. We pay for the storage portion of the cloud but only during testing and disaster do we pay for computing instances. This allows us to gain the following items:
- Reduced cost of both labor and infrastructure as we have no secondary computing to pay for unless we are using it. We also have no tape management to deal with in terms of labor. Further our backups will move once taken immediately offsite and there is no need for people, shipping containers, trucks and vaulting process, it moves automatically offsite as part of the backup process.
- Ability to remove complexity from the backup process. People are not touching tapes, making sure new tapes are added or managing sending tapes offsite.
- Speed of restore is improved. Since we are taking backups to local disk and sending that offsite to cloud disk, the majority of our operational restores will happen from this local disk, so restores will be at disk speed, no waiting for tapes to load, come back from offsite vaults etc.
For more technical specifications and requirements, contact us. Evolving Solutions has tested this scenario in depth and knows the limitations and requirements.
In a future blog post, I will go into a second scenario where the key goals are the speed of return to operation (RTO) and minimization of data loss (RPO).
James Keating III is a Business Technology Architect for Evolving Solutions. James is a technology leader in the IT community and brings a combination of excellent technical skills and business acumen which allows him to guide customers in developing IT solutions to meet business requirements.