Cisco Cisco Process Orchestrator 3.1 User Guide
16-5
Cisco Process Orchestrator 3.1 User Guide
Chapter 16 Managing High Availability and Resiliency
Advance Planning
•
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.
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.
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.
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.
center. Consider replicating your snapshots to a secondary data center.
Moving to High Availability
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:
content against many targets should consider going to a single database and a multiple high availability
server installation. To migrate to this environment:
Step 1
Upgrade one of the servers directly.
Step 2
Add additional high availability servers (on separate hardware, unrelated to the old 2.x servers).
Step 3
Create automation packs to include your targets from the non-upgraded 2.x environments.
Step 4
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.
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:
content against many targets might not want to use high availability, but it can be accomplished. In this
case, to migrate to this environment:
Step 1
Perform same steps listed above.
Step 2
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.
content back into the new high availability environment.
Storing the Information
Virtually all Process Orchestrator state information is stored in the database. Although there are two
databases, only the configuration database is a hard upstream dependency (see
databases, only the configuration database is a hard upstream dependency (see
) and must be made highly available to prevent a database-based Process
Orchestrator outage. The reporting database is used for auditing and reporting purposes, but Process
Orchestrator does not depend on its presence or on it being up and running.
Orchestrator does not depend on its presence or on it being up and running.
Process Orchestrator supports the following high availability databases:
•
SQL Server Failover Cluster