Deployment Concepts

This chapter provides several deployment scenarios that show different levels of search and index high-availability, depending on your hardware budget.

The goal with all multihost deployments is to:

• Minimize the query load on the primary server and any additional index build hosts, so as to not slow down document processing and index updates.

You can deploy Exalead CloudView on multiple hosts to provide:

• High search availability and Queries Per Second (QPS) scalability, using multiple indexes and search servers with an external load balancer.

• Increased corpus volume and indexing throughput, by adding additional index build groups.

At index-time, you can increase corpus volume and indexing throughput by adding more build groups.

At search-time, you can increase queries per second (QPS) processing by adding more indexes. This has the additional benefit of ensuring high availability for your deployment.

Deploying multiple search servers on secondary servers, together with an external load balancer, ensures high availability for the search application.

Deploying multiple indexes on secondary servers provides index high availability, while reserving the primary server for processing new documents.

In a standard multihost configuration (with no advanced tuning), in the mashup-ui->mashup-api->search-api chain, each layer always tries to contact its local follower, unless it has failed or an exception is returned. In such case, the processing layer contacts its follower on another host.

Note: It has nothing to do with mashup ui/api. The search-api targets the local index slice whatever happens. If the search-api returns an exception (for example, no index), its local mashup-api is aware of it and tries to contact a search-api on another host.

By default, Exalead CloudView search servers:

• Send queries to the primary server's index only when no other indexes are available.

To ensure high availability, include redundant load balancers to distribute user queries among available search servers.

Note: In this guide, the recommended scenarios include the use of external load balancers that monitor search server health. For more information, see "Monitor search server health with load balancers" in the Exalead CloudView Administration Guide.

A build group is a component that takes care of indexing, pushing and analyzing documents.

It then creates the source index from which all the index replicas in your deployment are based. Each build group has its own analyzer, index, data model, and indexing configuration.

You can add more build groups to an existing host, or create a new host for a new build group.

• Add more build groups to an existing host when, for example, you need to do one of the following:

◦ Accommodate multiple corpuses with different indexing schedules, or different data models.

◦ Index your corpus on a rotating basis. For example, if it1 indexes on week 1, then it2 indexes on week 2 while it1 is cleared.

• Add more build groups to a new host to increase corpus volume and indexing throughput.

For more information, see Add a New Build Group.

For a multihost Exalead CloudView deployment, you must configure hosts and roles . This consists of a primary server and one or more secondary servers. The processes that run on these hosts are determined by adding roles to the hosts.

Create secondary servers to:

• Add additional search servers and indexes (to provide HA and better QPS).

• Or to add another build group (to increase document processing volume) to the deployment.

For complete details on roles, see the "Appendix - Deployment Roles and Related Processes" in the Exalead CloudView Administration Guide.

You can configure index slices in the Exalead CloudView index to maximize performance at search-time.

The number of index slices depends on available CPU, IO, and latency requirements. Each index slice adds a search thread, therefore you can increase parallel search processing by using more slices.

The Search server interprets the user query and processes the request.

Exalead CloudView processes each user query according to a specific search logic and search target.

Note: You can display search results either in the Mashup UI (the default search application), or a custom search application created with the Exalead CloudView Search API.

Search targets specify the index slices called by the search server.

You can use search targets to define failover behavior. By default, search servers query all indexes on an active/active basis, and query the default index (i0) on the build group host, only when no other indexes are available.