Login
    Contenu x
    Load Balancing
    • 22 Nov 2024
    • 4 Minutes à lire
    • Sombre
      Lumière
    • PDF
    Contenu

    Load Balancing

    • Mis à jour le 22 Nov 2024
    • 4 Minutes à lire
    • Sombre
      Lumière
    • PDF
    The content is currently unavailable in French. You are viewing the default English version.
    Résumé de l’article

    Load balancing is a technique to spread client requests between two or more hardware servers to get optimal request throughput.

    A load balancer can be one of the following:

    • A software product to be installed on standard server hardware.
    • A solution appliance with pre-installed software, usually configurable via a web interface (e.g. Barracuda Load Balancer).

    Using multiple servers with load balancing, instead of a single server, can also increase reliability through redundancy.

    A load balancer typically exposes one virtual IP address and abstracts the IP addresses of each of its supporting servers. Each load-balanced service is assigned a specific port on the load balancer.

    A load balancer/failover device needs to make an authentication request to the OneSpan Authentication Server instance it is trying to reach to determine whether that instance is still operational. To enable this check, and to prevent this mechanism from interfering with reporting figures, the following actions must be taken:

    • Create a dummy domain.
    • Create a client component that uses a policy that will accept password-only authentications for the dummy domain.
    • Update the policy so that the client component will only accept users from the dummy domain.

    • Create a dummy user in the dummy domain:

      • The user is created with password authentication.
      • The user does NOT have admin privileges.
      • The user is in a separate domain so the keep-alive authentications cannot contaminate normal authentication figures for reporting purposes.
    • Create a static password for the dummy user.
    • Perform a SOAP authentication request from the load balancer with this user and password.

    If the OneSpan Authentication Server instance that the load balancer is trying to access is still enabled, it will send a response.

    Methods

    Two methods exist to use SSL communication between an application and OneSpan Authentication Server via a load balancer:

    Scheduling

    Most load balancers support a variety of scheduling algorithms to distribute the client requests.

    Common scheduling algorithms are:

    • Random. Each incoming client request is forwarded to a random back-end server.
    • Round robin. Incoming client requests are equally distributed to the different back-end servers. The load balancer determines the next server to send the request to by retrieving the next server entry in the list of available back-end servers.
    • Least connection. The load balancer forwards an incoming request to the server with the least number of active connections at that time.

    Monitoring frequency

    Load balancers regularly monitor the health of each server. A load balancer automatically removes an offline or otherwise malfunctioning server from the rotation, thereby preventing any authentication requests from reaching that server.

    Consider the frequency at which the load balancer should check each server carefully. While a higher frequency of health checks ensures more updated information about the server health, it also proportionally impacts the performance of OneSpan Authentication Server.

    Persistence

    An important issue when operating a load-balanced service is how to handle information that must be kept across the multiple requests in a user's session.

    If this information is stored locally on one back-end server, then subsequent requests going to different back-end servers would not be able to find it. This might be cached information that can be recomputed, in which case load balancing a request to a different back-end server just introduces a performance issue.

    One solution to the session data issue is to send all requests in a user session consistently to the same back-end server. This is known as persistence or stickiness. A large disadvantage of this technique is its lack of automatic failover: if a back-end server goes offline, its pre-session information becomes inaccessible, and sessions depending on it are lost.

    The persistence can be performed based on the following information in the client request:

    • Client IP address
    • HTTP cookie

    Authentication, provisioning, and signature validation fully support the use of a load balancer, and do not need persistence or stickiness.

    However, administrative operations that consist of more than a single step, such as DPX import, user import, key rotation, or reporting require it.

    High availability

    Each load balancer should be deployed together with a backup load balancer (mode primary-backup) to ensure high availability (no single point of failure).

    Load balancing methods

    SSL bridging

    With this load balancing method, the load balancer acts as endpoint of all connections, i.e.:

    • The SSL tunnel between the client and the load balancer (SSL tunnel 1 in the illustration).
    • The tunnels between the load balancer and each of the back-end OneSpan Authentication Server instances (SSL tunnel 2 in the illustration).
    SSL bridging (Load balancing method)

    Figure: SSL bridging (Load balancing method)

    Advantages

    Since the load balancer acts as SSL tunnel endpoint, the load balancer can introspect the client request contents and easily handle persistent sessions.

    Disadvantages

    The load balancer can introspect all sensitive information communicated by the client as it will be available in unencrypted form on the load balancer at a some point in time. This security risk should be evaluated when this setup is considered.

    Persistence

    Following persistence mechanisms are supported:

    • Client IP address
    • HTTP cookie

    SSL certificates

    This setup requires following SSL certificates:

    • One commercial SSL certificate for the client—load balancer tunnel, to be installed on the load balancer.
    • Commercial or self-signed certificates for the individual back-end OneSpan Authentication Server instances. If self-signed certificates are used, the certificates should be imported to the load balancer to establish trust with the back-end servers.

    SSL tunneling

    With this load balancing method, SSL tunnels are created between the client and the OneSpan Authentication Server.

    SSL tunneling (Load balancing method)

    Figure: SSL tunneling (Load balancing method)

    Advantages

    No data introspection possible by the load balancer.

    Disadvantages

    Not supported by all load balancers.

    Persistence

    Only persistence via the client IP address is supported.

    SSL certificates

    This setup requires one commercial wildcard SSL certificate for the different client OneSpan Authentication Server tunnels, to be installed on each of the back-end OneSpan Authentication Server instances.

    Cet article vous a-t-il été utile ?
    What's Next
    Change password!
    Changing your password will log you out immediately. Use the new password to log back in.
    Change profile
    Success!
    First name must have atleast 2 characters. Numbers and special characters are not allowed.
    Last name must have atleast 1 characters. Numbers and special characters are not allowed.
    Enter a valid email
    Enter a valid password
    Your profile has been successfully updated.
    Logout
    ESC

    Ozzy, facilitant la découverte de connaissances grâce à l’intelligence conversationnelle