Sun Java System Calendar Server 6 2004Q2 Deployment Planning Guide |
Chapter 4
Planning Your Calendar Server ConfigurationThis 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 ConsiderationsCalendar 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 alarms.
- Distributed Database Service (csdwpd) links multiple database servers together within the same Calendar Server system to form a distributed calendar store.
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.
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:
Single-Server Minimal ConfigurationIn 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
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:
- Single Sign-on (SSO). You can implement SSO for Sun Java Enterprise System servers, including Calendar Server and Messaging Server, using Identity Server, or through trusted circle technology. Identity Server serves as the SSO gateway for the Sun Java Enterprise System servers. Users log in to Identity Server and then can access other the servers, as long as all servers are configured properly for SSO.
- Sun Java System LDAP Schema 2. Identity Server (release 2003Q4 or later) is required if you want to use this version of the schema.
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 ConfigurationCalendar 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
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 ConfigurationIn 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
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: