2 Planning Your Calendar Server Installation
This chapter provides information about planning your Oracle Communications Calendar Server installation. It also describes the Calendar Server logical and physical architectures.
About Calendar Server
Calendar Server is a high-performance, Internet standards-based calendar server that features calendaring, group scheduling, event-information sharing, task management, event and task search, and email invitations. Calendar Server supports the standard CalDAV access protocol, which makes it usable with Apple iCal, iPhone, Thunderbird Lightning, and any other CalDAV client.
Calendar Server Front-End and Back-End Components
Calendar Server consists of the following front-end and back-end components:
-
Stateless J2EE-based front end (provided by the application server)
-
SQL back end (can be either MySQL Server or Oracle Database), for calendar data and iSchedule data
-
Document store, for storing large data
You can locate these components on the same host or separate the components onto multiple hosts.
Figure 2-1 shows a Calendar Server configuration that uses one front-end host and one back-end host. In this figure, the back-end host contains both the calendar database and the iSchedule database. The document stores, one for each of the databases, are located on separate hosts.
Figure 2-1 Calendar Server Front-End and Back-End Configuration
Description of ''Figure 2-1 Calendar Server Front-End and Back-End Configuration''
In a multiple-host deployment, each front-end host has access to all the SQL back-end hosts. As a consequence, each front-end host has access to all Calendar Server end users' data.
Multiple front ends can be grouped together by using a simple load balancer. The load balancer must use IP-based stickiness as its load balancing method.
Mapping Calendar Users to Back-End Servers
In a multiple back-end host environment, when a user issues a Calendar Server request, the front-end host handling the request must determine on which back-end SQL host the targeted resource resides. Calendar Server makes this determination by using the "davstore" identifier (the actual LDAP attribute is davStore).
The mapping between Calendar Server front ends and back ends is indirect:
-
Each Calendar Server front-end instance is configured with a list of opaque back-end identifiers, called "davstore" identifiers. There is one "davstore" identifier per back-end SQL host database.
-
A Java Naming and Directory Interface (JNDI) name is associated to each "davstore" identifier (it is also in the Calendar Server configuration), for example: jdbc/davstore_id.
-
The application server that hosts the Calendar Server is configured with corresponding JNDI resources containing the actual back-end information such as server names, ports, database names, credentials, and so on.
-
At startup, Calendar Server performs a JNDI lookup for each "davstore" identifier value in its configuration.
davStore LDAP Attribute
You can add the davStore LDAP attribute to users' and resources' object classes to associate those users and resources with a particular back-end Calendar Server store. The value of the davStore attribute is equal to one of the davstore IDs defined in the server configuration. The davStore LDAP attribute is single valued. When not present, a server configurable default davstore ID is used.
Users have only one davStore LDAP attribute for all types of data. In the single user repository model, all data for users with the same davStore value is hosted on the same back-end repository. This does not prevent a deployment from using different repositories for the different types of data.
Planning Your Calendar Server Installation
This section contains the following planning topics you must consider before installing Calendar Server:
Using a Single Web Container for Multiple Applications
You use the application server as a web container for Calendar Server. For production deployments, deploy Calendar Server to the root context (/) to simplify configuring mobile clients. The URI syntax is:
http://calendar_server_host_name:port/calendar_server_webapp/dav/principals/email-address/
For example:
http://example.com:3080/davserver/dav/principals/jsmith@example.com/
You can deploy Calendar Server with other applications in the same GlassFish Server web container. In this case, you deploy Calendar Server in its own context, for example, /davserver, and not the root context (/) of the GlassFish instance.
If you use Oracle WebLogic Server as a web container, ensure to use a separate Managed Server for deploying Calendar Server.
Regardless of whether you use a single web container for multiple applications or put Calendar Server in its own web container, for production environments, deploy Calendar Server under the root (/) URI context.
Deciding on the Database
You can use either MySQL Server or Oracle Database as the Calendar Server database to store calendar and iSchedule information. You cannot mix database types in a deployment.
Caution:
You can view contents of the database by using standard SQL tools. However, do not use SQL tools to modify your data. This applies to both MySQL Server and Oracle Database.Planning the iSchedule Database
The iSchedule database is used to manage external calendar invitations.
The established standard for scheduling between two separate calendar servers is still only through iCalendar Message-Based Interoperability Protocol (iMIP), which sends calendar data over email. Previously, end users had to manually import such invitations and responses that arrived in email into their calendars. Starting with Oracle Communications Messaging Server 7 Update 5, you can use an iSchedule channel that interprets such mail messages and posts them to Calendar Server directly. Thus, external invitations and responses get into users' calendars without any user intervention. See the topic about using the iSchedule channel to handle iMIP messages in Messaging Server Administration Guide for instructions on how to set up Messaging Server. No special setup is required for Calendar Server.
Planning the Document Store
The Calendar Server document store is used to store and retrieve large data, such as calendar events with many invitees, and todos with large attachments. You must set up one document store per configured Calendar Server back-end database. That is, every logically configured database must have its own unique document store to manage its large data. You must configure a document store even if you decide to not use its capability.
The document store can be either local or remote, or, if you use Oracle Database, within the database itself. When the document store is local, it runs as part of a Calendar Server instantiation. For example, the local document store could be part of a Calendar Server front-end installation or part of a single host installation providing both front-end and back-end functionality. When the document store is local, Calendar Server accesses the file systems directly. You can only use a local document store in a single front-end deployment, as all front-end hosts need to be able to access the data. When the document store is remote, Calendar Server accesses the documents by using either HTTP or HTTPS. If you use Oracle Database, you can configure it to contain both the calendar data and the data that otherwise would need to be stored in the separate document store. That is, you would use a single, large Oracle database for both calendar data and the document store.
Note:
You cannot configure MySQL database to contain both contact data and document store data.In a multi-host deployment with multiple front-end hosts, you must ensure that each front-end host that accesses a back-end database must also have access to the back-end database's related document store.
The default directory for the document store is /var/opt/sun/comms/davserver/db. You can configure this by changing the store.dav.*.dbdir parameter. If at some point you move the document store, you must migrate the data.
Planning for Multiple Calendar Server Hosts
Using multiple Calendar Server hosts can help you:
-
Avoid network latency and unnecessary bandwidth consumption by positioning the server closer to the client (that is, in a geographically distributed environment).
-
Scale your deployment by distributing end users onto different machines, thus avoiding possible bottlenecks in terms of I/O, memory, CPU, and backup time. A very large deployment can also be geographically distributed.
Note:
The Calendar Server default installation and configuration supports only one front-end/back-end deployment. You must perform some additional steps to set up the multiple-server scenario. See "Configuring Calendar Server with Multiple Hosts" for more information.Planning for Virus Scanning
Calendar Server supports virus scanning of attachments, such as documents. If you choose to configure virus scanning, decide whether to use an existing Messaging Server MTA, or to deploy a dedicated MTA-only Messaging Server installation to scan for viruses. To use virus scanning for Calendar Server, you must deploy at least Messaging Server 7.4 patch 23. For more information, see the topic on configuring virus scanning in Calendar Server System Administrator's Guide.
Planning to Use an External Directory for Authentication
You can configure your deployment to authenticate against a separate, external LDAP directory while keeping user LDAP information internal and private. Such a configuration is useful in hosted environments for delegating one administrative aspect to a provider (managing the Calendar Server front- and back-end hosts) while maintaining control over the LDAP user passwords in the internal, corporate network. For more conceptual information on Calendar Server and external authentication, see Calendar Server Concepts. For instructions on how to configure external authentication, see to the topic on configuring external authentication in Calendar Server System Administrator's Guide.
Planning for the Unique Identifier
Calendar Server requires a unique identifier in the form of an LDAP attribute whose value is used to map each user account (in the LDAP Directory Server) to a unique account in the calendar database (the MySQL Server or Oracle Database) that stores the Calendar Server data. The unique identifier links various entries from different database tables for a user. You must use a unique identifier, and one that does not change, for each user entry stored in LDAP.
Before installing Calendar Server, decide on the LDAP attribute to be used as the unique identifier. This is a critical decision. It is very difficult to change the attribute you use as the unique identifier once you deploy Calendar Server and start using it. Calendar Server provides the davuniqueid attribute, which is the recommended attribute to use. For more information on this attribute, see Communications Suite Schema Reference.
How Do You Set the Unique Identifier?
You set the attribute to be used as the unique identifier during the Calendar Server initial configuration phase. (When installing a Communications Suite component such as Calendar Server, you first install the software and then configure it. These are two separate steps.) The Calendar Server configurator script, init-config, prompts you to enter the attribute you have chosen as your unique identifier. The configurator then stores the value to the Calendar Server davcore.uriinfo.permanentuniqueid configuration parameter.
In the initial release of Calendar Server 7, the LDAP operational attribute nsUniqueId was chosen as the default value used for the unique identifier. However, it was discovered that this choice has a potential serious downside. The problem with using nsUniqueId is that if the LDAP entry for a user, group, or resource is deleted and recreated in LDAP, the new entry would receive a different nsUniqueId value from the Directory Server, causing a disconnect from the existing account in the calendar database. As a result, recreated users cannot access their existing calendars. See "Changing the User Unique Identifier" for more information.
To prevent this potentially serious issue, Calendar Server 7 Update 3 introduced a new attribute, davUniqueId, in the davEntity object class, to use as the unique identifier. You should provision this attribute for your users, groups, and resources LDAP entries with globally unique IDs. To use Delegated Administrator as your provisioning tool, ensure that you are running at least Delegated Administrator 7 Patch 6, which supports provisioning the davUniqueId attribute.
In the Calendar Server data base, the unique identifier value is case sensitive. If you must move or recreate the corresponding LDAP entry, make sure to retain the case of the value as is. However, because the value is considered as case insensitive for LDAP comparisons, do not create a unique identifier value for another user or resource entry by just changing the case of the value.
Setting the Unique Identifier During Calendar Server Installation
For a fresh Calendar Server installation use these steps to set the unique identifier:
-
During initial configuration, when prompted by the Calendar Server init-config configurator, choose the default value, davUniqueId.
This is stored to the davcore.uriinfo.permanentuniqueid configuration parameter. For more information, see the topic on davUniqueId in Communications Suite Schema Reference.
-
In LDAP, populate calendar users, groups, and resources with the davUniqueId attribute.
You can:
-
Use the populate-davuniqueid tool.
-
Use your own LDAP tools.
-
Changing the Unique Identifier During Calendar Server Upgrade
If you initially deployed Calendar Server 7 Update 2 to use the nsUniqueId attribute as your unique identifier, you should switch to using the davUniqueId attribute, new in Calendar Server 7 Update 3. For more information on the problems with using nsUniqueId, see "Changing the User Unique Identifier".
To upgrade and change to using the davUniqueId attribute, see "Upgrading Calendar Server".
System Deployment Planning
This section contains the following system-level planning topics you must consider before installing Calendar Server:
Planning for High Availability
You can configure Calendar Server front-end and back-end hosts to be highly available. For high availability of Calendar front-end hosts, deploy the hosts behind a load balancer. See "Using Load Balancing" for more information. Choices for making the Calendar Server back-end database highly available include MySQL asynchronous replication and Oracle Data Guard. Refer to the documentation for those products for installation and configuration instructions. You can also configure the document store for high availability. See "Configuring the Document Store for High Availability" for more information.
Using Load Balancing
When you deploy multiple Calendar Server front-end hosts, a load balancer (with IP-based stickiness) is necessary to distribute the load across the front-end hosts.
Planning Backup Strategies
Backing up and restoring data is one of the most important administrative tasks for your Calendar Server deployment. You must implement a backup and restore policy for your Calendar Server database to ensure that data is not lost if the system crashes, hardware fails, or information is accidentally deleted.
The two ways to back up Calendar Server data are:
-
davadmin db backup command
-
Oracle Solaris ZFS snapshots
For more information, see Calendar Server System Administrator's Guide.
Calendar Server Logical Architecture
When planning your Calendar Server logical architecture, you can use the following options:
-
Single-tiered Calendar Server architecture: You can deploy all components on a single host.
-
Two-tiered Calendar Server architecture: You can deploy Calendar Server with the front-end component installed on a separate host and the database back end installed on another host.
-
Two-tiered, multiple server Calendar Server architecture: You can install multiple front-end hosts and multiple back-end database hosts. You can also install the document store onto a separate remote host.
Sample Calendar Server Physical Architecture
Figure 2-2 shows a sample Calendar Server deployment consisting of three front-end hosts, two back-end hosts, and a load balancer to handle client requests.
Figure 2-2 Calendar Server Physical Architecture
Description of ''Figure 2-2 Calendar Server Physical Architecture''
About Installing a Secure System
You can configure Secure Sockets Layer (SSL) between the Calendar Server GlassFish Server front-end hosts and database back-end hosts. You can also configure SSL between the Calendar Server GlassFish Server front-end hosts and the remote document stores.
When configuring SSL between the front-end and back-end hosts, you first enable the back-end database hosts for SSL by configuring either the required trustStore files or wallets. Then you configure the Calendar Server front-end hosts to connect over SSL by making use of the stored certificates.
For information about secure installation and configuration of Calendar Server, see Calendar Server Security Guide.
If you use Oracle WebLogic Server, see the discussion about performing a secure Calendar Server installation chapter in Calendar Server Security Guide.