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:

  • Create a high availability, scalable architecture.
  • 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.

This page discusses:

See Also
Default Installation
High Availability with a Small Index
Full High Availability with a Large Index
Adding Hosts, Roles and Build Groups
Installing Secondary Servers

Scalability

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.



High Availability

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.

Load Balancing

By default, Exalead CloudView search servers:

  • Distribute queries equally among available indexes.
  • 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.

Build Group

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.

Hosts and Roles

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.

Index Slices

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.

Search Server

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

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.