Skip to main content
ExLibris
  • Subscribe by RSS
  • Ex Libris Knowledge Center

    Load Balancer Requirements

    Load Balancer Requirements

    Purpose

    Load-balancing functionality can be achieved by either hardware or software components. The purpose of this section is to describe the functional aspects of the load balancer as used by Rosetta regardless of whether it is a hardware or software solution.

    Sticky Session

    Session stickiness must be provided by the load balancer.
    A load balancer redirects end users, identified by source IPs, to the same physical Deposit server, during a single user session.

    Forwarding

    Configure the load balancer to pass the client's IP address in the X-Forwarded-For HTTP header value.

    Load Balancing Web Requests

    In any of the supported topologies, a load balancer should be defined for each Fully Qualified Domain Name (FQDN). A separate FQDN is required for each module/role that must be accessed separately. The following modules can be accessed separately:
    • PDS
    • Deposit
    • Back Office
    • Delivery
    Configure the load balancer to redirect all requests to the specified domain names to be forwarded to the real server which made up the cluster (for example, port 1801). For example, requests to http://delivery.rosetta.myorg.org/ should redirect to http://delivery1:1801 and http://delivery2:1801.
    If your topology requires that the Web service response includes the load balancer hostname (and not a specific application server hostname), make sure the load balancer forwards the request's original host header (for example, the mod_proxy ProxyPreserveHost directive is turned on).
    All UI and Web service requests are directed to the appropriate load balancer FQDN as defined in global.properties. For further details, see Managing Application Roles and Other Server Settings.

    Worker Pools for Back-End Activities

    Workers are managed by the database direct communication with the application servers. No load balancer is necessary. Users can manage the number of workers (threads) that run on each server in order to optimize the performance of the system. For further details, see Managing Workers.
    • Was this article helpful?