IdoNotes (and sleep)

Replication Topology 101 - the basics

Recently this has become a point of, well not frustration, but amazement.  I think I finally got ahold of the answer today though.  When admins are new in a small environment, they don't always get the training they need on how to grow the domain.  So they do what they know best, just go and make it work.  Unfortunately, once your domain starts growing too fast and large, the lack of the basic training becomes the Achilles heel.  So I took it upon myself to right the wrong by throwing this little primer out there.  Oh, there will be some to follow.  This is to get the feet wet of those that need it.

There are a few options of topology design when you have multiple servers in a Domino domain.  You can classify the architecture in a few different ways:

• Hub & Spoke - A typical design where a central server pushes and controls changes to all the servers around it.  You update one central source and everyone gets happy eventually.  But, if there are too many spokes, you can have times where the hub cannot reach all the servers during a cycle.  So you moved to the next couple ways.  The other downside relies on one central server for all updates.  If the hub dies, so does the topology.
• Multiple Hub & Spoke - Here there is more than one hub, possibly even in a cluster, that handles the updates to their own sets of spokes.  This allows redundancy for the centralized architecture and lets the servers make the rounds updating the spokes.  This works well in a good LAN speed environment.  The downside, not too many if the central hubs are in a cluster.  That way data can pass across spokes fairly quickly on opposite sides.  If there is no cluster, see above.
• Tiered (Binary Tree) - Taking the hub and spoke idea a bit different, a central servers updates two or a few servers.  Those servers update two or more each and so on down the pyramid.  This works well if you have some good network connections to a few servers and then those have some decent speed to downstream servers without the top having that speed access.  Otherwise you could go back to hub and spoke.  The downside is that in a large tiered environment, it can take some time for a change to go up and down the tree if they do not share a parent server all the way to the top.  I have seen some tiers that cross somewhere in the middle to alleviate that and leave the top server for administration and NAB master.
• Ring  - Simple enough, servers call each other in a circle updating, adding and deleting as it goes.  The downside relies on a large ring where it can take some time to get all the way around.  Also, if one server in the ring goes down, so goes the cycle.
• End-to-End -  Basically data starts on one end, passes through multiple servers through replication and then comes right back.  Timing becomes and issue to make sure that data can make it all the way down and back before the next baton is passed.  Think of it as runners that pass the baton, and if one runner takes off too early, who knows where the baton is.
• Meshed (or Peer-to-Peer) - This is basically random servers that call other random servers.  It is all made with some reason when laid out, but you are never quite sure how or when data is getting to somewhere else.  It just shows up.
• Spaghetti - This is the last result and the most frustrating.  Admins just create connection records form one to all the others, over and over again.  For each server in the domain.  Replication conflicts occur, the servers have no idea who owns the database, and design changes fly everywhere.  I usually encounter this when doing audits of domains where they keep patching and adding band-aids instead of fixing the real issue.  No topology design.

blog comments powered by Disqus



On Thursday, July 14th, 2005   by Chris Miller        

Next Document | Previous Document