[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