Site Replication w/ multi connections

cashew

Let's say you have two sites created. You have a T1 line and a backup ISDN line between the sites. You create two site links. You assign one cost lower than the other. The obvious would be assign the T1 the lower cost. My question is how do you specify which connection to use on the site link? If there are two site links with the same sites for the connection, how does it know which connection to use? I know it chooses the lower cost first, but how do I assign the fast connection to lower cost site link?

royal

It's only logical, not physical. Site links basically say, "You are allowed to talk to this site." Now for the actual data connectivity, that is dependent on your layer 3 network routing architecture. So basically, you still want to try to mirror your physical architecture so a T3 would lets say be a cost of 10 while a T1 would be a cost of 20. This will change which sites will allow to replicate with each other on a logical level. Because of this logical, "You can replicate with this specific site," it will of course use the connection that links 1 site with another site, which is taken care of on the layer 3 side of things.

Does this help?

cashew

It makes a little more sense now, but I'm trying to figure out how redundancy is involved in this. So what you're saying is I would have to create two site links. One for the T1 say with a cost of 10 and another for the DSL connection with a cost of 20. For the T1 I would add both the sites to the connector. The point where I'm confused is that both connections are directly connected to each site. How would I extend the path for the DSL link if I only have two sites?

royal

Well, Site links connect one site to another. So if you had let's say 2 Data Centers, Chicago and Detroit which are connected with a T3. You'd create a Site Link called something like CHI-DET with a cost of 10. Then let's say you had a Site called Maine which connects to the Detroit Data Center via a T1. You'd create a 2nd Site Link called DET-MAI with a cost of 20. Now since there's a site link DET-MAI, Maine will directly replicate with DET site. Site Links are transitive by default. So because DET and MAI have a site link, both with replicate with each other. Now if DET site were to go down, since DET has a site link directly to Chicago, MAI would be able to directly replicate with Chicago due to the site link transivity. So in normal circumstances, since DET would replicate directly with MAI, the MAI bridgehead DC would directly connect to the DET bridgehead DC and would use layer 3 routing to send the data. If DET were to go down, becuase of the site link transitivity, MAI would then send data directly to CHI.

Ahriakin

I think the problem is you are viewing site links on a line by line basis which is not accurate, you take the connectivity between sites as a whole when creating links. The redundancy considerations between your main and backup lines are handled by whatever network services you are using to perform your routing and connectivity (whether it's a hardware firewall or connection decisions handled by your servers). Basically AD via the ISTG will decide which is the most efficient site/subnet to replicate with, not the actual connection mechanism from a choice of multiple lines at one site - your only real input as long as you want the ISTG to do it's thing is to assign an overall cost to the link which (afaik) cannot react dynamically to the fact that your main line has failed and you are now using a slower backup line - though I guess if there are significant delays and/or failures it will move to a different link (I've always wondered if/what network conditions affect the ISTG decisions...)

royal

Yep. Your site links don't do the actual determination. It just helps build the underlining infrastructure. Then when the Knowledge Consistency Checker runs (every 15 minutes), it'll create the connection objects that actually tell what servers can replicate based on your Site Links. When a site DC goes down, the KCC will actually re-create the connection objects. The KCC talks to the Intersite Topology Generator (ISTG) which actually helps determine which DC will become a bridgehead server.