Gateway Servers and Clustering

The TIBCO Patterns server supports clustering to distribute table data across hardware. A cluster consists of one or more node servers and a single gateway server. Clustering is primarily useful for handling very large tables. A cluster may have up to 64 nodes.

Applications address the gateway server, which then distribute data and workload to the nodes. Most applications might not address nodes directly. This is considered an administrative function.

For a cluster to support checkpoint / restore, each node must be started with the data-persistence directory specified.

For a cluster to support durable-data, each node must be started with a data-persistence directory specified (via -R option) and durable-data enabled (via -B option).

The host machine for the gateway server must be on the authentication list for each of the nodes. See the description of the IP address list in the section: Running the TIBCO Patterns Server.

When starting the servers in a cluster the outgoing IP mode of the gateway (-U option) must match the incoming IP mode of the nodes (-u option). If they do not match the gateway may not be able to communicate with the nodes.

Gateway servers are started with the -g option. This is incompatible with the -R, -A, and -a options for specifying a data-persistence directory or an auto-restore directory (gateway servers do not store tables, character maps, thesauri, or Learn Models; data is kept on the nodes).

The gateway must be started with maxthreads (-t option) equal to the sum of the maxthreads value for each of the nodes. The gateway only distributes the workload. It does not perform any administrative functions such as starting or stopping node servers. It is recommended to start the gateway after all nodes have been started.

Cluster Configuration Files

Cluster configuration files contain only ASCII text. Lines must be 200 characters or less. Empty lines are ignored. Lines containing a hash mark (#) or semicolon are truncated at that character (this allows for commenting). After truncation, leading and trailing whitespace is ignored.

In the following example, square brackets indicate optional items.

The file has two sections.

•

First is the list of named nodes, containing the connection information. Each node has three required lines:

   NODE node-name
   HOST host-name or IP-address
   PORT port-number 

Node names must be unique.

•

Second is the SSL flag. This flag controls whether communications between the gateway and nodes are encrypted.

SSL ENABLED | DISABLED

SSL encryption defaults to disabled. If encryption is enabled, the gateway server must use the correct trust store (see the --trust-store option), and node servers must be launched with SSL configured (see the --port, --private-key, and --public-key options).

To use encryption, all nodes must have encryption enabled.

Sample Configuration File

NODE Alpha
	    host 10.75.99.1
	    port 7051
NODE Beta
	    host 10.75.99.2
	    port 7052
NODE Gamma
	    host 10.75.99.3
	    port 7053
NODE Omega
	    host 10.75.99.3
	    port 7053
SSL ENABLED

Changing a Configuration File

Changes to a configuration file do not take effect until the gateway is restarted or the configuration file is explicitly reloaded through a load cluster configuration command. See TIBCO® Patterns Concepts Guide for a description of the load cluster configuration command.

Monitoring a Cluster

It is recommended to monitor the health of a production cluster. If TIBCO Hawk is not in use, you can write a simple program that can periodically call the cmdstats function on the gateway and every node.