9.6 Routing groups

 < Day Day Up > 



Servers in a routing group typically communicate through high-speed connections, so the definition of a routing group is very similar to that of an Exchange 5.5 site. In general, network links should be capable of supporting the transfer of even very large messages (>10 MB) within the routing group without causing concern. Within a routing group, servers form a point-to-point, fully meshed network to route messages over SMTP, and each server must be able to make a connection to another server in the group without waiting for a network link to become available. The sole exception to SMTP transmission is when legacy Exchange servers operate inside a routing group in a mixed-mode organization. In this situation, the MTA sends messages to the legacy servers via RPCs.

While the availability of high-speed connections is always a definite plus for a messaging infrastructure, the move away from RPCs to SMTP means routing groups are able to span across low-speed connections as well. RPCs are prone to failure over high-latency connections, where SMTP is able to connect quite happily. Thus, it is possible to build large routing groups that incorporate a mixture of different network connections.

Initially, organizations that migrate from Exchange 5.5 begin with a routing group for every Exchange 5.5 site. After the organization moves into native mode, you can consider modifying the routing group structure to improve the topology. Consider reducing the number of routing groups to simplify the routing topology, or perhaps move servers into special administrative groups that only contain routing groups to isolate routing management away from other administrative tasks.

Many older designs use a hub and spoke approach, with sites that contain mailbox servers connecting into hub routing sites. Designers create hub sites to introduce resilience and provide multiple paths for messages. However, the dynamic nature of link state routing and the way that the Routing Engine now directs messages between routing groups reduces the need for hub sites, affording a further opportunity to simplify the routing topology.

In order of importance, the factors that influence the decision to create new routing groups include:

  • Availability of stable network links

  • Available bandwidth that can support the automatic on-demand connections made by servers within a routing group

  • A need to schedule connectivity between servers

  • A need to control the transmission of large messages

  • A need to restrict the use of connections to particular users, or to deny a connection to particular users

The first three factors also pertain to older Exchange designs, while the last two are specific to Exchange 2000/2003. The Routing Engine is flexible, but it depends on network consistency. You will never attain efficient routing if the links between routing groups go up and down all the time. In this scenario, the link state table will be in "continuous update mode," and messages will bounce from one connector to the next. The safest approach is to group servers into islands of highly available connectivity, which then become your basic routing group structure. Later on, as experience with network conditions, traffic, and message throughput grows, you can make selective changes to the routing group design by creating new groups and moving servers into them, or transferring servers between existing groups. The Routing Engine is flexible and will adapt to new conditions as quickly as the AD can replicate the updated configuration data, so do not be afraid to make changes. You can reduce any possible impact on users by making changes to routing groups at times of low user demand. Any temporary queues that build up due to slow replication should clear before peak time occurs again.

Network use and message delivery times are the key indicators that you need to make some changes to the routing topology. If network links become saturated, you should attempt to reduce the traffic that goes across the link. If message delivery times become extended (more than 15 minutes between individual routing groups, or more than 1 minute between servers in a routing group), changes in the routing topology may be called for, depending on the goals of the organization. Some companies require message delivery times of less than one minute everywhere, while others will be happy if messages get through in less than an hour. Understanding the expectations of users for message delivery time is an important piece of data for a routing group design.

Always remember that Exchange depends on a solid Windows infrastructure, particularly the underlying network and AD replication. If the network fails, and configuration data and the AD cannot replicate information about servers and connectors, no amount of tinkering with routing groups will result in a dependable routing structure.

9.6.1 Routing group master

One server in each routing group acts as the routing master. By default, the first server installed in a routing group takes on the role of the routing master and remains as such unless altered by an administrator. You can assign the routing master role to any server in a routing group, and the most important and critical task the server then takes on is to maintain the link state table (LST). The routing master builds the LST from two sources: basic configuration data about the Exchange organization fetched from the DSAccess configuration cache and routing updates that come in from other routing groups. The routing master attributes a higher importance to routing updates than the somewhat static configuration data that comes from AD. This is only natural, because servers generate and communicate link state updates dynamically.

After it builds the LST, the routing master shares the LST automatically with all the servers in a routing group. As bridgehead servers in the routing group become aware of information about connections (their link state), they relay the data to the routing master, which uses the data to create an updated LST every time an update arrives from any source. After it updates the LST, the routing master broadcasts change information to all the servers in the routing group, and the servers adjust their own copy of the link state table.

You can move the routing master role easily between servers, as shown in Figure 9.17. Select the server that you want to take on the role and right- click to bring up a context-sensitive menu. Then select the "Set as Master" option.

click to expand
Figure 9.17: Defining a routing master.

Occasionally, the routing master is unavailable due to maintenance or a system outage. When this happens, the other servers in the routing group continue to route based on the last known LST. Routing in this situation may not follow an optimal path, because Exchange may send messages to a server whose link is unavailable, or there may be a better route available. However, even in its suboptimal state, the last LST is likely to be far more up-to-date with network information than the GWART used by the MTA to route messages in Exchange 5.5. The MTA normally generates the GWART once a day-after a new server or connector joins a site or if an administrator decides to request the MTA to generate the GWART. As such, the GWART is relatively static. Routing problems usually do not surface with the GWART when the network is stable, but if connectors or servers go offline it can be difficult to regenerate an accurate picture of the network and get messages to flow optimally again.

9.6.2 Creating new routing groups

Creating a new routing group is easy, mostly because a new routing group is just a container in the Exchange organization. Unlike an Exchange 5.5 site, which is instantiated when you install the first server into the site, you can create a routing group in the organization long before you move the first server into the group. This is a useful feature, because it allows you to configure the routing group structure for an Exchange organization at the start of the deployment and instruct administrators as to which routing group to use for new server installations. It also avoids the complications that occur in Exchange 5.5 when you remove the first server originally installed into a site and need to reconfigure homes for all the site objects (such as the default set of system folders).

To create a new routing group, select the routing groups container and take the "New" option from the right-click menu, as shown in Figure 9.18. You can do this even when your organization is operating in mixed mode- the sole requirement is that a routing group container already exists in the Administrative Group. If you have not yet created a routing group container, click on the Administrative Group; take the "New" option from the context-sensitive menu, and then the "Routing Group Container" choice. This mechanism makes it obvious that a routing group is just another container within the configuration container for an Exchange organization, so the properties that you need to add at this point (the name of the new routing group) are not very exciting.

click to expand
Figure 9.18: Creating a new routing group.

Exchange performs no validation to check that the routing group name you provide already exists in the organization. This is logical from the perspective of the hierarchy within the Exchange configuration. Remember that a routing group is a subcontainer within an administrative group, so you can create routing groups with the same names as long as they are in different administrative groups. Exchange is happy, because the resulting routing groups each have a different distinguished name within their configuration containers, but an obvious chance for confusion now exists. If we look at Figure 9.19, we see "EMEA Routing" and "Ireland" administrative groups, both containing routing groups for "Finland." In addition, further confusion arises from the "Europe HUB" routing group in the "EMEA Routing" administrative group and the "European Hub" routing group in the Ireland administrative group. On the surface, both routing groups seem that they might act as a central hub for European-wide routing operations, but can you tell the difference? The ease in which you can create new routing groups and the fact that they are subcontainers that can have the same name as existing containers underlines the need to plan the routing topology from the start rather than allowing administrators to build the topology on a whim.

click to expand
Figure 9.19: Duplicate routing groups.

As with Windows sites, I favor naming routing groups after geographical terms so that their purpose and coverage is immediately obvious. The alternative is to come up with another naming scheme, but I do not see the point unless you really want to sit down and construct a set of complex names that only you and your fellow administrators understand. However, consider the case of a new administrator. Will he or she understand the naming and purpose of routing groups if you do not use simple names? In all cases, the important thing is that users remain unaware of whatever you do, because they cannot see all of the organizational detail about Exchange.

Best practice is to create a special administrative group to hold all the routing groups in the organization and to assign permissions over that administrative group to the people who are responsible for managing the routing topology. They should be the only people who ever create a routing group or connector, which then limits the potential for other routing groups to appear and cause confusion.

Figure 9.20 shows an example of the type of naming convention I recommend for routing groups: simple and easy to understand. After Exchange has created the new routing group, you can add servers to it by selecting a server and dragging it to the "Members" container of the new routing group. However, you can only drag and drop a server into a new routing group if you have Exchange administrator rights for the server's administrative group. You can also install servers directly into the new routing group.

click to expand
Figure 9.20: Properties of the new routing group.

Dragging and dropping servers between routing groups just to see what happens seems like a fun way to idle away a rainy afternoon, but it is only an exercise that you should perform in a software laboratory for test purposes. Never move a server unless you have to, and only perform the operation after everyone involved in the administrative group has approved. In other words, it is still good to have the discipline to plan server moves rather than move servers around on a whim.

Exchange imposes some restrictions on server moves. You cannot move a server to another routing group if the server is a bridgehead for a connector. Connectors and routing groups are fundamental inputs to the routing tables, and moving a server that hosts a number of connectors would have a huge impact on the way Exchange routes messages. While Exchange is now much more amenable to change and has a mechanism to discover changes in the network very quickly (link state routing), as well as taking updates through changes made to configuration data managed by the AD, it is still not a good idea to make wholesale changes. Figure 9.21 illustrates the type of error you will see if you attempt to move a server that still has active bridgeheads. In this instance, the server is in the Netherlands routing group and has a connector to Ireland. The server also hosts an SMTP connector, and its name indicates that it handles external communication, so it is likely to be quite an important connector for the whole organization. If a server is the only member of a routing group, you will have to delete all connectors in the group (a connector must have at least one bridgehead server allocated to it) before you can move the server to a new routing group.

click to expand
Figure 9.21: Error when moving a server to a routing group.

If you want to decommission routing groups, best practice is to gradually move the servers from the defunct routing group to other routing groups and relocate or delete connectors as required. Leaving one or two days between each server move is sufficient to allow AD replication to occur in large organizations and to reveal any flaw or problem in routing behavior provoked by the move. After you move the final server from the defunct routing group, you can rename the routing group to indicate that it is no longer used and leave it for a week or so before final deletion. Figure 9.22 illustrates the concept.

click to expand
Figure 9.22: A defunct routing group awaits deletion.

9.6.3 Routing groups and public folder referrals

Apart from routing messages, routing groups also control access to public folder replicas through referrals. The AD holds a list of available replicas for every public folder with the other Exchange configuration data. When a client attempts to access a public folder, Exchange looks for a replica on the same server as the user's mailbox, and then for a replica on a server within the same routing group. If Exchange cannot locate a local replica, it looks for a replica in other routing groups connected by connectors that allow public folder referrals.[7] Exchange 2003 improves matters by allowing you to specify the servers that you want to handle public folder referrals.

If you do not provide Exchange with a preferred list of referral servers, the cost of a connector determines which replica to access if replicas exist in multiple routing groups. Content from the public folders does not flow across the connectors. Instead, the requesting client makes a direct network link to the server that hosts the public folder. Naturally, if this link extends across low-bandwidth connections, access to the public folder is slow. MAPI clients continue to use RPCs to access public folder content, while other clients use their native protocol (IMAP or HTTP-DAV). Most IMAP clients do not support referrals, because the protocol does not include any mention of this functionality.

[7] . The "Do not allow public folder referrals" checkbox on a connector's general property page controls referrals. The default is to allow referrals across the connector.



 < Day Day Up > 



Microsoft Exchange Server 2003
Microsoft Exchange Server 2003 Administrators Pocket Consultant
ISBN: 0735619786
EAN: 2147483647
Year: 2003
Pages: 188

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net