It is very important to understand the whole architecture of System Center Orchestrator before your start installing any of the SCO components.
Understanding the Orchestrator architecture
Getting ready
The author recommend you to review the latest information on SCO at https://technet.microsoft.com/en-us/library/hh420377(v=sc.12).aspx, as the documentation about the architecture of the product is regularly updated by Microsoft.
How to do it…
The SCO architecture is made up of six types of components. The basic automated activity delivered by SCO is called a Runbook, which is commonly known as workflow in other products. The six components, which make up the SCO product are listed and described in the following table and are illustrated in the figure following the table:
|
SCO component |
Description
|
|
The Runbook Designer |
The Runbook Designer is a tool used for creating and editing Runbooks. Runbooks are stored in the Orchestration database. A subcomponent of the Runbook Designer is called the Runbook Tester, which is used to validate the execution of Runbooks. |
|
The Orchestration database |
The Orchestration database is a Microsoft SQL Server database, which stores Runbooks, the statuses of Runbooks, and the security delegation configuration. The database also stores log files and the configuration of the SCO deployment. |
|
The Management Server |
The Management Server is the core communication component of the SCO architecture and is responsible for coordinating the communication between the Runbook Designer and the Orchestration database. There is only one Management Server per SCO deployment. |
|
The Runbook Server |
The Runbook Server is responsible for executing the instances of Runbooks. When a Runbook is invoked, a copy of the Runbook instance is sent to its assigned Runbook Server, and then it is executed (by default, this is the first installed Runbook Server, which is assigned the Primary role). |
|
The Orchestrator web service |
The Orchestrator web service is the interface that enables applications to connect to SCO. Typical tasks performed through the web service are Runbook status views, start, and stop actions. |
|
The Orchestrator browser console |
The Orchestrator browser console is a Silverlight supported web console, which uses the Orchestrator web service to communicate with SCO. |
The six parts of SCO are illustrated in the following figure:
For the smallest implementation, all the components can be deployed to one server (physical or virtual). You have the option to scale out the deployment using multiple servers to host one or more components of SCO. The deployment choice is determined by the planning activities you perform before invoking the installation of the product. This recipe discusses the factors you must consider to assist with the deployment choice.
About the Management Server
At the time of writing, the current version of SCO supports only one instance of a Management Server per deployment. You can deploy multiple instances of the other parts of the product with a note that we are still dealing with just one database per Management Server. The database instance can be made highly available.
How it works...
The understanding of the SCO architecture is an essential task in order to be successful in automating your task. Before planning your deployment, make sure you understand the architecture and the components of SCO. Afterward, start planning your deployment as described in the recipe, Planning the Orchestrator deployment.