I love Cloud Networking infrastructure. And by that I mean Virtual Networks I can create within a public cloud, across public clouds, and across public clouds and multiple private infrastructures (whether private cloud or traditional data center infrastructure).
I am not talking about the way down there - way below me - the massive grunting beasts of the data center the Cisco or Juniper Model Number whatever. They provide me egress and ingress at the most fundamental level but as long as my packets flow - that's all I need from them.
I am not talking about the fair bit below me - for the most part out of my scope of concern as well - the humming, hypervisor-centric accelerator, the "v" switch or its metal equivalent, the device that the virtual infrastructure provider uses to make all those hypervisors able to talk to each other. Its job is to network together hypervisors and be the first line of transport for all those virtual ethernet adaptors stuck inside all of our/my Virtual Machines. This is the guy that potentially collaborates with my virtual infrastructure providers (my IT department, Amazon, others) to, despite all my best efforts, systematically destroy the concept of device "MAC" address, leaving me prone to wonder how I could have used something now so ephemeral as a permanent identity all these years.
I am talking about my life as a "cloud tenant". Whether a private fabric or cloud, or a public fabric or cloud, I am a tenant. I use all of that "goop" below me in indirect ways and there is a completely new separation of concerns between the three layers (physical provider, virtual provider, and cloud tenant) and those things which we each Enable, Allow and Control.
So with that as the precursor here is a network I am constantly setting up and tearing down. We use it for a variety of demonstrations of our cloud automation capabilities. It has these properties:
- A 172.31.1.0/24 subnet overlaying Amazon West and Amazon East with redundant VPN-Cubed (VPN3) managers running in the primary segment (West). It is an application network running an N tier, clustered java application running on a clustered MySQL setup.
- A 192.168.1.0 network running as a floating "office network" in the EC2 cloud capable of running Windows and Linux remote desktops. This has an IPsec connection to the main application network and back to CohesiveFT's offices.
- A 192.168.3.0/24 network at CohesiveFT Chicago accessible to and from the other parts of the cloud network.
Here is a high level picture:
I designed this network using our VPN3 2.0 (release candidate 3) AMIs at EC2. This next release which includes a command line API, overlay firewall, 64 bit support and more, is definitely our best yet. To see the network creation process check out our configuration video.
Once I designed my network, I took snapshot files from each of the VPN3 Managers. These snapshots contain network configuration and credentials information. I save those in a secure location for use to then re-inflate the networks.
Armed with these snapshots I can then use our Context3 Cluster Launch tools to process an XML definition of the instances needed. It looks like this (this is a very simple cluster launch file):
<ec2-cluster>
<cluster-settings>
<defaults>
<ami-type>m1.small</ami-type>
<ami-security>vpncubed-mgrA</ami-security>
<ami-security>started-by-pk</ami-security>
<ami-availability-zone>us-east-1c</ami-availability-zone>
<ec2-endpoint>us-east-1.ec2.amazonaws.com</ec2-endpoint>
</defaults>
</cluster-settings>
<instance-groups>
<group id="1" name="VPN-Cubed xCloudMotion">
<instance-post-launch-delay>1</instance-post-launch-delay>
<group-post-launch-delay>1</group-post-launch-delay>
<instance name="Motion VPN-Cubed Manager 1 - East">
<ami-id>ami-ce9366a7</ami-id>
<elastic-ip>1xx.1xx.2xx.xx</elastic-ip>
<ami-type>m1.small</ami-type>
</instance>
<instance name="Motion VPN-Cubed Manager 2 - East">
<ami-id>ami-ce9366a7</ami-id>
<elastic-ip>1xx.1xx.2xx.xx</elastic-ip>
<ami-type>m1.small</ami-type>
</instance>
<instance name="Motion VPN-Cubed Manager 3 - West">
<ami-id>ami-60e0b125</ami-id>
<ec2-endpoint>us-west-1.ec2.amazonaws.com</ec2-endpoint>
<ami-availability-zone>us-west-1a</ami-availability-zone>
<elastic-ip>1xx.xx.xx.xx</elastic-ip>
<ami-type>m1.small</ami-type>
</instance>
<instance name="DemoOffice VPN-Cubed Manager 1 - East">
<ami-id>ami-ce9366a7</ami-id>
<ami-availability-zone>us-east-1d</ami-availability-zone>
<elastic-ip>1xx.xx.2xx.xxx</elastic-ip>
<ami-type>m1.small</ami-type>
</instance>
</group>
</instance-groups>
</ec2-cluster>
As this definition is processed I get some important information for use in subsequent commands like the instance id which is used is the initial default API password for the individual VPN3 managers.
I then can remake and peer my network connections by uploading the proper snapshot to the new manager at the appropriate Elastic IP. Armed with the API (vpncubed.rb), the instance ids of the newly launched instances, the EIP's assigned to the newly launched instances, and the pre-saved snapshot files from my design phase.
vpncubed.rb -K api -S $mgr1_id -H $mgr1_ip import_snapshot --snapshot $mgr1_snapshot
vpncubed.rb -K api -S $mgr2_id -H $mgr2_ip import_snapshot --snapshot $mgr2_snapshot
vpncubed.rb -K api -S $mgr3_id -H $mgr3_ip import_snapshot --snapshot $mgr3_snapshot
vpncubed.rb -K api -S $mgr4_id -H $mgr4_ip import_snapshot --snapshot $mgr4_snapshot
A few minutes later - it is all up and running again. It is ready for using Context3 to deploy the N-tier clustered application and my floating remote office infrastructure in a matter of minutes.
Without any re-work other than the definition of the network in cubesetup.xml I can move my topologies easily between availability zones and these two regions, and with a modicum of additional network design I can jump things to EC2 EU, EC2 APAC or other public and private clouds. And the fun of it is - it's scriptable and reproducible at will.
If you want to try out "import_snapshot" or other fun scriptable cloud network calls such as setup_ipsec, get_ipsec_local_address, set_ipsec_local_address, create_ipsec_endpoint, create_remote_subnet and more email us at "vpn3beta (at) cohesiveft.com".
(pat k)
