This is a powerful yet under-utilized feature in Domino. It’s not complicated. In a replication connection document, you can use the Domino server cluster name instead of a server name in the “Destination server” field.
There’s a couple of small caveats, the cluster.ncf on the source server needs to be up to date, and the source server needs to be able to resolve the DNS name of all of the Domino servers in the cluster to work efficiently.
Apart from that, it just works.
“Why would I change anything related to connection documents if they already work”?
Well the question I’d ask you is: do they actually work as well as they could? Do you ever see replication lags? Users complaining documents are sometimes taking a while to catch up across servers particularly on databases running into hundreds of thousands of documents? Do you see a heap of unnecessary replication traffic in your console logs?
The instinct for Admins in this case can be to add extra connection documents or lower the interval in-between replication. This can often make the problem worse.
So a simple example would be one 4 Domino server cluster, connecting to another 4 Domino server cluster. If you have each server in the cluster connecting to every other server in the other cluster, from each direction, it’s potentially 32 connection documents for replication for inter cluster traffic (that’s not counting connection documents within each cluster). Many admins will double up and have another 32 for mail routing. So 64 in total.
If these are on short intervals that’s a lot of unnecessary traffic and can be highly inefficient. Sometimes there’ll actually be double the replication connection documents because “critical apps” are given their own dedicated replication connection documents. so you end up with about 100 connection documents in this scenario. This is not an exaggeration. From bitter experience, what generally happens is:
No Admin is afraid to add connection documents but most are terrified of deleting one.
You can actually use as little as just 4 connection documents in this scenario and have full inter cluster failover (assuming all nodes within a cluster can connect to each other). If they’re in the same NNN you don’t need two bidrectional connection documents for NRPC mail.
You just need bi-directional replication (i.e. Push/Pull) between two servers which just requires one server initiating a bi-directional replication to the other. In the vast majority of cases, if the interval is relatively short already so you won’t require a connection initiated from the other direction as well. My advice in most cases would be less server-to-server connections is usually better to simplify your topology (sometimes this isn’t always the best idea but in my experience mostly it is particularly where the intervals are short).
The “once burned twice shy admin” knows that stuff breaks if you change connection documents. I agree if you don’t really understand the topology, contact someone who does. Plan your changes. Document them. Peer review them. Have a rollback plan. Test them. Implement them. Verify they worked as you expected (or not). But do review your topology and you can improve efficiency in your environment drastically.
Where this it valuable is when there are multiple clusters in an environment and a relatively complex topology.
You can also look at tuning this further by manually changing cluster.ncf (you can just RDP/putty to the source server host and manually edit in a text editor) , so that one server in a cluster isn’t being hit for every connection.
Hope you found this useful.
Cormac McCarthy – Domino People Ltd.