Developing Messaging Server Architectural Strategies

Once you have identified your system performance needs, the next step in sizing your Messaging Server deployment is to size specific components based on your architectural decisions.

The following sections point out sizing considerations when you deploy two-tiered and one-tiered architectures.

For detailed information on planning your architecture, see Chapter 11, Developing a Messaging Server Architecture.

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.

Single-tiered Messaging Server Architecture

In a single-tiered architecture, there is no separation between access and data layers. The MTA, Message Store, and sometimes the Directory Server are installed in one layer. Figure 10–2 shows a single-tiered architecture.

Figure 10–2 Simplified Messaging Server Single-tiered Architecture

Single-tiered architectures have lower up-front hardware costs than two-tiered architectures. However, if you choose a one-tiered architecture, you need to allow for significant maintenance windows.

To Size a Single-tiered Messaging Server Architecture

1. Size your message stores like you size message stores in a Two-tiered Messaging Server Architecture.

2. Add CPU for SSL, if necessary.

3. Account for denial of service attacks.

4. Add more disks for the increased number of SMTP connections.

5. Add more disks for outbound MTA routing.

   ---

   Note –

   For specific instructions on sizing Messaging components in single-tiered or two-tiered architectures, contact your Sun Client Services representative.

   ---