This chapter covers the system architecture of System Center 2012 Orchestrator, the various components that are part of the product and how to deploy it in an environment. It discusses the different options that are available to deploy Orchestrator, the scenarios and requirements that you have to think about first before getting started, and details the high availability concepts for each of the components. We also describe the data bus, a key concept of Orchestrator that will help you build your runbooks and allows you to pass data between activities and runbooks without writingcode.
This section introduces the system components of Orchestrator, their purpose, and how they are going to work together.
The system architecture of Orchestrator contains different components—some of them are required, some of them are optional depending on the requirements and usage. This topic will provide an overview of Orchestrator and describe the components and its capabilities.
A runbook is the visual representation of your workflow. You will use a graphical interface, the Runbook Designer, to design and build the IT process automation and create those runbooks. A runbook consists of activities and colorful icons, each performing a specific task (for example, create an alert in System Center Operations Manager or run a Windows PowerShell script) that are linked together. The links between activities provide options to do filtering and give you the ability to use multiple paths and conditional logic such as if-then-else.
The Orchestrator Management server is the layer that is responsible for the communication between the designer of runbooks (Runbook Designer) and the database that holds all required data such as runbook definitions, instances of runbooks, etc.
A runbook server controls the running instances of a runbook; it directly communicates with the database without using the management server. The Runbook server is a Windows service that can be deployed using the Orchestrator Deployment Manager. You can have multiple runbook servers in your environment to distribute load and increase the total capacity of your automation architecture. It is also used to provide high availability.
The Orchestrator database utilizes Microsoft SQL Server and contains all runbook definitions, various logging information, as well as configuration data for Orchestrator. It is a single database that holds all the information required for the entire Orchestrator deployment.
The Runbook Designer shown in Figure 3-1 is a tool that is part of Orchestrator which you can use to build, edit, and manage your runbooks. It consists of a design pane and a folder structure to organize your runbooks as well as a toolbox that provide the different activities that you will use to build your workflows.
Although the left side of the window shows a similar interface to File Explorer, all runbooks, regardless of how you manage and group them, are stored in the Orchestrator database and not in the file system.
The Runbook Tester is another tool that comes with Orchestrator that will help you to test your runbooks at run-time. It will provide you with detailed information and data that are part of your runbook and is very helpful in troubleshooting problems that you might facing during implementation.
The Orchestration console lets you manage your runbooks in real-time. You are able to start and stop them and gather real-time status information about current running instances of your runbooks. The tool is a web browser interface that can be accessed remotely.
The Orchestrator web service interface is a Representational State Transfer (REST)-based service that enables custom applications to connect to Orchestrator. It will help to integrate the runbook infrastructure to other portals and tools and give you the option to manage your runbooks such as starting or stopping them or retrieving information about runbook operations.
The Orchestration console uses the Orchestrator web service to communicate with Orchestrator.
If you want to use integration packs (IPs) that extend the capabilities of Orchestrator, such as integration of other platforms and tools (for example, HP Service Manager), you need to register and deploy them into your Orchestrator environment. This can be done using the Deployment Manager, a tool that is used to deploy runbook servers and Runbook Designers. The tool is shown in Figure 3-2.
Automation is all about moving data between components, platforms, and tools. In most cases you take input data, work with that data, pass it to different systems, get some results back, and at the end of the runbook it’s common to return data such as the result state and, optionally, error messages.
The data bus is a key concept of Orchestrator that will help you to do exactly that—pass that data around without writing any code.
To achieve that, the data bususes another core concept called Published Data. Every step (called activities in Orchestrator) within a runbook will publish data to the data bus automatically. You can also easily add additional data to the data bus. Every subsequent activity in the runbook can access that data bus, subscribe to it, and use the Published Data from there again without any coding.
This makes it very easy to work with data across different vendors and tools to provide automated processes, and it will also decrease the time of implementing those processes significantly.
The architectural diagram shown in Figure 3-3 illustrates each of the Orchestrator features and the communication between each component.
The center of every Orchestrator environment is the orchestration database running on Microsoft SQL Server. This is really one of the key critical components of an automation environment using Orchestrator. The database will contain all your runbooks, configuration settings, and logs.
You also need at least one (or more) runbook servers that will communicate directly with the database to retrieve runbooks, to run and store information about the jobs created from the runbooks. So this is the second critical key component that must be available to run your automation processes.
The web services layer also communicates directly with the orchestration database and provides a web browser connection for the Orchestration console. The unavailability of the web service won’t impact your automation solution as long as you don’t rely on that web service within your implemented runbooks.
The management server is required as a communication layer between the Runbook Designer and the orchestration database, but it is not required for actually running the runbooks, which means a management server that is not available doesn’t impact the runbooks from doing their work, but it will impact building new runbooks or changing existing runbooks.
If you’re going to implement automation it will always be the heart of each datacenter and reliability and availability are top most concerns. So this section describes—based on the different components of the product—where high availability is important and how to achieve that.
This component is actually limited to one single management server, so within every Orchestrator environment there can only be one management server. From an availability perspective there is no requirement that the Orchestrator management server must be up and running or available. Even if the management server is down the runbook servers or runbooks will still run and work.
If the management server is not available, there is an impact on the Runbook Designer. The Runbook Designer cannot be used to publish runbooks or start, monitor, or stop runbooks. Instead, the Orchestration console or the web services must be used to start, monitor, and stop runbooks.
An Orchestrator 2012 database is hosted on Microsoft SQL Server 2008 or SQL Server 2012 with the basic database engine features, so there is no need for additional features. The database is one of two components that are critical to the entire environment. So it’s key to have an available database for Orchestrator. From a high availability perspective we would recommend you to use Failover Clustering and at least two nodes for SQL Server.
The Orchestrator web service must be installed on a server that is running IIS. If you use the Orchestrator web service in your runbooks then high availability might be required and important to your environment. In general, it is used to start, monitor, or stop runbooks, but it does not have to be available for runbook servers or runbooks to function. For high availability we recommend you install the Orchestrator web service on multiple IIS servers and use a load balancer to both provide additional capacity as well as continuous web service support in case of a failure of one of your web servers.
The Orchestration console must be installed on a server that is running IIS. The console can be used to start, monitor, or stop runbooks and similar to the web service it is not required to be available for the runbook servers or runbooks to function.
In case you want high availability, we would recommend that you install Orchestration console on more than one IIS server configured for load balancing. This will provide you high availability, but also additional capacity for requests that will use the console.
Runbook servers are required for runbooks to function. If there isn’t a runbook server available, no runbooks will be executed. Therefore high availability is required and important for your Orchestrator environment. But note that runbook servers are not designed to run on a cluster node. To achieve high availability in that case, we recommend deploying at least two runbook servers—depending on your environment and workload it might be required or recommended to have even more than two runbook servers. If the primary runbook server for a runbook is unavailable, the runbook can run on another server.
There are actually two mechanisms in place that are combined, the “spill over” mechanism helps spread the load of runbook instances across the existing runbook servers. So the more runbook servers that are available, the more concurrent instances can run in the same environment. The second mechanism will check for the health of a runbook server using a heartbeat signal. As soon as the runbook server is unhealthy (after 3 missed heartbeats, or 45 seconds) the assignment of a runbook instance will be changed to another runbook server. This makes sure that an unavailable runbook server will not bring down the automation environment and other runbook servers can take over.
You might come across the “Runbook Server Monitor” service in your environment. It monitor the health of the runbook servers and generates Orchestrator platform events should a runbook server show signs of problems. It does not provide any other high availability function in the Orchestrator environment.
A runbook doesn’t provide high availability; the runbook server must be high available to make sure your workflows will continue to run in case of a failure. By default, each runbook server is configured to run a maximum of 50 runbooks concurrently. You can change that number based on your experience, resource requirements of your runbooks, and the available resources of your runbook servers.
Consider the resource requirements of the runbooks on a particular server and based on that you can change the default value of 50 to another number by using the runbook server Runbook Throttling tool. In cases where the server has a number of runbooks with high resource requirements, you might want to run fewer concurrent runbooks on the runbook server. In cases of more simple runbooks with small or minimal requirements, you might consider increasing the number of concurrent runbooks on the runbook server.
For additional high availability you can deploy multiple runbook servers, which is described earlier in the “Runbook server section.
This section discusses some typical design patterns for Orchestrator 2012 deployments with different requirements and environments. It also gives some examples where you might want to use it, but it doesn’t offer general recommendations as there are always requirements that might change the architecture.
The following architecture patterns will be discussed:
Single-server Orchestrator 2012 infrastructure
High availability Orchestrator 2012 infrastructure
High availability and multisite Orchestrator 2012 infrastructure
This single-server Orchestrator 2012 infrastructure is a basic deployment where all components are deployed either on a single physical machine or on a single virtual machine. This single machine hosts the management server, Orchestration database, runbook server, Runbook Designer, and Orchestration console.
This design pattern shown in Figure 3-4 is fully functional, but does not provide any high availability or redundancy. In case of a failure, Orchestrator will not be able to process runbooks anymore. So you shouldn’t deploy this pattern in a production environment, but it can be used for proof of concepts, demos, or development environments.
Make sure you are aware of the hardware and software requirements. You’ll find these at http://technet.microsoft.com/en-us/library/hh420361.aspx.
A high availability Orchestrator 2012 design pattern presented in Figure 3-5 is the most common and widely used one. The critical components of Orchestrator 2012 that were described earlier in this chapter are configured to enable high availability:
Orchestration database
Runbook servers
Orchestrator web service
The Orchestration database used to store configuration information, runbooks, and logs is deployed and configured on a two-node SQL Server cluster.
In Figure 3-5 two runbook servers are deployed for failover and load balancing, but you can use more than two and deploy additional runbook servers to provide additional capacity. The exact number of runbook servers depends on the business and technical requirements of your environment.
Scaling out runbook servers can be performed using the Deployment Tool of Orchestrator, where a wizard guides you through the deployment process in a few steps.
The Orchestration console uses the Orchestrator web service and those two components depend on the performance of the orchestration database and the IIS server that hosts the Orchestrator web service. This is why we would recommend you install the Orchestrator web service on load balanced servers running IIS to provide high availability and additional capacity. Similar to the runbook servers, the more servers that are available to provide the service, the better the performance and the more requests can be handled.
The Orchestrator design pattern presented in Figure 3-6 is intended for managing devices and/or integrating systems from another datacenter in case your network is too slow and/or security plays a more important role than in the other scenarios.
On slow networks there is always a risk of packet loss, but configuring a runbook server across a wide area network (WAN) for the purpose of managing devices and/or integrating with systems is not recommended and will result in failures in your runbooks. In cases where latency in your network is greater than 30ms, the recommended approach is to configure a dedicated Orchestrator infrastructure in each datacenter and build runbooks that pass data between the datacenters using the Orchestrator web services. So instead of implementing the runbooks that will cross datacenter boundaries you will pass the data through the web service interface to another runbook in the remote datacenter.
For SQL you would implement a SQL Server geographically distributed cluster on which you deploy the Orchestrator database. The Orchestrator web services will be deployed separately in each datacenter. Those will access the SQL instance in the same datacenter. Runbook servers will be deployed in each datacenter, each accessing their local SQL instances. If they need to communicate across datacenter sites, the web service of the remote site can be used to leverage https connections.
There is only one active management server, with backups/restores another standby management server is kept updated and in case of a datacenter loss, the backup management server can take over.