Quoting Andrew Deason <[email protected]>:
... 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 _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
