On 9/25/2013 11:14 AM, Andrew Deason wrote:
> On Wed, 25 Sep 2013 00:03:12 -0400
> Jeffrey Altman <[email protected]> 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.

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.

I hope that clarifies.



Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to