View Source

h1. Indexing and Search Service Deployment Planning


h2. 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| Common Release Information for Communications Suite 7.0.6#Product Version Compatibility Requirements].

h3. 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|Understanding Communications Suite Product Requirements and Considerations#Directory Server Considerations].

h3. Messaging Server Considerations With ISS

ISS requires at least Messaging Server 7 Update 3.

h3. Java Message Queue Considerations With ISS

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

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

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

h2. 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|].

h2. Disk Space Requirements

ISS takes additional disk space to store its indexes. See [Memory and Disk Space Requirements|Common Release Information for Communications Suite 7.0.6#Memory and Disk Space Requirements] for more information.

h2. 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)

{info:title=Note}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.{info}

h2. ISS Multi-host Architecture

The following diagram shows how to separate the ISS components across a multi-host deployment.
!CommSuite:Communications Suite Attachments^ISS Multi-Host Architecture.png|alt="This figure shows shows how to separate the ISS components across a multi-host deployment."!\\
{gliffy:name=ISS Multi-Host Architecture|space=CommSuite|page=Indexing and Search Service Deployment Planning|pageid=76417857|align=left|size=L|alt=This figure shows the logical architecture for a multiple host ISS deployment.|version=10}
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.

h2. 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].