Benefits of a Two-tiered Architecture

All services within the Communications Suite offering rely on network capabilities. A two-tiered architecture provides for a network design with two separate networks: the public (user-facing) network, and the private (data center) network.

Separating your network into two tiers provides the following benefits:

• Hides Internal Networks. By separating the public (user-facing) network and the private (data center) network, you provide security by hiding the data center information. This information includes network information, such as IP addresses and host names, as well as user data, such as mailboxes and calendar information.

• Provides Redundancy of Network Services. By provisioning service access across multiple front-end machines, you create redundancy for the system. By adding redundant messaging front-end servers, you improve service uptime by balancing SMTP requests to the available messaging front-end hosts.

• Limits Available Data on Access Layer Hosts. Should the access layer hosts be compromised, the attackers cannot get to critical data from the access hosts.

• Offloads Tasks to the Access Layer. By enabling the access layer to take complete ownership of a number of tasks, the number of user mailboxes on a message store increases. This is useful because the costs of both purchase and maintenance are much higher for store servers than for access layer machines (the second tier). Access layer machines are usually smaller, do not require large amounts of disk (see MTA Performance Considerations), and are rarely backed up. A partial list of features that are offloaded by the second tier includes:

  • Denial of Service protection

  • SSL

  • Reverse DNS

  • UBE (spam) and virus scanning

  • Initial authentication - Authentications to the Message Store should always succeed and the directory servers are more likely to have cached the entry recently.

  • LMTP - With support for LMTP between the MTA relays and the message stores, SMTP processing is offloaded and the need to do an additional write of the message into the MTA queues on the message stores is eliminated.

• Simplifies End-user Settings in Client Applications. By using a two-tiered architecture, end users do not have to remember the physical name of hosts that their messaging and calendar applications connect to. The Access-Layer Application hosts provide proxies to connect end users to their assigned messaging or calendar data center host. Services such as IMAP are connected to the back-end service using LDAP information to identify the name of the user’s mailbox host. For calendar services, the calendar front-end hosts provide a calendar lookup using the directory server to create a back-end connection to the user’s assigned calendar store host.

  This capability enables all end users to share the same host names for their client settings. For example, instead of remembering that their message store is host-a, the user simply uses the setting of mail. The MMP provides the proxy service to the user’s assigned message store. You need to provide the DNS and load balancing settings to point all incoming connections for mail to one (or more) MMPs.

  By placing Calendar Server into two tiers, more than one Calendar Server back-end server can be used. Calendar Server’s group scheduling engine enables users to schedule appointments with users whose calendars are on any of the back-end Calendar Server hosts.

  An additional benefit of this proxy capability provides geographically dispersed users to leverage the same client application settings regardless of their physical location. Should a user from Europe visit California, the user will be able to connect to the immediate access server in California. The user’s LDAP information will tell the access server to create a separate connection on the user’s behalf to the user’s message store located in Europe.

  Lastly, this enables you to run a large environment without having to configure user browsers differently, simplifying user support. You can move a user’s mailbox from one mail store to another without contacting the user or changing the desktop.

• Reduces Network HTTP Traffic on the Data Center. The Calendar Server front end greatly reduces HTTP traffic to the data center network. HTTP provides a connectionless service. For each HTML element, a separate HTTP request must be sent to the mail or calendar service. These requests can be for static data, such as an image, style sheets, JavaScript^TM files, or HTML files. By placing these elements closer to the end user, you reduce network traffic on the back-end data center.