An interesting feature in vCloud Director networking is the capability of creating a fenced vApp. Basically, it’s like having an extra (in case you have one for Organization network which means routed) vShield router and firewall on the edge of vApp.
One of the coolest applications for fenced vApps is when you want to have identical machines (same IP and MAC) in your vDC; it means when you want to do a fast clone without customizing guest OS by changing IP’s and names, … In this case vApps are completely isolated while they can have connection to External networks or perhaps internet! See here for a how-to about creating fenced vApp.
After you created a fenced vApp, you will notice that the IP addresses in the vApp are in the same subnet with Organization Network (see the picture above), although a NAT gateway is operating between the vApp and Organization network. So when you want to do a DNAT (Destination NAT), there are 2 places you should configure. In the picture above, suppose you want to give access to a VM with IP 192.168.0.45 in Fenced vApp from External Network. Assume that Edge 1 got IP 192.168.0.3 (specified while fencing). First, you need to create appropriate rules in Edge Gateway of Organization Network, Edge 2 (if there is any) to NAT and open ports for the IP address of Edge 1 (192.168.0.3)
Next step, you need to do NAT and open ports from Edge 1 to specific VM but this configuration is not in Edge Gateways of vDC (unlike Edge 2) but can be found in Networking Tab of the vApp itself.
Click on the vApp, go to Networking tab,
right click on the selected network and choose ‘Configure Services’. there, you can define appropriate NAT and firewall rules.
Sometimes you feel like implementing a powerful edge gateway in your VMware vCloud environment. Let’s say you have heavy load and you plan to use load balancer capability of edge gateway in VMware vCloud Director. Unfortunately hardware configuration of vShield edge gateways are not customizable through vCloud Director and changing hardware configuration through vCenter is not possible. Also, hardware templates for use as edge gateways are limited in terms of processing power and memory. There are 3 pre-defined hardware configurations in vCloud Director 5.5: Compact, Full and Full-4. Full-4 type is a new one in vCloud 5.5 and as I know Full gateways in vCloud 5 are upgraded to Full-4 automatically when you upgrade the infrastructure to version 5.5. In brief, hardware configurations for vShield edge gateways are as follows:
- Compact: 1 * vCPU and 256 MB of Memory – 64000 concurrent sessions
- Full: 2 * vCPU and 1024 MB of Memory – 1,000,000 concurrent sessions
- Full-4 (new in vCloud 5.5): 4 * vCPU and 1024 MB of Memory
I didn’t find updated detailed information for vCloud 5.5 but you can see more details about edge gateway specifications and performance parameters in vCloud Director 5.1 at this useful link.
As you see, hardware power is limited especially in regards to memory. So, in case you need a memory intensive edge gateway (Load balancer is a good example) you need to upgrade the hardware. Although there is no direct method to this through vCloud Director admin panel, the fact is that vShield Manager has this capability to implement x-large gateways. x-large edge gateway in VMware Networking and Security 5.5 has 4 * vCPU and 8GB of Memory that is quite considerable.
As VMware recommended, if you need to upgrade hardware configuration of an edge gateway in vCloud Director, you can use vShield portal to do so. As it’s shown in the following picture, login to vShield Manager admin panel, choose your Datacenter, on ‘Network Virtualization’ tab select ‘Edges’, click on the edge gateway you intend to upgrade and finally from Actions menu choose: ‘Convert to X-Large’. That’s all.
Just keep in mind that in the picture above login to vShield Manager is done via vCenter. So, the ‘Network Virtualization’ tab shown in the figure is within vCenter; however it’s a bit difficult to get into vShield Manager through vCenter and I faced some weird errors about Acrobot Adobe! As a result, I recommend to use vShield Manager directly to avoid such issues.
One of the features of edge gateways in VMware vCloud Director is the capability of implementing load balancer for HTTP, HTTPS and TCP-based applications in a virtual data center. For web applications (in specific HTTP), session management is an important matter. If web developers don’t implement session management in application level (using database, … to store sessions) and rely on Cookies, load balancer could be an issue. In these cases, network administrators are asked to configure load balancer with sticky session. Simply it means that if a client is forwarded to a web server for the first time (especially login page), it should stick to that specific server in later web requests. If it doesn’t happen, user may be forced to login again that would be frustrating!
By the way, when it comes to configuring vShield Edge Gateway to do load balancing, there is no obvious option to choose Sticky Session but it’s possible to do this by specifying proper value for Cookie name in the Virtual Server. As it’s shown in the picture, the procedure is as follows. I assume that you already know how to implement Load Balancer by creating Pool Servers and Virtual Server. See this link fore more information on how to create Load Balancer.
- Right Click on the Edge Gateway and choose ‘Configure Services’
- Select ‘Load Balancer’ tab
- Go to ‘Virtual Servers’ section
- Edit selected Virtual Server
- Choose ‘Cookie’ as Persistence Method instead of default ‘None’
- Type proper value as Cookie Name; i.e, ‘ASP.NET_SessionId’ for .NET application, ‘PHPSESSID’ for PHP, … (ask your developer)
In VMware vCloud Director 5.1, NAT (Network Address Translation) and PAT (Port Address Translation) can be implemented using Edge Gateway of a vDC. Edge Gateway is created by Networking and Security component if you want a routed network in your Virtual Data Center.
Both NAT and PAT rules can be added/configured in Edge Network Services under NAT tab. There you can define Source NAT/PAT (SNAT) or Destination NAT/PAT (DNAT) rules. Apparently, SNAT provides connectivity to external network for your internal network users/machines and DNAT provides access to your internal network (the whole network or a specific machine or a specified port) from an external network.
The interesting point is that as it shown in the figure, in both cases, either SNAT or DNAT you have to choose your external network (‘Internet’ in this example) as the ‘Applied on’ network.
The other important thing is that you need to have a Firewall rule for NAT/PAT rules. For example if you are PAT’ing port 80 of an external IP to port 80 of an internal IP (DNAT), there must be a rule in Firewall that allows access to port 80 of external IP. In fact, in this case it is firewall that acts first; after firewall allows the connection, translation (DNAT) would be done.