vCenter Chargeback and vCloud Director 5.1 in DMZ

Recently in the Load Balancing vCloud Director Cells with vShield Edge post I described typical vCloud Director architecture where vCloud Director Cells are multihomed and placed in DMZ with firewall separating it from the internet and the management zone.

VCD Design

When vCloud Director is installed two IP addresses have to be specified. One for binding the GUI portal and API access the other for binding the remote console proxy. In the diagram above there are both on the nortbound interface(s) and load balanced and firewalled from the internet. The cells need to communicate with vCloud Director database, Resource Group ESX hosts and other management systems (Resource Group vCenter, vShield Manger, etc.). For this in the diagram above the southbound network interface is used. Btw it does not need to be specified during the vCloud Director installation as guest OS IP routing table decides which interface is used. The cells also need to talk to each other directly (see the note at the end of the article). Some customers do not allow multihomed VMs that would bridge security zones – then the set up looks different but that is out of scope for this article..

So what all that has to do with Chargeback? vCenter Chargeback Manager is additional management system (usually installed in the management zone) that needs to communicate with vCloud Director in order to retrieve grouping of tenant resources (resource pools, VMs, networks, etc.) to so called hierarchies. Chargeback uses vCloud Director Data Collector for this. The collector can be installed together with the Chargeback server or as a standalone component. In the vCloud Director 1.x version the VCD Data Collector directly retrieved the needed information from vCloud Director database. The VCD Database has usually direct connectivity to the management zone so that was not an issue.

However in vCloud Director 5.1 the Data Collector does not talk to the VCD Database anymore and instead uses vCloud API (bound to the north VCD cell network interfaces) to retrieve the hierarchies. And this might be an issue if security rules prohibit routing between management zone and the internet DMZ zone. Note besides Chargeback there could also be deployed additional systems that need to talk to vCloud API – vCenter Orchestrator, vFabric Application Director, vCloud Automation Center or any third party system.

There are two options how to solve this problem:

1. Placement into DMZ

We can keep the Chargeback in the management zone, but deploy the Chargeback VCD Data Collector into DMZ next to the cells. The following diagram shows the setup.

VCD Data Collector

The data collector is a dual homed Windows VM. It talks to the vCloud API via its north interface – I have included additional vShield Edge internal IP address (10.0.1.2) for the internal load balancing of cell API interfaces (10.0.1.60 and 10.0.1.62). The south interface is used for communication with the Chargeback database.

2. vCloud Director Management Cell

Additional vCloud Director cell(s) is deployed with the http (GUI + API) interface bound to the south interface.

VCD API Cell

The VMware Remote Console (VMRC) proxy is still bound to the north network interface and can be used for load balancing VMRC traffic coming from the internet. All the management systems that need to talk to vCloud API can do so directly from the management zone by talking to the 10.0.4.64 IP address.

Note: As was said at the beginning of the article all the vCloud Director cells communicate with each other over ActiveMQ message bus. The bus is always using the primary (http) IP address of the cell and this cannot be changed. Therefore each cell must be able to reach all the others on the http interface. So a design where the VCD3 (API) cell is connected only to the management network would not work. What would be the impact? For example there is always only one vCenter Proxy services running on one of the cells for a particular resource vCenter Server. The VC Proxy service is responsible for invoking operations on the vCenter and listening back on their progress. However any cell can pick up a particular task and if it cannot reach the VC Proxy the task will fail.

Advertisements

2 thoughts on “vCenter Chargeback and vCloud Director 5.1 in DMZ

  1. Hi Tom
    In the Install guide (2.5.1) it states several times, “first install the load balancer on the DMZ network and then install vCenter Chargeback Manager and the data collectors in the internal network.” What’s your take on that?. In my case management systems shouldn’t talk directly to vCloud API.

  2. Chargeback Manager itself can be installed in load balanced configuration. The loadbalancer is part of the Chargeback installation and must be always installed. Then you can have multiple Chargeback Manager servers. The LB could be in the DMZ if you want to give access to it to end users which is usually not the case. In my picture I have installed Chargeback LB, Chargeback Server and vShield Manager and vCenter collectors all on one VM. Only vCloud collector was separate.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s