tacoplexadm:
The user control interface to the system can only be executed by the root user. Commands issued via tacoplexadm are broadcast to all levelers so that a command issued on any leveler machine will propagate across all levelers. Network delivery delays will cause different levelers to accept commands at different times, but the delay will be very small and it is unlikely that a noticeable service delay will result.
Usage:
./tacoplexadm [-f file]
./tacoplexadm [-f file] -V a.b.c.d port
./tacoplexadm [-f file] -v a.b.c.d port
./tacoplexadm [-f file] -S a.b.c.d
./tacoplexadm [-f file] -s a.b.c.d
./tacoplexadm [-f file] -L a.b.c.d
./tacoplexadm [-f file] -l a.b.c.d
Commands:
none view system state
-V add virtual address
-v delete virtual address
-D add real server
-d delete real server
-L add leveler
-l delete leveler
-f use config file
|
Running tacoplexadm with no options parses an entry in the /proc filesystem and gives a human readable report that looks something like:
TacoPleX (Version 0.10) Using 32 bins. I am not the leader. Leveler: 10.0.1.1 2201450106 Leveler: 10.0.1.2 2201450106 Server: 10.0.1.101 32327 Server: 10.0.1.102 150829 Virtual: 10.0.1.200:80 183156 |
The number to the right of each leveler IP is the timestamp of the last beat received from that machine. It is used by tacoplex.monitor to detect software failure. The number to the right of each server IP is how many packets have been routed to a server by this leveler only. The number to the right of each virtual IP is the total number of packets routed to that VIP by this leveler only.
tacoplexd:
The system daemon does the majority of the work in a TacoPleX cluster. It takes one optional command-line arguement that specifies the location of the configuration file. Tacoplexd runs in the background as a system daemon and can only be executed by the root user. On startup, the daemon broadcasts its presence to the other levelers and waits for a specified time period to get the system state. After that period has expired, the daemon starts arping for packets on the shared LevIP and sending heartbeat packets to the other levelers.
Heartbeats serve a dual purpose. First, the allow detection of a leveler failure. If a heartbeat from a leveler is not received within a certain period, tacoplex.monitor will remove it from the cluster. Also, heartbeats are used to maintain the election algorithm. At one time, exactly one leveler is the leader. He is responsible for periodically broadcasting the system state and only he will make changes in hash bin assignments. Should the leader fail, the remaining levelers will arrange a new election.
An orderly shutdown of a leveler can be accomplished by signaling the daemon. An instance of tacoplexd that receives a terminate signal will remove itself from the cluster and cease sending arp and heartbeat packets.
tacoplex.monitor:
The monitor executable works within the framework of the mon architecture. It takes exactly two arguements. The first is the full path of the directory where monitors are stored (by default this is /usr/lib/mon/mon.d). The second is the amount of time in milliseconds to wait for a heartbeat from a leveler before taking it out of the system. No other arguments should be passed to tacoplex.monitor. You must specify the ;; option in your mon.cf file to prevent mon from passing additional arguements. You can call tacoplex.monitor from the command-line. It will output messages on stdout after checking the system. Tacoplex.monitor may call tacoplexadm and should therefore only be executed as root.
Tacoplex.monitor (in addition to monitoring levelers), monitors every server you specify for every virtual service. It maps standard port numbers to standard services (e.g. port 80 to http). To alter this behavior or add custom monitors, you must make changes and recompile the source of tacoplex.monitor. The mapping of ports to services is very limited and unrecognized ports are checked with a simple ping rather than a more involved monitor.
tac-o-meter:
The TacoPleX benchmarking tool is only useful for users whose servers run the Linux operating system. The source side of the system, tac-o-meter generates UDP traffic of a certain size up to a certain frequency (packets per second) using as many different port numbers as possible. It than gathers statistics from the destination machines and prints out a data summary in a format suitable for plotting with gnuplot.
Usage: tac-o-meter -t time -a addr dport [-p cport]
[-s serv]* [-i intf] [-m maxp] [-l psize]
time: how long to run the test (in seconds)
addr: destination address of test packets
dport: destination port of test packets
cport: port for communicating test results
serv: ip address of a server
intf: name of network interface for outflow
maxp: maximum number of packets to send per second
psize: size of packets to be transmitted
At least one server must be specified. All supplied
servers must be running tac-o-plexd on the correct address
and port for the test to complete.
|
The tac-o-meter ramps up load from a minimum to maxp over time seconds and keeps stats on how many packets get lost during each interval. The results answer the question: what percent of packets will be lost if my TacoPleX cluster receives x packets per second that are y bytes each? This system is only designed to test the performance of the leveling layer. Service delays (e.g. time to service an http request) are not taken into account.
tac-o-meterd:
The benchmarking daemon is meant to run on server machines in place of a service daemon. It initiates tests, gathers statistics, and reports them all under orders from an instance of tac-o-plex. The tac-o-plexd program is the only piece of software in the TacoPleX distribution that is meant to run on the server and is only available for Linux.
Usage: tac-o-meterd [-p port] [-i intf] port: destination port of test packets intf: name of network interface for outflow |