Sun Java logo     Previous      Contents      Index      Next     

Sun logo
Sun Java System Calendar Server 6 2004Q2 Deployment Planning Guide 

Chapter 4
Planning Your Calendar Server Configuration

This chapter describes the three basic Calendar Server configurations, which can vary depending on your site’s specific requirements.

This chapter contains the following sections:


Calendar Server Considerations

Calendar Server consists of five major services:

In a scalable Calendar Server deployment, you deploy an instance of HTTP Service and Administration Service together as a Calendar front-end system. (You would deploy one instance of the cshttpd per machine. On each machine, you would configure one cshttpd process per CPU on that machine.) An instance of Notification Service, Event Notification Service, Distributed Database Service and Administration Service are deployed together as the Calendar back-end system.

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.

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.

You will want to consider early on in a deployment separating 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. This suggests care should be taken in accounting for peak calendar usage and choosing 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. 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 SPARC or Intel server. You would deploy one instance of the Calendar Server cshttpd process per machine. 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.

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 Calender Server hosts, all hosts must be running:

  • The same operating system
  • The same releases of Calendar Server, including patch or hotfix releases.


Single-Server Minimal Configuration

In a single-server minimal configuration (shown in Figure 4-1), all Calendar Server services (processes) run on the same server, either in the same CPU (processor) or across multiple CPUs. The directory server and Sun Java System Identity Server processes can run on the same server or on different servers.

Figure 4-1  Single-Server Minimal Calendar Server Configuration

Minimal Calendar Server configuration

A Calendar Server instance on a single server includes the following services:

For a description of Calendar Server services, see the Sun Java System Calendar Server Administration Guide.

The Database Wire Protocol (DWP) service (csdwpd process), which provides networking capability when the calendar database is on another server, is not required for a minimal configuration because the database is on the same server.

Calendar Server requires a directory server to authenticate users and to store user preferences. Usually, the directory server is an LDAP directory server, such as Sun Java System Directory Server. However, if you prefer, you can use the Calendar Server API (CSAPI) to write a plug-in to use a non-LDAP directory server. This API is described in the Sun Java System Calendar Server Developer’s Guide.

The directory server can run on the same server where Calendar Server is running or on a remote server.

Sun Java System Identity Server (release 2003Q4 (6.1) or later) provides the following functionality:

For more information on the above topics, see the Sun Java System Calendar Server Administration Guide.

Identity Server can run on the same server where Calendar Server is running or on a remote server.

End users connect to Calendar Server from client machines by using one of the two Web user interfaces (UIs), that is, either Sun Java System Calendar Express, or Sun Java System Communications Express. For information on either user interface, refer to the respective interface’s online Help. Also, see the Sun Java System Communications Express Administration Guide:


Network Front-end/Database Back-end Server Configuration

Calendar Server supports scalability by distributing a configuration over multiple front-end and back-end servers. On each server, Calendar Server services (processes or daemons) can also be distributed across multiple CPUs (or processors).

In network front-end/database back-end configuration (shown in Figure 4-2), users log in to a front-end server and connect to a back-end server using the Database Wire Protocol (DWP) service (csdwpd process). The calendar database is connected only to the back-end servers.

Figure 4-2  Network Front-end/Database Back-end Server Configuration

Scalable Calendar Server configuration

Calendar Server processes run on both the front-end and back-end servers as follows:

In this configuration, users do not log in to the back-end servers, so the HTTP service (cshttpd process) is not required.

For a description of Calendar Server services, see the Sun Java System Calendar Server Administration Guide.

A scalable Calendar Server configuration requires a directory server to authenticate users and to store user preferences.

You can use Identity Server (release 6.1 (release 6 2003Q4) or later) to implement Single Sign-on (SSO), to use Sun Java Enterprise System LDAP Schema 2, or to provision and manage hosted (virtual) domains, users, groups, organizations, resources, and roles.

End users connect to Calendar Server from client machines by using one of the two Web user interfaces (UIs), that is, either Sun Java System Calendar Express, or Sun Java System Communications Express. For information on either user interface, refer to the respective interface’s online Help. Also, see the Sun Java System Communications Express Administration Guide:


Multiple Front-end/Back-end Server Configuration

In a multiple front-end/back-end server configuration (shown in Figure 4-3), users log in to a specific server, and each server is connected to a calendar database. This configuration allows calendars to be geographically distributed, with each calendar residing on the server where its owner logs in to Calendar Server.

Figure 4-3  Multiple Front-end/Back-end Server Configuration

Calendar Server Configuration for Multiple Front-End/Back-End Servers

Each front end and back end requires all Calendar Server services: Administration Service (csadmind process), HTTP Service (cshttpd process), Event Notification Service (enpd and csnotifyd processes), and Database Wire Protocol (DWP) Service (csdwpd process).

For a description of Calendar Server services, see the Sun Java System Calendar Server Administration Guide.

A multiple front-end/back-end server configuration requires a directory server to authenticate users and to store user preferences.

You can use Identity Server (release 6.1 (release 6 2003Q4) or later) to implement Single Sign-on (SSO), to use Sun Java Enterprise System LDAP Schema 2, or to provision and manage hosted (virtual) domains, users, groups, organizations, resources, and roles.

End users connect to Calendar Server from client machines by using one of the two Web user interfaces (UIs), that is, either Sun Java System Calendar Express, or Sun Java System Communications Express. For information on either user interface, refer to the respective interface’s online Help. Also, see the Sun Java System Communications Express Administration Guide:



Previous      Contents      Index      Next     


Copyright 2004 Sun Microsystems, Inc. All rights reserved.