vROPS & vSAN – Per SP capacity usage reporting dashboard – Part 1
Recently I was asked by a customer to provide more insight on vSAN storage policy reporting questions. To be more specific, my customer wanted to know how much space was consumed by each storage profile on their (stretched) vSAN cluster. The cluster was getting rather full and they wanted to see if and how they could get back some of those expensive bytes. Challenge accepted, while building I decided to dedicate a blog post to this and due to the length of the post, I decided to split it up in 2 parts:
Part 1 – Describe the use case and prepare vSphere Tags
- Identify use case
- Verify existence of functionality in vROPS
- Prepare Tags in vSphere
Part 2 – vRealize Operations preparation (Custom groups / Super metrics and dashboard)
- Create custom group containing the different storage policies
- Prepare super metrics to calculate vSAN consumed space per policy for VM’s
- Create dashboard to represent the data in a visible way
- Conclusion
Since a couple of versions (I believe this was introduced in 6.7u2), the build in dashboard in the vCenter UI will give you quite some information about storage usage and there’s even an option to see the amount of storage you might win or lose when changing the storage policy to a different one. Unfortunately, this will only show the amount when all the objects’ policies are changed to the selected policy.
My first idea now was to just go and log into vROPS as there should be a dashboard available out of the box, right? Well, not really.… So, what about building one yourself then? To give my vROPS skills a boost I decided to accept that challenge just to find out after a few minutes that there are no SPBM properties attached to your virtual machines so no out-of-the-box-click-o-magic dashboard unfortunately ☹.
Ok, so next question (or more a workaround really) : How do we attach something to the VM that tells us about its storage policy? Obviously, we can abuse tags for this purpose! Tags can be easily assigned to a virtual machine and can be used in vROPS to create custom groups which we will use later. This introduced a bit of a sidestep as I had to look how I could connect the 2 together in an automated way because we don’t want to tag hundreds of VM’s by hand. To accomplish this, I created a small and easy PowerShell script that gets the storage policies from a vCenter Server and then gets the virtual machines in this policy. Now that we have the two of them together, we need to assign the tags in vCenter.
I would advise to think of some descent naming for the tags to prevent you from interfering with any tags that might already exist in the system. In my example I created a separate tagging category: SPBM_Tags and used SPBM_<StoragePolicy_Name> as the name for the tags.
Once the GUI stuff has been done, we can create the PowerShell script. The script will remove existing tag assignments with the SPBM prefix to ensure that VM’s who’s storage policy has changed are not reflected correctly later on in vROPS. Then it will assign (or re-assign) the correct tag. I will update the script at a later stage to skip re-assigning tags where the policy and tagname already match and will post a short update on the script at that moment.
#Connect to target vCenter Appliance
Connect-VIServer <vCenter Server FQDN or IP>
#Get storage policies in the target vCenter and display on screen mssg
$storagepolicies = Get-SpbmStoragePolicy
Write-Host "Storage Policies found: " $storagepolicies -ForegroundColor Yellow
#Get storage policy and VM's assigned this policy and (re)set the vSphere tag corresponding with this policy
foreach ($storagepolicy in $storagepolicies){
$vms = Get-SpbmStoragePolicy | Where {$_.Name -like $storagepolicy} | Get-VM
write-host "VMs found in " + $storagepolicy.Name " policy: " $vms -ForegroundColor Yellow
$tagname = “SPBM” + $storagepolicy.Name
write-host "Tagname for this policy will be:" $tagname -ForegroundColor Yellow
foreach ($vm in $vms){
Get-TagAssignment -Entity $vm | where{$_.Tag.Name -like "SPBM*"} | Remove-TagAssignment -Confirm:$false
New-TagAssignment -Entity $vm -Tag $tagname
}
}
I am aware that there are some flaws in this mechanism. For example: It will be impossible to correctly tag VM’s with a per disk storage policy assigned to them (For example a DB server with OS disk on R5 and DB/Logs on R1 policy). For my use case however, this was enough. The script can be scheduled to run at certain times (the more frequent it runs, the more accurate the data will be), to keep the information up to date.
Now that the tags are all set, we can go back to vROPS and see if we can utilize what we did earlier and put it in a nice dashboard. This will be further described in part-2 of this post.