The use of naming conventions in the data center can play an important part in operational efficiency. Naming conventions are most often used for devices such as hosts and switches, along with other entities such as VMs, virtual switches, and Microsoft Group Policy Objects. Choosing a consistent approach to naming can reduce time for change requests, and minimize operational mistakes as an environment grows.
Determining the right approach for naming is often an exercise in tradeoffs. Overly simplistic standards can result in ad-hoc naming that lacks consistency. Overly complex standards often fail because governance becomes too difficult. The ideal naming convention is one that addresses the needs of the organization, is descriptive and flexible, all while maintaining simplicity.
How naming conventions can help with storage policies
Storage Policy Based Management (SPBM) can also benefit from naming conventions. When used with vSAN or vVols, the SPBM framework takes what used to be all-or-nothing settings defined on external storage, and allows the administrator to assign storage policies to individual VMs. The administrator can easily specify performance, availability, and space efficiency settings on a per VM, or even per VMDK basis to accommodate application requirements. Policies can be named in whatever way that suites an organization best.
Depending on the need, an environment may require just a few storage policies, or dozens. Before deciding on an approach that works best for your organization, let’s review a few characteristics of storage policies with SPBM.
- A maximum of 1024 SPBM policies can exist per vCenter server.
- A storage policy is stored and managed per vCenter server, but can be applied to VMs in one or more clusters.
- A storage policy can define one or many rules around performance, availability, space efficiency, etc.
- Storage policies are not additive. Only one policy (that contains one or more policy rules) can be applied per object.
- A storage policy can be applied to a group of VMs, a single VM, or even a single VMDK within a VM.
- A storage policy name can consist of up to 80 characters.
- A storage policy name is not the true identifier. Storage policies use a unique identifier for system management.
With a high level of flexibility, users are often faced with the decision of how best to name policies, and apply them to their environments.
Balancing descriptiveness and simplicity
Policy names are most effective when they include two descriptors: intention, and scope.
- Intention refers to what the policy aims to achieve. Perhaps the goal of the policy is to apply high performing mirroring using a Failure Tolerance Method (FTM) of RAID-1, with an increased level of protection by using a Level of Failures to Tolerate (FTT) of 2.
- Scope refers to where the policy will be applied. Maybe a policy is for a farm of servers hosting the company ERP solution. or perhaps it is for just the respective VMDKs holding databases in a specific vSAN cluster.
To improve readability of policy names, you may wish to associate specific terms to a policy to indicate their settings. For instance, “BasicProtect” may be associated with all policies using an FTT of 1, while “EnhancedProtect” might be associated with all policies using an FTT of 2. This type of approach can also be used for Performance (“EnhancedPerf” associated with RAID-1 and a stripe width of 4) along with capacity consumption (“SpaceEfficient” associated with RAID-5/6). The naming flexibility lets you decided on how much technical detail you wish to expose in the name to administrators, application owners, or automation teams interacting with policies.
Determining the realistic needs of the organization is an important step in finding the best storage policy naming conventions for an environment. A few questions to ask yourself might include:
- What is the size of the environment?
- Are there multiple clusters? If so, how many?
- Are there stretched clusters?
- Is there a preference to indicate actual performance/protection settings within names, or adopt a gold/silver/bronze approach?
- Is there a need for application specific storage policies?
- Is there a need for VMDK specific storage policies?
- What type of delimiter will work best? Spaces? Hyphens? Periods? What will work best in conjunction with scripting?
- Are there specific departments, or business units that need representation in a storage policy name?
- Who is the intended audience? Virtualization Administrators? Application Owners? Automation teams? This can have an impact on the level of detail you wish to provide in a policy name.
- The answer to these questions will help determine how you might want to name storage policies, and the level of sophistication to a naming convention used.
Examples
The following examples show how different approaches can be used to simplify the management of storage policies. These are only examples. Storage policy names can be as simple or descriptive as you wish them to be. The flexibility of storage policies allows you to decide how best to apply them for your conditions. The intention with these examples are to inspire a way for you to name storage policies that suites your organization best.
Example 1: The example below shows a storage policy that could be used for a collection of general purpose workloads. One can optionally provide additional setting indicators of the policy for readability. Specifying a cluster name is optional, but might be helpful for environments that have multiple clusters, or stretched cluster environments that will be best served by dedicated policies.
Naming structure:
[ClusterName]-[Workloads]-[IntentionofPolicy]-[OptionalSettingIndicators]
Functional examples:
Cluster01-ManagementVMs-BasicProtectionEnhancedPerf
MultiCluster-ProductionVMs-BasicProtectionEnhancedPerf
MultiCluster-ProductionVMs
Example 2: The example below shows a storage policy that could be used for application specific workloads. They could be assigned to one or more VMs that provide the services of the application. This type of approach would be most appropriate for environments with targeted performance and protection SLAs that could not be met by a general policy as shown in Example 1.
Naming structure:
[ApplicationName]-[IntentionofPolicy]-[OptionalSettingIndicators]
Functional examples:
App-SharePointWebFarm-BasicProtectionSpaceEfficient
App-SharePointSQLBackEnd-EnhancedProtectionEnhancedPerf
App-VDIPoolX-BasicProtectionEnhancedPerf
App-VDIPoolX
Example 3: The example below shows a storage policy to define performance and protection settings for a department, business unit, or predefined service tier.
Naming structure:
[Department]-[IntentionofPolicy]-[OptionalSettingIndicators]
Functional examples:
Group-DevelopomentCodeCompling-BasicProtect-UltraHighPerf
Group-CustomerX-BasicProtectionSpaceEfficient-ValueTier
Group-CustomerX
Example 4: The example below shows a storage policy that could be used for performance characteristics of a targeted VMDK type, in a single VM, or multiple VMs. In this case, the policy rules will limit the number of IOPS for all VMDKs using this policy so that they do not interfere with the performance of other VMs (the noisy neighbor phenomenon).
Naming structure:
[ApplicationorWorkloadName(s)]-[IntentionofPolicy]-[OptionalSettingIndicators]
Functional examples:
App-LogAnalyticsCollectorVMDKs-1500IOPSCap
App-LogIndexingVMDKs-1000IOPSCap
App-LogIndexing
In Figure 1, we see how the examples above look when viewed in vCenter. The examples represent policies that are applied across large collections of VMs, specific departments with an organization, as well as targeted applications. Naming standards make them easier to understand and manage.
Figure 1. Example policies added in vCenter
More policies could easily be created that address requirements such as site affinity, or workloads with application redundancy. You may also find the “vSAN Storage Policy Example Creation” script created by Jared Lutgen on code.vmware.com helpful.
Other Tips
Here are a few other operational tips related to storage policies.
- Do not attempt perfection of a naming standard. Try what works, and adjust as necessary. There is no right or wrong way to name policies.
- Avoid using and changing the “vSAN Default Storage Policy.” Create and clone storage policies as needed.
- Use the “Description” field in a storage policy. This is a great way to define what the intention and scope of a policy is for, and assist in self-documentation efforts.
- Find the right balance of descriptiveness in a policy name. Short names are easy to consume, but may not be descriptive enough. Naming conventions that are too cryptic often do a good job of keeping the name length to a minimum, but do little to help the user. Be mindful that a policy name is limited to 80 characters.
- Move VMs to another policy instead of changing existing policy rules. Changing existing policy rules can introduce a large amount of resynchronization traffic, and immediately applies to all VMs using that policy. Some settings like a change in the FTM, or stripe width can generate a lot of data movement. By moving VMs to a new policy, resynchronization traffic will be limited to those VMs that are assigned a new policy.
- Unsure of what you need? Start with generic storage policies, then add application specific policies as needed. This is a way to achieve a mix of policies that can address groups of VMs with undetermined storage requirements, while adding custom policies intended for a single application, or the collection of VMs that make up an application.
Conclusion
As data centers continue to move toward a more elastic, software defined model, control of that infrastructure will be through policy engines like SPBM for vSAN and vVols, as well as what is found in solutions like NSX. An administrator has tremendous flexibility in determining what policies are applied, where they are applied, and how they are named. Having an approach to naming conventions for policies that drive the infrastructure will allow you to make changes to your environment with confidence.
