TECHNOLOGY
System Center Orchestrator

Introduction

System Center Orchestrator (formerly known as Opalis Integration Server) is a solution for process management at data centers and other IT-infrastructures. Orchestrator allows almost complete automating data centers, integrating their system components of different levels (from hardware up to users) and creating solutions, which otherwise would be unrealizable or unreasonable.

Automation

Orchestrator is often jokingly called “PowerShell with graphical user interface” or “Visio where pictures work”. Many a true word is spoken in jest – Orchestrator resembles PowerShell in its structure, and its automated procedures appear and are created in a manner very similar to Visio diagrams. But opposed to PowerShell Orchestrator is an actually commercial automation solution for significant systems of medium-sized and large business. It is provided by better manageability, logging, access control system, possibility to create server clusters for scripts execution. However PowerShell features are also used. PowerShell scripts are often used as Orchestrator procedure elements to increase system flexibility, to use additional integration possibilities and to save resources invested in scripts development.

Orchestration

One of the main advantages of Orchestrator implementation is possibility to bind all kinds of infrastructure elements and create processes interacting with these elements at any levels. Orchestrator can be integrated almost with everything – from servers and network hardware to web-sites and service management systems. Databases, monitoring and management systems, E-mail, source code management system – all these items can be involved into processes integrating actions, logic and data at all levels.

Integration

As mentioned above, Orchestrator integration capabilities are wide enough. Complete list of ready-to-use integration packs is given in “Integration packs” section; however the Orchestrator capabilities are not limited by the listed ones. Firstly, many new integration packs are being developed not only by Microsoft company but also by great community of experts. It is possible due to simplicity of development of such packs and snowballing product popularity. Secondly, if you have not found required integration pack in the list of ready-to-use packs, it does not mean that you cannot integrate you system with Orchestrator or with other systems by Orchestrator’s means. In this case integration process is a little more complicated than simple activity-blocks drag-and-drop and their properties configuring. But there is nothing impossible in this case. Orchestrator allows integrating with systems by the means of not only ready-to-use integration packs but also protocols ant methods being used in IT-industry such as command line utilities, web-services, WMI, configuration files, etc.

Heterogeneity

Although Orchestrator is developed by Microsoft company, its capability of working with products and operating systems developed by other companies including competitors of Microsoft is worth mentioning. It is clear enough that to develop data center or any other complicated infrastructure using technologies of only one vendor is rather difficult. Nevertheless there should be capability to bind all these systems with each other for their actually effective management. Microsoft comprehends this fact, that’s why they save, maintain and develop integration packs for competitors’ products acquired together with Opalis. So, it does not matter which virtualization system is used at you company – Hyper-V, VMware or both at the same time; it does not matter which service and request management system is customary for your users – HP Service Manager, Microsoft Service Manager, SharePoint-based product or completely your own solution, Orchestrator anyway will help you to arrange any infrastructure.

Features

This section tells about main technical features of Orchestrator and its components.

Architecture

Architecture

Architecture of Orchestrator consists of several elements that can be both combined within one server in case when there is no high load on the server or risk and separated to different servers duplicating/clustering all significant components.

Graphical procedure designer (Runbook Designer)

 Runbook designer

Procedure designer is the main user interface for adjusting and managing Orchestrator. Automated procedures, which will be executed later on procedure servers, are created and debugged just with this interface. There can be as many procedure designers as necessary. Moreover simultaneous work of several users does not crash the system – Check-In/Check-Out procedures, change log and agile access control system are provided.

Furthermore procedure designer console contains Runbook Tester – useful component working as friendly procedure debugger.

Web-portal (Orchestration Console)

Web-portal is the only interface for procedures end user, supplied together with Orchestrator. The portal allows starting procedures manually with transferring required parameters to them and controlling their execution. Though this portal may be less user-friendly than specialized portals based on service management system or SharePoint, nevertheless it can perfectly meet the requirements of many companies. Besides the portal, web-service allowing managing procedures from other systems is provided. For instance, Microsoft Service Manager uses it to synchronize and start procedures.

Management Server

It is the only system component that does not support clustering, but this component is not critical. It is used only as a connector between procedure designers and web-portal.

Orchestration Database

Orchestrator uses common SQL Server database. Since it is one of the most important system components, it can be clustered. To do this standard procedures of SQL Server are used.

Procedure Server (Runbook Server)

The main system component is the server directly executing automated procedures. For correct work it requires broadband connection to database server. When working Runbook Server connects to procedures being managed. Orchestrator does not use “agents”, that’s why connections are performed directly from procedure server. There can be several procedure servers at the company infrastructure for both allocating procedures being executed in case of high server load or moving procedure to the next preferred server in case of other server failure 

Procedures

Runbook

The main component, which makes Orchestrator so valuable, is procedures. Procedure is an automated process being continuously executed or started by condition or timer. When working procedures call activities and other sub-procedures, carry out conditions validation and transfer data.

Activities

Activity is a basic block performing the main work, which procedure consists of. Examples of activities: “Run the command”, “Run SQL query” or “Get Service Manager queries meeting the condition”. Standard Orchestrator supply includes more than forty standard activities, and integration packs provide even more activities.

Transition conditions and cycles

Procedures are not linear sequences of commands. To implement complex logic you can create cycles, transition conditions, etc.

Data Bus

Opposed to many similar systems and even to script languages Orchestrator has an interesting feature called “Data Bus”. Its essence is that all data got from the activities at one of procedure stages are available for other activities being executed later without necessity to save these data within variables. This capability simplifies and hastens procedure development process to great extent.

Multithreading

Many or even majority of processes in data centers may take a lot of time, for instance creating virtual machine or backup. If several operations should be executed at the same time, then capability to execute different procedures in parallel threads is critical. Moreover limit of procedure instances running in parallel is available. For example, if backup system can perform only three backup tasks simultaneously and increase of their number results in system failure, then procedure limit to 3 parallel tasks provides avoiding failure due to enqueuing all new queries.

Integration packs

Although Orchestrator is recent enough, the product has got a lot of ready-to-use integration packs. And the majority of them (including all packs developed by Microsoft) is free and does not require special licenses. The main set of packs is surely packs for integration with other components of System Center. All of them are developed by Microsoft:

  • Service Manager
  • Virtual Machine Manager
  • Configuration Manager
  • Operations Manager
  • Data Protection Manager

Moreover Microsoft has released following packs for other systems:

  • Active Directory
  • Exchange Admin (managing administration elements)
  • Exchange Users (managing mail, calendars, etc.)
  • FTP
  • HP iLO and OA
  • HP Operations Manager
  • HP Service Manager
  • IBM Tivoli Netcool/OMNIbus
  • REST (web-services)
  • Windows Azure
  • VMware vSphere.

Relevant information and up-to-date documentation for Microsoft integration packs can be found at TechNet.

Except Microsoft, community of enthusiastic specialists and company’s partners develop integration packs. For instance, following integration packs are available:

 If required integration pack does not exist

What to do if integration pack for your system does not exist yet or is not expected (in case it is your own self-developed system)? Orchestrator has many features for work with system without ready-to-use management packs. Almost every IT-system has some kind of standard interface that can be used by Orchestrator for interaction, for instance the following:

  • Command line utilities
  • Web-services
  • SSH (*-nix systems, hardware)
  • SNMP
  • WMI
  • SQL (Microsoft SQL, Oracle, and even Access)
  • PowerShell

Basing on PowerShell scripts or command line utilities specific integration pack can be easily developed using special wizard. If the developers of your system want to develop full-featured integration pack using your own API, they will be able to use easy and user-friendly SDK.

Scenarios examples

Several well-known Orchestrator usage scenarios are given below. But it should be kept in mind that its capabilities are not limited with these examples.

  • Connecting different systems for transferring data or synchronization.
  • Automation of routine repetitive and long running IT-processes to reduce dependency on employees and their workload.
  • Delegating permissions. Orchestrator allows delegating permissions to any operation and using almost any validations set. For instance, you can give permission to reboot domain controller at weekends from 11 pm till 5 am providing that at least two controllers are turned on without giving any administration rights on these servers.
  • Automating problems solution. Solving of many routine tasks often can be automated. For example: restart of services in specified sequence on different servers, check of logs, clearing cash, performing additional actions.
  • Communication link between security levels. Two independent Orchestrator systems can work within infrastructures with different security levels (e.g. workplace network and isolated segment) using any solution for communication, for instance shared folder with text files or even USB-drives, and validating received data.
  • Virtualization management. Orchestrator is used to manage virtualization and related systems at different levels, from several Hyper-V servers to solutions of country-wide public cloud.
  • Depository of automation scripts. Eventually Orchestrator will benefit even though you move existing automation scripts, e.g. PowerShell ones, into it. This will provide consolidation of separated mechanisms and simplifying their monitoring and support.