Background Information

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

• CLD Plug-in Overview

• How the CLD Plug-in Works

• Configurations Supported by the CLD Plug-in

• Simple Sizing Exercise

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, 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.

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.

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

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

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”.

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 Calendar Servers for CLD and DWP.

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

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

Simple Sizing Exercise

The following are a few rough formulas based on a medium usage profile for figuring how many back-end and front-end servers you need, and how much storage:

• Definition of Medium Usage Profile

• Number of Front-End CPU's

• Number of Back-End CPU's

• Amount of Storage Needed

Definition of Medium Usage Profile

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 2K.

• Each person creates five 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.

Number of Front-End CPU's

The formula is:

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

Number of Back-End CPU's

The formula is:

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

Amount of Storage Needed

The formula is:

Amount of Storage = 5 emails per week times 52 weeks a year times 2K per email (5*52*2K)

= 520KB per user per year

For the assumed two years of calendar data, 1 MB per user.