On Wed, 25 Sep 2013 16:09:07 +0000 Mark Vitale <[email protected]> wrote:
> On Sep 25, 2013, at 11:33 AM, Jeffrey Altman <[email protected]> > 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 [email protected] _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
