When you design a VMware Cloud Foundation deployment, you decide what architecture model, that is, standard or consolidated, and what workload domain types, for example, consolidated, isolated, or standard, to implement according to the requirements for hardware, expected number of workloads and workload domains, co-location of management and customer workloads, identity isolation, and shared or isolated networking and security.

Architecture Models

Decide on a model according to your organization's requirements and your environment's resource capabilities. Implement a standard architecture for workload provisioning and mobility across VMware Cloud Foundation instances according to production best practices. If you plan to deploy a small-scale environment, or if you are working on an SDDC proof-of-concept, implement a consolidated architecture.

Figure 1. Choosing a VMware Cloud Foundation Architecture Model

The first decision is based on the need to minimize hardware. If yes, next if co-location of management and customer workloads is allowed, you implement the consolidated architecture. Otherwise, you implement the standard architecture.
Table 1. Architecture Model Recommendations for VMware Cloud Foundation

Requirement ID

Design Requirement

Justification

Implication

VCF-ARCH-RCMD-CFG-001

Use the standard architecture model of VMware Cloud Foundation.

  • Aligns with the VMware best practice of separating management workloads from customer workloads.

  • Provides better long-term flexibility and expansion options.

Requires additional hardware.

Workload Domain Types

A workload domain represents a logical unit of application-ready infrastructure that groups ESXi hosts managed by a vCenter Server instance with specific characteristics according to VMware recommended practices. A workload domain can consist of one or more vSphere clusters, provisioned by SDDC Manager.

Table 2. Workload Domain Types

Workload Domain Type

Description

Benefits

Drawbacks

Management domain

  • First domain deployed.
  • Contains the following management appliances for all workload domains:

    • vCenter Server

    • NSX Manager

    • SDDC Manager

    • Optional. VMware Aria Suite components

    • Optional. Management domain NSX Edge nodes

  • Has dedicated ESXi hosts

  • First domain to upgrade.
  • Guaranteed sufficient resources for management components

  • Makes it possible to use specific hardware to meet the needs only of the management components

  • Makes it possible to use dedicated physical compute, network and storage separately from those used for additional workloads

  • Enables separate lifecycle management of management and workload components.

  • You must carefully size the domain to accommodate planned deployment of VI workload domains and additional management components.

  • Hardware might not be fully utilized until full-scale deployment has been reached.

Consolidated domain

  • Represents a management domain which also runs customer workloads.

  • Uses resource pools to ensure sufficient resources for management components.

  • Considers the minimum possible initial hardware and management component footprint.

  • Can be scaled to a standard architecture model.

  • Management components and customer workloads are not isolated.

  • You must constantly monitor it to ensure sufficient resources for management components.

  • Migrating customer workloads to dedicated VI workloads domains is more complex.

VI workload domain

  • Represents an additional workload domain for running customer workloads.

  • Shares a vCenter Single Sign-On domain with the management domain.

  • Shares identity provider configuration with the management domain.

  • Has dedicated ESXi hosts.

  • Can share an NSX Manager instance with other VI workload domains.

  • All workload domains can be managed through a single pane of glass.

  • Reduces password management overhead.

  • Enables independent life cycle management.
  • This workload domain type cannot provide distinct vCenter Single Sign-On domains for customer workloads.

  • You can scale up to 14 VI workload domains per VMware Cloud Foundation instance.

Isolated VI workload domain

  • Represents an additional workload domain for running customer workloads.

  • Has a distinct vCenter Single Sign-On domain.

  • Has a distinct identity provider configuration.

  • Has dedicated ESXi hosts.

  • Can provide distinct vCenter Single Sign-On domains for customer workloads.

  • You can scale up to 24 VI workload domains per VMware Cloud Foundation instance.

  • Enables independent life cycle management.
  • Workload domain vCenter Server instances are managed through different panes of glass.

  • Additional password management overhead exists for administrators of VMware Cloud Foundation.

Figure 2. Choosing a VMware Cloud Foundation Workload Domain Type for Customer Workloads

The first decision is based on the architecture model. If you are not using the consolidated architecture, next if NSX must be shared between domains, you use VI workload domains. Otherwise, if you need more than 14 VI workload domains, you use isolated domains. Otherwise, you go with isolated workload domains if you need a dedicated single sign-on domain or with VI workload domains otherwise.
Table 3. Workload Domain Recommendations for VMware Cloud Foundation

Recommendation ID

Design Recommendation

Justification

Implication

VCF-WLD-RCMD-CFG-001

Use VI workload domains or isolated VI workload domains for customer workloads.

  • Aligns with the VMware best practice of separating management workloads from customer workloads.

  • Provides better long term flexibility and expansion options.

Requires additional hardware.