System Center 2012 SP1 – Orchestrator: Server Components

In the first post of our series we began with a holistic overview of System Center 2012 – Orchestrator. Now as we being in our journey exploring the flexibility and fluidity of this System Center product, we will first take a closer look at the Orchestrator server components which when combined enable this technology. Although extremely powerful as a solution, the architecture is amazingly simple with just five services or server components, of which only three are mandatory. (Be sure to also check out my previous article on installing System Center 2012 SP1 – Orchestrator.)

System Center 2012 – Orchestrator Services

Our initial focus will be on the server side services, which together form the fabric of the service. We will identify the role of the service along with its criticality within a deployment, while we also consider the steps that we may need to take to implement a highly available installation.

Data Store

At the heart of the Orchestrator solution, the data store hosts both system configuration details, along with systems status information and logs, but most importantly it includes all of the runbooks and respective settings for the contained activities and links. As you can appreciate, the data store is a mandatory component in an Orchestrator environment.

Utilizing Microsoft SQL Server, Orchestrator stores all of its configuration and operational data in a centralized database, to which all other components will connect. For production-ready implementations, a highly available deployments of Orchestrator is easily achievable through the use of SQL clustering services, and with the release of Orchestrator, support has been further enhanced enabling all the benefits of SQL 2012 Always On features.

Management Server

Acting as the coordinator in an Orchestrator environment, the role of the management server is to enable communications between the data store and the Runbook server. Only a single management server can be deployed to a specific Orchestrator environment, for example with both pre-production and production Orchestrator environments we will deploy a maximum of one Management Server to each.

Although initially appearing to be a design problem for highly available (HA) deployments, this is essentially not the case, since the management server offline deployed runbooks will continue to execute without issue.

In the event that the management server is offline, there are a number of restrictions enforced until the situation is rectified. These include the inability to deploy new runbooks, or edit existing ones, and deploy new or upgrade existing Integration Packs. Both the Orchestrator Runbook Designer and Deployment Manager will be unable to connect to the environment until the management server is restored.

It is strongly advisable to utilize technologies such as Hyper-V Replica to ensure you have a working copy of this server role available in the event of a disaster. The management server role can be deployed in isolation or it can coexist with any other Orchestrator Component.

Runbook Server

The brains and muscle of our orchestrator environment is without doubt the runbook server. This service coordinates with the management server and data store to enumerate all the available integration pack activates, and runbooks that are published and ready for execution. Runbooks can be targeted to specific runbook servers or to all available servers – in which case an overflow-based system is utilized with the first runbook server processing any available jobs until it reaches capacity, fails, or shuts down (then the next available runbook server will immediately begin executing the runbooks). By default each runbook server will execute 50 simultaneous runbooks before entering overflow; however, this number can be easily changed if required.

To enable a scalable and highly available deployment, multiple runbook servers can be deployed to the environment. In the event of a disaster on any runbook server the overflow scenario will be triggered, automatically moving all runbooks (except the explicitly targeted) to the next available server.

Web Service

Extending the flexibility of System Center 2012 SP1 – Orchestrator, a new ODATA-based Representational State Transfer (REST) web service API is offered to enable additional integration. This API enables a vast amount of new possibilities for managing and monitoring an Orchestrator environment, spanning from rich reporting trough ODATA-enabled services such as Excel and PowerPivot, to remote triggering and monitoring of specific runbooks from third-party tools and utilities, or by simply enabling the ability to render new views of the orchestrator environment (for example, through the use of the Web Console).

Implemented as a website hosted on IIS, the web service can be deployed in a highly scalable fashion and is published through any HTTP/HTTP load balancing technology, including Microsoft’s IIS Application Request Routing module. This module is optional but highly recommended in an Orchestrator environment

Web Console

Also hosted as a website application on IIS, the web console is a new Silverlight application that permits end users to monitor and manage any available runbooks, to which they have access from the convenience of their browser in real time. The Silverlight Console application connects directly to the web service feature to gain insight into the Orchestrator environment and enable its user services.

As with the web service, this module is also optional, but if deployed depends on the web service also being deployed. Highly scalable deployments are implemented in the same manner as the web service, and the console also offers support for single sign-on integration. Both the web service and web console can be deployed to independent servers, or it can coexist with any other Orchestrator components or other IIS website farms.

In the next post in this series, we will take a closer look at the management tools which we will depend on for operating this service.