Do you love screenshots? I have just the post for you!
When first introducing users to vCloud Director several people walk away confused about how vApp networking actually works. I posted earlier about how vApp networking makes life easier, but didn’t necessarily illustrate how vApp networks are built.
To make things a bit clearer I will step through the construction of a brand-new vApp living within a vCloud Director Organization. The Org is a tidy one that offers two networks: one isolation network and one Internet network. For our example, let’s ignore the isolation network and just focus on the Internet network.
Let us start with an example of a 3-tier web application. We have an HTTP server, an application server and a database server. To better isolate our virtual servers we want two networks dividing them: one for the application server and database to live within, the other for the HTTP server to live in and receive inbound traffic. We will call these two networks “outbound Internet” and “inbound Internet” respectively. “Outbound Internet” will be a 10.0.0.0/24 network and “inbound Internet” will be a 192.168.2.0/24 network.
First let’s create a new vApp within our vCloud Director organization. The new vApp will have three VMs inside: Web01 for our HTTP server, App01 for our application server and DB01 for our database server. For now each server has one network interface (NIC). Let’s see the options we are given for networks as we define our vApp:
Behold, this is the first major stumbling point we hit across. Your instincts may tell you to connect directly to our “internet01” network, but this would create a direct connection to an organization network. We really want to create a new vApp network, something that sits on top of the organization network. So instead of selecting a network from the drop-down list we will select “Add Network…”
By using the “Add Network…” selection we can create both our “inbound Internet” and “outbound Internet” networks by giving them an address range, gateway and DNS servers. Bear in mind the gateway IP address doesn’t have to exist – vCloud Director will automagically create this gateway for you as a vShield Edge device every time you start your vApp. Nice!
Before you hit the “Finish” button to add our new networks, make sure you select the “Show networking details” check box. Here you will establish a direct connection to our organization network, internet01. This effectively creates a bridge between your vApp network and your organization network.
We will assign Web01′s NIC to the “inbound Internet” network, since it will be the only one receiving inbound requests from the Internet. DB01 and App01 will be assigned the “outbound Internet” network, since we only want to to have outbound connections to the Internet.
Once we’re happy with the names and settings, click “Finish” to complete the construction of your vApp. Don’t power things on just yet! We still need to tweak a few things in the “Networking” tab of your vApp.
We need to switch our “outbound Internet” network to one that masquerades connections through a single IP address. By clicking on the “Details” for the network we can define port forwarding and IP masquerading.
For our inbound network we need to establish a set of firewall rules that allow HTTP traffic through. By clicking on “Details” and checking out the firewall policies, we can map our internet IP address to the external, Internet IP address.
We are finished with our networks, but we need to do one final tweak to our Web01 virtual machine. Since it needs to both talk to the Internet as well as talk to our application server, it needs to have two network interfaces – one for each network. Let’s jump into the hardware details for Web01 and add an additional network interface to connect to our “outbound Internet” network. Web01 should now be able to speak with both of the vApp networks we have created.
We are ready to power up on the vApp! Once we power up the entire vApp the new vShield Edge devices are created to service our networks, VMs are powered on and IP addresses are allocated to each virtual machine from their connected networks.
Fantastic! Now we have created a n-tier web application with both a public-facing and a private network. The best part: we can now clone or download this vApp and all the network settings stick with it. Now that we’ve done the hard work never again do we need to re-wire our network, even if we move it do a completely different data center.
I would love feedback from other users who have been leveraging vApp networking. If you think I have omitted an important step, or if you have a novel way to leverage these portable network layouts, leave a comment and share your insights!
Sensitive data and applications need to be protected, but they also need to be secure and easily restored when disaster happens. That’s why customers trust Bluelock Disaster Recovery-as-a-Service (DRaaS) + Veeam Cloud Connect. This solution allows customers to expand their recovery options, providing afully integrated, fast and secure way to backup and restore in the cloud.