SPBM might be a familiar term to some of you – it’s been with us in the vSphere world for a while now. You can create storage policies based on capabilities and state information exposed from your storage array as through vSphere APIs for Storage Awareness (or VASA). This information can be used to place workloads based on things like the number of failures that a workload needs to be able to tolerate and the number of IOPS required.
Storage in VMware Cloud on AWS is provided by vSAN. The capacity shown in the VMware Cloud on AWS console is the raw storage presented, and is consumed at different rates dependent on the storage policy applied to the VMs. There’s a great example that really helps explain how capacity is consumed in the VMware Cloud on AWS storage documentation.
Jason Massae from our HCI Business Unit covers SPBM in great detail in a dedicated blog series over at Virtual Blocks.
vSAN Capabilities
vSAN provides deduplication and compression capabilities which can help improve the efficiency of your storage consumption. Dedupe and Compression ratios are highly workload dependent, so do your testing!
vSAN Encryption is enabled out of the box, and cannot be disabled. When you deploy your SDDC the AWS Key Management Service (KMS) generates an initial Customer Master Key (CMK), which is stored by the AWS KMS. vSAN then generates the Key Encryption Key (KEK), and this key is encrypted using the CMK. This KEK is then used to encrypt the Disk Encryption Key (DEK) which is used to encrypt each vSAN disk.
vSAN Policies
Let’s look at our options for vSAN policies. If you deployed your SDDC as a stretched cluster across 2 Availability Zones (AZs) you have some options for site disaster tolerance, which protects your workloads against the failure of a site. Think of this like Secondary Failures To Tolerate (SFTT) in vSAN. If we had a stretched cluster we can specify Site Disaster Tolerance of Dual-Site Monitoring, None – Keep data on primary or None – Keep data on secondary. We have a standard (ie non-stretched cluster) deployment, so our only option is None (standard cluster).
We can then specify the number of failures that we need to be able to tolerate within 1 site – think of this like Primary Failures To Tolerate (PFTT) in vSAN. Here, we can specify between 1 and 3 failures, and either mirroring or RAID 5/RAID 6 erasure coding. Dependent on the number of failures we need the workloads to tolerate we require different numbers of hosts, and consume different amounts of vSAN capacity. There’s more information on this in the documentation.
VMware Cloud on AWS comes with a Default vSAN Storage Policy, which will be used for all VMs unless another policy is specified. This policy provides 1 disk stripe per object, tolerates 1 failure, reserves 0% of object space and does not force provision the objects.
Creating Storage Policies
Name the policy, and enter a description if you wish, then click Next.
Select “Enable rules for ‘vSAN’ storage” and click next
Select the number of failures that you wish to tolerate. We provide an estimate of the raw vSAN capacity that a 100Gb VM disk will consume dependent on your policy. If you wish to specify Advanced Policy Rules select this tab and configure these here.
Click Next and you will see all available compliant datastores. Note that if you specify requirements that your existing number of hosts cannot satisfy you will see no options here!
Click Next to see a summary of your policy, then click Finish.
Now all you need to do is apply the storage policy to some VMs. This is super simple! In the vSphere Client simply right click the VM in question > VM Policies > Edit VM Storage Policies.
From here, you can simply select the new VM Storage policy, and it’ll be applied to the VM on the fly, bringing it into compliance.
If we need to check the compliance status we can browse to the VM – you can see here that there’s a VM Storage Policies card in the vSphere Client which shows the allocated policy.
Click the Check Compliance link to force a compliance check now. As you can see, this VM is compliant.
Compute Policy
Compute policies specify rules that tell DRS how to place workloads onto hosts. If you’ve ever used DRS affinity or anti-affinity rules this may seem like familiar territory. Be aware however: compute policy rules in VMware Cloud on AWS apply to the entire SDDC (and not just a cluster). Compute policies leverage Tags. I detail the Compute Policy options below.
This policy states that a category of VM should run on a specific category of hosts. This can be helpful where you want to license only specific hosts to run certain applications, and also when you want VMs to run on hosts with a specific set of characteristics.
This policy states that a category of VM should not run on a category of hosts. This can be helpful where you need your VMs to run on hosts with specific capabilities, such as GPUs. In this situation you might create a host-affinity rule for the GPU workloads, and a VM-Host Anti-Affinity Affinity rule to ensure that other workloads are kept off the hosts with GPUs.
This policy is great for when you ideally want to keep a category of VMs on the same host to minimise latency between them. Alternatively, for when you want to keep specific VMs together to simplify auditing.
As the name suggests, this is the opposite of the above. This can be helpful when you have highly available workloads and you want to ensure that the loss of a host cannot bring down your applications.
This policy can be useful when you have workloads that you would prefer not to be vMotioned by DRS, and may be a good policy to use in conjunction with VM-VM affinity rules. This type of policy will try to keep a VM on a specific host as long as the host is available.
Important Notes!
Note that all of these policies are considered “should” rules. They cannot prevent a VM being powered on, so if no available hosts match the policy the VMs will be placed on any available host. The rules also cannot prevent a host from entering maintenance mode. Policies cannot prevent a VM from being placed on a specific host if one is specified, but will correct the placement in line with the policy at the next remediation cycle.
Compute Policies can be created and deleted, but not edited once created. Let’s create a Compute Policy now.
As always, login to your VMware Cloud on AWS console and select your SDDC. Select Open vCenter to launch the vSphere Client.
Click Menu>Policies and Profiles
In the left column select Compute Policies, then click Add to open the New Compute Policy wizard
Select the type of policy that you wish to create and enter a name and description for your policy. Next, specify the category and tag that you wish to associate with this policy.
Now that we have a policy create we can I’ve already created some tags to use for this – if you need more information on how to create tags in the vSphere Client please see the documentation.
To apply this policy to a VM in this example we simply add the tag “DRSvMotionDisable” to the VM. This will policy will be applied to the VM on the next scheduled remediation window.
Elastic DRS
If you’re anything like most people your workloads do not remain at the same level all year long. There’s natural peaks and troughs, and so you need to plan for the peaks when capacity planning traditionally. With Elastic DRS (EDRS) in VMware Cloud on AWS you can specify policies that will automatically grow and shrink the number of ESXi hosts in use based on resource demand.
By default, EDRS is disabled. EDRS has 3 main options if enabled. Optimise for Best Performance, which will add hosts more aggressively and remove hosts more slowly. You can optimise for Lowest Cost (which essentially flips things the other way). Finally, you can also specify to scale out only when more storage capacity is required.
To configure EDRS, login to the VMware Cloud on AWS console and select your SDDC, select the summary tab. Click Edit EDRS Settings.
You’ll see below that I’m scaling out based on storage capacity requirements. Select the option that meets your needs. Specify the minimum and maximum number of hosts that you want to be deployed at any time. Whenever a scale-out or scale-in operation occurs all Organization users will receive notifications by email and in the SDDC console.
And that just about covers Storage, Compute and EDRS policies!
Thanks for joining me again for this post on the importance of policy based management in VMware Cloud on AWS. I hope that you’ll be back for the next post, where I’ll be diving into the world of Security Policies.
