Bobcares

How to Dynamically Add Backends in HAProxy without Downtime

by | Sep 27, 2024

Learn how to add backends to HAProxy without downtime dynamically. Our HAProxy Support team is here to help you with your questions and concerns.

How to Dynamically Add Backends in HAProxy without Downtime

HAProxy, a versatile load balancer and proxy server written in C> it is well known for being reliable, fast, secure, and easy to configure.

How to Dynamically Add Backends in HAProxy without Downtime

Whether managing traffic for multiple backend servers or creating complex routing logic, HAProxy shines in its simplicity and power.

Today, we are going to explore setting up HAProxy for routing RESTful API requests using a frontend-backend model, based on custom headers. We also take a look at how to handle traffic dynamically with the Runtime API and dynamic configuration updates.

An Overview:

  1. Set Up HAProxy with Custom Backend Routing
  2. HAProxy Runtime API: Real-Time Server Management
  3. Reconfigure Backends Dynamically
  4. Security Best Practices for HAProxy Configuration

Set Up HAProxy with Custom Backend Routing

Imagine we have a frontend named `fe_main` and several backend servers (`be_alpha`, `be_bravo`, `be_charlie`, and `be_delta`). We’ll configure HAProxy to route traffic based on the `X-API` request header.

If a request contains the `X-API` header, HAProxy will map it to a specific backend. If not, it will default to `be_delta`.

The setup begins with a simple frontend configuration:

frontend fe_main
bind 192.168.1.100:80
mode http
acl xapi_header req.hdr(X-API) -m found
use_backend %[req.hdr(X-API),lower,map(/etc/haproxy/api.map,be_delta)] if xapi_header
default_backend be_delta

In this configuration:

  • The `acl xapi_header` checks for the presence of the `X-API` header.
  • `use_backend` sends requests to the mapped backend, defined in `/etc/haproxy/api.map`.
  • Requests without the `X-API` header are sent to the default backend `be_delta`.

HAProxy map files play a key role in simplifying complex routing decisions by externalizing them from the primary configuration. Instead of hardcoding routing logic directly into the haproxy.cfg file, map files allow administrators to map specific values to corresponding backends.

This keeps the configuration clean and modular and allows dynamic updates without restarting HAProxy.

Here is a Map File example:

# X-API value | HAProxy backend
v1.0 be_alpha
v1.1 be_bravo
v2.5 be_charlie
v2.2 be_alpha

The map file pairs `X-API` header values with backend servers, enabling a dynamic and easy-to-maintain setup.

Here are a few tips for maintaining HAProxy map files:

  • Organize mappings logically to ensure easy updates and maintenance.
  • Comment on the map files extensively to explain complex routing logic.
  • Also, monitor the size of map files as large files can increase lookup times, impacting performance.
  • Furthermore, use the dynamic reloading feature to update map files without service interruptions.

HAProxy Runtime API: Real-Time Server Management

HAProxy’s Runtime API allows real-time interaction with the HAProxy server for seamless management of traffic. Here’s how we enable it:

global
stats socket ipv4@127.0.0.1:9999 level admin
stats socket /var/run/haproxy.sock mode 666 level admin
stats timeout 2m

With the Runtime API, we can manage your servers dynamically without restarting HAProxy. For example, we can gradually drain traffic from a server:

# Drain traffic
set server be_alpha/alpha_server state drain
# Re-enable server
set server be_alpha/alpha_server state ready

This makes traffic management smoother, ensuring minimal disruption.

Reconfigure Backends Dynamically

Dynamic reconfiguration of HAProxy lets us modify backend routing without downtime. Here’s an example where HAProxy directs traffic based on URL path segments:

frontend main
bind *:80
use_backend %[path,fields(2,/)]
backend backend1
reqrep ^([^\ :]*)\ /backend1/(.*) \1\ /\2
server foo 192.168.1.200:80
backend backend2
reqrep ^([^\ :]*)\ /backend2/(.*) \1\ /\2
server bar 192.168.1.201:80

By examining the URL path, HAProxy intelligently routes requests to the appropriate backend. For even more flexibility, we can define a list of all backends in a file (`all_backends.txt`) and use the `acl` directive to control routing based on dynamic conditions.

Security Best Practices for HAProxy Configuration

Security should be a top priority when configuring HAProxy, especially since it sits between users and backend servers, handling sensitive traffic.

A misconfigured HAProxy instance can expose our infrastructure to a variety of threats, including data breaches, unauthorized access, and man-in-the-middle attacks. Here are several best practices to secure our HAProxy configuration:

  • Encrypt all traffic between clients and HAProxy to protect sensitive data. HAProxy supports SSL termination, allowing it to handle SSL certificates and decrypt HTTPS traffic before passing it to backend servers. We can configure this in the frontend section of haproxy.cfg:

    frontend https_in
    bind *:443 ssl crt /etc/haproxy/certs/cert.pem

  • HAProxy’s Runtime API allows real-time control over configuration and monitoring, but it can also be a security risk if improperly configured. To protect the API:
    • Use strong access controls, restricting access to trusted IPs or networks.
    • Also, enable user authentication for API commands that modify the configuration.
    • Avoid exposing the API over unsecured public networks by using Unix sockets or limiting the API to internal interfaces only.
  • Ensure that only trusted users can access HAProxy’s administrative functions. Restrict access to the statistics page by requiring basic authentication.
  • Use ACLs to block malicious traffic, such as SQL injections, cross-site scripting, and DDoS attacks.
  • Set up comprehensive logging to monitor traffic and detect suspicious activity. Enable logging of HTTP headers and SSL information to identify potential attacks.

[Need assistance with a different issue? Our team is available 24/7.]

Conclusion

HAProxy is a robust tool for managing and routing traffic in complex architectures. By leveraging frontends and backends, dynamic reconfiguration with map files, and real-time management via the Runtime API, HAProxy becomes a powerful solution for scaling applications, ensuring high availability, and optimizing performance.

In brief, our Support Experts demonstrated how to dynamically add Backends in HAProxy without downtime.

0 Comments

Submit a Comment

Your email address will not be published. Required fields are marked *

Never again lose customers to poor
server speed! Let us help you.

Privacy Preference Center

Necessary

Necessary cookies help make a website usable by enabling basic functions like page navigation and access to secure areas of the website. The website cannot function properly without these cookies.

PHPSESSID - Preserves user session state across page requests.

gdpr[consent_types] - Used to store user consents.

gdpr[allowed_cookies] - Used to store user allowed cookies.

PHPSESSID, gdpr[consent_types], gdpr[allowed_cookies]
PHPSESSID
WHMCSpKDlPzh2chML

Statistics

Statistic cookies help website owners to understand how visitors interact with websites by collecting and reporting information anonymously.

_ga - Preserves user session state across page requests.

_gat - Used by Google Analytics to throttle request rate

_gid - Registers a unique ID that is used to generate statistical data on how you use the website.

smartlookCookie - Used to collect user device and location information of the site visitors to improve the websites User Experience.

_ga, _gat, _gid
_ga, _gat, _gid
smartlookCookie
_clck, _clsk, CLID, ANONCHK, MR, MUID, SM

Marketing

Marketing cookies are used to track visitors across websites. The intention is to display ads that are relevant and engaging for the individual user and thereby more valuable for publishers and third party advertisers.

IDE - Used by Google DoubleClick to register and report the website user's actions after viewing or clicking one of the advertiser's ads with the purpose of measuring the efficacy of an ad and to present targeted ads to the user.

test_cookie - Used to check if the user's browser supports cookies.

1P_JAR - Google cookie. These cookies are used to collect website statistics and track conversion rates.

NID - Registers a unique ID that identifies a returning user's device. The ID is used for serving ads that are most relevant to the user.

DV - Google ad personalisation

_reb2bgeo - The visitor's geographical location

_reb2bloaded - Whether or not the script loaded for the visitor

_reb2bref - The referring URL for the visit

_reb2bsessionID - The visitor's RB2B session ID

_reb2buid - The visitor's RB2B user ID

IDE, test_cookie, 1P_JAR, NID, DV, NID
IDE, test_cookie
1P_JAR, NID, DV
NID
hblid
_reb2bgeo, _reb2bloaded, _reb2bref, _reb2bsessionID, _reb2buid

Security

These are essential site cookies, used by the google reCAPTCHA. These cookies use an unique identifier to verify if a visitor is human or a bot.

SID, APISID, HSID, NID, PREF
SID, APISID, HSID, NID, PREF