Product: OpenText Content Server Version: 10.0.0 Task/Topic:
Deployment
Audience: Administrators, Administrators, Decision Decision Makers Platform: All Document ID: 500146 Updated: November 29, 2012
White Paper
Content Server 10 Architecture Overview
CHAMPION TOOLKIT
Contents Summar Sum mar y ......... .................. .................. ................... ................... .................. .................. .................. ................... ................... .................. .................. ................. ........3 Serv ic es Avai lab le ......... .................. .................. ................... ................... .................. ................... ................... .................. ................... ................... ...........4 Open Text Cont ent Server Arc hit ectu re Overv iew ..... ......... ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ...... ..5 Monolithic Architecture ........................................................................................... 5 Dual-Server Architecture ........................................................................................ 6 Tri-Server Architecture Architectur e ................ ................................. .................................. ................................. ................................. .......................... ......... 7 Clu st er Ar ch it ect ur e .............. ....................... ................... ................... .................. .................. ................... ................... .................. .................. ............ ... 8 Fro nt –End Scal Scalin in g ......... .................. ................... ................... .................. ................... ................... .................. ................... ................... .................. .........9 Horizontal Horizon tal Scaling ................. ................................. ................................. ................................. ................................. .......................... ......... 9 Vertical Scaling ................................................................................................ 9 Horizontal and Vertical Scaling ...................................................................... 10 Horizontally Scaled Cluster Architecture .......................... .................................... ................... ................... ................. .......10 Monolithic and /or Dual-Server Architecture – Ver Vertically tically Scaled ................. .......................... ......... 11 Tri-Server Architecture – Vertically Scaled ........................................................... 12 Horizontally and Ver Vertically tically Scaled Cluster Architecture......... .................. .................. ................... ............. ...13 Bac k-En d Scal Scalin in g ........ .................. ................... .................. ................... ................... .................. ................... ................... ................... ................... .........14 Search Infrastructure Sections ............................................................................. 15 The Data Flow .............. ............................... ................................. ................................. ................................. ................................ ................ 16 Enterprise Extractor (a Producer Process): .......... ................... ................... ................... ............... ......16 Prospec tor Importer: ................. Prospector .................................. .................................. ................................. ............................. ............. 16 Classificatio Classi fications ns Importer: ................. .................................. .................................. ................................. ....................... ....... 17 Update Distributor:................................................................................... Distributor:................................................................................... 18 Index Engine: Engi ne: ................ ................................. .................................. .................................. ................................. ........................ ........ 18 Index: ....................................................................................................... 18 Search Engine: ................ ................................ ................................. ................................. ................................. ....................... ...... 19 Search Federator:.................................................................................... Federator:.................................................................................... 19 The Search Manager ..................................................................................... 19 The Search Infrastructure on Disk ........................................................................ 20 The index1 Folder:................................................................................... 21 The data_flow data_fl ow Folder: .............. ............................... ................................. ................................. ............................... .............. 21 The System Object Volume Interface ................................................................... 22 The Searc h Gri Grid d ......... .................. ................... ................... .................. ................... ................... .................. ................... ................... .................. ........... .. 24 Adding Search Federators ......... .................. ................... ................... ................... ................... .................. ................... ............ ..25 Adding Partitions .......... ................... .................. ................... ................... .................. ................... ................... .................. ................. ........27 Adding Search Federators and Partitions Partitions ......... ................... ................... .................. ................... ................. .......29 Ad di ng A dm in Serv Servers ers ......................... ................................... ................... ................... ................... ................... ................... .................. ........... ..30 Hig h-Av ail abi li ty Clu st er ............ ..................... ................... ................... .................. ................... ................... .................. ................... .............. ....36 Ag ent ents s an d Noti No ti fi cat io ns Opt io ns ............... ......................... ................... ................... ................... ................... ................... ............ ...37 Con cl us io n .......... ................... .................. ................... ................... .................. ................... ................... .................. ................... ................... .................. ........... 39 For Further Information......................................................................................... 39 Ab ou t OpenText Op enText ...................... ............................... .................. ................... ................... .................. ................... ................... .................. ................. ........40 CHAMPION TOOLKIT
2
Contents Summar Sum mar y ......... .................. .................. ................... ................... .................. .................. .................. ................... ................... .................. .................. ................. ........3 Serv ic es Avai lab le ......... .................. .................. ................... ................... .................. ................... ................... .................. ................... ................... ...........4 Open Text Cont ent Server Arc hit ectu re Overv iew ..... ......... ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ...... ..5 Monolithic Architecture ........................................................................................... 5 Dual-Server Architecture ........................................................................................ 6 Tri-Server Architecture Architectur e ................ ................................. .................................. ................................. ................................. .......................... ......... 7 Clu st er Ar ch it ect ur e .............. ....................... ................... ................... .................. .................. ................... ................... .................. .................. ............ ... 8 Fro nt –End Scal Scalin in g ......... .................. ................... ................... .................. ................... ................... .................. ................... ................... .................. .........9 Horizontal Horizon tal Scaling ................. ................................. ................................. ................................. ................................. .......................... ......... 9 Vertical Scaling ................................................................................................ 9 Horizontal and Vertical Scaling ...................................................................... 10 Horizontally Scaled Cluster Architecture .......................... .................................... ................... ................... ................. .......10 Monolithic and /or Dual-Server Architecture – Ver Vertically tically Scaled ................. .......................... ......... 11 Tri-Server Architecture – Vertically Scaled ........................................................... 12 Horizontally and Ver Vertically tically Scaled Cluster Architecture......... .................. .................. ................... ............. ...13 Bac k-En d Scal Scalin in g ........ .................. ................... .................. ................... ................... .................. ................... ................... ................... ................... .........14 Search Infrastructure Sections ............................................................................. 15 The Data Flow .............. ............................... ................................. ................................. ................................. ................................ ................ 16 Enterprise Extractor (a Producer Process): .......... ................... ................... ................... ............... ......16 Prospec tor Importer: ................. Prospector .................................. .................................. ................................. ............................. ............. 16 Classificatio Classi fications ns Importer: ................. .................................. .................................. ................................. ....................... ....... 17 Update Distributor:................................................................................... Distributor:................................................................................... 18 Index Engine: Engi ne: ................ ................................. .................................. .................................. ................................. ........................ ........ 18 Index: ....................................................................................................... 18 Search Engine: ................ ................................ ................................. ................................. ................................. ....................... ...... 19 Search Federator:.................................................................................... Federator:.................................................................................... 19 The Search Manager ..................................................................................... 19 The Search Infrastructure on Disk ........................................................................ 20 The index1 Folder:................................................................................... 21 The data_flow data_fl ow Folder: .............. ............................... ................................. ................................. ............................... .............. 21 The System Object Volume Interface ................................................................... 22 The Searc h Gri Grid d ......... .................. ................... ................... .................. ................... ................... .................. ................... ................... .................. ........... .. 24 Adding Search Federators ......... .................. ................... ................... ................... ................... .................. ................... ............ ..25 Adding Partitions .......... ................... .................. ................... ................... .................. ................... ................... .................. ................. ........27 Adding Search Federators and Partitions Partitions ......... ................... ................... .................. ................... ................. .......29 Ad di ng A dm in Serv Servers ers ......................... ................................... ................... ................... ................... ................... ................... .................. ........... ..30 Hig h-Av ail abi li ty Clu st er ............ ..................... ................... ................... .................. ................... ................... .................. ................... .............. ....36 Ag ent ents s an d Noti No ti fi cat io ns Opt io ns ............... ......................... ................... ................... ................... ................... ................... ............ ...37 Con cl us io n .......... ................... .................. ................... ................... .................. ................... ................... .................. ................... ................... .................. ........... 39 For Further Information......................................................................................... 39 Ab ou t OpenText Op enText ...................... ............................... .................. ................... ................... .................. ................... ................... .................. ................. ........40 CHAMPION TOOLKIT
2
Summary This document provides a technical overview of the various types of Deployment Architecture for Open Text Content Server (formerly Livelink ECM – Enterprise Server). Customers considering any change to their existing deployment should consider a contract under a statement of work to receive an Ar ch it ect ur e and Scaling Engagement from our Global Services consulting group. Global Services is our front line in the area of clustered environments, high availability, redundancy, customizations, and complex upgrades. With the Architecture and Scaling engagement, our Global Services Group would not only address any design/performance/deployment concerns, but would also assist in building an optimum design necessary to address not only performance requirements now, but five years from now, based on future growth forecasts and needs of your enterprise. In any serious deployment, there is a requirement for redundancy and likely a scale that demands multiple physical resources. resources. A recommended approach is to use multiple Open Text Content Servers (OTCS) along with a load balancer.
CHAMPION TOOLKIT
3
Services Available Open Text (OT) offers a Health Check Service and Service and a Performance Check Service through our Technical Services Group. Health Check : This service supports the proactive identification of potential problems Health in the configuration and usage of the OT Product environment. A check is carried out on the OT Product installation and configuration, the database setup, activity and content, the index, and the supporting system. Results are articulated in a report summarizing the checks performed and recommendations for any improvements. Performance Check: This service supports the proactive identification of potential performance bottlenecks before they negatively impact end-users’ experiences with the OT Product system, and keeps those who are interested in an on-going analysis of their system apprised of how it is being used, possible weaknesses, and if relevant, comparative reports with earlier performance checks. Customers contemplating changes to their existing deployment should consider the OTCS Performance Bundle from our Technical Services Group. This bundle was designed specifically for customers concerned with the growth, performance, availability, and adoption of their Open Text solutions—and includes a number of tools and utilities, services, and workshops. Technical Services consultants are experts in the area of clustered environments, high availability, redundancy, and complex upgrades for existing Open Text deployments. Customers considering a new deployment should consider a contract under a statement of work to receive an Ar ch it itect ect ur e and Scal in g Eng agem ent from our Global Services consulting group. Global Services is our front line in the area of clustered environments, high availability, redundancy, customizations, and complex upgrades. Our Services’ groups not only address any design/performance/deployment concerns, but also assist in building an optimum design necessary to address performance requirements, based on future growth forecasts and needs of your enterprise.
CHAMPION TOOLKIT
4
Open Text Content Server Architecture Overview Monolithic Architecture This is the simplest approach, which is typically used in small organizations or for development machines. The OTCS Web server and Admin server are installed on the same physical/logical* machine as the database server. This will support internal storage of files in the database, or external storage—where files are stored externally from the database on a separate drive/disk on the same machine or on a separate machine or device (SAN). Monolithic deployments are typically used for development systems and rarely in a small production environment.
Figure 1 Content Server - Monolithic Architecture
* Monolithic implies four CPUs or less.
CHAMPION TOOLKIT
5
Dual-Server Architecture The second configuration is called a Dual-Server architecture, where the OTCS Web server and Admin server are deployed on one machine, and the database server is deployed on a separate physical/logical machine. This will support internal storage of files in the database, or external storage—where files are stored externally from the database on a separate drive/disk on the same machine or on a separate machine or device (SAN). The main advantage here is the increase in configuration options available to both servers. Like Monolithic deployments, Dual-Server Architecture is also becoming rarer with the demands of today’s ECM world.
Figure 2 Content Server - Dual Server Architecture
CHAMPION TOOLKIT
6
Tri-Server Architecture The third configuration is calle d a tri-server architecture, where the OTCS Web server and OTCS Admin server are split up and deployed on separate physical machines. The OTCS Admin server will handle all of the search and indexing. The OTCS Web server will handle all of the traffic to and from the user community. Agents such as Notifications can only be on one system—depending on the mix of optional modules deployed, so there is the option of running Agents on the OTCS Web server, or distributing the load across two servers. This configuration will support internal storage of files in the database, or external storage—where files are stored externally from the database on a separate drive/disk on the same machine or on a separate machine or device (SAN).
Figure 3 Content Server - Tri- Server Architecture
CHAMPION TOOLKIT
7
Cluster Architecture The fourth configuration is the OTCS Cluster Architecture. This Architecture has multiple OTCS instances installed accessing the same database and optional external file store. A load balancer directs requests to the most “available” OTCS Web server. OTCS Cluster Architecture is basically a Web farm deployment. This will be broken down into two sections—the Front End and Back End. The “Front End” concerns the scaling of the OTCS Web server. The “Back End” concerns the scaling of the OTCS Admin server. There are three subtypes of OTCS Front End Cluster Architecture: Horizontal Scaling, Vertical Scaling, and a combination of the two—Horizontal and Vertical Scaling.
Figure 4 Content Server Front End and Back End concept. Regions that can be scaled in different ways in an OTCS Cluster deployment
CHAMPION TOOLKIT
8
Front–End Scaling OTCS by default is configured to be self-adjusting; that is, it can create and utilize more threads when required. However, a OTCS thread can take some time to start up. The preferred configuration is to set the min and max threads on a system to the same number preventing the system from spawning more threads. OTCS by default starts with 8 threads but can be configured to run more based upon resource availability. Determining the correct number of threads to run per instance is based upon many factors including the number of cores, amount of RAM and available disk IO.
Horizontal Scaling Horizontal Scaling is where there are two or more physical Web servers deployed behind a load balancer. This is the simplest and most common way to implement an OTCS Cluster Architecture across a Web farm. It is easily understood, and the distinct servers will not interfere with one another. For example, if there are two Web servers—each with eight threads running, there would be a total of sixteen available threads. In order to take advantage of this, a load balancer is deployed out in front, redirecting traffic to the most “available” OTCS instance. Redundancy is now introduced as well, so that if one OTCS instance fails, the other one(s) will take over the load.
Vertical Scaling 1 Another method to maximize the number of available threads per server is to install more than a single instance of OTCS on a single server. Each instance is separate from one another by the ports they are using, but all of them are connected to the same Database, Admin server, and optional External Storage. This is known as Vertically Scaled or Vertically Stacked. Each instance of OTCS on the Web server runs in its own space. The limitation to this type of scaling is CPU and RAM availability. In this configuration, if the physical hardware fails, remove more instances of OTCS from the cluster. A Horizontally Scaled system will not have resource contention between Content Server instances on the same physical hardware. The number of threads to run absolutely depends on the Usage Profile of the OTCS system. The Usage Profile is an analysis that is done via an Ar ch it ect ur e and Scaling Engagement from the Global Services consulting group. For example, if a single OTCS Web server had three instances of OTCS—each with eight threads running, there would be 24 available threads. In order to take
1
The performance improvements in Content Server 2010 significantly reduce the need for vertical scaling. Content Server 2010 is more efficient and can handle much more throughput. However Vertical Stacking is still useful for redundancy.
CHAMPION TOOLKIT
9
advantage of this, a load balancer is deployed out in front, redirecting traffic to the most “available” OTCS instance.
Horizontal and Vertical Scaling For large-scale Enterprise deployments, OTCS is typically installed across several servers (Horizontal Scaling) with each server containing two or more instances of OTCS (Vertical Scaling). Redundancy is also in place so that if one Vertically Scaled OTCS Web server fails, the other one(s) will take over the load.
Horizontally Scaled Cluster Architecture There is one instance of OTCS per Web server, and there are two or more physical Web servers deployed behind a load balancer, this is called a Horizontally Scaled Cluster Architecture.
Figure 5 Simplistic view of a Content Server- Horizontally Scaled Cluster Architecture
In the example above, there are two OTCS instances across two physical servers. Each instance has eight threads, for a grand total of sixteen threads available.
CHAMPION TOOLK IT
10
Monolithic and /or Dual-Server Architecture – Vertically Scaled This is the simplest approach to vertically scaling OTCS. It is only practical for test and development environments. The OTCS Web server and Admin server are installed on the same physical machine as the database server, or with Dual Server Architecture, the database server is installed on another physical box. In the example below, we have three instances of the OTCS Web server installed. This will support internal storage of files in the database, or external storage—where files are stored externally from the database on a separate drive/disk on the same machine or on a separate machine or device (SAN).
Figure 6 Content Server- Dual Server Architecture Vertically Scaled
In the example above, there are three OTCS instances installed on one physical server. Each instance has eight threads, for a grand total of twenty-four threads available.
CHAMPION TOOLK IT
11
Tri-Server Architecture – Vertically Scaled In a production environment, the place to start in a Vertically-Scaled Architecture is with a tri-server architecture, where the OTCS Web server and OTCS Admin server are split up and deployed on separate physical machines. The OTCS Admin server will handle all of the search and indexing. The OTCS Web server will have three instances of OTCS installed, behind a load balancer, handling all traffic to and from the user community. The load is now distributed across three instances, but on one physical server. This will also support internal storage of files in the database, or external storage—where files are stored externally from the database on a separate drive/disk on the same machine or on a separate machine or device (SAN).
Figure 7 Content Server- Tri- Server Architecture Vertically Scaled
In the example above, there are three OTCS instances installed on one physical server. Each instance has eight threads, for a grand total of twenty-four threads available.
CHAMPION TOOLK IT
12
Horizontally and Vertically Scaled Cluster Architecture The preferred method of deploying a Vertically Scaled Architecture is to combine it with Horizontal Scaling, Two or more instances of OTCS per Web server, and there are two or more physical Web servers deployed behind a load balancer in this design.
Figure 8 Simplistic view of a Content Server- Horizontally and Vertically Scaled Cluster Architecture
In the example above, there are nine OTCS instances across three physical servers. Each instance has eight threads, for a grand total of seventy-two threads available. This type of architecture can be split out even more by adding another OTCS Web server—with a single instance of OTCS deployed—whose sole purpose is to run Notifications Agents. This server would not be part of the Web farm, and therefore can focus all its resources to this single task—depending on the mix of optional modules in the scenario.
CHAMPION TOOLK IT
13
Back-End Scaling The OTCS Admin server can also be scaled to meet performance demands of a large Enterprise deployment. OTCS can have multiple Admin servers, with each one managing different index components. In order to understand how to scale the OTCS Indexing and Searching system, a breakdown of the design into the i ndividual processes and components is necessary. The illustration in Figure 9 below breaks out the basic search i nfrastructure.
Figure 9 The Search Infrastructure simplified
All of the processes in the search infrastructure are managed by the OTCS Admin server.
CHAMPION TOOLK IT
14
Search Infrastructure Sections The Search Infrastructure is broken into three main sections (Figure 10): •
Data Flow
•
Search Grid
•
Search Manager
Figure 10 The Search Infrastructure simplified
CHAMPION TOOLK IT
15
The Data Flow The Data Flow contains the indexing processes. There are five main components: •
Producer Process
•
Document Conversion Process
•
Update Distributor
•
Prospector Importer
•
Classifications Importer
Referencing Figure 11, here are the tasks the components listed perform.
Figure 11
Enterprise Extractor (a Producer Process): The Enterprise Extractor Process is monitoring OTCS for any new/modified/deleted information, which is then extracted. Other examples of producer processes that locate or extract data are the Directory Walker and XML Activator. This new information is then extracted and added to the first iPool, (Data Interchange Pool, which is located in the working folder called data_flow; more on this later), which hands it over to the next process, the Document Conversion Process. Document Conversion Process: The Document Conversion Process monitors the iPool from the Enterprise Extractor Process. The Document Conversion Process provides two services in Content Server: it converts the documents from their native formats to HTML, XML, or raw text so that the data can be indexed. The converted data is then deposited into another iPool, located in the working folder called data_flow. Prospector Importer: The Prospectors importer process is a data flow process that scans new data after it is indexed and identifies items that match a prospector’s search criteria. In a typical data flow, the Prospectors importer process exists after the Update Distributor process (the Update Distributor Process is part of the Search Grid). Prospectors importer processes are automatically added to each data flow that you create using the Enterprise Server index templates. If you want to add Prospectors importer processes to existing data flows, you must do so manually. The Update Distributor executes prospector queries against incoming data. The hits are exported to iPool messages to the Prospector Importer. The Importer CHAMPION TOOLK IT
16
imports the hits into a database table. A Content Server agent processes the table entries and updates Prospector results in Content Server. Notification emails are sent if the results are notification enabled. Classifications Importer: If the Content Server Classifications module is installed, the Update Distributor executes classification queries against incoming data. Classification matches are exported to iPool messages to the Classification Importer. The importer imports the matches into a database table. A Content Server agent processes the table entries and updates matched nodes' classification information in Content Server.
The Search Grid The Search Grid section is the scalable section of the Search Infrastructure. The Search Grid section within the Search Infrastructure contains at the very minimal the following components: •
Update Distributor
•
Index Engine
•
Index1 or Index Partition
•
Search Engine
•
Search Federator
Referencing Figure 12 here are the tasks that the components listed perform.
CHAMPION TOOLK IT
17
Figure 12
Update Distributor: The Update Distributor Process reads the data output by the Document Conversion Process from this second iPool, and then distributes the data among the Index Engine(s) in their respective Partition(s). It sends new objects to read-write partitions in a round-robin manner. The Update Distributor process also distributes index update requests to Index Engines so that all indexed data in each partition is kept upto-date. To do this, the Update Distributor process communicates with Index Engines to determine if the object that it is trying to update exists in its partition's index. Once the object is located, the Update Distributor process sends the updated data to that Index Engine for indexing. If there are defined Prospector/Classification queries, the Update Distributor also deposits match-info into a third iPool (located in the working folder called data_flow) where it is picked up by the Prospector and/or Classifications Importer. Index Engine: The Index Engine is a process that indexes data for the Partition to which it belongs, so that Search Engines can search the data. There is only one Index Engine per partition. Index: The index is housed in a subfolder (along with the data_flow subfolder by default) under the \ i ndex\ ent er pr i se\ subfolder (OTHOME—the root folder CHAMPION TOOLK IT
18
for OTCS, wherever it was initially installed). It will have a number attached to the name (for example, i ndex1, i ndex2 and so on) for the partition it represents. This folder houses the actual index data for the partition in question. It also contains the Admin Server’s signature file. Search Engine: A Search Engine is a process that searches the Partition’s index. The search result that it produces from the data it locates is passed on to the Search Federator. There is at least one Search Engine per partition. Search Federator: A Search Federator is a process that manages one or more Search Engines, and distributes search requests to each one of them. When search results are returned from the Search Engine(s), the data is then merged and passed on to the Search Manager.
The Search Manager The Search Manager is a container for the Search Federator processes. There is overlap between the Search Manager section and the Search Grid section of the Search Infrastructure. The Search Federator receives a user’s search request in the form of a query, and then passes the request on to a Search Engine(s). The Search Federator also receives the final results set from the Search Engine(s) and passes it to OTCS so it can appear to the user on the Search Results pages. Referencing Figure 13 here are the tasks the components listed perform.
Figure 13
CHAMPION TOOLK IT
19
The Search Infrastructure on Disk On the hard disk, the index directory is by default installed under the OTHOME (the root folder for OTCS, wherever it was i nitially installed) folder. Initially the index folder should not be located under the OTHOME folder. Index files may reside on a local drive, mapped drive, UNC drives, SAN, or NAS, as long as it is readable and writeable by the Index Engines and Search Engines. A common misconception is that the index folder is the actual index. In reality the initial index folder can consist of three subfolders. These subfolders are the data source folders. Assuming the Admin Help and User Help indices were created, the data source subfolders would consist of:
adminhelp
enterprise
help
•
•
•
In Figure 14, the three main folders shown reside under the primary index folder, assuming the Admin Help and User Help indices were created. The adminhelp data source folder houses the data flow a nd index for the Admin Help. This is only indexed once when created, and should be manually purged and reindexed upon the installation/removal of any optional modules. The enterprise data source folder is the main one that houses the data flow and index. This is the “living” index, which is dynamic and is constantly being updated. The help data source subfolder houses the data flow and index for all of the User Help. This is only indexed once when created, and should be manually purged and re-indexed upon the installation and removal of any optional modules.
Figure 14
CHAMPION TOOLK IT
20
By default, each of these data source folders in turn has two or more subfolders (Figure 15). One is entitled data_flow, and the other is index1.
Figure 15
The index1 Folder: The index1 folder houses the actual index. If there is another partition, there will be an index2 folder present as well. The data_flow Folder: The data_flow folder is the working storage folder or “scratch pad” for the indexing processes. The iPools are located here. Open Text recommends that the data flow folders be on a drive local to the extractor, document conversion, and Update Distributor processes for performance and stability reasons. The folder structure for the enterprise index is illustrated in Figure 16.
Figure 16 The Enterprise data source Index Folder Structure on Disk
CHAMPION TOOLK IT
21
Another view of the enterprise index structure is a process map. The Data Flow processes are mapped to the data_flow folder, and the Search and Index Engine processes are mapped to the index1 folder (see Figure 17).
Figure 17 The “Index” consists of two components, which are separate: the Index partition, and the Data Flow
These components appear separately within the System Object Volume interface.
The System Object Volume Interface The System Object Volume interface (Figure 18) lists the Ad mi n Help Data So ur ce folder, the Enterpri se Data Sour ce folder and the Help Data Source folder.
Figure 18 Content Server System view
Looking in the Enterpri se Data Source folder, there is a view of the Enterprise Data Source Folder components (Figure 19)—see page 21.
CHAMPION TOOLK IT
22
Figure 19
Compare Figure 19 and Figure 20. In Figure 19, the Enterpri se Data Flow Manager lists four processes. Looking at Figure 20, the same processes are shown within the Enterprise Data Flow Manager container. The Enterprise Partition Map lists one partition. The Enterprise Search Manager lists one Search Federator. In Figure 20, each component that the System Object Volume Interface manages is highlighted. The Enterprise Partition Map allows for the configuration of the Search Grid section of the search infrastructure. The Enterprise Data Flow Manager and Enterprise Search Manager allow for the configuration of the Data Flow and Search Manager sections respectively.
Figure 20 The main components of the Enterprise Data Source Folder
CHAMPION TOOLK IT
23
The Search Grid The Search Grid (Figure 21) is a system within the Search Infrastructure that allows for scalability in three ways: •
Adding Search Federators
•
Adding Partitions
•
Allocating additional Admin servers
There is additional RAM and CPU resources required for additional Search Federators and Search Engines. Adding more Search Federators adds redundancy as well as high availability. By adding more partitions, more scalability is allowed for accommodating the growth of a system.
Figure 21 The scalable Search Grid
CHAMPION TOOLK IT
24
Adding Search Federators Looking at Figure 22 below, there is a single Search Federator / Search Engine for the single index partition.
Figure 22 Add Search Federators
CHAMPION TOOLK IT
25
When a new Search Federator is added, an additional Search Engine is now assigned to the Index partition. With more Search Engines available for this partition, the Index can now accommodate more user queries. This type of scaling addresses a growing user base.
Figure 23 New Search Federator added
CHAMPION TOOLK IT
26
Adding Partitions A partition consists of one Index Engine, and at least one Search Engine. The example in Figure 24 is the default setup for a new OTCS installation.
Figure 24 Add Partitions
CHAMPION TOOLK IT
27
When a new Partition is added (Figure 25), a new Index Engine is created and dedicated to it. An additional Search Engine is created and assigned to the new partition, as well as under the single Search Federator. The Update Distributor routes update requests among read-write/update-only partitions in a round-robin manner. This type of scaling allows for accommodating the growth of an index.
Figure 25 New Index Partition added
CHAMPION TOOLK IT
28
Adding Search Federators and Partitions Combining the two methods of scaling allows more flexibility. In the example below (Figure 26), a new partition has been added resulting in a new dedicated Index Engine and a total of two Search Engines under a single Search Federator. Next a new Search Federator was added, which created a Search Engine for each partition, resulting in a total of four Search Engines across two partitions.
Figure 26 Combination of the two, New Index Partition added along with a new Search Federator
CHAMPION TOOLK IT
29
Adding Admin Servers Although Admin servers are technically not part of the Search Grid, performance can be enhanced by expanding across additional Admin servers. This will enhance performance by distributing the load over other servers. All the processes of the Search Infrastructure are managed by the default Admin server (Figure 27).
Figure 27 Out of the box, OTCS has a single Admin server that controls the entire Search Infrastructure
CHAMPION TOOLK IT
30
Adding a second Admin Server and assigning the Search Grid portion of the Search Infrastructure to it allows for more available RAM and processing power (Figure 28).
Figure 28 The Search Infrastructure with two Admin servers. The default Admin server controls the Data Flow portion, and the new Admin server controls the Search Grid portion.
CHAMPION TOOLK IT
31
With the two Index Partitions and two Search Federators scenario that is illustrated in Figure 26, by adding a second Admin server, the Search Grid portion can be assigned separately (Figure 29):
Figure 29 The Search Infrastructure with two Index partitions and two Search Federators distributed across two Admin servers. The default Admin server controls the Data Flow portion, and the new Admin server controls the Search Grid portion.
CHAMPION TOOLK IT
32
Scaling this scenario up even further with an additional Admin server illustrates how the overall Search grid is scalabl e for the enterprise (Figure 30).
Figure 30 The Search Infrastructure with four Index partitions and two Search Federators distributed across two Admin servers. The default Admin server controls the Data Flow portion.
In Figure 30, there are eight Search Engines available to the users spanning four Index partitions. On the other side, there are four Index Engines updating the indices. The folder structure of the above scenario for the enterprise index is depicted in Figure 31 below.
Figure 31 The folder structure on the disks of the Admin servers
CHAMPION TOOLK IT
33
OTCS administrators have flexibility when scaling for extremely large data sets. The Search Grid allows large datasets to be indexed by more than one Index Engine process, and the Index Engine process may reside on different machines. The Search Grid architecture supports parallelism during indexing, and al lows the index to grow larger by adding more processes or machi nes (Admin servers) to do the work. All of the processes in the Search infrastructure, Update Distributor, Index engines, Search federators, and Search engines, are managed by the OTCS Admin Server. Although Open Text recommends that the Index engine and Search engine processes associated with a partition run on the same computer, other indexing and searching processes can (and in large installations, should) run on separate computers. The Content Server must be running on the server where the Extractor Process runs. The extraction actually takes place within a Content Server thread. Deploying additional Admin servers can distribute indexing processes across machines, especially if the index partitions are deployed across different servers.
NOTE: Never attempt to try to enhance performance by making modifications to the search.ini file.
Here is an example of a deployment with Front-End Scaling in combination with Back-End Scaling:
Figure 33 A simplistic view of a Content Server- Horizontally and Vertically Scaled Cluster Architecture on the Front End. Primary Admin Server with distributed Search Partitions across two Secondary Admin Servers on the Back End.
CHAMPION TOOLK IT
34
The Database server and the External File Store can also be scaled as well. The database could reside on a SAN behind a cluster of Database Application servers. Backup generators and universal power supplies will be part of the mix, along with backup systems, firewalls, etc. In effect, all parts of the cluster are becoming redundant. This is now getting into the realm of High-Availability Clustering. From a scalability perspective, there is no difference between a “cluster” and a “high-availability cluster.”
CHAMPION TOOLK IT
35
High-Availability Cluster A Service Level Agreement (SLA) defines the High-Availability Cluster. The SLA is designed to set expectations and goals. The SLA should cover areas such as: •
•
•
•
•
•
Reliability – Will the service consistently and accurately perform the functions identically each time? Avai lab il it y – Is the service avail able to the end-user community? Maintainability – Will any customizations/changes be available upon upgrading? Performance – Will the transactions complete in x time, and solutions be capable of y TPS? Security – Will the system be secure from intrusion, tampering or any other violations? Recovery – What happens in the event of a fire or other form of disaster—such as if a hurricane takes out the site? Will there be a mirrored location?
If no single, point of failure was part of the matrix, then network and network services such as firewalls, routers, load balancers, etc. need to be taken into account. What about fire redundancy, and maintenance windows for software updates and hardware upgrades? What about user errors such as the accidental deletion of data? How will the system be monitored? These are items that are above and beyond the scope of this document. Only through a Ar ch it ect ur e and Scal in g Eng agem ent via the Open Text Global Services Group could these issues be analyzed and addressed.
CHAMPION TOOLK IT
36
Agents and Notifications Options It is recommended that agents and notifications be run on a dedicated server. In this way, more resources will be available to the Admin server for search and indexing. In a large-scale distributed deployment, one option is to set up an OTCS server outside of the main cluster dedicated to running the agents and notifications. No other traffic is directed to it. Running agents or notifications on a front-end server, however, can negatively impact the front-end server’s performance.
New Agents for Content Server 10 Verify Agent This new agent allows the administrator to verify a certain set of metadata for each node against that in the index, find nodes that should no longer be in the index, and discover nodes that are missing from the i ndex. In previous versions this was a fire-once handler that would run for a long time and inflict a huge load on the system. The agent now uses a new method on OTCS 10 which allows for more consistent checking while lowering the load impact. There is a configuration screen to set up the parameters. This can be anywhere in the cluster, and there should be no more than one.
Distributed Agent The Distributed Agent supports tasks that don’t become active until a specified time. This is used in facets where less significant updates are delayed a period of time to allow batching of operations. The choice of the activation date is defined as part of the creation of the particular task. There must be at least one Distributed Agent configured, but it can be spread across the cluster. If there is load room on the front-end servers, then a couple of threads configured there would be more efficient.
DA Agent This thread will collect together Distributed Agent tasks and collapse duplicates down for processing. This agent also can be deployed anywhere in the cluster, but there can only be one.
CHAMPION TOOLK IT
37
Agents and Notification Cluster Configuration Example In this example, the Agent Distribution Map illustrates where the agents are going to run. The Verify Agent will be deployed on the primary Admin server only. The DA Agent will be deployed on the dedicated Agents and Notifications server. The Distributed Agent will be deployed on each of the front-end servers and on the dedicated Agents and Notifications server. The remaining agents and notifications will be assigned to the dedicated Agents and Notifications server.
Figure 34 - OTCS 10 Agent Distribution Map
CHAMPION TOOLK IT
38
Conclusion Content Server is very scalable and can grow into ever-larger configurations. None of the illustrated Architectures should be implemented without a careful analysis of system use, growth forecasts, and environmental issues such as network latency, disaster recovery etc. To do so may result in an underpowered environment or one where a large amount of funding is distributed in an inefficient manner. A Technical Architecture Consultant with the Global Services Program will help estimate the performance and scalability needs of the OTCS system, and make the most of your investment in the ECM platform.
For Further Information See the following documents on the Champion Toolkit for further information: •
Performance-Related Tools and Service Engagements
•
Case Study Series- Upgrading to Content Server 10.0
•
Case Study Series - Building a Test Environment
•
Best Practices Oracle for OpenText Content Server
•
Best Practices for Enterprise Web Services
•
Performance Assessment - Content Server 10
•
Content Server WAN Deployments Performance White Paper
•
Configuring for Least Privilege - OpenText Content Server 10
•
Configuring Antivirus Software for use with Content Server 10
•
OpenText Content Server 10.0.0 - Application Hardening Guide
CHAMPION TOOLK IT
39
