|
On Thursday 27 September 2001 03:52 pm, Horms wrote:
> As far as I can work out you'll need the persistance to be much longer than
> 5s. NFS is stateless, but regardless, when a client connects to a server a
> small ammount of state is established on both sides. The stateless aspect
> comes into play in that if either side times out, or a reboot is detected
> then the client will attempt to reconnect to the server. If the client
> doesn't reconnect, but rather its packets end up on a different server
> because of load balancing the server won't know anything about the client
> and nothing good will come of the sitiation. The solution to this is to
> ensure a client consistently talks to the same server, by setting a really
> long persistancy.
I actually specifically tested for this. Now it may just be a linux thing,
not common to all NFS platforms, but in my tests, when packets were sent to
the server other than the one mounted, it happily serves up the requested
data without even blinking. So whatever state is being saved (And I do know
there is some minimal state) seems unimportant. It actually surprised me how
seamlessly it all worked, as I was expecting the non-mounted server to reject
the requests or something similar.
> There is also the small issue of locks. lockd should be running on the
> server and keeping track of all the locks the client has. If the client
> has to reconnect, then it assumes all its locks are lost, but in the mean
> time it assumes everything is consistent. If it isn't accessing the same
> server (which wouldn't work for the reason given above) then the server
> won't know about any locks it things it has.
This could indeed be an issue. Perhaps setting up persistence for locks.
But I don't think it is all bad. Of course, I am basing this off several
assumptions that I have not verified at the moment. I am assuming that NFS
and GFS will Do The Right Thing. I am assuming the NFS lock daemon will
coordinate locks with the underlying OS. I am also assuming that GFS will
then coordinate the locking with the rest of the servers in the cluster. Now
as I understand locking on UNIX, it is only advisory and not enforced by the
kernel, the programs are supposed to police themselves. So in that case, as
long as it talks to a lock daemon, and keeps talking to the same lock daemon,
it should be okay, even if the lock daemon is not on the server it is talking
to, right?
Of course, in the case of a failure, I don't know what will happen. I will
definately have to look at the whole locking thing in more detail to know if
things work right or not, and maybe get the lock daemons to coordinate
locking.
|
