Freigeben über

Orchestrator 2012 Deployment & Configuration Step by Step – Part 1 “Overview and Architecture”

  • Artikel

In this post series I will go through Microsoft System Center Orchestrator 2012 Deployment and Configuration in Step by Step format, and will go into details of the product to help you better understand how you can get benefits from this powerful product.

In this port I will start with an overview about Orchestrator 2012 and Orchestrator 2012 Architecture based on RC version that is subject to change in future release,

Orchestrator Overview

With Orchestrator, you can connect different systems from different vendors together without any scripting or programming.

To automate processes with Orchestrator, you use the Runbook Designer to drag and drop Activities and Link them together to create workflows called Runbooks. These runbooks become the encapsulation of your automated procedures.

The graphic below illustrates a simple runbook that monitors an event log, then based on the event detected, checks the status of a Windows process, end the process and restart it, then send email to an administrator,

A runbook that monitors an event log

You can create runbooks that contain just a few steps, or you can create runbooks that contain hundreds of steps, including running other runbooks. Each activity publishes data to the Databus , which can be used by any later activity it in the runbook. You can use the Published Data to enable dynamic decision-making in your runbooks or to provide for automated creation of emails, alerts, accounts, and more.

The StandardActivities included with Orchestrator provide a number of monitors, tasks, and runbook controls. In addition, you can extend the capabilities of Orchestrator through Integration Packs, which include additional functionality for third party products, technologies, or complex actions.

Before using new runbooks in your production environment you can quickly test the runbooks in a safe environment using the Runbook Tester. Also, with the browser-based Orchestration Console you can keep track of runbooks that are currently running and control them.

Using the Deployment Manager, runbooks are deployed to and run on one or more Runbook Servers within the infrastructure, providing a scalable, highly-available process automation architecture. Linking all of the components together is the Management Server and the Data Store, which is the database where configuration information, runbooks and logs are stored.

Multiple Runbook Servers are used to provide load balancing and failover capabilities. If a Runbook Server goes down, runbooks will automatically begin to process on another Runbook Server.

Terminology

The following terms will be used during the course of this lab. Familiarizing yourself with their definitions will help you progress through the lab more easily.

  • Runbook – These are the workflows that are created and used with Orchestrator. They contain exactly one starting point, but can contain many branches, many different actions, and many potential stopping points.

  • Activities – The individual actions within a runbook, available within the Activity Pane.

  • Standard Activities – The activities that are included with the default installation of Orchestrator; they include the basic activities used to build runbooks.

  • Integration Pack (IP) – This is a collection of custom activities that are specific to a product or a technology. An example is the Integration Pack for System Center Operations Manager.

  • Link – The connection between two activities in a runbook. Links provide the flow from one activity to another based on criteria defined in the filters.

  • Monitors – A special type of activity designed to run continuously and trigger action based on a specific condition. Monitors are often used to start a runbook.

  • Variables – Global values that can be used in runbooks to define frequently-used settings, such as directory paths to common files, server names, or other strings.

  • Counters – Global integer variables you can use within runbooks, with the ability to modify the value within a runbook, such as an incremental number of attempts.

  • Schedules – Global settings that allow you to define a set of date/time criteria for use within a runbook. Schedules can be used to define when a runbook will run an action, or when it cannot run an action.

  • Check In / Check Out – When you have finished updating a runbook, you must check in your changes to commit them to the Orchestrator Data Store. This is the way Orchestrator saves the runbooks.

  • Trigger – Causing a Runbook Activity to activate, either by satisfying a monitor condition or by linking to a previously-run activity.

  • Databus – The Databus is a mechanism used within Orchestrator to pass information in a runbook from one activity to later activities. The data flowing in the Databus for a runbook is called Published Data, and each activity in a runbook publishes its own data to the Databus.

  • Published Data – The foundation of a working runbook. It is the data resulting from each activity in a runbook. This data is published to the Databus so that activities in the runbook can subscribe to it and use it in their configuration. Link conditions also use this information to add decision-making to the runbook.

  • Pipelining – A term used to describe the process of moving from one activity to the next in the runbook based on links between the activities and conditions placed on the links.

  • Job – When you start a runbook, a job is created and added to a queue in the data store. Runbook servers poll this queue and pick up any available jobs that they can work on.

  • Instance – When a runbook server picks up a job, an executing instance of the runbook is spawned on the server.

Orchestrator Runbook Designer

This is the Runbook Designer. This is the interface where a designer builds, edits, and manages runbooks in Orchestrator. The interface is organized into three core areas:

image

1. The Connections pane on the left side is the folder structure where you can organize runbooks in the Orchestrator system. These folders are saved to the Orchestrator central database. You can also edit permissions on folders.

2. The Design Workspace is where you create and manage runbooks.

3. The Activity Pane contains all the activities (either Standard Activities or activities available from Integration Packs) available for insertion into runbooks. You drag activities from the Activity Pane into the workspace then link them together to form runbooks.

4. A fourth area, the Log pane shows you the activity of your runbooks and actions

Architecture

Orchestrator includes the following main components:

  • Runbook Server – The engine that runs runbooks. Runbook Servers communicate with the Data Store. Runbook Servers do not require a Management Server to be online to be able to run runbooks. You can deploy a single Runbook Server or multiple.

  • Management Server – The central manager of Runbook Designer, Runbook Servers, Runbooks, Runbook Tester, and the Self-Monitoring functionality. The Management Server deploys Orchestrator Integration Packs to Runbook Servers and Runbook Designers, deploys runbooks to Runbook Servers, and acts as a communication link between the Runbook Designers, the Runbook Servers, and the Data Store.

  • Runbook Designer – The tool used by designers to create, modify, and publish runbooks.

  • Runbook Tester – The tool used by designers to test runbooks that are developed in the Runbook Designer before they are deployed.

  • Orchestration Console – A web-based application that enables you to see which runbooks are available in the system, view their real-time status, and start or stop them.

  • Data Store – The Data Store is the SQL Server database where configuration information, runbooks, and logs are stored.

  • Web Service – The Web Service is the web interface to the Data Store. The Orchestration Console uses the web service to access data.

The following diagram illustrates each of the Orchestrator features and the communication between each:

System Center Orchestrator 2012 Architecture

The 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 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 database and provides a connection from client browsers for the Orchestration console.

In the coming post I will go through Orchestrator 2012 System Requirements for Orchestrator 2012 and Installation Steps.

----------------------------------------------------------------------------------------------------------

Comments

  • Anonymous
    January 01, 2003
    Nice one, Maged!