VMware Cloud on AWS™ brings VMware’s enterprise class Software-Defined Data Center software to the AWS Cloud, and enables customers to run production applications across vSphere-based private, public and hybrid cloud environments. Delivered, sold and supported by VMware as an on-demand service, customers can also leverage AWS’s breadth of services including storage, databases, analytics and more.
IT teams manage their cloud-based resources with familiar VMware tools – without the hassles of learning new skills or utilizing new tools. However, administrative responsibilities for the vSphere cluster deployed as part of the Cloud Software-Defined Data Center (SDDC) will be shared between the VMware Cloud on AWS service and the on-premises administrator.
This blog series will describe the differences between running the VMware SDDC software on-premises vs. in VMware Cloud on AWS, and will go over the new operation model that administrators will need to adopt when using this service.
VMware Cloud on AWS Operations: Part 2, Administration
Vmware Cloud on AWS Operations: Part 3, Virtual Machine Deployment and Service Lifecycle
PART 1 OF BLOG SERIES: HOST CONFIGURATION
A Cloud SDDC cluster is dedicated to a single customer. Existing AWS controls ensure customer segregation using dedicated AWS accounts and AWS Virtual Private Connections (VPC) for each Cloud SDDC deployment. Because vSAN is built out of local storage and each ESXi host is dedicated to a single customer, there is no sharing of resources across different customers inside the SDDC compute, network or storage layers.
Cluster Settings Overview
At initial availability, a single cluster can be deployed per Cloud SDDC. VMware manages the vSphere HA, DRS, and vSAN settings for the customer and as a result the customer cloud administrator has read-only view of the cluster configuration settings. This model does not provide the option to configure per-VM HA and DRS settings nor does it allow configuration of DRS affinity rules settings such as VM-VM as well as VM-Host affinity rules.
Figure 1: Read-Only View vSphere Cluster
Two vSphere DRS resource pools are created. A resource pool named MGMT-ResourcePool contains the management virtual machines and is configured with a CPU and memory resource reservation. The customer cloud administrator has read-only view of the virtual machine and resource pool settings of the management resource pool.
Customer workload virtual machines are placed in the resource pool named Compute-ResourcePool. By default, the customer workload resource pool is not configured with CPU and memory resource reservations. The customer cloud administrator has full control access rights over this resource pool.
Figure 2: Customer Workload Resource Pool Configuration
Table 1: VMware Cloud on AWS SDDC Cluster Setting
* Nested Resources Pools should not be used as a substitute for a folder structure in the inventory view. The technical paper DRS Cluster Management with Reservation and Shares provides guidance on how to structure nested resource pools.
ESXi Host Settings Overview
In this model customer are expected to focus on consuming cloud resources and move away from an infrastructure focused operational model. No direct access to ESXi host resources is provided to the customer cloud administrator. SSH is disabled and the customer cloud administrator will not receive any ESXi host credentials. As a result, the customer cloud administrator cannot install any third-party software on the Cloud SDDC ESXi hosts. ESXi host reporting, such as host logs, and core dumps are unavailable to the customer cloud administrator. Read-only host operations are mediated through vCenter such as vSphere API calls and the execution of PowerCLI and ESXCLI commands.
Network Settings Overview
VMware NSX is a key ingredient for VMware Cloud on AWS. All virtual machine networking in VMware Cloud on AWS is provided by NSX and provides compatibility with NSX and vSphere products used on-premises. The networking technologies used in VMware Cloud on AWS are jointly engineered solution between VMware and Amazon and allows vSphere and NSX to optimally work in the AWS environment. Amazon has enhanced AWS infrastructure to enable the VMware Cloud on AWS service. Similar to every other key infrastructure component of the Cloud SDDC, it is delivered as a service cloud model and allows frequent introductions of additional networking capabilities.
The customer is not required to run NSX on premises to connect to the Cloud SDDC. NSX in the Cloud SDDC connects the ESXi hosts to the AWS infrastructure and abstract AWS VPC networks for the customer cloud administrator.
At VMware Cloud on AWS initial availability, the customer connects to VMware Cloud on AWS by using a L3 VPN Connection. There should be a VPN connection to the management gateway of the Cloud SDDC, to allow communication with the management interfaces such as vCenter Server, and optionally another VPN which connects to the compute gateway, to allow private communication between the workloads running in the Cloud SDDC and the on-premises datacenter.
Simplified Mode Networking
The goal is to allow everyone that uses vSphere to consume VMware Cloud on AWS as easy as possible. VMware Cloud on AWS is designed from the ground up to provide an easy method of resource consumption. To avoid any steep learning curve for network management for on-premises network and cloud administrator unfamiliar with NSX operations, simplified mode provides basic networking services. The network topology and its components are preconfigured and cannot be changed by the customer; this is referred to as a prescriptive network topology. The on-premises administrators only need to specify subnets and IP ranges.
Figure 3: VMware Cloud on AWS Network Connectivity Diagram
A VMware Cloud on AWS Service Console (Portal) is developed for end user access. The connectivity to and from the Cloud SDDC is managed through the VMware Cloud on AWS portal at http://vmc.vmware.com. The customer cloud network admin logs into the VMware Cloud on AWS portal and configures the network. The customer cloud network admin establishes VPN connectivity and configures the access rules of the firewall. For example, this is necessary for the connection to the vCenter because, by default, there is no external access to the vCenter Server system in the Cloud SDDC. The customer cloud administrator logs into vCenter with the vSphere web client and consumes the networks that the cloud network admin created. The customer cloud administrator can create logical networks and connect virtual machines. The customer cloud network admin permits traffic through the firewall and across the VPN networks.
Figure 4: VMware Cloud™ on AWS Networking Configuration in VMware Cloud™ on AWS Portal
vSphere Networking Settings
NSX allows ease of management by providing logical networks to virtual machines. When the cluster is scaled-out, NSX automatically connects the new hosts to the logical networks and the VMkernel networks. The NSX version used in VMware Cloud on AWS provides compatibility with NSX on premises. The customer cloud administrator is unable to configure or add and remove VMkernel networks which provide infrastructure services, but does have full control over logical networks. The NSX logical network construct is the Cloud SSDC equivalent to the on-premises SDDC distributed switch port group.
vMotion Encryption
Encrypted vMotion was introduced in VMware vSphere 6.5. It does not require a third-party key manager. It is set on a per-VM basis as part of the virtual machines Options. Encrypted vMotion encrypts the data going over the vMotion network, not the network itself. As such it requires no special configuration other than enabling it in the virtual machine options. Encrypted vMotion is available at VMware Cloud on AWS initial availability between hosts inside the Cloud SDDC.
Storage Settings Overview
vSAN provides the storage capacity and storage services to the virtual machines. vSAN consumes eight local NVMe device per ESXi host and is comprised of two disk groups. The customer cloud administrator has read-only view to the configuration of the vSAN datastore. To provide data security, all local storage NVMe devices are encrypted at the firmware level by AWS. The encryption keys for NVMe encryption are managed by AWS and are not exposed or controlled by VMware or the VMware Cloud on AWS customers.
vSAN Datastore
All virtual machines running inside the Cloud SDDC consume storage capacity and leverage storage services from vSAN. Management workloads, and the workloads belonging to a single VMware Cloud on AWS customer are located on the same vSAN cluster. However, a new vSAN capability is being introduced for Cloud SDDC to provide two logical datastores instead of one. One of these datastores will be used to store the management virtual machines and the other datastore will be used for the customer virtual machines.
Figure 5: Cloud SDDC vSAN Datastores
The customer cloud administrator has read-only view to the management virtual machines datastore to browse the datastore space. The customer cloud administrator can allocate space and browse the workload datastore. By default, the default storage policy is applied to both the management virtual machines datastore and the customer WorkloadDatastore.
vSAN Health Services
VMware monitors the health and performance of the vSAN datastore, as a result vSAN Health Monitoring and vSAN Performance Service are not available to the on-premises Cloud Administrator.
vSAN Storage Policies
The storage policies are applied to virtual machines and their objects. There is a default policy set on the VSAN datastore. This policy is applied to all new virtual machines that do not have a specific policy assigned to them.
Table 2: Default vSAN Storage Policies for Workload Virtual Machines
The customer cloud administrator is unable to reconfigure the storage policies set to the management virtual machines. Instead of using RAID-1, the vSAN storage policy of management VMs is configured with the RAID 5/6 Fault Tolerance Method. This reduces the capacity footprint of the management virtual machines, preserving the most available datastore capacity for workload virtual machines. The primary level of failures to tolerate for management virtual machines is adjusted if the ESXi host count inside the Cloud SDDC is six or more.
Table 3: Default vSAN Storage Policies for Management VMs
The customer cloud administrator is able to create a storage policy with the required failure tolerance method for the vSAN datastore storing the workload virtual machines. This can be for example, RAID-5 for the initial cluster configuration. If the SDDC cluster contains six ESXi hosts, the RAID-6 erasure coding fault tolerance method is supported. The new storage policy can act as the default storage policy of the WorkloadDatastore.