Static Clusters

Shared Domains Backend and Frontend Server Settings Adding Servers to a Static Cluster Withdrawing Servers from a Static Cluster Backend Failover in a Static Cluster Static Clusters can be used to handle extremely large (practically unlimited) sites, providing 24x7 site access. Static Clusters are loosely-coupled systems: each Server works almost independently of the other Servers. The Static Cluster setup is an extension of the CommuniGate Pro Distributed Domains configuration. If a Backend Server fails, the Static Cluster continues to operate, and access to Accounts on the failed Server can be restored within 2-10 minutes (depending on how easily the disk storage can be reassigned and how fast the Routing tables/Directory can be updated, or how quickly a stand-by Server can be switched on).

Shared Domains

Shared Domains in a Static Cluster are created in the same way as regular CommuniGate Pro Domains. Each Server in a Static Cluster contains a subset of all Shared Domain Accounts. As a result, each Shared Domain Account has its "Host Server". Only the Host Server needs physical access to the Account data, so Static Clusters can use regular, non-shared disk storage. Static Clusters rely on some method that allows each Cluster Server to learn the name of the Host Server for any Shared Domain account. This type of routing can be implemented using a shared Directory Server, in the same way it is implemented for Distributed Domains:

Backend and Frontend Server Settings

To set a Static Cluster:

• Install and configure CommuniGate Pro Software on all Servers that will take part in a Static Cluster.
• Configure all Servers to use one Shared Directory for all Shared Domains.
• Create Shared Domains on all (Backend and Frontend) Servers in the same way regular, non-shared Domains are created.
• Use the WebAdmin Interface to open the Settings->General->Cluster page on each Server, and enter the names (Main Domain Names) of all Backend Servers and the IP addresses of those Servers:

Static Clustering
Static Member Name Member Address

If an address is routed to a domain listed in this table, the CommuniGate Pro Server uses its Clustering mechanism to connect to the Backend server at the specified address and performs the requested operations on that Backend server.

The logical setup of the Backend and Frontend Servers is the same - you simply do not create Shared Domain Accounts on any Frontend Server, but create them on your Backend Servers.

Computers in a Static Cluster can use different operating systems.

A complete Frontend-Backend Static Cluster configuration uses Load Balancers and several separate networks:

In a simplified configuration, you can connect Frontend Servers directly to the Internet, and balance the load using the DNS round-robin mechanism. In this case, it is highly recommended to install a firewall between Frontend and Backend Servers.

Adding Servers to a Static Cluster

You can add Frontend and Backend Servers to a Static Cluster at any time.

To add a Server to a Static Cluster:

• Properly configure the Server (see above): configure it to access the Shared Directory, create Shared Domains, and set the Clustering Settings.
• Add the IP address of the new Server to the Backend or Frontend Addresses tables of other Cluster Members (if you have specified proper network address ranges for those tables, this step is not needed).
• If the new Server is a Backend one, add its name and IP Address to the Static Clustering tables on other Servers.

After a new Frontend Server is configured and added to the Static Cluster, reconfigure the Load Balancer or the round-robin DNS server to direct incoming requests to the new Server, too.

After a new Backend Server is configured and added to the Static Cluster, you can start creating Accounts in its Shared Domains.

Withdrawing a Server from a Static Cluster

If you decide to shut down a Static Cluster Backend Server, all Accounts hosted on that Server become unavailable. Incoming messages to unavailable Accounts will be collected in the Frontend Server queues, and they will be delivered as soon as the Backend Server is added back or these Accounts become available on a different Backend Server (see below).

Backend Failover in a Static Cluster

If a Backend Server in a Static Cluster is shut down, all Accounts hosted on that Server become unavailable (there is no interrupt in service for Accounts hosted on other Backend Servers).

To restore access to the Accounts hosted on the failed Server, its Account Storage should be connected to any other Backend server. You can either:

• physically connect the disk storage to some other Backend Server;
• use dual-access RAID devices and tell the sibling Server to take over that device;
• use a file server partition or file directory for each Backend Account Storage, and mount that directory on some other Backend Server in case of a Backend Server failure.

After a sibling Backend server gets physical access to Account Storage of the failed server, you should modify the Directory so all Servers will contact the new "home" for Accounts in that Storage. This can be done by an LDAP utility that modifies all records in the Domains Subtree that contain the name of the failed Server as the hostServer attribute value. The utility should set the attribute value to the name of the new Host Server, and should add the oldHostServer attribute with the name of the original Host Server. This additional attribute will allow you to restore the hostServer attribute value after the original Host Server is restored and the Account Storage is reconnected to it. If the CommuniGate Pro is used as the site Directory Server, 500,000 Directory records can be modified within 1-2 minutes.