Part- III vCloud Director
Multi-Site & High Availability Design
● vCloud Director supports multi-site federation for global clouds.
● You can link multiple vCD instances for:
○ Cross-site tenant access
○ Workload mobility
○ Disaster recovery
● vCD Cells can be deployed in HA clusters behind load balancers.
● Databases can be replicated for fault tolerance.
7️⃣ Summary Table: vCD Architectural Layers
Layer | Managed By | Components | Purpose |
Application | Tenant | vApps, VMs, Templates | Run workloads |
Tenant | Tenant | OrgVDC, Org Networks, Edge Gateways | Manage resources |
Provider | Cloud Admin | PVDC, Network Pools, Policies | Aggregate vSphere & NSX resources |
Virtualization | Cloud Admin | vCenter, NSX | Abstract physical hardware |
Physical | Data Center Ops | ESXi Hosts, Storage, Fabric | Underlying hardware infrastructure |
✅ In summary:
● vCenter = Core virtualization platform.
● vCloud Director = Multi-tenant orchestration and IaaS layer.
● VCF = Full-stack private cloud foundation for lifecycle management.
● vCD’s architecture cleanly separates provider resources from tenant operations, enabling secure, scalable, and automated cloud environments.
—-----------------------------------------------------------------------------------------------------------------------------------------
VMware vCloud Director Architecture Deep Dive
1️⃣ Architecture Layers
The vCloud Director architecture is divided into three main layers — each serving a distinct purpose and managed by a specific administrative role.
Layer | Description | Managed By |
Infrastructure Layer | Physical and virtual resources (compute, network, storage) managed by vCenter and NSX. | Provider |
Cloud Management Layer | vCloud Director components — cells, database, AMQP, API, and orchestration services. | Provider |
Tenant Service Layer | OrgVDCs, catalogs, networks, vApps, and self-service portals for end users. | Tenant |
These layers communicate through standardized APIs, ensuring abstraction and security between physical infrastructure and tenant workloads.
2️⃣ vCenter & NSX Integration
vCloud Director acts as an abstraction layer on top of vCenter Server and NSX (V or T). They together form the resource and network backbone for the vCD environment.
🔹 vCenter Server Integration
Each vCD instance integrates with one or more vCenter Servers. The integration provides:
● Compute Resource Access: vSphere Clusters and Resource Pools.
● Storage Resource Access: Datastores and Storage Policies.
● VM Management: vCD orchestrates VM lifecycle operations (clone, deploy, power-on) via vCenter APIs.
vCenter Mapping in vCD:
● A vCenter is registered within vCD as a vSphere Resource.
● The vSphere resources are then grouped into Provider Virtual Data Centers (PVDCs).
● Each PVDC can serve one or multiple Organization VDCs (OrgVDCs).
💡 vCD does not replace vCenter — it orchestrates and abstracts it.
🔹 NSX Integration (V or T)
NSX provides the network virtualization layer for vCD:
● Logical Segments (VXLAN/VNI)
● Distributed Routers (Tier-1)
● Edge Gateways (Tier-0)
● NAT, Firewall, Load Balancer, VPN services
Depending on the deployment:
● NSX-V (legacy) → uses VXLAN-backed networks.
● NSX-T (modern) → uses Geneve-backed overlay networks and segments.
vCD consumes these NSX constructs as:
● Network Pools
● Org Networks
● vApp Networks
● Edge Gateways
Benefits of NSX Integration:
● Tenant network isolation
● Self-service network creation
● Policy-driven micro-segmentation
● Multi-tenant routing with no VLAN sprawl
3️⃣ Cloud Cells and PostgreSQL Database
vCloud Director is composed of Cloud Cells, which are the application nodes that deliver web, API, and task processing functions.
🔸 vCD Cells
Each vCD Cell runs multiple services:
● UI Service – handles web portal access.
● API Service – exposes REST API endpoints.
● vApp/Task Engine – executes provisioning workflows.
● Messaging & Queue Service – interacts with RabbitMQ.
● Networking Engine – communicates with NSX Manager.
Cells can be scaled horizontally for high availability — typically behind a load balancer.
Recommended Deployment:
● Minimum 2–3 vCD Cells (HA).
● Shared NFS or S3-backed transfer storage for catalogs and media.
● Load Balancer for API/UI access.
● External PostgreSQL DB.
🔸 PostgreSQL Database
vCloud Director uses PostgreSQL as its core configuration and metadata database. It stores:
● System configuration (organizations, users, policies)
● vApp templates, catalogs, VDC info
● Task history, audit logs, and resource allocations
Database Design Considerations:
● External PostgreSQL preferred for production.
● High availability via replication or clustering.
● Use dedicated compute and fast IOPS storage.
● Back up regularly (e.g., pg_dump, vCD cell-management-tool).
4️⃣ Cloud Resource Management Stack
The resource stack in vCD defines how infrastructure resources are abstracted and delivered to tenants.
Stack Hierarchy:
vCenter (Clusters, Datastores)
↓
Provider VDC (PVDC)
↓
Org VDC (Tenant Allocation)
↓
vApp / VM (Workload)
Each level enforces policies, quotas, and isolation boundaries.
5️⃣ Provider Virtual Data Center (PVDC)
The PVDC is the backbone of vCloud Director. It is a resource container that aggregates:
● One or more vSphere clusters
● NSX network pool
● Storage policies
Purpose: To group infrastructure resources from vCenter and expose them to vCloud Director as a single logical pool.
Key Components of a PVDC:
Component | Description |
Compute Resources | Cluster or Resource Pool from vCenter. |
Storage Policies | Mapped from vCenter datastore policies. |
Network Pool | Backed by NSX-T segments or VXLANs. |
Resource Allocation | Defines how OrgVDCs draw capacity. |
6️⃣ Resource Pools, Storage Policies, and Network Pools
These elements define how resources are consumed within the cloud.
🔸 Resource Pools
● Logical abstraction of CPU and Memory resources.
● Assigned to PVDCs and OrgVDCs.
● Used for tenant quota enforcement.
🔸 Storage Policies
● Define storage characteristics (performance, redundancy, cost).
● Example: “Gold SSD”, “Silver SATA”, “Bronze Archive”.
● Tenants choose storage tiers when deploying VMs.
🔸 Network Pools
● Collection of pre-provisioned networks from NSX.
● Types:
○ VXLAN-backed / Geneve-backed
○ VLAN-backed
○ Port Group-backed
● Used to automatically create Org and vApp networks.
7️⃣ Organization Virtual Data Center (OrgVDC)
An OrgVDC is the tenant’s private virtual datacenter, carved from a Provider VDC.
Key Characteristics:
● Assigned CPU, Memory, and Storage quotas.
● Associated with one or more Edge Gateways.
● Supports multiple network types:
○ Routed (via Edge)
○ Isolated
○ Direct (to external networks)
Each OrgVDC belongs to a specific Organization (tenant) and can contain:
● vApps
● VMs
● Catalogs
● Networks
● Users and Roles
8️⃣ Quotas, Limits, and Allocation Models
The Cloud Provider can define resource allocation models to control how compute and memory resources are reserved or shared across tenants.
Key Parameters:
● CPU / Memory Limit – maximum allocation.
● Reservation – guaranteed resources.
● Shares – prioritization during contention.
These models determine performance, cost, and elasticity for each tenant.
9️⃣ Allocation Models Explained
🔹 A. Allocation Pool Model
● A percentage of the allocated resources are reserved (guaranteed).
● The rest are burstable up to the allocation limit.
Example:
● Allocated: 100 GHz CPU, 200 GB RAM
● Reservation: 50% → 50 GHz CPU and 100 GB RAM are guaranteed; the rest are on-demand.
✅ Best for: Balanced environments where overcommitment is acceptable. ⚙️ Commonly used by MSPs for multi-tenant clouds.
🔹 B. Reservation Pool Model
● All allocated resources are fully reserved.
● No overcommitment allowed.
Example:
● Allocated: 100 GHz CPU, 200 GB RAM → 100% guaranteed for that OrgVDC.
✅ Best for: Performance-critical production environments. ⚙️ Ensures strict SLA adherence.
🔹 C. Pay-As-You-Go (PAYG) Model
● Resources are consumed on demand when VMs are powered on.
● No pre-allocation at the VDC level.
● Provider sets maximum limits and guarantees per VM.
Example:
● Limit: 100 GHz CPU per OrgVDC
● Reservation: 20% per VM → Each powered-on VM reserves 20% of its configured CPU.
✅ Best for: Dynamic, usage-based billing environments. ⚙️ Ideal for public cloud or lab tenants.
10️⃣ vCloud API and SDK Overview
vCloud Director is fully API-driven. Every UI operation corresponds to an API call via REST.
🔸 REST API
● Endpoint: https://<vcd-host>/api/
● Supports XML and JSON.
● Authentication: OAuth / Basic / SAML.
● Used for:
○ vApp/VM provisioning
○ Network configuration
○ OrgVDC management
○ Automation and CI/CD integration
🔸 SDKs
VMware provides official SDKs for:
● Python (pyvcloud)
● Java
● .NET
● PowerCLI Module (VimAutomation.Cloud)
🔸 Terraform Integration
● Provider: vmware/vcd
● Enables Infrastructure as Code (IaC)
● Supports:
○ Org creation
○ VDC provisioning
○ Network & Edge configuration
○ vApp deployments
💡 vCloud API is the backbone of all modern automation — from Terraform to Ansible to ServiceNow integration.
11️⃣ vCloud Director Cell Communication & Load Balancing
🔹 Cell Communication
Each vCD cell communicates with:
● PostgreSQL DB – configuration & state data.
● vCenter(s) – VM management.
● NSX Manager(s) – network provisioning.
● RabbitMQ – async task notifications.
Cells maintain stateless front-end sessions; thus, they can be load-balanced horizontally.
🔹 Load Balancing
Use a Layer 7 Load Balancer (e.g., NSX Edge, F5, or AVI Load Balancer) to:
● Distribute UI and API requests.
● Enable high availability and failover.
● Maintain sticky sessions for UI users.
Example Architecture:
+-------------------+
| Load Balancer |
+--------+----------+
|
+------------+------------+
| vCD Cell 1 |
| vCD Cell 2 |
| vCD Cell 3 |
+------------+------------+
|
[PostgreSQL DB]
|
[vCenter / NSX]
12️⃣ RabbitMQ, AMQP, and Messaging in vCD
vCloud Director uses AMQP (Advanced Message Queuing Protocol) for event-driven communication and task orchestration.
🔸 RabbitMQ Integration
● Acts as the message bus between vCD and external systems.
● Queues asynchronous events like:
○ vApp deployment
○ Network changes
○ Resource allocation events
🔸 Use Cases
● Event Subscriptions: Trigger automation workflows in vRealize Orchestrator or Ansible.
● Custom Integrations: Feed notifications to third-party portals (e.g., ServiceNow).
● Asynchronous Processing: Improves scalability by decoupling tasks from UI threads.
Configuration:
● Define the AMQP broker details in vCD (System > Administration > Extensibility).
● Messages are published under specific routing keys (e.g., com.vmware.vcloud.event.vm.create).
💡 RabbitMQ enables “event-driven cloud operations” — essential for large-scale automation.
✅ Summary
Component | Description |
vCenter / NSX | Provides compute, storage, and networking foundation. |
vCD Cells | Stateless management nodes for UI and API. |
PostgreSQL DB | Stores metadata and configuration data. |
RabbitMQ (AMQP) | Handles asynchronous events and extensibility. |
PVDC / OrgVDC | Core resource containers linking providers and tenants. |
Allocation Models | Define how resources are committed and billed. |
API & SDKs | Enable full automation and integration. |
Load Balancing | Ensures scalability and HA for multi-cell deployments. |
========================================================================
Networking in VMware vCloud Director (vCD)
1️⃣ Integration with NSX-T and NSX-V
🔹 vCloud Director Networking Overview
vCloud Director relies on VMware NSX (either NSX-V or NSX-T) for its software-defined networking (SDN) layer. It provides tenants with logical isolation, routing, and security services on shared physical infrastructure.
🔸 NSX-V Integration (Legacy Mode)
Older vCD deployments use NSX for vSphere (NSX-V), which is tightly coupled with vCenter.
Key Components:
● VXLAN-backed logical switches
● Distributed Logical Router (DLR)
● Edge Services Gateway (ESG)
● Firewall, NAT, VPN, and Load Balancer
Characteristics:
● Works per vCenter instance.
● VXLAN networks mapped via Network Pools.
● Now deprecated — NSX-V reached EOL (End of Life).
🔸 NSX-T Integration (Modern Mode)
NSX-T Data Center is the current and future standard for vCloud Director networking. It supports both vSphere and non-vSphere environments.
Key Components:
● Overlay Segments (Geneve encapsulation)
● Tier-0 / Tier-1 Gateways
● NSX-T Edge Nodes
● Distributed Firewall (DFW)
● Load Balancing (LBaaS)
● VPN & NAT Services
vCD Integration Highlights:
● NSX-T Managers are added to vCD as Network Providers.
● vCD creates and manages Tier-1 gateways per tenant OrgVDC.
● The provider controls Tier-0 uplink configuration.
● Tenants self-manage routing, NAT, firewall, DHCP, and VPN within their Edge Gateways.
💡 Best Practice: Always use NSX-T-backed Network Pools for new vCD deployments (NSX-V is deprecated).
2️⃣ Network Types in vCloud Director
vCloud Director abstracts physical and NSX networks into three main types that define connectivity and isolation.
A. External Network
● Created by the Cloud Provider.
● Connects the vCD environment to external networks (internet or WAN).
● Backed by NSX-T Tier-0 gateway uplinks.
● Used as the uplink for tenant Edge Gateways.
Example: External-Network-Internet → maps to Tier-0 gateway in NSX-T.
B. Organization (Org) Network
● Belongs to a specific Organization VDC (OrgVDC).
● Represents the tenant’s internal network domain.
● Can be:
○ Routed – connected via Edge Gateway to external networks.
○ Isolated – internal-only, no routing.
○ Direct – bridged to external network directly (shared access).
Usage Example:
● OrgNet-Prod (Routed)
● OrgNet-Test (Isolated)
● OrgNet-Shared (Direct)
C. vApp Network
● Local to a specific vApp.
● Connects VMs inside that vApp.
● Can connect upstream to an Org Network.
● Supports transient, project-level networking.
💡 Think of vApp networks as “temporary sandbox networks” for multi-VM applications.
3️⃣ Edge Gateways: Configuration, HA, and Services
🔹 What is an Edge Gateway?
An Edge Gateway in vCD represents an NSX-T Tier-1 Gateway that provides tenant-level routing, firewalling, and NAT services.
A. Edge Gateway Functions
Function | Description |
Routing | Connects Org Networks to external networks. |
NAT | Translates private tenant IPs to public or shared addresses. |
Firewall | Controls ingress/egress between Org Networks and external links. |
VPN | Site-to-Site and SSL VPNs for tenant connectivity. |
Load Balancing | Distributes traffic across backend VMs. |
DHCP | Provides automatic IP allocation within Org Networks. |
B. High Availability (HA)
Edge Gateways can be deployed in Active/Standby mode across NSX-T Edge Nodes for redundancy.
Requirements:
● Minimum 2 NSX-T Edge Nodes.
● Shared Tier-0 uplink.
● Automatic failover of T1 services.
vCD Handling: HA configuration is exposed in the tenant portal; tenants can enable or disable it for their Edge Gateways.
C. Multi-Site Connectivity
Edges can connect to multiple external networks for:
● Internet and private WAN uplinks.
● Multi-homed routing.
● VPN peering to remote sites.
4️⃣ Tenant Networking Isolation
vCloud Director achieves complete tenant isolation using:
● NSX Segments (Geneve encapsulated)
● Tier-1 Gateways per OrgVDC
● Per-tenant firewall/NAT policies
● Unique routing tables and VRFs
Isolation Example:
Tenant | Tier-1 Gateway | Segment | Isolation Mechanism |
OrgA | T1-OrgA | SEG-A | Separate VRF |
OrgB | T1-OrgB | SEG-B | Separate VRF |
OrgC | T1-OrgC | SEG-C | Separate VRF |
Each tenant’s network traffic remains completely segregated at the NSX overlay level, even when sharing physical hosts or Edge Nodes.
5️⃣ Advanced Networking
🔹 Tier-0 / Tier-1 Gateways
Layer | Managed By | Function |
Tier-0 (T0) | Provider | External routing to WAN or internet. |
Tier-1 (T1) | Tenant | Internal routing between Org Networks and uplinks. |
● Tier-0 connects to physical routers.
● Tier-1 connects to tenant Org Networks.
● Each tenant gets its own Tier-1 Gateway linked to a shared Tier-0.
💡 This architecture ensures scalable and isolated routing per tenant.
🔹 Route Advertisement and BGP
● Tier-0 Gateways advertise routes externally via BGP (Border Gateway Protocol).
● Tier-1 Gateways advertise tenant internal networks to Tier-0.
● Dynamic routing ensures seamless connectivity between cloud tenants and external networks.
Common Setup:
● Tier-1 to Tier-0: Internal BGP (iBGP)
● Tier-0 to WAN Router: External BGP (eBGP)
Example BGP Configuration Flow:
Tenant T1 Gateway → advertise 10.10.0.0/16
Provider T0 Gateway → redistribute via BGP to Internet Router
6️⃣ Network Pools and Backing Types
Network Pools define how vCD creates tenant networks dynamically.
Backing Type | Description | Used With |
VXLAN-backed | Uses VXLAN segments (NSX-V). | NSX-V deployments. |
Geneve-backed | Uses NSX-T overlay segments. | NSX-T deployments. |
VLAN-backed | Each network assigned a VLAN ID. | Small-scale setups. |
Port Group-backed | Uses existing vCenter port groups. | Legacy use cases. |
Recommendation: Use Geneve-backed network pools with NSX-T for scalability, automation, and multi-tenancy.
7️⃣ DHCP, NAT, and Firewall Rules
🔸 DHCP
● Configurable per Org Network or via Edge Gateway.
● Supports static bindings and IP ranges.
● Managed directly by tenants through the portal or API.
🔸 NAT (Network Address Translation)
● Supports:
○ SNAT (Source NAT) → private → public.
○ DNAT (Destination NAT) → public → private.
● Common for internet access or published services.
Example:
SNAT 192.168.10.0/24 → 203.0.113.50
DNAT 203.0.113.60 → 192.168.10.20
🔸 Firewall
● Stateless or Stateful rules.
● Policy order: Top to Bottom.
● Configurable via:
○ Tenant Portal
○ API
○ Terraform or PowerCLI
Example Firewall Rule:
Allow HTTPS
Source: 192.168.10.0/24
Destination: Any
Protocol: TCP/443
Action: Allow
8️⃣ Load Balancing and VPN in vCD
🔹 Load Balancing
● Built into NSX-T Edge.
● Tenants can configure:
○ Virtual Servers
○ Pools
○ Health Monitors
○ Persistence Profiles
Example Use Case: Tenant hosts a 3-node web app cluster behind a vCD LB VIP.
VIP: 203.0.113.100:443
Pool Members: 192.168.10.11, 192.168.10.12, 192.168.10.13
Health Check: HTTPS
🔹 VPN Services
IPsec VPN: Site-to-site connectivity to on-premises networks.
SSL VPN: Remote access for end-users.
L2 VPN: Extends Layer 2 networks between on-prem and cloud.
Configured via:
● vCD Tenant UI
● Terraform or REST API
💡 All VPN encryption keys and tunnels are isolated per tenant Edge Gateway.
9️⃣ Network Automation with Terraform & PowerCLI
🔹 Terraform Automation
Provider: vmware/vcd
Common Terraform resources:
resource "vcd_network_routed_v2" "org_net" {
org = "TenantA"
vdc = "TenantA-Prod"
edge_gateway_id = data.vcd_edgegateway.tenant.id
name = "TenantA-Network"
gateway = "192.168.10.1"
prefix_length = 24
dns1 = "8.8.8.8"
}
Other supported resources:
● vcd_edgegateway_vpn
● vcd_nsxt_network_dhcp
● vcd_lb_virtual_server
● vcd_firewall_rule
🔹 PowerCLI Automation
Example PowerCLI snippet to create a routed network:
Connect-CIServer -Server vcd.cloudprovider.local -User admin -Password "password"
$Org = Get-Org "TenantA"
$VDC = Get-OrgVdc -Org $Org -Name "TenantA-Prod"
New-OrgVdcNetwork -OrgVdc $VDC -Name "TenantA-Network" -Gateway "192.168.10.1" -Netmask "255.255.255.0" -DNS1 "8.8.8.8" -StaticIPPool "192.168.10.100-192.168.10.200" -FenceMode NATRouted
🔹 CI/CD Integration
● Combine Terraform + GitLab/GitHub Actions for IaC pipelines.
● Use PowerCLI for operational scripts (bulk edge rule updates, DHCP reservations).
● Integrate Postman or Ansible for API-driven orchestration.
✅ Summary
Concept | Description |
NSX-T Integration | Modern, scalable SDN backbone for vCD. |
Network Types | External, Org, and vApp networks define tenant connectivity. |
Edge Gateways | Provide routing, firewall, NAT, VPN, and load balancing. |
Isolation | Achieved via Tier-1 gateways, NSX Segments, and VRFs. |
Advanced Networking | BGP routing and multi-tier architecture (T0/T1). |
Network Pools | Dynamic network provisioning backed by NSX overlays. |
Tenant Control | DHCP, NAT, Firewall, and VPN configurable via portal or API. |
Automation | Terraform and PowerCLI fully supported for IaC. |
Comments