Inspired by my colleague Wayne Silberman’s most excellent post on low-cost disaster recovery with Clumio, I decided it was time to grab the world’s largest can of energy drink and tackle a very frequent ask from our customers: Can you help me automate the recovery of my virtual machines to VMware Cloud on AWS (VMC) in a disaster?
We sure can. Let me walk you through the architecture and deployment of VM-Recovery-Lambda that I wrote with this specific purpose in mind.
Clumio’s stateless and scalable architecture is uniquely suited for this task. As an authentic SaaS platform built natively in AWS, Clumio’s entire backup and recovery infrastructure shares the same network backbone as VMC. Our intelligent use of AWS endpoints and Elastic Network Interfaces (ENIs) means all backup and restore traffic never leaves AWS. For backup and recovery, this means no egress fees. More relevant to this effort, it means end-to-end 25Gbit performance.
Furthermore, Clumio’s publicly accessible APIs are a developer’s dream: our platform is not reliant on the availability of your data centers or opening firewall ports to a physical appliance. The Clumio API gateway, as with all of our architecture, is built serverlessly in the cloud. This means you don’t need to host scripting jobs on a persistent (and operationally opaque) VM in the data center. This is the magic of AWS Lambdas!
Deploying the VM Recovery Lambda
Prerequisites: VMC infrastructure is provisioned and registered to Clumio. See Wayne’s post for more details.
1) Deploying the Lambda via Cloud Formation Template (CFT)
Lambdas are ideal for this task both for their availability in the event of a data center loss, and their relative adjacency to our target infrastructure (they’re fast). Ideally, you’ll want to create your Lambda in the same AWS region as the VMC environment we are recovering into. To simplify the deployment of this automation, I packaged the Lambda settings and permissions into a CFT. All resources for this lambda can be located on the Clumio Github page.
After uploading the CFT template YAML file, accept the default values and deploy (Figure A). The CFT will create a customized Lambda and the required IAM role in less than a minute.
2) Upload Supporting Files to S3
The recovery lambda needs two input files to provide credentials and guide the VM recovery actions. After customizing the files for your needs, you’ll need to upload the JSON based credentials file (Figure B) and the CSV based recovery plan (Figure C) to an S3 bucket (Figure D) in the same region.
3) Define Environmental Variables
With all of our infrastructure in place, the last remaining step is to specify the S3 location of the credential and recovery files within the lambda. This is done with the Environmental Variables (Envars) section. The variable keys will be predefined by the Cloud Formation, you only need to specify the S3 bucket and files names.
With our automation now fully configured, you can create a test event and run the newly created Lambda. Depending on how many VMs are being recovered, the Lambda could take up to several minutes to run. Each recovery job is logged in AWS Cloudtrail for reporting and debugging purposes.
Thanks for stopping by to learn about Clumio’s RESTful automation capabilities with AWS Lambda. Cost effective Disaster Recovery (DR) in the cloud is a common conversation with customers, and on-demand VMC infrastructure makes it easy. With high performance AWS-native VMware infrastructure at your fingertips and extensibility of Clumio’s simple API based recovery workflows, customers can now meet business critical DR requirements that they have long struggled to procure due to cost and complexity.
Interested in trying this out yourself? Head over to the Clumio Trial page where you can sign up for a free 30-day test drive of our platform and begin your journey with infrastructure-free data protection!