With runbook automation you can automate complicated workflows. Runbooks represent a set of procedures that a server administrator performs on a regular basis. Originally, runbooks were actual physical books. These books contained documentation that described to the server administrator how to perform specific procedures. Today runbooks are software parts that, when triggered, actually perform the procedures with little or minimal direct input from the server administrator. Runbook automation is important in Microsoft private cloud environments because it allows you to automate complex tasks. The System Center product that you use to create runbook automation is System Center 2012 R2 Orchestrator.
Orchestrator
Unlike Windows PowerShell, which requires you to write scripts using an editor like Windows PowerShell ISE, Orchestrator allows you to build automation using a drag and drop interface called the Runbook Designer. Orchestrator can still call Windows PowerShell scripts, but it also integrates with many other products, including products within the System Center suite through integration packs. An integration pack is a collection of product-specific tasks that you can trigger through Orchestrator. You can download integration packs from the Internet, import them using the System Center 2012 R2 Orchestrator Deployment Manager as shown in Figure 1, and then deploy them to your runbook servers.
FIGURE 1 Orchestrator integration packs
An Orchestrator deployment consists of the following parts:
- Management server This server manages the runbook servers. You use the management server to distribute integration packs to runbook servers and runbook designers. The management server also manages communication between the runbook designers, runbook servers, and the orchestration database. There is only one management server in an Orchestrator deployment
- Runbook server This server runs Orchestrator runbooks. Each runbook server can run up to 50 runbooks concurrently. You can alter this number using the Runbook Server Runbook Throttling tools, but should monitor the runbook server’s resource requirements. You can have multiple runbook servers in an Orchestrator deployment, with no maximum limit to the number of runbook servers specified in the Orchestrator documentation.
- Runbook Designer This designer allows you to build and test runbooks. The interface allows you to build runbooks by dragging and connecting activities that are available in integration packs. The Runbook Designer is shown in Figure 2.
FIGURE 2 Runbook Designer
- Orchestration database Hosted on a Microsoft SQL Server instance, the orchestration database stores configuration data, policies, and log information.
- Orchestration console A web interface that users can use to list, control, and view runbooks.
- Orchestrator Web Service This web service allows custom applications, third-party tools, and other System Center items such as Service Manager, to connect to Orchestrator and to interact with runbooks.
- Deployment Manager The Deployment Manager allows you to deploy integration packs, Runbook Designers, and runbook servers. You use the Deployment Manager to import and deploy integration packs that you’ve downloaded from the Internet.
Runbooks
Runbooks are collections of linked activities that perform a procedure. You build runbooks in Orchestrator by dragging activities from integration packs to the designer workspace. For example, the runbook shown in Figure 3 uses two activities. The first activity, named Monitor Service, checks the state of a specific service on a specific computer and triggers if the service is in a specific state (started, stopped, or paused). The second activity, named Start/Stop Service, allows you to start, stop, pause, or restart a service. When the runbook is deployed, it will be triggered when the monitored service is in the state specified in the Monitor Service activity. After being triggered, the runbook will perform the task defined in the Start/Stop Service activity.
FIGURE 3 Simple runbook
This example is very basic. When creating Orchestrator runbooks to perform sophisticated automation tasks, you are likely to use multiple activities and include conditional branches, loops, and error handling tasks. Each integration pack that you import into Orchestrator increases the number of activities that you can include in your runbooks.
Keep the following in mind when creating Orchestrator runbooks:
- Provide meaningful names for activities. You can rename activities after you drag them to the designer workspace. By renaming activities with descriptive names, then you can quickly understand what tasks a runbook is designed to accomplish. For example, with the runbook in the example above, you might rename the Monitor Service activity “Is the VMM Service Stopped” and the Start/Stop Service activity “Start the VMM Service.”
- Minimize the number of activities that are performed in a runbook. You can call runbooks from within runbooks. This modular approach to creating runbooks will simplify the process of troubleshooting them.
- Configure runbooks to write logs to external files rather than to the orchestration database.
Orchestrator runbooks run according to configured schedules. You create each run separately, and then assign the schedule to the runbook. You create runbook schedules in the Schedules node, under Global Settings, in the Runbook Designer as shown in Figure 4. Creating a runbook schedule involves assigning a name to the schedule, specifying what days of the week or days of the month the schedule applies to, and specifying which hours the schedule applies to.
FIGURE 4 Runbook schedule
Once you’ve created the schedule, you can apply it to a runbook. You do this by selecting the schedule on the General tab of the runbook’s properties, as shown in Figure 5.
FIGURE 5 Apply runbook schedule
You check out a runbook to make changes to the runbook. When you check in a runbook, the runbook will be deployed to runbook servers. Checked-in runbooks will also synchronize to Service Manager if you have configured a connector between Service Manager and Orchestrator.
