Static Clusters

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:

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
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.

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.

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).

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.