This part contains the following chapters:
This chapter provides an overview of Sun Java System Calendar Server, the business reasoning behind deploying Calendar Server, and the deployment process itself.
This chapter contains the following sections:
Sun Java System Calendar Server is a high-performance, Internet standards-based calendar server designed with the scalability to meet the needs of customers ranging from medium- and large-sized enterprises to even the largest telecommunication and Internet service providers. Through a Web browser interface or connectors to other calendar clients, including Microsoft Outlook, Calendar Server provides group scheduling and personal calendaring to consumers at home or at work, while enabling them to share calendar information with others over the Internet.
Calendar Server provides one of the industry’s most open, interoperable, and high-performance time and resource management solutions. Through its scalability, performance, and reliability, it provides the features you require at a lower total cost of ownership than alternative solutions. Native support for iCalendar standards enables users to schedule events in a format that is easily shared across the Internet. Calendar Server employs standards and protocols such as:
Internet Calendaring (iCalendar)
iCalendar Transport-Independent Interoperability Protocol (iTIP)
iCalendar Message-based Interoperability Protocol (iMIP)
eXtensible Markup Language (XML)
Lightweight Directory Access Protocol (LDAP)
HyperText Transport Protocol (HTTP)
The Calendar Server architecture is flexible, extensible, and scalable both vertically (by increasing the number of CPUs per system) and horizontally (by introducing additional servers into the network). As a result, Calendar Server can be thought of as a system of servers that can be configured to fit a variety of needs. It can remain in isolation as a standalone calendar server, or it can be configured with many instances, having the various services duplicated or split between them.
Calendar Server makes use of plugins to obtain external services. Calendar Server also supports both LDAP- and identity-based deployments, and integrates with Sun Java System Access Manager, Sun Java System Portal Server, and Sun Java System Instant Messaging to provide additional functionality.
Calendar Server provides the following benefits:
Group scheduling, free-busy lookup, and corporate directory lookup
Resource scheduling for conference rooms, projectors, and other resources
Support for standards-based event and calendar data feeds published in XML or iCalendar formats, which improves communication and can offer new revenue opportunities through commerce links and banner ads
Native LDAP support, with an API for other directory services
Support for the Connector to Microsoft Outlook
Support for hosted domains including command-line and GUI tools to manage these domains
Simplified system management, online backup and restore, and entire database backup and restore
Support for multiple calendars, such as work, family, friends, and more
Support for public and private calendars, as well as public, private, and confidential individual events
Automatic email notification of appointments, invitations, and reminders sent to selected recipients; integrates with Sun Java System Instant Messaging to provide automatic pop-up reminders
Support for multiple owners of each calendar, to facilitate communication and productivity with project teams and community groups
Ability to delegate calendar ownership to others who may act on behalf of the primary owner
Support for daily, weekly, monthly, and yearly views of a calendar
Supports hundreds of thousands of users through a scalable, networked, server-to-server, client- server architecture
Supports Secure Sockets Layer (SSL) encryption, LDAP authentication, authentication plugins, and identity-enabled single sign-on (SSO) through Access Manager
Integrated personal address book and email functionality
Support for layered calendar views, enabling users to combine two or more calendars into a single view for improved communications and productivity
Support for attachments in events and tasks
Support for LDAP groups including static, nested, and dynamic groups
For more information on Calendar Server concepts, see the Sun Java System Calendar Server 6.3 Administration Guide.
The deployment process consists of the following general phases, referred to as the Solution Life Cycle:
Analyzing business requirements
Analyzing technical requirements
Designing the logical architecture
Designing the deployment architecture
Implementing the deployment
Operating the deployment
The deployment phases are not rigid: the deployment process is iterative in nature.
Before you begin your Calendar Server deployment planning, a good question to ask is:
Why is my organization deploying Calendar Server?
Several reasons to consider are:
Cost savings. The total cost of ownership per user is lower than using other calendar products on the market.
Increased productivity. Your calendar users can manage their events and tasks as well as schedule meetings and appointments with others in the organization. Your users can also manage calendar groups and resources such as meeting rooms and equipment. They can also synchronize their calendars with mobile devices and Microsoft Outlook.
Improved scalability and availability. Calendar Server scales both horizontally and vertically. If your organization grows, you can easily upgrade your configuration by upgrading a server or add more servers.
High availability (HA) configuration. Integration with Sun Cluster software enables you to configure Calendar Server as a highly available service. If you experience a software or hardware failure, Calendar Server fails over to a secondary server.
Deploying Calendar Server usually involves a number of people, each with different roles and responsibilities. In a small organization, one person might perform several roles. Some of the roles to consider are:
Program Manager oversees the overall Calendar Server deployment and is responsible for its success or failure.
Calendar Server Administrator performs day-to-day administrative tasks to manage Calendar Server and might also be responsible for installing and upgrading Calendar Server.
Performance Engineer tests and monitors the Calendar Server performance for the trial and production deployments to see if the deployment criteria is met.
Development Engineering writes Calendar Server applications or plugins, or customizes the Calendar Server user interface (UI), if required.
Documentation Specialist writes any customized documentation for administrators and end users.
Education/Training develops training classes and material.
Support Specialists, who support both the trial and production deployments.
End users can connect to Calendar Server by using the Communications Express web client, or Sun Java System Connector for Microsoft Outlook.
Questions about end users at your site include:
How many total Calendar Server end users will your site have?
How will your end users connect to Calendar Server? Communications Express? Microsoft Outlook? A combination of both clients?
How many geographic locations are involved? Are your end users all in the same or different time zones?
Will your end users log into Calendar Server at the same time each day?
How many active end users will your deployment have during peak use?
How fast will your end user base grow?
What are your specific performance requirements for Calendar Server end users?
What are your single sign-on (SSO) requirements?
Are any of your users migrating from an earlier version of Calendar Server?
Are your end users planning to use Communications Sync Software?
Does your site plan to use a proxy server?
What are your specific performance requirements for your end users? For example:
What end user response times are acceptable?
Can you tolerate a possible degradation in performance during peak load times?
What configuration do you plan to use for your deployment? Calendar Server configuration scenarios include:
Single Calendar Server instance
Single front-end server with single back-end database server
Multiple front-end servers with multiple back-end database servers using LDAP CLD plugin
Multiple front-end/back-end servers using LDAP CLD plugin
High Availability (HA) configuration
If you plan to configure multiple front-end servers, how do you plan to distribute your end users?
If you plan to configure multiple back-end database servers, how do you plan to distribute your database? For example, you could distribute servers geographically.
What plans do you have for growth? For both front-end and back-end servers?
This chapter describes three basic Calendar Server deployment architectures, which can vary depending on your site’s specific requirements.
This chapter contains the following sections:
Figure 16–1 shows a single-server architecture. In this deployment, all Calendar Server services (processes) run on the same server, either in the same CPU (processor) or across multiple CPUs. The Directory Server and Access Manager processes can run on the same server or on different servers.
A Calendar Server instance on a single server includes the following services:
Administration service (csadmind process) provides support for administration functions such as commands to start or stop Calendar Server, create or delete calendar users or resources, or fetch and store calendars.
HTTP service (cshttpd process) handles WCAP requests.
Event Notification Service (enpd) acts as the broker for event and alarm notifications.
Backup service (csstored) implements automatic backups, both archival backups and hot backups.
For a description of Calendar Server services, see the Sun Java System Calendar Server 6.3 Administration Guide.
The Database Wire Protocol (DWP) service (csdwpd process), which provides networking capability when the calendar database is on another server, is not required for a minimal configuration because the database is on the same server.
Calendar Server requires a directory server to authenticate users and to store user preferences. Usually, the directory server is an LDAP directory server, such as Sun Java System Directory Server. However, if you prefer, you can use the Calendar Server API (CSAPI) to write a plugin to use a non-LDAP directory server. This API is described in the Sun Java System Calendar Server 6.3 WCAP Developer’s Guide.
The directory server can run on the same server where Calendar Server is running or on a remote server.
The tool Calendar Server uses for administration of users, groups, resources, domains, and roles for Schema 2 deployments is Delegated Administrator, which must be installed and configured separately. The Delegated Administrator has both a graphical user interface console, and a command line utility (commadmin). For information about the Delegated Administrator utility, see the Sun Java System Delegated Administrator 6.4 Administration Guide.
For Schema 1 deployments, Calendar Server has its own bundled set of utilities for administration.
You can implement SSO for Communications Suite products using Access Manager, or using trusted circle technology among the Communications Suite products. Users log in to Access Manager and then can access other the servers, as long as all servers are configured properly for SSO. For the trusted circle technology, a user logging into Messaging Server would also have access to Calendar Server and Instant Messaging without having to login again. For more information on SSO trusted circle implementation, see the Sun Java System Calendar Server 6.3 Administration Guide.
Calendar Server supports scalability by distributing a configuration over multiple front-end and back-end servers. On each server, Calendar Server services can also be distributed across multiple CPUs.
In a two-tiered architecture, sometimes referred to as network front-end/database back-end configuration (shown in the following figure), users log in to a front-end server and connect to a back-end server using the Database Wire Protocol (DWP) service (csdwpd process). The calendar database is connected only to the back-end servers. Though not shown in this figure, the front-end hosts need access to the LDAP directory.
Calendar Server processes run on both the front-end and back-end servers as follows:
Users are directed by load balancers to a front-end server, where they log in. Each front-end server requires these services:
Administration Service (csadmind process)
HTTP Service (cshttpd process)
GSE database (csstored)
Each back-end server is connected to a calendar database, so each back-end server requires these services:
In this configuration, users do not log in to the back-end servers, so the HTTP service (cshttpd process) is not required.
For a description of Calendar Server services, see the Sun Java System Calendar Server 6.3 Administration Guide.
A scalable Calendar Server configuration requires a directory server to authenticate users and to store user preferences.
In a two-tiered Calendar Server architecture with multiple front-end and back-end servers (shown in Figure 16–3), users log in to a specific server, and each server is connected to a calendar database. This configuration enables calendars to be geographically distributed, with each calendar residing on the server where its owner logs in to Calendar Server.
In this architecture, each server functions as both a front end and back end, and requires all Calendar Server services: Administration Service (csadmind process), HTTP Service (cshttpd process), Event Notification Service (enpd and csnotifyd processes), Database Wire Protocol (DWP) Service (csdwpd process), and Backup Service (csstored).
For a description of Calendar Server services, see the Sun Java System Calendar Server 6.3 Administration Guide.
In this architecture, you could also separate the front end services from the back end services onto separate machines, and use the LDAP Calendar Lookup Database (CLD) to determine which back end a front end needs to get data from. For more information, see the Sun Java System Calendar Server 6.3 Administration Guide.
A multiple front-end/back-end server deployment requires a directory server to authenticate users and to store user preferences.
This chapter describes how to plan for and protect the various components of your Calendar Server deployment.
This chapter contains the following sections:
Security plays a key role in the day-to-day operations of today’s businesses. Breaches in security can not only compromise trade secrets, but can also result in downtime, data corruption, and increased operation costs. Calendar Server provides a number of security levels to protect users against eavesdropping, unsanctioned usage, or external attack. The basic level of security is through authentication. Calendar Server uses LDAP authentication by default, but also supports the use of an authentication plugin for cases where an alternate means of authentication is desired. Furthermore, integration with Access Manager enables Calendar Server to take advantage of its single sign-on capability.
Security involves not only ensuring the integrity of users. It also means ensuring the confidentiality of data. To this end, Calendar Server supports the use of SSL encryption for login, or both login and data. In other words, only the login may be encrypted, or the entire session including the login may be encrypted, from the Web client to the server.
Integration with Secure Remote Access also provides SSL encryption, but through a proxy gateway. In addition, integration with the portal gateway provides a URL rewriting capability to further insulate Calendar Server from external entities. Calendar Server can be deployed with the portal gateway such that there is no direct connection to the Calendar Server without going through the gateway. In this case, every URL is rewritten, thus obfuscating the true URL of the Calendar Server. Even though a user is authenticated, that does not mean that the user should have access to other calendar users’ data.
Within a calendar domain exist other layers of security to prevent authenticated users from unauthorized access to other authenticated users’ calendar data. One security measure is through the Calendar Server access control entries. Access control enables calendar users to specify who can see their calendars, who can schedule events into their calendars, who can modify their calendars, and who can delete events from their calendars. Access control also enables users to select who can act on their behalf to respond to invitations, schedule or modify events, and delete events. Finally, access control can be used to span domains of users, thus preventing (or enabling) users in one domain from scheduling events with users of another domain.
In addition to access control, Calendar Server provides an additional level of security at the database protocol level for deployments that separate the calendar front end from the database back end. This level of security is referred to as Database Wire Protocol (DWP) authentication, and utilizes a user name/password pair to authenticate a DWP connection. The user name/password pairs on both the front end and database back end must be identical for a DWP connection to be authenticated.
Monitoring your server is an important part of your security strategy. To identify attacks on your system, monitor message queue size, CPU utilization, disk availability, and network utilization. Unusual growth in the message queue size or reduced server response time can identify some of these attacks. Also, investigate unusual system load patterns and unusual connections. Review logs on a daily basis for any unusual activity.
User authentication enables your users to log in through their calendar clients to retrieve their calendar information. Methods for user authentication include:
User IDs and passwords are stored in your LDAP directory. Password security criteria, such as minimum length, are determined by directory policy requirements. Password security criteria is not part of Calendar Server administration. To understand directory server password policies, see the Directory Server documentation:
http://docs.sun.com/app/docs/coll/1316.2
Both plain text and encrypted password login can be used.
Calendar Server uses the SSL protocol for encrypted communications and for certificate-based authentication of clients and servers. This section describes certificate-based SSL authentication.
SSL is based on the concepts of public-key cryptography. Although TLS (Transport Layer Security) is functionally a superset of SSL, the names are used interchangeably.
At a high-level, a server which supports SSL needs to have a certificate, a public key, a private key, certificate, key, and security databases. This helps assure message authentication, privacy, and integrity.
To authenticate with SSL, the calendar client establishes an SSL session with the server and submits the user’s certificate to the server. The server then evaluates if the submitted certificate is genuine. If the certificate is validated, the user is considered authenticated.
If you use SSL for authentication, you need to obtain a server certificate for your Calendar Server. The certificate identifies your server to clients and to other servers. Your server can have more than one server certificate with which it identifies itself. Your server can also have any number of certificates of trusted Certification Authorities (CAs) that it uses for client authentication.
For more information on SSL, see the Sun Java System Calendar Server 6.3 Administration Guide.
This chapter describes the planning information for Calendar Server services.
This chapter contains the following sections:
Calendar Server consists of six major services:
HTTP Service (cshttpd) listens for HTTP requests. It receives user requests and returns data to the caller.
Administration Service (csadmind) is required for each instance of Calendar Server. It provides a single point of authentication and administration for the Calendar Servers and provides most of the administration tools.
Notification Service (csnotify) sends notifications of events and todos using either email or the Event Notification Service.
Event Notification Service (enpd) acts as the broker for event alarms.
Distributed Database Service (csdwpd) links multiple database servers together within the same Calendar Server system to form a distributed calendar store.
Backup Service (csstored) implements automatic backups, both archival backups and hot backups. The first backup is a snapshot with log files, the second is a snapshot with log files applied. This service is automatically started when you run the start-cal command.
In a scalable Calendar Server deployment, you would deploy front-end systems in conjunction with a back-end server. The front-end systems would contain one instance of the cshttpd daemon per processor and a single Administration Service. A back-end server would contain an instance of Notification Service, Event Notification Service, Distributed Database Service and Administration Service. The calendar databases can be distributed over one or more back-end machines. These back-end machines can be associated with one front-end machine.
Calendar back-end services usually require half the number of CPUs sized for the Calendar front-end services. To support quality of service by the Calendar front-end system, the Calendar back-end system should use around two-thirds the number of CPUs as the front-ends.
You will want to consider early on in a deployment separating the Calendar Service into front-end and back-end services. Assign a separate host name for the front-end services and back-end services so that when it comes time to separate the functionality onto different hosts, the changes are essentially internal and do not require users to change their methods of operation.
The Calendar Server HTTP process that is typically a component of the front-end services is a dominant user of CPU time. Account for peak calendar usage to provide enough front-end processing power to accommodate the expected peak HTTP sessions. Typically, you would make the Calendar Server front end more available through redundancy, that is, by deploying multiple front-end hosts. As the front-end systems do not maintain any persistent calendar data, they are not good candidates for HA solutions like Sun Cluster. Moreover, the additional hardware and administrative overhead of such solutions make deploying HA for Calendar Server front ends both expensive and time-consuming. Communications Express deployments with Calendar Server have different characteristics. See the Communications Express documentation for more information.
The only configuration for Calendar front ends that might warrant a true HA solution is one where the Calendar front end is deployed on the same host that contains a Messaging Server MTA. Even in this configuration, however, the overhead of such a solution should be carefully weighed against the slight benefit.
A good choice of hardware for the Calendar Server front ends is a single or dual processor server. In this case, you deploy one instance of the Calendar Server cshttpd daemon per processor. Such a deployment affords a cost-effective solution, enabling you to start with some level of initial client concurrency capability and add client session capacity as you discover peak usage levels on your existing configuration.
When you deploy multiple front ends, a load balancer (with sticky/persistent connections) is necessary to distribute the load across the front-end services.
The Calendar Server back-end services are well balanced in resource consumption and show no evidence of bottleneck formation either in CPU or I/O (disk or network). Thus, a good choice of hardware for the back end would be a SPARC server with a single striped volume. Such a machine presents considerable capacity for large-peak calendar loads.
If your requirements include high availability, deploy the Calendar Server back end with Sun Cluster, as the back end contains persistent data.
In a configuration with both front-end and back-end Calender Server hosts, all hosts must be running the same releases of Calendar Server, including patch or hotfix releases.
The LDAP data cache option ensures that LDAP data is available immediately after it has been committed. In some configurations of LDAP, an update might need to be referred to a (remote) master server from which the update is then replicated down to the local LDAP directory. These kinds of configurations can induce a delay in the availability of committed data on the local LDAP server.
The LDAP data cache can ensure that your Calendar Server clients have accurate LDAP data, but can introduce a delay in the availability of committed LDAP data. For example, if your site has deployed a master/slave LDAP configuration, with Calendar Server accessing the master LDAP directory through a slave LDAP directory server, it introduces a delay.
This section covers the following topics:
Using the LDAP Data Cache in a Master/Slave LDAP Configuration
Configuring the LDAP Data CacheConfiguring the LDAP Data Cache
Use these guidelines to determine if your site should configure the LDAP data cache:
You don’t need to configure the LDAP data cache if your Calendar Server accesses the master (or root) LDAP directory directly with no delays in the availability of committed LDAP data.
If your site has deployed a Using the LDAP Data Cache in a Master/Slave LDAP Configuration where Calendar Server accesses the master LDAP directory through a slave LDAP directory server, which in turn introduces a delay in the availability of committed LDAP data, configure the LDAP data cache to ensure that your end users have the most recent data.
A Master/Slave LDAP configuration includes a master (root) directory server and one or more slave (consumer or replica) directory servers. Calendar Server can access the master LDAP directory server either directly or through a slave directory server:
If Calendar Server accesses the master LDAP directory server directly, the LDAP should be accurate, and you do not need to configure the LDAP data cache. In this case, make sure that the local.ldap.cache.enable parameter is set to “no” (which is the default).
If Calendar Server accesses the master LDAP directory server through a slave directory server, LDAP data changes are usually written to the master directory server transparently using an LDAP referral, which in turn replicates the data back to each slave directory server. This introduces a delay in the availability of committed LDAP data. For example, Calendar Server commits an LDAP data change, but the new data is not available for a specific amount of time because of the delay in the master directory server updating each slave directory server. A subsequent Calendar Server client operation uses the old LDAP data and presents an out-of-date view.
If the delay in updating the slave directory servers is short (only a few seconds), clients might not experience a problem. However, if the delay is longer (minutes or hours), clients will display inaccurate LDAP data for the length of the delay.
The following table lists the LDAP attributes that are affected by a delay in a master/slave LDAP server configuration where Calendar Server accesses the master LDAP directory server through a slave LDAP directory server.
Table 18–1 Calendar Server LDAP Attributes Affected by Delays
Operation |
LDAP Attributes Affected |
---|---|
Auto provisioning |
icsCalendar, icsSubscribed, icsCalendarOwned, icsDWPHost |
Calendar groups |
icsSet |
Calendar creation |
icsCalendarOwned, icsSubscribed |
Calendar subscription |
icsSubscribed |
User options |
icsExtendedUserPrefs, icsFirstDay, icsTimeZone, icsFreeBusy |
Calendar searches |
icsCalendarOwned |
To ensure that your end uses have the most recent LDAP data, configure the LDAP data cache as described in the following section, Resolving the Master-Slave Delay Problem.
The LDAP data cache resolves the master/slave LDAP configuration problem by providing Calendar Server clients with the most recent LDAP data, even when the master directory server has not updated each slave directory server.
If the LDAP data cache is enabled, Calendar Server writes committed LDAP data to the cache database (ldapcache.db file). By default, the LDAP cache database is located in the /var/opt/SUNWics5/csdb/ldap_cache directory, but you can configure a different location if you prefer.
When a client makes a change to the LDAP data for a single user, Calendar Server writes the revised data to the LDAP cache database (as well as to the slave directory server). A subsequent client operation retrieves the LDAP data from the cache database. This data retrieval applies to the following operations for a single user:
User’s attributes at login
User’s options (such as color scheme or time zone)
User’s calendar groups
User’s subscribed list of calendars
Thus, the LDAP data cache database provides for:
Data consistency across processes on a single system—The database is available to all Calendar Server processes on a multiprocessor system.
Data persistence across user sessions—The database is permanent and does not require refreshing. You can configure the time to live (TTL) for an LDAP data cache entry and the interval between each database cleanup.
The LDAP data cache does not provide for:
Reading the cache for searches where a list of entries is expected, for example, searching for attendees for a meeting. This type of search is subject to any LDAP delay. For instance, a newly created calendar will not appear in a calendar search if the LDAP search option is active and the search is performed within the delay period following the creation of a new calendar.
Reading and writing of the cache across multiple front-end servers. Each front-end server has its own cache, which is not aware of data in other caches.
The capability to handle a user who doesn’t always log into the same server. Since each server has its own LDAP cache, within the delay period, one cache will not know about the user's activities while logged into the another cache.
Configure the LDAP data cache by setting the appropriate parameters in the ics.conf file. See the Sun Java System Calendar Server 6.3 Administration Guide for more information.
If Calendar Server or the server where Calendar Server is running is not properly shut down, manually delete all files in the ldap_cache directory to avoid any database corruption that might cause problems during a subsequent restart.
For new Calendar Server installations, you must first create a default domain before running the Calendar Server configuration script. To create a default domain, use Delegated Administrator. This means that Delegated Administrator must be installed and configured before Calendar Server is configured.