Most Exchange Server environments will grow beyond their original sizing.  Sometimes this growth has been accounted for in the design, and sometimes it is not.  In either case the question to ask as the user base increases is whether to scale up or scale out.

What do each of those terms mean?  An example of scaling up would be increasing the capacity of a server to handle higher loads.  An example of scaling out would be adding new servers to spread the higher load across more hosts.

Each approach has its pros and cons in the context of the different Exchange Server roles.  In this post I’ll discuss the Exchange Server 2007 Transport server roles and the different scaling considerations that they have.

Edge Transport/Hub Transport Servers

The role of the Edge Transport server is to route incoming and outgoing internet email while applying security and compliance rules to messages.  The role of the Hub Transport is basically the same though it is also responsible for routing emails between internal mailboxes as well.

The Transport Server workload relies primarily on fast CPUs to assess and process each email message against these rules, and fast disks for reading and writing messages to the transport queue.

Processor Scaling

Scaling up with more CPU cores to handle higher workloads is appropriate; however, there is a practical limit of 4 CPU cores per Edge Transport server and 8 cores per Hub Transport server.  This is an obvious “scale out” threshold for this server role – if the server is already at the maximum number of cores and CPU is showing signs of a performance bottleneck then it is time to look at scaling out to more Transport servers.

Disk Scaling

Disk performance is slightly different.  Each Transport server has a transport queue, which is a location on the disk in which emails are read and written in a database.  Emails are only temporarily stored in this queue, and large capacity disks are quite cheap and common in servers these days, so disk space is not likely to be a problem for the volume hosting the transport queue.

On the other hand, disk speed may become a problem in larger Exchange Server environments where email traffic is very high.  Because the transport queue can’t be split across multiple volumes within a single server if disk performance becomes a bottleneck the only option is to scale out to more Transport servers.

Scaling Impacts

Scaling up a Transport server usually won’t affect the configuration requirements for the server.  However scaling out often will require some configuration or architecture changes.  Hub Transport servers have their own load balancing algorithms built-in so not much needs to be done there, but Edge Transport servers will need some attention.

Each Edge Transport server needs to be “subscribed” to the Active Directory Site that hosts the Hub Transport servers it will relay messages with.  This subscription is configured per-server.  Furthermore, there is no common settings location for multiple Edge Transport server, each must be configured individually (although this can be scripted to reduce administrative effort).

Finally, once you scale out to more than one Edge Transport server either multiple public IP addresses and MX records are required, or a load balancing solution needs to be implemented for inbound internet email traffic.

In the next post in this series I will discuss scaling considerations for the Client Access server role.