[OpenAFS] Re: Questions about multihoming servers
Wed, 02 Oct 2013 11:34:23 -0400
On Wed, 2013-09-25 at 11:33 -0400, Jeffrey Altman wrote:
> All that logic does is IP address aliasing for the purpose of elections.
> However, it does not permit the use of multiple addresses. UBIK does
> not distribute RPCs across all of the DISK_UpdateInterfaceAddr() listed
> addresses. It always uses the address in the CellServDB. AND you
> cannot put multiple addresses for a server in the server's CellServDB.
No. It always _starts_ by using the address in the CellServDB. Once
addresses have been exchanged, Ubik will switch to a different address
if the first one fails. This affects both elections (the VOTE service)
and replication (the DISK service).
> Go back to the original posting. The reason for adding multiple
> interfaces was to increase throughput on the server.
The OP doesn't say that. He asks for an opinion on link aggregation vs
multihoming, either of which may be intended to provide increased
throughput, redundancy, or both.
> If only one
> address is used for UBIK replication that is not multihomed support.
Only one address _at a time_ is used. That certainly qualifies not only
as supporting multihomed servers but taking advantage of it.
> For the DB clients (cache manager, pts, vos, etc) which use a different
> CellServDB from the server's CellServDB it is possible to list all of
> the public addresses. The same is true if DNS SRV and AFSDB records are
> used. However, each address appears to the client as a unique server.
> This is fine for most situations but it also wasteful. The DB clients
> do not have access to the list of registered addresses.
Nor do they really need such access. Sure, if a connection goes down
you might prefer to try a different server rather than an alternate
address of the same server. Of course, if the failed component is the
router leading to the unreachable interface, that may be exactly the
wrong strategy. Fortunately, cache managers regularly check on dbserver
availability and will generally not send real requests to a server
already known to be down.
All of that said, in general, link aggregation should be preferred over
having a server with multiple interfaces on the same subnet. The latter
arrangement offers very few benefits and generally does not result in