2 Planning Your Contacts Server Installation
This chapter provides information about planning your Oracle Communications Contacts Server installation. It also describes the Contacts Server logical and physical architectures.
About Contacts Server
Contacts Server enables end users to store and retrieve contact information such as name, email address, photo, birthdays, and any other information that relates to the contact. Contacts Server supports all properties defined in the vCard specification, RFC 6350, available at:
http://tools.ietf.org/html/rfc6350
Contacts Server provides a Network Address Book that facilitates centralized storage and access of contacts for a large number of users. Being full-featured, it not only provides contact creation, management and searching capabilities along with multiple group and multiple address book support, but includes features that enterprises demand, such as Global Address List integration and address book sharing. Contacts Server provides the capability to back up, synchronize, and merge address books in a secure, accessible, reliable, and device independent way. Contacts Server also enables end users to create multiple address books for organizing and sharing contacts.
Contacts Server Front-End and Back-End Components
Contacts Server consists of the following front-end and back-end components:
-
Stateless J2EE-based front end (provided by the application server)
-
SQL back end (can be either MySQL Server or Oracle Database)
-
Document store, for storing of large data
You can locate these components on the same host or separate the components onto multiple hosts.
Figure 2-1 shows a Contacts Server configuration that uses two hosts.
Figure 2-1 Contacts Server Front-End and Back-End Configuration
Description of ''Figure 2-1 Contacts Server Front-End and Back-End Configuration''
In a multiple-host deployment, each front end has access to all the SQL back ends. As a consequence, each front-end host has access to all Contacts Server end users' data.
Multiple front ends can be grouped together by using a simple load balancer. The load balancer must use IP-based stickiness as its load balancing method.
Planning Your Contacts Server Installation
This section contains the following planning topics you must consider before installing Contacts Server:
Using a Single Web Container for Multiple Applications
Contacts Server requires that you use the application server as its web container. For production deployments, deploy Contacts Server to the root context (/) to simplify configuring mobile clients. The URI syntax is:
http://contacts-server-host-name:port/contacts-server-webapp/dav/principals/email-address/
For example:
http://example.com:3080/nabserver/dav/principals/jsmith@example.com/
You can deploy Contacts Server with other applications in the same application server web container. In this case, you deploy Contacts Server in its own context, for example, /nabserver, and not the root context (/) of the application server instance.
You cannot deploy Contacts Server and Calendar Server in the same domain, even if you use different contexts, for example, /nabserver and /davserver. You must deploy Contacts Server and Calendar Server in different domains.
Regardless of whether you use a single web container for multiple applications or put Contacts Server in its own web container, for production environments, deploy Contacts Server under the root (/) URI context.
Deciding on the Database
You can use either MySQL Server or Oracle Database as the Contacts Server database to store contact information. You cannot mix database types in a deployment.
Caution:
You can view contents of the database by using standard SQL tools. However, do not use SQL tools to modify your data. This applies to both MySQL Server and Oracle Database.Planning for Multiple Contacts Server Hosts
Using multiple Contacts Server hosts can help you:
-
Avoid network latency and unnecessary bandwidth consumption by positioning the server closer to the client (in a geographically distributed environment).
-
Scale your deployment by distributing end 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.
Note:
The Contacts Server default installation and configuration supports only one front-end/back-end deployment. You must perform some additional steps to set up the multiple-server scenario. See "Configuring Contacts Server With Multiple Hosts" for more information.Planning the Document Store
The Contacts Server document store is used to store and retrieve large data, such as photos and logos. You must set up one document store per configured Contacts Server back-end database. That is, every logically configured database must have its own unique document store to manage its large data. You must configure a document store even if you decide to not use its capability.
The document store can be either local or remote, or, if you use Oracle Database, within the database itself. When the document store is local, it runs as part of a Contacts Server instantiation. For example, the local document store could be part of a Contacts Server front-end installation or part of a single host installation providing both front-end and back-end functionality. When the document store is local, Contacts Server accesses the file systems directly. You can only use a local document store in a single front-end deployment, as all front end hosts need to be able to access the data. When the document store is remote, Contacts Server accesses the documents by using either HTTP or HTTPS. If you use Oracle Database, you can configure it to contain both the contact data and the data that otherwise would need to be stored in the separate document store. That is, you would use a single, large Oracle database for both contacts data and the document store.
Note:
You cannot configure MySQL database to contain both contact data and document store data.Planning for Virus Scanning
Contacts Server supports virus scanning of attachments, such as photos. If you choose to configure virus scanning, decide whether to use an existing Oracle Communications Messaging Server MTA, or to deploy a dedicated MTA-only Messaging Server installation to scan for viruses. To use virus scanning for Contacts Server, you must deploy at least Messaging Server 7.4 patch 23. For more information, see the topic on configuring virus scanning in Calendar Server System Administrator's Guide.
Though this information is written for Calendar Server, it also applies to Contacts Server.
Planning for the Unique Identifier
Contacts Server requires a unique identifier in the form of an LDAP attribute whose value is used to map each user account (in the LDAP Directory Server) to a unique account in the contacts database (the MySQL Server or Oracle Database that stores the Contacts Server data). The unique identifier links various entries from different database tables for a user. You must use a unique identifier, and one that does not change, for each user entry stored in LDAP.
Before installing Contacts Server, decide on the LDAP attribute to be used as the unique identifier. This is a critical decision. It is very difficult to change the attribute you use as the unique identifier once you deploy Contacts Server and start using it. Contacts Server provides the davuniqueid attribute, which is the recommended attribute to use. For more information, see the unique identifier documentation in Calendar Server Concepts. Though this information is written for Calendar Server, it also applies to Contacts Server.
System Deployment Planning
This section contains the following system-level planning topics you must consider before installing Contacts Server:
Planning for High Availability
You can configure Contacts Server front-end and back-end hosts to be highly available. For high availability of front-end hosts, deploy the hosts behind a load balancer. See "Using Load Balancing" for more information. Choices for making the Contacts Server back-end database highly available include MySQL asynchronous replication and Oracle Data Guard. Refer to the documentation for those products for installation and configuration instructions. You can also configure the document store for high availability.
Using Load Balancing
When you deploy multiple Contacts Server front-end hosts, a load balancer (with IP-based stickiness) is necessary to distribute the load across the front-end hosts.
Planning Backup Strategies
Backing up and restoring data is one of the most important administrative tasks for your Contacts Server deployment. You must implement a backup and restore policy for your Contacts Server database to ensure that data is not lost if the system crashes, hardware fails, or information is accidentally deleted.
The two ways to back up Contacts Server data are:
-
davadmin db backup command
-
ZFS snapshots
For more information, see the backup and restore best practices topic in Contacts Server System Administrator's Guide.
Contacts Server Logical Architecture
When planning your Contacts Server logical architecture, you can use the following options:
-
Single-tiered Contacts Server architecture: You can deploy all components on a single host.
-
Two-tiered Contacts Server architecture: You can deploy Contacts Server with the front-end component installed on a separate host and the database back end installed on another host.
-
Two-tiered, multiple server Contacts Server architecture: You can install multiple front-end hosts and multiple back-end database hosts. You can also install the document store onto a separate remote host.
Sample Contacts Server Physical Architecture
Figure 2-2 shows a sample Contacts Server deployment consisting of three front-end hosts, two back-end hosts, and a load balancer to handle client requests.
Figure 2-2 Contacts Server Physical Architecture
Description of ''Figure 2-2 Contacts Server Physical Architecture''
About Installing a Secure System
You can configure Secure Sockets Layer (SSL) between the Contacts Server application server front-end hosts and database back-end hosts. You can also configure SSL between the Contacts Server application server front-end hosts and the remote document stores.
When configuring SSL between the front-end and back-end hosts, you first enable the back-end database servers for SSL by configuring either the required trustStore files or wallets. Then you configure the Contacts Server front-end hosts to connect over SSL by making use of the stored certificates.
For information about secure installation and configuration of Contacts Server, see Contacts Server Security Guide.
If you use Oracle WebLogic Server, see the discussion about performing a secure Contacts Server installation chapter in Contacts Server Security Guide.