Policy-based management is the enabling technology behind storage management inside the VMware Cloud on AWS Service. By empowering customers to easily align the availability and performance configuration on a per workload basis. This declarative framework is incredibly powerful, but when making changes that impact a large number of objects, we need to consider transition space.
The Decision
Occasionally the configuration for a particular policy will need to be adjusted. Which leads to a critical decision; Change the existing policy, or create a new policy and reassign?
The answer depends on how many objects are associated with the current policy. While it is possible to change the settings of an existing policy, choosing to delay processing, managing this transition can be tedious, and error-prone.
Alternatively, one could choose to process the change now, but doing so could cause vSAN to consume an excessive amount of capacity during the transition. Worse case, triggering Elastic DRS to scale-up the cluster and causing vSAN to rebalance due to high disk group utilization.
Doesn’t vSAN handle this for me?
Several subsystems within vSAN try and limit the impact of changing a storage policy configuration. Adaptive Resync will restrict the effect of any resynchronization traffic on production workloads. As of vSAN 6.7u3 (VMC 1.8), vSAN will also batch policy transitions.
Slack space coordination attempts to limit the amount of storage capacity used for reconfiguring objects to no more than 20% of free capacity.
Together these systems empower Administrators to perform storage management via artillery, merely lobbing requests over the hill to vSAN to ‘make it so.’ For the most part, these systems will batch up any policy changes, pausing the resync as needed to ensure the cluster does not run out of free capacity. The exception being any objects that are larger than 255GB.
Dealing with Large Objects
Each object within vSAN is made up of one or more components. The maximum size of a component is 255GB. Larger objects are split up into multiple components. The entire object must be rebuilt to transition from one policy configuration to another. This activity cannot be broken up or paused on larger objects. The cluster must have sufficient capacity to make the transition. Very large disks may require temporarily scaling up the cluster to accommodate the change.
Elastic DRS
If too much capacity is consumed, the service will scale up the cluster. Adding an additional host. This host can be removed as soon as the transition is completed.
Manage the transition
While no longer required as of vSAN 6.7u3/VMC on AWS 1.8. To guarantee sufficient free capacity, the policy transition can be managed more directly by creating a new policy, and then reassign the policy configuration in batches. Ensuring sufficient capacity for each transition.
Summary
For the most part, the robust data handling subsystems within vSAN enable the storage administrator to embrace a declarative mindset. Lobbing policy changes as needed; trusting in vSAN, and VMware Cloud to sort it out. When changing many objects all at once and or when transitioning a massive Virtual Disk, it may be necessary to manage the transition to avoid unplanned host additions.
Availability
To view the latest status of features for VMware Cloud on AWS, visit https://cloud.vmware.com/vmc-aws/roadmap.
Resources:
- You can learn more about the service at https://cloud.vmware.com/vmc-aws
- Watch: VMware Cloud on AWS: Overview
- Learn more about VMware Site Recovery at http://cloud.vmware.com/vmware-site-recovery
- Obtain our VMware Cloud on AWS Solution Brief and TCO 1-pager
- Follow our release notes on continuing updates here: docs.vmware.com/en/VMware-Cloud-on-AWS/0/rn/vmc-on-aws-relnotes.html
- Check out our YouTube channel
- Follow us on Twitter @VMwareCloudAWS and at @VMwarevSAN
- Connect with me on Twitter at @glnsize
Take our vSAN 6.7 Hands-On Lab here, and our vSAN 6.7 Advanced Hands-On Lab here!
