This section provides detailed information for installing and configuring a cluster Windchill system with attention to file vault management and data loading.

A cluster is a collection of computers that can be accessed independently or as a single unit. The cluster can take a single work unit, defined as either an HTTP request or RMI method call, and distribute it to one of many Windchill servers.

The main advantages of a cluster over a single server are increased performance, scalability, and reliability. Performance increases because Windchill server processes have less competition on a given node. The system is scalable. As the load increases, additional Windchill servers can be added. This scalability also provides a more reliable system. When a Windchill server fails, requests can be directed to the remaining servers.

The figure that follows shows a typical cluster configuration. In this figure, five computers (A, B, C, D, and E) work together to increase performance, scalability, and reliability.

A typical Windchill cluster consists of three segments:

As shown in the diagram, the Windchill cluster interacts with a server where the physical vault is maintained (E). Setting up the Windchill interaction with a file server is not discussed in this set of topics. For setup details, see File Server Administrator.

The load balancing router takes requests from clients and distributes them among one of the many Windchill servers. To the rest of the network, this router appears as a single Windchill server. For information on the load balancer, see the section Configuring a Load Balancing Router.

Windchill servers that participate in a cluster are similar to a simple autonomous Windchill server except that they share a database and caching mechanism with other members of the cluster. Since caches are subject to updates from a top-level main cache, these server nodes are also known as cache clients. They share a common DNS name to direct clients to the cluster instead of the individual Windchill server for subsequent requests.

The persistence storage server machine contains the relational database as well as the main Windchill cache and background method servers. For any deployment, a single database is used to store persistent data for the entire cluster even when the database is clustered. For a clustered deployment, a separate server manager must be deployed and designated as the “Main Cache”. This server manager has the responsibility of synchronizing the caches across all client caches.

The server-manager process on each node in the cluster manages the caching. In the previous figure, the server-manager running on the persistence storage server also serves as the cluster main cache. Additional properties must be set in the wt.properties file to properly configure the distributed caching mechanism.

At any given point in time, there is a single cache main server manager. By default, this main server manager is initially selected through negotiation with other server managers. Generally, this is the server manager on the first cluster node that is started. After the cluster selects a main cache node, this server manager remains the main cache until it becomes unreachable. If this occurs, another server manager automatically becomes the main server manager. After a switch in main cache nodes, if the previous main server manager becomes reachable, it reverts to a secondary cache status.

The load balancing router takes requests from clients and distributes them among the available Windchill servers. This router may also act as a firewall, separating the Windchill cluster from the rest of the network. To the rest of the network, this router appears as a single Windchill server.

End-users typically access a Windchill cluster through a load balancing router. The load balancing router dispatches their requests across several machines in an attempt to distribute the workload evenly. However, configuring Affinity within the load balancer can take advantage of the servlet engine session cache and processing multi-step operations. This configuration directs subsequent related requests to the same servlet engine and Method Server for processing.

The load balancing router must load balance any and all TCP traffic and IP traffic that is to be allowed across this boundary. Thus, if you limit the traffic to HTTP or HTTPS (tunneling RMI over HTTP or HTTPS, etc), then you only need to have a load balancing router that handles HTTP or HTTPS. If you allow other TCP communication and IP communication across this boundary, such as direct RMI traffic, then it too must be load balanced.

The method servers have no additional affinity requirements when tunneling RMI over HTTP or HTTPS. However, the load balancer must still properly enforce affinity for HTTP and HTTPS traffic which will include tunneled traffic. If direct RMI ports are load balanced by the routers, then the load balancer must enforce affinity for these ports. Since RMI is not a protocol that can handle cookies or other tags for affinity purposes, this usually will be enforced using client host affinity over a period of time.

Windchill also has affinity requirements of its servlet engines however, and requires either client host or session affinity. Client host affinity maps all requests from a given host during a given time period to the same servlet engine JVM, thus ensuring that all session data from the host remains with that JVM. Session affinity is more precise and is the best match for what servlet engines actually require.

Whether the IP load balancing router is responsible for ensuring this affinity depends on your architecture. For example, you could have an IP load balancing router balancing between several machines, each running an Apache-based web server with mod_jk and load balancing over all servlet engines on all of the machines. If you do this correctly, then mod_jk ensures session affinity and your IP load balancer does not have to ensure any affinity. However, incoming requests are likely to be directed to an arbitrary web server for initial processing. The requests are then directed to a servlet engine on a different machine for subsequent processing.

Alternatively, you could use an Apache-based web server and mod_jk as your load balancer, having just one web server on a "load balancer" machine and having it send out requests to the servlet engines on the cluster nodes. This approach requires that all non-HTTP(S) traffic be tunneled over HTTP(S).

The easiest approach is to configure the load balancing router with host affinity for all TCP connections and IP connections. This ensures that all requests from a specific client host will, during a specific period of time, be handled by the same node of the cluster.

Client systems typically access a Windchill cluster server environment through a load balancing router. Due to security concerns or limitation of ports, you need to determine which TCP ports and IP ports must be open for the load balancer, when a cluster environment integrates Workgroup managers and Windchill visualization.

The requirements on the communication between client and server are complicated by the many possible communication environments. To simplify the requirement of ports for the communication between client and server, this discussion makes the following assumptions:

If you tunnel RMI over HTTP or HTTPS, then only HTTP or HTTPS ports need to be open on the load balancer. Otherwise, the ports that need to be open depend on the customer environment:

For details on the ports set through the PTC Solution Installer (PSI), see Prerequisite Checklist.

PTC recommends two classes of cluster configurations depending on individual needs. In the first class of cluster configuration is where every node in the cluster is identical. Each node in the cluster can negotiate to become a main cache node. This type of cluster is referred to as identical nodes cluster. In the second class of cluster configuration is where separate secondary and main nodes are configured. This allows for a possibility of separate dedicated main cache and dedicated foreground secondary cache nodes. This type of cluster is referred to as a dedicated mains cluster.

All cluster nodes of Windchill must be configured similarly so that any one of them can respond to the same request with the same response. Clients access this system as single server though there are several servers responding to the requests in the background.

To configure a Windchill environment for clustering, review the following sections and complete the instructions in the sections as they apply to your environment:

In the example configuration, all cluster nodes are configured identically. A single cluster node that is properly configured can be synchronized to other nodes and can perform within the cluster without any modifications.

The configuration requires that all HTTP access goes through the main IP load balancer. The following Example Properties section lists the minimum configuration properties. Detailed descriptions of the properties can be found in the section Understanding Properties Used in Examples.

All cluster nodes require the following properties (found in the wt.properties file):

In the example configuration, all cluster nodes are configured identically. However, only specific nodes are allowed to become a cluster node. A single cluster node that is properly configured can be synchronized to other nodes and can perform within the cluster without any modifications.

The configuration requires that all HTTP access goes through the main IP load balancer. The following Example Properties section lists the minimum configuration properties. Detailed descriptions of the properties can be found in the section Understanding Properties Used in Examples.

All cluster nodes require the following properties (found in the wt.properties file):

In the example diagram, only host D is allowed to be a the main cache. If you have multiple hosts that you want to allow as the main cache, those host names can be added to the wt.cache.main.hostname property value.

The following table lists the properties used in the previous examples and describes their use:

A Windchill adapter is automatically configured for foreground method servers running on the Windchill secondary cache nodes. A single Windchill adapter is configured during the installation phase. Whenever a Windchill adapter starts, its configured port range is compared to the port range used by the Windchill RMI (as configured by the wt.method.minPort and wt.method.maxPort wt.property values). If the configured port range is smaller than the one in use by Windchill RMI, then it automatically increases to match in size.

For more information, see the section Windchill Adapter for complete details on configuring the Windchill adapter.

There is no restriction on how many MethodServer and BackgroundMethodServer instances are allowed on each cluster node. In a cluster with a dedicated main node, PTC recommends that background queue processing be dedicated to BackgroundMethodServer instances on the main nodes. For more information, see the following sections: