Full-Text Multi Node Install 6.5

EMC® Documentum®
Content Server
Version 6.5
Multinode Fulltext Indexing Installation Guide

P/N 300007201A01
EMC Corporation
Corporate Headquarters:
Hopkinton, MA 01748‑9103
1‑508‑435‑1000
www.EMC.com
Copyright © 1994 ‑ 2008 EMC Corporation. All rights reserved.
Published July 2008
EMC believes the information in this publication is accurate as of its publication date. The information is subject to change
without notice.
THE INFORMATION IN THIS PUBLICATION IS PROVIDED AS IS. EMC CORPORATION MAKES NO REPRESENTATIONS
OR WARRANTIES OF ANY KIND WITH RESPECT TO THE INFORMATION IN THIS PUBLICATION, AND SPECIFICALLY
DISCLAIMS IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Use, copying, and distribution of any EMC software described in this publication requires an applicable software license.
For the most up‑to‑date listing of EMC product names, see EMC Corporation Trademarks on EMC.com.
All other trademarks used herein are the property of their respective owners.
Table of Contents
Preface ........................................................................................................................... 7
Chapter 1 Understanding Multinode Deployments ................................................. 9

Distributing index server processes across nodes .......................................... 10
Distributing documents across nodes ........................................................... 12
Installing the index server in a multinode configuration ................................ 14
Chapter 2 Creating the InstallProfile.xml Configuration File .................................. 17

Host section ............................................................................................... 18
Administrative services section ................................................................... 19
Content distributor section .......................................................................... 21
Status server section ................................................................................... 21
Search engine section .................................................................................. 22
Document processor section ........................................................................ 23
Query server section ................................................................................... 24
Webcluster section ...................................................................................... 25
Other sections ............................................................................................ 26
Chapter 3 Installing the Indexing Software ............................................................ 29

Installing a multinode configuration ............................................................ 29
Configuring the index agent ........................................................................ 31
Modifying the indexagent.xml file to map file stores ................................. 33
Configuring directed routing....................................................................... 34
Creating fulltext collections ..................................................................... 35
Mapping file stores to collections ............................................................. 36
Mapping collections to index columns ..................................................... 38
Adding a node ........................................................................................... 39
Removing a node........................................................................................ 42
Backing up and restoring an index .............................................................. 43
Uninstalling a Multinode Indexing Configuration......................................... 43
EMC Documentum Content Server Version 6.5 Multinode Fulltext Installation Guide 3
Table of Contents
List of Figures
Figure 1. Multinode configuration with three nodes ....................................................... 11

Figure 2. Multinode configuration using round‑robin distribution ................................... 12
Figure 3. Multinode configuration using directed routing ............................................... 13
Figure 4. The first available document processor handles each incoming
document................................................................................................... 23
Figure 5. Mapping file stores to collections to index columns........................................... 35
4 EMC Documentum Content Server Version 6.5 Multinode Fulltext Installation Guide
Table of Contents
List of Tables
Table of Contents
Preface
Purpose of the manual

This manual contains information and instructions you need to install a multinode
fulltext indexing system. It provides step‑by‑step instructions for installing and
configuring the software.
Intended audience
The intended audience for this document is EMC Documentum Professional Services
and partners who are certified by EMC to support multinode fulltext implementations.
Before installing a multinode configuration, a customer needs to have its proposed
architecture reviewed and approved by EMC. Contact your Account Manager to arrange
for a review.
Related documentation
• The EMC Documentum Fulltext Indexing System Installation and Administration Guide
contains detailed information on installing the index agent and index server in basic,
consolidated, and high availability deployments, as well as describing indexing
operations and maintenance.
• The EMC Documentum Search Development Guide contains complete information on
querying.
• The Content Server Installation Guide contains information on installing Content
Server.
• The Documentum Administrator online help system contains instructions for
managing the index queue and for starting and stopping the index server and index
agent, in basic, consolidated, and high‑availability deployments. No Documentum
Administrator support is provided for multinode deployments.
Revision history
The following revisions have been made to this document:
Preface
Revision History
Date Description
July 2008 Publication for version 6.5
Chapter 1
Understanding Multinode Deployments
In a basic fulltext indexing scenario, a single index server adds all index information to a single index,
and all queries return results from that index. In a large implementation with a high volume of
documents to index, concentrating all of this activity on a single host machine can negatively impact
performance. The delay between when a new document is added to the repository and when its
content is available for fulltext searches may become unacceptably long.
To improve performance, you can install multiple indexing processes, each one managing a distinct
portion of the index on a distinct host machine. This distributed configuration improves performance
by enabling parallel index processing. Each host machine is referred to as a node, and the distributed
configuration is referred to as a multinode implementation.
This chapter provides conceptual information about installing the index server in a multinode
configuration. It includes these topics:
• Distributing index server processes across nodes, page 10
• Distributing documents across nodes, page 12
• Installing the index server in a multinode configuration, page 14
Note: All hosts in a multinode implementation need to use the same operating system platform. For
best performance, it should be the same operating system as the Content Server host, however this
is not required.
Distributing index server processes across

nodes
The index server consists of five groups of processes that have different functions. In a
basic, single‑node configuration, these processes all run on the same host machine. In a
multinode configuration, these processes are run on different host machines to improve
performance. The processes are:
• Administrative services
The index server’s administrative services include the Status Server, which monitors
the progress of a document through the index server’s internal processes, and the
Content Distributor, which accepts documents from the index agent and routes them
to a document processor for indexing.
• Document processors
Document processors extract indexable content from content files, convert DFTXML
to FIXML (the format that is used by the indexer), and pass the FIXML to the indexer.
Document processors are the largest consumer of CPU power in the index server.
• Indexers
Indexers create the searchable fulltext index entries from the intermediate FIXML
format.
• Query and Results Server
The Query and Results Server (QR Server) accepts queries from Content Server and
passes them on to the search server(s). In a multinode configuration, each node has a
search server that returns the search results for that node, and the QR Server merges
the results before returning them to Content Server.
• Search servers
Search servers locate items in the index as specified in a query.
In a multinode implementation, each node runs the processes necessary to index
documents and run queries against the index; that is, each node runs an instance of an
indexer and a search server. In a common configuration, each node also runs a document
processor. Each node manages a portion of the complete fulltext index, containing
entries for a unique subset of the documents in the repository. Each separate portion of
the index is referred to as a column.
Figure 1. Multinode configuration with three nodes
The number of nodes depends on the required indexing and querying throughput. You
can add additional nodes as necessary to increase indexing and querying capacity.
The index server’s administrative processes are installed on just one node, referred to as
the administrative node. (Node 1 is the administrative node in Figure 1.) The index agent,
which provides communication with Content Server, is installed on the administrative
node or on the Content Server host.
As documents are added to the repository and need indexing, the index agent passes
the documents to the Content Distributor on the administrative node. The Content
Distributor determines on which node each document will be indexed and routes the
documents to a document processor. The document processor extracts the indexable
content then routes the FIXML representation of the document to the indexer on the
proper node. The indexer updates the column on the indexer’s node.
Note: Figure 1 shows a common configuration with one document processor on each
node. However, there is no special relationship between the document processor and
indexer on the same host machine. The Content Distributor routes documents to the first
available document processor regardless of which node the document is ultimately
targeted for. The document processor passes the document to the indexer on the proper
node. See Document processor section, page 23 for more information about document
processor configuration options.
When Content Server sends a query to the index server, the index server needs to return
the matching results from all columns. The Query and Results Server (QR Server) on
the administrative node issues the query to the search servers on each node. The search
servers run in parallel and return their results to the QR Server. The QR Server collects
and combines the results before returning them to the Content Server.
Distributing documents across nodes

The Content Distributor on the administrative node determines which node processes a
given document that has been submitted for indexing. By default, it routes documents
to nodes in a round‑robin fashion. For example, if there are four nodes, the first object
is directed to the first node, the second to the second node, and so on, with the fifth
object directed to the first node.
This basic multinode configuration ensures that each index column contains
approximately the same number of entries, which maximizes the benefit of the parallel
indexing and search processing. However, the round‑robin processing means that all
nodes are equally active, which makes it difficult to manage the nodes individually. For
example, to back up the fulltext index, you need to back up all index columns. If you add
an additional node, you need to rebalance the index to ensure that the data is properly
balanced across nodes (see Adding a node, page 39 for details).
Figure 2. Multinode configuration using roundrobin distribution
Alternatively, you can configure the Content Distributor to use directed routing. Directed
routing is a means of distributing documents to specific index server nodes based on
which Content Server file store contains their content files. (File stores are the most
common type of storage area in a Documentum repository.) Each Content Server file
store is mapped to a specific index column; when the Content Distributor receives a
document to index, it routes the document to the node associated with the document’s
file store.
Content Server enables you to assign content files to specific file stores based on
user‑specified parameters. For example, you can instruct Content Server to store
documents in particular file stores based on their type (marketing documents in one file
store, engineering documents in another) or on when they were created (documents
checked in from January 1 through June 30 in one file store, those checked in from July 1
to December 31 in another). The time‑based option can be beneficial in archiving and
other high‑volume indexing scenarios. With directed routing, you can divide the fulltext
index along the same lines as the content files.
Figure 3. Multinode configuration using directed routing
Using directed routing provides these advantages:
• You can add file stores and index nodes as needed, with little or no need to
reorganize the index data.
When you add a node to an implementation using round‑robin distribution, the
index server needs to rebalance the data across nodes. With directed routing, the
index server can begin routing documents to a new node without rebalancing
existing index entries.
• You can close index nodes either temporarily or permanently.
A particular node can become inactive for indexing purposes, for example once the
end date is passed and documents begin to be routed to a new file store. The node
remains active for searching but receives no new entries. You can back up such nodes
when they are closed off, and they need not be backed up from that point forward.
From an implementation perspective, the mapping from specific file stores to specific
index columns occurs in two steps. The index agent configuration file (indexagent.xml)
assigns files from specific file stores to specific collections, and a configuration file on the
index server administrative node (routing.cfg) assigns specific collections to specific
index columns. See Configuring directed routing, page 34 for details about configuring
directed routing.
Installing the index server in a multinode

configuration
You install the index server in a multinode configuration by running the index server
installation program on the host machine for each node. The installation program
refers to a configuration file named InstallProfile.xml to determine which index server
processes to install on the current host.
The major steps required to install the index server in a multinode configuration are:
1. Create a single, global copy of the InstallProfile.xml configuration file that defines the
complete configuration.
The InstallProfile.xml file lists the host machines for each node and specifies
which index server processes to install on each host. See Chapter 2, Creating the
InstallProfile.xml Configuration File.
2. Run the index server installation program on each host machine, as described in
Installing a multinode configuration, page 29.
3. Install an index agent to provide communication with Content Server.
The index agent is usually installed on the host machine where the index server’s
administrative processes are running, or on the Content Server host. See Configuring
the index agent, page 31.
4. If you plan to use directed routing, configure the index agent and index server to
provide the desired mapping of documents to index columns.
See Configuring directed routing, page 34.
Chapter 2
Creating the InstallProfile.xml
Configuration File
The InstallProfile.xml configuration file is an XML file that controls which index server components
are installed on each node of a multinode deployment. Before beginning the installation, you create
a single, global copy of InstallProfile.xml that defines the complete configuration. The index server
installation program refers to the file as it installs each node.
To create the InstallProfile.xml file for your implementation:

1. Copy the sample InstallProfile.xml file for the platform on which you plan to install
the index server.
Refer to Support Note esg90092 for the sample InstallProfile.xml files. The
sample files are named for each platform: InstallProfileWindows.xml,
InstallProfileSolaris.xml, InstallProfileLinux.xml. Save the file for your platform as
InstallProfile.xml, and modify the saved copy of the file. Ensure that you retain a
backup copy of the modified file.
2. Open the file in a text editor and make the changes described in this chapter.
The file contains separate sections, several of which contain parameters defining the
particulars of the configuration. This chapter covers each of the sections separately,
describing the purpose of the section and identifying the values you need to update.
Note: Do not change the property names or IDs found in the file. The sections below
discuss which parameter values you may change; leave the remaining content
unchanged.
3. Save the file with the name InstallProfile.xml.
You will make an exact copy of this file for each index server node you install, as
described in Installing a multinode configuration, page 29.
Creating the InstallProfile.xml Configuration File
Host section
The host section of the InstallProfile.xml configuration file identifies the hosts in the
multinode deployment and defines some basic configuration parameters for each host.
To complete this section, you need the following information:
• The fully‑qualified domain name for each host computer
For example, tristan.documentum.com, not tristan.
• The platform on which the indexing software will be installed
There is a sample IndexProfile.xml file for Windows, Linux, and Solaris (= Sun OS).
• The installation owner’s user name
This is the same user as the Content Server installation owner. Ensure that you use
the same domain or NIS user account for installing each index server node as you
used for installing Content Server. The user IDs need to match.
• The installation directory
The defaults are drive\Documentum\fulltext\IndexServer\ on Windows and
/fulltext/IndexServer/ (under $DOCUMENTUM) on Linux and UNIX. Since all host
computers use the same InstallProfile.xml file, ensure that you use the same drive
letter or mount‑point specification on all index server nodes.
• The host’s temporary directory
The defaults are C:\temp on Windows and /tmp/ on Linux and UNIX.
• The base index server port
The default is 13000. Use the same base port on all nodes in the multinode
deployment.
Below is a sample of the host section for a Windows installation in
which there are two hosts (norway1.performance.documentum.com and
norway2.performance.documentum.com), with user name dmadmin, installation
directory of F:\Documentum\fulltext\IndexServer\, temporary directory of :
C:\Temp\, remote command of SSH2, and base port of 13000:
<hostset>
<host id="norway1.performance.documentum.com">
<property name="hostname" value="norway1.performance.
documentum.com"/>
<property name="platform" value="Windows"/>
<property name="username" value=".\dmadmin"/>
<property name="installdir" value="F:\Documentum\
fulltext\IndexServer\"/>
<property name="tempdir" value="C:\Temp\"/>
<property name="remotecmd" value="SSH2"/>
<property name="baseport" value="13000"/>
</host>
<host id="norway2.performance.documentum.com">
<property name="hostname" value="norway2.
performance.documentum.com"/>
<property name="platform" value="Windows"/>
<property name="username" value=".\dmadmin"/>
<property name="installdir" value="F:\Documentum
\fulltext\IndexServer\"/>
<property name="tempdir" value="C:\Temp\"/>
<property name="baseport" value="13000"/>
</host>
</hostset>
The items you should update with the details for your configuration are shown below in
italic font. Do not change any other values, such as the remote‑cmd property or its value.
Add an additional <host> section for each host in the configuration, following the pattern
shown below. All <host> sections need to appear inside the <host‑set> element.
Note: On Windows hosts, the value of the property username needs to start with a period
and backslash, for example, .\dmadmin. On UNIX hosts, the value would be dmadmin.
<hostset>
<host id="Fully_qualified_host_name">
<property name="hostname" value=
"Fully_qualified_host_name"/>
<property name="platform" value=
"platform"/>
<property name="username" value=
"installation_owner_name"/>
<property name="installdir" value=
"installation_directory"/>
<property name="tempdir" value=
"temporary_directory"/>
<property name="baseport" value=
"base_port_number"/>
</host> </hostset>
Administrative services section

The administrative services section identifies which host will server as the administrative
node and the index server components that are installed on the administrative node of
the multinode deployment. To complete this section, you need the following information:
• The fully‑qualified name of the host where the administrative node will be installed
• The installation owner’s user name and password
Below is a sample of the administration section of the InstallProfile.xml file, in
which norway1.performance.documentum.com is identified as the host where the
administrative services are installed:
<administrationset>
<configurationservice id="CS1" hostref="norway1.
performance.documentum.com">
</configurationservice>
<logservice id="LGS1" hostref="norway1.performance.
documentum.com"></logservice>
<administrationgui id="ADM1" hostref="norway1.
performance.documentum.com"></administrationgui>
<vespa id="VSP1" hostref="norway1.performance.
documentum.com"></vespa>
<storageservice id="STOR1" hostref="norway1.
performance.documentum.com" admin="root" adminpassword=
"d4tAs34rch" user=“dmadmin" userpassword=“d3v3l0p">
</storageservice>
<nameservice id="NAME1" hostref="norway1.
</nameservice>
</administrationset>
italic font. Do not change any other values; for example, do not change the admin user
name and admin password in the <storage‑service> element.
Note: On Windows hosts, the value of the property user needs to start with a period and
backslash, for example, .\dmadmin. On UNIX hosts, the value would be dmadmin.
<administrationset>
<configurationservice id="CS1" hostref=
"Fully_qualified_host_name">
</configurationservice>
<logservice id="LGS1" hostref=
</logservice>
<administrationgui id="ADM1" hostref=
</administrationgui>
<vespa id="VSP1" hostref=
</vespa>
<storageservice id="STOR1" hostref=
"Fully_qualified_host_name"
admin="root"
adminpassword="d4tAs34rch"
user=“install_owner_name"
userpassword=“install_owner_password">
</storageservice>
<nameservice id="NAME1" hostref=
</nameservice>
</administrationset>
Content distributor section

The content distributor section of the InstallProfile.xml file identifies the host on which
the content distributor service runs. This is typically the administrative node, which is
the node you identified in the Administrative services section, page 19. To complete
this section, you need to know the fully‑qualified name of the computer where the
administrative services are installed.
Below is a sample of this section, in which the content distributor is running on a host
called norway1.performance.documentum.com:
<contentdistributorset>
<contentdistributor id="CD1" hostref="norway1.
</contentdistributorset>
The item you should update with the details for your configuration is shown below in
italic font.
<contentdistributorset>
<contentdistributor id="CD1" hostref=
"Fully_qualified_host_name"/>
</contentdistributorset>
Status server section

The status server section identifies the host where the status server is installed. This is
typically the administrative node, which is the node you identified in the Administrative
services section, page 19. To complete this section, you need to know the fully‑qualified
name of the computer where the administrative services are installed.
Below is an example of this section, in which the status server is running on a host called
norway1.performance.documentum.com:
<statusservice>
<statusserver id="STATUS1" hostref="norway1.
</statusserver>
</statusservice>
The item you should update with the details for your configuration is shown below in
italic font.
<statusservice>
<statusserver id="STATUS1" hostref=
</statusserver>
</statusservice>
Search engine section

The search engine section identifies the hosts on which the indexers and search servers
are installed. Install both components on each host in the multinode deployment.
To complete this section, you need to know the fully‑qualified names of the computers in
the deployment. You provided these names in the Host section, page 18.
Below is a sample of this section, in which the indexer and search server
are running on hosts called norway1.performance.documentum.com and
norway2.performance.documentum.com:
<searchengineset>
<searchengine id="RTS1" hostref="norway1.
<property name="search" value="true"/>
<property name="index" value="true"/>
</searchengine>
<searchengine id="RTS2" hostref="norway2.
</searchengine>
</searchengineset>
italic font. Do not change any other values. Do not change the property names indicating
that the search server and indexer are installed or change the value true.
Add an additional <search‑engine> section for each host in the configuration, following
the pattern shown below. All <search‑engine> sections need to appear inside the
<search‑engine‑set> element.
<searchengineset>
<searchengine id="RTS1" hostref=
"Fully_qualified_host_name1">
</searchengine>
<searchengine id="RTS2" hostref=
"Fully_qualified_host_name2">
</searchengine>
</searchengineset>
<searchengine id="RTSN" hostref=
"Fully_qualified_host_nameN">
</searchengine>
</searchengineset>
Document processor section

The document processor section of the InstallProfile.xml file defines the hosts on which
document processors are installed. To complete this section, you need to know the
fully‑qualified names of the computers in the deployment. You provided these names in
the Host section, page 18.
Below is a sample in which the document processors are running on hosts called
norway1.performance.documentum.com and norway2.performance.documentum.com:
<documentprocessorset>
<documentprocessor id="DP1" hostref="norway1.
<documentprocessor id="DP2" hostref="norway2.
</documentprocessorset>
A common configuration, such as that shown in Figure 1, page 11, has one document
processor on each host. However, you can install multiple document processors on
the same host or install one or more document processors on host separate from the
nodes where the indexers and columns reside. When the Content Distributor routes a
document, it routes it to the first non‑busy document processor, regardless of which host
the document processor is running on. The document processor passes the document to
the proper indexer.
Figure 4. The first available document processor handles each incoming document
italic font. Do not change any other values.
Add an additional <document‑processor> section for each document processor you want
to create, following the pattern shown below. All <document‑processor> sections need
to appear inside the <document‑processor‑set> element. All host names need to match
hosts listed in the Host section, page 18.
<documentprocessorset>
<documentprocessor id="DP1" hostref=
"Fully_qualified_host_name1"/>
<documentprocessor id="DP2" hostref=
"Fully_qualified_host_name2"/>
<documentprocessor id="DPN" hostref=
"Fully_qualified_host_nameN"/>
</documentprocessorset>
Query server section

The query server section of the InstallProfile.xml file defines the host on which the Query
and Results Server is installed. This is typically the administrative node, which is the
node you identified in the Administrative services section, page 19. of the multinode
deployment. Do not install more than one Query and Results Server.
The section also specifies which linguistic rules are used to process search queries
and which language dictionaries are installed. The default‑language property sets the
(single) language whose linguistic rules are used to perform grammatical normalization,
spell‑checking, and so on. The languages property sets the list of languages whose
dictionaries are installed.
To complete this section, you need to know the fully‑qualified name of the computer
where the administrative services are installed and the two‑character language codes
for the languages you want to enable. For a list of the available language codes, see the
Content Server Fulltext Indexing Installation and Administration Guide.
Below is an example in which the Query and Results Server is running on a host called
norway1.performance.documentum.com, the default language is English (en), and the
English and French (fr) dictionaries are installed:
<queryresultprocessorset>
<queryresultprocessor id="QRP1" hostref="norway1.
<property name="defaultlanguage" value="en"/>
<property name="languages" value="en,fr"/>
</queryresultprocessor>
</queryresultprocessorset>
italic font. If you include multiple language codes for the language property, separate
them with commas.
<queryresultprocessorset>
<queryresultprocessor id="QRP1" hostref=
<property name="defaultlanguage" value=

"language_code"/>
<property name="languages" value=
"language codes"/>
</queryresultprocessor>
</queryresultprocessorset>
Webcluster section
The webcluster section defines which index columns are associated with which search
engines.
The Search engine section, page 22 provides an ID for the search engine running on
each host (as the value of the id parameter of the <search‑engine> element). They have
sequential names based on which node they are running on: RTS1 for node 1, RTS2 for
node 2, and so on. The webcluster section identifies the index columns and associates
each column with the search engine running on the same node. The IDs for the columns
are also sequential, however the numbering starts at zero. Therefore, as shown in the
sample below, column 0 is associated with search engine RTS1, column 1 is associated
with search engine RTS2, and so on.
<searchengineclusterset>
<searchenginecluster id="webcluster">
<property name="usememsearch" value="false"/>
<property name="indexprofiletype" value="custom"/>
<property name="indexprofilefilename"
value="..\config\datasearch\indexprofiles
\indexprofiledctm.xml"/>
<searchenginecolumn id="col0">
<searchengine idref="RTS1"/>
</searchenginecolumn>
<searchengine idref="RTS2"/>
<queryresultprocessors>
<queryresultprocessor idref="QRP1"/>
</queryresultprocessors>
</searchenginecluster>
</searchengineclusterset>
The items you should update with the details for your configuration are shown below
in italic font. Do not modify anything else in the webcluster section. Do not change the
value of the index‑profile‑type. It needs to remain “custom.”
Add an additional <search‑engine‑column> section for each host in the configuration,
following the pattern shown below. All <search‑engine‑column> sections need to appear
inside the <search‑engine‑cluster> element. The value of the <search‑engine‑column id>
needs to be the string “col” followed by the next sequential number after the previous
column. The number needs to match the partition_id for the column as specified in the
CSConfig.xml file; see Adding a node, page 39.
The value of the <search‑engine id‑ref> property for each node needs to match the
value specified for that host in the Search engine section, page 22. Similarly, the value
of <query‑result‑processor id‑ref> needs to match the ID provided in the Query server
section, page 24.
<searchengineclusterset>
<searchenginecluster id="webcluster">
<property name="usememsearch" value="false"/>
<property name="indexprofiletype" value="custom"/>
<property name="indexprofilefilename"
value="..\config\datasearch\indexprofiles
\indexprofiledctm.xml"/>
<searchengine idref=
"searchengine ID for node 1"/>
<searchengine idref=
"searchengine ID for node 2"/>
<queryresultprocessors>
<queryresultprocessor idref="QR Server ID"/>
</queryresultprocessors>
</searchenginecluster>
</searchengineclusterset>
Other sections
The configuration file also contains data‑source, anchor‑service, status‑service, and
license‑services sections. Do not modify the data‑source section. In the anchor‑service,
status‑service, and license‑service sections, provide the fully‑qualified name of the
administrative node, which is the node you identified in the Administrative services
section, page 19. Do not modify any other values.
<anchorservice>
<anchorserver id="anch1" hostref="Fully_qualified_host_name">
<property name="dispatcher" value="true"/>
</anchorserver>
</anchorservice>
<statusservice>
<statusserver id="STATUS1" hostref="Fully_qualified_host_name">
</statusserver>
</statusservice>
<licenseservices>
<licenseservice id="LCS1" hostref="Fully_qualified_host_name">
</licenseservice>
</licenseservices>
Chapter 3
Installing the Indexing Software
This chapter contains instructions for installing a multinode indexing deployment and configuring it
to use directed routing. It contains the following topics:
• Installing a multinode configuration, page 29
• Configuring the index agent, page 31
• Configuring directed routing, page 34
• Adding a node, page 39
Installing a multinode configuration

Before installing the software for a multinode configuration, review the information
in Chapter 2, Creating the InstallProfile.xml Configuration File and create an
InstallProfile.xml configuration file suitable for your deployment.
To install a multinode configuration:

1. Log on as the Content Server installation owner to the host machine that will serve
as the administrative node.
The administrative node is identified in the Administrative services section, page
19 of the InstallProfile.xml file. It is the host identified by the <configuration‑service>
element.
2. Download the software distribution package for the correct platform to a temporary
area on the host machine.
3. Unzip or untar the software distribution package.
4. Copy the InstallProfile.xml configuration file you created to the same temporary area.
See Chapter 2, Creating the InstallProfile.xml Configuration File for details about
creating the file.
5. Run the index server installation program.
• On Windows, double‑click fulltextWinSuiteSetup.exe.

• On UNIX and Linux, type
% fulltextoperatingsystemSuiteSetup.bin
and press Enter, where operatingsystem is the operating system on which you
are installing.
6. Select index server installation only.
The installation program detects the InstallProfile.xml file and asks you to confirm
that you require multinode installation.
7. Click Yes.
The correct index server processes are installed and configured on the host.
8. After the installation is completed, ensure that the index server starts.
• On Windows, select Yes, restart my computer., then click Next.
— If the computer does not restart automatically, click
Start®®Shutdown® ®Restart and restart the computer manually.
— If the index server does not automatically start, click
Start®®Programs® ®Administrative Tools® ®Services and start the
FAST InStream service.
— If the system restarts, the index server starts automatically as a Windows
service.
• On UNIX and Linux, run $DOCUMENTUM/fulltext/jboss4.2.0/IndexServer/
bin/startup.sh.
The index server is started.
9. Install and configure an index agent.
See Configuring the index agent, page 31 for instructions.
10. To configure directed routing, perform the steps described in Configuring directed
routing, page 34 on the administrative host.
11. Repeat steps 1 through 8 on each additional node.
12. Confirm that the index server processes are running correctly.
• On the administrative node, type dsadmin listmodules at a command prompt.
The running processes, their version numbers, host name, and port numbers
are displayed.
• On each nonadministration node, use the nctrl command to verify that the
processes are running correctly:
$ cd $FASTSEARCH/bin
$ ../setupenv.sh
$ nctrl sysstatus
Each running module name is listed, as well as the process name, process ID,
and status.
Configuring the index agent

The index agent configuration program configures the index agent to process documents
for a particular repository and to pass the documents to the correct index server instance
for indexing.
By default, the index agent automatically starts when the configuration program
completes. You do not want the index agent to start automatically when installing a
multinode implementation, because there may be additional configuration steps that
need to be completed before the index agent starts. (See Modifying the indexagent.xml
file to map file stores, page 33 and Configuring directed routing, page 34.) The procedure
below includes steps to prevent the index agent from starting automatically.
To configure the index agent:

1. Log on to the host machine as the Content Server installation owner.
element.
2. Ensure that the index server is running.
3. Navigate to the directory %DOCUMENTUM_SHARED\IndexAgents (on Windows)
or $DOCUMENTUM_SHARED/IndexAgents (on UNIX).
4. Use a text editor to create a file named setup.ini with these two lines as its content:
[INDEX_AGENT]
AUTO_START_INDEX_AGENT=false
5. Start the index agent configuration program using the appropriate command for
your platform.
• Windows: IndexAgent_Configuration_Program.exe –config setup.ini
• AIX: IndexAgent_Configuration_Program.aix –config setup.ini
• Solaris: IndexAgent_Configuration_Program.bin –config setup.ini
• HP‑UX: IndexAgent_Configuration_Program.hp –config setup.ini
• On Linux, IndexAgent_Configuration_Program.linux –config setup.ini

A Welcome dialog box is displayed.
6. Click Next.
7. On Windows, type in the installation owner’s password, then click Next.
8. Type in the port used to communicate with application server for administration
purposes, then click Next.
The default port, 9200, is for the first index agent on the host. The default port for
any other index agents are 9220 for index agent 2, 9240 for index agent 3, and so on.
9. Select the repository for which the index agent will prepare documents, then click
Next.
The drop‑down list contains the repositories that project to the connection brokers
listed in the dfc.properties file on the host.
10. Type in the user name and password for the Superuser account that the index agent
will use to connect to the repository.
11. Indicate whether to run the index agent in normal mode or migration mode.
12. Type in the host where the index server for this index agent is running and the base
port number for the index server, then click Next.
A summary dialog box is displayed.
13. Click Next.
14. To exit from the configuration program, click Finish.
15. To complete the installation process:
• If you are mapping the file stores, complete the instructions in Modifying the
indexagent.xml file to map file stores, page 33.
• If you are using directed routing, complete the instructions in Configuring
directed routing, page 34.
16. On Windows, to start the index agent manually, start the IndexAgent service to
start IndexAgent instance.
On Linux, to start the index agent manually, run $DOCUMENTUM_SHARED/
jboss4.2.0/server/startIndexAgent1.sh.
Modifying the indexagent.xml file to map file stores

If you have shared or mounted the drives containing the repository’s file stores and
installed the indexing software, the index agent configuration file needs to be manually
edited to indicate that the drives are shared. The changes depend on whether the file
system paths to the content are identical on the Content Server host and index server host.
Using shared or mounted drives improves performance, because the index agent does
not need to copy documents from Content Server to a staging area. See the Documentum
Content Server Fulltext Indexing System Installation and Administration Guide for more
information about sharing file store drives.
To modify the indexagent.xml file and map the file stores:

1. On the index agent host, navigate to C:\Documentum\jboss4.2.
0\server\DctmServer_IndexAgent1\deploy\IndexAgent1.war\WEB‑INF\classes
(on Windows) or $DOCUMENTUM_SHARED/jboss4.2.0/server/DctmServer_
IndexAgent1/deploy/
IndexAgent1.war/WEB‑INF/classes (on UNIX).
If you installed multiple index agents on this host, replace the number 1 in these
paths with the appropriate index agent number.
2. Open the indexagent.xml file in a text editor.
3. If the paths to the content files are identical on the Content Server host and index
server host, locate the <exporter></exporter> element and change the value of the
<all_filestores_local> element to true:
<all_filestores_local>true</all_filestores_local>
4. If the paths to the content files are different, do not modify the value of
<all_filestores_local>, but instead, create a file store map within the <exporter>
element.
For example, if Content Server is on a host called Dandelion where filestore_01
is physically located in the directory /Dandelion/Documentum/data/
repository_name/content_storage_01 and the index agent and index server
on a host from which the drive on the Content Server host is shared as
/mappingtoDandelion/repository_name/content_storage_01, create an alias as follows:
<local_filestore_map>
<local_filestore>
<store_name>filestore_01</store_name>
<local_mount>/mappingtoDandelion/
repository_name
/content_storage_01</local_mount>
</local_filestore>
<! and so on for each filestore !>
</local_filestore_map>
If you are indexing content stored on a NAS device or a Windows 2003 Server host,
you may see the following error message in the dmi_queue_item’s message attribute:
DocumentRetriever :ERROR Retrieval error: Couldn't open file
<file path/name> ERROR Processor error status:
DataNotAvailable Not read permission
To resolve this error, edit the <local_mount> element or elements in the
IndexAgent.xml file that reference the storage area or areas on the NAS device.
Add two backslashes immediately after the opening <local_mount> element. For
example, assume the following references a storage are on an NAS device:
<local_mount>\\100.2.4.32\share3\c\data_for_example
\content_storage_1</local_mount>
After editing, it is now:
<local_mount>\\\\100.2.4.32\share3\c\data_for_example
\content_storage_1</local_mount>
5. Save the indexagent.xml file.

6. Restart the index agent.
Configuring directed routing

Directed routing is a means of distributing documents to specific index server nodes
based on which Content Server file store contains their content files; see Distributing
documents across nodes, page 12 for a conceptual overview.
There are four major steps involved in configuring directed routing:
1. Configure Content Server to direct documents to specific file stores based on business
rules. See “Allocating content to storage areas” in the Content Server Administration
Guide for information about creating content assignment policies.
2. Create a fulltext collection corresponding to each index server node. See Creating
fulltext collections, page 35.
3. Update the index agent configuration file (indexagent.xml) to associate particular
file stores with particular fulltext collections. See Mapping file stores to collections,
page 36.
4. Create a routing configuration file on the index server administrative node to
associate each collection with an index column. See Mapping collections to index
columns, page 38.
Figure 5. Mapping file stores to collections to index columns
Creating fulltext collections

All documents submitted for indexing are assigned to a collection, which is a logical
set of data to which the index server applies the same indexing rules. In a basic
implementation, all documents are typically assigned to a single default collection that is
created automatically as part of the index server installation process.
With directed routing, you want the index server to treat documents differently
depending on which file stores contain their content files — specifically, you want the
index server to route them to different nodes for inclusion in different columns. To
enable the index server to route documents to different nodes, you need to assign the
documents to different collections.
The first step is to create additional collections. You create one collection for each node.
To create a fulltext collection:

1. Log on to the administrative node as the Content Server installation owner.
element.
2. Enable access to the FAST InStream administration tool.

• On Windows, start the Fast InStream Web Server service.
• On UNIX, navigate to the directory $DOCUMENTUM/fulltext/IndexServer/bin
and enter these commands:
source setupenv.sh
httpd f $DOCUMENTUM/fulltext/IndexServer/etc/httpd/httpd.conf
3. Launch the FAST InStream administration tool by entering this URL:
http://localhost:port+3000
In this URL, port is the base port number assigned to the index server during
installation. The default base port is 13000, in which case the URL would be
http://localhost:16000.
The FAST InStream administration tool appears.
4. Click the Create Collection link.
5. Enter a name and description for the collection. Note the name for future reference.
You will need it in later steps when you update the indexagent.xml file and the
routing.cfg file. The name is case sensitive.
6. Click Next. The page for selecting a cluster appears. The value webcluster is
automatically selected, since it is the only option.
7. Click Next.
8. Select DFTXML (webcluster) from the Available Pipelines drop‑down list, then
click the add selected button that appears to the right of the drop‑down list.
9. Click Next.
A message appears informing you that no data sources exist.
10. Click OK.
11. Repeat steps 4 to 10 to create additional collections.
In most cases, you want to create one collection for each index server node.
Mapping file stores to collections

Once you have created the necessary fulltext collections, you associate them with file
stores in the indexagent.xml configuration file, which resides on the index agent host
machine.
To configure the index agent for directed routing:

1. Shut down the index agent if it is running.
2. On the index agent host, navigate to C:\Documentum\jboss4.2.

0\server\DctmServer_IndexAgent1\deploy\IndexAgent1.war\WEB‑INF\classes
(on Windows) or $DOCUMENTUM_SHARED/jboss4.2.0/server/DctmServer_
IndexAgent1
/deploy/IndexAgent1.war/WEB‑INF/classes (on UNIX).
If you installed multiple index agents on this host, replace the number 1 in these
paths with the appropriate index agent number.
3. Open the indexagent.xml file in a text editor.
4. Locate the closing tag of the <indexer> element.
Place the cursor just before the </indexer> tag.
5. Insert an element with this format.
<partition_config>
<default_partition>
<collection_name>name_of_default_collection</collection_name>
</default_partition>
<partition>
<storage_name>name_of_file_store
</storage_name>
<collection_name>name_of_collection
</collection_name>
</partition>
</partition_config>
The name_of_default_collection needs to match the value of the <fds_collection>
element that appears later in the indexagent.xml file. It is the name of the collection
created during installation.
Include a <partition> element for each file store whose documents you want to assign
to a specific collection. The name_of_file_store needs to match the file store name
from the Content Server repository, and the name_of_collection needs to match the
collection name you specified when you created the collection in Creating fulltext
collections, page 35.
For example, the <partition_config> element below assigns documents from
filestore_01, filestore_02, filestore_03, and filestore_04 to three collections (repb01,
repb02, and repb03). Documents from other file stores are assigned to repb01, which
is designated as the default partition. Notice also that filestore_03 and filestore_04
are assigned to the same collection.
<partition_config>
<default_partition>
<collection_name>repb01</collection_name>
</default_partition>
<partition>
<storage_name>filestore_01</storage_name>
</partition>
<partition>
</partition>
<partition>
</partition>
<partition>
</partition>
</partition_config>
</indexer>
6. Save and close the indexagent.xml file.

7. Restart the index agent.
Mapping collections to index columns

When using directed routing, the index agent assigns documents to collections based
on which file store contains their content files. The index server needs to route the
documents to different nodes based on which collection they belong to. To configure
the index server to do this, you create a routing configuration file (routing.cfg) and
update the Status Server configuration file (NodeConf.xml) so that it refers to the routing
configuration file.
To configure the index server for directed routing:

1. Log on to the index server administrative node as the Content Server installation
owner.
The administrative node is the node on which the Status Server process is running.
2. Shut down the index server if it is running.
3. Navigate to the directory %DOCUMENTUM%\fulltext\IndexServer\etc (on
Windows) or $DOCUMENTUM/fulltext/IndexServer/etc (on UNIX).
4. Open the CSConfig.xml file in a text editor.
The CSConfig.xml file defines the configuration of the index server nodes, including
the definitions of the index columns on each node.
5. Record the partition_id value for each index column.
The file includes a <column> element for each index column. The <column> element
identifies the machine hosting the column and also sets a numerical ID value for the
column. Note the numerical ID, which is the value of the partition_id parameter.
You will need it at step 8 below.
For example, this <column> element sets the partition_id for host1 to 0:
<column hostname="host1.emc.com" port="15674" mode="NORMAL"
partition_id="0"
ft_mode="0" docapiport="15500">
</column>
6. Close the CSConfig.xml file.

7. Use a text editor to create a file named routing.cfg in the current directory.
8. Enter the collection to column mapping in the following format:
collection_name=partition_id
On each line, collection_name is the name of a collection you created in Creating
fulltext collections, page 35, and partition_id is the ID of the index column to which
you want to route documents from this collection. For example:
repb01=0
repb02=1
repb03=2
9. Save the routing.cfg file.

10. Open the NodeConf.xml file in a text editor.
11. Add a parameter to the Status Server configuration entry, providing the name and
location of the routing.cfg file.
Add the text shown in bold below:
<executable>statusserver</executable>
<parameters>>type=single dbdir=$FASTSEARCH/data/status
dbmem=1 ORBendPointNoListen giop:tcp:host1:$PORT
ORBendPointNoPublish
giop:tcp::$PORT collectionroutingfile=
$FASTSEARCH/etc/routing.cfg
12. Save the NodeConf.xml file.

13. Restart all index server processes on all nodes.
14. Use the nctrl command on each node to verify that the processes are running
correctly:
$ cd $FASTSEARCH/bin
$ . .setupenv.sh
$ nctrl sysstatus
A list of index server processes and their status is displayed.
Adding a node
Use these instructions to add an additional node to an existing multinode configuration.
To add a node to a multinode configuration:

1. Edit a copy of the existing InstallProfile.xml file to include information about the
additional node.
See Chapter 2, Creating the InstallProfile.xml Configuration File for information
about editing this file.
2. Shut down all running index server nodes and the index agent.
3. Log in to the host machine for the new node as the Content Server installation owner.
4. Install the new index server node.
a. Download the software distribution package for the correct platform to a
temporary area on the host machine.
b. Unzip or untar the software distribution package.
c. Copy the InstallProfile.xml configuration file you created at step 1 to the same
temporary area.
d. Run the index server installation program, fulltextoperatingsystemSuiteSetup.
e. Select index server installation only. The installation program detects the
InstallProfile.xml file and asks you to confirm that you require multinode
installation.
f. Click Yes. The correct index server processes are installed and configured on
the host.
5. Log on to the administrative node host as the Content Server installation owner.
element.
6. Edit the CSConfig.xml file on the administration node to add information defining
the new node.
a. Navigate to the directory %DOCUMENTUM%\fulltext\IndexServer\etc (on
Windows) or $DOCUMENTUM/fulltext/IndexServer/etc (on UNIX).
b. Open the CSConfig.xml file in a text editor.
c. Within the <modules> element, add a new <module> element for the new host
machine. The <module> element has this format:
<module hostname="host_name" port=
"base_port_number" />
For example:
<module host="hostnew.emc.com" port="15674" />
d. Within the <search_clusters><cluster> element, add a new <column> element for

the new node. The <column> element has this format:
<column host="fully_qualified_host_name"
port="base_port_number" mode="NORMAL"
partition_id="partition_number"
ft_mode="0" docapiport="15500">
The partition_number should be the integer specified as part of
the <search‑engine‑column> ID in the Webcluster section, page
25 of the IndexProfile.xml file; if the IndexProfile.xml file includes
<searchenginecolumn id="col4">, the partition_number for the column
is 4. For example:
<column host="host0.emc.com" port="15674"
mode="NORMAL" partition_id="4" ft_mode="0" docapiport=
"15500>
e. Save and close the CSConfig.xml file.

7. If you are using directed routing, update the routing rules as necessary.
Updating the rules may require changes to routing.cfg, to indexagent.xml, or both.
You may also need to create additional collections. See Configuring directed routing,
page 34 for details.
8. If you are using round‑robin routing, rebalance the index across the newly expanded
set of nodes.
With round‑robin routing, each index column should have approximately the same
number of index entries. When you add a node, you need to redistribute the existing
entries.
a. Backup the FIXML files on each node to a local temporary directory. The FIXML
files are in the directory %DOCUMENTUM%\data\fulltext\fixml on Windows
and $DOCUMENTUM/data/fulltext/fixml on UNIX.
b. Delete the FIXML files and the index columns on each node.
c. Restart the index server nodes, beginning with the administrative node.
d. Configure each defined fulltext collection to use the migration pipeline. To do
so, launch the FAST InStream administration tool by entering this URL:
http://localhost:base_port+3000
The base_port is the index server’s base port number; if the index server is using
the default base port 13000, then the value for the URL is 16000. From the
Collection Overview screen, click the edit button that appears to the right of the
collection information row, choose Edit Pipeline, and select Migration from the
Available Pipelines drop‑down list. Repeat this step for each defined collection.
e. Suspend indexing on each node. Enter this command to suspend indexing:
rtsadmin localhost port webcluster
partition_id 0 suspendindexing
The port is the index server’s base port number plus the constant 3099. If the
index server is using the default base port 13000, then the port value is 16099.
The first integer after ’webcluster’ is the partition_id of the column hosted on
the node.
f. Rebuild the index by running the FIXML feeder on each node. Enter this
command:
cobra fixmlfeeder.py i path_to_temp_dir
The path_to_temp_dir is the path to the directory where you backed up the
FIXML files at step a.
g. When the feeding is complete, use the FAST InStream administration tool to
reset all collections to use the DFTXML (webcluster) pipeline (see step d above).
h. Resume indexing on each node. Enter this command to resume indexing:
rtsadmin localhost port webcluster
partition_id 0 resetindex
9. Restart the index server on each node and restart the index agent.
Removing a node
Use these instructions to remove a node from an existing multinode configuration.
To remove a node from a multinode configuration:

1. Shut down all nodes, and shut down the administration node last.
2. Update the CSConfig.xml file on the administration to remove the node.
3. Update routing.cfg on the administration node to remove the node from the
collection.
4. Remove the NameService files from the omniorb log directory $FASTSEARCH/
var/log/omniorb/
5. Update the $FASTSEARCH/etc/searchrc‑1.xml file on each search node adjoining
the node being removed.
6. Update the following two directories that contain references to the node being
removed: $FAST_SEARCG/var/searchctrl/etc/enginesrc_[portNumber] and
engine/data_[portNumber]
7. On Windows, run the uninstaller on the node being removed. On UNIX, manually
remove the $FASTSEARCH installation.
8. Restart the remaining node, first the administration node, then the other nodes.
Backing up and restoring an index

Use the following procedure to back up and restore and index in a multinode
configuration.
To back up and restore and index:

1. Back up the fixml and index folders on the administration node or on any other node.
2. Back up the following configuration files on any nonadministration node:
• CSConfig.xml
• routing.cfg
• NodeState.xml
• NodeConf.xml
• IndexAgent.xml (Backup of this file is optional.)
3. Create a few documents in the repository and index them to the index server.
4. Remove the index server installation.
5. Reinstall the index server.
6. Restore the configuration files you backed up in Step 2.
7. Copy the index and fixml folders from the backup location.
8. Start the index server on the node.
9. Verify that the index has been properly restored:
1. Verify that all documents are restored to the node by using Matching Engines
and Collections in the FAST administration page.
2. Run a query against the collection on the node.
3. Verify that all documents in the query are returned as expected.
4. Run the ftintegrity tool to verify the completeness and accuracy of the index.
Uninstalling a Multinode Indexing Configuration

To uninstall a multinode configuration, stop all running processes on all hosts. Use the
instructions in the Documentum Content Server Fulltext Indexing System Installation and
Administration Guide to uninstall the index server from each node and to uninstall the
index agent.
Index
C I
collections index agent
routing to columns, 13 configuring, 31
collections, defined, 35 index routing
Content Distributor, described, 10 index server configuration
requirements, 38
index server
D Content Distributor, 10
DFTXML, 10 DocProcessor, 10
directed routing findex process, 10
configuring, 34 Indexer, 10
DocProcessor, described, 10 QR Server, 10
documentation, 7 query subsystem, 10
documents Status Server, 10
routing to nodes, 13 indexagent.xml file, 33
drives, sharing, 33 Indexer, described, 10
installing indexing software, 7
F
findex process, described, 10 P
FIXML, 10 processor, see DocProcessor
frtsobj process, described, 10
fulltext indexes
collections, 35 Q
fulltext indexing QR Server, described, 10
directed routing, configuring, 34 query subsystem, described, 10
documentation, 7
file store mapping, 33
performance, 33
S
routing, directed, 13 Status Server, described, 10
sharing drives, 33
software installation, 7

Full-Text Multi Node Install 6.5

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Full-Text Multi Node Install 6.5

Caricato da

Copyright:

Formati disponibili

EMC® Documentum®

Multinode Fulltext Indexing Installation Guide

Chapter 1 Understanding Multinode Deployments ................................................. 9

Chapter 2 Creating the InstallProﬁle.xml Conﬁguration File .................................. 17

Chapter 3 Installing the Indexing Software ............................................................ 29

Figure 1. Multinode configuration with three nodes ....................................................... 11

Purpose of the manual

Distributing index server processes across

Figure 1. Multinode conﬁguration with three nodes

Distributing documents across nodes

Figure 2. Multinode conﬁguration using round­robin distribution

Figure 3. Multinode conﬁguration using directed routing

Using directed routing provides these advantages:

Installing the index server in a multinode

To create the InstallProﬁle.xml ﬁle for your implementation:

Administrative services section

Content distributor section

Status server section

Search engine section

Document processor section

Query server section

<property name="default­language" value=

Installing a multinode conﬁguration

To install a multinode conﬁguration:

• On Windows, double‑click fulltextWinSuiteSetup.exe.

Conﬁguring the index agent

To conﬁgure the index agent:

• On Linux, IndexAgent_Configuration_Program.linux –config setup.ini

Modifying the indexagent.xml ﬁle to map ﬁle stores

To modify the indexagent.xml ﬁle and map the ﬁle stores:

5. Save the indexagent.xml file.

Conﬁguring directed routing

Figure 5. Mapping ﬁle stores to collections to index columns

Creating fulltext collections

To create a fulltext collection:

2. Enable access to the FAST InStream administration tool.

Mapping ﬁle stores to collections

To conﬁgure the index agent for directed routing:

2. On the index agent host, navigate to C:\Documentum\jboss4.2.

6. Save and close the indexagent.xml file.

Mapping collections to index columns

To conﬁgure the index server for directed routing:

6. Close the CSConfig.xml file.

9. Save the routing.cfg file.

12. Save the NodeConf.xml file.

A list of index server processes and their status is displayed.

To add a node to a multinode conﬁguration:

d. Within the <search_clusters><cluster> element, add a new <column> element for

e. Save and close the CSConfig.xml file.

To remove a node from a multinode conﬁguration:

Backing up and restoring an index

To back up and restore and index:

Uninstalling a Multinode Indexing Conﬁguration

Potrebbero piacerti anche

Figure 2. Multinode conﬁguration using roundrobin distribution

<property name="defaultlanguage" value=