Evaluate System Requirements
Updated: May 13, 2016
Applies To: System Center 2012 SP1 - Orchestrator, System Center 2012 - Orchestrator, System Center 2012 R2 Orchestrator
This section summarizes the ITIL best practices to determine your deployment requirements as it applies to Orchestrator. The following table shows the sequence of evaluation criteria.
1: Define the scope of the project.
2: Identify the tasks you plan to automate.
3: Identify the system workloads for Orchestrator and the tasks you plan to automate.
4: Estimate the number of running jobs per hour.
5: Identify the integration packs required for your environment.
6: Determine security requirements.
7: Determine the number and placement of runbook servers.
8: Determine the requirements for fault tolerance.
9: Identify additional resources required for your deployment.
10: Identify network traffic and potential bottlenecks.
11: Identify your service and operations requirements.
12: Determine the level of integration with other System Center products.
13: Determine authoring requirements.
14: Design your Orchestrator test environment.
15: Design your Orchestrator pre-productions environment.
As part of planning the size of your deployment, begin by identifying your business requirements. This process should define the processes you want to automate by using Orchestrator, the reporting requirements for your organization, and departments impacted by this installation. Identify all applications, services, servers, and manual processes associated with the tasks you want to perform. Prioritize these requirements based on their business impact to prioritize the deployment tasks effectively.
What processes do you plan to automate? Map the processes you intend to automate to the individual steps involved. This level of detail simplifies the task of authoring runbooks. You should identify business-critical processes as requiring more validation effort before relying on the runbook in a production environment.
For the processes you automate, determine how frequently you intend them to run. A runbook that is started one time per day uses significantly fewer resources than a continuously running runbook that is monitoring a system process. Consider both the workload on the Orchestrator system and the automated process. A server that previously responded to manually input requests can behave much differently when the request input occurs by automation.
Consider how much logging of Published Data is required in each of your runbooks. As logging increases, network traffic and load on the server that is hosting the Orchestrator database increases.
When you have individual workloads defined, calculate the total number of jobs that could be running at any point in time. Your system design should take a maximum workload into account. The number and placement of your runbook servers in addition to the resources of the processes you are automating have to be sized to accommodate the largest number of running runbooks.
Devices and applications that are not produced by Microsoft are automated through integration packs. Determine the integration packs required for your automated processes. Each software and hardware product typically requires its own integration pack. If there is no commercially available integration pack, can you create script level automation? Do you have to create custom integration packs for full automation?
Security model planning should include determining if you require your Runbooks servers and resources to be located in more than one Active Directory forest. Is there a cross-domain trust? Are there Operations Manager gateways that require certificates? Review the current security requirements for your environment to identify permission and certificate requirements.
Do you plan to locate runbook servers across wide area network (WAN) links and trust boundaries? If so, you must determine gateway server placement in relationship to the Orchestrator database and runbook servers. While a running management server is not required to start runbooks or save runbook data, an Orchestrator database is required for all active runbook servers.
Determine the level of fault tolerance for your Orchestrator deployment. Depending on your requirements, you can design your Orchestrator environment to be highly available in the case of a single failure.
Determine the requirements for your Orchestrator deployment, and any additional load that increased requirements on processes impacted by automation create. Do you have adequate runbook servers for the number of runbooks that can be running at a given time? Is the Orchestrator database the appropriate size to handle all requests and log Published Data?
Identify all requirements for your environment. Include any data consolidation strategies and requirements for cross-management group, data-retention, data-warehouse size, or fault-tolerance.
Determine if additional bandwidth is required to support the increased traffic the runbook servers and the Orchestrator database generate. Do you have to change any network port settings to accommodate the Orchestrator web service?
Orchestrator fully supports all System Center products such as Service Manager or Operations Manager. Identify existing System Center products in your environment to determine if additional management servers or gateways are required.
Determine where and how authoring of runbooks is carried out. Authoring of runbooks typically occurs on computers isolated from production. However, your business requirements might include the requirement to author runbooks when they were not planned.
If you are authoring in isolation from your production environment, identify the necessary resources to build and test new runbooks.
It is prudent to deploy high impact runbooks in a pre-production environment before introducing the runbook into a production environment. Pre-production environments should closely approximate the full-scale production environment.