- 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 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:
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.
CommuniGate® Pro Guide. Copyright © 1998-2006, Stalker Software, Inc.