Intersite Replication Essentials
While intrasite replication is focused on speed, intersite replication is focused on efficiency. The primary goal of intersite replication is to transfer replication information between sites while making the most efficient use of the available resources. With efficiency as a goal, intersite replication traffic uses designated bridgehead servers and a default configuration that is scheduled rather than automatic, and compressed rather than uncompressed.
• With designated bridgehead servers, the ISTG limits the points of replication between sites. Instead of allowing all the domain controllers in one site to replicate with all the domain controllers in another site, the ISTG designates a limited number of domain controllers as bridgehead servers. These domain controllers are then the only ones used to replicate information between sites.
• With scheduled replication, you can set the valid times during which replication can occur and the replication frequency within this scheduled interval. By default, when you configure intersite replication, replication is scheduled to occur every 180 minutes 24 hours a day. When there's limited bandwidth between sites, you might want to change the default schedule to better accommodate the users who also use the link. For example, you might want to allow replication to occur every 180 minutes 24 hours a day on Saturday and Sunday, but during the week set the schedule to allow more bandwidth during the day. For example, you might set replication to occur every 60 minutes from 6 A.M. to 8 A.M. and from 7 P.M. to 3 A.M. Monday through Friday.
• With compression, replication traffic is compressed 85 to 90 percent, meaning that it is 10 to 15 percent of its uncompressed size. This means that even low bandwidth links can often be used effectively for replication. Compression is triggered when the replication traffic is more than 32 kilobytes (KB) in size.
As discussed previously, there are two key ways to change intersite replication, as follows:
• Turn off automatic compression if you have sufficient bandwidth on a link and are more concerned about the processing power used for compression.
• Enable automatic notification of changes to allow domain controllers on either side of the link to indicate that changes are available. Automatic notification allows those changes to be requested rather than making domain controllers wait for the next replication interval.
Regardless of the site link configuration, replication traffic is sent through dedicated bridgehead servers rather than through multiple replication partners. When changes are made to the directory in one site, those changes are replicated to the other site via the designated bridgehead servers. The bridgehead servers then initiate replication of the changes exactly as was discussed in the section entitled "Intrasite Replication Essentials" earlier in this chapter, except that SMTP can be used instead of RPC over IP if SMTP is being used as a transport. Thus, intersite replication is really concerned with getting changes from one site to another across a site link.
Figure 35-5 shows an example of intersite replication using a single dedicated bridgehead server on each side of a site link. In this example, DC3 is the designated bridgehead server for Site 1 and DC4 is the designated bridgehead server for Site 2.
- Figure 35-5. Replication between two sites.
As you can see from the figure, replication is set up as follows:
• DC1 has incoming replication connections from DC2 and DC3.
• DC2 has incoming replication connections from DC1 and DC3.
• DC3 has incoming replication connections from DC1 and DC2.
• DC4 has incoming replication connections from DC5 and DC6.
• DC5 has incoming replication connections from DC4 and DC6.
• DC6 has incoming replication connections from DC4 and DC5.
If changes were made to DC1 in Site 1, DC1 would notify DC2 of the changes. DC2 would then pull the changes. Once replication was completed, DC1 would notify DC3 of the changes. DC3 would then pull the changes. Because all domain controllers in the Site 1 have now been notified, no additional replication would occur within the site. However, DC2 would still notify DC3 that changes were available. DC3 would not pull the changes, however, because it would already have them.
According to the site link configuration between Site 1 and Site 2, DC3 would notify DC4 that changes were available. DC4 would then pull the changes. Next DC4 would notify DC5 of the changes. DC5 would then pull the changes. Once replication was completed, DC4 would notify DC6 of the changes. DC6 would then pull the changes. Because all domain controllers in Site 2 have now been notified, no additional replication would occur. However, DC5 would still notify DC6 that changes were available. DC6 would not pull the changes, however, because it would already have the changes.
So far, I've talked about designated bridgehead servers but haven't said how bridgehead servers are designated. That's because it is a rather involved process. When you set up a site, the knowledge consistency checker (KCC) on a domain controller that Active Directory has designated the Inter-Site Topology Generator (ISTG) is responsible for generating the intersite topology. Each site has only one ISTG and its job is to determine the best way to configure replication between sites.
The ISTG does this by identifying the bridgehead servers that are to be used. Replication between sites is always sent from a bridgehead server in one site to a bridgehead server in another site. This ensures that information is replicated only once between sites. As domain controllers are added and removed from sites, the ISTG regenerates the topology automatically.
The ISTG also creates the connection objects that are needed to connect bridgehead servers on either side of a site link. This is how Active Directory logically represents a site link. The ISTG continuously monitors connections and will create new connections when a domain controller acting as a designated bridgehead server is no longer available. In most cases, there will be more than one designated bridgehead server, and I'll discuss why in the following section, "Replicating Rings and Directory Partitions."
Note You can manually configure intersite replication in several ways. In addition to the techniques discussed previously for scheduling, notification, and compression, you can also configure site link costs, configure connection objects manually, and designate preferred bridgehead servers.
Post a comment