Determining the Site Topology
Active Directory employs a multimaster replication technology that allows nearly every aspect of the directory service to be modified from any of the domain controllers within a domain. Changes that are made to one domain controller within the domain are replicated to all of the other domain controllers within the domain. This replication allows all the domain controllers to act as peers and provide the same functionality. However, this same replication can cause issues when you are trying to keep WAN traffic to a minimum.
To reduce the amount of WAN traffic generated by replication, you will need to create sites within Active Directory that define the servers that are well connected. The domain controllers that are all members of the same site will update quickly, whereas replication to domain controllers in other sites can be controlled as to when and how often the replication will occur.
Another advantage to using sites is that client traffic can be contained within the site if there are servers that provide the service that the user needs. User authentication occurs with domain controllers that are located in the same site as the computer that the user is logging onto. In addition, you can make queries to a Global Catalog server and access the Distributed File System (DFS) shares within the same site as the user s computer.
Within a site, the Knowledge Consistency Checker (KCC) , a background process that runs on all domain controllers, creates connection objects that represent replication paths to other domain controllers within the site. These connection objects are created in order to produce an efficient replication path to all of the domain controllers within the site. An administrator can also create connection objects manually. If a manual connection is created, the KCC will build other connections around the manual connection to allow for replication redundancy. Do note, however, if you create a connection object that does not allow for efficient replication, the KCC will not override your efforts. As domain controllers are brought online or sites are created, the KCC is responsible for creating the connection objects to allow replication to occur. If a domain controller fails, the KCC will also rebuild the connection objects to allow replication to continue.
The KCC is also responsible for generating the intersite connection objects. When a site connector is created to allow replication between two sites, one domain controller is identified as the Intersite Topology Generator (ISTG) . The ISTG is responsible for determining the most efficient path for replication between sites.
As you should remember from studying for previous exams, domain controllers that are placed in different sites do not automatically replicate to one another. To give them the ability to replicate objects to one another, you have to configure a site connector. Once the site connector is created, the domain controller that is defined as the bridgehead server for the site will poll the bridgehead server from the other site to determine if there is any data that needs to be replicated. Because data that is replicated between sites is compressed to conserve network bandwidth, you may want to designate a server to be the bridgehead server. Bridgehead servers should have enough available resources to perform the compression and decompression of data as well as send, receive, and redistribute the replicated objects.
Bridgehead servers are chosen according to their globally unique ID (GUID). If you do not select a domain controller to be a preferred bridgehead server, then the domain controller with the highest GUID is selected. The same holds true if you have multiple domain controllers that are configured to be preferred bridgehead servers ”the one with the highest GUID is selected. The remaining domain controllers will wait until the bridgehead server goes offline, and then the ISTG will appoint one of the remaining domain controllers according to the GUID value.
Only one domain controller in each site will become the ISTG. The domain controller with the highest GUID in the site will become the ISTG for the site. It is responsible for determining the bridgehead server and maintaining the connection objects between bridgehead servers in each of the other sites.
In the following section, we are going to look at the options and strategies that you need to consider when designing the site topology to support your Active Directory design.
Understanding the Current Network Infrastructure
Very few organizations will be starting fresh with Windows Server 2003. Unless it is a brand-new business, some type of network will already be in place. In Chapter 3, Designing the Active Directory Forest Structure, we discussed some of the information you should have gathered about the existing infrastructure. Most of the information gathered at that time dealt with the directory service aspect of the current infrastructure. To build an effective site topology for the Active Directory design, you will also need to know how the current infrastructure supports the user and computer base. Once you have identified the current network infrastructure, you can create the site and site link design.
Identifying the Current Network Infrastructure Design
Networks are made up of well-connected network segments that are connected through other less-reliable or slow links. For a domain controller to be considered well connected to another domain controller, the connection type will usually be 10Mbps, or greater. Of course that is a generalization. Some segments on your network may have 10Mbps or higher links between systems, but if the links are saturated , you may not have enough available bandwidth to support replication. The inverse is also true, you may have network connections that are less than 10Mbps that have enough available bandwidth to handle the replication and authentication traffic.
Look over the existing network and draw out a network map that defines the subnets that are well connected. Some organizations have a networking group that is responsible for the network infrastructure and a directory services group that is responsible for the Active Directory infrastructure. If this is the case, you have to make sure that the two groups work closely together. From the group that is responsible for maintaining the network infrastructure, find out the current physical topology of the network. Gather the information about the location of routers, the speed of the segments, and the IP address ranges used on each of the segments. Also note how many users are in each of the network segments and the types of WAN links that connect the locations. This information will prove useful as you design the site topology.
As an example, consider a company that has a campus in Newark with four buildings and two remote locations: Albuquerque and New Haven. All of the buildings in Newark are connected via an FDDI ring. The two remote locations are connected to Newark via T1 connections. Figure 8.1 shows the network map, which also lists the user population at each location.
Figure 8.1: Network map
For those organizations that have more than one domain, you will need to determine where the user accounts reside. A site can support users from multiple domains as long as those domains are members of the same forest. On your network map, if you have more than one domain, designate the number of users from each domain. In our previous example, if the Research and Development department has its own domain for security purposes, the network map may look like Figure 8.2.
Figure 8.2: Multiple domain network map
| Note | Don t confuse the logical representation of your network with the actual physical entities. You could still have domain controllers from multiple forests within the same physical subnet, but the Active Directory objects that define them can only exist within one forest. |
Designing Sites to Support the Active Directory Design
Once you have created the network map, you can begin designing the required sites . Sites are collections of well-connected subnets that are used to control Active Directory replication or manage user and application access to domain controllers and Global Catalog servers. As with every other Active Directory object, you should determine a naming strategy for sites and site links. A site s name should represent the physical location that the site represents. The location could represent a geographic location for organizations that have regional offices, the buildings within an organization s campus or distinct portions of a building. Once you have defined the naming strategy, make sure all of the administrators who have the ability to create sites understand the strategy and follow it.
You need to create a document that details the sites that will be used within the design. This document should include the name of the site, the location that the site represents, the IP subnets that are members of the site, and the WAN links that connect the sites.
If you look at Figure 8.2, you can see that the information that was gathered about the current infrastructure is shown in the network map. You need to use this information to create the site design, as shown in Figure 8.3. Notice that the primary locations are identified as sites within the design. Newark, New Haven, and Albuquerque are all identified as sites. Each of the
Figure 8.3: Site design layout
IP subnets from the buildings at the Newark campus is shown as included within the Newark site; the IP subnets from the office in Albuquerque are included in the Albuquerque site; and the IP subnets from the office in New Haven are included in the New Haven site.
The WAN links that connect Albuquerque and New Haven to the Newark campus are shown on the site design layout. But because the Newark campus is considered a single site, the FDDI connections between the buildings are not considered WAN links at this point. Later when we address the replication needs, this may change.
You should also consider including information about the WAN links on the site layout. This information should include the locations that the WAN link connects, the speed of the link, the available bandwidth on the link during normal operation and how reliable the link is. You may also want to consider including information concerning when the link is used the most, when the off-peak hours are and whether the link is persistent or a dial-up connection. This information will help you to determine the replication schedule.
Once the initial site choices are made based upon the network requirements, you will need to determine if you should create sites to support user and application requirements. Users sitting at workstations that are Active Directory aware will authenticate to a domain controller from their domain, if there is one within their site. If their site does not have a domain controller for their domain, they will authenticate with a domain controller within another site. All domain controllers determine if any sites exist that do not contain domain controllers from their domain when they are brought online. If some sites match this criteria, the domain controller then determines if it is located within a site near the site without a domain controller. The domain controller determines this based on the cost of the site link or site link bridges that connect the two sites. If it is determined that the domain controller is close to the site, it registers a service locator (SRV) record for the site.
| Tip | For more information on how to configure domain controllers to register their services to other sites, see Knowledge Base articles 200498 and 306602. |
As an example, Company G has two domains: corp.com and RD.corp.com . Five sites exist within their environment: A, B, C, D, and E. Figure 8.4 shows the site layout and the site links that connect them. Within the sites, there are domain controllers for each of the domains. Note that site C does not contain a domain controller for RD.corp.com . In this case, as domain controllers start up, they will check the configuration of the domain to determine whether or not a site exists without a domain controller from their own domain. When domain controllers from RD.corp.com start up, they will recognize that site C does not have a domain controller. They will then determine whether they should register SRV records for the site based upon whether or not they are in a site that is considered to be the nearest . Since site B has the lowest cost value over the site link to site C, RDDCB1.RD.corp.com will register SRV records on behalf of site C. When users from the RD.corp.com domain authenticate from a computer in site C, they will authenticate with the nearest domain controller, RDDCB1.RD.corp.com .
Figure 8.4: Determining the nearest site
Active Directory replication can consume a considerable amount of network resources within a site. Replication traffic is not compressed between domain controllers that exist within the same site. If the available network bandwidth will not support the replication traffic that you are anticipating , you may want to look into dividing up IP segments so that you can control the replication moving between the domain controllers. Once additional sites are created, site links can then be configured. Replication traffic that passes across site links is compressed to conserve bandwidth if the data exceeds 50KB.
Another consideration is application support. Applications such as Exchange Server 2003 require access to a Global Catalog server. If you want to control which Global Catalog server an Exchange server will use, you could create a site and place the two servers within the site to control the traffic between them. For example, within our corp.com domain, we have an Exchange Server 2003 server that is located within Building 1 of the Newark campus. We have specified that a domain controller within Building 2 is to be used by the Exchange server when it sends queries to a Global Catalog server. In order to control the requests , another site is created that includes Building 1 and Building 2. Figure 8.5 represents the site design once the change has been made to support our decision.
Figure 8.5: Site design to support application requirements
Designing Site Links and Site Link Bridges
Because we have identified the WAN links that connect the sites within our design, we can decide easily on the site links that we will need to support the design at this point. Site links are objects that are created to connect sites so that replication can be controlled. You also need to address other considerations such as replication, log-on authentication control, and application support.
Site link bridges are collections of site links that allow replication traffic from domain controllers in one site to pass to domain controllers in another site when no explicit replication partners exist in the intermediary site that connects them.
In the following sections we are going to spend some time reviewing the options that are available for sites and site link bridges.
Site Links
By default there is one site link created when the first domain controller is installed. This site link is called DEFAULTIPSITELINK, but it can be renamed to conform to your naming strategy. This site link uses Remote Procedure Calls (RPC) for replication. You could take advantage of using this site link for all of the sites that you have within your infrastructure if they all have the same replication requirements. For example, if all of the sites are connected by WAN links that have approximately the same available bandwidth and they all use RPC for replication, then simply rename this site link to conform to your naming strategy and make sure all of the sites are included.
Another reason you may want to create additional site links is to control when the replication can occur. You may have some sites that need to have objects updated at different schedules. Using site links, you can create a replication schedule between sites. You cannot define which physical connection a site links uses in order to control the replication traffic over specific network links. For instance, if you have a T1 connection and an ISDN connection to a branch office and the ISDN connection is only used as a backup communication link if the T1 goes down, you cannot create two site links with two different costs, one for each of the communication links.
When creating the site link, you have the options of choosing the following:
Protocol used for replication Two protocols can be used for replication of objects: IP and SMTP. When selecting IP, you are really specifying that you want to use RPCs to deliver the replicated objects. You can select SMTP if the domain controllers that you are replicating data between are not within the same domain. If the domain controllers are within the same domain, the file replication service (FRS) has to use RPCs to replicate the Sysvol data. Since FRS requires the same replication topology as the domain partition, you cannot use SMTP between the domain controllers within a domain. You can use SMTP if you want to control the replication between Global Catalog servers or domain controllers that are replicating the schema and configuration partition data between domain controllers.
Name of the site link The name should follow your naming strategy and should define the sites that are connected using the link.
Connected sites These are the sites that will explicitly replicate between bridgehead servers in each listed site.
Schedule The schedule consists of the hours when replication can occur and the interval ”how often you want to allow replication to occur during the hours that replication data is allowed to pass between the bridgehead servers.
Cost of the connection A value that determines which link will be used. This cost, or priority, value is used to choose the most efficient site link. You will use the combination of site links with the lowest total cost to replicate data between any pair of sites.
Note the replication patterns when you are trying to determine the schedule. You could cause a good deal of latency to occur if the schedule is not compatible. For example, a company may have a central office that acts as the hub for the regional office. The regional offices are responsible for replication to the branch offices in their region. Figure 8.6 shows the schedule for the Atlanta central office, the Sydney and Chicago regional offices, and the Exmouth, Peoria, and Bloomington branch offices. Because all of the domestic U.S. links have approximately the same bandwidth availability, you could create a single site link that uses a 15-minute interval. You could then create a separate site link between Atlanta and Sydney that has the replication interval set for every two hours so that replication does not adversely affect the WAN links. Between the Sydney and Exmouth sites, another site link uses a 1- hour interval to control traffic. Depending on the connection objects that are created by the KCC, the total propagation delay for an update in Chicago to reach Exmouth could be three and a half hours. And that is only considering the replication interval. The schedule on the site link could be configured to allow replication traffic to flow only during the evening hours. If you have a schedule that is closed off for a portion of time, the propagation delay will increase even more. You need to make sure that this will be acceptable within your organization.
Figure 8.6: Replication schedules based on site links
You should also plan the cost of site links carefully . The default site link cost value is 100. If all of the communication links have the same available bandwidth, you could leave the default cost on all links. However, if different bandwidth constraints occur on any of the communication links, you will need to adjust the cost values. One method of determining a valid cost for site links is to divide 1,024 by the base 10 logarithm of the available bandwidth as measured in kilobits per second (Kbps). In doing so, you will find cost values that correspond to the entries in Table 8.1.
| Available Bandwidth in Kbps | Cost Value |
|---|---|
| 4096 | 283 |
| 2048 | 309 |
| 1024 | 340 |
| 512 | 378 |
| 256 | 425 |
| 128 | 486 |
| 64 | 567 |
| 56 | 586 |
| 38.4 | 644 |
| 19.2 | 798 |
| 9.6 | 1042 |
Site Link Bridges
In Windows Server 2003 Active Directory, site link bridging is enabled for all site links by default, making replication transitive throughout sites. In Figure 8.7, note that there are domain controllers in all three sites from corp.com . Site B is the only site that does not have a domain controller from RD.corp.com . With site link bridging enabled, replication from domain controllers for RD.corp.com in site A will pass to RD.corp.com domain controllers in site C.
Figure 8.7: Site Link Bridge
If you have a network infrastructure that is fully routed and all of the locations can communicate directly with one another, then you can leave this default setting turned on. However, if you have locations where not all of the domain controllers are able to communicate directly to one another ”for instance, if they are separated by firewalls ”you may want to turn off the site link bridging. You may also want to turn it off if you want to manually control where it is allowed. If you have a large, complex network, you could turn off the bridging and create your own site link bridges by defining which site links will be included in a bridge.
Firewalls that exist within your organization s network infrastructure could also pose challenges. There may be rules in place that will only allow specific servers to communicate with internal resources. If you do have a firewall in place you may need to turn off site link bridging so that you can control the site links that will pass replication traffic from site to site.
Remember that the site link does not define any physical network links. The physical connections are determined by how the domain controllers are connected to one another. A site link cannot detect if a physical link is down and thus will not reroute the traffic immediately.
Determine your site link s costs based upon the paths on which you would like replication to occur when using bridging.
| Note | For more information on creating site links and controlling site link bridging, see the MCSE: Windows Server 2003 Active Directory Planning, Implementation and Maintenance Study Guide, by Anil Desai with James Chellis (Sybex, 2003). |
In the Determining Site Topology Design Scenario, you will determine a site topology for a specific scenario.
 |
Charles is designing his site topology and is trying to determine where the sites should be located and the site links that will connect the sites. When reviewing the network, he decided to create a network map that includes three locations: Centralia, Sparta, and Gridley. Centralia and Sparta are connected via a T1 connection that is currently at 60 percent capacity. Gridley connects to Sparta via a 1.5Mbps SDSL VPN connection that averages 40 percent capacity. Each of the locations has approximately 1,000 users.
-
Question: Where should Charles create sites? Answer: Each of the locations should be its own site. Because there are 1,000 users per location, you should not risk losing a WAN connection, which would keep users from being able to authenticate.
-
Question: When creating site links, how should you configure the site links? Answer: Depending upon how much data will be replicated, you could use the DEFAULTIPSITELINK for all three sites. Because there is enough available bandwidth on each of the connections, the default schedule and interval should work also.
| |
In the next section, we start discussing domain controllers, what server specifications are recommended, and where they should be located. This includes servers that will be domain controllers for the domain and those that will also be Global Catalog servers.
EAN: 2147483647
Pages: 159