Sun Java logo     Previous      Contents      Index      Next     

Sun logo
Sun Java System Calendar Server 6 2005Q1 Administration Guide 

Chapter 6
Configuring Calendar Database Distribution Across Multiple Machines

This chapter describes how to use the Calendar Lookup Database (CLD) plug-in to enable the calendar database to be distributed over multiple back-end servers.

Note

For Calendar Server installations that separate functionality across front-end and back-end machines, the hardware platforms must be the same on each end.

More specifically, due to big-endian versus small-endian incompatibility, you can’t use both an x86 platform machine and a Sparc platform machine in the same Calendar Server deployment containing front-end and back-end machines.

This chapter contains the following topics:

For information on how to improve the performance of the CLD plug-in, see Chapter 21, "Tuning Calender Server Performance".

CLD Plug -in Overview

The Calendar Lookup Database (CLD) plug-in provides horizontal scalability of the calendar database by allowing user and resource calendars to be distributed over a number of back-end servers for a single calendar instance. When the calendar database is distributed over several back-end servers, Calendar Server uses the CLD plug-in to determine the actual server where a calendar is stored.

Calendar Server accesses the calendar data on the back-end server using the Database Wire Protocol (DWP). DWP is an internal protocol that runs as the csdwpd service and provides the networking capability for the calendar database.

How the CLD Plug-in Works

Calendar Server accesses calendar data on a back-end server as follows:

  1. When an end user accesses a calendar through Communications Express (or Calendar Express), the CLD plug-in extracts the userid from the calendar’s calid and then looks up the calendar owner in the LDAP directory database, or the CLD data cache (if enabled). For information and instructions on enabling the CLD data cache, see Enabling the CLD Plug-in.
  2. After finding the calendar owner, the plug-in uses the value in the icsDWPHost LDAP attribute to determine the host name of the back-end server where the calendar resides. This host name must be resolvable by your Domain Name Service (DNS) into a valid IP address.
  3. Using the host name, Calendar Server accesses the calendar data on the back-end server using the Database Wire Protocol (DWP).
  4. Using DWP, Calendar Server sends the calendar data to the server where the user is logged in, so it can be rendered in one of the user interfaces.

    5. Note

    If your site is using the CLD plug-in, all calendars created for the same user must reside on the same back-end server, as indicated by the LDAP user entry’s icsDWPHost LDAP attribute. If you try to create a calendar on a different back-end server, Calendar Server returns an error.

Configurations Supported by the CLD Plug-in

The CLD plug-in supports the following Calendar Server configurations:

Multiple Front-End Servers with Multiple Back-End Servers

Figure 6-1 shows two front-end servers and two back-end servers running a single Calendar Server instance. You can also configure more than two front-end or back-end servers, if you wish.

This configuration allows the servers to be protected by a firewall to restrict access to the LDAP and calendar databases. The calendar database is distributed across the two back-end servers.

The front-end servers are CPU intensive, with most CPU time spent rendering calendar data for end-users. The back-end servers are disk intensive, with most CPU time spent accessing the calendar database.

For configuration instructions, see Configuring the Servers for CLD and DWP.

Figure 6-1  Multiple Front-End Servers with Multiple Back-End Servers

Calendar Server Configuration for Multiple Front-End Servers with Multiple Back-End Servers

Multiple Machines Functioning as Both Front-end and Back-end Servers

Figure 6-2 shows three machines functioning as both front-end and back-end servers. Each machine is connected to a calendar database. This configuration allows calendars to be geographically distributed. Calendar owners (end users) log into the machine where their calendars reside. For configuration instructions, see To Configure Both Front-End and a Back-End Servers on the Same Machine.

Figure 6-2  Multiple Front-End/Back-End Servers

Calendar Server Configuration for Multiple Front-End/Back-End Servers

Enabling the CLD Plug-in

There are several ics.conf parameters that need to be set on every front-end server in order for the CLD plug-in to be activated and used:

For information on how plug-ins work in Calendar Server, see Chapter 1, “Calendar Server API (CSAPI) Overview” in the Sun Java System Calendar Server 6 2005Q1 Developer’s Guide.

Note

In Calendar Server 5.1.1 and later releases, the CLD plug-in major version number changed from 1 to 2. The minor version number is still 0. If you have written your own CLD plug-in, you must make sure your plug-in’s version number is 2.0 or higher.

csapi.plugin.loadall

This parameter, when set to “y”, tells the system to load all shared objects in the cal_svr_base/SUNWics5/cal/bin/plugins directory that start with the prefix cs_. If set to “n”, then you must specifically tell it which plug-ins to load, using the next two parameters (csapi.plugin.calendarlookup, and csapi.plugin.calendarlookup.name).

For example, if you only want specific plug-ins loaded, for every front-end server set the parameter in the ics.conf file to the following:

csapi.plugin.loadall = "n"

csapi.plugin.calendarlookup

This parameter, when set to “y”, tells the system that there is a specific plug-in to be loaded. You can tell the system not to load this plug-in by setting it to “n”.

For example, if you have set the csapi.plugin.loadall to “n” and you want to load the calendarlookup plug-in, then set it as follows:

csapi.plugin.calendarlookup = "y"

This parameter is used in conjunction with the csapi.plugin.calendarlookup.name parameter that follows.

csapi.plugin.calendarlookup.name

If you want to load the calendarlookup plug-in, you must specify this parameter as follows:

csapi.plugin.calendarlookup.name = "calendarlookup"

This parameter is used in conjunction with the csapi.plugin.calendarplugin parameter.

For more information about how the plug-ins work, see the Sun Java System Calendar Server Developer’s Guide at:

http://docs.sun.com/db/coll/CalendarServer_05q1

caldb.cld.type

The system decides whether or not to load the CLD plug-in based on the value of the caldb.cld.type parameter in the ics.conf file. The two expected values are as follows:

For example, to tell the calendar system to load the CLD plug-in, on every front-end server, set the ics.conf parameter as follows:

caldb.cld.type=”directory”

Configuring the Servers for CLD and DWP

This sections contains instructions for configuring servers and contains the following topics:

To Configure a Front-End Server for CLD and DWP

On each front-end server, set the following ics.conf parameters:

  1. Enable the DWP service (csdwpd):

    2. service.dwp.enable=”yes”

  2. Set the CLD type:

    3. caldb.cld.type=”directory”

  3. Set the port number for the DWP service (csdwpd):

    4. service.dwp.port = "59779"

    The default is “59779”. The port number must be the same for all configured front-end and back-end servers.

  4. Set the server name for each back-end server in the configuration:

    5. caldb.dwp.server.backend-server-1.ip = "backend-server-1"
    caldb.dwp.server.backend-server-2.ip = "    backend-server-2"
    ...
    caldb.dwp.server.backend-server-n.ip =     "backend-server-n"

    The server name must be fully qualified and be resolvable by your Domain Name Service (DNS) into a valid IP address. In each part of the parameter, the server name must be identical and fully qualified. For example:

    caldb.dwp.server.calendar.sesta.com.ip = "calendar.sesta.com"

    The server name must also match the name used for the icsDWPHost LDAP attribute for the applicable calendar owners.

  5. Set the default DWP server name:

    6. caldb.dwp.server.default = "server-name"

    where server-name is the fully qualified default server name used by Calendar Server if the user or resource entry in the LDAP server database does not have an icsDWPHost attribute. This name must be resolvable by your Domain Name Service (DNS) into a valid IP address. For example:

    caldb.dwp.server.default = "calendar.sesta.com"

  6. Set the LDAP host for authentication.

    7. The default is “localhost”, but if your LDAP directory is not installed on the same machine as this front-end server, set this parameter to the host name where the LDAP directory is installed (where Directory Server is installed).

    local.authldaphost=ldaphost

    where ldaphost is the host name where your LDAP directory is installed.

  7. Set the LDAP host for user preferences.

    8. If you have a separate LDAP directory for user preferences, set this parameter to that host name. Otherwise, this should be the same as the local.authldaphost.The default is “localhost”.

    local.ugladaphost=”ldaphost”

    where “ldaphost” is the host name where your LDAP directory is installed.

  8. Disable the Event Notification Service (enpd):

    9. service.ens.enable=”no”

  9. Disable calendar database server alarms:

    10. caldb.serveralarms=”0”
    caaldb.serveralarms.dispatch=”no”

  10. Disable the notify service:

    11. service.notify.enable=”no”

  11. Disable the automatic backup services:

    12. caldb.berkeleydb.archive.enable=”no”
    caldb.berkeleydb.hotbackup.enable=”no”

  12. Restart Calendar Server for the changes to take effect:

    13. cal_svr_base/SUNWics5/cal/sbin/start-cal

To Configure a Back-End Server for CLD and DWP

On each back-end server, set the following ics.conf parameters:

To configure a back-end server, set the following parameters in the ics.conf file on each back-end server.

  1. Enable the DWP service (csdwpd).

    2. The default is “no” (disabled).

    service.dwp.enable = "yes"

  2. Set the DWP port number.

    3. The default port number is “59779”. The port number must be the same for all configured front-end and back-end servers.

    service.dwp.port = "59779"

  3. Disable the HTTP service because it is not required on a back-end server.:

    4. service.http.enable = "no"

  4. Make sure service.admin.enable is set to the default value of "yes".

    5. service.admin.enable = "yes"

  5. Set the calendar lookup type to use the plug-in:

    6. The default is “local” (no CLD).

    caldb.cld.type = "directory"

  6. Set csapi.plugin.calendarlookup to "n" because a back-end server does not need to perform any calendar data lookup:

    7. csapi.plugin.calendarlookup = "n"

  7. Set the LDAP host for authentication.

    8. The default is “localhost”, but if your LDAP directory is not installed on the same machine as this back-end server, set this parameter to the host name where the LDAP directory is installed (where Directory Server is installed).

    local.authldaphost=ldaphost

    where ldaphost is the host name where your LDAP directory is installed.

  8. Set the LDAP host for user preferences.

    9. If you have a separate LDAP directory for user preferences, set this parameter to that host name. Otherwise, this should be the same as the local.authldaphost.The default is “localhost”.

    local.ugladaphost=”ldaphost”

    where “ldaphost” is the host name where your LDAP directory is installed.

  9. Restart Calendar Server for the changes to take effect.

To Configure Both Front-End and a Back-End Servers on the Same Machine

On each machine, edit the ics.conf file as follows:

  1. Enable the DWP service (csdwpd):

    2. service.dwp.enable = "yes"

  2. Set the port number for the DWP service (csdwpd):

    3. service.dwp.port = "59779"

    The default is “59779”. The port number must be the same for all configured front-end and back-end servers.

  3. Enable calendar lookup plug-ins:

    4. csapi.plugin.calendarlookup = "y"

  4. Have Calendar Server load all plug-ins:

    5. csapi.plugin.calendarlookup.name = "*"

    This loads all plug-ins in the plug-in directory.

  5. Specify the type of calendar lookup plug-in that Calendar Server should use:

    6. caldb.cld.type = "directory"

  6. Set the default DWP server name:

    7. caldb.dwp.server.default = "server-name"

    where server-name is the fully qualified default server name used by Calendar Server if the user or resource entry in the LDAP server database does not have an icsDWPHost attribute. This name must be resolvable by your Domain Name Service (DNS) into a valid IP address. For example:

    caldb.dwp.server.default = "calendar.sesta.com"

  7. Set the server name for all front-end/back-end servers in the configuration, including the local server:

    8. caldb.dwp.server.server-1.ip = "server-1"
    caldb.dwp.server.server-2.ip = "server-2"
    ...
    caldb.dwp.server.server-n.ip = "server-n"

    The server name must be fully qualified and be resolvable by your Domain Name Service (DNS) into a valid IP address. In each part of the parameter, the server name must be identical and fully qualified. For example:

    caldb.dwp.server.calendar.sesta.com.ip = "calendar.sesta.com"

    The server name must also match the name used for the icsDWPHost LDAP attribute for the applicable calendar owners.

  8. Enable the Event Notification Service (enpd):

    9. service.ens.enable=”yes”

  9. Enable calendar database server alarms:

    10. caldb.serveralarms=”1”
    caaldb.serveralarms.dispatch=”yes”

  10. Set the LDAP host for authentication.

    11. The default is “localhost”, but if your LDAP directory is not installed on the same machine as this front-end server, set this parameter to the host name where the LDAP directory is installed (where Directory Server is installed).

    local.authldaphost=ldaphost

    where ldaphost is the host name where your LDAP directory is installed.

  11. Set the LDAP host for user preferences.

    12. If you have a separate LDAP directory for user preferences, set this parameter to that host name. Otherwise, this should be the same as the local.authldaphost.The default is “localhost”.

    local.ugladaphost=”ldaphost”

    where “ldaphost” is the host name where your LDAP directory is installed.

  12. Restart Calendar Server for the changes to take effect.

Maintaining Security Between Front-End and Back-End Servers

You can configure password authentication between front-end and back-end servers. This section explains how secure communication between the two can be set up and how it works. The following topics are covered:

How Authentication is Accomplished

A front-end server uses the Database Wire Protocol (DWP) to communicate with a back-end server. Because DWP uses HTTP as the transport mechanism, Calendar Server provides authentication for DWP connections between front-end and back-end servers using the configuration parameters in Table 6-1 and Table 6-2.

These parameters are optional and by default are not included in the ics.conf file. To use authentication for DWP connections, you must add the required parameters to the ics.conf file on each front-end and back-end server.

Table 6-1  Back-end Configuration Parameters for Authentication of a DWP Connection

Parameter

Description

service.dwp.admin.userid

On a back-end server, specifies the user ID that is used to authenticate a DWP connection. If a back-end server does not specify a user ID, no authentication is performed.

service.dwp.admin.cred

On a back-end server, specifies the password that is used to authenticate a DWP connection. If a back-end server does not specify a password, no authentication is performed.

Table 6-2  Front-end Configuration Parameters for Authentication of a DWP Connection

Parameter

Description

caldb.dwp.server.back-end-server.admin

On a front-end server, specifies the user ID that is used for authentication for a DWP connection to a back-end server, where back-end-server is the name of the server.

caldb.dwp.server.back-end-server.cred

On a front-end server, specifies the password that is used for authentication for a DWP connection to a back-end server, where back-end-server is the name of the server.

When the front-end server first connects to the back-end server, it sends the user ID and password specified by the parameters. The back-end server checks the parameters, and if both parameters match, the authentication is successful. The back-end server then sends a session ID back to the front-end server. The front-end server uses the session ID in subsequent DWP commands to the back-end server.

Subsequent connections from the same front-end server do not need to be authenticated again, unless the back-end server is restarted or the session expires because of no activity between the two servers.

If you have multiple front-end and back-end servers, you can use the same user ID and password for each one.

If a back-end server does not specify a user ID and password, no authentication is performed.

To Set Up Authentication for DWP Connections

To set up the authentication for DWP connections between front-end and back-end servers, follow these steps:

  1. In the ics.conf file on each front-end server, add these parameters:

    2. caldb.dwp.server.back-end-server.admin = "userid"
    caldb.dwp.server.back-end-server.cred = "password"

    where back-end-server is the name of the back-end server and userid and password are the user ID and password you want Calendar Server to use to authenticate the connection.

  2. In the ics.conf file on each back-end server indicted by back-end-server, add these parameters:

    3. service.dwp.admin.userid = "userid"
    service.dwp.admin.cred = "password"

    where userid and password are the same user ID and password you specified on the front-end server.



Previous      Contents      Index      Next     

Part No: 819-0024-10.   Copyright 2005 Sun Microsystems, Inc. All rights reserved.