LBCD(8) | lbcd | LBCD(8) |
lbcd - Report system load for remote load balancing
lbcd [-dfhlRtZ]
[-a allowed-service [-a allowed-service]]
[-b bind-address [-b bind-address]]
[-c command]
[-P file] [-p port]
[-T seconds]
[-w weight]
lbcd -t [v2] [service ...]
lbcd runs as a daemon and reports various system utilization information and optionally service status information via a UDP network protocol. It is designed to run on the client systems of a remote load balancing system, such as the DNS-based lbnamed load balancer.
lbcd supports two different query protocols, version two and version three. (Currently, lbnamed only supports version two queries.) Either will return the current time according to that system, the time of the last system boot, the time the information about logged in users last changed, the load averages (one, five, and fifteen minute), the total and unique logged in users, whether a user is logged in on console, percentage full of the system /tmp directory is full, and percentage full of the system /var/tmp directory. (See, however, the note below about how some of this data is replaced with calculated weights for version two responses.) The version three protocol can also return weight and increment information about a set of services.
The service information is based around a model that returns a weight (indicating the current utilization of the box -- the higher, the busier) and an increment (an estimate of how much the utilization will increase for each additional connection directed to this box) which defaults to one. The intent is for the load balancer to query the system periodically, using the returned weight as the system load, and to estimate the system load between queries of lbcd as the last returned weight plus the last returned increment times the number of connections directed to that system.
By default, only one service is returned. That default service weight is calculated as follows:
(<uniq-users> * 100 + 300 * <one-minute-load> + (<total-users> - <unique-users>) * 20) * <tmp-penalty>
where <tmp-penalty> is a multiplier applied for the most full of /tmp and /var/tmp. <tmp-penalty> will be 1 if both are less than 90% full and will range between 2 for 90-93% full up to 32 for 100% full. If /tmp or /var/tmp are completely full, the maximum possible weight will be returned. Different algorithms for determining the weight can be used instead; see the -w option.
If you want to use a simple load average instead, pass the -S option to lbcd and then the load service will use only the one-minute load. If you want every system running lbcd to return the same load, use the -R option.
If the file /etc/nolbcd exists, lbcd will force the weight of the default service to the maximum value regardless of the normal service calculation. This allows one to effectively remove a host from a load-balanced pool by touching a file without having to stop the lbcd daemon.
Since lbnamed calculates the weight from the one minute load and the number of logged-in users and currently only supports version two, lbcd will replace the one-minute load with the weight of the primary service when responding to a version two query and will set all of the user numbers to zero unless -S was given. If -S was given, the values returned will be left alone. (This means that -S will override -R for version two queries, since -R is equivalent to specifying a service of "rr".)
lbcd responds to any UDP packets on port 4330 (or the port given with the -p option). It has no built-in security, so if you do not want to disclose the above information to random systems on the Internet, you will want to limit access to this port using iptables, firewall rules, or other similar measures.
By default, lbcd listens on all addresses and responds on whatever address the kernel picks for outgoing packets. lbnamed sends out all of its packets and then waits for replies and uses the source address of the reply packet to associate that reply with one of the queried hosts. This means that if lbnamed is not configured to query the same address as the kernel picks for lbcd to respond on, the response may be ignored and the host considered down. To work around this, use the -b flag on hosts with multiple interfaces to ensure that replies go out on the interface being queried. If a host has multiple IP addresses that will be queried, run multiple instances of lbcd, one for each interface.
For a list of the supported services, and therefore the allowed values for allowed-service, see the -w option.
Client queries are compared exactly against the allowed-service values, including any port information after a colon, so all service values that should be queryable must be listed using this option.
This option is ignored if lbcd is passed already open sockets via the systemd socket activation protocol. In that case, the bind addresses of the sockets should be controlled via the systemd configuration.
This option is ignored if lbcd is passed already open sockets via the systemd socket activation protocol. In that case, the listening port should be controlled via the systemd configuration.
When run with this option, the remaining command-line arguments are taken as services to probe. The valid service names are the same as the valid service arguments to the -w option, with one exception. If the first service is the string "v2", lbcd will behave as if it received a protocol version two query packet and will manipulate its reply information accordingly before printing it out.
The currently supported services are "load" (the default), "ftp", "http", "imap", "nntp", "ntp", "pop", "smtp", "tcp", and "rr" (round-robin, the same as -R). The "http" and "tcp" services must be followed by a colon and a port number.
This option only affects the default service. A version 3 protocol client can query any of the supported services provided that the service is listed as allowed, using the -a flag. This allows the client to get weight and increment information for several different services.
Run lbcd as a daemon, using the default load service, and writing a PID file to /var/run/lbcd.pid:
lbcd -P /var/run/lbcd.pid
Run lbcd in the foreground, and log all client requests via syslog. This is a typical invocation with systemd, using socket activation.
lbcd -f -l
The same, but raise SIGSTOP after lbcd is ready to answer queries. This is a typical invocation with upstart.
lbcd -f -l -Z
Run lbcd as a daemon, with default behavior, but use round-robin as the default service. This will equally balance queries across machines instead of trying to be sensitive to load.
lbcd -R
Determine the weight of the system based on whether the local HTTP port is responding. If it isn't, the system will return the maximum weight, which will cause it to drop out of the pool.
lbcd -w http:80
Run the external program /usr/bin/lb-slapd to determine the weight.
lbcd -c /usr/bin/ldap-check
This program should print, to standard output, two numbers separated by a space. The first will be the weight and the second will be the load. In this case, it does a query against a local LDAP search to determine its health. (A good approach for LDAP slaves would be to check the syncrepl data to see if the slave is up-to-date.)
Note that using socket activation is recommended when running under systemd, and status notification is not necessary or useful when using socket activation.
Originally written by Roland Schemers and Larry Schwimmer. Currently maintained by Russ Allbery <eagle@eyrie.org>.
Copyright 1993, 1994, 1996, 1997, 1998, 2000, 2003, 2004, 2005, 2006, 2009, 2012, 2013, 2014 The Board of Trustees of the Leland Stanford Junior University
Copying and distribution of this file, with or without modification, are permitted in any medium without royalty provided the copyright notice and this notice are preserved. This file is offered as-is, without any warranty.
lbcdclient(1)
The current version of this program is available from its web page at <http://www.eyrie.org/~eagle/software/lbcd/>.
2015-04-26 | 3.5.2 |