OpenBSD's base install delivers two mechanisms for load-balancing traffic:
carp(4) allows multiple hosts to share ip addresses. Load Balancing amongst a group of carp hosts is achieved through ARP balancing and IP balancing.
Balancing network traffic between hosts should be transparent to the source and destination. The the interdepence of those servers determine the complexity required of the load balancer solution.
For example, services with no interdepence between multiple servers (such as static/image web sites, download servers, MX Proxies) can be readily scaled through adding more boxes to the service pool.
In practise we use relayd(8) load-balancing such that we can use commodity desktop machines to provide high availability for:
With multiple hosts sharing IP Addresses through carp(4) these hosts can service ip traffic through:
- IP Balancing
- ARP Balancing
OpenBSD Firewalls (OpenBSD 4.6 onwards) uses pfsync(4) to share state information to support stateful Load Balancing.
If all your hosts run OpenBSD, then you can get the above Load Balancing functionality through carp.
Most, picture Load Balancing using a device in front of multiple services/hosts. This 'device' is usually pictured as independent (separate) from the services/hosts effected by the "load balancing". This is the Man in the Middle scenario:
relayd(8) supports ISO Layer 3 and/or Layer 7 forwarding.
Similar Open Source tools for load balancing include:
- Layer 3,
- PFE: Packet Filter Engine
- Layer 7, Application Level, Load Balancing
- Parent Process
- HCE: Host Check Engine
- Relay Engine
PFE: PF Engine
At ISO Layer 3, the Packet Filter Engine allows integration with the OpenBSD's Packet Filter.
- Create and destroy PF rules
- Update PF tables based on HCE notifications
Layer 7, Application Level, Load Balancing
- Man-in-the-middle approach
- allows packet processing
Using a parent process, with 'root' privileges, is configured in OpenBSD with a userlevel application for making safe changes to the relay schedule.
- Handle configuration loading and reloading
- Handle external script execution
- Handle carp demotion requests
HCE: Host Check Engine
The Host Check Engine is a methodology to verify that the target host service is functional, before routing traffic to the host.
- Mono-process, fully asynchronous checks
- Schedule checks and notify PFE of state transitions
- Create listening sockets for services
- Filter protocols before relaying
- Calomel.org's Relayd Proxy
- Me in IT's OpenBSD loadbalancing and failover with relayd, pf and carp