On Fri, Dec 17, 2010 at 9:41 PM, Jaap Winius <jwin...@umrk.nl> wrote: > Quoting Andrew Deason <adea...@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. _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info