Cisco Cisco Process Orchestrator 3.0 Guida Utente

A single-server environment does not provide high availability, so you should plan to implement 
multiple Process Orchestrator active-active servers. When you are planning your Process Orchestrator 
environment, consider these recommendations:

Be sure that all Process Orchestrator servers have similar hardware and software configurations; that 
is, the same (or similar) amounts of memory, number of CPUs, OS levels, and so on.

Cisco Process Orchestrator’s high availability solution does not take hardware or operating system 
differences into account when distributing load. When new work arrives to be executed by Cisco 
Process Orchestrator, only the current load (the number of process instances and monitored triggers) 
is considered. Over time, more work will be assigned to less loaded or more capable Process 
Orchestrator servers, but the amount of memory, CPUs, or storage is not directly taken into account 
when assigning work. 

Install the Process Orchestrator servers on virtual machines backed by networked storage. Using this 
approach, if a host fails, the VM can be migrated to a new host using a tool such as vCenter. Many 
customers find this method of fault tolerance preferable because the host can change to another site 
in disaster recovery situations. 

VM farms tend to be sets of machines connected to the same storage, and might be in the same data 
center. Consider replicating your snapshots to a secondary data center.

Customers running multiple database and Process Orchestrator 2.x server installations running the same 
content against many targets should consider going to a single database and a multiple high availability 
server installation. To migrate to this environment:

Upgrade one of the servers directly.

Add additional high availability servers (on separate hardware, unrelated to the old 2.x servers).

Create automation packs to include your 

s from the non-upgraded 2.x environments.

One by one, shutdown your old 2.x servers and at the same time, import the automation packs with 
targets from those servers into the new high availability environment.

Customers running multiple database and Process Orchestrator 2.x server installations running different 
content against many targets might not want to use high availability, but it can be accomplished. In this 
case, to migrate to this environment:

Perform same steps listed above.

Export whatever content you need from each 2.x server (in addition to the targets), then import the 
content back into the new high availability environment.