Objective 4.1. - VCF Deploy and Configure:

Identify the components of a VCF Deployment:

Management Components

These are deployed as part of the Management Domain and are essential for operating and managing the VCF environment:

SDDC Manager - Centralised management plane for VCF; automates lifecycle management of the entire stack.

vCenter Server - Manages compute, storage, and networking resources for the management domain.

NSX/NSX-T - Provides software-defined networking and security for the management and workload domains.

vSAN - Software-defined storage for the management domain, aggregated from ESXi host disks.

VCF Operations - Suite for monitoring, logging, and operations management (replaces VMware Aria Operations).

VCF Automation - Automation and orchestration for workload provisioning (replaces VMware Aria Automation).

VCF Identity Broker - Enables single sign-on (SSO) and identity management across VCF components.

Workload Domain Components

Workload domains are created to host tenant workloads and can be customized based on requirements:

vCenter Server - Dedicated vCenter instance for each workload domain.

NSX-T/NSX - Software-defined networking for workload isolation, security, and connectivity.

vSAN/External Storage - Storage for workloads; can use vSAN or external storage arrays.

ESXi Hosts - Compute resources for running virtual machines and containers.

Edge Clusters - Optional; provide north-south connectivity, load balancing, and VPN services.

VCF Operations Suite

A unified operations management platform for VCF 9.0:

VCF Operations (Monitoring) - Monitoring, performance, and capacity management.

VCF Operations for Logs - Log management and analytics.

VCF Operations for Networks - Network visibility, troubleshooting, and flow monitoring.

VCF Operations Fleet Management - Manages the lifecycle of VCF Operations components.

VCF Automation

VCF Automation (formerly Aria Automation) - Self-service catalog, blueprint design, and multi-cloud automation.

VCF Orchestrator - Workflow automation and orchestration.

Optional Components

Workload Domain Components

Tanzu/Kubernetes - Enables container orchestration via vSphere with Tanzu or TKG (Tanzu Kubernetes Grid).

HCX - Hybrid Cloud Extension for workload mobility and migration between on-prem and cloud.

Cloud Director - Multi-tenant cloud management platform (if deployed).

VCF Installer

  • A virtual appliance used to deploy, upgrade, and converge VCF environments.

  • Automates the deployment of management and workload domains.

VCF Business Services Console

  • Used for licensing, entitlement management, and registration of VCF Operations.

Identity and Access Management

  • VCF Identity Broker

    • Integrates with enterprise directories (Active Directory, LDAP) for SSO.

  • Role-Based Access Control (RBAC)

    • Granular access control for VCF components.

Backup and Recovery

  • VCF Operations Backup

    • Built-in backup for VCF management components (SDDC Manager, vCenter, NSX).

  • Third-Party Integration

    • Supports integration with external backup solutions (e.g., Veeam, Commvault).

Networking

  • NSX Edge

    • Provides routing, NAT, firewall, and VPN services.

  • Transit Gateway (TGW)

    • Centralized connectivity for multi-site and multi-cloud environments.

Storage Options

  • vSAN

    • Hyperconverged storage for both management and workload domains.

  • External Storage

    • Support for SAN, NAS, and vVol-compatible arrays.

Security and Compliance

  • FIPS Compliance Mode

    • Optional FIPS 140-2 validated cryptographic modules.

  • Certificate Management

    • Custom or VMware-signed certificates for secure communication.

Identify the appropriate VMware Cloud Foundation deployment models

1. Standard Deployment (Single Region, Single Availability Zone)

Scenario:

  • Greenfield deployment for a single data center.

  • No strict high availability (HA) or disaster recovery (DR) requirements across sites.

  • Typical for small to medium enterprises or proof-of-concept (PoC) environments.

Characteristics:

  • All management and workload domains are deployed in a single availability zone (AZ).

  • Uses a single vCenter and NSX instance for the management domain.

  • Workload domains can be added as needed.

Use Cases:

  • Development/test environments.

  • Small production environments with local HA.

  • Cost-sensitive deployments.

2. Stretched Cluster Deployment (Single Region, Multiple Availability Zones)

Scenario:

  • Requires high availability within a metro region (e.g., two data centers <10ms latency).

  • Protection against site-level failures (e.g., power outage, network failure).

  • Common for enterprises needing continuous availability for critical workloads.

Characteristics:

  • Management and/or workload domains are stretched across two AZs using vSAN Stretched Cluster.

  • Active-active configuration for vSphere and NSX.

  • Requires low-latency, high-bandwidth connectivity between sites.

Use Cases:

  • Financial services or healthcare applications requiring zero downtime.

  • Environments where site-level resilience is a priority.

3. Multi-Instance Federation (Multiple Regions, Independent Instances)

Scenario:

  • Global or multi-regional deployments with independent management.

  • Each region operates as a separate VCF instance (no shared management plane).

  • Suitable for organizations with autonomous regional IT teams.

Characteristics:

  • Each region has its own SDDC Manager, vCenter, and NSX.

  • No shared services or centralized management across regions.

  • Workloads can be migrated or replicated between instances using HCX or SRM.

Use Cases:

  • Multi-national organizations with regional compliance or data sovereignty requirements.

  • Disaster recovery (DR) across geographically distant sites.

4. VCF+ (Subscription-Based, Cloud-Connected)

Scenario:

  • Organizations wanting a cloud-operated VCF experience.

  • Simplified lifecycle management with VMware-managed updates and upgrades.

  • Hybrid cloud integration with VMware Cloud on AWS, Azure VMware Solution, or Google Cloud VMware Engine.

Characteristics:

  • Subscription-based licensing (VCF+).

  • Cloud-connected for centralized management and updates.

  • Supports hybrid cloud workload mobility.

Use Cases:

  • Enterprises adopting hybrid cloud strategies.

  • Organizations wanting to reduce operational overhead for VCF lifecycle management.

5. Converged Deployment (Brownfield)

Scenario:

  • Existing vSphere/NSX environments that need to be "converged" into VCF.

  • Minimal disruption to current workloads.

  • Leverages existing infrastructure investments.

Characteristics:

  • Uses VCF Installer to "adopt" existing vSphere and NSX environments.

  • Gradual migration to VCF-managed workload domains.

Use Cases:

  • Organizations with legacy vSphere environments looking to modernize.

  • Phased adoption of VCF without a full greenfield deployment.

6. Edge Deployment (Small Footprint, Remote Locations)

Scenario:

  • Deployments in edge or remote locations (e.g., retail, branch offices).

  • Limited IT staff or infrastructure at the edge.

  • Requires centralized management from a primary VCF instance.

Characteristics:

  • Lightweight management domain.

  • Minimal hardware requirements (e.g., 2-4 nodes).

  • Managed remotely via VCF Operations.

Use Cases:

  • Retail stores, branch offices, or IoT edge locations.

  • Environments with limited on-site IT resources.

7. Disconnected/Offline Deployment

Scenario:

  • Air-gapped or highly secure environments (e.g., government, defense).

  • No internet connectivity for downloading binaries or updates.

Characteristics:

  • Uses an offline depot for binary distribution.

  • Manual updates and patching.

  • Strict security and compliance controls.

Use Cases:

  • Classified or regulated environments (e.g., military, intelligence).

  • Offshore or isolated data centers.

8. Multi-Cloud Deployment (Hybrid or Multi-Cloud)

Scenario:

  • Workloads distributed across on-premises VCF and public cloud (e.g., VMware Cloud on AWS).

  • Unified management and operations across clouds.

Characteristics:

  • VCF on-premises + VMware Cloud SDDC in public cloud.

  • HCX for workload mobility and DR.

  • Consistent networking and security policies (NSX).

Use Cases:

  • Cloud bursting or disaster recovery to public cloud.

  • Hybrid applications spanning on-prem and cloud.

VCF Deployment Models by Scenario

Qualifying Questions to Refine Your Choice

  1. What are your availability requirements?

    • Need protection against site failures? → Stretched Cluster.

    • Regional independence? → Multi-Instance Federation.

  2. Do you have existing vSphere/NSX infrastructure?

    • Yes → Converged Deployment.

    • No → Standard or Stretched Cluster.

  3. Is hybrid cloud part of your strategy?

    • Yes → VCF+ or Multi-Cloud Deployment.

  4. Are there latency or bandwidth constraints?

    • Low latency between sites → Stretched Cluster.

    • High latency or distant sites → Multi-Instance Federation.

  5. What is your operational model?

    • Centralized IT team → VCF+ or Multi-Cloud.

    • Autonomous regional teams → Multi-Instance Federation.

  6. Are there compliance or data sovereignty requirements?

    • Yes → Multi-Instance Federation or Disconnected Deployment.

Installation:

1. Planning and Preparation

  • Download and Populate the Planning and Preparation Workbook

    • Obtain the workbook from the Broadcom Technical Documentation site.

    • Fill in all required details for your environment (network, storage, hosts, etc.).

2. Prepare ESX Hosts for Deployment

  • Install Required ESX Version

    • Install the ESX version specified in the VCF 9.0 Bill of Materials on all hosts that will be part of the management domain.

3. Deploy and Configure VCF Installer

  • Deploy the VCF Installer Appliance

    • Deploy the VCF Installer OVA/OVF to a vSphere environment or directly to one of the ESX hosts.

    • Power on the appliance and configure the following during deployment:

      • Network Settings: IP address, subnet mask, gateway, DNS, NTP, and domain search path.

      • Passwords: Set strong passwords for root and local user (admin@local) as per requirements.

      • Hostname: Use the FQDN for the VCF Installer appliance.

    • After deployment, SSH into the appliance as the vcf user and verify network connectivity (ping ESX hosts, DNS, NTP).

  • Access VCF Installer Web Interface

    • Log in to the VCF Installer admin interface at https://<installer_appliance_FQDN> using admin@local and the password set during deployment.

4. Download Binaries to VCF Installer

  • Connect to an Online Depot

    • If the appliance has internet access, connect to the online depot using a download token from the Broadcom Support Portal.

    • Download all required binaries:

      • VCF Automation

      • NSX

      • VCF Operations (and its components)

      • vCenter

      • SDDC Manager

  • Offline Depot Option

    • If no internet access, use an offline depot or the VCF Download Tool to transfer binaries.

5. Start a New VCF Fleet Deployment

  • Launch the Deployment Wizard

    • In the VCF Installer interface, start a new VCF fleet deployment.

    • Follow the wizard, providing details for:

      • Management domain (network, storage, cluster)

      • ESX hosts (IPs, credentials)

      • vCenter and NSX configuration

      • Passwords and certificates

  • Review and Confirm

    • Review all settings on the “Ready to complete” page and confirm to begin deployment.

6. Deploy VCF Operations

  • Deploy VCF Operations Appliance

    • Configure the primary node (name, IP, NTP, availability mode).

    • Optionally, add data nodes before starting the cluster.

    • Start the VCF Operations cluster (takes 10–30 minutes).

  • Register VCF Operations

    • Register VCF Operations with the VCF Business Services console to license the platform.

7. Deploy Identity Broker and Configure SSO

  • Deploy VCF Identity Broker

    • Deploy in appliance mode for single sign-on (SSO) access to VCF management components.

8. Deploy Workload Domain(s)

  • Create Workload Domains

    • Use VCF Operations to create new workload domains as needed.

9. Post-Deployment Tasks

  • Stretch vSAN Clusters (if required)

    • Stretch the vSAN cluster for the management domain across availability zones if needed.

  • Configure Backups

    • Set up backup schedules for VCF management components via VCF Operations fleet management.

10. License Your VCF Fleet

  • Assign Licenses

    • Assign the primary license to the management domain vCenter instance.

11. Optional: Deploy Edge Clusters and VPCs

  • Configure Networking

    • Deploy edge clusters and configure default Virtual Private Clouds (VPCs) and Transit Gateways (TGW) as required.

12. Activate Supervisor (if using Tanzu)

  • Activate Supervisor

    • Enable the Supervisor on workload domain clusters for Kubernetes workloads.

Key Notes:

  • Ensure all passwords meet complexity requirements.

  • Verify network connectivity and DNS resolution before proceeding.

  • Deployment times vary based on environment size and resources.

Given a scenario describe the deployment of a VCF Network Gateway

1. Scenario: Greenfield VCF Deployment (Single AZ)

Goal:

Deploy a basic network gateway for a new VCF 9.0 environment in a single availability zone, providing north-south connectivity for workloads.

Topology:

  • Single workload domain with one Edge Cluster.

  • No stretched clustering or multi-site requirements.

  • Upstream connectivity to a physical router/firewall.

Deployment Steps:

A. Deploy Edge Cluster

  • Action: Deploy a 2-node Edge Cluster in the workload domain.

    • Edge VM Size: Medium (for up to 5Gbps throughput).

    • Uplink Profile: Single uplink to physical network (VLAN-backed).

    • HA Mode: Active/Standby.

B. Configure Tier-0 Gateway

  • Action: Create a T0 gateway with static routing.

    • Uplink IP: 192.168.1.1/24 (connected to physical router).

    • Default Route: 0.0.0.0/0 → 192.168.1.254.

    • Firewall: Allow outbound traffic; restrict inbound to VPN/load balancer IPs.

C. Configure Tier-1 Gateway

  • Action: Create a T1 gateway for workload segments.

    • Connected to: T0 gateway.

    • Segments: Web (172.16.1.0/24), App (172.16.2.0/24), DB (172.16.3.0/24).

    • NAT: SNAT for workloads to access the internet.

D. Optional Services

  • Load Balancer: Deploy for web traffic (192.168.1.100:443).

  • VPN: IPSec VPN for remote access (192.168.1.1 ↔ 203.0.113.1).

E. Validation

  • Test connectivity from workloads to the internet.

  • Verify NAT and firewall rules.

2. Scenario: Stretched Cluster (Metro AZs)

Goal:

Deploy a highly available gateway across two AZs in a metro region, with active/active uplinks and stretched workload segments.

Topology:

  • Stretched workload domain across AZ1 and AZ2 (<10ms latency).

  • Edge Cluster: 2 nodes in AZ1, 2 nodes in AZ2.

  • Tier-0 Gateway: Active/Active HA mode.

Deployment Steps:

A. Deploy Edge Cluster

  • Action: Deploy a 4-node Edge Cluster (2 per AZ).

    • Uplink Profiles: Two uplinks (one per AZ) for redundancy.

    • Teaming Policy: LACP for uplink aggregation.

B. Configure Tier-0 Gateway

  • Action: Create a T0 gateway in Active/Active mode.

    • Uplink IPs: 192.168.1.1/24 (AZ1), 192.168.2.1/24 (AZ2).

    • BGP: Peering with upstream routers in both AZs.

    • ECMP: Enable for load balancing across uplinks.

C. Configure Tier-1 Gateway

  • Action: Create a T1 gateway with stretched segments.

    • Segments: Stretch Web, App, and DB segments across AZs.

    • Route Advertisement: Advertise segments to both AZs.

D. Configure NAT and Firewall

  • Action: Distribute NAT rules across both AZs.

    • Firewall: Synchronize rules between AZs.

E. Optional Services

  • Load Balancer: Global load balancer with VIPs in both AZs.

  • VPN: Terminate VPN in both AZs for redundancy.

F. Validation

  • Failover testing: Shut down AZ1 uplink and verify traffic fails over to AZ2.

  • Test BGP convergence time.

3. Scenario: Multi-Site Federation (Independent Regions)

Goal:

Deploy independent gateways in two regions, with no shared management plane but connected via HCX or VPN.

Topology:

  • Region A: T0-A, T1-A, Edge Cluster A.

  • Region B: T0-B, T1-B, Edge Cluster B.

  • Connectivity: Site-to-site VPN or HCX between regions.

Deployment Steps:

A. Deploy Edge Clusters

  • Action: Deploy separate Edge Clusters in each region.

    • Region A: 2-node cluster in Site-A.

    • Region B: 2-node cluster in Site-B.

B. Configure Tier-0 Gateways

  • Action: Create T0 gateways in each region.

    • Region A T0: 192.168.1.1/24, static route to local router.

    • Region B T0: 192.168.2.1/24, static route to local router.

C. Configure Tier-1 Gateways

  • Action: Create T1 gateways for local workloads.

    • Segments: Non-overlapping IP ranges (e.g., 172.16.0.0/16 in Region A, 172.17.0.0/16 in Region B).

D. Connect Sites

  • Action: Set up IPSec VPN or HCX between T0 gateways.

    • VPN: 192.168.1.1 ↔ 192.168.2.1.

    • HCX: Deploy HCX appliances for workload mobility.

E. Validation

  • Test cross-site connectivity (e.g., 172.16.1.10 ↔ 172.17.1.10).

  • Verify failover for DR scenarios.

4. Scenario: Hybrid Cloud (VCF + VMware Cloud on AWS)

Goal:

Extend on-premises VCF networking to VMware Cloud on AWS (VMC) for hybrid workloads.

Topology:

  • On-Prem: T0-OnPrem, T1-OnPrem, Edge Cluster.

  • VMC: T0-VMC (managed by VMware).

  • Connectivity: HCX or VPN between on-prem and VMC.

Deployment Steps:

A. Deploy On-Prem Edge Cluster

  • Action: Deploy a 2-node Edge Cluster on-prem.

    • Uplink: Connect to physical network and VMC via Direct Connect/VPN.

B. Configure Tier-0 Gateway

  • Action: Create T0-OnPrem with BGP to physical router.

    • Uplink IP: 192.168.1.1/24.

    • BGP: Peer with VMC SDDC (10.0.0.1).

C. Configure HCX

  • Action: Deploy HCX appliances on-prem and in VMC.

    • Service Mesh: Stretch L2 networks or use HCX mobility.

D. Configure Tier-1 Gateway

  • Action: Create T1-OnPrem for local segments.

    • Segments: 172.16.1.0/24 (on-prem), 172.17.1.0/24 (VMC).

E. Optional Services

  • Load Balancer: Deploy on-prem and in VMC for redundancy.

  • Firewall: Synchronize rules between on-prem and cloud.

F. Validation

  • Migrate a VM from on-prem to VMC using HCX.

  • Test connectivity between on-prem and cloud workloads.

5. Scenario: Edge/Remote Office

Goal:

Deploy a lightweight gateway for a remote office or edge location, managed centrally from a primary VCF instance.

Topology:

  • Edge Site: 2-node Edge Cluster (small form factor).

  • Central Site: Full VCF deployment with SDDC Manager.

  • Connectivity: VPN or SD-WAN to central site.

Deployment Steps:

A. Deploy Edge Cluster

  • Action: Deploy a 2-node small Edge Cluster at the edge site.

    • Uplink: Single uplink to local ISP.

B. Configure Tier-0 Gateway

  • Action: Create T0-Edge with static default route.

    • Uplink IP: 203.0.113.2/30.

    • VPN: IPSec to central site (203.0.113.1).

C. Configure Tier-1 Gateway

  • Action: Create T1-Edge for local segments.

    • Segments: 192.168.100.0/24 (edge site).

D. Central Management

  • Action: Use VCF Operations to monitor and manage the edge gateway.

E. Validation

  • Test VPN connectivity to central site.

  • Verify edge workloads can access central resources.

6. Scenario: Disconnected/Air-Gapped Environment

Goal:

Deploy a fully offline gateway with no internet connectivity, using manual updates.

Topology:

  • Isolated VCF instance with no external access.

  • Edge Cluster: 2 nodes, no BGP/VPN to external networks.

Deployment Steps:

A. Deploy Edge Cluster

  • Action: Deploy Edge VMs using offline binaries.

    • Uplink: Connect to isolated physical network.

B. Configure Tier-0 Gateway

  • Action: Create T0 with static routes to internal routers.

    • Uplink IP: 10.0.0.1/24.

    • Default Route: 0.0.0.0/0 → 10.0.0.254 (internal router).

C. Configure Tier-1 Gateway

  • Action: Create T1 for internal segments.

    • Segments: 172.18.0.0/16 (internal only).

D. Security

  • Action: Disable NAT/VPN; restrict firewall to internal traffic.

E. Validation

  • Test internal connectivity (e.g., 172.18.1.10 ↔ 172.18.2.10).

  • Verify no external leaks.

Key Considerations for All Scenarios:

  1. High Availability:

    • Always deploy at least 2 Edge VMs.

    • Use Active/Active for stretched clusters; Active/Standby for simplicity.

  2. Performance:

    • Choose Edge VM size based on throughput (Small: 1Gbps, Medium: 5Gbps, Large: 10Gbps+).

  3. Security:

    • Enable firewall logging and intrusion detection.

    • Restrict management access to T0/T1 gateways.

  4. Scalability:

    • Add more T1 gateways for tenant isolation.

    • Scale Edge Clusters horizontally for higher throughput.

  5. Automation:

    • Use VCF APIs or Terraform to automate gateway deployment.

Describe the deployment of VCF Networking

1. Scenario: Greenfield Single-Site VCF Deployment

Goal:

Deploy a fully isolated VCF networking stack for a new data center with a single availability zone, supporting basic north-south and east-west traffic.

Topology:

  • Single workload domain with one Edge Cluster.

  • No stretched networking or multi-site requirements.

  • Physical connectivity to upstream routers/firewalls.

Components:

  • NSX Manager Cluster (3 nodes)

  • Edge Cluster (2 nodes)

  • Tier-0 Gateway (1, Active/Standby)

  • Tier-1 Gateway (1 per workload segment)

  • Overlay Transport Zone (for workloads)

  • VLAN Transport Zone (for uplinks)

Deployment Steps:

A. Deploy NSX Manager Cluster

  1. Action: Deploy 3 NSX Manager VMs in the management domain.

    • IPs: 192.168.100.10-12/24

    • Cluster VIP: 192.168.100.100

    • Join to VCF SDDC Manager.

  2. Action: Configure NSX Manager HA and backup.

B. Prepare Host Transport Nodes

  1. Action: Create an Uplink Profile for ESXi hosts.

    • Teaming Policy: Failover (Active/Standby).

    • MTU: 1600 (or match physical network).

  2. Action: Configure Transport Zones:

    • Overlay TZ: For workload traffic (VXLAN).

    • VLAN TZ: For Edge uplinks.

  3. Action: Add ESXi hosts to the Overlay Transport Zone.

C. Deploy Edge Cluster

  1. Action: Deploy a 2-node Edge Cluster.

    • Form Factor: Medium.

    • Uplink Profile: Connect to physical VLAN (e.g., VLAN 100).

    • Transport Zone: Overlay + VLAN.

D. Configure Tier-0 Gateway

  1. Action: Create T0 Gateway (T0-GW-01).

    • HA Mode: Active/Standby.

    • Uplink IPs: 192.168.1.1/24 (connected to physical router).

    • Routing: Static default route (0.0.0.0/0 → 192.168.1.254).

E. Configure Tier-1 Gateway and Segments

  1. Action: Create T1 Gateway (T1-GW-01).

    • Connected to: T0-GW-01.

    • Segments:

      • Web: 172.16.1.0/24

      • App: 172.16.2.0/24

      • DB: 172.16.3.0/24

  2. Action: Enable DHCP and NAT for workloads.

F. Configure Security

  1. Action: Create Distributed Firewall rules.

    • Allow Web → App → DB traffic.

    • Restrict external access to Web segment (port 443).

G. Optional: Load Balancer

  1. Action: Deploy NSX Advanced Load Balancer (ALB).

    • VIP: 192.168.1.100:443

    • Pool: 172.16.1.10-20.

H. Validation

  • Test workload connectivity (e.g., 172.16.1.10 → 172.16.2.10).

  • Verify internet access via NAT.

2. Scenario: Stretched Cluster (Metro AZs)

Goal:

Deploy highly available networking across two AZs in a metro region, with stretched segments and active/active uplinks.

Topology:

  • Stretched workload domain across AZ1 and AZ2 (<10ms latency).

  • Edge Cluster: 4 nodes (2 per AZ).

  • Tier-0 Gateway: Active/Active with BGP.

Components:

  • NSX Manager Cluster (3 nodes, AZ1)

  • Edge Cluster (4 nodes, 2 per AZ)

  • Tier-0 Gateway (Active/Active, ECMP)

  • Stretched Overlay Transport Zone

Deployment Steps:

A. Deploy NSX Manager Cluster

  1. Action: Deploy NSX Managers in AZ1.

    • VIP: 192.168.100.100.

B. Prepare Host Transport Nodes

  1. Action: Configure Transport Zones for both AZs.

    • Overlay TZ: Stretched across AZ1/AZ2.

    • VLAN TZ: Local to each AZ.

  2. Action: Add ESXi hosts from both AZs to the Overlay TZ.

C. Deploy Edge Cluster

  1. Action: Deploy 4-node Edge Cluster (2 in AZ1, 2 in AZ2).

    • Uplink Profiles:

      • AZ1-Uplink: VLAN 100

      • AZ2-Uplink: VLAN 200

D. Configure Tier-0 Gateway

  1. Action: Create T0 Gateway (T0-GW-Stretched).

    • HA Mode: Active/Active.

    • Uplinks:

      • AZ1: 192.168.1.1/24

      • AZ2: 192.168.2.1/24

    • BGP: Peer with upstream routers in both AZs.

    • ECMP: Enable for load balancing.

E. Configure Tier-1 Gateway and Stretched Segments

  1. Action: Create T1 Gateway (T1-GW-Stretched).

    • Segments:

      • Web: 172.16.1.0/24 (stretched)

      • App: 172.16.2.0/24 (stretched)

F. Configure BGP and Firewall

  1. Action: Advertise stretched segments via BGP.

  2. Action: Synchronize firewall rules between AZs.

G. Optional: VPN and Load Balancer

  1. Action: Deploy IPSec VPN terminated in both AZs.

  2. Action: Configure Global Load Balancer with VIPs in both AZs.

H. Validation

  • Failover Test: Shut down AZ1 uplink; verify traffic fails over to AZ2.

  • Test BGP convergence (<5s).

3. Scenario: Multi-Site Federation (Independent Regions)

Goal:

Deploy independent VCF networking stacks in two regions, connected via IPSec VPN or HCX.

Topology:

  • Region A: NSX-A, T0-A, Edge-A

  • Region B: NSX-B, T0-B, Edge-B

  • Connectivity: Site-to-site VPN or HCX.

Components:

  • NSX Manager Cluster per region (3 nodes each)

  • Edge Cluster per region (2 nodes each)

  • Tier-0 Gateways (1 per region)

  • HCX or IPSec VPN for cross-site connectivity

Deployment Steps:

A. Deploy NSX Managers

  1. Action: Deploy NSX-A in Region A and NSX-B in Region B.

B. Configure Local Networking

  1. Action: In Region A:

    • Deploy Edge-A (2 nodes).

    • Create T0-A (192.168.1.1/24).

    • Create T1-A and local segments (172.16.0.0/16).

  2. Action: Repeat for Region B (172.17.0.0/16).

C. Connect Sites

  1. Action: Set up IPSec VPN between T0-A and T0-B.

    • Local IP: 192.168.1.1

    • Peer IP: 192.168.2.1

    • Pre-Shared Key: SecureKey123!

  2. Action: Alternatively, deploy HCX for L2 extension.

D. Configure Firewall and Routing

  1. Action: Allow cross-site traffic (e.g., 172.16.1.0/24 ↔ 172.17.1.0/24).

E. Validation

  • Test VM migration between regions (if using HCX).

  • Verify VPN connectivity.

4. Scenario: Hybrid Cloud (VCF + VMware Cloud on AWS)

Goal:

Extend on-premises VCF networking to VMware Cloud on AWS (VMC) for hybrid workloads.

Topology:

  • On-Prem: NSX-OnPrem, T0-OnPrem, Edge-OnPrem

  • VMC: NSX-VMC (managed by VMware)

  • Connectivity: HCX or VPN.

Components:

  • NSX Manager Cluster (on-prem)

  • Edge Cluster (on-prem, 2 nodes)

  • HCX Appliances (on-prem + VMC)

  • Tier-0 Gateway (on-prem, BGP to VMC)

Deployment Steps:

A. Deploy On-Prem NSX

  1. Action: Deploy NSX Manager Cluster and Edge Cluster.

  2. Action: Create T0-OnPrem with BGP to physical router.

B. Configure HCX

  1. Action: Deploy HCX On-Prem and HCX VMC.

  2. Action: Create Service Mesh for L2 extension or mobility.

C. Configure Tier-0 and Tier-1

  1. Action: On T0-OnPrem, add BGP peer to VMC SDDC (10.0.0.1).

  2. Action: Create T1-OnPrem for local segments (172.16.1.0/24).

D. Test Connectivity

  1. Action: Migrate a VM from on-prem to VMC using HCX.

  2. Action: Verify cross-cloud connectivity.

5. Scenario: Edge/Remote Office

Goal:

Deploy lightweight VCF networking for a remote office, managed centrally.

Topology:

  • Edge Site: 2-node Edge Cluster (small)

  • Central Site: Full VCF with SDDC Manager

  • Connectivity: VPN or SD-WAN.

Components:

  • NSX Manager (central)

  • Edge Cluster (remote, 2 small nodes)

  • Tier-0 Gateway (VPN to central site)

Deployment Steps:

A. Deploy Edge Cluster

  1. Action: Deploy 2-node Edge Cluster at the edge.

    • Uplink: Single ISP connection.

B. Configure Tier-0 Gateway

  1. Action: Create T0-Edge.

    • Uplink IP: 203.0.113.2/30.

    • VPN: IPSec to central site (203.0.113.1).

C. Configure Local Segments

  1. Action: Create T1-Edge and segment (192.168.100.0/24).

D. Central Management

  1. Action: Monitor edge site via VCF Operations.

E. Validation

  • Test VPN connectivity to central site.

  • Verify edge workloads can access central resources.

6. Scenario: Disconnected/Air-Gapped Environment

Goal:

Deploy fully offline VCF networking with no external connectivity.

Topology:

  • Isolated VCF instance

  • Edge Cluster: 2 nodes (no BGP/VPN)

  • Tier-0 Gateway: Static routing only

Components:

  • NSX Manager Cluster (3 nodes)

  • Edge Cluster (2 nodes)

  • Tier-0 Gateway (internal routing only)

Deployment Steps:

A. Deploy NSX Manager

  1. Action: Deploy using offline binaries.

B. Configure Transport Zones

  1. Action: Create Overlay TZ for workloads.

C. Deploy Edge Cluster

  1. Action: Deploy 2-node Edge Cluster with internal uplinks.

D. Configure Tier-0 and Tier-1

  1. Action: Create T0-GW with static route to internal router.

  2. Action: Create T1-GW and segments (172.18.0.0/16).

E. Security

  1. Action: Disable NAT/VPN; restrict firewall to internal traffic.

F. Validation

  • Test internal connectivity (e.g., 172.18.1.10 ↔ 172.18.2.10).

  • Verify no external leaks.

Key Considerations for All Scenarios:

  1. High Availability:

    • NSX Manager: Always deploy 3 nodes.

    • Edge Cluster: Minimum 2 nodes (4 for stretched).

  2. Performance:

    • Edge VM Size: Match throughput requirements (Small: 1Gbps, Medium: 5Gbps, Large: 10Gbps+).

  3. Security:

    • Enable Distributed Firewall and IDPS.

    • Restrict management access to NSX/T0/T1.

  4. Scalability:

    • Add T1 Gateways for tenant isolation.

    • Scale Edge Clusters for higher throughput.

  5. Automation:

    • Use VCF APIs, Terraform, or PowerShell for repeatable deployments.

Given a Scenario describe the deployment of a Workload Domain

1. Scenario: Greenfield Single-Site Workload Domain

Goal:

Deploy a new Workload Domain in a single-site VCF 9.0 environment to host production workloads (e.g., VMs, Kubernetes, databases).

Topology:

  • Single vCenter for the WLD.

  • NSX-T/NSX for networking and security.

  • vSAN or external storage (e.g., SAN/NAS).

  • 4+ ESXi hosts (scaled as needed).

Components:

  • vCenter Server Appliance (VCSA)

  • NSX Manager Cluster (shared or dedicated)

  • Compute Cluster (4+ ESXi hosts)

  • Distributed Switch (VDS) for networking

  • Storage: vSAN or external (e.g., Dell EMC, NetApp)

  • Tier-1 Gateway for workload segmentation

Deployment Steps:

A. Prerequisites

  1. VCF Installer: Ensure binaries for vCenter, ESXi, and NSX are downloaded.

  2. Networking:

    • VLANs for management, vMotion, vSAN, and workload traffic.

    • IP blocks for ESXi hosts, vCenter, and NSX components.

  3. Storage:

    • For vSAN: Local disks in ESXi hosts.

    • For external storage: LUNs/volumes presented to hosts.

B. Deploy Workload Domain via VCF Installer

  1. Log in to the VCF Installer UI (https://<VCF-Installer-FQDN>).

  2. Navigate to Inventory > Workload Domains and click Add Workload Domain.

  3. Specify Workload Domain Details:

    • Name: WLD-Production

    • Type: VI Workload Domain (for vSphere) or VxRail (if using VxRail).

    • vCenter Specifications:

      • FQDN: wld-vcenter.example.com

      • IP Address: 192.168.100.10/24

      • SSO Domain: vsphere.local (or custom)

  4. Select Compute Resources:

    • Cluster Name: WLD-Prod-Cluster

    • ESXi Hosts: Add 4+ hosts (FQDN/IP, credentials).

    • Network: Select management network for hosts.

  5. Configure Storage:

    • vSAN: Enable and select disk groups.

    • External Storage: Select datastore(s).

  6. Configure NSX:

    • NSX Manager: Use existing or deploy new.

    • Edge Cluster: Select existing or deploy new (2+ nodes).

    • Tier-0 Gateway: Connect to existing (e.g., T0-GW-01).

  7. Networking:

    • Distributed Switch: Create new or use existing.

    • Uplinks: Configure vmnics for management/vMotion/vSAN.

  8. Review and Deploy:

    • Validate settings and start deployment.

    • Monitor progress in the Tasks tab.

C. Post-Deployment Configuration

  1. Create Tier-1 Gateway:

    • Log in to NSX Manager.

    • Navigate to Networking > Tier-1 Gateways and create T1-WLD-Prod.

    • Connect to T0-GW-01 (from management domain).

  2. Create Segments:

    • Web Tier: 172.16.1.0/24

    • App Tier: 172.16.2.0/24

    • DB Tier: 172.16.3.0/24

  3. Configure Firewall Rules:

    • Allow traffic between tiers (e.g., Web → App → DB).

  4. Deploy Workloads:

    • Create VMs or Kubernetes clusters (if using Tanzu).

D. Validation

  • Verify ESXi hosts are connected to vCenter.

  • Test storage connectivity (vSAN or external).

  • Deploy a test VM and validate network connectivity.

2. Scenario: Stretched Workload Domain (Metro AZs)

Goal:

Deploy a highly available Workload Domain stretched across two availability zones (AZs) in a metro region (<10ms latency).

Topology:

  • vCenter: Single instance (active in AZ1, standby in AZ2).

  • Compute Cluster: Hosts in AZ1 and AZ2.

  • Storage: vSAN Stretched Cluster or external metro storage.

  • NSX: Stretched Tier-1 Gateway and segments.

Components:

  • vCenter Server (single instance)

  • NSX Manager Cluster (3 nodes in AZ1)

  • Compute Cluster: 4+ hosts per AZ

  • vSAN Stretched Cluster or external storage with replication

  • Tier-0 Gateway: Active/Active

Deployment Steps:

A. Prerequisites

  1. Networking:

    • Stretched VLANs for management/vMotion.

    • vSAN Stretched Cluster: Witness host in a third site (or cloud).

  2. Storage:

    • vSAN: Configure fault domains for AZ1 and AZ2.

    • External Storage: Metro storage replication (e.g., SRDF, SnapMirror).

B. Deploy Workload Domain via VCF Installer

  1. In VCF Installer, click Add Workload Domain.

  2. Specify Details:

    • Name: WLD-Stretched-Prod

    • vCenter FQDN: wld-stretched-vc.example.com

  3. Add Hosts:

    • AZ1 Hosts: esxi-az1-01 to esxi-az1-04

    • AZ2 Hosts: esxi-az2-01 to esxi-az2-04

  4. Configure vSAN Stretched Cluster:

    • Fault Domains: AZ1, AZ2

    • Witness Host: esxi-witness-01 (in a third site or cloud).

  5. Configure NSX:

    • Edge Cluster: 4 nodes (2 per AZ).

    • Tier-0 Gateway: T0-Stretched (Active/Active).

  6. Networking:

    • Stretched Segments: 172.16.1.0/24 (Web), 172.16.2.0/24 (App).

  7. Review and Deploy.

C. Post-Deployment Configuration

  1. Configure vSAN Stretched Cluster:

    • Set site affinity and witness host.

  2. Test Failover:

    • Simulate AZ1 failure; verify VMs restart in AZ2.

  3. Monitor vSAN Health:

    • Check vSAN Skyline Health for synchronization status.

D. Validation

  • Deploy a test VM in AZ1 and migrate to AZ2.

  • Verify storage synchronization and network failover.

3. Scenario: Multi-Site Workload Domain (Federation)

Goal:

Deploy independent Workload Domains in two regions, connected via HCX or VPN for workload mobility.

Topology:

  • Region A: WLD-A (vCenter-A, NSX-A, local storage)

  • Region B: WLD-B (vCenter-B, NSX-B, local storage)

  • Connectivity: HCX or IPSec VPN

Components:

  • vCenter Server per region

  • NSX Manager per region

  • Compute Clusters: Local to each region

  • HCX Appliances for migration

Deployment Steps:

A. Deploy WLD-A (Region A)

  1. In VCF Installer, deploy WLD-A:

    • vCenter: wld-a-vc.example.com

    • NSX: NSX-A

    • Storage: Local vSAN or external.

  2. Repeat for WLD-B (Region B).

B. Configure Cross-Site Connectivity

  1. Deploy HCX:

    • Install HCX Manager in both WLDs.

    • Create a Service Mesh between WLD-A and WLD-B.

  2. Configure Networking:

    • Tier-0 Gateways: T0-A and T0-B.

    • VPN: IPSec between T0-A and T0-B (if not using HCX).

C. Migrate Workloads

  1. Use HCX to migrate VMs between WLD-A and WLD-B.

  2. Test Replication:

    • Enable HCX Replication for critical VMs.

D. Validation

  • Migrate a test VM from WLD-A to WLD-B.

  • Verify network connectivity between regions.

4. Scenario: Hybrid Cloud Workload Domain (VCF + VMware Cloud on AWS)

Goal:

Extend on-premises VCF to VMware Cloud on AWS (VMC) for hybrid workloads.

Topology:

  • On-Prem WLD: Connected to VMC via HCX.

  • VMC SDDC: Managed by VMware.

  • Networking: L2 extension or routed connectivity.

Components:

  • On-Prem WLD: vCenter, NSX, vSAN/external storage

  • VMC SDDC: Pre-deployed by VMware

  • HCX: For workload mobility

Deployment Steps:

A. Deploy On-Prem WLD

  1. Deploy WLD-Hybrid via VCF Installer:

    • vCenter: wld-hybrid-vc.example.com

    • NSX: Configured for HCX.

  2. Configure HCX:

    • Deploy HCX On-Prem and HCX VMC.

    • Create a Service Mesh between on-prem and VMC.

B. Connect to VMC

  1. Networking:

    • Tier-0 Gateway: Peer with VMC SDDC (10.0.0.1).

    • Segments: Extend 172.16.1.0/24 to VMC.

  2. Migrate Workloads:

    • Use HCX vMotion to move VMs to VMC.

C. Validation

  • Deploy a VM on-prem and migrate to VMC.

  • Test cross-cloud connectivity.

5. Scenario: Edge/Remote Office Workload Domain

Goal:

Deploy a lightweight Workload Domain for a remote office, managed centrally.

Topology:

  • Edge WLD: 2-3 ESXi hosts.

  • vCenter: Managed from central site (or local).

  • Storage: Local vSAN or small SAN.

  • Connectivity: VPN to central site.

Components:

  • vCenter: Shared with central site or local.

  • NSX Edge: Small form factor (2 nodes).

  • Tier-0 Gateway: VPN to central site.

Deployment Steps:

A. Deploy Edge WLD

  1. In VCF Installer, deploy WLD-Edge:

    • vCenter: Use existing or deploy new (small).

    • Hosts: 2-3 ESXi hosts (esxi-edge-01, esxi-edge-02).

    • Storage: Local vSAN.

  2. Configure Networking:

    • Tier-0 Gateway: T0-Edge with VPN to central site.

    • Segments: 192.168.100.0/24.

B. Central Management

  1. Monitor via VCF Operations.

  2. Backup: Configure VCF backups to central site.

C. Validation

  • Deploy a local VM and test VPN connectivity.

  • Verify central management (e.g., monitoring, backups).

6. Scenario: Disconnected/Air-Gapped Workload Domain

Goal:

Deploy a fully isolated Workload Domain with no external connectivity.

Topology:

  • Isolated vCenter/NSX.

  • No internet access.

  • Local storage only.

Components:

  • vCenter: Offline deployment.

  • NSX: Offline binaries.

  • Storage: Local vSAN or isolated SAN.

Deployment Steps:

A. Deploy Offline WLD

  1. Upload Binaries: Use VCF offline depot for vCenter, ESXi, NSX.

  2. Deploy via VCF Installer:

    • vCenter: wld-airgap-vc.example.com

    • NSX: Offline mode.

  3. Configure Networking:

    • Tier-0 Gateway: Internal routing only.

    • Firewall: Block all external traffic.

B. Validation

  • Deploy a test VM and verify internal connectivity.

  • Ensure no external network leaks.

Given a Scenario, configure Workload Domain storage

1. Scenario: Greenfield Workload Domain with vSAN

Goal:

Configure vSAN storage for a new Workload Domain in a single-site VCF 9.0 environment, optimized for performance and capacity.

Topology:

  • 4+ ESXi hosts with local SSDs/HDDs.

  • vSAN Datastore for all workloads.

  • All-Flash or Hybrid configuration.

Prerequisites:

  • ESXi hosts with vSAN-compatible SSDs (cache tier) and SSDs/HDDs (capacity tier).

  • Network: 10Gbps+ NICs for vSAN traffic (dedicated VLAN recommended).

  • VCF Installer access and hosts added to the Workload Domain.

Configuration Steps:

A. Prepare Hosts for vSAN

  1. Verify Hardware Compatibility:

    • Check VMware vSAN HCL.

    • Ensure SSDs for cache tier (e.g., 1-2 SSDs per host) and SSDs/HDDs for capacity tier.

  2. Network Configuration:

    • Create a vSAN VMkernel port on each host:

      • VLAN: Dedicated (e.g., VLAN 200).

      • MTU: 9000 (jumbo frames).

      • Teaming Policy: Active/Active or LACP.

B. Configure vSAN During WLD Deployment

  1. In VCF Installer:

    • Navigate to Workload Domains > Add Workload Domain.

    • Under Storage, select vSAN.

    • vSAN Configuration:

      • License: Assign vSAN license.

      • Fault Domains: Enable if using rack awareness.

      • Deduplication/Compression: Enable for all-flash.

      • Erasure Coding: RAID-5/6 for capacity efficiency (optional).

  2. Disk Group Configuration:

    • Cache Tier: 1 SSD per host (e.g., 800GB).

    • Capacity Tier: 1+ SSDs/HDDs per host (e.g., 4x 3.84TB SSDs).

    • Disk Group Count: 1 per host (or more for performance).

  3. Deploy Workload Domain:

    • VCF will automatically create a vSAN datastore and enable vSAN on the cluster.

C. Post-Deployment Validation

  1. Log in to vCenter for the WLD.

  2. Navigate to Cluster > Configure > vSAN > General.

    • Verify vSAN is enabled and all hosts are contributing storage.

  3. Check Disk Groups under vSAN > Disk Management.

  4. Run Health Checks:

    • Go to Monitor > vSAN > Health and remediate any issues.

D. Storage Policy Configuration

  1. Create a vSAN Storage Policy:

    • Navigate to Policies and Profiles > VM Storage Policies.

    • Click Create and select vSAN Default Storage Policy.

    • Rules:

      • Failure Tolerance: RAID-1 (Mirroring) or RAID-5/6 (Erasure Coding).

      • Stripe Width: 2+ for performance.

    • Name: vSAN-Gold (example).

  2. Apply Policy to VMs:

    • During VM deployment, select the vSAN-Gold policy.

E. Optional: Enable vSAN File Services

  1. Action: Deploy vSAN File Service for NFS shares.

    • Navigate to vSAN > File Service and follow the wizard.

2. Scenario: Workload Domain with External SAN (FC/iSCSI)

Goal:

Configure external SAN storage (e.g., Dell EMC, NetApp, HPE) for a Workload Domain, using FC or iSCSI.

Topology:

  • SAN Array: FC or iSCSI (e.g., Dell EMC PowerStore, NetApp AFF).

  • ESXi Hosts: FC HBAs or iSCSI initiators.

  • Datastores: VMFS or NFS.

Prerequisites:

  • SAN LUNs pre-configured and zoned/masked to ESXi hosts.

  • FC Switches (for FC) or iSCSI network (10Gbps+, dedicated VLAN).

Configuration Steps:

A. Configure Host Storage Access

  1. For FC:

    • Zone SAN ports to ESXi HBAs.

    • Rescan HBAs in vCenter (Hosts > Configure > Storage Adapters).

  2. For iSCSI:

    • Configure iSCSI VMkernel ports on each host:

      • VLAN: Dedicated (e.g., VLAN 300).

      • MTU: 9000.

    • Add iSCSI targets (SAN array IPs) to the software iSCSI adapter.

B. Add Storage During WLD Deployment

  1. In VCF Installer:

    • Under Storage, select External Storage.

    • Storage Type: VMFS (block) or NFS (file).

    • Datastore Details:

      • Name: WLD-Prod-DS01

      • Capacity: Specify size (e.g., 10TB).

      • Protocol: FC or iSCSI.

      • LUN/NFS Share: Provide SAN LUN or NFS export details.

  2. Deploy Workload Domain:

    • VCF will mount the datastore to all hosts in the cluster.

C. Post-Deployment Validation

  1. Log in to vCenter for the WLD.

  2. Navigate to Datastores and verify the new datastore is accessible.

  3. Multipathing:

    • Check Hosts > Configure > Storage Adapters > Paths.

    • Ensure active/optimized paths for all LUNs.

D. Storage Policy Configuration

  1. Create a Storage Policy for SAN:

    • Rules: Tag datastore with capability:storageType=SAN.

    • Name: SAN-Gold.

  2. Apply Policy to VMs.

3. Scenario: Stretched Workload Domain with vSAN Stretched Cluster

Goal:

Configure vSAN Stretched Cluster for a Workload Domain spanning two availability zones (AZs), with a witness host for quorum.

Topology:

  • AZ1: 4+ ESXi hosts.

  • AZ2: 4+ ESXi hosts.

  • Witness Host: 1 ESXi host in a third location (or cloud).

  • Network: Low-latency (<10ms) inter-AZ link.

Prerequisites:

  • vSAN HCL-compliant hosts in both AZs.

  • Witness Appliance (deployed on a tiny host or in the cloud).

Configuration Steps:

A. Prepare Hosts and Network

  1. Fault Domains:

    • Group hosts by AZ in vCenter (Cluster > Configure > vSAN > Fault Domains).

  2. Witness Host:

    • Deploy a tiny ESXi host or use vSAN Witness Appliance in a third site.

B. Configure vSAN Stretched Cluster During WLD Deployment

  1. In VCF Installer:

    • Select vSAN and enable Stretched Cluster.

    • Fault Domains: Assign AZ1 and AZ2.

    • Witness Host: Specify FQDN/IP of the witness.

    • Site Affinity: Enable to prefer local reads/writes.

  2. Deploy Workload Domain.

C. Post-Deployment Validation

  1. Log in to vCenter for the WLD.

  2. Navigate to vSAN > Fault Domains and verify AZ1/AZ2 and witness.

  3. Test Failover:

    • Simulate AZ1 failure; verify VMs remain accessible in AZ2.

D. Storage Policy for Stretched vSAN

  1. Create a Policy:

    • Rules:

      • Site Disaster Tolerance: RAID-1 (Mirroring) across AZs.

      • Witness: Automatic.

    • Name: vSAN-Stretched-Gold.

4. Scenario: Multi-Site Workload Domain with External Storage Replication

Goal:

Configure external storage replication (e.g., SRDF, SnapMirror) for a Workload Domain across two sites, with array-based replication.

Topology:

  • Site A: Primary SAN array (e.g., Dell EMC SRDF).

  • Site B: Secondary SAN array.

  • Workload Domain: One per site, with replicated LUNs.

Prerequisites:

  • SAN replication configured between arrays.

  • Consistent LUN IDs across sites.

Configuration Steps:

A. Configure SAN Replication

  1. Action: Set up synchronous or asynchronous replication on the SAN array.

    • Example: Dell EMC SRDF/S (synchronous) or SRDF/A (asynchronous).

B. Add Storage During WLD Deployment

  1. In VCF Installer (Site A):

    • Select External Storage and provide primary LUN details.

  2. Repeat for Site B with secondary LUNs.

C. Post-Deployment: Configure SRM (Optional)

  1. Deploy Site Recovery Manager (SRM):

    • Pair Site A and Site B vCenters.

    • Configure protection groups and recovery plans.

D. Storage Policy for Replicated Storage

  1. Create a Policy:

    • Rules: Tag datastores with capability:replication=SRDF.

    • Name: SAN-Replicated-Gold.

5. Scenario: Hybrid Cloud Workload Domain with vSAN and VMware Cloud on AWS

Goal:

Extend on-premises vSAN to VMware Cloud on AWS (VMC) for hybrid storage.

Topology:

  • On-Prem: vSAN Workload Domain.

  • Cloud: VMC SDDC with vSAN.

  • Connectivity: HCX or vSAN Stretched Cluster (if <10ms latency).

Prerequisites:

  • HCX deployed for workload mobility.

  • VMC SDDC provisioned.

Configuration Steps:

A. Configure On-Prem vSAN

  1. Follow "Greenfield with vSAN" steps for on-prem WLD.

B. Configure VMC vSAN

  1. Action: VMC vSAN is pre-configured by VMware.

    • Verify datastore in VMC vCenter.

C. Enable HCX Storage Mobility

  1. Action: In HCX, configure Replication Assisted vMotion (RAV) or Bulk Migration.

  2. Migrate VMs:

    • Select VMs and migrate storage to VMC vSAN.

D. Storage Policy for Hybrid Cloud

  1. Create a Policy:

    • Rules: Use tag:cloud=vmc for VMC datastore.

    • Name: Hybrid-vSAN.

6. Scenario: Edge Workload Domain with Local Storage

Goal:

Configure local storage (e.g., vSAN or direct-attached) for a remote/edge Workload Domain.

Topology:

  • 2-3 ESXi hosts with local disks.

  • No SAN (cost-sensitive or remote location).

Prerequisites:

  • Local SSDs/HDDs in each host.

Configuration Steps:

A. Configure vSAN for Edge

  1. In VCF Installer:

    • Select vSAN with 2-node ROBO configuration.

    • Witness: Use vSAN Witness Appliance in the cloud or central site.

B. Post-Deployment Validation

  1. Log in to vCenter for the edge WLD.

  2. Verify vSAN health and witness connectivity.

C. Storage Policy for Edge

  1. Create a Policy:

    • Rules: RAID-1 (Mirroring) for resilience.

    • Name: Edge-vSAN.

Key Considerations for All Scenarios:

  1. Performance:

    • vSAN: Use all-flash for latency-sensitive workloads.

    • SAN: Ensure queue depth and multipathing are optimized.

  2. Resilience:

    • vSAN: Enable deduplication/compression for all-flash.

    • SAN: Use RAID-1/10 for LUNs.

    • Stretched/Multi-Site: Test failover and RPO/RTO.

  3. Capacity Planning:

    • vSAN: Reserve 30% slack space for rebalancing.

    • SAN: Monitor thin provisioning and snapshots.

  4. Security:

    • Encrypt vSAN or SAN LUNs if required.

    • Restrict datastore access to specific clusters.

  5. Automation:

    • Use VCF APIs or PowerCLI to script storage policies and datastore mounting.

Given a scenario, configure Supervisor within a Workload Domain

1. Scenario: Greenfield Supervisor Cluster in a Single-Site Workload Domain

Goal:

Enable a Supervisor Cluster in a new Workload Domain to run Kubernetes workloads alongside traditional VMs, using vSAN for storage and NSX-T for networking.

Topology:

  • Workload Domain: Single-site, vSAN-backed.

  • Supervisor Cluster: Enabled on the vSphere cluster.

  • Networking: NSX-T Tier-1 Gateway for Kubernetes services.

  • Storage: vSAN Default Storage Policy for persistent volumes.

Prerequisites:

  • Workload Domain deployed with vSAN and NSX-T.

  • vCenter 8.0+ and ESXi 8.0+.

  • NSX-T 3.2+ (or NSX 4.x in VCF 9.0).

  • Tanzu Kubernetes Grid (TKG) 2.x binaries available in VCF.

  • Harbor Registry (optional, for container images).

  • Load Balancer (NSX ALB or third-party).

Configuration Steps:

A. Enable Workload Management

  1. Log in to the vCenter for the Workload Domain.

  2. Navigate to Menu > Workload Management.

  3. Click Get Started and select the target cluster (e.g., WLD-Prod-Cluster-01).

  4. Configure Supervisor Cluster:

    • Control Plane Size: Small/Medium/Large (select based on workload).

    • Network:

      • Service CIDR: 10.96.0.0/16 (default or custom).

      • Pod CIDR: 192.168.0.0/16.

      • Ingress CIDR: 10.97.0.0/16.

    • Storage: Select the vSAN Default Storage Policy.

    • Master DNS Name: wld-prod-supervisor.rainpole.io.

    • Master IP: 192.168.100.100 (or DHCP).

  5. Review and Finish to enable the Supervisor Cluster.

B. Configure NSX-T for Supervisor

  1. Log in to NSX Manager for the Workload Domain.

  2. Navigate to Inventory > Groups and create a Kubernetes group for the cluster.

  3. Configure Tier-1 Gateway for Ingress:

    • Edit the Tier-1 Gateway (T1-WLD-Prod-01).

    • Enable Route Advertisement for the Ingress CIDR (10.97.0.0/16).

  4. Create a Load Balancer Service:

    • Deploy NSX Advanced Load Balancer (ALB) or use an existing one.

    • Configure a Virtual IP (VIP) for the Supervisor Cluster (e.g., 192.168.100.101).

C. Create Namespaces

  1. In vCenter, navigate to Workload Management > Namespaces.

  2. Click Add Namespace:

    • Name: tanzu-prod

    • Storage: Assign the vSAN Default Storage Policy.

    • Permissions: Add users/groups (e.g., tanzu-admins).

    • Limit Ranges: Set CPU/memory limits (e.g., Request: 1CPU/1Gi, Limit: 4CPU/8Gi).

  3. Enable VM Service (optional) to run VMs as Kubernetes pods.

D. Deploy a Tanzu Kubernetes Cluster

  1. Navigate to Workload Management > Tanzu Kubernetes Clusters.

  2. Click Create Tanzu Kubernetes Cluster:

    • Name: tkg-prod-01

    • Control Plane: 3 nodes.

    • Worker Nodes: 3+ nodes.

    • Storage Class: vsan-default-storage-policy.

    • Network: Select the Tier-1 Gateway.

  3. Deploy and wait for the cluster to initialize.

E. Access the Supervisor Cluster

  1. Install kubectl and the vSphere Plugin:

kubectl vsphere login --server=wld-prod-supervisor.rainpole.io --vsphere-username administrator@vsphere.local

2. Verify Access

kubectl get nodes

kubectl config use-context tkg-prod-01

2. Scenario: Supervisor Cluster in a Stretched Workload Domain

Goal:

Enable a Supervisor Cluster in a stretched Workload Domain across two availability zones (AZs), with high availability for Kubernetes control plane and workloads.

Topology:

  • Workload Domain: Stretched vSAN or external storage with replication.

  • Supervisor Cluster: Control plane nodes distributed across AZs.

  • Networking: NSX-T Tier-1 Gateway with BGP/ECMP for cross-AZ connectivity.

Prerequisites:

  • Stretched Workload Domain with vSAN or replicated SAN.

  • NSX-T configured for stretched networking.

Configuration Steps:

A. Enable Workload Management

  1. Log in to vCenter and navigate to Workload Management.

  2. Select the stretched cluster (e.g., WLD-Prod-Stretched).

  3. Configure Supervisor Cluster:

    • Control Plane Size: Medium (3 nodes, 1 per AZ + witness).

    • Network:

      • Service CIDR: 10.96.0.0/16.

      • Pod CIDR: 192.168.0.0/16.

    • Storage: Use a stretched storage policy (e.g., vSAN-Stretched-Gold).

B. Configure NSX-T for Cross-AZ

  1. Log in to NSX Manager.

  2. Edit the Tier-1 Gateway (T1-WLD-Prod-Stretched):

    • Enable Route Advertisement for the Ingress CIDR.

    • Configure BGP for cross-AZ connectivity.

  3. Deploy NSX ALB with VIPs in both AZs.

C. Create Namespaces

  1. Add a Namespace (tanzu-prod-stretched):

    • Storage Policy: vSAN-Stretched-Gold.

    • Permissions: Assign to tanzu-admins.

D. Deploy a Tanzu Kubernetes Cluster

  1. Create a TKG Cluster (tkg-prod-stretched):

    • Control Plane: 3 nodes (1 per AZ + witness).

    • Worker Nodes: 3+ nodes per AZ.

    • Storage Class: vSAN-Stretched-Gold.

E. Test Failover

  1. Simulate AZ1 failure:

    • Power off hosts in AZ1.

    • Verify Kubernetes pods failover to AZ2.

3. Scenario: Supervisor Cluster in a Hybrid Cloud Workload Domain (VCF + VMware Cloud on AWS)

Goal:

Extend a Supervisor Cluster from on-premises VCF to VMware Cloud on AWS (VMC), enabling hybrid Kubernetes workloads.

Topology:

  • On-Prem: Supervisor Cluster in VCF Workload Domain.

  • Cloud: Tanzu Kubernetes Clusters in VMC.

  • Connectivity: HCX for workload mobility.

Prerequisites:

  • HCX deployed and configured between on-prem and VMC.

  • VMC SDDC with Tanzu enabled.

Configuration Steps:

A. Enable Workload Management (On-Prem)

  1. Follow the Greenfield steps to enable the Supervisor Cluster on-prem.

B. Enable Tanzu in VMC

  1. Log in to the VMC vCenter.

  2. Navigate to Workload Management and enable Tanzu on the VMC cluster.

C. Configure HCX for Kubernetes Mobility

  1. Log in to HCX Manager.

  2. Create a Service Mesh between on-prem and VMC.

  3. Migrate a TKG Cluster (or deploy new in VMC):

    • Use HCX Replication Assisted vMotion (RAV) to migrate Kubernetes nodes.

D. Federate Clusters (Optional)

  1. Install Tanzu Mission Control (TMC):

    • Attach both on-prem and VMC Tanzu Kubernetes Clusters.

    • Configure global policies for security and compliance.

4. Scenario: Supervisor Cluster in an Edge Workload Domain

Goal:

Deploy a lightweight Supervisor Cluster in an edge/remote Workload Domain, optimized for low resource usage.

Topology:

  • Workload Domain: 2-3 ESXi hosts with local storage.

  • Supervisor Cluster: Minimal control plane (1-3 nodes).

  • Networking: NSX-T Edge with VPN to central site.

Prerequisites:

  • Edge Workload Domain with vSAN or local storage.

  • NSX-T Edge configured for VPN connectivity.

Configuration Steps:

A. Enable Workload Management

  1. Log in to the edge vCenter.

  2. Navigate to Workload Management and select the edge cluster.

  3. Configure Supervisor Cluster:

    • Control Plane Size: Tiny (1 node) or Small (3 nodes).

    • Network:

      • Service CIDR: 10.96.0.0/20 (smaller range).

      • Pod CIDR: 192.168.0.0/20.

    • Storage: Local vSAN or NFS.

B. Create a Namespace

  1. Add Namespace (tanzu-edge):

    • Limit Ranges: Request: 0.5CPU/512Mi, Limit: 2CPU/4Gi.

    • Storage Policy: Edge-vSAN.

C. Deploy a Tanzu Kubernetes Cluster

  1. Create a TKG Cluster (tkg-edge-01):

    • Control Plane: 1 node.

    • Worker Nodes: 1-2 nodes.

    • Storage Class: edge-local-storage.

D. Manage from Central Site

  1. Use Tanzu Mission Control (TMC) to manage the edge cluster centrally.

5. Scenario: Supervisor Cluster with External Container Registry (Harbor)

Goal:

Configure a Supervisor Cluster to use an external container registry (e.g., Harbor) for custom container images.

Topology:

  • Workload Domain: Any (single-site, stretched, or hybrid).

  • Container Registry: Harbor or Docker Hub.

  • Networking: Allow outbound access to the registry.

Prerequisites:

  • Harbor Registry deployed and accessible.

  • Tanzu Kubernetes Grid (TKG) integrated with Harbor.

Configuration Steps:

A. Enable Workload Management

  1. Follow the Greenfield steps to enable the Supervisor Cluster.

B. Configure Container Registry

  1. Log in to the Supervisor Cluster:

kubectl vsphere login --server=<supervisor-fqdn> --vsphere-username administrator@vsphere.local

2. Create a Secret for Harbor:

kubectl create secret docker-registry harbor-secret --docker-server=harbor.rainpole.io --docker-username=admin --docker-password=password --docker-email=admin@rainpole.io

3. Deploy a TKG Cluster with Harbor:

Key Considerations for All Scenarios:

  1. Resource Allocation:

    • Control Plane: 3 nodes for production (1 for edge/dev).

    • Worker Nodes: Scale based on workload (start with 3).

  2. Networking:

    • Service CIDR/Pod CIDR: Avoid overlaps with existing networks.

    • Ingress: Use NSX ALB or a third-party load balancer.

  3. Storage:

    • vSAN: Use storage policies for persistent volumes.

    • SAN/NAS: Tag datastores for Kubernetes.

  4. Security:

    • RBAC: Restrict namespace access with vSphere roles.

    • Image Registry: Use private registries (Harbor, ECR) for custom images.

  5. Day-2 Operations:

    • Monitoring: Integrate with vRealize Operations or Prometheus/Grafana.

    • Backup: Use Velero for Kubernetes backup/restore.

    • Upgrades: Patch Tanzu Kubernetes Clusters via TKG CLI or vCenter.

  6. Automation:

    • Use TKG CLI or Terraform to automate cluster deployment.