|
| |
| Sun Java System Communications Services 6 2004Q2 Enterprise Deployment Planning Guide | |
Chapter 4
Developing a Communications Services Logical ArchitectureThis chapter describes how to develop your Communications Services logical architecture.
This chapter contains the following sections:
Communications Services Enterprise Deployment Logical Architectures OverviewYou can deploy Communications Services in either a single tier or two tier 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 tend towards the single tier, whereas ISP and Telco deployments are two tier. 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-tier 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 Services logical architectures:
- Single Tier. 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 Tier. The access and data layers for the component products are separated onto different servers.
- Edge. Builds on the two-tier architecture by also providing for secure connections over the Internet to a mobile workforce.
Whether you deploy Communications Services in a single tier or multiple tiers, you need to understand the advantages and disadvantages of both models.
Single Tier, One Host Logical Architecture
As its name implies, the single tier, one host logical architecture locates all services onto a single machine. In general, such an architecture is best suited for enterprises that are:
The following figure represents the single tier, one host logical architecture.
Figure 4-1 Single Tier, One Host Logical Architecture
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. 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 tier, one host logical architecture 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 enterprise’s needs for this type of deployment.
When implementing the single tier, one host architecture, you can position the deployment for growth into a 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 Tier, Multiple Hosts Logical Architecture
The single tier, multiple hosts logical architecture 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 tier 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 tier 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 tier logical architecture, no front-end processes are located on separate machines.
Figure 4-2 represents the one-tier, multiple hosts logical architecture for Communications Services.
Figure 4-2 Single Tier Multiple Hosts Logical Architecture
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.
Single Tier Distributed Logical Architecture
The single tier distributed logical architecture is a variant of the single tier 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-tier fashion and replicated over the low-bandwidth to keep data local.
Figure 4-3 represents the single tier distributed logical architecture for Communications Services.
Figure 4-3 Single Tier 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 Services 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.
Two Tier Logical Architecture
In a two tier logical architecture, the data stores communicate through front-end processes. In the case of Messaging Server, this means MMPs, MEMs, and MTAs are residing on separate machines from the data store processes. This 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 tier 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 4-4 represents the two tier logical architecture for Communications Services.
Figure 4-4 Two Tier 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, and Instant Messaging front ends form Tier 1. Finally, the Directory Server, Calendar Server, Messaging Server, and Instant Messaging back ends form Tier 2. This 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-tier or two-tier architectures, contact your Professional Services representative.
Edge Logical Architecture
The edge logical architecture adds security for remote access to the two tier 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:
Figure 4-5 represents the edge logical architecture for Communications Services.
Figure 4-5 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.
Edge Architecture Design Recommendations
- Capacity planning for 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 Tier Architecture
The benefits of the single tier approach to your logical 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 tier logical architecture is best for your enterprise:
Answering yes to these questions suggests that your enterprise could use a single tier logical architecture.
Benefits of a Two Tier Architecture
All services within the Communications Services offering rely on network capabilities. A two tier architecture provides for a network design with two separate networks: the public (user-facing) network, and the private (data center) network. The separation of these two networks is made possible by the Access-Layer Application hosts.
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 Message Transfer Agent (MTA) 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-tier 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 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 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. Both the Messaging Express Multiplexor (MEM) and the calendar front-end greatly reduce 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™ 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 StrategyScalability is critical to enterprises 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-tier architecture, the Communications Services 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.
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 growing enterprises, whether the growth is in terms of users or throughput.
Other Deployment IssuesThis section describes some common Communications Services deployment best practices and other deployment considerations.
Implementing LMTP for Messaging Server
Best practices say you should implement LMTP to replace SMTP for message insertion. An LMTP architecture removes some of the demand for storage IOPs while providing a more robust and efficient solution that will increase system reliability and position your deployment for implementing new services.
The MTA’s LMTP server 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.
- Pulling the MTA queues from the stores could reduce IOPS by as much as 30 percent.
- 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-tier architecture to implement LMTP. See the Sun Java System Messaging Server Administration Guide for instructions on configuring LMTP:
Implementing Realtime Blackhole List (RBL)
The Mail Abuse Protection System’s Realtime Blackhole List (MAPS RBL) is a dynamically updated list of known UBE sources identified by source IP address. The Messaging Server SMTP server supports use of the RBL and can reflect mail coming from sources identified by the RBL as originators of unsolicited bulk email (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.
RBL 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 the Sun Java System Messaging Server 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 the Communications Services. 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 table describes these logical entities.
