In many ways, the public cloud is an outgrowth of large colocation providers and ISPs buying up servers and creating a lucrative outsourced server industry. In the late 1990s, these large players started the trend of making the physical virtual; that was the state of the market until recently.

Then came the cloud and all its benefits that are too numerous to mention. For the last couple years, the cloud has been a showcase for proof-of-concept efforts and pilots with very few real production deployments save those from a handful of new companies that were born in the cloud. For the most part enterprises — you know, where the money is — have not significantly adopted the cloud computing model.

The lack of enterprise adoption can be attributed to a slow shift from cloud build out (focusing on putting virtual infrastructure in place) to enterprise use and management. It is this slow shift that forms the basis of this article; the shift has brought the focus onto the cloud users — maybe best described as cloud "tenants" — instead of on the cloud providers.

There is a completely new separation of concerns among the three market layers:

• The physical provider.
• The virtual provider.
• The cloud tenant.

This separation concerns the capabilities that each of those layers enable, allow, and control.

Traditionally, the physical infrastructure providers control the underlying hardware; they provide the cloud tenant with egress and ingress at the most fundamental level. As long as the packets flow, the tenant doesn't care. The virtual infrastructure provider manages the hypervisors and V switch or equivalent; his role, by all accounts, is outside the tenant's scope of concern as well.

The year 2010 in cloud adoption has increasingly been about how to help cloud tenants use these agile public, on-premise, or hybrid cloud infrastructures. And to clear up the miscommunication that the only path to cloud and virtualization adoption is by completely re-architecting existing systems to address potential scaling issues or to accommodate a specific cloud stack.

So the two questions are:

• How do you help enterprises understand that they aren't locked into a complete redesign of their existing applications and data systems in order to effect a successful migration to the cloud?
• How do you help those enterprises start their journeys to this agile infrastructure?

The answer is the same for both questions: Show them how they can maximize the reuse of existing skills, infrastructure, and software. Without having to face infinite risk, pain, and change.

In this article, I will demonstrate how using a virtual network can give the enterprise user control of addressing, topology, protocols, and encrypted communications for the devices the user deploys to the cloud. As a result of this virtual networking at the tenant layer, one of the highest-ranking concerns about cloud computing from a tenant's point of view, security, is eased since the tenant gains more control over the networking aspects of his cloud deployment.

Now let's look at the virtual network.

The virtual network

A virtual network is a computer network built on top of another network. Nodes in the virtual network can be thought of as being connected by virtual or logical links, each of which corresponds to a path, perhaps through many physical links, in the underlying network.

Cloud-based virtual networks can be used to maintain control across multiple locations, allowing the customer to control their own network topology, the network addressing, encrypted communication, and desired network protocols, all in a scalable, highly redundant form.

Virtual networks are based on redundant, encrypted, point-to-point connections from cloud-based servers to hybrid virtual appliances running in the cloud. These hybrid devices act as virtual switches and routers of this virtual network which essentially sits above your physical network. A virtual network gives a customer a common LAN-like network where the servers can be located in the physical data center (virtualized or not), private cloud, and public cloud.

The advantages of virtual networks in the cloud are:

• They allow user control over:
  • Addressing (custom private addressing for cloud-based servers).
  • Topology (virtual network comprised of virtual switches, virtual bridges, and virtual routers).
  • Protocols (protocols like UDP Multicast are available for service election/discovery).
• Encrypted communication between cloud-deployed servers.
• Secure connection to existing data-center-based extranet solutions via an IPsec tunnel.
• Abstraction of location from network identity which allows for quick and easy disaster recovery.
• Provides a user-controlled layer of security for compliance reporting and auditing.
• Allows existing NOC to monitor and manage the cloud-based servers.

Now let's look at some considerations for setting up a virtual network.

Back to top

Setting up a virtual network

Setting up an virtual network requires little modification of the customer's data center network infrastructure. Connections to the cloud side of the virtual network are done via existing IPsec extranet devices using parameters tested and proven by the organization — the same way current organizations set up extranet connectivity to partners and vendors. Encrypted IPsec connections are made to the virtual network appliances and routes are put in place so the cloud-based servers can communicate with the appropriate data-center-based servers.

Setting up the cloud side of the virtual network is very similar to setting up a network in a physical data center. In the physical case, servers need to be connected to each other via cables and switches and in some cases connected to the Internet via a firewall/edge router. The cloud requires a virtual abstraction — cloud-based virtual network manager instances serve as virtual switch, firewall, and router and client VPN connections from the cloud-based servers to these manager instances are required to handle the encrypted communication inside the cloud. The manager instances route the IPsec tunnel traffic to the data center and act as encrypted switches between the cloud-based servers.

Back to top

Networking protocol configurations

Virtual networks make use of virtual switches. This does entail another I/O hop through the switch when communicating to servers in the cloud, but the tradeoff is the ability to know your data in motion is secure and encrypted.

When building out a physical network (when you are "configuring metal"), availability is a major concern; having active/passive server setups where you have a replacement sitting and waiting in the event of a failure. This is the norm and it can be expensive and cumbersome to manage. When using virtual networks, you are also using virtual network gear, so there's no "metal in waiting." Backups can be provisioned on-demand through existing monitoring tools, thus reducing overhead and increasing utilization.

This process is safe and it reuses your team's existing skills: IPsec for site-to-site and Secure Sockets Layer in the cloud segments. Your IT teams already know how to configure, manage, and monitor these now. With the virtual versions, they get to do this in a dynamic (both meanings here) fashion.

Back to top

Example: Demonstrating cloud automation capabilities

Now I'd like to show you an example of what I've been discussing. Here is a network I am constantly setting up and tearing down. At CohesiveFT, 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 the IBM Dev & Test Cloud Raleigh RTP and Einighen EHN with redundant VPN-Cubed (VPN3) managers running in the primary segment (RTP). 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 IBM 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.

I designed this network using our VPN3.2.0 (release candidate 3) AMIs at RTP and EHN. This next release which includes a command-line API, virtual firewall, and 64-bit support is definitely our best effort to date. You can take a look at the network creation process configuration video.

Once I designed the 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 to use to then re-inflate the networks.

Armed with these snapshots, I can then use the VPN-Cubed 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):

<ibm-cluster>
<cluster-settings>
<defaults>
<server-size>bronze-32</server-size>
<images-availability-zone>RTP</image-availability-zone>
</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 - RTP">
 <image-id>20009551</image-id>
 <ip>1xx.1xx.2xx.xx</ip>
 <server-size>bronze-32</server-size>
</instance>
<instance name="Motion VPN-Cubed Manager 2 - RTP">
 <image-id>20009551</image-id>
 <ip>1xx.1xx.2xx.xx</ip>
 <server-size>bronze-32</server-size>
</instance>
<instance name="Motion VPN-Cubed Manager 3 - EHN">
<image-id>20009551</image-id>
 <images-availability-zone>EHN</image-availability-zone>
 <ip>1xx.xx.xx.xx</ip>
 <server-size>bronze-32</server-size>
</instance>
<instance name="DemoOffice VPN-Cubed Manager 1 - RTP">
<image-id>20009551</image-id>
<images-availability-zone>RTP</image-availability-zone>
 <ip>1xx.xx.2xx.xxx</ip>
 <server-size>bronze-32</server-size>
</instance>
</group>
</instance-groups>
</ibm-cluster>

I then can remake and peer my network connections by uploading the proper snapshot to the new manager at the appropriate public IP. Armed with the API (vpncubed.rb), the instance IDs of the newly launched instances, the IP'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 to use 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 these two data centers and with a modicum of additional network design, I can jump things to other public and private clouds. And the fun of it is, it's scriptable and reproducible at will.

Back to top

In conclusion

Virtualization and cloud computing are creating new junctures in how systems are assembled, deployed, and managed. The success of virtualization and cloud initiatives rests on the ability of existing IT departments to maximize the reuse of their skills, infrastructure, and software. A virtual network that can be configured and run by an IT staff already familiar with configuration and management of a traditional networks and VPN is one such example.

Due to the global recession, the enterprise has been a tough place to be in the last few years with flat IT budgets and head counts. Cloud's ability to reuse IT resources and skills is a shining light in this gloom. By providing the mechanisms to enable better customer control of their own data resources as they move back and forth over the networks to and between cloud environments, you can deliver a higher level of customer confidence in the security of cloud systems. And that can only lead to an increased migration rate of enterprises adopting cloud computing.

Resources

Learn

• Learn more about VPN-Cubed technology and CohesiveFT.
  
  
• The VPN-Cubed image is available as a pre-release, with VPN-Cubed Datacenter Connect production version coming in 4Q 2010. Access the image, or find out how to get started on IBM Smart Business Development and Test on the IBM Cloud.
  
  
• The IBM Smart Business Development and Test on the IBM Cloud site is your place to see how to start developing your applications for the cloud. See the growing list of software images available on the IBM Cloud.
  
  
• In the developerWorks cloud developer resources, discover and share knowledge and experience of application and services developers building their projects for cloud deployment.
  
  
• Brian Snitzer talks about the VPN-access technology released as part of the IBM Development and Test on the IBM Cloud Release 1.1. Read | Listen.
  
  

Discuss

• Join a cloud computing group on My developerWorks.
  
  
• Read all the great cloud blogs on My developerWorks.
  
  
• Join the My developerWorks community, a professional network and unified set of community tools for connecting, sharing, and collaborating.
  
  

About the author

Rate this article

Comments

Back to top

Table of contents

• The virtual network
• Setting up a virtual network
• Networking protocol configurations
• Example: Demonstrating cloud automation capabilities
• In conclusion
• Resources
• About the author
• Comments

Next steps from IBM

Learn more, join the cloud community

---

• Community: Cloud computing conversations led by IBM community members
• Buy: Try IBM software on IBM SmartCloud Enterprise

Dig deeper into Cloud computing on developerWorks

IBM SmartCloud trial. No charge.

Unleash the power of hybrid cloud computing today!

---

Public and private solutions in one trial.

Special offers