Chapter 5 Developing a Communications Suite Logical Architecture
This chapter describes how to develop your Communications Suite logical architecture. The logical architecture is a design that depicts the logical building blocks of the Communications Suite components and the infrastructure services needed to support them.
This chapter contains the following sections:
Communications Suite Deployment Logical Architectures Overview
You can deploy Communications Suite in either a single-tiered or two-tiered logical architecture. Deciding on your logical architecture is crucial, as it determines which machine types you will need, as well as how many.
In general, enterprise corporate deployments use a single-tiered architecture while internet service providers (ISPs) and telecommunications deployments use a two-tiered architecture. However, as with all generalities, the exceptions prove the rule. Small ISPs might just as well deploy on a single machine, and larger, centralized enterprises might deploy in a two-tiered architecture for many of the same reasons that ISPs do. As more and more corporations look to offer ease of access to employees working remotely, their deployments will begin to look more and more like an ISP.
This section discuss the following Communications Suite logical architectures:
-
Single-tiered Architecture. All services are either located on a single host sufficiently provisioned with memory and CPUs, or deployed on multiple servers, with each server hosting all of a particular component product’s services.
-
Two-tiered Architecture. The access and data layers for the component products are separated onto different servers.
-
Edge Architecture. Builds on the two-tiered architecture by also providing for secure connections over the Internet to a mobile workforce.
Whether you deploy Communications Suite in a single-tiered or multiple-tiered architecture, you need to understand the advantages and disadvantages of both models.
Single-tiered Logical Architecture for One Host
As its name implies, the single-tiered logical architecture for one host locates all services onto a single machine. In general, such an architecture is best suited for enterprises that are:
-
Composed of 500 users or less
-
Not geographically distributed
-
Served by few administrators
-
Seeking an entry-level configuration
The following figure represents the single-tiered logical architecture for one host.
Figure 5–1 Single-tiered Architecture for One Host
End-user client programs, such as Outlook and Messenger Express, form the User Tier. Tier 1 is a single machine running all services, including messaging, calendar, instant messaging, and directory. If you deploy Communications Express, the single machine is also running Web Server (or Application Server). The distinction of the single tier deployment is that end users communicate directly to the stores, and not through proxies or other agents.
The single-tiered logical architecture for one host requires a machine that provides sufficient CPU, memory, and storage. You should work with your Sun representative to determine the machine that best meets your organization’s needs for this type of deployment.
When implementing the single-tiered logical architecture for one host, you can position the deployment for growth into a multi-tiered architecture by assigning logical names to services. Such a configuration makes use of DNS mapping to direct users to the same front-end process (machine). If, in the future, you need to make changes to accommodate growth, such as splitting out services in a tiered fashion, users do not need to reconfigure their client applications. See Using Logical Service Names for more information.
Single-tiered Logical Architecture for Multiple Hosts
The single-tiered logical architecture for multiple hosts is a set of servers that each run the services particular to a component product. For example, the Messaging Server host is installed and configured to run all the Messaging Server services, the Calendar Server host is installed and configured to run all the Calendar Server services, and so on. This architecture might also be configured for high availability.
The distinction of the single-tiered logical architecture is that end users communicate directly to the data stores, and not through proxies or other agents. For example, in Messaging Server, users would not be routed through MMPs or MTAs. The single-tiered logical architecture might have standalone MTA routers for routing mail between servers, or in and out of the corporate network, but end users submit mail to the MTA on their message stores. No MMPs are involved in intranet connection to the message stores.
The same idea applies to both Calendar Server and Instant Messaging. In the single-tiered logical architecture, no front-end processes are located on separate machines.
Figure 5–2 represents the single-tiered logical architecture for multiple hosts.
Figure 5–2 Single-tiered Architecture for Multiple Hosts
In the preceding figure, end-user client programs, such as Outlook and Messenger Express, form the User Tier. Tier 1 is a set of four servers. One server runs the Calendar Server processes, the second runs the Messaging Server processes, the third runs the Instant Messaging processes, and the fourth runs the Directory Server process. If you are deploying Communications Express, the Messaging Server host also includes a web server, either Web Server or Application Server, (for Webmail).
Single-tiered Distributed Logical Architecture
The single-tiered distributed logical architecture is a variant of the single-tiered architecture in that the Directory Server is deployed in two tiers. Such a deployment works well for enterprises with small departments or organizations that are geographically distributed. Each department or office has its own services (mail, calendar, instant messaging) and a local directory instance (consumer). All the local directory instances are cached, but are synchronized with the centralized, master corporate repository. This is a fairly common scenario for offices with low bandwidth connectivity. The directory is architected in a two-tiered fashion and replicated over the low-bandwidth to keep data local.
Figure 5–3 represents the single-tiered distributed logical architecture.
Figure 5–3 Single-tiered Distributed Architecture
In the preceding figure, end-user client programs, such as Outlook and Messenger Express, form the User Tier. Tier 0 consists of load balancers that distribute load across the Tier 1 layer. Tier 1 is a set of multiple servers for the Communications Suite processes. Multiple servers run the Calendar Server processes, multiple servers run the Messaging Server processes, and multiple servers run the Instant Messaging processes. Directory Server processes are split between a consumer server in Tier 1 running a local, replicated copy of the directory, and another server situated in Tier 2, which contains the master copy of the directory. Notice that in this kind of deployment, client queries are directed to the local directory copy, not to the master copy. Only the local Directory Server communicates to the master Directory Server.
Note –
When deploying a single-tiered architecture with Internet connectivity, use a separate access layer. For example, you direct access to the data stores from inside the intranet without having to use SSL. However, you direct access to the data stores from the Internet through an access layer over SSL. This offloads much of the SSL load on the data stores to the access layer that separates it from the Internet.
The downside to this type of deployment is that users who make use of the server from a system that is sometimes on the corporate intranet and sometimes accessing the server from the Internet must configure their client applications to use SSL all the time. This is because it is too much trouble to switch back and forth. Therefore, there will still be a substantial percentage of SSL traffic being put on the stores directly. By using an access layer inside the intranet, you can remove that problem and by limiting connection directions further protect the intranet from illegal access.
Two-tiered Logical Architecture
In a two-tiered logical architecture, the data stores communicate through front-end processes. In the case of Messaging Server, this means MMPs and MTAs are residing on separate machines from the data store processes. A two-tiered architecture enables the mail store to offload important and common tasks and focus on receiving and delivering mail. In the case of Calendar Server, this means the HTTP service and Administration service reside on a separate machine from the store processes. In the case of Instant Messaging, this means the proxy service is residing on a separate machine from the back-end processes.
There might be some level of cohabitation with other services. For example, you could have the Calendar store and the Message Store on the same machine. Similarly, you could have the calendar front end on the MMP machine.
In a two-tiered logical architecture, Directory Server is usually a complex deployment in its own right, with multi-master and replication to a set of load-balanced consumer directories.
Figure 5–4 represents the two-tiered logical architecture.
Figure 5–4 Two-tiered Architecture
In the preceding figure, end-user client programs, such as Outlook and Messenger Express, form the User Tier. The load balancers form Tier 0. The Calendar Server, Messaging Server, Instant Messaging, and web proxy front ends form Tier 1. Finally, the Directory Server, Calendar Server, Messaging Server, and Instant Messaging back ends form Tier 2. When deploying Communications Express, you could have Web Server in Tier 2 as well.
A two-tiered architecture enables you to deploy Tier 1 and Tier 2 elements as separate instances, increasing overall flexibility of design. Additionally, you enhance system security by assigning discrete functions to individual instances.
For typical deployments, place the messaging and calendar front ends within the network Demilitarized Zone (DMZ), connecting to the main messaging and calendar services through a firewall. This configuration enables you to scale the system horizontally, as the Tier 1 elements can be scaled independently. Do not scale these elements beyond the capacity of the back-end servers.
When the front-end elements have reached the capacity of the back-end servers, you can scale the back-end Tier 2 elements to support more users. In general, the front end should scale as a function of the traffic. The back end should be scaled as a function of the number of users.
Note –
For specific instructions on sizing components in single-tiered or two-tiered architectures, contact your Client Services representative.
Edge Logical Architecture
The edge logical architecture adds security for remote access to the two-tiered logical architecture. An edge deployment grants access to a remote, mobile workforce over the public Internet by using only name/password authentication (SMTPAuth). As messages travel to and from the corporate network over the public Internet, they are encrypted through the use of SSL. No virtual private network is involved. The internal side of the communications transmission is “in the clear” for maximum performance. Access is contained on the “edge” of the deployment, protecting the data stores from unauthorized intrusion.
Business reasons for an edge deployment include:
-
Your workforce consists of mobile, remote workers.
-
You do not want to install and maintain Communications Suite servers at every remote site.
Figure 5–5 represents the edge logical architecture.
Figure 5–5 Edge Architecture
In the preceding figure, the data stores are located in Tier 2, which is a secure, private network, connected only to the “edge” and “internal” front-end servers. Remote clients connect to front-end servers by using SSL. Internal clients do not need to use SSL to connect, as the assumption is made that internal access is inherently secure.
Edge Architecture Design Recommendations
-
Capacity planning for the Edge tier is difficult to generalize. You should work with the hardware and software vendors who are supplying equipment for your deployment to develop a capacity plan. Nevertheless, you should implement the Realtime Blackhole List (RBL) at your site at the Edge tier. The RBL is a list of IP addresses whose owners refuse to stop the proliferation of spam.
-
Design the Edge tier for minimal latency (less that one millisecond through the entire Edge tier).
-
Use load balancing algorithms that are load-aware by CPU utilization or by the number of active connections. Round-robin is not an acceptable load-balancing model. With the exception of MTAs (stateless), use sticky-bit load balancing.
-
Webmail clients need load balancers that can manage sticky bits, because Webmail interfaces do not share state across Webmail servers.
Benefits of a Single-tiered Architecture
The benefits of the single-tiered architecture come down to cost savings, as you do not have to purchase nor maintain additional hardware.
Answer the following questions to help decide if the single-tiered architecture is best for your enterprise:
-
Is there no requirement for SSL?
-
Do you have significant maintenance windows available?
Answering yes to these questions suggests that your enterprise could use a single-tiered architecture.
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:
-
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, JavaScriptTM files, or HTML files. By placing these elements closer to the end user, you reduce network traffic on the back-end data center.
Horizontal Scalability Strategy
Scalability is critical to organizations needing to make the most cost-effective use of their computing resources, handle peak workloads, and grow their infrastructure as rapidly as their business grows. Keep these points in mind:
-
How the system responds to increasing workloads: what performance it provides, and as the workload increases, whether it crashes or enables performance to gracefully degrade.
-
How easy it is to add processors, CPUs, storage, and I/O resources to a system or network to serve increasing demands from users.
-
Whether the same environment can support applications as they grow from low-end systems to mid-range servers and mainframe-class systems.
When deployed in a two-tiered architecture, the Communications Suite offering is meant to scale very effectively in a horizontal manner. Each functional element can support increased load by adding additional machines to a given tier.
Scaling Front-end and Back-end Services
In practice, the method for scaling the front-end and back-end services differs slightly.
For Tier 1 elements, you start the scaling process when traffic to the front end grows beyond current capacity. You add relatively low cost machines to the tier and load balance across these machines. Thus, load balancers can precede each of the Tier 1 service functions as overall system load, service distribution, and scalability requirements dictate.
For Tier 2 elements, you start the scaling process when the back-end services have exceeded user or data capacity. As a general rule, design the Tier 2 services to accommodate just under double the load capacity of the Tier 1 services.
For example, for an architecture designed for 5,000 users, the Tier 1 front-end services are designed to support 5,000 users. The back-end services are then doubled, and designed to accommodate 10,000 users. If the system capacity exceeds 5,000 users, the front-end services can be horizontally scaled. If the overall capacity reaches 5,000 users, then the back-end services can be scaled to accommodate. Such design enables flexibility for growth, whether the growth is in terms of users or throughput.
Other Deployment Issues
This section describes some common Communications Suite deployment best practices and other deployment considerations.
Implementing Local Message Transfer Protocol (LMTP) for Messaging Server
Best practices say you should implement LMTP to replace SMTP for message insertion. An LMTP architecture is more efficient for delivering to the back-end Message Store because it:
-
Reduces the load on the stores. Relays are horizontally scalable while stores are not, thus it is a good practice to make the relays perform as much of the processing as possible.
-
Reduces IOPS by as much as 30 percent by removing the MTA queues from the stores.
-
Reduces the load on LDAP servers.
The LDAP infrastructure is often the limiting factor in large messaging deployments.
-
Reduces the number of message queues.
You need a two-tiered architecture to implement LMTP. See To Configure LMTP Delivery in Sun Java System Messaging Server 6.3 Administration Guide for instructions on configuring LMTP.
Note –
By design, LMTP is intended for use in multi-tier deployments. It is not possible to use LMTP with single-system deployments. Also, the Messaging Server's LMTP service as implemented is not designed to work with other LMTP servers or other LMTP clients.
Implementing Realtime Blackhole List (RBL)
The Mail Abuse Protection System’s Realtime Blackhole List (MAPS RBL) is a dynamically updated list of known unsolicited bulk email (UBE) sources identified by source IP address. The Messaging Server SMTP server supports use of the RBL and can reject mail coming from sources identified by the RBL as originators of UBE or spam.
Implementing an RBL should be a consideration of every deployment. In general, a good RBL deployed in front of MTAs reduces traffic to the MTAs by a minimum of 10 percent, and in some cases, much higher.
RBLs, and anti-spam and anti-virus servers, such as BrightMail, can work together. For example, if your anti-spam server rejects 95 to 99 out of 100 emails from a particular IP address, you can add that IP address to the RBL. You can also adjust the RBL for BrightMail’s false positives when you conduct your BrightMail analysis. Thus, you make the RBL much more proactive in handling a specific wave of UBE.
See Sun Java System Messaging Server 6.3 Administration Reference for information on configuring the ENABLE_RBL option of the MTA Dispatcher.
Using Logical Service Names
Design your deployment around the use of logical names for Communications Suite servers. You should use logical names even on a single-system deployment, to position it for ease of future growth and expansion. Using logical names does not impose any additional deployment setup costs other than populating your DNS.
You can think of these logical names as falling into two categories: those that affect end users, such as settings in email client programs; and those affecting back-end administration, such as inbound SMTP servers.
The following tables describes these logical entities.
Table 5–1 User Facing Logical NamesTable 5–2 Maintenance Level Logical Names
|
Example |
Description |
|---|---|
|
relay-in.siroe.com |
Corresponds to a bank of inbound SMTP servers. |
|
relay-out.siroe.com |
Corresponds to a bank of outbound SMTP servers. |
|
mmp.siroe.com |
Corresponds to a bank of MMP servers. |
|
storeAA.siroe.com |
Back-end message store. Select a naming scheme to work with your topology, for example, storeAA.siroe.com through storeZZ.siroe.com. |
|
calstoreAA.siroe.com |
Back-end calendar store. Select naming scheme to work with topology, for example, calstoreAA.siroe.com through calstoreZZ.siroe.com. |
Table 5–3 Mapping of User Level to Maintenance Level Logical Names
|
Maintenance Level |
User Level |
|---|---|
|
relay-in.siroe.com |
N/A |
|
relay-out.siroe.com |
smtp.siroe.com |
|
mmp.siroe.com |
Any one or more of mmp.siroe.com, pop.siroe.com, and imap.siroe.com |
|
storeAA.siroe.com - storeZZ.siroe.com |
N/A, hidden from end users |
|
calstore_aa.siroe.com - calstore_az.siroe.com |
N/A, hidden from end users |
- © 2010, Oracle Corporation and/or its affiliates