| Oracle® Communications Calendar Server Installation and Configuration Guide Release 7.0.5 E54934-01 |
|
|
PDF · Mobi · ePub |
| Oracle® Communications Calendar Server Installation and Configuration Guide Release 7.0.5 E54934-01 |
|
|
PDF · Mobi · ePub |
This chapter describes how to configure multiple Oracle Communications Calendar Server back-end hosts. For conceptual information, see "Calendar Server Front-End and Back-End Components." For information on performing an initial installation of Calendar Server, including back-end hosts, see "Installing Calendar Server."
A standard Calendar Server installation consists of a default back-end database that contains user data, and an iSchedule back-end database for iScheduling requests. Over time, you might want to add additional back-end user data bases to your initial deployment.
In the case of multiple Calendar Server front ends, configure each to use the same initial default database back end and iSchedule back end. Then, you add additional back ends to each front end. Only one iSchedule back end is needed for all front ends to share.
Each back-end database, including the iSchedule database, must have its own document store. In the case of multiple front ends, all document stores must be available to all front ends. You cannot make all document stores local to a front end in a multiple front-end deployment.
The high-level steps to configure multiple back-end Calendar Server hosts include:
Installing, configuring, and preparing the new database
Gathering the database host names, ports, and other database names
Installing all front-end hosts, if not already done
Configuring all front-end servers by using the init-config script, if not already done
Running the init-config script creates the config-backend script for use in the next step. Information on any back-end host can be used for this step. If you have already run the init-config script, and you want to rename the default back-end host, see "Renaming the Default Calendar Server Back-End Host."
On each front-end host, running the config-backend script
On each front-end host, enabling connection pool validation
On each front-end host, restarting Oracle GlassFish Server
Skip Steps 2 and 3 if you are adding new back-end hosts to an existing front-end installation.
To install and configure multiple Calendar Server back-end hosts:
Install the database software on each back-end host. Choose one of the following:
Decide if you must create additional Oracle Database or MySQL Server back-end databases. If MySQL, continue with this step. If Oracle, skip to Step 3.
Note:
If the Calendar Server software is not installed on the back-end host, copy the config-mysql, config-oracle, and Util.pm scripts from an installed Calendar Server host and adjust the following path to those scripts accordingly.If this is first database on the host, set up the instance, and create the user and database by running the following command.
Calendar_Home/tools/unsupported/bin/config-mysql -s -u -c
If there is already a database on the host, just create the calendar database by running the following command.
Calendar_Home/tools/unsupported/bin/config-mysql -c
Skip to Step 3.
To create the Oracle database user and schema, see the following:
On each front-end host, run the config-backend script.
This script creates a JDBC connection pool and a JDBC resource on the GlassFish Server, and a davserver attributed back-end configuration.
CalendarServer_home/sbin/config-backend
If current deployment is using MySQL, you are prompted for the following information:
Remote database server host name Remote database server port Calendar db name on remote server Calendar db user name Calendar db user password Verifying the database input... Database input is verified Backend identifier for the remote db Document store directory (leave blank if store is remote) Document store host (leave blank if store is local) Document store port (leave blank if store local) Application Server admin user password
Make sure the value for Calendar db name on remote server is the one that you used for the config-mysql -c command.
If current deployment is using Oracle Database, you are prompted for the following information:
Remote database server host name Remote database server port Oracle database service name on remote server Calendar db user name Calendar db user password Verifying the database input... Database input is verified Backend identifier for the remote db Document store directory (leave blank if store is remote) Document store host (leave blank if store is local) Document store port (leave blank if store local) Application Server admin user password
Make sure the value for Calendar db user name is the one that you used for the config-oracle -c command.
Enter Y when prompted to perform the tasks for creating the JDBC connection pool and resource, and davserver back-end identifier.
The system responds that the database back-end configuration is configured successfully.
On each front-end host, enable Connection Validation for the connection pools (both CalDav back-end and iSchedule pools) so that Calendar Server automatically reconnects to the back-end database if it goes down:
In the GlassFish Server Administration Console, select Resources, then JDBC, then Connection Pools.
Select the pool.
Check the Required box for Connection Validation.
Select table for the Validation Method.
Enter DUAL for Table Name.
Click Save.
Click the Advanced tab.
Enter 60 for Validate Atmost Once.
Click Save.
This configuration then issues the command select count(*) from DUAL; on every connection, at most one time every 60 seconds. (If the connection is not being used, it is not checked.)
Note:
Use these settings as a starting point and adjust where necessary. For example, if validation is not important, you can turn it off. Additionally, you might want to adjust the "Validate At Most Once" time duration or validate each time a connection is requested (by setting the value to 0). HA deployments might also use different values.Restart GlassFish Server:
Provision accounts for a multiple back-end deployment.
See "Provisioning Calendar Accounts in a Multiple Back-End Deployment."
The Calendar Server init-config script creates the JDBC connection pool and resource, and adds the information to the davserver.properties file, for the one back-end host specified during the front-end configuration. The JDBC resource used is defaultbackend.
If you must change this JDBC resource, to match other naming conventions, follow these steps:
On each front-end GlassFish Server, create a JDBC resource associated with the caldavPool connection Pool.
For example, you might use db1 as the resource name.
Save this change then restart GlassFish Server.
Add the following two lines to each davserver.properties file.
store.dav.db1.backendid=JDBC resource store.dav.db1.jndiname=jdbc/JDBC resource
For example, if your resource name is db1, then you would add:
store.dav.db1.backendid=db1 store.dav.db1.jndiname=jdbc/db1
The new resource name can be used in davstore attribute values.
Note:
Once your Calendar Server deployment is up and running, do not change the user back-end ID as defined by the davStore attribute.For calendar accounts to know which back-end host they should connect to, you must provision accounts with the davstore attribute. The davStore attribute indicates the back-end host that stores a user's data if the deployment is configured for multiple back-end hosts. For more information, see the topic on Calendar Server and Directory Server integration in Calendar Server Concepts.
The following examples apply only to Calendar Server 7 and Calendar Server 7 Update 1. Starting with Calendar Server 7 Update 2, this process is automated by the config-backend script.
This section contains the following topics:
Using the GlassFish Server Administration Console to Create a Connection Pool
Using the Command Line to Create a Connection Pool for Non-Default Back-End Hosts
This example uses the GlassFish Server Administration Console to create a connection pool caldav1Pool and JDBC resource jbc/backend1, and to enable Connection Validation.
Select New and enter the following information.
Name: caldav1Pool
Resource Type: javax.sql.DataSource
Database Vendor: MySQL
Click Next.
Set the following properties and be sure that the URL property is either not set or set correctly.
You can also delete all the default properties and keep just the following six properties.
databaseName: caldav1
portNumber: 3306
networkProtocol: jdbc
serverName: localhost (or your MySQL server host name)
user: mysql
password: mysql
Click Save.
Select the pool and use the Ping button to test the pool.
If ping was not successful, you can delete all the default properties and keep just the six properties previously mentioned. Then retry the ping.
Create JDBC resource for the connection pool.
Select JDBC from Resources, then JDBC Resources.
Select New and enter the following information:
JDNI Name: jdbc/backend1
Pool Name: caldav1Pool
Status: check Enabled
Enable Connection Validation for the connection pool:
In the GlassFish Server Administration Console, select Resources, then JDBC, then Connection Pools.
Select caldav1Pool.
Check the Required box for Connection Validation.
Select table for the Validation Method.
Enter DUAL for Table Name.
Click Save.
Click the Advanced tab.
Enter 60 for Validate Atmost Once.
Click Save.
This example uses the command-line interface to create a connection pool caldav1Pool and JDBC resource jbc/backend1.
GlassFish_home/bin/asadmin create-jdbc-connection-pool --user admin --datasourceclassname com.mysql.jdbc.jdbc2.optional.MysqlDataSource --restype javax.sql.DataSource --property "DatabaseName=caldav1:serverName=mysqlhost:user=caldav:password=mysqlpass:portNumber=3306:networkProtocol=jdbc" caldav1Pool GlassFish_home/bin/asadmin create-jdbc-resource --user admin --connectionpoolid caldav1Pool jdbc/backend1
When you deploy Calendar Server in a multiple back-end host configuration, the information flow for a user login is as follows.
The user logs in to Calendar Server.
The user's davstore LDAP attribute is read, indicating the back-end database with which the user is associated.
The davstore attribute is mapped to one of the store.dav.xx.backendid values in the Calendar Server davserver.properties file.
The corresponding JNDI name (store.dav.xx.jndiname) is obtained.
This points to a JDBC Resource associated with the back-end database.
The JDBC Resource points one of the JDBC Connection pools.
The user gets a Calendar Server database connection.
For example, assume that user1 has a davstore attribute set to backend1. This would be mapped to the following backendid values:
store.dav.backend1.backendid=backend1 store.dav.backend1.jndiname=jdbc/backend1
The JNDI name would be obtained from:
store.dav.backend1.jndiname=jdbc/backend1
This, in turn, resolves to the following JDBC Resource:
Name=jdbc/backend1 ConnectionPool=caldav1Pool
Next, the following JDBC Connection pool is obtained:
ConnectionPool=caldav1Pool Name=caldav1Pool DB=jdbc:mysql://dbhost.example.com:3306/caldav1
Finally, user1 is given a connection to the back-end host with the caldav1 database.
|
 Copyright © 2015, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|