Deploy Windows Server 2003: Considerations for Planning Network Bandwidth
"For a complete guide to planning, designing and implementing high availability with Windows Server 2003 and Cisco Technologies, check out 'Windows Server 2003 Clustering and Load Balancing' from Amazon.com"
When planning and designing a Windows Server 2003 deployment that spans a global Wide Area Network (WAN), understanding how the base operating system communications subsystems function will help you to size your lines appropriately, plan a site link architecture that follows a planned design and so on. When placing domain controllers (DCs) on a network, they need to be designed so that they can help you to control bandwidth consumption, through them - site links can be used. It is very important to assess your network properly before deployment and that is what we will learn to do in this article.
If you do not assess properly, problems such as an under assessment of the unknown effect on your telecommunications lines when rolling out Windows Server 2003 in your corporate network will raise its ugly head right in front of you and your bosses, you could cause problems not only to the current data traversing the network, but also to the directory service that Windows Server 2003 relies on – Active Directory Service (ADS or ‘AD’ for short). Directory corruption is not fun to deal with, hence why backups are so important, but to keep yourself from having to restore or deal with major issues, planning the replication strategy to ‘avoid’ corruption in the first place would be wise, exactly what this article’s target lesson is all about. Getting you to assess, plan, design, and avoid disaster.
What is at Stake?
Data corruption happens all the time, Directories are nothing more than data files that can be corrupted and a poorly performing directory system will only eventually become corrupted and cause issues. Consider the NTDS.DIT file, nothing more than a file, nothing more than the ‘Active Directory database’. Problems with your directory will cause an unstable environment which breeds nothing but problems such as users being able to logon, then not being able to log on – ‘phantom-like’ issues. To not consider what may affect your network bandwidth in your plan is technical suicide, most of what a company relies on to do business comes across such telecommunication lines, and Ethernet based network switches… phones, email, Instant Messaging (IM), file transfers, Internet access, application access, printing and so on so ensuring that you assess all that was just mentioned in your planning stages will help lessen the risk of something bad happening not only to your directory, but also to the other systems running on the network.
In today’s large environments, it is imperative to get the most out of your network bandwidth so that businesses can continue to operate, and the businesses do not overspend on telecommunications costs which can get out of control very quickly if not monitored carefully. Your data transmission speed can be affected by any excessive traffic created by applications and services. The question comes up often… does replication traffic affect bandwidth? Let’s assess the whole situation and come to that conclusion with an example. How does Windows Server 2003 affect Bandwidth? In this article we will consider the fictitious 123 Ltd Group. They are in 3 separate locales, one location in the US, one location in the UK, and one location in Asia. Yes, even ‘where’ they are located can help you to assess your needs for bandwidth and DC placement.
Assessing Your Network Infrastructure
When assessing your network infrastructure, you should start with network documentation. This would be any network diagrams that show the whole company layout by site, with the connection methods in between. This map does not have to be identical to, but should resemble something similar to Figure 1. If it doesn’t exist, it needs to be made first, before anything else is done. Without a map, or a diagram of your current network, you will find it somewhat difficult to plan a Windows Server 2003 deployment across the network… Figure 1 shows you the US – UK – ASIA company connections for 123 Ltd Group.
Figure 1: High Level Overview of 123 Ltd Group’s Wide Area and Local Area Networks
This high level overview shows you the most critical information needed to plan for replication traffic and site links…
T1 at head end (Hub), Router running EIGRP, PPP encapsulation, LAN 10/100 Mbps, Backbone server farm segment on 1000 Mbps.
512K link to Hub, Static Routes to Hub, PPP encapsulation, LAN 10/100 Mbps.
512K link to Hub, Static Routes to Hub, PPP encapsulation, LAN 10/100 Mbps.
Other Planning Information
Not relevant to this article but equally important to get is the following information which will do nothing but help you plan and design your Windows Server 2003 Active Directory deployment. This large list of information helps point you in the direction of what you may want to gather for planning purposes, but for our purposes here, the chart above is perfect for this example. Just be aware of other these items you would want to look at or for when in the planning stages of Windows Server 2003 deployment. Include the following in your planning documentation:
- Intranet infrastructure
- Current server roles
- Trust relationships
- Security Infrastructure
- LAN and WAN Documentation
- Physical communication links (cabling, copper, fiber)
- Server names (Naming conventions used, current naming list)
- IP addresses (any and all TCP/IP related documentation)
- In Active Directory, a collection of computer, user, and group objects defined by your administrator.
- Domain Name System, DNS namespace
- Location of printers
- Security infrastructure
- Physical network infrastructure
- Addressing infrastructure
- Naming infrastructure
- Authentication infrastructure
- Management infrastructure
- Domain architecture
- Interoperations (connections to other platforms such as Novell and Unix)
Windows Server 2003 and Replication
When working with Windows Server 2003, it’s important to understand the enhancements to replication over previous versions. To improve replication efficiency and scalability, many changes and enhancements went into how a replication takes place within a forest. It’s important to note that for best performance you should set to a Windows Server 2003 functional level over previous levels such as Windows 2000 Server.
Checking for Slow Replication
A good site topology design is important for replication efficiency, but other factors play heavy into how well your replication scheme will work. Bandwidth is the most important practical consideration affecting intrasite replication on your network because if you don’t have a connection – you can’t replicate – so if you have a ‘poor’ connection, you will have ‘poor’ replication. It’s all relative. Bandwidth is easy to eat up too because many times it’s not restricted, therefore its imperative you consider it for site connector planning. Synchronization and directory related problems could occur as a result. A common problem would be ‘slow’ replication causing issues. The time required to replicate directory data between domain controllers is known as the ‘replication latency’ and replication latency is the ‘delay time’ from when an update is applied to a replica of the directory partition, and the time is it is applied to ‘another’ replica of the ‘same’ directory partition.
To keep up on replication issues, open the Computer Management MMC, and review the directory service log in the Event Viewer for any replication errors. You can also use the Support Tools to gain access to repadmin and dcdiag, two tools to aid in finding replication problems. Adlb.exe, a Windows Resource Kits tool for the Windows Server 2003 family, can help improve replication efficiency in forests as well. Adlb.exe is easy to use. To use it, simply type in at the command prompt adlb with the syntax needed to perform whatever task you need performed. For instance, using the /site: switch, you can examine the Active Directory connection to that site inbound and outbound and then balances then Active Directory objects between available bridgehead servers within the time frames set for replication to occur. Adlb.exe output is written in LDAP Data Interchange Format (LDIF). For more information on LDIF files see RFC 2849, LDAP Data Interchange Format.
Managing intrasite replication and bandwidth is done with a ‘site link’. A site link is an Active Directory object that represents a set of sites that can communicate at ‘uniform cost’ through an intersite transport such as IP or SMTP. Figure 2 shows you the US – UK – ASIA company site link connections for 123 Ltd Group.
Figure 2: 123 Ltd Group Site Link Architecture (High Level)
For Internet Protocol (IP) transport, a typical site link connects just two sites and corresponds to an actual wide area network (WAN) link. You would want to configure your site links with the IP subnets that they correspond with, such as … if you have the hub site as 10.1.1.0, then that is subnet you want to correspond to that site link on the hub site end. The remote sites (the UK and Asia) are also connected via site links, as per their respective subnets… 10.1.2.0 and 10.1.3.0. By placing one domain controller per site, (called the intersite topology generator) which is nothing more than a service that runs on a DC which scans all connections and reports new or dead ones, is able to assess link status, as well as to ‘control’ link connection which will give you a way to manage the links in between physical sites… with new logical ones that you build within the Active Directory Sites and Services MMC. A way to find out if you are having issues is to search the Directory Log in the Event Viewer for KCC errors, many of which point to replication and synchronization errors. The Knowledge Consistency Checker (KCC) process will updates the intersite replication topology accordingly with its findings as well. Other benefits are the elimination of redundant replication paths between sites, as changes can occur rapidly in your environment; Windows Server 2003 is working for you to get the best path.
Other Bandwidth Considerations
To only look at Directory traffic would be silly. You also have to assess WINS traffic if used (NetBIOS, Broadcasts, etc), Multicast traffic, Application traffic such as File and Print sharing at the very minimum… email, Internet access… figure 3 shows you some of the considerations besides for replication traffic, all of these could be cause of or pose issues as well.
Figure 3: Other Services to Consider on a Network
As you can see from Figure 4, when replication traffic patterns are added, you can see that a single file request if too large (like 50 MB) pulled over that WAN link connecting the sites… that alone could cause an issue on that link. You have to consider this when planning and designing.
Figure 4: High Level Overview of Network Infrastructure
Lastly, look at one more ‘concept’ of what could happen (and where you should also take consideration in) is an unexpected thing such as ‘Virus Outbreaks’, a Link going down because your provider had an accident (such as a cut fiber that leaves you dead in the water). In figure 5 you can see some major issues going on:
- You have a Virus outbreak on the NY LAN, this is causing saturation on your 10/100 Mbps switch, causing slowdown to the servers (especially the DC) on your local subnet. Other issues could be, excessive broadcast/multicast traffic affecting your LAN, routers and so on.
- You have a Link that dropped to one of your remote offices. Today, you have no Disaster Recovery (DR) lines set up, No DR will kill you too… no replication, a DC is then cutoff and on an island.
- Consider all bandwidth flows and at what times do you have the most activity…
Figure 5: High Level Overview of Network Infrastructure with Activity
In this article we covered the basics of planning a Windows Server 2003 deployment from a ‘networking’ point of view. We looked at considering bandwidth, site link design, replication, traffic analysis and many other things that can be used to help you plan a successful Windows Server 2003 and Active Directory infrastructure that works and is reliable, efficient and provides reliable and solid performance.
Links and Reference Material
For a complete guide to planning High Availability for Windows Server 2003 and Windows 2000 Server, check out:
Windows 2000 & Windows Server 2003 Clustering & Load Balancing