vSphere Storage Policy Based Management Overview (part 2)

Welcome to part 2 of the vSphere Storage Policy Based Management Overview. In our previous article, we looked at challenges with traditional storage provisioning models, the advantages of the Software-Defined Storage model, as well as an introduction and background to VMware vSphere Storage Policy Based Management. If you have not yet had opportunity to read it, it might be beneficial to glance through before continuing on.

In today’s article, we will be carrying on with the vSphere Storage Policy Based Management (SPBM) theme as we look to understand the components of the vSphere Storage Policy. Afterwards we will display a few policy examples for single VM provisioning and options for a collection of VMs as well.

Storage Policy Components

Virtual machine storage policies, are an evolution of virtual machine storage profiles, and used to ensure that virtual machines are placed on storage that guarantees a specific level of capacity, performance, availability, redundancy, and so on.

When you define a storage policy, you specify storage requirements for applications that would run on virtual machines. After you apply this storage policy to a virtual machine, the virtual machine is placed to a specific datastore that can satisfy the storage requirements.

vSphere Storage policies are made up of three primary components:

• References to storage provider’s storage capabilities
• Rules [Key value pair: Storage Capability + (Value for Quantity or Quality)]
• Rule Sets

Storage Capabilities

When you define a virtual machine storage policy you can reference two types of storage capabilities: user-defined metadata tags and vendor specific storage capabilities. A user-defined metadata tag is an optional user-defined tag that can be assigned to a datastore to allow storage policies to be created with additional criteria than over and above what the storage array’s storage provider service publishes. Vendor specific storage capabilities outline the quality of service that a storage system can deliver. There can also be capabilities provided by vSphere that are common to all datastores.

The list of storage capabilities that a storage array can deliver is published by the storage array’s storage provider service. Storage providers represent storage systems using vStorage APIs for Storage Awareness (VASA), also called VASA. Storage providers inform vCenter Server about specific storage devices, and present characteristics of the devices and datastores deployed on the devices as storage capabilities. These storage capabilities are system-defined and vendor specific.

The table below contains a list of capabilities that the Virtual SAN Storage Provider makes available for policy consumption:

Rules

A storage policy Rule references a combination of a single vendor-specific, user-defined metadata tag and a related value indicating the quality or quantity of the capability that is desired. These two items act as a key and a value that when referenced together through a Rule, become a condition that must be met for compliance.

For example, the Virtual SAN storage provider publishes 5 capabilities, one of which is the capability to set the “Number of failures to tolerate”. This capability is used to define the number of host, disk, or network failures a virtual machine object can tolerate. The minimum value for the FTT capability is 0, the default value is 1, and the maximum value is 3.

We could create a rule that references the “Number of failures to tolerate” capability, with for instance, a value of “2”. This Rule would require that for any value that is supplied for this capability, the result will be a storage policy that when applied to a VM, will look for a vsanDatastore that can support n+1 copies of the virtual machine object and 2n+1 hosts with storage are required.

After reviewing the published storage capabilities and deciding upon which capabilities and values you require in your storage policy, the next step is to group these rules into a Rule Set that will then be referenced in the storage policy. If you are using the vSphere Web Client, the VM Storage Policies section provides a great wizard that will walk you through the process.

Rule Sets

A Rule Set is comprised of one or more Rules. One Rule Set can include one or more rules but only from a single storage provider.

A storage policy includes one or more Rule Sets that describe requirements for virtual machine storage resources. Multiple Rule Sets can be leveraged to allow a single storage policy to define alternative selection parameters, even from several storage providers.

In the section of above titled Vendor Specific Storage Capabilities, we see that Virtual SAN provides 5 storage capabilities. Each storage capability contains a default value, a minimum value, and a maximum value.

Let us continue our example from the previous section and create a Rule Set referencing Virtual SAN capabilities along with the “Numbers of failures to tolerate” Rule that we decided upon earlier. We can choose any combination of Virtual SAN capabilities for our policy.

Example Virtual SAN Rule Set:

This Rule Set contains two rules and is now designed to target a Virtual SAN datastore that has the capacity to create 3 replicas of the virtual machine object with each replica existing on a minimum of 2 disks.

Putting it all together

In this next section we will combine what we have learned about vSphere Storage Policy Based Management (SPBM) and create vSphere Storage Policies that reflect real-world application provisioning scenarios.

Provisioning Scenario

We can use a common provisioning scenario involving a Windows VM that is running an intensive 700GB database backed by an all-flash array. The operating system and user data have been separated onto their own individual VMDKs as per VMware’s recommended practice.

This image to the right displays the traditional provisioning approach with both VMDKs housed by the same datastore. This approach is fully functional and we have provisioned this way for years. Could we do better though?

In our example, it is only our database that is requiring the extra performance from the all-flash array. In comparison to our database, the operating system’s workload is very minor and would operate well within our performance SLAs on spinning disk. If we could relocate our operating system to a spinning disk tier, while leaving the database on the all-flash datastore, we would be able to reclaim 100GB of SSD capacity. That is great incentive to examine the rest of the environment for similar opportunities for optimization.

Operational Impact

Detaching and manually moving VMDKs to different datastores for potentially thousands or tens of thousands of VMs would be so much of a painstaking exercise that it would likely deter the majority of administrators from pursuing it as an optimization option. For the scripters and developers out there, you could certainly leverage VMware’s robust APIs to build a series of scripts that would perform these actions for you. What of those who do not have access to either the time or skillset required to accomplish this on their own?

Storage Policy Configuration

vSphere Storage Policy Based Management (SPBM), presents a quick and easy method to automate the placement of VMDKs by defining virtual machine storage requirements in the form of a storage policy. With SPBM, when a virtual machine is created, the storage policy is used to automate the selection of datastore(s) that fulfills the requirements listed within the storage policy.

The image to the left details two storage policies referencing the capabilities from two different storage arrays. The Mission Critical policy (Gold) references capabilities provided by a vSphere Virtual Volume enabled all-flash array. The Business Priority policy (Silver) references capabilities from a Virtual SAN datastore.

Storage Policy Application

Rather than applying the Mission Critical (Gold) policy to our entire example virtual machine, we can actually achieve better application and storage alignment by assigning two separate policies to each of the VM’s individual VMDKs. We will apply our Mission Critical (Gold) policy to the database VMDK, and we will apply the Business Priority (Silver) policy to the VM’s operating system. The SPBM service will then identify which datastores are compatible and instruct the provisioning process to place the VM’s operating system VMDK onto the Virtual SAN datastore and the database VMDK onto the all-flash datastore.

With vSphere Storage Policy Based Management (SPBM), these two policies now take minutes to create and can be applied to any number of new or existing VMs. This is in stark contrast to the hours, days, or weeks that it would take to create and debug scripts to accomplish the automated provisioning for us. Creating a full strategy of provisioning scripts to support an entire global enterprise environment could easily take years to follow the full development lifecycle. Afterwards there would still remain a need for the ongoing support and maintenance of the scripts.

We truly have entered the era of the Software-Defined Data Center and we can see very quickly the advantages in leveraging vSphere Storage Policy Based Management (SPBM). vSphere Storage Policy Based Management (SPBM) provides an integral, low-touch, VM-centric alternative for VM storage provisioning, placement, and ongoing storage SLA management for virtual machines in your vSphere virtual infrastructure.

For more information on the Software-Defined Data Center, Software-Defined Storage, and Storage Policy Based Management, check out the resources section below.

Resources

vSphere Storage Policy Based Management Overview (part 1)

The VMware Perspective on Software-Defined Storage

 Understanding the DNA of Software Defined Storage

Software-Defined Data Center and how VMware’s technology enables IT transformation

Video Training – VMware vSphere: Storage Profiles

Storage Policy Based Management (SPBM) Configuration Maximums (2062751)

VMware VVOLs blog content