Share via

System Center Orchestrator enterprise deployment models

  • Article

 

Orchestration across multiple data centers 

Recently I did some research for a customer on possible ways to distribute System Center Orchestrator 2012 over a wide area network,. The customer in this case has global data centers at several sites, but also needs some form of command and control at the enterprise level.  Some information I’ll present here was also contributed by some really smart guys in Microsoft’s Orchestrator product team – Jim Britt and Charles Joy.

In a scenario of orchestration and a wide area network there are at least 3 possible models:

  1. Centralized - A centralized instance of Orchestrator automates IT administration in several remote sites
  2. Decentralized – several instances of Orchestrator, where a localized instance of Orchestrator automates IT administration at each local site
  3. Centralized “Stretch” Instance – a Centralized instance where the Runbook Server role is stretched out to remote data centers 

Below I’ll explain each model and describe the advantages / disadvantages of each model, and some things to be aware of for each.

What makes an Orchestrator instance ?

To set the terminology straight, what do we mean by an Orchestrator INSTANCE ?  Basically an instance is comprised of the four major server roles that Orchestrator requires:

  • SQL Server Database – often provisioned as a dedicated instance on an existing SQL Server
  • Management Server – the management server is the core of Orchestrator authoring, the Runbook Designer and Runbook Tester connect here.
  • Runbook Server – Orchestrator explicitly supports having more than 1 Runbook Server per instance
  • Web Services – this includes the Orchestrator Web Console and Orchestrator Web Services. These are normally deployed as a single unit to one or more servers.

So each instance of Orchestrator will look something like this:

Drawing4 - instance

Note there are all sorts of scalability and high availability models for Orchestrator, and those things have probably been well covered elsewhere. I will refer you to the Scale Planning information at https://technet.microsoft.com/en-us/library/hh420359.aspx.

 

1) The Centralized Model

Drawing1 centr

Here we have a single instance of Orchestrator performing automation at several datacenter sites.

Advantages

  • A single instance is easiest to manage overall
  • Moving solutions from Development into Production will be straight forward
  • It will be easier here to gain a consolidated view of automation results and/or issues across the enterprise

Disadvantages

  • Network bandwidth (especially, high latency) may inhibit effectiveness of your runbook automations
  • Firewalls between datacenters are likely to present a challenge 
  • With a single instance there is more security planning and administration needed, to make sure teams or persons cannot overwrite each other’s projects. There may also be a risk concerning sensitive information that could be stored in Orchestrator (such as passwords).

 

2) The Decentralized Model

Drawing2 decent

Here we have multiple instances of Orchestrator, perhaps one per datacenter. We could even have several instances per datacenter, depending on how various teams work together. The advantages and disadvantages of this approach will be pretty much the opposite of the centralized model.

Advantages

  • Multiple instances provide easy segregation of duties and delegation of ownership / responsibility.
  • Autonomy – if a new project team wants to start up their own instance of Orchestrator it doesn’t require an exception. the model.
  • Runbook servers can be placed closest to the IT servers and fabric being managed.

Disadvantages

  • Runbook synchronization and version control across instances is a manual process in this release. There are no supported automation interfaces for this sort of thing, and no over-arching management across multiple SCOrch instances.
  • If you need to consolidate runbook status or progress across these 2 or more distributed instances, this will require custom work.
  • More instances overall being managed, and these must be patched occasionally, monitored and kept in a healthy state.

 

 

3) The “Stretch Armstrong” Model

Drawing3 - stretch

Here we have a single instance of Orchestrator , but with Runbook Servers from that instance deployed to the remote datacenter sites. This model is TO BE AVOIDED  in most cases, unless you have a highly reliable and speedy network (megabit or above) network connecting your WAN sites.

 

Advantages

  • Ability to manage a single instance of Orchestrator
  • Localized presence of Runbook Server on the same network as the managed servers and/or fabric

Disadvantages

  • Bad Performance - This is a potential SHOW STOPPER if you have a slow WAN in place, because the Runbook Server (RS) will make frequent calls to the database server (DB).
  • It may be more difficult to troubleshoot runbooks – because runbook logging from the runbook server to the Database will require additional bandwidth and may be disabled 
  • It is actually complicated to control precisely which Runbook Server a Runbook will execute on. There is a setting of a Preferred Runbook Server for each runbook. But if you want a single runbook to automatically execute at the most optimal location this is not directly supported today.

The overall impact is you are likely to have bad performance,  and you may not achieve the gain in automation speed and reliability you are seeking.

Design principles for the Orchestrator WAN scenario

There are a few design principles we can highlight here:

  • There is no overarching management console for Orchestrator to provide a consolidated view of multiple instances. In this release each Orchestrator instance is pretty much a stand-alone entity.
  • If you have a Runbook Server on a different network from the Database Server, ensure this network connection is high speed and has a packet latency of no more that 15-20 milliseconds.  Also be aware if your network connection has a high error rate as this can slow down communications.
  • When distributing copies of a runbook to multiple instances, be sure to approach this with centralized authoring in mind. You don’t want to have a set of runbooks being modified by several people in different places.
  • If you need to invoke one Orchestrator instance from a separate instance, use the REST web services. This will be a stateless connection and will traverse a WAN relatively well.  Also there is a Powershell module in Codeplex to allow invoking a runbook via the Web Service from within Powershell. That module is available at https://orchestrator.codeplex.com/releases/view/82959.

 

References

A few additional references to point you in the right direction:

I hope this information is helpful for your System Center Orchestrator endeavors.

Glenn Walton, July 2012

Comments

  • Anonymous
    February 04, 2014
    The comment has been removed