Guidewire PolicyCenter cluster installations

The typical PolicyCenter cluster consists of two or more PolicyCenter servers, each of which has one or more server roles, and a load balancer. In general, a PolicyCenter cluster contains the following types of servers:

  • One or more user interface servers (online servers) that process web requests, perform business transactions, and render web pages.
  • One or more non-user interface servers (offline servers) that manage batch processing, work queues, scheduling, message destinations, and startable services (plugins).
  • A load balancer that manages user interface requests if there are multiple user interface servers.

Technically, non-user interface servers can also process web requests from business users, meaning that they can also act as user interface servers. However, Guidewire recommends that you avoid redirecting business user web requests to non-user interface servers to simplify the management of the cluster.

Cluster membership

As a PolicyCenter server joins the cluster, it updates a membership table in the PolicyCenter database. All cluster servers periodically poll this table to determine cluster membership.

Cluster availability

To ensure a high degree of availability, Guidewire recommends that the cluster configuration include two or more servers with each specific server role. You also need to provide ample capacity for running role-constrained items such as message destinations or batch processes.

Cluster monitoring

Guidewire provides cluster monitoring screens that are available to those with privileges to view the Server Tools screens:

  • The Server Tools Cluster Members screens provide information on each server in the cluster.
  • The Server Tools Cluster Components screen provides information on the components running on a given server.

Also, there are system_tools command options that provide information on cluster members and components in the PolicyCenter cluster.

Cluster cache usage

Cluster inter-communication ensures that if an object changes in one cluster member cache, that member sends a cache invalidation message to the other members of the cluster. This message instructs the other cluster members to tag the cache entry for the object as obsolete and evict it from the cache. The next time a PolicyCenter server needs the object, it reloads the object value directly from the database. This mechanism is different from full cache synchronization, in which a server broadcasts the new value of the object to other cluster members.

It is possible to lose message packets. Network failures or other issues also can disrupt communication between cluster members. Such cases can result in cache eviction messages not being propagated to all cluster members. As a result, one or more cluster members can contain stale cache entries.

Guidewire applications implement a data versioning mechanism to prevent data corruption. One or more version mismatches indicates that one or more objects have changed since PolicyCenter last accessed the entities. This mismatch results in PolicyCenter issuing a Concurrent Data Change Exception (CDCE). The user or batch job can then re-issue a change based on the latest values entered.