Introduction #

What is BalanceNG? #

BalanceNG (“Balance Next Generation”) is a Software Load Balancing Solution utilizing its own network stacks and functionality. In fact, BalanceNG uses the underlying operating system only for accessing the physical interfaces, all IP and other functionality (like ARP, ND6 and ICMP) is being processed internally.

BalanceNG runs as a user mode program using the PF_PACKET API on Linux operating systems and the BPF API on macOS to access the network interfaces as directly as possible.

With BalanceNG the Network or Data center Administrator is capable to build high availability capable load balancing devices at a very low and very competitive price (compared to dedicated hardware boxes / Load Balancing Appliances).

BalanceNG Feature Overview #

• Layer 2-4 based load balancer.
• Available for various Linux distributions and macOS.
• Capable to run in multiple instances on the same host.
• Session persistence based on client address and optional source port.
• Backup targets (hosts) specifiable in case of failure of all primary targets.
• Health checking via: PING, TCP Socket Open and freely customizable UDP Health Check Agent (supplied in Source-Code).
• External target specific health check scripts.
• Alert/Upalert notification scripts (e.g. for sending email or sending a SNMP trap to a network management system).
• Distribution methods: Round Robin, Simple Weighted Round Robin, Random, Weighted Random, Client Address Hashing, First Operational, Least Session, Least Bandwidth and Least Resource based on agent supplied information.
• Unchanged client addresses on IP-level.
• Supports DSR (Direct Server Return) configurations.
• Small, very fast and reliable.
• Simple to implement and administer.
• Simple “init script style” arguments like “start”, “stop” and “status” (and “control” for interactive configuration and control).
• Interactive communications mode with command line editing.
• Pcap packet dumping with automated dumpfile rotation (e.g. to implement a “transparent forensic logging bridge”).
• Multi-node High Availability capability using standard VRRP (Virtual Router Redundancy Protocol).
• Session table synchronization and connection state replication using a BalanceNG- specific VRRP extension.
• “All services load balancing” based on client IP address enables most protocols to be supported (e.g. active FTP, RTSP/RTP/RTCP streaming protocols etc). SNMP Support integrating into Net-SNMP .
• Layer 3 link load balancing to a set of outbound routers or ISP links.
• Supports up to 512 virtual servers and up to 1024 targets (real servers).
• Location-Based Load-Balancing Support.
• In-memory IP-to-Location database.
• DNS-based GSLB-support (Global Server Load-Balancing).

Hardware and OS Requirements #

BalanceNG can be installed on different hypervisors and “bare metal” and with all important Linux distributions. The installation of ethtool is recommended, but not a required dependency.

In general, you are good to go with the following:

• 4GB of RAM (the memory footprint of BalanceNG itself is far less)
• One core per 1GbE interface
• 4 cores per 10GbE interface

BalanceNG Core Concepts #

Interfaces #

Interfaces are the physical hardware interfaces to one or more networks. They are named like the underlaying Linux kernel names them and have a unique identication number for BalanceNG.

BalanceNG uses the interfaces that it is allowed to use, this is done by specifying a corresponding interface section.

Interfaces don’t have to be “up” or configured, BalanceNG performs all necessary administrative tasks automatically. Also it is neither required or necessary to configure interface addresses in the Linux operating system.

Networks #

Networks are IP network definitions the have a network address and a network mask. Additionally one or more interfaces are being referenced by the BalanceNG network definition.

On a UNIX system an interface has one or more associated network definitions and addresses, in the BalanceNG world this relation is reversed: One network definition (and the addresses) are associated to one or multiple interfaces.

Each network definition additionally has to have two required IP addresses: The real address being used for ARP-requests and health checks and the virt address being addressable as a routing endpoint for external devices. The real network address has to be node specific, the virt address has to be shared between multiple BalanceNG nodes in a VRRP HA configuration. Similar definitions apply for IPv6 where the addresses are named real6 and virt6 (and ND6 is used instead of ARP).

Servers #

Servers are the addressable “virtual Servers” in the BalanceNG world. Servers are “virtual” or “artificial” IP (4 and 6) addresses represented by BalanceNG. Network requests to those servers are distributed among the targets according to the load balancing definitions.

Servers may be defined in any BalanceNG network referencing targets in any BalanceNG network.

BalanceNG servers would be called “virtual servers” by other load balancing software vendors.

Targets #

BalanceNG represents one or more virtual servers and distributes the requests among a set of targets associated with each virtual server.

BalanceNG targets would be called “real servers” by other load balancing software vendors.

Modules and the Module Chain #

BalanceNG implements several packet handling modules. The functionality of BalanceNG is defined by the module chain, which defines a sequential order of modules. Each packet enters that module chain at the left side and is forwarded until a module gains responsibility for that packet.

After some processing, the module in charge may decide to stop processing or may decide to forward a possibly changed packet to the next module in the module chain.

Threads #

BalanceNG operates multi-threaded when the multi-threading packet scheduler is activated (which is the recommended default). The packet processing of each BalanceNG interface may be processed by 1 to 8 simultaneous threads.

Configuration and Configuration Files #

The behavior and actions of BalanceNG are controlled by its internal configuration. This configuration may be altered in interactive mode by entering configuration commands. An external representation of this configuration may be saved to /etc/bng.conf, BalanceNG loads an existing configuration in /etc/bng.conf automatically at startup (for the default instance 0).

A BalanceNG configuration consists of the following sections in exactly that order:

1. hostname, remark, license
2. module chain definition
3. parameter settings (“set”-section)
4. interfaces section
5. interfaces register/enable section
6. vrrp-section
7. network definitions
8. network register/enable section
9. IPDB section
10. lgrp (Location Group) section
11. gateway section
12. server definitions
13. server register/enable section
14. target section
15. target register/enable section

BalanceNG makes use of the following configuration files:

It’s safe to copy the main configuration file (/etc/bng.conf) from a master node to the backup if the node private data has been saved on the other side before (save private). This allows easy implementation of configuration synchronization scripts between nodes of the same VRRP virtual router.

Instances #

BalanceNG may be started independently multiple times on the same host machine (node). Each invocation is called an instance of BalanceNG and has an unique instance number in the range of 0 … 127. BalanceNG instance 0 is called the default instance.

IPDB, Locations and Location-Groups #

BalanceNG supports a very efficient, in-memory IP-to-Location database (IPDB). This database associates ranges in the IPv4 and IPv6 address space to a set of locations, which are usually 2-Letter codes as “US”, “DE” and “AT”, for example.

These location may be logically grouped using the BalanceNG “location groups” (LGRP’s). Eventually, a target may be a member of exactly one location. The whole feature set allows easy setup of “location based server load balancing”.

Parameters #

BalanceNGs behaviour can be controlled and fine-tuned by a set operational parameters, which are all initialized with an individual, proven and recommended default setting. If a parameter is changed and its value is no longer its default, this new setting appears in the parameter (“set”) - section in the running configuration and also in the configuration file (when saved).