Planning Site Links
| When you're planning the site links between multiple sites, you are defining a replication topology for an organization. You therefore need to understand the various components associated with a site link and how they are used to control and optimize intersite replication. Consider the following issues when planning for site links, each of which is discussed in this section:
Link CostsOne of the advantages of using site links is that they can be assigned a site link cost. A site link cost is a number assigned by an administrator to a site link. By assigning costs to site links, an administrator can define a preferred route for replication when multiple routes exist. When assigning costs to site links, keep in mind that a site link with a lower value is seen as the preferred route over a site link with a higher value. For example, if multiple replication routes were available between to the LA site and the NJ site, a site cost could be assigned to each of the links to define a preferred route. If the preferred route is not available, the other is used, as shown in Figure 9.2. Figure 9.2. Assigning a cost value to site links enables an administrator to specify a preferred route when multiple site links exist.
Link SchedulesOne of the options an administrator has to control replication between sites is to schedule when site links are available. Intersite replication does not use the process of notification. If changes occur in one site, the other sites are not notified. Instead, a domain controller in one site periodically checks for changes by contacting a domain controller in another site. To optimize this process, an administrator can schedule certain times when the site link can be used for intersite replication. This ensures that replication does not occur when the link is already heavily used. For example, the XYZ Corporation might choose to schedule the site link between LA and NJ to be available only during nonworking hours so that the already heavily used link is not tied up with replication traffic, as shown in Figure 9.3. Figure 9.3. Placing a schedule on the site link between LA and NJ enables an administrator to control when intersite replication can occur over the link. One of the drawbacks of placing a schedule on a site link is that it can increase replication latency. Replication latency is the time it takes for changes made on one domain controller to appear on another domain controller. Obviously, placing a schedule on a link means that information between sites might not always be up-to-date. However, if a link used for RPC replication is saturated when a replication cycle begins, the replication can fail with an RPC timeout. Therefore, although latency can be a problem in a multiple-master environment such as Active Directory, setting site link schedules can actually improve replication performance. Determining the Need for Site Link BridgesIn a fully routed IP network, all site links are transitive (or bridged ). The transitiveness of the site links establishes a replication route throughout a network with little administrative effort. Administrators do not have to define site links between every site; in other words, if two sites have links with a common site, a replication route does not have to be explicitly defined between them. However, in some situations, networks are not fully routed. If, for example, two subnets are connected at a multihomed server but that server does not route or routes only very specific traffic, the network is not fully routed. Dial-on-demand routers, one-way dialup connections, firewalls, and several other configurations can create a network that is not fully routed. When the network is not fully routed, the transitiveness of site links can be turned off and site link bridges can be created to establish a replication path. After the transitiveness of site links is turned off, a replication path does not exist between sites A and C if there are site links between sites A and B and sites B and C. To allow information from site A to be replicated to C, a site link bridge must be defined. Sites that do not have an explicit site link between them can be linked together using multiple site links to establish site link bridges. For example, if the ABC Corporation does not have a fully routed network, the transitiveness of the site links can be turned off and an administrator can create site link bridges to establish a replication topology that models the routing operation of the network. If three sites have been configured in an organization and two site links exist, a site link bridge can be defined to establish a replication path, as shown in Figure 9.4. Figure 9.4. A site link bridge establishes a replication path between sites that do not have an explicit site link between them. Establishing site link bridges reduces the administrative overhead associated with a replication topology because explicit site links do not have to be defined between every site.
Selecting Bridgehead ServersIf you refer to Table 9.1 (which compares intrasite and intersite replication), you'll see that multiple connections between domain controllers are automatically established to replicate information in a site. Between sites, connections are established between dedicated computers called bridgehead servers . Bridgehead servers are those computers that have been designated the responsibility of intersite replication and are responsible for receiving updates from other sites. This obviously means that these computers must be capable of handling a large amount of replication traffic ”much more than other servers in the site. After a bridgehead server receives updates from another site, that information is replicated to other domain controllers in its own site. This is much more efficient than having multiple connections with multiple domain controllers established over a slow link to replicate information from one site to another. For example, in the sites in the XYZ Corporation, there would be at least one bridgehead server per site responsible for receiving updates from other sites and replicating them throughout its local site, as shown in Figure 9.5. Figure 9.5. The bridgehead servers in each site are responsible for intersite replication. When planning for bridgehead servers, keep in mind that a bridgehead server is needed for each naming context in a site. If a site contains IP subnets from more than one domain, multiple bridgehead servers are needed in the site. The reason for this is that domain controllers can replicate data only to other domain controllers in their own domains. Therefore, for replication to occur between sites, a bridgehead server for one domain must be capable of connecting to a bridgehead server from the same domain in the remote site. For example, if the Paris and NY domains contain IP subnets from the Training domain and the Consulting domain, multiple bridgehead servers must be designated in each site, one for each naming context, as shown in Figure 9.6. Figure 9.6. If the sites have IP subnets from multiple domains, a bridgehead must be designated for each naming context in each site for intersite replication to occur. The designation of bridgehead servers in a site can be done automatically or manually. When it's done automatically, the KCC designates a computer as the bridgehead server ”usually the first domain controller in each site. If the server designated as the bridgehead is unavailable, the KCC designates another server to take its place. If you designate the bridgehead server for a site manually, the KCC uses only this server and does not designate another to take its place if it is unavailable. If you are going to manually designate a bridgehead server, you should configure more than one for a site; if the bridgehead server is unavailable, the KCC attempts to use one of the others.
 |
EAN: 2147483647
Pages: 148