Considerations When Deploying a Front-End and Back-End Topology

  • Article

 

When deploying a front-end and back-end topology, you must account for several factors including, expected load, hardware needs, administrative overhead, load balancing, and security. The following sections cover these factors in more detail.

Do Not Cluster Front End Servers

Clustering the Exchange front-end servers does not offer any performance benefit. Front-end servers are stateless so performance is much better having two separate servers sharing connections (or Network Load Balanced) rather than clustering them.

Server configuration depends on many factors, including the number of users for each back-end server, the protocols used, and the expected load on the system. The configuration of particular models of servers should be done in consultation with a hardware vendor or consultant.

Generally, one front-end server is reasonable for every four back-end servers. However, this number is provided only as a suggested ratio and starting point, not as a rule. Front-end servers do not need large or particularly fast disk storage, but should have fast CPUs and a large amount of memory. There is no need to back up the disks on the front-end server unless you choose to enable SMTP, because SMTP commits queued mail to the local disk. For POP, IMAP, and HTTP, no user data is stored on the drive.

For more information about hardware requirements for front-end and back-end servers, see the following technical papers:

Load Balancing

In a corporate or hosting environment, you may want to load-balance the front-end servers. Windows provides load balancing through Network Load Balancing (NLB). Alternatively, other load-balancing mechanisms can be used, including hardware load-balancing solutions.

Windows NLB works by clustering two or more servers that represent the NLB cluster with a single IP address. Each computer receives traffic to its own unique IP address and the shared IP address. Each member of the NLB cluster performs a hashing algorithm to map incoming clients to one of the members of the NLB cluster based on the client IP address, port, and other information. When a packet arrives, all servers or hosts perform the same hashing algorithm, and the output is one of the hosts. That host then responds to the packet. The mapping does not change unless the number of hosts in the NLB cluster changes. The configuration of every server in the NLB cluster must be same, otherwise clients may experience different behavior depending on which server they are routed to.

Note

NLB has no health monitoring; if the World Wide Web Publishing Service on a front-end server is not running, for example, NLB continues to send requests to that server. You can run Microsoft Application Center 2000 on a front-end server to set up NLB and monitor the health of load-balanced servers. (However, you cannot manage Exchange resources or replicate Exchange configuration information through Application Center.) For more information about Application Center, see the Microsoft Application Center Web site.

Although it is not required, you should ensure that each user is always sent to the same front-end server for the duration of a session. This uses the Secure Sockets Layer (SSL) handshake caching and connection state information already maintained on the front-end server. Additionally, this is required for forms-based authentication, as only the front-end server that issues the cookie can decrypt it. In NLB, this is referred to as "client affinity." Many hardware solutions also have this ability

Note

Advanced firewall servers may affect your ability to NLB-cluster your front-end servers, particularly if they mask the incoming client IP address. For more information, see the product documentation or contact your manufacturer for more details.

Reducing Virtual Server Creation

In some circumstances, it could be important to reduce the number of virtual servers created on the back-end servers. You should not reduce the number of virtual servers unless you fully understand how HTTP virtual servers work. You can reduce virtual server creation by either of two methods.

Analyze the users and data on each back-end server to determine if users will ever be directed to that particular server. If a back-end server contains mailboxes for only adatum.com, there is no need for that back-end server to have a virtual server for contoso.com. If users from contoso.com are later added to that back-end server, however, an administrator may need to create a virtual server for contoso.com.

Similarly, you only have to create virtual directories for resources your users will require access to. On a server that has no public store, the public virtual directory is not required.