Tagging recommendations and examples
This topic provides examples for creating and assigning tags and tag groups to determine the placement of user-requested services within the cloud.
You can use tags and tag groups:
- To identify a specific resources to modify. For example, you may want to change the number of CPUs for your application but not for web or database servers. See Example 1.
- To place a service on the appropriate infrastructure. For example, VMs should be provisioned to a specific data center. See Example 2.
- For documentation purposes (not discussed in this topic)
Example 1 - Identifying the resource to modify when setting option choices
In the following example, consider a group of service blueprints with three tiers, or resource sets: web, application server, and database. You have the capability to change the number of CPUs on the servers in all three tiers, but you only want to change CPUs on the application tier, not the web or database tiers.
When defining a service catalog, you can use the Options editor to identify the service blueprint components to which an option applies. You can make this association by blueprint component name or by tag. Because same option can apply to many different service blueprints, making the association by blueprint component name may be too restrictive. The following example makes the association by tag rather than component name.
In this example, all application tier resource sets in all blueprints for which you want to use the option can have different names. By applying a tag called Middleware Servers (in the Resource Set tag group) to both the option definition and the appropriate resource set in the service blueprints, you are instructing BMC Cloud Lifecyle Management to apply the option to a resource set tagged with the same tag group and tag in the service blueprint.
- Create a tag group named Resource Sets.
- Populate the Resource Sets tag group with identifying tags such as DB Servers, Middleware Servers, and Web Servers.
- Tag each resource set with the appropriate tag, such as Middleware Servers.
- When editing options, use the Resource Set tags to select the blueprint component for which you want to modify the number of CPUs.
Example 2 - Segregating services by hosting environment
In this example, consider three data data centers, one in the U.S., one in France, and one in Singapore. A network container is defined for each data center. To determine the data center where a service is placed, take the following steps:
- Create a tag group named "Location" with three tags: "US," "France," and "Singapore."
- In the Service Governor workspace, add a network container policy. For the policy, the Tag Source should be Service Blueprint and the Tag Group should be the Location tag group you created in the previous step.
- In the Resources workspace, add the appropriate Location tag to the U.S., France, and Singapore network containers
- Depending on how a service should be deployed, take one of the following actions:
- If the same service deployment definition should always be deployed to the same data center, use the service blueprint editor to add the appropriate tag from the Location tag group to that service deployment definition.
- If the requester of a service can choose the data center where a service is deployed, use the Service Catalog workspace to modify the service by adding an option and option choices that correspond to the three data center locations. When configuring the option choices, use the Option Choice Blueprint Configuration Editor to choose service deployment definition as the scope of each option. For each option choice, select the Location tag group and the appropriate tag. With a configuration like this, a service requester can select a location option, and BMC Cloud Lifecycle Management adds the appropriate tag to the service deployment definition when processing the service request.
This example describes how to provision infrastructure for a particular data center, but a similar approach can also be use segregate service offerings by business function, such as for sales, HR, development, or QA. This approach could also be used to provision infrastructure by service life cycle, such as for production or pre-production.
Example 3 - Customizing use of compute pools and storage pools
Using the example described above, you can extend its functionality to createa set of choices that can be used to satisfy a service level agreement (SLA). In this example, the SLA calls for three levels of service: Gold, Silver, and Bronze.
Using tags and policies, you can specify which compute and storage capabilities are sufficient to satisfy the SLA across a three-tiered architecture.
Create the following tag groups and tags:
Tag group Tags Compute SLA Gold
Using the Service Governor workspace, create policies as follows.
Policy type Tag Source Tag Group Compute pools Service Blueprint Compute SLA Network Service Blueprint Networks Virtual Disk Repository Pool Service Blueprint Storage
Defining policies in this way instructs BMC Cloud Lifecycle Management to look in the service blueprint for the specified tag group (using the search order described here). If BMC Cloud Lifecycle Management finds the tag group, the system matches tags from the tag group in the service blueprint to tags on the resource—in this case, the compute pool, virtual disk repository pool, and network resources.
- Assign the tag groups to compute pools, virtual disk repository pools, and networks in network containers.
Create a three-tier service blueprint and tag it as follows:
Tier Component Tag group Tag Comments Web Resource set Compute SLA Bronze The compute resources needed for the web tier never need to be more than what is available for the bronze compute pool Additional disk Storage Bronze Low disk I/O means bronze storage is sufficient NIC 0 Network Management NIC 1 Network Customer Application Resource set Compute SLA Silver Additional disk Storage Bronze Pools for compute and storage do not have to be the same NIC 0 Network Management NIC 1 Network Customer Database Resource set Compute SLA Gold Additional disk Storage Gold Faster I/O of gold-level storage is required NIC 0 Network Management NIC 1 Network Customer
When a service blueprint is tagged differently at different levels, the tag at the more specific level of the service blueprint is used during policy evaluation. For more information, see Service blueprint tag selections in policies.