Part VII Deployment Examples

This part contains the following chapter:

Chapter 28, Communications Suite Deployment Examples

Chapter 28 Communications Suite Deployment Examples

This chapter contains Communications Suite deployment examples. Depending on the features you want to implement in your deployment, you will need to install different sets of hosts and other networking infrastructure.

This chapter contains the following sections:

Note –

When making architectural decisions, ranging from single host deployment, to multi-tiered deployments, you should always plan for service definition across multiple tiers. Thus, use logical service names to install, even on a single host deployment. Logical service names position deployments for easier expansion. See Using Logical Service Names for more information.

Communications Suite Single-tiered Logical Deployment Example for One Host

As its name implies, this example installs and configures components onto a single server. Consult with your Sun Client Services representative to determine the server type and configuration that best suits your needs.

In general, the single-tiered one host architecture is best suited for enterprises that are:

Composed of less than 1,000 users
Not geographically distributed
Served by few administrators
Seeking an entry-level configuration

The trade-offs associated with a single-host configuration include:

No high availability to the infrastructure to ensure service reliability (unless the server itself provides automatic system reconfiguration)
No ability to counteract denial of service attacks

Figure 28–1 shows a single-host deployment example. The following Communications Suite components are installed on the same host:

Messaging Server (MTA, Message Store, and Webmail Server)
Calendar Server (Administration service, HTTP service, and Backup service)
Communications Express
Web Server

In this example, the directory service resides on a different host than Communications Suite. Directory Server and Access Manager are a complex deployment on their own. This figure represents those components by a “cloud.”

Figure 28–1 Communications Suite Single-tiered Deployment Example for One Host

This diagram shows a Communications Suite single-tiered deployment
example on a single host.

The following table explains the protocols and port numbers used by this deployment.

Table 28–1 Protocols And Ports Used by Single-tiered Deployment Example


Protocol	Port	Used By
SMTP	25	Messaging Server MTA component to communicate with other systems, and Calendar Server (`csenpd`) component to send email notifications
HTTP	80	Clients to communicate with the Messaging Server Webmail (`mshttpd`) components
HTTP	81	Communications Express to communicate with Calendar Server (`cshttpd`)
HTTP	82	Communications Express to communicate with Messaging Server (`mshttpd`)
IMAP	143	Clients to communicate with the Messaging Server `imapd` components
LDAP	389	Messaging Server and Calendar Server to communicate with LDAP directory

To position this deployment for future growth, you would use logical service names to install. Logical service names position deployments for easier expansion. See Using Logical Service Names for more information. You would consider expanding to a two-tiered architecture when issues arise with capacity, performance, multiple geographic sites, and availability.

Communications Suite Two-tiered Logical Deployment Example for Multiple Hosts

Figure 28–2 shows a two-tiered logical deployment example for Messaging Server and Calendar Server. Tier 0 consists of load balancers. Tier 1 consists of Calendar Server and Messaging Server front ends. The Calendar Server and Messaging Server back-end stores form Tier 2.

Directory Server and Access Manager are a complex deployment on their own. This figure represents those components by a “cloud.”

Figure 28–2 Communications Suite Two-tiered Deployment Example

In the preceding example, load balancers form Tier 0, and direct user access to the front-end services.

The front-end services consist of four machines. Two machines are installed with Calendar Server front-end components. These Calendar Server front-end machines consist of one or two CPU servers and their own internal disk storage. Two other machines are configured as Messaging Server proxies and MTAs, and share an external disk array. These Messaging Server machines consist of four CPU servers.

The back end also consists of four machines. Two machines serve as mail stores and run the Messaging Server processes. Two other machines serve as the calendar stores and run Calendar Server process. The store machines are attached to a Storage Area Network (SAN). These back-end machines can be deployed in a variety of ways, based upon your CPU needs. Once you determine the total number of CPUs, you can opt for a vertical or horizontal configuration. For example, if your architecture called for a total of twelve CPUs, you could use three four-way servers, two six-way servers, or even one 12-way server.

Another machine serves as an SMTP relay for both Calendar Server notifications and Messaging Server emails.

The following table explains the protocols and port numbers used by this deployment.

Table 28–2 Protocols And Ports Used by Two-tiered Deployment Example


Protocol	Port	Used By
HTTP	80	Clients to communicate with the Messaging Server Webmail (`mshttpd`) components
SMTP	25	Clients to communicate with the Messaging Server MTA component, MTA components on the front end and back end, and Calendar Server (`csenpd`) components for email notifications
IMAP	143	Clients to communicate with the Messaging Server MMP and `imapd` components
LMTP	225	MTA routes email directly from the front end to the Message Store on the back end, bypassing the back-end MTA
LDAP	389	Front ends and back ends to communicate with LDAP directory
HTTP	8081	Clients to communicate with Calendar Front End (`cshttpd`)
DWP	9779	Calendar front end (`cshttpd`) to communicate with Calendar back end (`csdwpd`)