Administration Guide
Overview Guide
Installation Guide
Previous Next Contents



What is a Cluster?
A cluster is a group of Netscape Application Servers that synchronizes data. Servers in a cluster are connected by the same reliable network.

Data Synchronization is Optional
By default, servers do not participate in data synchronization. You can set up a cluster when you install your Netscape Application Servers or after installation.

To set up data synchronization between servers, you

Synchronization Server Roles
Each server that participates in data synchronization can be set up to fill any one of the roles described in the following table.
Server Role

Description
Sync Server

Any Netscape Application Server that can potentially become a Sync Primary. The Sync Server category contains the Sync Primary, Sync Backups and Sync Alternates.

All Sync Servers are listed in the SyncServers registry key on each server in the cluster.

Sync Primary
The server that is the primary data store, to which all other cluster members communicate for the latest distributed data information.

The first Netscape Application Server to be started in a cluster must be a Sync Server, and that Sync Server becomes the Sync Primary for the cluster simply because it is started first.

Sync Backup
Any number of Sync Servers, up to a maximum number (MaxBackups) set by you, that mirrors the information on the Sync Primary. Because each Sync Backup increases the load on the cluster, weigh safety against performance impacts when deciding how many backups to assign.

If the Sync Primary becomes inaccessible, the Sync Backup with the highest priority (which is the lowest integer value) relative to other Sync Backups becomes the next Sync Primary.

Sync Alternate
A server listed in the SyncServers registry key that is eligible to become a Sync Backup. If the number of Sync Backups falls below the set maximum, the Sync Alternate with the highest priority relative to other Sync Alternates is promoted to Sync Backup.

Each Sync Alternate performs work similar to that of a Sync Local until the Sync Alternate is promoted to Sync Backup.
Sync Local

A server that uses data synchronization services, but is not eligible to become a Sync Primary, Sync Backup, or Sync Alternate. Sync Locals can use, create, and destroy all distributed data, but are never responsible for maintaining that data.

Sync Locals are not listed in the SyncServers registry key. However, the SyncServers list in every registry in the cluster contains identification and priority information for each of the Sync Servers in the cluster.

Each Sync Local contacts each of the servers listed in its SyncServers registry key until the Sync Local finds the Sync Primary, at which time the Sync Local becomes active in the cluster. If the Sync Local goes through its entire SyncServers registry key without finding the Sync Primary, the Sync Local assumes that the cluster is down, and acts as a local server.

Sync Locals communicate only with the Sync Primary, and the other servers in the cluster are not aware of them.

How a Cluster Communicates
Before the servers in a cluster can communicate with each other, each server has to know what cluster it belongs to. A Netscape Application Server becomes an active part of a cluster when you map its synchronizer to the cluster (see "Mapping the Synchronizer to the Cluster" for more information).

When an AppLogic requests a write to a distributed data source, the write occurs first on the Sync Primary. When the data changes on the Sync Primary, the Sync Primary immediately updates the Sync Backups.

Although you can define as many clusters as you like, the synchronizer for each Netscape Application Server can be mapped to only one cluster at a time.

Information Flow Within a Cluster
Sync Backups, Sync Alternates, and Sync Locals communicate with the Sync Primary in a star configuration, as the following illustration shows:

In this illustration, notice that all servers are communicating with the Sync Primary, although the Sync Backups communicate with it most closely. Also, notice that no Sync Local is assigned a priority number.

Note also that the illustration is an ideal representation of a cluster that has probably just started and has not experienced failover, in that the priority numbers correspond gracefully with the currently-assigned roles.

GXCONN Communication Protocol
Servers in a cluster communicate using the GXCONN communication protocol.

General Steps for Managing Clusters
The specific procedures for setting up and managing clusters are covered in "Modifying the Default Cluster for Fast Cluster Set Up," "Defining One or More Clusters," and "Mapping the Synchronizer to the Cluster." The general steps listed below are an overview of the procedures.

  1. Decide which servers will participate in a synchronization group (cluster), and which of those servers will be Sync Servers, eligible to act as the Sync Primary and as Sync Backups, and which will be Sync Locals.

  2. Edit the registry keys under Clusters and ClusterName on one of the Sync Servers, and then duplicate those edits in the registries of all the other servers in the cluster (including the Sync Locals).

    1. Create the registry keys that will contain synchronization information, if necessary.

    2. Edit the SyncServers registry key to contain identification information and the priority setting for each Sync Server in the cluster. Often, the larger and more powerful servers are chosen to be the highest-priority Sync Servers.

    3. Set the MaxBackups registry key to the number of Sync Backups. Sync Backups are servers that duplicate the data on the Sync Primary.

  3. Enter the name of the cluster in the ClusterName key.

    4. Make sure that the registry keys under Clusters and ClusterName are identical on all servers in the cluster, including the Sync Locals. Each SyncServers registry key must list the same Sync Servers with the same priority numbers, or the cluster will not function properly. See "Copying Cluster Definitions Between Servers" for a shortcut that duplicates the cluster information in the initial edited registry.

  4. Start the Sync Server that will be the Sync Primary. The server that you want to be the Sync Primary must always be the first server to be started in the cluster, and it becomes the Sync Primary simply because it started first.

  5. After starting the Sync Primary, start the other servers (including the Sync Locals). Although the starting order is not mandated after the Sync Primary starts, it is a good practice to start the Sync Servers in priority order, and then to start the Sync Locals.

    1. Start the servers that will become the Sync Backups, up to the value of MaxBackups. By default, the next servers listed in the SyncServer key that start, up to the value stored under the MaxBackups registry key, will become the Sync Backups.

    2. After MaxBackups number of servers have started, remaining Sync Servers that start become Sync Alternates.

    3. All servers not listed in the SyncServers registry key become Sync Locals. Sync Locals are part of the cluster simply because each is mapped to the cluster and the SyncServers registry key on each contains a list of all the Sync Servers in the cluster.
 

© Copyright 1998 Netscape Communications Corporation