Multisite Configuration
The prerequisites for using Multisite Clustering include the following:
- •This feature requires a Multisite license. Be sure to obtain a license to enable this feature in Process Server. The server configuration instructions describe how to enter your license. Enter the license into one server in your Multisite environment.
- •You must use either an Oracle or MySQL database. Currently Multisite supports Oracle Database 11g and MySql.
- •Use of Multisite requires that the Process Server Eventing Service is disabled. Eventing is disabled in a Multisite license.
- •Follow all instructions below to ensure successful Multisite configuration.
What is Multisite?
Process Server supports a site configuration, which allows a cluster of process servers to replicate its database to other databases serving other sites. Each site has a cluster of Process Servers (one or more servers) with a single persistent database, and the site operates independently of other sites. All process instances are available for execution at each site. In the event of a server failure, a process can start execution on one site and complete on a different site. In addition, most Process Server configuration properties are replicated from site to site. This means you can configure server properties in one site, and they are automatically copied to another site's administration console.
The following illustration shows a sample Multisite environment. The database setup is a master-master replication, as shown below. This technique allows you to replicate data in tables across separate databases.
Oracle and MySQL
The procedures you follow when you are using Oracle differ from those you use when using MySQL. Use the following links to jump to the description for your database.
Following these descriptions is a section describing "Pausing Replication When Performing Database Updates. This section applies to Oracle and MySQL.
Database Replication Setup and MultiSite Configuration
The MultiSite page does not show any site information until you set up and configure databases for replication on each site.
For set up and configuration details, refer to the Process Server MultiSite Configuration section within the Sever Install, Configure, and Deploy help.
MultiSite Page Details
The MultiSite page contains the following information.
Field | Explanation |
|---|
Name | Name added to the Site Properties page of the Process Console associated with the site. You can update site properties for the current site; however, you cannot update one site’s properties on another site’s Process Server. Connect to a site’s Process Console using this name. |
Status | Status values are as follows: - - Available—the site is sending heartbeats. If a site was unavailable or failed over, it changes to available when it begins to communicate.
- - Unavailable—the site is not communicating. It has exceeded the maximum number of missed heartbeats set in the Site Properties page. An alert is automatically triggered, and sent to the Monitor Alert Service, if the service is deployed and running. For details, see Monitoring Thresholds, Properties, and Monitor Alert Service. The site is not immediately failed over. You can manually fail over the site, as described in Failing Over a Site Manually.
- - Failed Over—you have manually failed over an unavailable site, as described in Failing Over a Site Manually.
- - Incompatible—the site is using a software version that does not match the other sites.
|
Id | A numeric value in the range of 0 to 127 which uniquely identifies the site (There is a limit of 128 sites). Process Server generates an Id after database replication is configured. |
Description | Description of the site as it appears in the Site Properties page. |
Failing Over a Site Manually
There may be times when inter-site communications go down but sites are still running. In this case, a site is considered unavailable.
When a site becomes unavailable due to a communication error, it is not immediately failed over to another site. Instead, Process Server sets the site status to Unavailable, triggers an alert, and provides a Fail Over action for you to take, if desired.
Once a site has failed over, a new state called Failed Over is displayed, and the Fail Over button is removed.
When the unavailable/failed-over site begins communicating with the other sites (sends a heartbeat), the site automatically becomes available.
Monitor Alert Service
When a site becomes unavailable, an alert is automatically triggered. If Process Server finds a deployed Monitor Alert Service, the service will run. For details, see Monitoring Thresholds, Properties, and Monitor Alert Service.
Site Properties
You can configure the following properties for the site associated with this Process Console. Each Site Properties page must be configured on a Process Server in its own site.
Field | Explanation |
|---|
Name | Type in a short name with no spaces. This name appears in the MultiSite page of each Process Console in all the sites. It also appears in the title area of the Process Console. If no name is provided, the host name defined in the Site Service URL is used. |
Description | Optional. Type in a short description of the site. The description appears in the MultiSite page of each Process Console in all the sites. |
Id | Id assigned to the site by Process Server; this is used in internal communication. |
Process Console URL | Type in the address of the Process Console for this site. The URL is defined during configuration and deployment of the server. The URL is the address that other sites use for a link from within the Process Console. |
Site Service URL | Define how the site should be contacted for multi-site communication. The address will most likely contain the address of the load balancer installed in front of the servers. |
WS-Security Enabled | (Replicated). By default, WS-Security is not enabled. Be sure to configure WS-Security on each node in each site before you enable it for MultiSite. For details on configuring WS-Security, refer to Configuring Process Server for WS-Security. within the Process Server help. If your site environment has another security implementation, you can leave WS-Security disabled. |
Allow Optimistic Deployment of User Contributions | (Replicated). If selected, site locking is not performed when BPR contributions are deployed. This means that you are assuming that the same BPR contribution is not deployed from two sites at exactly the same time, and each site does not need to be locked. Enabling this is useful in a multi-tenant environment because it allows for faster deployments. This option does not apply to system deployments. Sites are always locked for these deployments. |
Heartbeat Interval | (Replicated). Set the frequency in seconds to poll the site for its availability. The default is 15. |
Max Missed Heartbeats | (Replicated). Set the maximum number of missed heartbeats before assuming the site is unavailable. If a site does not respond, the site status changes to Unavailable, and database replication cannot occur. The default is four. |
Expected Database Latency | (Replicated). Set the latency in seconds expected for database replication to occur. The default is five seconds. This value serves as a guideline for anticipated database replication. This setting is necessary for the coordination of site to site communications with database replication. Site to site communication is typically completed in milliseconds while database replication varies, depending on your hardware and other environmental factors. A database latency of five seconds attempts to synchronize messages sent via site communications with database replication every five seconds until synchronization is either successful or the until the database latency timeout is reached. |
Database Latency Timeout | (Replicated). Set the latency timeout value in seconds. The default is 300. This setting indicates that changes made to one site’s database instance have not been replicated to another site within the latency period. If this value is reached, a critical storage error is written to the application Process Server. You can also configure a server property to monitor storage exceptions. For details, see Monitoring Thresholds, Properties, and Monitor Alert Service. |
Site Independent (Non-Replicated) Data and Configuration
All database information is replicated between sites except the following:
- •URL/URN mappings
- •Meta-data about the site, such as communication details, database name, scheduled maintenance
- •Data from the AeLock table, which is a local lock table
- •Engine monitoring for engines in each site’s cluster
Also, starting and stopping a server is confined to one server only.
For process scheduling, a single node is designated from all known sites to be responsible for scheduling. Schedule changes are broadcast between sites so that the scheduler stays in sync with schedule changes made on other sites.
Configuring File Locations for Identity Services and Global Functions
A few configuration tasks require that you specify a file location for certain files. Process Server allows you to specify an absolute path or to specify the location using an environment variable (or similar). In a MultiSite environment, you must ensure that required files have valid path locations for each site. This may mean that you copy a file to each site location or to store a file in a centralized location. The files can include:
- •File-based Identity service.
- •LDAP Identity Service Trusted keystore file.
- •Global Custom functions.
