|
Windchill 8.0 Cluster Configuration—
Battle for Performance
By Dmitry Tkach, isLaNd Inc.
Cluster configuration of Windchill 8.0 provides several advantages over a single server, including better performance, scalability, and reliability. In particular, if a Windchill server fails, a load-balancing router can direct requests to the remaining servers. Adding a high-availability algorithm and a failover mechanism to the cluster will improve service quality even further.
In the following example, we have a cluster of three segments—a load-balancing router (A), a persistence storage server (D), Windchill servers (B, C), and a vault server. In this case, A takes requests from clients and distributes them between B and C.
With this in mind, here are some suggestions for implementing Tomcat. It's important to understand Tomcat implementation when you are trying to build a cluster.
- Your session state is all you need during customization. If you want your customization application to fail over successfully, make sure the session is the only thing you need to determine the state of the current request. Storing request data in decentralized sources such as temporary files or class variables will cause Tomcat instances to be inconsistent.
- Always keep clustered Tomcat instances configured the same. Having different Tomcat configurations in your cluster can lead to unexpected consequences. If you are using session replication, you want all instances to behave identically.
- Keep your clusters small. Session replication means a lot of network IO, which you want to reduce as much as possible. If you have 18 Tomcat instances, for example, it is better to create six or even nine clusters (two to three nodes per cluster) than to create two (nine nodes per cluster). The more nodes you have, the more data has to be sent over the wire, potentially creating a bottleneck in your application.
- Be aware of what you store in your session. With almost any session modification, a session message is sent to the other nodes in a cluster, which again increases network IO. So avoid storing temporary variables that last only during the request in your session by using the request to store state (request.setAttribute(), request.getAttribute() as much as possible. In addition, avoid storing large objects in the session. Storing even a 1MB file in a session can seriously delay cluster communication.
- Design with clustering in mind. Clustering means less bang for the buck in terms of hardware resources and performance. For example, having three nodes in a cluster rather than two means that each Tomcat instance stores 50% more session data in memory (assuming an equal session load between instances). The number of replication messages sent between the instances in the cluster also increases. If you design with this in mind, you will not only get great cluster performance but also excellent application performance in a nonclustered environment.
Windchill Components to Install
WINDCHILL_A. Load Balancing Server
WINDCHILL_B. Windchill Server
- Apache – Starting on port 8081 to host the master/wt.properties file for the cluster
- Aphelion – Aphelion Server
- Tomcat – Using port 8009 (changed from default 8010)
- Windchill Server Manager and Two Method Servers – Using ports 5001 to 5009 (with Windchill adapters on ports 18001 and 18002)
- Second Windchill Server Manager and Background Method Server – Using ports 5101 and 3001 (using wt.properties under codebase/master)
(After changes, don't forget to propagate using the command: xconfmanager –p.)
WINDCHILL_C. Windchill Server
- Apache – Don't start
- Tomcat – Using port 8009
- Windchill Server Manager and [n] Method Servers – Using ports 5001 to 5009, with Windchill adapters on ports 18001 and 18002
WINDCHILL_D. Oracle Database Server 9.0
WINDCHILL_E. Vault Server (if you have one)
VMSTAT. Download the jvmstat package http://java.sun.com/performance/jvmstat/) and install it into a directory on the server. It can be renamed to .jar for Unix and extracted using the jar –xvf jvmstat.jar command.
Basic Property File Changes
To start the configuration, we need modify the basic Windchill Server properties.
1. Modify the etc/hosts file to local loopback the following addresses for WINDCHILL_B.COM and WINDCHILL_C.COM:
WINDCHILL_A.organization.CO
2. Install Windchill so that it shares the same LDAP instance between both servers. The LDAP structure can be installed in one of two ways:
Option 1: Install so that the LDAP branch appears as one server for the entire application cluster.
O=[Organization],cn=Application Services,cn=Windchill_A
Option 2: Install each server with its own LDAP branch.
O=[Organization],cn=Application Services,cn=Windchill_B
O=[Organization],cn=Application Services,cn=Windchill_C
With Option 2, the OU=People branch that is created on one of the two nodes needs to be consolidated into a single OU=People branch.
- Edit the com.organization.Windchill_C.Ldap adapter and change the search base from “ou=people,cn=Windchill_C,cn=Application Services,o=Organization” to “ou=people,cn=Windchill_B,cn=Application Services,o=Organization”
- Edit the com.organization.Windchill_C.ldap-pending adapter and change the search base to point to the Windchill_B.ldap-pending path
- For the “com.organization.Windchill_B.servlet” change the Server Name under General Properties to “com.organization.Windchill”
- For the “com.organization.Windchill_B.Windchill” adapter and each of the additional entries with the same name followed by a port number, add another service name called “com.organization.Windchill”
- For the “com.organization.Windchill_B.rpc,” change the Server Name under General Properties to “com.organization.Windchill”
3. Edit the Windchill/tasks/wt/federation/MapCredentials.xml on Windchill_C and change the ldap-pending adapter path to point to Windchill_B’s pending user adapter (may need additional configuration).
4. Edit the property files in site.xconf. The site.xconf files from WINDCHILL_B and WINDCHILL_C are very similar, with the exception of a few properties critical to getting a clustered application server to start using the installation option. These are listed below.
For WINDCHILL_B, the property settings should be:
<Property name="wt.federation.ie.namingService" overridable="true" targetFile="codebase/wt.properties" value="com.organization.Windchill_B.namingService"/>
<Property name="ie.ldap.serviceName" overridable="true" targetFile="codebase/WEB-INF/ieStructProperties.txt" value="Windchill_B.organization.com"/>
<Property name="ie.ldap.propertyBaseDn" overridable="true" targetFile="codebase/WEB-INF/ieStructProperties.txt" value="cn=Windchill_B,cn=Application Services,o=Organization"/>
For WINDCHILL_C, the property settings should be:
<Property name="wt.federation.ie.namingService" overridable="true" targetFile="codebase/wt.properties" value="com.organization.Windchill_C.namingService"/>
<Property name="ie.ldap.serviceName" overridable="true" targetFile="codebase/WEB-INF/ieStructProperties.txt" value="Windchill_C.organization.com"/>
<Property name="ie.ldap.propertyBaseDn" overridable="true" targetFile="codebase/WEB-INF/ieStructProperties.txt" value="cn=Windchill_C,cn=Application Services,o=Organization"/>
Creating the Master Cache wt.properties
The Master Cache Server Manager and Background Method Server(s) use a second wt.properties file on WINDCHILL_B to launch themselves. Unfortunately, the site.xconf file (and consequently the xconfmanager –p) cannot manage this file. As a result, instructions have been placed inside the site.xconf file to create the master/wt.properties file. This essentially involves copying wt.properties from WINDCHILL_B into the codebase/master directory and then making the following edits.
1. After copying the wt.properties file, search for and replace the property values with the values specified below. Disregard the warning messages in this property file because it cannot be modified by site.xconf.
java.rmi.server.hostname=Windchill_B.organization.com
wt.httpgw.hostname=Windchill_A.organization.com
wt.java.classpath.quoted= /opt2/Windchill/codebase/master:$(wt.java.classpath)
wt.manager.log.file= $(wt.logs.dir)$(dir.sep)Master_ServerManager.log # log file
wt.manager.monitor.start.BackgroundMethodServer=1 # of servers
wt.manager.monitor.services=BackgroundMethodServer
wt.manager.port=5101 # check available port
wt.server.codebase=https\://Windchill_A.organization.com/Windchill # https or http
2. Add the following two properties to the end of codebase/master/wt.properties:
wt.cache.master.slaveHosts=Windchill_B.organization.com Windchill_C.organization.com # names slaveHost
wt.method.clusterMonitor=true # turn on cluster monitor if necessary
3. Use the following command to launch the Master Cache instance:
java -cp //Windchill/codebase/master:/Windchill/codebase wt.manager.ServerLauncher
There is a dependency for the Slave Method Servers on WINDCHILL_B and WINDCHILL_C to be able to pull this wt.properties file from http://Windchill_B.organization.com:8182/Windchill/master/wt.properties. This means the Apache instance on WINDCHILL_B must be running before you can start Windchill on the two servers. If you no longer want to use the web server, you can use the file directive to reference a file held locally on both machines.
RMI Tunneling Properties
The current configuration for RMI tunneling simply has wt.rmi.clientSocketFactory and wt.rmi.javarmicgi properties set in site.xconf. Some older PTC documentation indicates that wt.rmi.serverSocketFactory is also required, but this is incorrect. (See updated TPI available at http://www.ptc.com/cs/tpi/128085.htm.)
To use forced RMI tunneling, click on the Java plugin option and add the following value to the advanced settings under parameters:
-Djava.protocol.handler.pkgs=HTTPClient -Dwt.boot.socketFactory=wt.boot.WTRMIHttpToCodebaseSocketFactory
You must also modify the launch scripts for Workgroup Managers and other Java applications to include this value in the Java arguments.
Starting and Stopping Windchill
The clustered components of Windchill start the same as a single server. Starting up the actual application servers using the “Windchill start” command requires a few extra steps.
1. Start the Master Cache Server Manager and Background Method Server first using:
java –cp /Windchill/codebase/master:/Windchill/codebase wt.manager.ServerLauncher
2. Insure that Apache on Windchill_B is started using:
./apachectl start
3. Start the Windchill servers using:
windchill start
4. Start Tomcat using:
tomcat_start
5. On WINDCHILL_C, start Windchill and Tomcat as outlined in (2) and (3) above.
6. To confirm that everything has started successfully, run
windchill wt.method.ClusterMonitor
7. To confirm that the replica sites are properly connected to the master, use the Rebroadcast Configuration to check the connections in wt.properties.
Stopping Windchill can be done in exactly the same manner.
Using Verify.jsp to Confirm Applications Are Running
A file called verify.jsp appears in both Windchill Server directories. Access https://Windchill_A.organization.com/Windchill/verify.jsp, to confirm that all Windchill processes are running properly.
Use Testing Utilities to Monitor Java Process Memory and Server Performance
Database configuration. The database used for these tests was Oracle 9.0. This database includes about 500 Windchill users and about 1,300 document iterations. Another 500 users were defined and some 57,000 additional part objects were loaded.
Concurrent users are those who have logged in and have an authenticated Windchill session in progress. (There were 1,000 concurrent users.) Concurrent transactions are those performed by concurrent users that are simultaneously requesting or posting data to Windchill.
Users = 1,000
Shared Cabinets = 400
Folders = 8,000
Parts (masters) = 120,000
Parts (Iterations) = 50,000
Documents (Masters) = 800
Documents (Iterations) = 2,340
Oracle (configuration) Init.ora
Db_block_buffers = 62400
Shared_pool_size = 96000000
Db_block_size = 16384
Open_cursors = 400
Sort_area_size = 262144
Sort_area_retained_size = 131072
Windchill (configuration) wt.properties
wt.cache.size.SessionCache = 1500
wt.cache.size.AclCache = 2000
wt.cache.size.WTPrincipalCache = 1500
wt.method.loadbalance.activeContext = 10
wt.method.loadbalance.maxRedirects = 6
wt.manager.rmi.maxSockets = 200
wt.method.rmi.maxSockets = 500
No major performance tuning was done to the memory regions used by Tomcat or Windchill (tomcat pooling). 
Dmitry Tkach is software architect at isLaNd Inc. (www.ittechstar.com).
|
