Load balancing and routing of requests

This topic discusses the load balancing and routing of external requests targeting different data domains hosted by the Endeca Server cluster.

Load balancing of requests

Depending on your deployment strategy, to the external clients, the entry point of contact with the Endeca Server cluster could be either any Endeca Server node in the cluster, or an external load balancer.

The Endeca Server cluster relies on the following two levels of load balancing of requests:
  1. Load balancing of requests across the nodes in the Endeca Server cluster. This task should be performed by an external load balancer, if you choose to use it in your deployment (it is not included in the Endeca Server package).

    If an external load balancer is used, it receives all requests and distributes them across all of the nodes in the Endeca Server cluster. Once requests are received by any Endeca Server node, they are routed by the Endeca Server to the requested data domain.

    If an external load balancer is not used, external requests can be sent to any node in the Endeca Server cluster. They will not be distributed across the nodes, but will be routed to the appropriate nodes serving the data domain, and then load-balanced between the data domain nodes.

  2. Load balancing of requests across the nodes of a given data domain. This task is automatically handled by the Endeca Server cluster — it accepts requests on any node running an Endeca Server instance and provides load balancing of these requests across the nodes in the data domain.

Routing of requests

The Endeca Server cluster can host multiple data domain clusters. The allocation of data domains to specific Endeca Server nodes is not transparent to the clients issuing the requests. The Endeca Server automatically directs requests sent to any Endeca Server node to the subset of the cluster hosting the targeted data domain.

The following statements describe the behavior of the Endeca Server cluster for routing of requests:
  • Requests can be submitted to any node in the Endeca Server cluster.
  • The Endeca Server routes requests to the appropriate Endeca Server nodes hosting the data domain specified in the request.

    For example, if the request is an updating request, such as a data loading request, or a configuration update, it will be routed to the leader node of the data domain cluster. If the request represents a non-updating (query processing) request, it will be routed to any of the follower nodes.

  • Non-updating requests are load-balanced randomly across the data domain cluster. To support session affinity, you can optionally configure the data domain profile with a session ID parameter, URL, or cookie that will be used to re-route requests from the same session to the same node in the data domain.

    Configuring session affinity in the Endeca Server guarantees that queries with the same session ID are routed to the same Dgraph nodes in the data domain. This improves query processing performance by efficiently utilizing the Dgraph process cache, and improves performance of caching entities (known in Studio as views). For information on how to configure session affinity for an Endeca data domain, see the Oracle Endeca Server Administrator's Guide.