Replication Topology 205 - Tiered (Binary Tree)
Prerequisite: You must have completed Replication Topology 101 - the basics (which was done in July) and 102 and 103 and 104 now also before completing this course. :-) I know I have taken my time on these but I find too many other things come up, plus it keeps you waiting for the next one.
Welcome to the graduate level course material (as Tom Duff said it should be) !!!!
HOMEWORK: From now on you are required to draw out the topology for your environment at each level. Even if you are doing it for future planning or hypothetical looks. This is a learning experience folks.
Here is what I said about Tiered (Binary Tree) topology:
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
A well thought out tree keep the data flowing; makes it locally available and with multiple tiers it can move between localities even if the connection is down to the main servers. This is a great solution for multi-continent deployments or in countries that have Internet connectivity issues to the outside world. Imagine a tier in America, Europe and Australia. All the top level servers from each country then tier up to one other server in China. If the link to China goes down, each country will still have the updates from all sites within itself. Later, the rest of the world will catch up.
This idea also gets around timezone difficulties. Data is most important to other sites in your timezone (in most instances, yes there are some corporate apps that rely on HQ but that is a side class). So moving it between multiple cities to the top tier in that country keeps people happy. You could some more tier levels into the mix, but for homework, draw one out for your company, no matter how big.
I said it best in the outline from the very start. You can spend an enormous amount of time if you build the pyramid too large. Imagine how it was done in ancient times. One large stone was carried from the bottom to the top, very slowly. You knew it was coming, you could see it in the distance down the great pyramid, but it took forever to get to the top so you could build on it. Then the call has to go all the way back down the other side to let them know it was there. Companies try to get around this by speeding up the cycle time in between each hop. However, your schedule could become faster than the replication time of the data and you start to miss things until it can catch up. I recently saw this with a DMZ at one corner of the pyramid. During the day it was trying to keep up the fast 7 minute cycle that was set. However, they noticed some data not showing for 2 plus hours. Looking in the logs we saw that it was never finishing at the time the most data was being updated all over. Then when the day slowed down or at night, it could easily catch up. This also had to do with bandwidth being utilized, but it all adds to the issue.
We had strike #3 already, I guess this is the start of out #2 in the graduate level class.