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.
Easier maintenance than one-tiered architectures
Easier growth management and system upgrade with limited overall downtime
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.
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.
Determine the amount of storage needed for each store machine.
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.
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.
From the raw performance of the inbound MTA, add SSL, virus scanning processes, and other extraordinary message processing.
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.
In addition, you must:
Add CPU or a hardware accelerator for SSL.
Add more disks for an SMTP proxy.
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.