vSphere Tags & Categories: Tips to Use Them the Right Way!
By Rick Vanover, Senior Director of Product Strategy for Veeam Software
Editor’s note: this blogpost was provided by our partners at Veeam Software
Like many vSphere users, we have known about vSphere tags for a long time. I believe they were first introduced in vSphere 5.5 and I love what can be done with them.
This year at the VMUG UserCon series of events; the Veeam team provided content built around automation for the best backup experience for your VMware workloads. vSphere tags are an important part of that presentation.
Consider a tag like a birth certificate
In order for vSphere tags to be used, they have to be present and effectively implemented from the start. One way to accomplish this is to automate vSphere tagging in vRealize Automation when a tag is deployed. This way, one or more tags are present on a VM as it is deployed. This is important as some of the most critical questions (examples shown below) can be answered immediately. This may save guesswork later on, or more importantly, save the risk of having a VM be deleted but in fact contain production data and it is not backed up.
Consider also a tag is part of the solution, categories should be used as well to provide relevant grouping for tags. This is especially important where there may be many answers to a tag and its classification.
Tag production vs. development
This is an easy one to start with and can make sense to most environments. Simply having a tag that indicates is a VM is a production VM versus a development VM can be a huge step forward in identification of the landscape of the VMs in your environment. Considering also the category advice from above, some sample category may be called “Status” and some tag values can be “Production”, or “Development”. It also is possible to implement tags such as “GRC-Production”, “Audit-Production”, “QA” or “PCI-Production”. Each of these examples implement a more specific classification of the VM, such as if it is subject to PCI Audits, or if it is subject to GRC (governance or regulatory compliance) in general. Likewise for different levels of non-production, you can implement very specific descriptions for the tags within a category.
Tag backup levels
At Veeam we have gravitated around the vSphere tag as an outstanding construct for building backup and DR polices. Simply put, consider a vSphere category called “Availability_Level” and inside are a number of tags such as “BU-T1-4H”, “BU-T1-12H”, “BU-T2-24H” and “BU-T3-7D”. This is a bit more abstract but indicates that it is BU (Backup policy) that is for T1 (Tier 1) applications and has a 4H (4 Hour) recovery point objective (RPO). Likewise, for 12 Hours, 24 Hours, 7 Days and Tier 2 and Tier 3. You can also implement the same tag logic for workloads that need disaster recovery (DR) and off-site availability. You can then build backup jobs around these policies in the tags to keep availability levels high and SLA’s met. Here is a figure in vSphere that shows tags like this:
Once these tags are in place, backup jobs can be built right off of them. Here is an example where a Tier1-12Hour policy is made using the vSphere tag:
This can also be done via PowrShell in just a few lines; making accuracy and receptiveness easy.
The nobackup tag
It may seem somewhat controversial, but I also advise to have a tag that indicates a VM is *not* backed up. Much like you would have a tag that says it is not production, not on Tier-1 storage, etc. This can benefit the organization in a number of ways.
The benefits of having an agreed upon no-backup strategy for selected VMs will save time during the backup window as those VMs do not need to process. This will also save storage resources on secondary storage as well as IOPs on primary storage systems. Lastly, this may present legal benefits for some situations.
It is important on this one think it through and get consensus through the organization on if a nobackup tag should be used.
Bad tags and public shaming
Well, maybe shaming is harsh. What I find annoying however is a non-descriptive tag. Tags or categories called “Sampletag”, “catA” “tag1” or “Newtag” are completely useless. The provide no reasonable description of what the tag or category is to be used for. Likewise, tags and categories like “Death_Star”, “Tatooine”, “Jakku” or “Stuff” are likewise useless. No offense to any favorite movie, but it is very possible that one may forget the correlation to the destruction of Tatooine and the fact that this VM is destined for decommissioning. It makes more sense to make a category called “Decommissioning” and tags called “Decomissioning_Pending” and “Decommissioning_Complete.”
What tags can do for you
This is just a start of how you can use vSphere tags, and this is just in regard to application on VMs. Tags can also be applied on datastores. One technique is to tag datastores their relative tier in your organization. This could be a category called “Storage” and tags called “Tier-1”, “Tier-2”, “Tier-3”, “Tier1-With-Array-Snapshots” or more options.
vSphere tags are truly an incredible framework and many services can be built from them. Do you use vSphere tags? How so? Share your comments and vSphere tag use cases below.
About the Author: Rick Vanover
Rick Vanover (Cisco Champion, vExpert) is Senior Director of Product Strategy for Veeam Software. Rick’s IT experience includes system administration and IT management; with virtualization being the central theme of his career recently. Follow Rick on Twitter @RickVanover or @Veeam.
VMUG Office
450 Rev Kelly Smith Way, Nashville, TN 37203
[email protected] +1 312-321-6886