Considerations for Sticky Sessions on a Vultr Load Balancer

Introduction

When using the Vultr load balancer as a service (LBaaS), you can turn on sticky sessions to create an affinity between clients' applications, such as a web browser, and your backend services for the duration of a session.

In this model, the Vultr LBaaS assigns an identifying attribute in the form of a cookie to a client's session to make sure the same server serves them during the lifetime of a session.

You can leverage the power of this session persistence in scenarios where your backend application serves personalized data to clients, for instance, in an online shopping cart or a chat application. However, without session stickiness, you must design a way to replicate session data across all backend servers. This is costly and inefficient in terms of resource utilization unless you're using modern technologies designed for this purpose.

The Vultr LBaaS provides you with an option to activate the session stickiness with a single click of a mouse. However, since this is not suitable for all use cases, this guide highlights the different considerations that you should make before turning on session persistence in your applications.

Cookie Support for Frontend Applications

Sticky sessions keep session data at a minimum by reducing data exchange across the backend servers. When a client connects to the load balancer for the first time, the request is routed to a backend server depending on the chosen algorithm: round-robin or least connections method.

Then, your backend application generates a time-based cookie and places it in an HTTP header. Before the cookie is sent back to the client, the load balancer creates another cookie on top of your application cookie but follows the lifetime of your app cookie. The load-balancer cookie contains encrypted information about where subsequent requests bearing this cookie will be routed to.

Now, every time a client sends a request to your application, the load balancer examines the parameters of the cookie and routes the session-based request to the same server where it originated. This is very efficient since users will never be routed to a different server before their session cookies expire.

With the above workings in mind, it is clear that your frontend application must support cookies. So, sticky sessions are suitable for browser-based applications, and they can't work with stateless applications like REST-based APIs, where every HTTP request happens in complete isolation.

Data Loss and Scalability Issues

While the Vultr LBaaS uses modern algorithms to ensure accurate load distribution between the backend servers, session stickiness may sometimes make balancing servers difficult.

For instance, some resource-hungry clients' requests may be persisted to the same server during the lifetime of a session. Then, the server can become overloaded, forcing the load balancer to shift incoming clients' requests to a different server in the middle of a session. This may result in data loss since the new server doesn't have a copy of the session data.

Another point worth mentioning is that when you turn on sticky sessions, you're simply telling the load balancer to bind session-based requests to specific servers. This limits the load-balancers ability to route subsequent connections to other less busy servers. This may lead to scalability issues and poor utilization of the backend servers.

Maintenance Issues

Sticky sessions ensure your clients continue to receive personalized session information by sending requests to the same backend instance where the first request was made. In simple terms, session persistence keeps track of which backend server processes which request.

In the above approach, the different clients' personalized information is fragmented across different backend servers. Therefore, if some servers become unresponsive/unhealthy or you want to bring them down for maintenance purposes, your clients will lose their data in the middle of the sessions, and they might get disconnected from the app.

As mentioned earlier, if your application logic depends on the session data and is somehow lost, it can lead to a poor user experience. However, if the session data is less important, this is not an issue. For instance, if you're using the session data to determine the login status of a client and one server clashes, clients will be prompted to log in again. However, since this may not happen quite frequently, it may not pose a threat to your application. Therefore, using session stickiness is recommended.

Conclusion

In conclusion, session stickiness is suitable in scenarios where your application does not use any form of session replication across the backend servers. In other words, you should turn it on if the only method of saving session data in your backend server is only through the server's RAM. The fragmented data ensures that you're not flooding your cluster with session data.

However, switching off session stickiness is recommended if you've implemented a more intelligent approach where your backend servers can read and write session data in a centralized layer.