... h1. Sun Java Calendar Server 7 Deployment Planning
Topics:
{toc:minLevel=2|maxLevel=2}
h2. Calendar Server 7 Deployment Architecture
The following Sun Java Enterprise System, Communications Suite, and database components are required for a Calendar Server 7 deployment:
* GlassFish Enterprise Server (web container for Calendar Server)
* Calendar Server (CalDAV server)
* Directory Server
* MySQL Server (calendar store) |
...
h4. Planning for Multiple Calendar Server Hosts
Using multiple Calendar Server hosts can help in the following ways:
* Avoiding network latency and unnecessary bandwidth consumption by positioning the server closer to the client (geographically distributed environment).
* Scaling horizontally by distributing 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.
Another reason to have multiple servers is if the deployment uses one repository per data type (see [User Repository|Introduction to Calendar Server 7#User Repository]). In that case, each user can have three independent repositories (for calendar, address book, and files), residing on three different servers or a set of servers.
The smallest unit of data that can be migrated from one server to another corresponds to a single subject's repository.
h2. MySQL Based Deployment
!CommSuite:Communications Suite Attachments^MySQL-deployment.jpg|alt="This figure shows MySQL Server deployed for Calendar Server 7."!
If you deploy Calendar Server with other applications in the same GlassFish Enterprise Server web container, you have an additional context root in the URI:
{{http://}}_calendar-server-host-name_{{:}}_port_context-root_{{/dav/principals/}}_email-address_{{/}}
Example: {nolink}http://example.com:3080/app1/dav/principals/jsmith@example.com/{nolink}
h2. Calendar Server Logical Architecture
* *Single-Tiered Calendar Server Architecture.* You can deploy all components to a single host.
* *Two-Tiered Calendar Server Architecture.* You can deploy Calendar Server with the front-end davserver component installed on a separate host and the MySQL Server back end installed on another host.
* *Two-Tiered, Multiple Server Calendar Server Architecture.* You can install multiple front-end davserver hosts and multiple back-end MySQL Server hosts.
h2. Mapping Calendar Users to Back-End Servers
As described in [Front-End and Back-End Servers|Introduction to Calendar Server 7#Front-End and Back-End Servers], you can distribute the DAV repository across multiple DAV server instances. The smallest unit of data corresponds to a single subject (user or group) home collection and all its descendants. When a user issues a Calendar Server request, the front-end host handling the request must determine on which back-end MySQL host the targeted resource resides. This is the role of the _davstore identifier_.
h4. About the davstore Identifier
The mapping between 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 IDs." One davstore ID is configured per back-end MySQL host database.
* A Java Naming and Directory Interface (JNDI) name is associated with each davstore ID is (it is also in the Calendar Server configuration), for example: {{jdbc/}}{_}davstore id_.
* The GlassFish Enterprise Server's web container hosting the server is configured with corresponding JNDI resources containing the actual back-end information, for example, server names, ports, database names, and credentials.
* At startup, the server does a JNDI lookup for each davstore ID value in its configuration.
A single MySQL Server instance can contain multiple SQL databases. Each davstore ID identifies one of those SQL databases, not the MySQL Server instance as a whole.
h4. davstore LDAP Attribute
You can add the {{davStore}} LDAP attribute to users' and resources' subject entries 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. {{davstore}} is single valued. If a {{davstore}} is not present, a server configurable default davstore ID is used.
Calendar Server users use only one attribute for all data types (calendar, address book, and files). This arrangement does not prevent a deployment from using different repositories for the different types of data. The only restriction associated with using a unique attribute is that all users with the same {{davStore}} value are hosted on the same repository.
{info:title=Note}The Calendar Server installation and configuration supports only one front-end/back-end deployment. You need to perform some additional steps to set up the multiple-server scenario. See [CommSuite7:Calendar Server 7 Multiple Hosts Scenarios] for more information. *Link not yet publicly available.*{info}
|