How To:Run Multiple amandad processes on a Client
Because the amandad process started by xinetd needs to be configured with the "wait = yes" status, there can normally be only one running process. When sending another request to the same client, the running amandad process will reply with a "amandad busy" error message.
There are circumstances when you want more than one amandad process concurrently running on a single client. Two methods are available:
- recompile the amanda programs with alternative service names
- configuring multiple IP-addresses and bind each instance to a single IP-address
Compiling with alternative service names
Normally the Amanda programs look in /etc/services (or the NIS-server etc) for the services "amanda" (usually 10080/udp) and "kamanda" (usually 10081/tcp).
You can compile the Amanda programs with the configure option --with-testing[=suffix]:
$ ./configure ...other-options... --with-testing
The resulting binaries will now look for the entries in /etc/services with names "amanda-test", "kamanda-test" which you can give numbers like 10090 and 10091.
Or giving an explicit suffix:
$ ./configure ...other-options... --with-testing=_2
which will look for the services named "amanda_2" and "kamanda_2".
When you want to install many Amanda suits on a single computer, you should also compile them with a different "--prefix=..." so that can exist next to each other.
Note that you also need to recompile the server side programs to use the alternative names.
These features are mainly to allow for a testing environment that can coexist with the normal environment.
Binding to a single IP-address with xinetd
More suitable for production systems is to add some parameters to the xinetd configuration.
We can dedicate one amandad process to each physical network interface, or (if only one interface is available) we can add aliases or virtual IP-numbers to the existing interface. E.g. when our interface has IP-number 192.168.0.101, we can add an IP-number:
# ifconfig eth0:1 192.168.0.102 netmask 255.255.255.0
By default xinetd will listen to all interfaces, but we can bind an instance of amandad listening to one interface:
service amanda { id = amanda1 bind = 192.168.0.101 disable = no socket_type = dgram protocol = udp wait = yes user = amandabackup group = disk groups = yes server = /usr/local/libexec/amandad } service amanda { id = amanda2 bind = 192.168.0.102 disable = no socket_type = dgram protocol = udp wait = yes user = amandabackup group = disk groups = yes server = /usr/local/libexec/amandad }
We also need to add different names for the two ip-addresses in DNS, e.g. client1.example.com (IP 192.168.0.101) and client2.example.com (IP 192.179.0.102).
In the disklist on the server, we can now divide the DLE's over the two amandad processes, by simulating as if it are two diffferent clients. Note that in this case, two dumps can happen at the same time, similar to "maxdumps 2" in the dumptype of one client. To avoid trashing the single client, we make sure to add all DLE's of a single disk (spindle) to only one amandad instance:
Let's assume these mounts:
/dev/hda1 on /boot /dev/hda3 on / /dev/hda4 on /var /dev/hdb1 on /oracle
Then the disklist entries can be:
client1.example.com / comp-root-tar client1.example.com /var comp-root-tar client1.example.com /boot comp-root-tar client2.example.com /oracle comp-user-tar
This technique can be used to work with fail-over services (services bound to a virtual IP-number) if you can manage to warn xinetd when a virtual IP-number becomes activated.
Another use of this technique is to overcome the UDP packet size. When you have many DLE's for one host, the amount of data in a request could overflow one UDP packet. Simulating as if the data is on two or more hosts, can get around this limit.