[OpenAFS] Multihomed issues
Mon, 17 Jan 2011 15:44:05 -0500
I kind of follow what you're saying here. However:
1) CellServDB is "where are database servers"
2) what's in the VLDB is "where are the volumes"
so just because it appeared in 1, well, that has nothing to do with 2.
mantra: "solve the real problem"
CellServDB on each host must list the addresses that the database
servers are reachable at from *this* host. not what each believes
their own address are. Make it so.
e.g. a db server behind a nat would list its internal address for
itself; one outside a nat would list the external address which you
are port forwarding from. The internal server would include in NetInfo
as its first line:
f (external address)
if its external address was 184.108.40.206
then whatever internal address
NetRestrict could be used to mask unwanted addresses, *but* you
probably want both addresses, the local and the external, so if there
are these two only, mask none with NetRestrict.
Now, as to fileservers, the same tip(s) with NetInfo/NetRestrict
apply. Here, the CellServDB only *needs* to provide an address for at
least one server, but ideally you still list, for each server, an
address which reaches it.
vos delentry is for a VLDB entry, not a server, so you didn't remove
any server addresses from the VLDB with it. remsite removes a server
for a volume. delentry removes a whole volume entry. changeaddr
-remove removes an address but probably still isn't what you want.
make the fileserver register the addresses you want (using netinfo and
netrestrict), start it and let it register. all will be well.
On Mon, Jan 17, 2011 at 3:20 PM, Jaap Winius <firstname.lastname@example.org> wrote:
> Hi folks,
> After messing around with a couple of multihomed hosts for a while, I get
> the impression that AFS, or at least the Debian squeeze install procedure
> for it, doesn't like to work this way. It's possible to prevent the file
> server from listening to certain interfaces (addresses) by using NetInfo =
> NetRestrict, but I wish I knew how to do something similar for the ptserv=
> and especially for the vlserver.
> When setting up a new database server (which is supposed to replicate via
> the Internet), it seems that, by default, AFS scans all of the interfaces=
> a new host to end up using the IP addresses associated with them. In my
> case, this includes several private addresses that I don't want any of th=
> database servers to use. However, even if immediately afterwards I remove
> these addresses from a new server's CellServDB and restart it, it's too
> late: they're already in the VLDB and AFS is already trying to send a new=
> copy of root.cell to the new server... using that server's private range =
> address. Now I've got:
> # vos volinfo root.cell -noresolv
> root.cell =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 536870915 RW =
=A0 =A0 =A0 =A0 =A06 K =A0On-line
> =A0 =A0oost.dapadam.nl /vicepa
> =A0 =A0RWrite =A0536870915 ROnly =A0536870916 Backup =A0 =A0 =A0 =A0 =A00
> =A0 =A0MaxQuota =A0 =A0 =A0 5000 K
> =A0 =A0Creation =A0 =A0Sun Jan =A09 15:32:11 2011
> =A0 =A0Copy =A0 =A0 =A0 =A0Sun Jan =A09 15:32:11 2011
> =A0 =A0Backup =A0 =A0 =A0Never
> =A0 =A0Last Access Fri Jan 14 18:17:02 2011
> =A0 =A0Last Update Fri Jan 14 18:16:57 2011
> =A0 =A00 accesses in the past day (i.e., vnode references)
> =A0 =A0RWrite: 536870915 =A0 =A0 ROnly: 536870916 =A0 =A0 RClone: 5368709=
> =A0 =A0number of sites -> 3
> =A0 =A0 =A0 server 220.127.116.11 partition /vicepa RW Site =A0-- New relea=
> =A0 =A0 =A0 server 18.104.22.168 partition /vicepa RO Site =A0-- New relea=
> =A0 =A0 =A0 server 192.168.26.10 partition /vicepa RO Site =A0-- Old rele=
> It seems to be stuck like this. Can it be fixed?
> Before discovering this, I had already used "vos delentry" to remove the
> private IP addresses from the VLDB, so "vos listaddrs" currently shows on=
> the correct (public) IP addresses.
> The last time around, I had succeeded in adding each new server only afte=
> first bringing down the internal interfaces. Once installed, the internal
> interfaces were brought up again and AFS ignored them. This afternoon,
> bringing down those internal interfaces was not an option, but I was hopi=
> to get it to work anyway. I had no such luck.
> This is a fresh setup involving two of the servers planned, so I can easi=
> blow it all away and start over, but I'm wondering if it's possible to
> install OpenAFS on multihomed hosts without having to down any internal
> OpenAFS-info mailing list