VMware Cloud on AWS: vCenter Architecture

Overview

The compute resources of an SDDC are composed of a series of bare-metal servers, installed with ESXi, and managed by an instance of vCenter.

The details of the vCenter architecture are discussed below.

vCenter Inventory

Datacenters

An SDDC supports a single Datacenter which is named “SDDC-Datacenter”. All resources for the SDDC reside within this Datacenter.

Datacenters within the SDDC cannot be renamed. While this is not typically an issue, it is something that should be kept in mind in situations where a deployment contains multiple SDDCs. In these cases, the fixed naming scheme may present challenges to monitoring and operations due to the identically named Datacenters.

Clusters

Clusters are used as a means of enabling vSphere High Availability (HA) and vSphere Distributed Resource Scheduler (DRS) within an SDDC. All hosts of the SDDC will exist within a cluster, and this behavior is enforced by the VMC management console and the permissions model of vCenter. The naming convention for Clusters is “Cluster-n”, where “n” is the sequence number of the Cluster. As with Datacenters, Clusters cannot be renamed.

An SDDC will start out with a single cluster, named “Cluster-1”, which will be used by both management appliances and end-user workloads. This cluster is commonly referred to as the base or primary cluster of the SDDC. Additional clusters may be added to the SDDC, as needed, up to the supported maximums for the SDDC.

By default, clusters are bound to a single AWS Availability Zone (AZ). For customers whose business needs require higher availability, there is the option to deploy an SDDC with stretched-cluster support enabled. Stretched clustering allows for the hosts of the cluster to be split across two AZs within an AWS region.

Hosts

New Hosts will be added to one Cluster within the SDDC and will contribute its resources to that Cluster. A Cluster must contain a minimum of 3 hosts for production deployments. Additionally, hosts within a Cluster must be of the same instance type. So called “mixed-host” Clusters are not permitted. Since the vast majority of vSAN deployments contain 16 or fewer hosts within a single Cluster, and this is generally considered a supported maximum for vSAN, VMware supports a maximum of 16 hosts per Cluster (with occasional temporary exceptions made under special circumstances).

In addition to limits on the number of hosts per cluster, there are also defined maximums on the total number of hosts per SDDC. See the configuration maximums for details.

Resource Pools

Resource Pools within an SDDC exist primarily to protect the management appliances. They serve 2 functions:

1. They provide a mechanism to reserve compute resources for management appliances.
2. They act as the target object for assigning permissions to management appliances.

The SDDC is created with 2 Resource Pools within the base cluster:

• Mgmt-ResourcePool - This Resource Pool contains the management appliances.
• Compute-ResourcePool - This Resource Pool is meant to contain end-user workloads.

Due to the permissions model of vCenter, it is possible to create workloads outside of Compute-ResourcePool. However, this practice is strongly discouraged due to the potential for creating resource contention between workloads which exist within Resource Pools and those that do not. As a general practice, all workloads should be placed within Compute-ResourcePool in order to avoid this problem.

Datastores

The base cluster of the SDDC contains 2 Datastores:

1. vsanDatastore - This Datastore is reserved for SDDC management appliances.
2. WorkloadDatastore - This Datastore is available for end-user workloads.

These Datastores are logical representations of the same underlying vSAN storage pool and are presented as separated entities for the purposes of enforcing permissions within the SDDC. Specifically, vsanDatastore is protected and cannot be modified.

Since management appliances reside exclusively within the base cluster, additional clusters that are added to the SDDC will contain only a single Datastore for end-user workloads. The naming convention for these Datastores is “WorkloadDatastore (n)", where “n” is the sequence number of the Datastore. Note that the sequence starts at 1 and may be a bit confusing considering the inconsistency with the Cluster naming convention. As an example:

• Cluster-1 owns WorkloadDatastore
• Cluster-2 owns WorkloadDatastore (1)
• etc…

Networks

Hosts of the SDDC use an NSX-T Virtual Distributed Switch (N-VDS) as their virtual switch of choice. The N-VDS is managed by the local instance of NSX-T within the SDDC.

Permissions Model

The permissions model of an SDDC is designed in such a way as to allow the administrator (VMware) and the tenant (customer) to co-manage the deployment. The high-level goals of the permissions model are:

• Permit the administrator and tenant joint access to vCenter.
• Permit the tenant to manage their own workloads, users/groups (via AD/LDAP), tags, permissions (on their inventory objects), roles (from subset of their permissions), etc.
• Protect administrator-managed objects (management appliances, users/groups, global policies, roles, permissions, hosts, storage, etc..).

Cloud Admin Role

The Cloud Admin Role defines the permissions for tenants within the SDDC. Custom roles created by the tenant may only consist of subset permissions from this role.

The specific permissions granted to the Cloud Admin Role are documented here.

Cloud Admin Group

The Cloud Admin Group is used for defining access to objects within the vCenter inventory tree. This group has been granted a Cloud Admin Role within Global Permissions as well as on the Datacenter object of vCenter. It has been granted a read-only permission set on the management resources within vCenter (storage, networks, Resource Pools, VMs) as well as on the “Discovered virtual machines” folder.

Tenant users within AD/LDAP will be assigned to the Cloud Admin Group (or an AD/LDAP group with a custom role and a subset permissions) within vCenter.

Cloud Admin User

Tenants will access vCenter using the cloudadmin@vmc.local user account. The Cloud Admin User is initially provisioned with a randomized password which is available from within the SDDC view of the VMC console. It should be noted that if this password is changed from within vCenter, the password will not propagate to the VMC console (which will continue to reflect the old password).

 

Authors and Contributors

Author: Dustin Spinhirne