John,

This is exactly what we are thinking of doing at my site.

We are looking at a trival method of dividing up the amanda
disks - group 1) local to server, group 2) remote clients.

With lots of local disk, fiber channel... this sort of makes
sense and will allow us to utilize both of our (locally attached)
jukeboxes.

Since one amanda will never actually touch the ethernet interface
is there another method or work-around we should know about ?

I've never had to compile with alternate ports before, assuming
its ./configure --with-port= or some equiv, if there a howto
on exactly what switches and other considerations ?

How do I choose ports without risking collision with anything else ?

                                                thanks,

                                                Brian

---
   Brian R Cuttler                 brian.cuttler AT wadsworth DOT org
   Computer Systems Support        (v) 518 486-1697
   Wadsworth Center                (f) 518 473-6384
   NYS Department of Health        Help Desk 518 473-0773




> >I'm not sure its possible to run concurrent Amanda's (at least not
> >without compiling different versions using different ports, etc).
> 
> It depends a little on your environment.  If you can partition the clients
> into separate groups (i.e. the same client is not in more than one Amanda
> configuration), you can run multiple Amanda servers at the same time.
> I used to do this quite a bit through our robot with several tape drives.
> 
> If you cannot easily divide up the clients, then, as Chris Karakas says,
> there is a *high* probability multiple servers will go after the same
> client at the same time and only one will "win".
> 
> We need to do this here for our end of semester checkpoint (full dump), so
> I wrote a very small patch to add a "servicename" entry to amanda.conf.
> It lets me tell a given configuration to use (e.g.) "amanda-alt1"
> instead of "amanda" as the service to connect to on the client.  This is
> essentially a runtime version of the AMANDA_SERVICE_NAME configuration
> time variable.  Then I have multiple inetd entries listening on all the
> potential services.  Works great.
> 
> I haven't put this change into the source tree because it's a hack and
> I think the whole arrangement should be thought through again, but if
> anyone wants it:
> 
>   http://www-rcd.cc.purdue.edu/~jrj/Backups/servicename.diff
> 
> Or (since this web server appears to be down at the moment):
> 
>   ftp://gandalf.cc.purdue.edu/pub/amanda/servicename.diff
> 
> I don't recall what version of Amanda this applies to, but it's a trivial
> change that should be easy to tweak to fit.
> 
> >Frank
> 
> John R. Jackson, Technical Software Specialist, jrj AT purdue DOT edu