On Sep 25, 2013, at 11:33 AM, Jeffrey Altman <jalt...@your-file-system.com> wrote:
> On 9/25/2013 11:14 AM, Andrew Deason wrote: >> On Wed, 25 Sep 2013 00:03:12 -0400 >> Jeffrey Altman <jalt...@your-file-system.com> wrote: >> >>> DB servers do not have UUIDs but more importantly the UBIK database >>> replication protocol has no support for them or any other mechanism that >>> could associate more than one IP address with a single service. From >>> the perspective of UBIK and all of the DB server clients, each IP >>> address is a distinct server. >> >> This is completely false. Or I'm misinterpreting what you're saying, but >> I don't see what I could be misinterpreting about this. While there are >> no UUIDs in ubik, it certainly does have a mechanism for matching >> different IPs to a single service; each site broadcasts its list of >> interfaces via DISK_UpdateInterfaceAddr to all other sites, so that >> sites can map an incoming RPC IP to a specific site (via >> ubikGetPrimaryInterfaceAddr). Instead of having a UUID to identify a >> site, we can identify it by its "canonical" IP, which is the IP in >> CellServDB. >> >> If a voting ubik node has IPs 198.51.100.2, 3, and 4, with 2 in the >> cellservdb, any node is supposed to interpret a request from e.g. >> 198.51.100.3 as coming from 198.51.100.2. That is, at the ubik layer, >> for ubik voting purposes; not e.g. at the rx layer. >> >> Now, if it's broken, it's broken, and 15640 sure makes it looks like >> it's broken at least with netinfo. But the underlying infrastructure and >> capability is there. > > 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. > > 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. I'm not familiar with the code here, but it seems the point of disagreement could be the definition of the word "support". 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. -- Mark Vitale mvit...@sinenomine.net
signature.asc
Description: Message signed with OpenPGP using GPGMail
