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 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

The following sections provide examples of tagging.

For more information about tags, see Creating tag groups and tags and Assigning a tag to an object.

Example 1 - Identifying the resource to modify when setting option choices

In the following example, consider a group of service blueprints with three tiers: 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 version or by tag. The following example makes the association by tag.

In this example, all server groups in all blueprints for which you want to use the option can have different names. By applying a tag called Middleware Servers (from the tag group called Server Group) to the option definition and the appropriate server group in the service blueprints, you are instructing BMC Cloud Lifecyle Management to apply the option to a server group tagged with the same tag group and tag in the service blueprint.

1. Create a tag group named Server Group.
2. Populate the Server Group tag group with identifying tags such as DB Servers, Middleware Servers, and Web Servers. 
3. Tag each server group in the service blueprint with the appropriate tag, such as Middleware Servers.
4. When editing options, use the Server Group 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:

1. Create a tag group named Location with three tags: US, France, and Singapore.
   You can create the tag group and tags from any interface that is described in Creating tag groups and tags.
2. 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.
3. In the Resources workspace, add the appropriate Location tag to the US, France, and Singapore network containers.
4. Depending on how a service should be deployed, take one of the following actions:
   
   • If the same definition (defined within the service blueprint) 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 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 used to 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 create a 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.

1. Create the following tag groups and tags:

   Tag group	Tags
   Compute SLA	Gold Silver Bronze
   Networks	Management Customer
   Storage	Gold Silver Bronze

2. 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.

3. Assign the tag groups to compute pools, virtual disk repository pools, and networks in network containers.

4. Create a three-tier service blueprint and tag it as follows:
   

   Tier	Component	Tag group	Tag	Comments
   Web	Server group	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	Server group	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	Server group	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.

Related topic

Policy management overview