[OpenAFS] Questions about multihoming servers

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


--Apple-Mail=_B14836E2-5F1F-4A76-AD96-F5B2F8D50699
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


On Sep 25, 2013, at 11:33 AM, Jeffrey Altman =
<jaltman@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 <jaltman@your-file-system.com> wrote:
>>=20
>>> 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.
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> 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.
>=20
> 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.
>=20
> 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=20
describing - the ability to not only tolerate the presence of multiple
interfaces without breaking, but actually exploit the increased =
potential throughput.

--
Mark Vitale
mvitale@sinenomine.net


--Apple-Mail=_B14836E2-5F1F-4A76-AD96-F5B2F8D50699
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="signature.asc"
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iQIcBAEBAgAGBQJSQwqiAAoJECQB9O5MipHIfXYQAJxxpNAzo4OFgs8Fb/UaXyM2
5cvVvBzUsiCLpWXdmVmX8xzODH6wlwExdbWR7GU8p4YpNEtP1Sv/YubW+AhX15j3
VYn0UNJDJJyFJ/2zqwJqdzWG+N87Wj48LYZQsKqbkrZVqTz11AxhwuNmz1CJcuLo
0tOkSGuGrilAwx74u+H887ybqVjUASsr4MPy7tj4ujAU2XOMZ8k6w110q/W74n6p
VazWSQRwvtZ4sEjt5Ea4N4opsrF7K0TLUIsU3wfhK7SVmRUmGYAPdy3YDuB82SVi
RL3hnWUqS/i45hZXNmDrctce+8E9WvuYbmG+ysiR6qyrfEDrGUJ1vQdmto1SReXz
xiFMk3f9fKnP/hyF5fVS6SwkhkcwOlJnTmHif1w9eXIOJmjjxYdg0z4qjgnuCbZY
nwUO9cg2h+fZA4FdADJHEUitaDdyw89fA8MaYQxiPSKWdE6OEtIv0mPeEQtB3dvG
MtE/ZBWONTfRYJoctCtd1A6wYI63L8cx6yFTssQ89qj4hD3x4MWiP+/BiC6C2gWp
PtHl31yTYMnzMDUXpgk9mliU25LjXZaO6iVjqcJuifTPvjVue4VlFhWdR2iH//Hy
72eDYw7MiPq0rU0duocFJQU8bCGZCJuu47wZof11p14V0krdJeHxld0t0etu7k5Y
jnQTKM7BdKDzzDGTvNHi
=TL2c
-----END PGP SIGNATURE-----

--Apple-Mail=_B14836E2-5F1F-4A76-AD96-F5B2F8D50699--