Replication Topology 205 - Tiered (Binary Tree)
Tags :Replication
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
NAB master
The Good:
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.
The Bad:
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.
blog comments powered by Disqus
On Wednesday, November 2nd, 2005 by Chris Miller
