In the Orchestrator 2012 R2 Installation article I have gone through the process of installing Orchestrator on a server to automate tasks, in this post I will describe Orchestrator Architecture and function of each of the components making up an Orchestrator deployment.
Orchestrator Architecture – Logical Diagram
In the picture below you can see a logical diagram of the Orchestrator Architecture
I will use the image a reference while describing the various components in more depth.
Orchestrator Architecture – Orchestration Database
The orchestration database is an SQL Database instance and is the center of the whole Orchestrator installation it contains among other configuration settings, runbooks and logs.
Without the database server Orchestrator cannot function, as simple as that, for this reason it is possible to deploy the Orchestration database on an SQL Always-On cluster.
Orchestrator Architecture – Management Server
The management server primary function is establishing communication between the Runbook Designer and the Orchestration database. It is not considered a critical feature and not necessarily needs to be highly available as Orchestrator can keep functioning without this server role.
Orchestrator Architecture – Runbook Designer/Tester
While logically separated I will describe the Runbook Designer and Tester in the same section as the latter is launched within the Designer console.
As the name implies the Runbook Designer is used to design, test and implement various runbooks that will responsible for automation, as per the management server this feature is not critical for operations and does not need to be highly available
Runbook Tester as I already mentioned is launched within Runbook Designer console and as the name implies is used to test runbooks before deployment publishing runtime data about each activity run by the runbook, imagine it as a debug component.
[su_note note_color=”#ffff96″ text_color=”#000000″ radius=”5″]Note: It is very important to note that despite the name Runbook Tester will actually run the runbook and not function as a “what if” tool so make sure to run tester again PoC or Lab servers to avoid impacting production systems.[/su_note]
Orchestrator Architecture – Runbook Server
Runbook server is the component responsible of actually executing any configured runbook as you can see in the diagram you can deploy multiple Runbook Servers for both fault tolerance and load balancing.
[su_note note_color=”#ffff96″ text_color=”#000000″ radius=”5″]Note: There is no technical limit to the number of Runbook Servers but, by default, each Runbook Server is configured to simultaneously run a maximum of 50 runbooks, this limitation is not hard-coded in Orchestrator but rather at the OS level.[/su_note]
Orchestrator Architecture – Web Service
The Orchestrator Web Service is a REST based service that allows programmatic access to Orchestrator, the Orchestrator Console uses this Web Service.
Orchestrator Architecture – Orchestration Console
The Orchestration Console allows administrators to access and monitor Orchestrator from their browser, the component is not critical for operations but enables operators to monitor state of runbook execution, start and stop jobs or review execution history for runbooks and it is the main point of administration for the Orchestrator deployment.
Orchestrator Architecture – Deployment Manager
The deployment manager component is not depicted in the above picture as it is not a proper role but more a tool that is used to deploy Integration Packs (IPs), additional runbook servers and runbook designers.
Orchestrator Architecture – The Bottom Line
This post does not intend to be a complete reference to the various components making up Orchestrator Architecture but is intended more as introduction to help clarifying the various components making up Orchestrator, in subsequent articles I will illustrate how to import Integration Packs (IPs) and how to write our own automation runbooks to carry on tasks that would otherwise require manual intervention.