Wendy Cheng wrote:
Fajar A. Nugraha wrote:
Lon Hohberger wrote:
On Wed, May 16, 2007 at 11:04:41AM +0200, Alain Moulle wrote:
how could it
be "without detecting when a failure occurs" ?
Sure I miss something somewhere ?
A 'managed NFS service' needs to include a 'managed virtual IP'.
Clients always access using the same IP.
Hi Lon,
How do nfs clients behave during this failover/server change?
To be more specific, :
- does the choice UDP vs TCP and nfs v3 vs v4 make a difference in how
much time it takes for clients to be serviced by the new server?
More specifically, TCP has ~30 minutes TIME_WAIT issue (see the bugzilla
comment mentioned in previous post).
- can the client handle the change gracefully so that
there will be no "stale nfs handle"?
This is a tough problem to solve. Hopefully the bugzilla entry explains
well.
On the server side :
- When the exported filesystem is non-cluster (e.g. ext3), how does the
server handle locking issues? If an nfs-client is locking a file, can
the server (in Managed NFS service) forcefully unmount the file system,
considering that the nfs daemon is kernel-space, so that it can't be
killed?
We have a tentative patch set for this. It is usable but still under
revised.
- Can the client gracefully handle new, failover, nfs clients, since
some nfs information is stored on /var/lib/nfs, which is on a local file
system?
This would need to be moved into the shared storage area (and done by
RHCS).
-- Wendy
These issues are documented in Red Hat bugzilla 132823 Comment #47
(https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=132823).
A draft write-up is placed in:
http://people.redhat.com/wcheng/Project/nfs (see section 4.3 and 4.4).
-- Wendy
--
Linux-cluster mailing list
Linux-cluster@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/linux-cluster
