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.
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.
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.
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.