In my previous post, I talked about the setup of a SDDC on AWS. Now I want to focus on resource management and the scalability features
One of the coolest features of VMC, is the ability to scale up or down (keep in mind 4 hosts is the minimum).
The Add /Remove Host feature allows for manual scaling of the environment, this really is elastic cloud, need more capacity, it takes a couple of minutes to add new hosts.
Once the additionally capacity is no longer needed, then it can be returned.
Perhaps you have a baseline of 4 hosts at Reserved Price (minimum 1 year), you have a new project and want to scale up for a few weeks, you add a couple of the more expensive on-demand hosts, and once the project is finished give back the extra capacity.
At the moment only one host type is available and they deliver a sizeable resource increase in minutes. It’s possible different host types or storage solutions will be added at a later date, but for now its a single host with fixed cpu, memory and storage.
Although the ability to scale manually is awesome, I heard talk of Elastic DRS, this will enable thresholds to trigger cluster size adjustments – so autoscaling of the vSphere cluster.
So far I haven’t seen how or where that is configured, but that leads on to a very important point
VMware Manage the hosts
Customers will access with a vmc account, VMware will have admin and root access, so customers will not patch or maintain vCenter or the hosts.
One advantage of this, is that while patching VMware will add additional hosts to ensure HA at no extra cost. Fixes will be applied quickly and although a schedule has yet to be defined but it’s most probable the environment will be updated every quarter.
Any linked on-premises vCenter is should be no more than one major release behind the AWS version.
* A Major Release is a generally designated by VMware by means of a change in the digit to the left of the first decimal point (e.g., Software 5.0 >> Software 6.0).
Besides adding additional hosts during patching, if there is a hardware or physical fault on a host, VMware will replace and remove it from the cluster, this means vm to host consolidation ratios can be a little higher than on-premises, you might even be tempted to leave some vms powered off until VMware fixes the issue or adds some extra capacity.
Tools such as PowerCLI, API calls, or our existing on-premises vRealise Automation will work exactly the same in VMC, though scripts or requests that require ESXi root access will fail due to insufficient permissions. My understanding is that a management folder and management resource pool will be used to limit permissions to the vCenter, NSX Manager and Controllers.
However as VMware have the responsibility to configuring and auditing the virtual infrastructure layer, we should need that level of access anyway.
In the next blog I discuss the storage architecture of VMware on AWS