Dell EMC VxRail – Introducing VCF 4.0

Dell EMC VxRail – Introducing VMware Cloud Foundation 4.0

VMware Cloud Foundation 4.0 software is now generally available (GA) as a jointly-engineered & integrated system via Dell EMC VxRail. Here I will highlight some key points from this new release of VCF On VxRail which is powered by vSphere 7.0, vSAN 7.0 and NSX-T 3.0.

The following is a list of all the components and their respective versions as per the VCF On VxRail 4.0 Bill of Materials:

• Cloud Builder 4.0.0.0
• SDDC Manager 4.0
• VMware vCenter Server Appliance 7.0.0
• VMware ESXi 7.0.0
• VMware vSAN 7.0.0
• VMware NSX-T 3.0 w/VDS 7
• VMware vRealize Suite Lifecycle Manager 8.1
• Dell EMC VxRail 7.0.0

VCF Supported Software Solutions:

• Horizon VDI 7.1.2 (manual guidance)
• vRSLCM 8.1 (AVN required)
• vRealize 8.1 components: vRA 8.1, vR Ops 8.1, and vRLI 8.1 (VVD guidance)

The above components are deployed by using a combination of Cloud Builder for the initial bring-up and SDDC Manager for the Day-X component deployments such as  vRSLCM. As part of the VCF implementation these components are installed and configured as per the VMware Validated Design(VVD) solution architectures.

The VMware Cloud Foundation 4.0 on Dell EMC VxRail Release Notes can be found here.

Note: VCF On VxRAIL 4.0 initial release is intended for greenfield VCF deployments only, upgrades from VCF 3.9.x are planned for a future release.

With the PSC now being embedded as part of the vSphere 7.0 architecture and with the addition of leveraging NSX-T we now have a more scaled down Management WLD compared to previous VCF releases. vRealize Log Insight(vRLI) is now optional, thus vRLI is no longer a Day-0 activity deployed by Cloud Builder and can be deployed as a Day-X task leveraging vRSLCM 8.1.

NSX-T is now used in the management domain (previously NSX-V only). In fact NSX-T is now used exclusively across both the Mgmt and VI workload domains as part of this VCF 4.0 release. As per previous releases the Mgmt WLD cluster requires a minimum of 4 nodes, it is worth noting that the 3x NSX-T manager appliances get deployed as a medium size (6vCPU, 24GB Mem, 300GB Disk). As part of the vRSLCM(optional) automated deployment via SDDC manager, geneve backed Application Virtual Networks(AVNs) leveraging BGP peering are required to have been enabled at which point the required 2x Edge nodes get deployed in an active/active state to the mgmt workload domain, again with a default medium size appliance (4vCPU, 8GB Mem, 200GB Disk). Kudos to Cathal Prendeville for the diagrams below.

N-VDS is no longer used for host connectivity with all traffic (VLAN & Overlay) now backed by the VxRail vDS, which includes VxRail system VLANs and NSX-T host TEPs using the same VxRail vDS.

Converged vDS now offers support for 2-NIC port configurations with NSX-T 3.0 (previously with VCF On VxRail 3.9 there was a requirement for 2x dedicated NSX-T physical NICs).

Flexible NSX-T deployment options – As of VCF 4.0 NSX-T Management cluster can be a 1:1 or a 1:Many relationship at a per Workload Domain level, which means a WLD can share an instance of NSX-T with other WLDs, the exception here is the Management WLD NSX-T instance which cannot be shared with other WLDs. During the deployment of a VI WLD you may now select to join an existing NSX-T Manager cluster that was previously created for another VI workload domain or deploy a dedicated NSX-T Manager cluster cluster.

NSX-T Edge-Cluster Automation – The deployment of the NSX Edge devices to their associated Edge cluster is now a Day-X automated task via SDDC Manager. SDDC Manager can now be leveraged to automate the deployment of an NSX Edge cluster to support a Kubernetes for vSphere cluster (WCP) or a VI workload domain, with the deployment options being presented as ‘Workload Management’ or ‘Custom’ respectively.

Consolidated Architecture (single VC/Cluster) – VCF 4.0 on VxRail 7.0 will support a 4-node initial consolidated deployment with a recommendation for a Standard Architecture model where solutions consist of 8 or more hosts. While consolidated architectures are useful for small scale deployments leveraging resource pools for logical separation, it is worth noting that SDDC Manager does not have support for the deployment of solutions such as Horizon and vSphere for Kubernetes as these solutions require dedicated workload domains. Converting from a VCF On VxRail consolidated architecture to a standard architecture is not supported at this time. Also as consolidated is a single WLD solution LCM will include both mgmt components and production workloads at the same time. Planning and sizing is key! Further info on consolidated architecture can be found here.

The VCF Management WLD name which was previously set to ‘MGMT’ may now be customized in the VCF input spreadsheet.  In addition the VCF input spreadsheet now inlcudes entries for optional AVN, NSX-T for management WLD and Log Insight entries are no longer required as part of the initial bring-up (vRSLCM utilized for day1 deployments of the vRealize components).

New Security Enhancements – The privileged user(dual auth) is no longer required with the introduction in VCF 4.0 of Admin and Operator roles for API and UI:

• Admin Role – All Privileges
• Operator Role – All Privileges with the Exception of: Password Mgmt,
  Backup/Restore, User Mgmt

PSC and AD integration available. Enhanced security API via Token Based Authentication. Public API requires Authentication Token.

vSphere with Kubernetes enabled clusters in VxRail VI
Workload Domains – ‘Fastest way to get Kubernetes (K8s) in your enterprise’
With VMware Cloud Foundation 4.0 Kubernetes clusters, containers and VMs can all now be managed from within vCenter server. The concept of a namespace (grouping of resource objects such as VMs and containers into logical applications) which is associated with Kubernetes is integrated into vSphere allowing a vi admin to manage Kubernetes from within vCenter itself. By leveraging SDDC Manager the following tasks associated with a deploying and managing a vSphere with Kubernetes WLD are automated:

• Create WLD
• Deploy NSX
• Deploy Edge Cluster
• Enable Workload Management
• Lifecycle the Software Stack

During the automated process of deploying the NSX Edge cluster through SDDC manager the capability exists to define profiles, a specific profile exists for the EDGE deployment which is unique to vSphere with Kubernetes to ensure the Edge devices match the requirements of a vSphere with Kubernetes cluster.

LCM of the SDDC environment continues in the same vein providing scheduled updates, monitoring & reporting and the capability to upgrade on a per Cluster level.

This is an exciting release and testament to the huge efforts put in by Dell Technologies teams across Dell EMC/VMware!