Planning for Calendar Server Front-end and Back-end Services

Calendar Server consists of six 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 todos 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.

• 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.

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. The calendar databases can be distributed over one or more back-end machines. These back-end machines can be associated with one front-end machine.

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 the number of CPUs as the front-ends.

You will want to consider early on in a deployment separating the Calendar Service into front-end and back-end services. Assign a separate host name for the front-end services and back-end services so that when it comes time to separate the functionality onto different hosts, the changes are essentially internal and do not require users to change their methods of operation.

The Calendar Server HTTP process that is typically a component of the front-end services is a dominant user of CPU time. Account for peak calendar usage to provide enough 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. Communications Express deployments with Calendar Server have different characteristics. See the Communications Express documentation for more information.

The only configuration for Calendar front ends that might warrant a true HA solution is one where the Calendar front end is deployed on the same host that contains a Messaging Server MTA. 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. In this case, you deploy one instance of the Calendar Server cshttpd daemon 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.

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, deploy the Calendar Server back end with Sun Cluster, as the back end contains persistent data.

In a configuration with both front-end and back-end Calender Server hosts, all hosts must be running the same releases of Calendar Server, including patch or hotfix releases.