I completely agree... It all depends on what the applications (or
users) can tolerate.
It's like, using CIFS/SMB, "most applications will transparently
reconnect a session".
But if you're using Notes, 10.000 users will try to lynch you...
:-P
Sebastian
On 29.05.2013 18:13, Jeff Cleverley
wrote:
Sebastian,
My definition of non-disruptive is "nobody notices". When I start
getting visits from engineers or support calls saying the network
is down or behaving badly, it qualifies as disruptive to our lab
:-) That's why I get to do all my cluster work or snapmirror
migrations in the early morning hours :-)
Jeff
On Wed, May 29, 2013 at 1:53 AM,
Sebastian Goetze <spgoetze@gmail.com>
wrote:
Hi Jeff,
the non-disruptiveness also depends upon what protocol
version you're using:
Version 3 doesn't have sessions, so there's no session infos
to be handed over to the partner...
Versions 4/4.1 have sessions, but are supposed to handle
reboots/takeovers more gracefully, also regarding locks.
Generally speaking "non-disruptive" means (not only in
NetApp speak), that the disruption is less than the protocol
timeout values (and there's no need to re-start a session).
It does not mean, that there isn't a small period of
non-responsiveness. Even SAN-protocols 'suffer' the same,
e.g. when there's a path state change and ALUA/MPIO kicks
in...
my 2c
Sebastian
On 29.05.2013 09:24, Jeff Cleverley wrote:
Rafal,
NetApp's definition of "non-disruptive" is generally
not what most people consider non-disruptive :-) It
does cause nfs outages during these modes. How much
time varies by hardware, system load, etc. The time
listed by the giveback is generally less than user
wall clock time. The system may say the downtime was
45 seconds, but a time command from a client will
usually be closer to 100 seconds before the filer
starts responding again. That is why I generally do
snapmirror migrations and cluster failovers in the
middle of the night to minimize user complaints.
I have two FAS3210 in 7-mode Actvie/Active.
I perform takeover/gieback and see that the
outage is visible for clients for nfs mounts.
From your experiences should it be so? I think
that information about nfs sessions and IP
address are moved to the takeover node so in
theory it should not be visible.