Notes from the Field–vSAN SBPM Tags and VR/SRM

VSAN_AcceptedSome of my favorite posts to write and put together are for the “Notes from the Field” titles/classifications. The reason being is these posts come from my experiences with clients to help solve a business requirement or design challenge that I am sure others have been or are faced with. This time around I am working with a customer on their Business Continuity/Disaster Recovery (BC/DR) initiative. Always a fun a topic!

High Level Architecture

The customer I have been working with is already down the path of HCI and specifically with vSAN ROBO edition for some of their remote locations. When they were looking for both a primary storage uplift at their production site as well as encompassing a disaster recovery strategy, looking to vSAN was an easy choice. For the replication or “data mover” task, vSphere Replication will be leveraged tied with Site Recovery Manager (SRM) for the orchestration engine.









While I won’t get into the speeds and feeds numbers or the overall amount of usable storage, some of the key elements to the design was availability of the workloads at the production site and a cost efficient cluster as the DR location. To accomplish the availability requirement at the production facility a Storage Policy was created setting the Failures to Tolerate to two (FTT=2) and the Failure Tolerance Method of RAID-1 (FTM=R1 Mirroring).

With an FTT=2  a primary copy of the virtual machine data is created and two replica copies of data are created with each copy residing on a separate host. A fourth object is created, the witness, and placed on an individual host as well:







For the second requirement, we did something a bit different a DR. We wanted to take advantage of not only the data reduction services that vSAN offers in All Flash configurations (deduplication/compression), but also the ability to leverage RAID-5 as the FTM method to provide even more space savings. Compared to a traditional FTT=1, leveraging RAID-5/erasure coding provides a 33% reduction in storage overhead. Even more so in our scenario as we are leveraging FTT=2 to provide a higher level of availability at the cost needing additional storage capacity. Notice we are no longer dealing with Primary/Replica copies of data, but striped copies of data with parity:







vSAN, vSphere Replication, and SPBM Tags

Ok, bit of a long read to get to this point of the post but I wanted to properly set the table for what we needed to accomplish. For those that are familiar with vSAN and Storage Policy Based Management (SPBM) you know that you assign a “Default Datastore” policy to vSAN and as needed you can get more granular by creating and assigning additional policy to assign at the VM or even the per VMDK level if you want.

So the rub for our scenario is we want to have two different policies in play based on where the virtual machine actual lands and is running. We either want a policy around FTT=2 with Mirroring (Production) or an FTT=1 with RAID-5/erasure coding (DR). There a few ways to accomplish this, but for this use case we were going to use SPBM Tags. Using these tags we will be able to set the storage policy for anything that is being transferred via vSphere Replication. To accomplish this:

  • Log into your vSphere Web Client with an Administrative account
  • From the Home screen Click the VM Storage Policies icon:










  • In the Right Hand pane under the VM Storage Policies tab Click on Create VM Storage Policy:










  • With the Create New VM Storage Policy wizard launched Select the DR/Inbound vCenter Server (DR-VC01 in my example) and provide a Name and Description of the policy. Click Next to continue:











  • Review the Policy Structure screen and Click Next to continue:











  • For this example we will not be leveraging the Common Rules for Data Services Provided by Hosts. Click Next to continue:











  • For the Rule-Set screen we have a lot going on. First, Select the box for Use rule-sets in the storage policy. From here I selected the following options for this policy:
      • Storage Type = VSAN
      • Number of disk stripes per object = 1
      • Flash read cache reservation = 0
      • Fault Tolerance Method – RAID-5/6 (Erasure Coding)
      • And key to what we are trying to accomplish, Tags from category = vSphere Replication











  • With the Tag from category added and set to vSphere Replication, Click the Add Tags button:











  • The Add Tags dialog will be displayed, Select the option for com.vmware.vr.HasVrDisks. Click OK to continue:












  • With our Rule-Set in place, Click Next to continue:












  • From the Storage Compatibility screen, make sure your vSAN Datastore is listed and Click Next to continue:












  • Finally, on the Ready to Complete screen review the settings and Click Finish to continue:











And with that, we have our storage policy created:






Putting the Policy and Tag to Work

With the hard part done and the through the magic of the internet the following screen shots provide the desired output we where looking for. The first screen shot provides the Virtual Object details for my test virtual machine, DR-SRM01. As you will see the virtual machine is leveraging the Virtual SAN Default Storage Policy configuration of an FTT=1 (Mirror):










Looking good so far. Next up was configuring vSphere Replication on the DR-SRM01 virtual machine to replicate the needed data from my primary site to the secondary site. With the SBPM in place leveraging a tag for vSphere Replication I could do the “Next..Next..Finish” of the replication job, but know that I would be using my space efficient policy. Again taking a look at the Virtual Object details of the virtual machine I see that my policy using tags is working as expected:










Wrapping it Up

The obvious goal of any HCI platform is ease the operation burden/overhead for the day to day administrator. VMware has a done decent job of getting the word out around SBPM and the granularity it provides to a given workload down to individual VMDK settings. Leveraging Tags in your SBPM policies allows you to group these workloads for a one to many management.

Thanks for reading!


%d bloggers like this: