Chapter 16 Developing a Calendar Server Architecture
This chapter describes three basic Calendar Server deployment architectures, which can vary depending on your site’s specific requirements.
This chapter contains the following sections:
Single-Server Calendar Server Architecture
Figure 16–1 shows a single-server architecture. In this deployment, all Calendar Server services (processes) run on the same server, either in the same CPU (processor) or across multiple CPUs. The Directory Server and Access Manager processes can run on the same server or on different servers.
Figure 16–1 Single-Server Calendar Server Architecture
A Calendar Server instance on a single server includes the following services:
-
Administration service (csadmind process) provides support for administration functions such as commands to start or stop Calendar Server, create or delete calendar users or resources, or fetch and store calendars.
-
HTTP service (cshttpd process) handles WCAP requests.
-
Event Notification Service (enpd) acts as the broker for event and alarm notifications.
-
Backup service (csstored) implements automatic backups, both archival backups and hot backups.
For a description of Calendar Server services, see the Sun Java System Calendar Server 6.3 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 plugin to use a non-LDAP directory server. This API is described in the Sun Java System Calendar Server 6.3 WCAP Developer’s Guide.
The directory server can run on the same server where Calendar Server is running or on a remote server.
The tool Calendar Server uses for administration of users, groups, resources, domains, and roles for Schema 2 deployments is Delegated Administrator, which must be installed and configured separately. The Delegated Administrator has both a graphical user interface console, and a command line utility (commadmin). For information about the Delegated Administrator utility, see the Sun Java System Delegated Administrator 6.4 Administration Guide.
For Schema 1 deployments, Calendar Server has its own bundled set of utilities for administration.
You can implement SSO for Communications Suite products using Access Manager, or using trusted circle technology among the Communications Suite products. Users log in to Access Manager and then can access other the servers, as long as all servers are configured properly for SSO. For the trusted circle technology, a user logging into Messaging Server would also have access to Calendar Server and Instant Messaging without having to login again. For more information on SSO trusted circle implementation, see the Sun Java System Calendar Server 6.3 Administration Guide.
Two-tiered Calendar Server Architecture
Calendar Server supports scalability by distributing a configuration over multiple front-end and back-end servers. On each server, Calendar Server services can also be distributed across multiple CPUs.
In a two-tiered architecture, sometimes referred to as network front-end/database back-end configuration (shown in the following figure), 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. Though not shown in this figure, the front-end hosts need access to the LDAP directory.
Figure 16–2 Two-tiered Calendar Server Architecture
Calendar Server processes run on both the front-end and back-end servers as follows:
-
Users are directed by load balancers to a front-end server, where they log in. Each front-end server requires these services:
-
Administration Service (csadmind process)
-
HTTP Service (cshttpd process)
-
GSE database (csstored)
-
-
Each back-end server is connected to a calendar database, so each back-end server requires these services:
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 6.3 Administration Guide.
A scalable Calendar Server configuration requires a directory server to authenticate users and to store user preferences.
Two-tiered, Multiple Server Calendar Server Architecture
In a two-tiered Calendar Server architecture with multiple front-end and back-end servers (shown in Figure 16–3), users log in to a specific server, and each server is connected to a calendar database. This configuration enables calendars to be geographically distributed, with each calendar residing on the server where its owner logs in to Calendar Server.
Figure 16–3 Two-tiered, Multiple Server Calendar Server Architecture
In this architecture, each server functions as both a front end and back end, and requires all Calendar Server services: Administration Service (csadmind process), HTTP Service (cshttpd process), Event Notification Service (enpd and csnotifyd processes), Database Wire Protocol (DWP) Service (csdwpd process), and Backup Service (csstored).
For a description of Calendar Server services, see the Sun Java System Calendar Server 6.3 Administration Guide.
Note –
In this architecture, you could also separate the front end services from the back end services onto separate machines, and use the LDAP Calendar Lookup Database (CLD) to determine which back end a front end needs to get data from. For more information, see the Sun Java System Calendar Server 6.3 Administration Guide.
A multiple front-end/back-end server deployment requires a directory server to authenticate users and to store user preferences.
- © 2010, Oracle Corporation and/or its affiliates