Page 1
Table of Contents
1Introduction
1.1Background
1.1.1Traditional automation methods
1.1.2Optimizing IT service delivery and increasing quality of service – through orchestration
1.2Customer and User Profiles
2Solution Architecture
2.1Orchestrator 2012 Components
2.2Orchestrator Architecture
2.2.1DataBus
2.2.2Integration
2.3Orchestrator 2012 System Requirements
2.3.1Hardware Requirements
2.3.2Security Planning
2.3.3Network Requirements
2.4Backup and Recovery Considerations
2.4.1Management Server
2.4.2Orchestrator Database
2.4.3Monitoring Plan
2.4.4Services and Event log monitoring
2.4.5Performance monitoring
2.4.6Antivirus exceptions
2.5Scalability Considerations
2.5.1Runbooks Scalability
2.5.2Runbook Servers Scalability
2.5.3Orchestrator 2012 Performance Tuning
2.5.4Resource Availability Requirements
2.5.5Database Sizing
2.6High Availability Considerations
2.6.1Management server
2.6.2Orchestrator database
2.6.3Orchestrator Web Service
2.6.4Orchestration Console
2.6.5Runbook Servers
3Orchestrator 2012 Architecture Patterns
3.1.1Design Pattern #1 – Single Server Orchestrator 2012 Infrastructure
3.1.2Design Pattern #2 – High Availability Orchestrator 2012 Infrastructure
3.1.3Design Pattern #3 – High Availability and Multi-Site Orchestrator 2012 Infrastructure
3.1.4Design Decision
4Evaluate Solution Requirements
5Appendix A – Sample Use Cases
5.1Use Case 1: Alert Remediation
5.1.1Free Space Remediation
5.1.2Detect and repair secure channel
5.2Use Case 2: Maintenance
5.2.1Advanced patching (patching machines in order, with pre- and post- checks)
5.2.2SQL Server maintenance tasks
5.3Use Case 3: Change management and provisioning
5.3.1Provisioning : Provision virtual machines
5.3.2Provisioning: Application deployment
5.3.3Administration: Put machines in Operations Manager maintenance mode
5.4Use Case 4: Cross-Technology Integration
5.4.1Connecting System Center Operations Manager to IBM NetCool (simple example)
5.4.2Connecting System Center Operations Manager to IBM NetCool (advanced example)
5.5Use Case 5: Dynamic Resource Allocation
5.5.1Web Farm demo: Scaling out a service to handle additional load
5.6Use Case 6: Line of business and other
5.6.1New hire onboarding
1Introduction
SystemCenter2012-Orchestrator is a workflow management solution for the data center. It enables automation of creation, monitoring, and deployment of resources in your environment. This document describes SystemCenter2012-Orchestrator planning and deployment and presents key concepts and captures business and environmental requirements for the automation of datacentre tasks using System Center 2012 Orchestrator. This document provides a summary of the topics, techniques, and design patterns to help deploy and use System Center 2012 Orchestrator.
1.1Background
Today customers are facing a broad range of challenges in their datacenters. On one hand the complexity of their environments is increasing every year due to server sprawl, various systems and platforms from different vendors, while on the other hand customers having a lot of pressure to reduce costs at the same time.
IT decision makers are constantly looking to streamline IT operations and processes, reduce the burden on IT resources, and improve their ability to meet the complex needs of the businesses that they support. They can accomplish this by automating time-consuming manual processes, a method used to keep the world’s largest and most efficient data center facilities operating with minimal manual oversight.
Automation allows IT departments to improveagility and response times and increase performance to better meet service-level agreements (SLAs).Decision makers can also adopt and maintain quality processes and performance that give them the consistency that they need to meet business requirements, while maintaining compliance with industry and government regulations. As these improvements are implemented, decision makers will have to make sure that their deployments can span heterogeneous environments—promoting adherence to similar management models and tools.
System Center 2012 Orchestrator automation capabilities will free up resources to focus on more strategic efforts and potentially reduce overall head count associated with specific tasks. Reduced reliance on human intervention or manual processes will improve efficiency, and overall quality through the reduction of human errors. In addition, automation will ensure that proper configuration management processes are followed and enforced, providing invaluable tracking of change control. Finally it provides a means and framework which will be used as a blueprint on how to achieve higher productivity.
1.1.1Traditional automation methods
Traditional automation methods, namely custom coding and scripts, are useful for running simple tasks, however, they typically lack best practices, change management, documentation, and the flexibility required in an operations environment, where business rules and configuration settings change frequently.
Traditional automation methods, namely job schedulers, run and monitor batch jobs. Although job scheduling comprises an important function in a production-computing environment, it is not well suited to automate operational processes or run book procedures, as they provide little to no integration with surrounding systems.
Due to the recent recognition of this market by both IT organizations and leading industry analyst firms alike, some companies have attempted to accomplish the equivalent of Runbook Automation, by running lengthy scripts with a job scheduler. This technique is costly, unreliable, and error-prone.
While scripts and schedulers work well for small tasks, they can rarely scale to handle complex environments. They also lack sophisticated dependencies and reporting that allow users to keep audit trails of processes. As process requirements grow, and more functionality is added, the result is a complex mix of scripts, programs, and utilities that only a few people actually understand. More concerning is that home-grown scripts can quickly turn into a fulltime programming commitment as well as a time-consuming and costly management burden.
1.1.2Optimizing IT service delivery and increasing quality of service – through orchestration
Runbook Automation solutions include many of the features and capabilities users require in a job scheduler, while also providing more advanced functions. IT process automation software can automate any administrative, maintenance, or business processes, such as restarting services, rotating logs, backing up data, deleting temporary files, and e-mailing files. It can also run several jobs on multiple machines, modify accounts, query databases, up load data and filter/read/send e-mail. In addition to standard enterprise requirements like load balancing, failover, failure routines, error handling, and logging, ITPA should also provide integration, orchestration, and process workflow.
As part of System Center 2012, The Runbook Automation component “Orchestrator” reduces operational costs and improves IT efficiency by delivering services faster, with fewer errors. This is achieved by replacing manual, resource-intensive and error prone activities with standardized, automated processes.
Orchestrator automates the end to end operational processes that traverse organizational boundaries – bridging historic IT silos (vendor specific backups and hardware, heterogeneous environments, physical and virtual environments, multiple management solutions, service desks,…). Where it was common in the past to implement multiple rigid “point to point” solutions, Orchestrator provides a rich and flexible 1:N automation between System Center components as well as non-Microsoft technology stacks in the datacenter.
Well defined workflow processes are the basis for implementing efficient incident, change, configuration and release processes in an IT environment. Repeatable IT processes lessens the risk for IT by eliminating opportunities for human error, as well as freeing up valuable IT staff from constantly performing mundane tasks. Thanks to its capabilities to integrate with many other technologies including monitoring, service desk and change management solutions, Runbook Automation enables the implementation of consistent operations processes in support of best practices and standards initiatives such as ITIL.
1.2Customer and User Profiles
Users of the proposed solution will be limited to the following core groups:
▪Operations team (Users). These users will be the main consumers of the solution and will derive the biggest benefits from the automation provided. This group is responsible for performing all operational tasks and is currently developing all scripts for the automation of these tasks.
The operations team will be the recipient of information and control gate status messages in the form of email messages.
▪Solution Administrators. These users will be the administrators of the solution and will ensure system maintenance is performed, troubleshoot errors, and restore availability of the solution in the event of an outage.
▪Runbook Designers. These users will be the designers of the system and will address the need to incorporate new features, capabilities and routines into the solution.
Runbook designers will develop the runbooks and activities needed for the solution to achieve the stated objectives. This may include changes to runbooks in support of new functions, features or even to support new versions. These users will have a strong development background and should not be permitted to operate on or with the production systems. Their work should be completed in the development environment where design work can be completed and tested before being approved for use in the production environment.
2Solution Architecture
System Center 2012 Orchestrator is a workflow management solution for the data centre. Orchestrator 2012 automates tasks for creation, monitoring, and deployment of resources in the environment.
2.1Orchestrator 2012 Components
An Orchestrator 2012 solution consists of multiple components as presented in Table 2.
Table 2: Orchestrator 2012 Solution Components
Name / DescriptionManagement Server / The Management Server is a service that provides a communication layer between the Runbook Designer and command line tools to the Orchestrator Datastore.
Orchestration Database / A SQL Server database that contains all of the deployed runbooks, the status of running runbooks, log files, and configuration data for Orchestrator 2012.
Orchestration Console / The Orchestration Console is a web-based tool with which an operator can view the list of runbooks, view current running status and start/stop runbooks.
Orchestration Web Service / The Orchestration Web Service is a Representational State Transfer (REST)-based service that enables custom applications to connect to Orchestrator 2012 to start and stop runbooks, and retrieve information about operations by using custom applications or scripts. The Orchestration Console uses this web service to interact with Orchestrator 2012.
Runbook Designer / The Runbook Designer is the tool used to build, edit and manage Orchestrator 2012 runbooks.
Runbook Server / Runbook Server is where an instance of a runbook runs. Runbook Servers communicate directly with the orchestration database. Multiple Runbook Servers can be deployed per Orchestrator 2012 installation to increase capacity and redundancy.
Runbook Server Monitor / The self-monitoring feature which monitors runbooks, activities, database connections and more to ensure that these items are running as expected.
Runbook Tester / Runbook Tester is a run-time tool used to test runbooks developed in the Runbook Designer.
Deployment Manager / The Deployment Manager is a tool used to deploy Integration Packs, Runbook Servers, and Runbook Designers.
Integration Pack (IP) / An integration pack is a collection of custom activities specific to a product or technology. Microsoft and other companies provide integration packs with activities to interact with their product from an Orchestrator 2012 runbook.
For further details about Orchestrator 2012 Integration Packs refer to
Orchestrator Integration Toolkit (OIT) / The Orchestrator Integration Toolkit extends default Orchestrator 2012 activities library beyond the collection of standard activities and integration packs. The Integration Toolkit has wizard-based tools to create new activities and integration packs for Orchestrator. Developers can also use the Integration Toolkit to create integration packs from custom activities that they build by using the Orchestrator Software Development Kit (SDK).
2.2Orchestrator Architecture
The following diagram illustrates each of the Orchestrator features and the communication between each.
The orchestration database is the center of the Orchestrator installation containing all runbooks, configuration settings, and logs. The management server is required as a communication layer between the Runbook Designer and the orchestration database. One or more runbook servers communicate directly with the database to retrieve runbooks to run and store information about the jobs created from the runbooks. The web service also communicates directly with the orchestration database and provides a web browser connection for the Orchestration console.
2.2.1DataBus
Integration DataBus, with full flexibility on process branching and parallelism. The Orchestrator engine – called the “databus” – provides the following features:
- Pass data between systems in one click with the unique Orchestrator publish/subscribe data bus for rapid integration
- Create context-adaptive workflows with intelligent decision making logic to automate even the most complex processes
- Run multiple, concurrent branches of a workflow for high volume processing
2.2.2Integration
2.2.2.1Extensions
The following shows multiple strategies available for extending the functionality provided by a standard installation of Orchestrator:
Name / DescriptionIntegration Pack (IP) / An integration pack is a collection of custom activities specific to a product or technology. Microsoft and other companies provide integration packs with activities to interact with their product from an Orchestrator runbook.
See Integration Packs for System Center 2012 - Orchestrator for more information
Orchestration Database / The Orchestrator Integration Toolkit lets you extend your library of activities beyond the collection of standard activities and integration packs. The Integration Toolkit has wizard-based tools to create new activities and integration packs for Orchestrator. Developers can also use the Integration Toolkit to create integration packs from custom activities that they build by using the Orchestrator SDK.
2.2.2.2Integration with the System Center suite
While its automation capabilities are not restricted to Microsoft environments, Orchestrator also provides best-of-breed automation capabilities for the other System Center components. In particular, runbook automation is often tied to ITIL process execution (incidents, problem, changes), and in System Center 2012, the Service Manager service catalog comes with a built-in connector for Orchestrator runbooks. This eliminates the need for complex scripting and development to tie runbooks into change requests. With System Center 2012, once the manual or review steps of a change have been processed, Service Manager can hand off the request seamlessly to Orchestrator, which can update the change request and the CMDB in return. This integration is key in the way System Center components work together to achieve Private Cloud scenarios, especially for Infrastructure as a Service. Microsoft provides a “Process Pack” leveraging this feature, as a download.
2.2.2.3Standard activities
There are a number standard activities to enable integration:
- Code-free integration with other solutions and home-grown applications (run command line, run SSH, run script, work with databases, web services, etc…)
- File system interactions (monitor, copy, move…files and folders)
- Perform schedule-based activities
- Monitor processes or system-level events
- Send notifications (including email)
- Manipulate text files
- Work with the databus, manage and interconnect runbooks
- Partners Integration Packs
More and more vendors are providing integration packs for Orchestrator, including Dell for Advanced Infrastructure Manager, NetApp, Cisco for UCS, DoubleTake, etc.
2.2.2.5Community Integration Packs
The Orchestrator community is always expanding, here are some community contributions as of today, for example there are many contributions on Codeplex.
2.3Orchestrator 2012 System Requirements
This section describes Orchestrator 2012 system requirements and supported operating system. Table 3 details the software configuration required to install individual Orchestrator 2012 components.
Table 3: Orchestrator 2012 Software Requirements
Name / Operating System/Software Requirements / CommentsManagement Server / Windows Server 2008 R2
Windows Server 2012 / Management server collocated with Runbook Server will use the same database.
Orchestration Database / Microsoft SQL Server 2008 R2
Microsoft SQL Server 2012 / Only Database Engine SQL Server feature is required. The instance of SQL Server can either be installed locally on the management server or on a separate dedicated database server. Orchestrator 2012 requires SQL_Latin1_General_CP1_CI_AS database collation.
Orchestration Console / Windows Server 2008 R2
Windows Server 2012 / Orchestrator 2012 setup will enable the internet Information Server (IIS) role if it is not already enabled.
Orchestration Web Service / Windows Server 2008 R2
Windows Server 2012 / Orchestrator 2012 setup will enable the IIS role if it is not already enabled.
Runbook Designer / Windows 7 32-bit or 64-bit
Windows Server 2008 R2
Windows Server 2012 / Orchestrator 2012 setup installs and enables .NET Framework 3.5 Service Pack 1 if it is not installed and enabled.
Runbook Server / Windows Server 2008 R2
Windows Server 2012 / Management server collocated with Runbook Server will use the same database.
2.3.1Hardware Requirements
This topic describes the hardware requirements for installation of the SystemCenter2012-Orchestrator SP1 components.
The server hardware requirements for Orchestrator are dependent on the number, size and complexity of the runbooks being executed. The following are the minimum hardware requirements:
2.3.1.1Management Server
- 1 gigabyte (GB) of RAM minimum, 2 GB or more recommended
- 200 megabyte (MB) of available hard disk space
- Dual-core Intel microprocessor, 2.1 gigahertz (GHz) or better
- Runbook Server
- 1 gigabyte (GB) of RAM minimum, 2 GB or more recommended
- 200 megabyte (MB) of available hard disk space
- Dual-core Intel microprocessor, 2.1 gigahertz (GHz) or better
- Orchestrator Web Service
- 1 gigabyte (GB) of RAM minimum, 2 GB or more recommended
- 200 megabyte (MB) of available hard disk space
- Dual-core Intel microprocessor, 2.1 gigahertz (GHz) or better
- Management Server
- 1 gigabyte (GB) of RAM minimum, 2 GB or more recommended
- 200 megabyte (MB) of available hard disk space
- Dual-core Intel microprocessor, 2.1 gigahertz (GHz) or better
2.3.2Security Planning
This section describes the service account and user account requirements, as well as security considerations for Orchestrator 2012 deployment.
2.3.2.1Service accounts
The following are Service accounts that are required for the services listed. These accounts have to be created before installing the features that use them.
Orchestrator 2012 Service / CommentsOrchestrator Management Service / The Orchestrator Management Service is installed on the management server. Its service account is specified during the installation of Orchestrator 2012. This is the same account used by the Orchestrator Management Service and Orchestrator Runbook Service on each computer to access system resources. The Orchestrator Management Service is responsible for maintaining the orchestration database, communicating with the Runbook Designers, and communicating with the Deployment Manager.
The account used for the Orchestrator Management Service can be a local account on the management server if the database is installed locally. However, this configuration might not allow access to other network resources. If the database is located on another server, the account must be joined to the Active Directory domain so it can access the database server.
This service account does not have to have domain administrator privileges, but it should be a member of the local Administrators group on the computer where the Orchestrator Management Service and Orchestrator Runbook Service are installed.
The service account for the Orchestrator Management Service must have the following permissions:
▪Permission to log on to the management server as a service. This permission is automatically granted during the installation process.
▪Member of the Microsoft.SystemCenter.Orchestrator.Admins role in the orchestration database. The account is automatically added to this role during the installation process.
Orchestrator Runbook Server Monitor Service / The Orchestrator Runbook Server Monitor is installed on the management server and is responsible for monitoring the health of Runbook Servers. It uses the same account as the Orchestrator Management Service and requires the same permissions.
Orchestrator Runbook Service / The Orchestrator Runbook Service is installed on each Runbook Server. When Runbook Server is collocated with the Management Server, Orchestrator Runbook Service and Orchestrator Management Service use the same account (Orchestrator Runbook Service account). If additional Runbook Servers are deployed, a different service account can be specified. The service is responsible for running runbooks and for communicating with the orchestration database.
By default, all activities in a runbook run under the service account of the Runbook Server on which they are running. Some activities can specify different credentials to be used for individual actions as required. Because runbook activities often access resources on other computers, the account used for the Orchestrator Runbook Service should be a member of Active Directory groups that have sufficient access to these external resources.
The account for the Orchestrator Runbook Service must have the following permissions:
▪Permission to log on to the management server as a service. This permission is automatically granted during the installation process.
▪Depending on the resources that the runbook activities access, the service account might require additional credentials on remote computers. Specific activities can also be configured with alternate credentials if the service account does not have access to particular resources.
▪This service account does not have to have domain administrator privileges, but it should be a member of the local Administrators group on the computer where the Orchestrator Management Service and Orchestrator Runbook Service are installed.
2.3.2.2Runbook security