You know how important it is to have your Exchange 2000 server running on the proper hardware. Naturally, if you use your hardware more efficiently, Exchange will perform better. However, there’s still one major piece of the puzzle that can impede optimum Exchange 2000 performance, network throughput. Even if you’re running Exchange 2000 on a server with dozens of the fastest CPUs in the world with acres of disk space and gobs of RAM, if your network isn’t configured properly, you’re doomed.
Network throughput can be best described as the amount of data that you can move from point A to point B in a given amount of time. Exchange is extremely dependent on good network throughput.
If you doubt the importance of adequate throughput, consider how long it normally takes you to check your e-mail on your LAN. Now, compare that speed to the speed it takes to download your e-mail over a dial-up connection. You’re accessing the same server in both cases, but the service is faster when you’re connected through the network. The server performs at the same level when you dial in and when you access it through the network, but the lack of bandwidth gives the illusion of poor performance.
Ultimately, the speed at which your Exchange server is able to communicate with other Exchange servers, mail clients, and the Internet has a tremendous impact on overall performance.
Build a dedicated backbone
The biggest problem with Exchange-related network traffic is that on medium- to large-sized networks, there tends to be a lot of network traffic. Exchange, by its very nature, is very chatty. It must stay in constant communication with the Internet, other Exchange servers in the organization, and every client connected to it. These communications generate a considerable volume of network traffic.
One way to ease the traffic is to construct a dedicated backbone between Exchange servers. Typically, all communications to and from a server go through a single network card, and since the network card is connected to the network, communications pass through the network as well. Some of this traffic should flow across the network. For example, the Exchange clients reside on the network, and communicating across the network is the only way for the clients and the server to communicate with each other. However, it is possible to remove server-to-server communications from the network.
You can do this by installing a second network card into each local Exchange 2000 server and then connecting all of these “spare” cards to each other through a dedicated hub not connected to the rest of the network. Finally, tell Exchange that the dedicated connection is the preferred connector for communicating between servers.
By doing so, you’ve actually built a dedicated backbone that increases performance and implements a degree of fault tolerance at a very nominal cost. First, you’ve freed up a considerable amount of bandwidth by moving server-to-server traffic off the primary network to a dedicated network. This will increase the throughput of other types of data because they won’t be competing with server-to-server communications for bandwidth. Second, you’ve created a redundant connection that can be used in hardware failure situations. This would come in handy if the network card went bad or the network cable was cut in a single network card server.
However, a failed network card or a cut cable won’t cause a problem in a dual network card server. Although one of the cables is designed to go to a dedicated backbone, the other cable still goes to the primary network. This means if either cable is cut, the server is still capable of communicating with the other servers and clients through the remaining connection, so long as the ability to route IP packets hasn’t been disabled.
Routing groups are similar to the site structures used in Exchange 5.5 but have some major differences. In Exchange 5.5, sites grouped servers with similar purposes for easier administration. The only real requirement was that the servers within the site must be joined by a permanent, reliable, and somewhat high-speed connection.
Exchange 2000 takes the concept of sites and breaks it down into two different subcomponents: administrative groups and routing groups. Administrative groups allow you to assign someone authority over a group of Exchange servers regardless of geographic location.
Routing groups are implemented based on the structure of your network. For example, if you have two offices separated by a low-speed connection, you could place each office into a routing group, in the same way you would previously have separated the two offices into individual sites using Exchange 5.5. However, you’re no longer confined in this way.
With the connection between the two offices, it would have been impossible for machines in both offices to be a part of a common Exchange 5.5 site. However, Exchange 2000 doesn’t place this sort of restriction on routing groups. Exchange 5.5 had to place some speed limitations on machines within a site because it used Remote Procedure Calls (RPCs) for communications between the sites. RPCs tend to have problems when bandwidth is inadequate for fast communications. Routing groups, on the other hand, are designed to use SMTP for communications. SMTP doesn’t have any problems with slow links, so you can implement routing groups anywhere.
So what does all of this have to do with optimizing Exchange 2000? The way you design your routing groups plays a big part in the way Exchange performs. I recommend implementing routing groups in a manner that mimics your network’s geographic layout. Any time you have a slow link, it should represent the end of one routing group and the beginning of another. Just because a routing group can span a slow connection doesn’t usually mean it should.
But just because you’ve isolated the routing groups geographically doesn’t mean one routing group will never have to communicate with another. The way you enable such communications is essential to performance. Routing groups communicate with each other through routing group connectors applied to the bridgehead server.
The bridgehead server is the Exchange Server within each routing group designed to facilitate communications with other routing groups. Depending on the size of your organization, a huge workload can be placed on the bridgehead server. Make sure you designate the most powerful Exchange Server or the Exchange Server with the least workload in each routing group as the routing group’s bridgehead server. This will ensure that the bridgehead can keep pace with the demands placed on it and won’t cause communications between routing groups to suffer from slower performance.
The next trick to tuning your network involves the way you implement the routing group connectors. The routing group connectors are logical entities that tell Exchange Server how to route traffic between routing groups. Routing group connectors can use a linear, star, circle, or a full mesh topology. I can’t tell you which topology is right for your network. So many factors go into selecting a topology that you’ll have to decide that yourself. What I can tell you is that if you have more than two routing groups, each routing group should have a routing connector to at least two routing groups. That way, if a connection fails, the routing group has an alternate path to reach the other routing groups.
The secret to planning routing group connectors is to look at the speeds and amounts of traffic flowing across the actual physical links between routing groups. You can assign each routing group connector a cost. If the physical connection between two routing groups is fast or doesn’t have much traffic, assign it a low cost. If a connection is slow or congested, assign it a high cost.
When routing traffic, Exchange will always calculate the lowest total cost between the source and the destination and use that route, unless the route is unavailable for some reason. For example, if Exchange calculates that one route has a cost of 10 and another route has a cost of five, Exchange will use the route that has the cost of five. Thus, applying costs carefully can really improve your network performance.
When trying to optimize Exchange 2000, it may seem easy to solve the problem using a hardware solution. However, as a network administrator, you should also focus on the network. By planning routing groups and designing the network backbone properly, you can increase Exchange 2000’s performance without spending extra money on hardware that may or may not solve your problem.