This article is part 3 of my vCloud vApp design considerations and use cases definition. Click here to read Part 1 and Part 2
In this follow on article we will look at some more of the use cases for vApp’s and what type of vCloud Director networking they will use.
Use Case 3 – vApp Network (Routed)
You would typically use this configuration where there is a requirement for connectivity between multiple vApps but in addition a requirement to provide controlled segregation between them. In this example multiple vApps of the same configuration can be deployed without risk of conflict due to the firewall and NAT capability being introduced. vApps will have connectivity to an isolated Organization network for inter vApp connectivity, but there is no external connectivity available and all network traffic within the Organization is isolated at Layer 2.
If you think of a training environment, where you have a three tier application, with say an Oracle back end database server, changing the IP address on these servers would cause lots of issues and would have to be re-configured everytime you deployed it. Using this method, you can deploy the same vApp multiple times without ever having to change any of the configuration items within the VMs themselves.
The characteristics of these types of vApp are:
-
VMs are connected together on isolated vApp networks
-
Connectivity between multiple vApps through Organization internal network
-
Same configuration can be deployed multiple times
This is one of the great features of vCloud Director, and something that I have personally used multiple times when designing and implementing training environments for customers.
This is great information. The only part I’m confused about is how the “routed” part comes into play. From the diagrams in this post, I don’t understand how this configuration differs from simple fenced configurations on a Organization Network. Also, how would the VMs in the two vApps in the example communicate with each other?