[OpenAFS] Re: Redundant Internet links
Jaap Winius
jwinius@umrk.nl
Sat, 18 Dec 2010 03:41:34 +0100
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?
> 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?
> ... 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.
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).
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.
Cheers,
Jaap