Load Balancing
- 22 Nov 2024
- 4 Minutes to read
- DarkLight
- PDF
Load Balancing
- Updated on 22 Nov 2024
- 4 Minutes to read
- DarkLight
- PDF
Article summary
Did you find this summary helpful?
Thank you for your feedback
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:
- SSL bridging (see SSL bridging).
- SSL tunneling (see SSL tunneling).
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).
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.
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.
Was this article helpful?