Indexing and Search Service Deployment Planning

Skip to end of metadata
Go to start of metadata
Starting with Oracle Communications Unified Communications Suite 7.0.6, and Delegated Administrator and Calendar Server 7.0.5, the documentation for Connector for Microsoft Outlook 8.0.2, Contacts Server 8.0, Instant Messaging Server 9.0.2, Delegated Administrator, and Calendar Server 7.0.5 is available on the Oracle Documentation site at

Indexing and Search Service Deployment Planning


Planning for Various Components

When designing your Indexing and Search Service deployment architecture, you take into account the same kind of requirements you would for a Oracle Communications Unified Communications Suite deployment for the various component products of your deployment. Because Indexing and Search Service, like other Unified Communications Suite components, depends on other products, you need to think about the following components in your deployment:

  • Directory Server
  • Messaging Server
  • Java Message Queue
  • GlassFish Enterprise Server
  • Apache HTTP Server

Though you can deploy all components on a single host, or deploy a particular service's components on the same host, consider moving to a multi-host tiered architecture. A tiered architecture provides for more flexibility in tuning, upgrading, and expanding your deployment.

Indexing and Search Service requires specific versions of dependent component products. For information about the specific component product versions necessary to support ISS, see Product Version Compatibility Requirements.

Directory Server Considerations With ISS

ISS requires Directory Server for LDAP information storage. ISS is compatible with Directory Server 5.x, 6.x, and Oracle Directory Server Enterprise Edition 11gR1. The script installs the necessary LDAP schema modifications for the Unified Communications Suite products.

For more information about general Directory Server requirements for Unified Communication Suite components, see Directory Server Considerations.

Messaging Server Considerations With ISS

ISS requires at least Messaging Server 7 Update 3.

Java Message Queue Considerations With ISS

ISS requires at least Java Message Queue 4.3 for notifications services.

GlassFish Enterprise Server Considerations With ISS

ISS requires a web container in which to run. Currently, you must install GlassFish Enterprise Server 2.1 as the ISS web container.

Apache HTTP Server Considerations With ISS

In a multi-host architecture, where the web tier is running on separate systems from the indexing tier, Apache HTTP Server 2 must be installed on the systems in the indexing tier.

Firewall Requirements

If you deploy a firewall between your Messaging Server and ISS Server, you need to open an additional port on the firewall for JMQ. That is, JMQ requires two ports. For more information, see Connecting Through a Firewall.

Disk Space Requirements

ISS takes additional disk space to store its indexes. See Memory and Disk Space Requirements for more information.

ISS Logical Architecture

You can deploy ISS components on a single host or in a multi-host architecture. If you use a multi-host deployment, the logical architecture is as follows:

  • Web Tier
    • GlassFish Enterprise Server
    • ISS components: storeui (enables access to images and attachments); searchui (JMAKI interface for demo purposes); rest (RESTful API)
  • Service Tier
    • Directory Server (for JNDI lookups; most likely you would use whatever Directory Server you are currently using in your deployment)
    • Java Message Queue
  • Indexing Tier
    • Apache HTTP Server
    • ISS components: searchSvc (for searching); indexSvc (for adding new users and processing mail server events); jmqconsumer (listens to the Messaging Server Java Message Queue for events to process and sends them to indexSvc)
If you deploy ISS in a multi-host tiered architecture, you need to run the Unified Communications Suite installer multiple times to install ISS software on each zone or host. Likewise, you also need to run the ISS setup initial configuration script multiple times on each zone or host.

ISS Multi-host Architecture

The following diagram shows how to separate the ISS components across a multi-host deployment.
This figure shows shows how to separate the ISS components across a multi-host deployment.

In the preceding figure, ISS is deployed onto multiple hosts, with a front end running GlassFish Server to respond to client searches and a back end containing the indexes. When you you deploy ISS in a multi-host environment, the back end requires Apache HTTP Server.

Indexing requires significant CPU resources, thus, it is best to install the indexing service on a separate host dedicated to an ISS single server installation. If this is not an option, then install ISS on the back-end host as a single server installation, and install GlassFish Server as well for ISS.

ISS and High Availability

Indexing and Search Service provides the ability to make its search component highly available through the use of the Cluster Search Service and a highly available NFS, upon which you locate ISS indexes. When ISS search is unavailable from an ISS web node, the clients' search requests are redirected to another ISS web node that accesses the HA NFS and locates the appropriate index. Thus, the ISS search component can fail without an effective loss of the overall search functionality. Additionally, by using hardware load balancers in front of the ISS web nodes, you split the network load across these ISS front ends, increasing their availability to respond to client requests.

For more information, see Configuring Indexing and Search Service for High Availability.

indexsearchservice indexsearchservice Delete
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.

Sign up or Log in to add a comment or watch this page.

The individuals who post here are part of the extended Oracle community and they might not be employed or in any way formally affiliated with Oracle. The opinions expressed here are their own, are not necessarily reviewed in advance by anyone but the individual authors, and neither Oracle nor any other party necessarily agrees with them.