This article, which details the recommended scale-up process for the application tier of a service instance with Orchestrator to automate the provisioning of additional capacity based on an alert in System Center 2012 Operations Manager (SCOM), is a supplemental post to the Veeam whitepaper “Automate Management of your Hyper-V Environment: Next Level Integration of System Center and Veeam Management Pack v7”, available at http://veeam.com/.
Before we get started, there are a couple of assumptions I am making:
- You have read the Veeam whitepaper
- You are familiar with Orchestrator and Orchestrator integration with other System Center 2012 components, most importantly SCOM and SCSM
- You have administrator access to a System Center environment, including:
- SCOM (with the Veeam v7 MP for Hyper-V deployed
- Orchestrator (with the SCOM and SCSM Integration Packs deployed)
If you are all good on the points above, read on!
In this post
This post is going to focus on creation of the Scale Up runbook described in the Veeam whitepaper. If you have not yet read the whitepaper, click the link above and give it a read so you have appropriate context for the situation.
High-level Process and Runbook Design
While scaling out a machine tier within a service is often a fully automated activity for presentation tier components behind NLB or hardware load balancers, scaling up is often more complex, as adding additional CPU and memory to a VM is frequently a disruptive process, and how much additional capacity to add is generally subjective. In this situation, the best automation approach is often to automate the documentation from alert up to the step where human intervention is needed.
The high level process is shown in figure 1 below.
Figure 1. High-level process for scale up in a service
This process translates into the following Orchestrator runbook, shown in figure 2.
Figure 2. Orchestrator runbook to support scale up within a service instance
With the high level process and runbook design details in hand, lets shift focus to the details of runbook configuration.
The following outlines the configuration of the activities within the runbook.
The fields you should configure in this activity are:
- Name: Alert name, should be configured to match on “Alert Name” contains “Veeam”
- IsMonitorAlert: should be set to true.
- NetBiosComputerName: Should be configured to match the naming convention of your application or database tier servers…those tiers that cannot scale out, and so must be scaled up.
Find Veeam Alerts
This renamed Map Published Data activity is meant to filter out the Veeam alerts for:
- for CPU and memory utilization
- for only the VMs in the application or data tier (depending on your scenario)
The objective of this activity is to map the contents of the alert to the appropriate text to populate the incident and change fields when they are created. In the properties of the activity, you click the Add button to open the Add Mapping dialogue, where you can insert
- Source data: Alert name from Monitor Alert
- Pattern: What alert name we are looking for
- Map To: Type the new text that replaces the text of those items that match Pattern. This is the data that will be inserted into the incident and / or change request.
TIP: You can add entries to map as many different alerts from the Veeam MP as you like, along with properties of the various fields in the SCOM alert, enabling automatic creation of very descriptive incidents and changes, providing detailed information to assist subject-matter experts in making good decisions when adding compute resources to affected systems.
This renamed Create Incident with Template is the activity that will create the incident based on alerts identified as relevant to our scenario. Exactly how you format the incident is up to you, based on the template you provide. However, using published data from the Monitor Alert and Map Published Data activities, you can automatically populate a variety of incident fields with context-specific information.
This renamed Change Incident with Template is the activity that will create the change request based on incidents created in our scenario. As with the Create Incident activity, exactly how you format the change request is up to you, based on the template you provide.
To support ITIL best practices, we want to create a change request as a record of the changes that will be made to address the issue logged in the incident from the monitoring alert.
This activity is used to create a relationship between two existing entities, in this case, tying together the incident and the related change request to record the corrective action. To configure the Create Relationship activity, set the following fields as described below:
- Source Class: Change
- Source Object GUID: System Center Object GUID from Create Change activity (published data)
- Target Class: Incident
- Target Object GUID: System Center Object GUID from Create Incident activity (published data)
This small, but important action ties the end-to-end process together from an ITIL perspective, providg full visibility from inception to remediation.
Conclusion and Next Steps
I hope you have found both the whitepaper and this supplemental post informative. If you have not already, I encourage you to download “Automate Management of your Hyper-V Environment: Next Level Integration of System Center and Veeam Management Pack v7”, available at http://veeam.com/.