Two-tiered Messaging Server Architecture

A two-tiered architecture splits the Messaging Server deployment into two layers: an access layer and a data layer. In a simplified two-tiered deployment, you might add an MMP and an MTA to the access layer. The MMP acts as a proxy for POP and IMAP mail readers, and the MTA relays transmitted mail. The data layer holds the Message Store and Directory Server. Figure 10–1 shows a simplified two-tiered architecture.

Figure 10–1 Simplified Messaging Server Two-tiered Architecture

Two-tiered architectures have advantages over one-tiered architectures that might impact your sizing decisions. Two-tiered architectures permit:

• Easier maintenance than one-tiered architectures

• Offloading of load-intensive processes like SSL, virus scanning, message reprocessing, and denial of service

• Easier growth management and system upgrade with limited overall downtime

The next several sections describe how to size specific components in a two-tiered deployment.

To Size the Message Store

The goals of sizing your Message Store are to identify the maximum number of concurrent connections your store can handle and to determine the number of messages that can be delivered to the store per second.

1. Determine the number of store machines and concurrent connections per machine based on the figures you gather by using a load simulator. For more information on sizing tools, see Using a Messaging Server Load Simulator.

2. Determine the amount of storage needed for each store machine.

3. Use multiple store partitions or store machines, if it is appropriate for your backup and restoration of file system recovery times.

   Sun Client Services is often asked to specify a recommendation for the maximum number of users on a message store. Such a recommendation cannot be given without understanding:

   • Usage patterns (as described in Using a Messaging Server Load Simulator.

   • The maximum number of active users on any given piece of hardware within the deployment.

   • Backup, restore, and recovery times. These times increase as the size of a message store increases.

To Size Inbound and Outbound MTAs

In general, separate your MTA services into inbound and outbound services. You can then size each in a similar fashion. The goal of sizing your MTAs is to determine the maximum number of messages that can be relayed per second.

To size inbound MTAs, you need to know the raw performance of your inbound MTA in a real-world environment.

1. From the raw performance of the inbound MTA, add SSL, virus scanning processes, and other extraordinary message processing.

2. Account for denial of service attacks at peak volume in the day.

3. Add enough MTAs for load balancing and for redundancy as appropriate.

   With redundancy, one or more of each type of machine can still handle peak load without a substantial impact to throughput or response time.

   In addition, sufficient disk capacity for network problems or non-functioning remote MTAs must be calculated for transient messages.

To Size Your MMP

When you size your MMP, the calculation is based on your system load, particularly the number of POP and IMAP concurrent connections for the MMP.

In addition, you must:

1. Add CPU or a hardware accelerator for SSL.

2. Add more disks for an SMTP proxy.

3. Account for denial of service.

4. Add capacity for load balancing and redundancy, if appropriate.

   As with inbound MTA routers, one or more of each type of machine should still handle peak load without a substantial impact to throughput or response time when you plan for redundancy in your deployment.