test

Sun Java Communications Suite 5 Deployment Planning Guide

Chapter 3 Understanding Product Requirements and Considerations

This chapter describes requirements and considerations that impact the design of your deployment. You need to understand these requirements and considerations to accurately determine your Communications Suite architecture.

This chapter contains the following sections:

Planning for Various Components

When designing your Communications Suite deployment architecture, take into account the requirements of the various component products of your deployment. For example, if you have a technical requirement to integrate Communications Suite with other Java System products, you need to choose your schema accordingly. Inter-product dependencies, for example, how Communications Suite accesses and places load on Directory Server, present deployment choices as well.

Understanding the individual components of each product enables you to plan for the type of architecture to best suit your requirements. Depending on your deployment, you need to potentially understand and plan for the following components:

Understanding Service Components and Service Tiers

When planning a Communications Suite deployment for multiple component products or services, you need to understand the composition of each component product (or service) itself.

Figure 3–1 illustrates how you can separate each service into components that can be deployed on separate hosts, and the particular tier each component occupies. Though you can deploy all components on a single host, or deploy a particular service’s components on the same host, consider moving to a tiered architecture. A tiered architecture, whether it be single-tiered, or two-tiered, provides a number of benefits. See Benefits of a Single-tiered Architecture and Benefits of a Two-tiered Architecture for more information.

Figure 3–1 Communications Suite Components

This diagram shows the various Communications Suite client, access, and data components.

In the preceding figure, the client components consist of the Outlook Connector plugin, thick clients such as Evolution, browsers, and standard email applications. These components reside on end users’ client computers. The access layer components consist of front-end services from Messaging Server (MMP and MTA); Calendar Server; Communications Express and Webmail Server; Instant Messaging (Instant Messaging Proxy); Portal Server (SRA and Core); Access Manager for authentication; and a corporate directory, which provides address book lookup. The data layer components consist of back-end services from Directory Server (which, in itself, can consist of front-end and back-end components); Messaging Server (Message Store); Calendar Server (Calendar Store); and Instant Messaging. A Storage Area Network (SAN) “cloud” represents the physical data storage.

Note –

The corporate directory shown in this figure is not a component product in itself. It represents a “copy” of the corporate directory that enterprises typically deploy in the access layer for clients to perform address-book type lookups.

The following sections explain these various components in more detail.

LDAP Directory Information Tree Requirements

The Directory Information Tree (DIT) is a way to organize directory entries in a tree structure, or schema, with nodes representing domains, subdomains, users, and groups. Sun Java Enterprise System introduces a fundamental change to how the directory is structured by implementing a one-tree structure.

Changes in the DIT Structure

Messaging Server and Calendar Server have introduced a one-tree structure, where there is no Domain Component (DC) Tree. All domain information is held in domain nodes in the Organization Tree. Aliasing is handled entirely differently in the new one-DIT structure.

The bottom half of Figure 3–2 illustrates a one-tree LDAP structure.

Figure 3–2 Two-Tree LDAP Structure Compared With One-Tree Structure

This diagram compares the one-tree LDAP structure, introduced by Messaging Server 6.0, with the previous two-tree structure.

Benefits of a One-Tree DIT Structure

The main advantages to using the one-tree structure Schema 2 native mode are:

As illustrated in the following figure, in the two-tree structure, some nodes point directly to a node in the Organization Tree (using the attribute inetDomainBaseDN). Other nodes are aliased nodes, which instead of pointing directly to an Organization Tree node, point to another DC Tree node, using the aliasedObjectName attribute.

Figure 3–3 Two-Tree Aliasing With aliasedDomainName and inetDomainBaseDN

This diagram shows the two-tree LDAP with an aliasedObjectName set up.

In the previous figure, sesta.com in the DC Tree points to siroe.com in the DC Tree using aliasedObjectName, and siroe.com points to the like named node in the Organization Tree, using inetDomainBaseDN.

Furthermore, as shown in Figure 3–4, there could be one or more nodes in the DC Tree using inetDomainBaseDN to point directly to the same node in the Organization Tree. In this case, a “tie-breaker” attribute, inetCanonicalDomainName, is necessary on one of the DC Tree nodes to designate which is the “real” domain name (the domain where the mail actually resides and where the mail is routed).

Figure 3–4 Two-Tree Aliasing With inetCanonicalDomainName

This diagram shows the two-tree LDAP with two DC Tree nodes pointing to the same Organization Tree node, using inetCanonicalDomainName.

By contrast, a one-tree structure contains only an Organization Tree, as shown in the following figure.

Figure 3–5 One-Tree Aliasing With associatedDomain

This diagram demonstrates the simplified way aliases are handled in Sun ONE Schema, v.2.

In the one-tree structure, domain nodes in the Organization Tree contain all the domain attributes formerly found on the DC Tree. Each domain node is identified by the sunManagedOrganization object class and sunPreferredDomain attribute, which contains the DNS domain name. A domain node can also have one or more associatedDomain attributes, which list the alias names this domain is known by. Contrary to the two-tree structure, there are no duplicate nodes for the alias names.

A one-tree DIT structure is beneficial in how you partition data for organization-specific access control. That is, each organization can have a separate subtree in the DIT where user and group entries are located. Access to that data can be limited to users in that part of the subtree. This allows localized applications to operate securely.

In addition, for new deployments of Calendar Server or Messaging Server, a one-tree structure maps better to existing single-DIT LDAP applications.

Schema Requirements

Before you install any of the Communications Suite products, you need to understand which schema you will use. The schema is the set of definitions describing what types of information can be stored as entries in the directory. Two schema choices, Sun Java System LDAP Schema 1 and Sun Java System LDAP Schema 2, are available and supported with Communications Suite. Your choice of schema depends on the following criteria:

Use Schema 2 if you:

Note –

You do not have to use Access Manager 6 to provide SSO. If you choose, you can still use the trusted circle type of SSO, which does not rely on Access Manager 6.

Use Schema 1 if you:

See Chapter 8, Understanding Schema and Provisioning Options for more information on schema choices.

Directory Server Considerations

Sun Java System Directory Server provides flexible, multi-tiered data storage for intranet, network, and extranet information. Directory Server integrates with existing systems and acts as a centralized repository for the consolidation of employee, customer, supplier, and partner information. You can extend Directory Server to manage user profiles and preferences, as well as extranet user authentication.

All custom LDAP schemas, such as those from Portal Server, Access Manager, Messaging Server, Calendar Server, and Instant Messaging, install into a single Directory.

There are many ways to architect your data environment and many factors to consider that depend on your business objective and expected usage patterns. Your directory design should address the following areas:

See the Directory Server documentation for a complete description of these factors and suggestions about how to architect your data environment:

http://docs.sun.com/coll/1316.1

Directory Server and Tiered Architecture Considerations

In moving from a single-tiered architecture to a multiple-tiered architecture, Directory Server should be the first component that you “split out” onto its own machine. At a certain point of load, Directory Server and Messaging Server on the same host have inherent performance impacts. This is due to the way Messaging Server is architected to work with Directory Server. Separating Directory Server onto its own machine is the first step to improve performance for a deployment.

See Chapter 5, Developing a Communications Suite Logical Architecture for more information on tiered architectures.

Note –

You can install Directory Server in such a way to have a clear separation between the directory user management and the software application configuration. Should you want to remove the software application configuration piece, this separation provides a cleaner way of removing that information from Directory Server.

Directory Server Topology Considerations

Though it is feasible to build a deployment around an instance of Directory Server installed on a single machine, the other Communications Suite components depend upon the directory as a core service to function. Thus, beyond trivial deployments, you should plan to deploy Directory Server in a redundant or highly availability configuration.

The first step toward making Directory Server more available is to establish a pair of master directory servers. Next, multimaster replication can be used to improve the LDAP write throughput and availability. If Sun Cluster is used for a high-availability deployment, then the two LDAP masters are clustered together. See Directory Server and High Availability for more information.

Directory Server Capacity Planning

While there are no hard and fast rules for Directory Server capacity planning, actively monitoring the directory is essential to ensure that performance metrics are met. When the system is not meeting these metrics, then it is time to add an additional directory consumer. Typically, you will want to monitor:

Evaluate the above metrics against a target response time of 10 Milliseconds. The IOWAIT should not exceed 10 Milliseconds, and the sum of the CPU utilization in this tier should not exceed 70 percent.

Directory Server and Calendar Server Interaction Considerations

Calendar Server performs multiple writes to user entries stored in Directory Server. The bulk of these writes occur when the user logs into Calendar Server for the first time and when the user performs certain actions. These actions include creating a calendar, subscribing to a calendar, changing a preference, and so on. If you do not take these actions into consideration, the Directory Master Server can experience heavy loads.

If you use Directory replication, the LDAP Master Server is replicating entries to the LDAP Replica servers. As Calendar users perform one of these actions, Calendar Server will only be able to write changes to the Master Directory Server. This is because the Replicas are read-only.

A second interaction consideration exists in these replicated Directory structures. As users make preference changes, their changes might not be rendered successful until the change is successfully replicated from the Master Directory Server to the Directory Replica, which is in use by the Calendar Server. A workaround is available, in which you configure Calendar Express (cshttpd) attempts to cache the change locally to avoid this latency delay. See Planning for the Calendar Server LDAP Data Cache for more information.

Directory Server and Personal Address Book Considerations

The Messenger Express Client supports the concept of a Personal Address Book (PAB). This enables users to store personal contacts (for example, business contacts, friends, and family) in the Directory Server. Each time a new personal contact is added to the user’s PAB, a write is made on the Directory Server. If you do not take these actions into consideration, the LDAP Master Server can face heavy loads (regardless of the Directory replication strategy).

One method to avoid performance issues on the User and Group Directory Server is to place the PAB information on a separate Directory Server. This enables PAB interactions to avoid placing a load on the LDAP Master Server.

Note –

If you are running both the current Communications Express client and also the deprecated Messenger Express Web mail interface, the address books used by these two clients do not share information. If end users switch between the two client interfaces, the two address books will contain different entries.

Messaging Server Considerations

In developing your Communications Suite architecture, you need to evaluate the performance aspects of the following Messaging Server components:

For a complete discussion of the performance aspects of these components, and potential hardware solutions, see Performance Considerations for a Messaging Server Architecture.

Calendar Server Considerations

Calendar Server consists of five major services:

In a scalable Calendar Server deployment, you would deploy front-end systems in conjunction with a back-end server. The front-end systems would contain one instance of the cshttpd daemon per processor and a single Administration Service. A back-end server would contain an instance of Notification Service, Event Notification Service, Distributed Database Service and Administration Service.

Authentication and XML / XSLT transformation are two Calendar Service activities that generate heavy load. Additional CPUs can be added to meet quality of service requirements. In a scalable environment, these heavy load activities take place on the front-end system(s), permitting more CPUs to be added to individual front-end systems, or more front-end systems to be added, to meet quality of service requirements.

Note –

The preceding paragraph is not applicable if the Communications Express Calendar client is used for calendar access. Communications Express uses the WCAP protocol to access Calendar Server data and therefore the Calendar Server infrastructure is not doing the XML/XSLT translations. See Part V, Deploying Communications Express deploying Communications Express.

Calendar back-end services usually require half the number of CPUs sized for the Calendar front-end services. To support quality of service by the Calendar front-end system, the Calendar back-end system should use around two-thirds of the front-end CPUs.

Consider early on in your deployment planning to separate the Calendar Service into front-end and back-end services.

The Calendar Server HTTP process that is typically a component of the front-end services is a dominant user of CPU time. Thus, account for peak calendar usage and choose sufficient front-end processing power to accommodate the expected peak HTTP sessions. Typically, you would make the Calendar Server front end more available through redundancy, that is, by deploying multiple front-end hosts. As the front-end systems do not maintain any persistent calendar data, they are not good candidates for HA solutions like Sun Cluster or Veritas. Moreover, the additional hardware and administrative overhead of such solutions make deploying HA for Calendar Server front ends both expensive and time-consuming.

Note –

The only configuration for Calendar front ends that might warrant a true HA solution is where you have deployed the Calendar front end on the same host that contains a Messaging Server MTA router. Even in this configuration, however, the overhead of such a solution should be carefully weighed against the slight benefit.

A good choice of hardware for the Calendar Server front ends is a single or dual processor server. You would deploy one instance of the Calendar Server cshttpd process per processor. Such a deployment affords a cost-effective solution, enabling you to start with some level of initial client concurrency capability and add client session capacity as you discover peak usage levels on your existing configuration.

When you deploy multiple front ends, a load balancer (with sticky/persistent connections) is necessary to distribute the load across the front-end services.

Note –

Communications Express does not scale beyond two processors. The same hardware choices explained previously for Calendar Server apply to Communications Express deployments.

The Calendar Server back-end services are well balanced in resource consumption and show no evidence of bottleneck formation either in CPU or I/O (disk or network). Thus, a good choice of hardware for the back end would be a SPARC server with a single striped volume. Such a machine presents considerable capacity for large-peak calendar loads.

If your requirements include high availability, it makes sense to deploy the Calendar Server back end with Sun Cluster, as the back end does contain persistent data.

Note –

In a configuration with both front-end and back-end Calendar Server hosts, all hosts must be running:

Instant Messaging Considerations

As with other Communications Suite components, you can create an architecture in which you separate Instant Messaging into front-end (Instant Messaging multiplexor) and back-end components (server and store). See Developing Instant Messaging Architectural Strategies for more information.

Portal Server Considerations

You can install Communications Suite products with Portal Server to provide an “umbrella” front end to access messaging, calendar, and instant messaging applications. The integration of Portal Server includes single sign-on capabilities between Portal Server, Calendar Express web client, Messaging Express web client and Communications Express client. In addition, the Messaging Express, Calendar Express, and Instant Messaging clients are made available to users through the Portal Server desktop.

See the Sun Java System Portal Server 7.1 Deployment Planning Guide and the Sun Java System Access Manager 7.1 Deployment Planning Guide for more information.

Connector for Microsoft Outlook Considerations

This section describes some deployment issues you will encounter deploying Connector for Microsoft Outlook. For complete information, see the Connector for Microsoft Outlook documentation:

http://docs.sun.com/app/docs/coll/1312.2

Sun Java System Connector for Microsoft Outlook enables Outlook to be used as a desktop client with Sun Java Enterprise System. Connector for Microsoft Outlook is an Outlook plug-in that must be installed on the end-user's desktop. Connector for Microsoft Outlook queries Messaging Server for folder hierarchies and email messages. It converts the information into Messaging API (MAPI) properties that Outlook can display. Similarly, it uses the WCAP protocol to query Calendar Server for events and tasks which are then converted into MAPI properties. With this model, Connector for Microsoft Outlook builds an end-user Outlook view from two separate information sources: mail from Messaging Server and calendar information from Calendar Server.

When users create and modify items through Outlook, Connector for Microsoft Outlook passes the new message along to the appropriate server depending on its message type. It sends new outgoing email to an SMTP mail server for delivery, and sends modified email messages back to the user's IMAP folder for storage. New calendar events and tasks are converted into a standard format to be stored in the Calendar Server database.

Connector for Microsoft Outlook Component Product Dependencies

To use Connector for Microsoft Outlook, both Messaging Server and Calendar Server are required in the same deployment. See those products' release notes for information on supported versions.

For Connector for Microsoft Outlook to function correctly, the following LDAP attributes in the Sun Java System Directory Server should be indexed for at least presence and equality to improve the overall performance:

See Chapter 7, Sun Java System Connector for Microsoft Outlook 7.2 Release Notes, in Sun Java Communications Suite 5 Release Notes for a complete list of product dependencies.

Migrating Sun ONE Calendar Server Data

If you are using a version of Calendar Server prior to Sun ONE Calendar Server 6.0, you need to engage Sun Client Services to convert and migrate the data to the new format. This Calendar Server data migration is required for the use of Outlook, and is necessary because of the underlying changes in the storage and management of recurring events. No migration service is required for new customers of Sun Java System Calendar Server.

Migrating Exchange Server Data

Connector for Microsoft Outlook does not convert Microsoft Exchange Server messages on the Exchange Server. You need to engage with Sun Client Services to convert the data.

Communications Express Considerations

Sun Java System Communications Express provides an integrated web-based communications and collaboration client. Communications Express is a common part of Messaging Server and Calendar Server, providing end users with a web interface to their calendar information and mail, as well as an address book.

Communications Express consists of three client modules: Calendar, Address Book, and Mail. The Calendar and Address Book client modules are deployed as a single application on a web container. Messenger Express is the standalone web-based mail application that uses the HTTP service of the Messaging Server. Messenger Express should be deployed on the same system as Communications Express.

Communications Express depends upon the following Sun Java System component products:

S/MIME Considerations

Communications Express Mail includes the security advantages of the Secure/Multipurpose Internet Mail Extension (S/MIME). Communications Express Mail users who are set up to use S/MIME can exchange signed or encrypted messages with other Communications Express Mail users, and with users of the Microsoft Outlook mail system.

See Requirements for Using S/MIME with Communications Express Mail in Sun Java Communications Suite 5 Installation Guide for more information.