[OpenAFS] Re: Questions about multihoming servers

[Andrew Deason]

On Wed, 25 Sep 2013 16:09:07 +0000
Mark Vitale <mvitale@sinenomine.net> wrote:

> On Sep 25, 2013, at 11:33 AM, Jeffrey Altman <jaltman@your-file-system.com> wrote:
> 
> > Go back to the original posting.  The reason for adding multiple
> > interfaces was to increase throughput on the server.  If only one
> > address is used for UBIK replication that is not multihomed support.

Every post from Stephen I can see is just about whether the servers work
at all in this configuration, nothing about taking advantage of the
extra IPs. Ticket 15640 is certainly about it just not working at all
(quorum isn't reached, even though everything is available).

So my answer to Stephen is "yes", it's supposed to work. If it doesn't,
that's a bug; if 15640 still occurs, that's a bug. It's not something
requiring architectural redesign or anything new, but just a bug. (Well,
probably; obviously I don't know what's _causing_ it if it's still a
problem, so maybe it's harder to fix than I think.) NetInfo/NetRestrict
are not supposed to be required if all of the IPs are equally public;
you don't need to do anything special, and there are no extra steps. The
dbservers will detect their own multiple addresses automatically and
handle them appropriately.

> If we are only talking about toleration support for multihomed DB
> servers, that could be covered by what Andrew described.
> 
> Exploitation support for multihomed DB servers could be what Jeff is
> describing - the ability to not only tolerate the presence of multiple
> interfaces without breaking, but actually exploit the increased
> potential throughput.

Either increased throughput or redundancy; we don't support either with
dbservers (with the sort-of exception of adding extra IPs in the client
csdb, which I don't think I would recommend). The extra addresses are
just "there", and we have enough support for them so that things should
still work. But they don't add anything.

And yes, thank you for that summary.

-- 
Andrew Deason
adeason@sinenomine.net