Above diagram illustrates information flow between tester and synchronizer.

On the left side of diagram there is tester (surealived),
composed of two processes - watchdog and tester.
On the right side we have the synchronizer (ipvssync), composed of a single process, connected
to IPVS.
And in the middle there are files and directories directly involved in data exchange
between tester and synchronizer.

The most important file, common to both the tester and the synchronizer is
 surealived.cfg, whose syntax will be explained in detail in  the next chapter.
It is simple key-value pair file which defines runtime parameters
for both applications mentioned above.

Tester reads its services definitions from services.xml file.
Reals view, their weights and their online/offline states are overriden by
two files - offline.dump and override.dump. Tester
saves the list of offline reals to the offline.dump, and after restart this file
is honoured so previously offlined real will be offline at start.
Second file which overrides xml config is override.dump. It can be
modified by cmd interface (drawn on the left side of the diagram),
listens on a port, allowing you to perform some interesting
commands on the tester while it's running. It is described in next chapter 

When the tester starts it forces rebuilding of synchronizer configuration ipvsfull.cfg and initiates saving of diff files in
diffs directory. The point is to only save the difference (rather than the entire configuration file) for every time a real server goes down. That's why
 ipvsfull.cfg file is changing every 60 seconds and all changes
relative to the main configuration are kept in last, difference file. The other two important
files are mutex file ipvsfull.lock and the reload flag ipvsfull.reload.
After tester restart, IPVS state is unknown from tester's point of view, that's why
after rebuilding ipvsfull.cfg it flags to synchronizer to reconfigure
whole IPVS table. Presence of file ipvsfull.reload is constantly searched for by

 ipvssync and if it finds that file it will read the new configuration,
synchronize to IPVS and remove the flag. During its operation, synchronizer remembers which diff file it is working on (current diff file) and removes all old diff files in diffs directory.

Tester also has an ability to save test statistics in stats
directory. It can save stats to one common file sd_fullstats.log as well as to
separate sd_virtstats*.TIMESTAMP files. When you decide to use
single test statistics files be careful - stats directory will
grow very fast.

Starting tester

In order to create synchronizer's config file ipvsfull.cfg,
it is necessary to run tester at least once before running synchronizer for the first time,

To see all possible tester options use -h switch.

wegorz@zaphod:~$ surealived -h
=== SureAliveD v.0.8.7 ===
Usage: surealived [options] <xml_config_file
Ex   : surealived -c /root/sd_new.conf -vv -d test_http.xm
        --help          -h              This help info
        --test-config   -t              Test configuration and exit
        --config        -c <path>       Use <path> as config file
        --verbose       -v              Increase verbosity level
        --daemonize     -d              Run in background (daemonize)
        --no-sync       -n              Do not write sync info
        --no-dumpfile   -k              Do not load and create offline.dump
        --version       -V              Show Version information

-t is a very useful option - it allows you to
check services xml config syntax. Return codes are standard
0 - ok, not equal to 0 - error.


Typically in production environment, the tester will be run as daemon:

wegorz@zaphod:~$ surealived -d /etc/surealived/services.xml

You need to remember, that executing tester as a daemon will cause all error
messages to be saved to /var/log/surealived/surealived.log
only if tester can write to that file. Therefore it's recommended to run the tester
in the foreground first to make sure it won't be running into problems when it will be
executed as daemon:

wegorz@zaphod:~$ surealived -vvv /etc/surealived/services.xml


Starting synchronizer

The synchronizer can only be started if its configuration file exists. It needs to be run from the root account, because it needs root privileges to modify IPVS.

To see the list of all possible options which can be used during synchronizer start-up
use -h switch.

zaphod:~# ipvssync -h
=== IPVSSync v.0.8.7 ===
Usage: ipvssync [options]
Ex   : ipvssync -c /home/surealived/surealived.cfg

        --help          -h           This help info
        --test-config   -t           Test ipvsfull.cfg configuration and exit
        --config        -c           Config file (default /etc/surealived/surealived.cfg)
        --verbose       -v           Increase verbosity level
        --daemonize     -d           Run in background (daemonize)
        --del-umanaged  -u           Delete unmanaged virtuals from IPVS table
        --keep-diffs    -k           Don't remove processed diff files
        --version       -V           Show Version information

Before we start the synchronizer, we can validate ipvsfull.cfg
syntax using -t option.
Return exit codes are standard: 0 - ok, not equal to 0 - error.

Options which change synchronization runtime behaviour are -u and -k.
First of them causes, ipvssync to remove all virtuals not listed in its
configuration file. So if you add a virtual to IPVS by hand, your changes will be removed from IPVS when synchronizer reloads its configuration. Second mentioned option
turns off removing old diff files from diffs directory.

Some notes about starting applications

It is recommended to set logging to info detail level in production environments. This level will provide you with most useful information regarding tester's and synchronizer's runtime status. When trying out a configuration, it's better to start these applications in foreground and use '-vvv' and have all messages written to stdout.