Sun Java System Calendar Server 6.3 Administration Guide

Chapter 5 Configuring Calendar Database Distribution Across Multiple Machines in Calendar Server Version 6.3

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. You must both enable and configure the CLD plug-in.

Caution –

You must run the same version of Calendar Server on both the front-end and back-end servers.

This chapter contains the following topics:

Tip –

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

5.1 CLD Plug-in Background Information for Calendar Server Version 6.3

This section covers valuable overview and background information that you might want to understand before actually enabling and configuring the CLD plug-in.

This section contains the following topics:

5.1.1 CLD Plug-in Overview for Calendar Server Version 6.3

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.

5.1.2 How the CLD Plug-in Works for Calendar Server Version 6.3

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

When an end user accesses a calendar through Communications 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 configuring a front-end machine, see To Configure a Front-End Server for CLD.
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.
Using the host name, Calendar Server accesses the calendar data on the back-end server using the Database Wire Protocol (DWP).
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.

Tip –

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.

5.1.3 Configurations Supported by the CLD Plug-in for Calendar Server Version 6.3

This section contains overview material about the CLD Plug-in.

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

Tip –

In all configurations, each front-end and back-end server must:

Be on the same hardware platform.
Be running the same operating system.
Be running the same Calendar Server release, including patches.
Use the same port number for the DWP port (service.dwp.port parameter). The default port number is “59779”.

5.1.3.1 Multiple Front-end Servers with Multiple Back-end Servers in Calendar Server Version 6.3

Figure 5–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 5.2 Configuring Calendar Servers for CLD and DWP.

Figure 5–1 Multiple Front-End Servers with Multiple Back-End Servers

This shows an example of a system with both multiple
back-ends and front-ends.

5.1.3.2 Multiple Machines Functioning as Both Front-end and Back-end Servers in Calendar Server Version 6.3

Figure 5–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 a Server as Both a Front-end and a Back-end.

Figure 5–2 Multiple Servers as Functioning as Both Front-end and Back-end

This graphic shows an example of machines functioning
as both front-end and back-end machines.

5.1.4 Simple Sizing Exercise for Calendar Server 6.3 Storage Requirements

This section describes a simple sizing method using a few rough formulas based on a medium usage profile. They allow you to figure out how many front-end and back-end servers you need and how much storage.

This sections covers the following topics:

5.1.4.1 Definition of Medium Usage Profile for a Calendar Server 6.3 Deployment

For our rough estimates, we are assuming the following:

All clients are Web clients.

Therefore, the only inputs to be used are: total number of users, and percent concurrency.
The average size calendar event size is 5K.
Each person creates ten events or todos per week.
80% CPU utilization.
900 MHz CPU's.
1 GB RAM per CPU.
Two years' worth of calendar data stored on system.
Six hot backup copies held in storage.

5.1.4.2 Number of Front-End CPU's

The formula is:

Number of CPU's = Number of Concurrent Users divided by 4800

5.1.4.3 Number of Back-End CPU's

The formula is:

Number of CPU's = 4 CPU's per 500,000 configured users

5.1.4.4 Amount of Storage Needed

The formula is:

Amount of Storage Per User = 100 emails per week, multiplied by 52 weeks a year, multiplied by 5K per email, multiplied by the number of years worth of data to keep online, multiplied by the number of copies (5 backups + 1 working copy) kept online = 100*52*5K*2*(5+1) = 65 MB storage per user.

That is 2.6 MB per user per year per copy held online.

Note –

The final number depends on how many hot backups or archival backups you keep online. For this example, 5 backup copies was the number used.

5.2 Configuring Calendar Servers for CLD and DWP

This sections contains instructions for configuring servers for CLD and DWP.

This section contains the following topics:

To Configure a Front-End Server for CLD

On every front-end server, log in as an administrator with permission to change the configuration.

Change to the /etc/opt/SUNWics5/cal/config directory.

Save your old ics.conf file by copying and renaming it.

Edit the ics.conf parameters as shown in the following list:
Parameters

Description

csapi.plugin.loadall

For every front-end server, set the value to “y” if you want all plug-ins starting with cs_ to be loaded into the cal-svr-base/SUNWics5/cal/bin/plugins directory.

Set to “n”, to load only a specific plug-in, the name of which is found in csapi.plugin.calendarlookup.name.

csapi.plugin.calendarlookup

Set this parameter to "yes".

csapi.plugin.calendarlookup.name

Set this parameter to the name of the plug-in,"calendarlookup". Or, to load all plug-ins, set the parameter to "*".

caldb.cld.type

This parameter specifies whether calendars are to be distributed across multiple back-ends (set value to “directory”), or calendars are to be stored on the same server on which Calendar Server is installed (set value to,“local”, which is the default value).

service.dwp.enable

Disable DWP service for the front-end, unless it is also serving as a back-end machine. For example: service.dwp.enable="no"

service.dwp.port

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

service.store.enable

This parameter is enabled by default (value = "yes"). It does not appear in the configuration file (ics.conf).

It must be added to the configuration file if you wish to disable it (value = "no").

caldb.dwp.server.backend-server-n.ip
This is a multi-valued parameter. Create one ics.confparameter for each back-end server in your Calendar Server deployment. The value of this parameter is the back-end server hostname. The server name must be fully qualified and be resolvable by your Domain Name Service (DNS) into a valid IP address. The server name must be identical and fully qualified in both the parameter name and the value.

For example:
```
caldb.dwp.server.calendar1.sesta.com="calendar1.sesta.com"
```
```
caldb.dwp.server.calendar2.sesta.com="calendar2.sesta.com"
```
caldb.dwp.server.default
Set the default DWP server name used by the system if the user or resource LDAP entry does not have an icsDWPHost attribute. The server name must be fully qualified and be resolvable by your DNS.

For example:
```
caldb.dwp.sever.default="calendar1.sesta.com"
```
local.authldaphost

The hostname where the Directory Server is installed. The default is "localhost".

local.ugldaphost

The hostname where the LDAP user preferences are stored. If you do not keep the user preferences in a separate LDAP host, then it should be set to the same value as local.authldaphost.

service.ens.enable

Disable ENS (enpd) for this front-end server, set this parameter to "no".

ENS must be enabled only on the back-end servers.

caldb.serveralarms

To disable server alarms for the front-end by setting this to "0".

Server alarms must be enabled ("1") only on the back-end servers.

caldb.serveralarms.dispatch

To disable the alarm dispatcher, set this parameter to "no".

The alarm dispatcher should be enabled ("yes") only on the back-end servers.

service.notify.enable

To disable the notify service, set this parameter to "no".

The notify service should be enabled ("yes") only on back-end servers.

caldb.berkeleydb.archive.enable

To disable the automatic archive backup service, set this parameter to "no". There is no need to have archiving configured on a front-end machine.

caldb.berkeleydb.hotbackup.enable

The automatic hot backup service should be disabled (value set to "no"). There is no need for hot backups on a front-end machine.

Save the file as ics.conf.

Restart Calendar Server.

cal-svr-base/SUNWics5/cal/sbin/start-cal

To Configure a Back-end Server for CLD and DWP

On every back-end server, log in as an administrator with permission to change the configuration.

Change to the /etc/opt/SUNWics5/cal/config directory.

Save your old ics.conf file by copying and renaming it.

Edit the ics.conf parameters as shown in the following table:
Parameters

Description

service.http.enable

Set this parameter to "no".

There is no need for HTTP on a back-end server.

service.admin.enable

Enable the administration service (csadmind) by setting the parameter to "yes", which is the default.

caldb.cld.type

If this machine is a back-end only machine, set to "local". If this machine is both a front-end and a back-end, set to "directory".

csapi.plugin.calendarlookup

Set this parameter to "no".

There is no need for a plug-in on a back-end server.

service.dwp.enable

Enable DWP by setting this parameter to "yes"

service.dwp.port

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

caldb.dwp.server.backend-server-n.ip
This is a multi-valued parameter. Create one ics.confparameter for each back-end server in your Calendar Server deployment. The value of this parameter is the back-end server hostname. The server name must be fully qualified and be resolvable by your Domain Name Service (DNS) into a valid IP address. The server name must be identical and fully qualified in both the parameter name and the value.

For example:
```
caldb.dwp.server.calendar1.sesta.com="calendar1.sesta.com"
```
```
caldb.dwp.server.calendar2.sesta.com="calendar2.sesta.com"
```
caldb.dwp.server.default
Set the default DWP server name used by the system if the user or resource LDAP entry does not have an icsDWPHost attribute. The server name must be fully qualified and be resolvable by your DNS.

For example:
```
caldb.dwp.sever.default="calendar1.sesta.com"
```
local.authldaphost

The hostname where the Directory Server is installed. The default is "localhost".

local.ugldaphost

The hostname where the LDAP user preferences are stored. If you do not keep the user preferences in a separate LDAP host, then it should be set to the same value as local.authldaphost.

service.ens.enable

To enable ENS (enpd) for this back-end server, set this parameter to "yes".

caldb.serveralarms

Server alarms must be enabled ("1") on the back-end servers.

Save the file as ics.conf.

Restart Calendar Server.

cal-svr-base/SUNWics5/cal/sbin/start-cal

To Configure a Server as Both a Front-end and a Back-end

On every server, log in as an administrator with permission to change the configuration.

Change to the /etc/opt/SUNWics5/cal/config directory.

Save your old ics.conf file by copying and renaming it.

Edit the ics.conf parameters as shown in the following table:
Parameters

Description

csapi.plugin.loadall

For every front-end server, set the value to “y” if you want all plug-ins starting with cs_ to be loaded into the cal-svr-base/SUNWics5/cal/bin/plugins directory.

Set to “n”, to load only the CLD plug-in, the name of which is found in csapi.plugin.calendarlookup.name.

csapi.plugin.calendarlookup

Set this parameter to "yes".

csapi.plugin.calendarlookup.name

To load all plug-ins, set the parameter to "*".

If you want to load only the CLD plug-in, set this parameter to the name of the plug-in,"calendarlookup".

caldb.cld.type

This parameter specifies whether calendars are to be distributed across multiple back-ends (set value to “directory”), or calendars are to be stored on the same server on which Calendar Server is installed (set value to,“local”, which is the default value).

service.dwp.enable

Enable DWP by setting this parameter to "yes"

service.dwp.port

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

caldb.dwp.server.backend-server-n.ip
This is a multi-valued parameter. Create one ics.confparameter for each back-end server in your Calendar Server deployment. The value of this parameter is the back-end server hostname. The server name must be fully qualified and be resolvable by your Domain Name Service (DNS) into a valid IP address. The server name must be identical and fully qualified in both the parameter name and the value.

For example:
```
caldb.dwp.server.calendar1.sesta.com="calendar1.sesta.com"
```
```
caldb.dwp.server.calendar2.sesta.com="calendar2.sesta.com"
```
caldb.dwp.server.default
Set the default DWP server name used by the system if the user or resource LDAP entry does not have an icsDWPHost attribute. The server name must be fully qualified and be resolvable by your DNS.

For example:
```
aldb.dwp.sever.default="calendar1.sesta.com"
```
local.authldaphost

The hostname where the Directory Server is installed. The default is “localhost”(on the same server as the front-end).

local.ugldaphost

The hostname where the LDAP user preferences are stored. If you do not keep the user preferences in a separate LDAP host, then it should be set to the same value as local.authldaphost.

service.ens.enable

Enable ENS by setting this parameter value to "yes".

caldb.serveralarms

Server alarms must be enabled ("1") on the back-end servers.

caldb.serveralarms.dispatch

The alarm dispatcher should be enabled ("yes") on the back-end servers.

service.notify.enable

The notify service should be enabled ("yes") on back-end servers.

caldb.berkeleydb.archive.enable

The automatic archive backup service should be enabled (value set to "yes"on the back-end systems.

caldb.berkeleydb.hotbackup.enable

The automatic hot backup service should be enabled (value set to "yes"on the back-end systems.

Save the file as ics.conf.

Restart Calendar Server.

cal-svr-base/SUNWics5/cal/sbin/start-cal

5.3 Maintaining Security Between Front-End and Back-End Servers for Calendar Server Version 6.3

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.

This section covers the following topics:

5.3.1 How Authentication is Accomplished in Calendar Server Version 6.3

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 configuration parameters.

When the front-end server first connects to the back-end server, it sends the user ID and password specified in the ics.conf file. The back-end server checks the parameters in its ics.conf file, 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 for a Front-end Server in Calendar Server Version 6.3

Before You Begin

Caution –

These parameters are not included in the installed version of 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 server.

On every front-end server, log in as an administrator with permission to change the configuration.

Change to the /etc/opt/SUNWics5/cal/config directory.

Save your old ics.conf file by copying and renaming it.

Add the ics.conf parameters as shown in the following list:

Parameter

Description

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

On a front-end server, specifies the administrator's 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.

Save the file as ics.conf.

Restart Calendar Server.

cal-svr-base/SUNWics5/cal/sbin/start-cal

To Set up Authentication for DWP Connections for a Back-end Server in Calendar Server Version 6.3

Before You Begin

Caution –

On every back-end server, log in as an administrator with permission to change the configuration.

Change to the /etc/opt/SUNWics5/cal/config directory.

Save your old ics.conf file by copying and renaming it.

Add the ics.conf parameters as shown in the following table:

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.

Save the file as ics.conf.

Restart Calendar Server.

cal-svr-base/SUNWics5/cal/sbin/start-cal