Oracle® Communications Calendar Server Installation and Configuration Guide Release 7.0.5 E54934-01 |
|
|
PDF · Mobi · ePub |
This chapter provides information about planning your Oracle Communications Calendar Server installation. It also describes the Calendar Server logical and physical architectures.
Calendar Server (also referred to as Calendar Server 7 and formerly known as Oracle Communications Calendar Server for CALDAV Clients and Sun Java System 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 consists of the following front-end and back-end components:
Stateless J2EE-based front end (provided by Oracle GlassFish Server)
SQL back end (can be either MySQL Server or Oracle Database)
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 SQL database and the document store. The document store can be located on a separate host if desired.
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, either by using a simple load balancer or by using the GlassFish Server cluster functionality.
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 GlassFish Server's web container hosting the server is configured with corresponding JNDI resources containing the actual back-end information (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.
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.
This section contains the following planning topics you must consider before installing Calendar Server:
Calendar Server requires that you use GlassFish Server as its web container. 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.
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.
You can use either MySQL Server or Oracle Database as the Calendar Server database to store contact 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.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.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.
The iSchedule database is used to manage external calendar invitations. You must set up one iSchedule database per configured Calendar Server back-end database. That is, every logically configured database must have its own unique iSchedule database.
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.
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.
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.
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.
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.
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.
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."
This section contains the following system-level planning topics you must consider before installing Calendar Server:
You can configure Calendar Server to be highly available. Choices for making Calendar Server highly available include GlassFish Server high availability features, 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.
When you deploy multiple Calendar Server front-end hosts, a load balancer (with persistent connections) is necessary to distribute the load across the front-end hosts. Multiple front-end hosts can be grouped together, either by using a simple load balancer or by using the GlassFish Server cluster functionality.
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.
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.
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
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.