In most production deployments, it is desirable to configure a load balancer in front of the cluster. This topic discusses the considerations for this load balancer.
- One in front of the servers hosting Studio
- One between the Studio servers and the cluster
This topic discusses the load balancer in front of the cluster (the load balancer with the callout):
- Include host names and ports
of all Oracle Endeca Servers in the load balancer configuration, including the
name and port of the leader node. This ensures that regular query-type
(non-updating) requests from Studio are sent to any of the nodes in the
cluster. Updating requests from Studio for changing the configuration should be
directed to the leader node.
If you add nodes to the cluster, you must update the configuration of the load balancer with the host names and ports of the added Oracle Endeca Servers.
For the duration of an outer transaction (which may include updates sent to the leader node), the load balancer continues sending requests to all nodes in the cluster, including the leader node.
- You may optionally configure
the load balancer to use session affinity. In this case, all queries from a
given session end up on the same Oracle Endeca Server. This allows the Oracle
Endeca Server to use its cache to avoid redundant processing on related
queries.
Configuring session affinity also helps minimize consistency problems as updates propagate from the leader to the follower nodes in the cluster (if you are not using outer transactions to run updates).
For information on configuring the data sources in Studio that allow access to any node in the cluster through a load balancer, and access to the leader node for sending updating requests, see the Oracle Endeca Information Discovery Studio User's Guide.
