Using Dyn to Automate DNS failover Between Cloudhelix and Amazon EC2

In this post we will detail the creation of a demo hybrid cloud solution?—?the result being a website hosted on the Cloudhelix platform, with Dyn providing automatic DNS-based failover to an Amazon EC2 instance.

Summary

The solution has the following components:

• Compute 1: vCloud Director VDC on the Cloudhelix platform.
• Compute 2: Amazon EC2 instance, with a private VPC.
• Network: Amazon Direct Connect with a customer-dedicated BGP session between a
• Cloudhelix-managed VRF and an AWS Virtual Private Gateway.
• DNS: demo.cloudhelix.io has an Active Failover service provided by Dyn (for more information: http://dyn.com/managed-dns/active-failover/)

Compute 1

Within our ‘cloudhelix-demo’ VDC a vApp has been created, which contains a CentOS VM?—?clh-web-01, IP 10.100.1.50.

A DNAT entry of 185.43.40.22 -> 10.100.1.50 has been added to the vShield Edge, along with a firewall rule allowing HTTP traffic (an SSL VPN is in place for other administrative traffic).

Compute 2

An EC2 instance of the Amazon Linux AMI has been launched?—?aws-web-01?—?which has private IP 172.31.41.82, and public IP 54.76.198.109. Its security group allows HTTP from all, and SSH from 10.100.1.0/24.

Network

Each connection to a customer AWS VPC requires a separate VLAN and a separate virtual interface (associated with the AWS account) which runs over Amazon Direct Connect. A BGP session is required to advertise routes. At the Cloudhelix end we will provision a VRF on a segment of our core routing hardware?—?this will then establish a BGP session with Amazon on your behalf. The virtual interface will show in your Amazon account under Direct Connect -> Virtual Interfaces?—?once it has a state of ‘available’ you are ready to go!

Assuming route propagation is enabled within your VPC, a route to the remote network will automatically appear.

The net result is that the vCloud Director VM will be able to route to the AWS EC2 instance and vice versa. This is not required for the DNS failover to work, however it is used for day-to-day administration, file transfers, and so on.

DNS

A simple demo webpage has been added to both servers which indicates which platform it is running on.

Using the Dyn management console, an Active Failover service has been added for demo.cloudhelix.net.

This has 185.43.40.22 (Cloudhelix vCD) configured as the primary IP address, with 54.76.198.109 (Amazon EC2) configured as the failover IP address. If the primary fails to respond to HTTP healthchecks, the A record (which has a TTL of 30s) will be changed.

Normal operation:

The webpage is being served from the CLoudhelix webserver.

Apache is then stopped on the Cloudhelix webserver:

The healthcheck fails, and the DNS record is then automatically updated by Dyn:

The webpage is now being served from the Amazon EC2 instance?—?some extra information about the instance is being displayed on the page (output generated from the ec2-metadata command available in the cloud-utils package).

The Dyn service can also be configured to send out an email alert detailing the status change. It will automatically fail back once the primary is responding again, unless configured for manual failover.

Hopefully you will agree with our opinion that the combination of the technologies above to provide a multi-provider, resilient solution is a great hybrid cloud example! Automatic failover combined with the concept of a private link between your Cloudhelix VDC and Amazon VPC gives you a world of possibilities.