Your Browser is Out of Date

Nytro.ai uses technology that works best in other browsers.
For a full experience use one of the browsers below
Architecture Guide—VMware Cloud Foundation on VxRail: VCF 5.x on VxRail 8.x
Executive Summary Architecture Overview Workload Domain Architecture
Introduction
Management WLD
VI workload domain
Isolated SSO workload domains
Consolidated architecture
Physical WLD layout
VxRail Virtual Network Architecture Network Virtualization NSX WLD Design Enabling VCF with Tanzu Features on Workload Domains Physical Network Design Considerations Storage Options Multi-site Design Considerations Operations Management Architecture Lifecycle Management Cloud Management Architecture

Consolidated architecture

Home > Integrated Products > VxRail > Guides > Architecture Guide—VMware Cloud Foundation on VxRail: VCF 5.x on VxRail 8.x > Consolidated architecture

Consolidated architecture

  • Overview

    In a standard deployment, the VCF management WLD consists of workloads supporting the virtual infrastructure, cloud operations, cloud automation, business continuity, and security and compliance components for the SDDC. Using SDDC Manager, separate WLDs are allocated to tenant or containerized workloads. In a consolidated architecture, the VCF management WLD runs both the management workloads and tenant workloads.

    There are limitations to the consolidated architecture model that must be considered:

    • The conversion of consolidated to standard requires a new VI WLD domain to be created. The tenant workloads must be migrated to the new VI WLD. The recommended method for this migration is to use HCX.
    • Use cases that require a VI WLD to be configured to meet specific application requirements cannot run on a consolidated architecture. The singular management WLD cannot be tailored to support management functionality and these use cases. If your plans include applications that require a specialized VI WLD (such as Horizon VDI or PKS), plan to deploy a standard architecture.
    • Life-cycle management can be applied to individual VI WLDs in a standard architecture. If the applications targeted for VCF on VxRail have strict dependencies on the underlying platform, consolidated architecture 4 is not an option.
    • Autonomous licensing can be used in a standard architecture, where licensing can be applied to individual VI WLDs. In a consolidated architecture, autonomous licensing is not an option.
    • Scalability in a consolidated architecture has less flexibility than a standard architecture. Expansion is limited to the underlying VxRail cluster or clusters supporting the single management WLD because all resources are shared.
    • If a VxRail cluster was built using two network interfaces, consolidating VxRail traffic and NSX traffic, additional nodes are limited to two Ethernet ports being used for VCF for VxRail.

    Remote VxRail clusters

    With Remote Clusters, you can deploy a VI WLD that has its VMware vSphere cluster at a remote location. You can also enable VCF with Tanzu on a cluster deployed at a remote site. All the VCF operational management can be administered from the central or regional data center out to the remote sites, which is important because:

    • It eliminates the need to have technical or administrative support personnel at the remote locations resulting in better efficiencies with significantly lower operating expenses.
    • Edge compute processing also allows customers to comply with data locality requirements that are driven by local government regulations.
    • VCF Remote VxRail clusters establish a means to standardize operations and centralize the administration and software updates to all the remote locations.

    The following figure illustrates a VCF Deployment with two VI WLD Domains, one local and the other remote which is located at single Edge site where the VxRail cluster is deployed:

    Figure 5.   Remote VxRail cluster deployment

    Remote VxRail cluster deployments

    The following requirements must be met for remote VxRail cluster deployments. Failure to adhere to these requirements will lead to system integrity, instability, resiliency, and security issues of the Edge workload.

    • 10 Mbps bandwidth.
    • 50-millisecond RTT latency.
    • Support for only three or four nodes per remote site per VI WLD domain. VI WLD domain can include a local cluster or remote cluster but not both.
    • Single Site Remote Cluster support per VCF instance for VCF 5.0 or earlier.
    • Primary and secondary active WAN links (not required, but highly recommended).
    • DNS and NTP Server available locally or reachable from central site to Edge site.
    • A DHCP server that is available for the NSX host overlay (Host TEP) VLAN of the WLD. When NSX creates Edge Tunnel End Points (TEPs) for the VI WLD, the TEPs are assigned IP addresses from the DHCP server. The DHCP server should be available locally at the Edge site.

    Remote VxRail cluster network design

    The remote sites require NSX Edge Nodes to be deployed at each site for north-south connectivity. Also, connectivity from the central site to the remote site must be maintained to ensure connectivity of management components such as vCenter, SDDC Manager, NSX Manager, and so forth. As mentioned in the requirements, if DNS and NTP servers are running in the central site, they must be reachable from the Edge site.

    Figure 6.   Remote VxRail cluster network design