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.
Whether you deploy Communications Suite in a single-tiered or multiple-tiered architecture, you need to understand the advantages and disadvantages of both models.
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.
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.
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.
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).
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.