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 Services architecture.
This chapter contains the following sections:
When designing your Communications Services 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 Services with other Java System products, you need to choose your schema accordingly. Inter-product dependencies, for example, how Communications Services access and place 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:
LDAP Directory Information Tree
Schema
Directory Server (Access Manager)
Messaging Server
Message Transfer Agent (MTA)
Message Store
Messaging Multiplexor (MMP)
Messaging Express Multiplexor (MEM)
Calendar Server
Front End
Calendar Store
Instant Messaging
Instant Messaging Proxy
Instant Messaging Back End
Portal Server
Connector for Microsoft Outlook
Communications Express
When planning a Communications Services 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.
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, MTA, and MEM); Calendar Server; Communications Express (which must be collocated with MEM); 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.
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.
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.
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.
The main advantages to using the one-tree structure Schema 2 native mode are:
The structure is integrated with Access Manager.
The structure is more closely aligned with industry standards.
The structure is significantly less complex than the two-tree structure.
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.
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).
By contrast, a one-tree structure contains only an Organization Tree, as shown in the following figure.
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.
Before you install any of the Communications Services 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 JavaTM System LDAP Schema 1 and Sun JavaTM System LDAP Schema 2, are available and supported with Communications Services. Your choice of schema depends on the following criteria:
Want to use Access Manager 6 2005Q4 (formerly Identity Server), either for user provisioning or single sign-on (SSO)
Are installing Communications Services components for the first time
Are integrating Communications Services with other Java Enterprise System products, such as Portal Server
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.
Have an existing version of any of the Communications Services components, for example, if you are upgrading from Messaging Server 5.2
Do not need to provision users through Access Manager (unless Access Manager SSO is also a requirement)
Want to use Sun ONE Delegated Administrator (formerly called iPlanetTM Delegated Administrator) to do your user provisioning
See Chapter 8, Understanding Schema and Provisioning Options for more information on schema choices.
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:
Directory schema and object class definitions
Groups and membership definitions
A strategy for Access Control Lists (ACLs) including static and dynamic groups
Directory architecture for high availability and performance, including failover, replication, and referrals
Management of the directory
See the Sun Java System Directory Server 5 2005Q1 Administration Guide for a complete description of these factors and suggestions about how to architect your data environment.
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 Services Logical Architecture for more information on tiered architectures.
You can install Directory Server in such a way to have a clear separation between the directory user management and the software application configuration. In this architecture, there are two directories: a user/group directory on a directory host, and a configuration directory on a separate host. Should you want to remove the software application configuration piece, this separation provides a cleaner way of removing that information from Directory Server.
Though it is feasible to build a deployment around an instance of Directory Server installed on a single machine, the other Communications Services 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.
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:
Hit load
Cache load
Requests per second
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.
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.
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.
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.
In developing your Communications Services architecture, you need to evaluate the performance aspects of the following Messaging Server components:
Message Store
Message Transfer Agent (MTA)
Mail Message Proxy (MMP)
Messaging Express Multiplexor (MEM)
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 consists of five major services:
HTTP Service (cshttpd) listens for HTTP requests. It receives user requests and returns data to the caller.
Administration Service (csadmind) is required for each instance of Calendar Server. It provides a single point of authentication and administration for the Calendar Servers and provides most of the administration tools.
Notification Service (csnotify) sends notifications of events and to-dos using either email or the Event Notification Service.
Event Notification Service (enpd) acts as the broker for event and alarm notifications.
Distributed Database Service (csdwpd) links multiple database servers together within the same Calendar Server system to form a distributed calendar store.
Backup Service (csstored) implements automatic backups, both archival backups and hot backups. The first backup is a snapshot with log files, the second is a snapshot with log files applied. This service is automatically started when you run the start-cal command. However, it is not enabled at installation time, so you must configure it to function. If left unconfigured, Backup Service sends out a message to the administrator every 24 hours, with the notification that the service is not configured.
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.
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.
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.
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.
In a configuration with both front-end and back-end Calendar Server hosts, all hosts must be running:
The same operating system
The same releases of Calendar Server, including patch or hotfix releases
As with other Communications Services 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.
You can install Communications Services 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 6 2005Q4 Deployment Planning Guide and the Sun Java System Access Manager 7 2005Q4 Deployment Planning Guide for more information.
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.1
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.
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:
icsCalendar
mailalternateaddress
See Chapter 6, Sun Java System Connector for Microsoft Outlook 7 2005Q4 Release Notes, in Sun Java System Communications Services 2005Q4 Release Notes for a complete list of product dependencies.
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.
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.
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:
Directory Server
Access Manager (If you are using Sun Java System LDAP Schema Version 2)
Calendar Server
Messaging Server
Web Server/Application Server (for web container)
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 for more information.