[OpenAFS] Re: Redundant Internet links

[Derrick Brashear]

On Fri, Dec 17, 2010 at 9:41 PM, Jaap Winius <jwinius@umrk.nl> wrote:
> Quoting Andrew Deason <adeason@sinenomine.net>:
>
>> ... We don't provide the tools for a split-horizon vldb (yet, anyway).
>
> Actually, if we're all going to move to IPv6 anyway, of what use would that
> be?

ipv4 isn't going away tomorrow...

>> To be clear, the fileserver does not become readonly; what becomes
>> readonly are the databases that contain volume location information and
>> authenticated user metadata. So, that means you can read and write to
>> files to any fileserver you can reach, but you cannot create, remove, or
>> release volumes, create, remove, or alter users/groups, or anything else
>> that requires modifying those databases.
>
> Very interesting. So, I take it a different, local database is used to keep
> track of the changes made to individual files in local R/W volumes, and this
> database stays R/W even if the server it's on gets cut off?

each volume is tracked individually on the server hosting it (whether
RW or RO; RO are just published, snapshot copies, of the RW)

>> ... You contact the vlserver at site A, and
>> it will tell you that the volume is on a fileserver at site B, and it
>> will also tell you all known IP addresses for the fileserver at site B.
>
> Sounds like you're referring to the IP addresses for the servers that the
> clients are given. In that case I understand. I can do that with AFSDB RRs.
>
> What I meant, though, are the IP addresses that the servers have to contact
> each other. On Debian, these are in /etc/openafs/server/CellServDB. I'd like
> to use multiple IP addresses for each host in there too, but that would
> adversely affect the voting algorithm.

can't do it. sorry.

> On the other hand, what if I were to set up virtual hosts on which to run
> the file servers separately? In that case, each database server would still
> run on the bare metal OS and those CellServDB files would still contain only
> three IP addresses. Lower level routing would still take care of
> connectivity if one of the main links went down. The files servers, however,
> could each have a CellServDB file with five addresses: a local private range
> address and four public addresses for the two remote file servers (which
> would be reached through port-forwarding).

doable, albeit potentially fussy if there are issues with the routing.

> Still, even if this would work, I no longer think I'd want to do it. That's
> because I'd rather have the AFS servers avoid the secondary links entirely
> unless the main links go down, and I can't instruct them to do that (yet)
> through prioritization. I can only do that with routing.