Configuring Indexing and Search Service for clusterv2

Skip to end of metadata
Go to start of metadata

Configuring Indexing and Search Service for clusterv2 High Availability

This information describes how to configure Indexing and Search Service for high availability such that the NFS tier, on which the indexes are stored, is not exposed through your firewall. In ISS terms, this means using the clusterv2 installation type when configuring high availability. For more information on high availability in Indexing and Search Service, see Configuring Indexing and Search Service for High Availability.

This feature was introduced in Indexing and Search Service 1 Update 4.

Topics:

clusterv2 Overview

As described in Configuring Indexing and Search Service for 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 sites interested in enhanced security, the clusterv2 high availability installation type provides a solution where the NFS storage that contains the highly available indexes is protected behind the firewall. The front-end web nodes that handle the search requests are separated in front of the firewall from the searching/indexing nodes that are behind the firewall. Thus, requests to NFS are not allowed to pass through the firewall. This version of clustering uses HTTP.

clusterv2 Architecture

The following figure shows the ISS HA architecture using the clusterv2 installation type.

This figure shows the ISS high availability architecture that uses the clusterv2 configuration.

In the preceding figure, the following setup is shown:

  • GlassFish Server: Use hardware load balancers to split the network load across the Web Services front ends (the web nodes).
  • Firewall: Prevents NFS requests from coming through the front ends.
  • Search service: Use Cluster Search Service (clusterv2), which can search and maintain account state information for different dIndex repositories.
  • Indexes: Place indexes on an HA NFS to be shared to the Clustered Search Service in case the indexing host is unavailable.

Configuring clusterv2 High Availablity

This section describes how to configure ISS HA by using the clusterv2 installation type. You need to install the NFS service and the following three ISS node types in the order shown.

Topics in this section:

Before You Begin

Make sure that you have performed the following steps prior to beginning the ISS HA clusterv2 configuration:

  1. Install and configure your Messaging Server deployment (most sites already have deployed Messaging Server).
    For more information, see Communications Suite Installation Guide.
  2. Set up your HA NFS.
    Many options exist for this requirement. Choose an NFS that best suits your site's requirements.
  3. Install and configure your Indexing and Search Service deployment. For more information, see Installation Scenario - Indexing and Search Service. Note the following additional package requirements:
    • ISS Web Host: The web host needs GlassFish Server.
    • ISS Indexing Host: The indexing host needs Java Message Queue, and Directory Server (LDAP), if you don't already have a Directory Server set up to perform JNDI lookups.
      Note
      When installing ISS through the Communications Suite installer, Java Message Queue is automatically installed for each type of ISS node. You need to install GlassFish Server and Directory Server separately.

Node Types

The following table shows the different node types required for a highly available clusterv2 configuration.

clusterv2 Node Types

Node Name clusterv2 value Function Required Service(s)
Web web Provides the Restful web interface GlassFish Server
Cluster Search csearch Provides search layer (supports multiple index nodes) Java Message Queue
Index index Provides indexing and real time event processing Java Message Queue, Directory Server

To Set up NFS to Contain the ISS Indexes

Note
In case of indexing host failure, putting the indexes on NFS still provides the ability to do searches. However, the longer the indexing host is unavailable, the more risk you run of the indexes getting out of date with the store.
  1. Create a share on the NFS server, making sure that iss.user and iss.group parameters have permissions to the files on the share.
  2. Mount the share as read-write the on indexing host.
    This becomes the base directory for the {{iss.store.dir}}and {{iss.attach.dir}}parameters when configuring the index node.
  3. Mount the share as read-only on the cluster search host.
    This becomes the base directory for the iss.store.dir}}and {{iss.attach.dir}}parameters when configuring the {{cluster.d configuration file(s).

To Configure the Indexing Hosts

Perform the following steps on each ISS indexing host.

  1. If you haven't done so already, install Java Message Queue and Directory Server, which are the required services for an indexing host.
  2. Run the ISS setup script.
  3. Configure the cluster setup by responding to the following prompts.
    • iss.cluster.install: clusterv2
    • iss.cluster.type: index
    • iss.cluster.jndi.namespace: CLUSTERNAME (Can be any alphanumeric text but must be the same for all nodes.)
    • instance.name: issindex (Can be any alphanumeric text but must be unique for all nodes.)
    • iss.store.dir:NFS-BASE-DIR/index
    • iss.attach.dir: NFS-BASE-DIR/attach
    • iss.log.dir: Place logs on the local file system.
    • imq.host: Java Message Queue server (usually running on the index node)
    • jndi.type: ldap
    • ldap.host: Directory Server (usually running on the index node)
    • iss.storeui.access.method: disk
  4. Repeat the preceding setup steps for each indexing host.

To Configure the Search Hosts

  1. If you haven't done so already, install Java Message Queue, which is the required service for search hosts.
  2. Run the ISS setup script.
  3. Configure the cluster setup by responding to the following prompts.
    • iss.cluster.install: clusterv2
    • iss.cluster.type: csearch
    • iss.cluster.jndi.namespace: CLUSTERNAME (Can be any alphanumeric text but must be the same for all nodes.)
    • instance.name: isscsearch (Can be any alphanumeric text but must be unique for all nodes.)
    • iss.store.dir: Accept default value, is not used.
    • iss.attach.dir: Accept default value, is not used.
    • imq.host: Java Message Queue Server (usually running on the cluster search node)
    • iss.storeui.access.method: http
  4. Create the cluster configuration file for the index node, basedir/etc/cluster.d/iss1.conf.
    1. On the index node run the following command:
    2. Copy the iss1.conf file to the cluster search node's basedir/etc/cluster.d/iss1.conf file.
    3. Update the iss.store.dir parameter to NFS-BASE-DIR/index.
    4. Update the iss.attach.dir parameter to NFS-BASE-DIR/attach.
  5. Run the following command.
  6. Run the following command.

To Configure the Web Hosts

  1. If you haven't done so already, install GlassFish Server, which is the required service for web hosts.
  2. Configure the clusterv2.conf file:
    • Edit the_basedir_/etc/cluster.d/clusterv2.conf as follows:
      • instance.name: Comma delimited list of index instance names, for example, issindex
      • imq.host: Comma delimited list of cluster search Java Message Queue hosts, for example, csearch.example.com:7676
    • Change the ownership of the clusterv2.conf file:
  3. Run the ISS setup script.
  4. Configure the cluster setup by responding to the following prompts.
    • iss.cluster.install: clusterv2
    • iss.cluster.type: web
    • iss.cluster.jndi.namespace: CLUSTERNAME (Can be any alphanumeric text but must be the same for all nodes.)
    • instance.name: issweb (Can be any alphanumeric text but must be unique for all nodes)
    • iss.store.dir: Accept the default value, it is not used.
    • iss.attach.dir: Accept the default value, it is used.
    • imq.host: Java Message Queue server running on the cluster search node.
    • iss.storeui.access.method: http

Troubleshooting

This section contains common problems and their solutions for installing and configuring clusterv2 high availability.

Topics in this section:

GlassFish Server (Web Node) Log Contains "cannot find cn=CommsQueueFactory, cn=CommsTopicFactory, or cn=SearchTopic"

This indicates there is a problem setting up the local JNDI information. Check the following settings:

  • The /etc/jiss/cluster.d/clusterv2.conf file is present.
  • Run basedir/bin/csearchmgr.sh -A.
  • Run basedir/bin/factorymgr.sh -l, the output should be the following:
    Listing all administered objects in the object store specified by: 
     
     java.naming.factory.initial com.sun.jndi.fscontext.RefFSContextFactory 
     java.naming.provider.url file:/etc/jiss/jms 
     
     Lookup Name Object Class Name 
     cn=CommsQueueFactory com.sun.messaging.QueueConnectionFactory 
     cn=CommsTopicFactory com.sun.messaging.TopicConnectionFactory 
     cn=IndexXXXX com.sun.messaging.Queue 
     cn=SearchTopic com.sun.messaging.Topic 
     
     Objects listed successfully.
    

Where IndexXXXX is the instance name from the clusterv2.conf file.

Searching Rest Interface Always Returns 404 Error

If you receive this error, check the following items:

  • Make sure that the cluster search service is running on the cluster search node.
  • View the GlassFish Server log on the web node while updating the state on the indexing node by running the issadmin.sh --setstate A --user command.
  • View the cluster search log on the cluster search node while updating the state on the indexing node by running the issadmin.sh --setstate A --user command.
Labels:
ha ha Delete
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.