Hi All.
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.
Best regards, Rafal.
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.
Jeff
On Wed, May 29, 2013 at 1:07 AM, Rafał Radecki radecki.rafal@gmail.comwrote:
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:
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.comwrote:
Hi Jeff,
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:
If you are running a virtual environment such as vmware, you want to make sure you are using the timeout advanced options settings specified in the vmware on netapp best practice document (or whatever is applicable to your environment)
Also, if you’re taking a hit of more than 30-45 seconds to NFS on giveback/failover, I would wonder what the load on the storage system during the failover. I always stop SIS and snapmiror , disk scrubs, or anything else I can to get load down as low as possible. Preferably, each head is running at 30-40% or less before the failover to minimize impact. If I have the luxury, I usually watch the performance manager i/o trends and time the takeover/giveback in a trough after coming down from a peak.
With cifs this all goes out the window as you all know, cifs is terminated prior to giveback and then restarted.
--JMS
From: toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.net] On Behalf Of Jeff Cleverley Sent: Wednesday, May 29, 2013 12:14 PM To: Sebastian Goetze Cc: Toasters@teaparty.net Subject: Re: Netapp ONTAP 8.0.2 - NFS takeover/giveback - should it be visible to clients?
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.commailto: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.
Jeff On Wed, May 29, 2013 at 1:07 AM, Rafał Radecki <radecki.rafal@gmail.commailto:radecki.rafal@gmail.com> wrote: Hi All.
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.
Best regards, Rafal.
_______________________________________________ Toasters mailing list Toasters@teaparty.netmailto:Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters
-- Jeff Cleverley Unix Systems Administrator 4380 Ziegler Road Fort Collins, Colorado 80525 970-288-4611
_______________________________________________
Toasters mailing list
Toasters@teaparty.netmailto:Toasters@teaparty.net
http://www.teaparty.net/mailman/listinfo/toasters
-- Jeff Cleverley Unix Systems Administrator 4380 Ziegler Road Fort Collins, Colorado 80525 970-288-4611
I think that if I use nfs version 3 and hard mount option on clients they will not see any problems during takeover/giveback. What do you think about using 'hard' on clients when they connect to netapp shares and takeover/giveback is performed?
Best regards, Rafal.
2013/5/29 Jordan Slingerland Jordan.Slingerland@independenthealth.com
I've had occasions when I enjoyed using hard nfs mounts. As long as both humans and the software they run are tolerant of possibly lengthy hangs, that turns transient conditions that would have been visible outages into hangs, system freezes, where no data loss errors are directly caused by failed I/O.
On 11/07/2013, at 7:14 PM, Rafał Radecki wrote:
I think that if I use nfs version 3 and hard mount option on clients they will not see any problems during takeover/giveback. What do you think about using 'hard' on clients when they connect to netapp shares and takeover/giveback is performed?
'hard' is appropriate when you are using applications which can't fail gracefully if their data goes away. In practise that is almost all of them so we always use 'hard'. You probably want to use 'intr' as well, this permits you to interrupt (kill) processes which have hung because their NFS server went away.
'soft' would be useful if you have an application which could fail gracefully in the event that its data went away. A case I can think of is where you have a web server providing a UI for an application, where the UI could revert to a sensible error message in the event that the NFS server (holding the application data) went offline.
To be honest, I have never seen the latter case in practise, but maybe there are some out there.
Another possible use case is if you have a very unreliable NFS server, but that wouldn't be a production environment would it?
To enable takeover/giveback to be transparent to clients (apart from the brief hang) you definitely would want to use 'hard', though 'soft' may work if the timeout is greater than 180 seconds.
HTH, Jeremy
Thanks for all the info, 'hard' did the job well.
Best regards, Rafal Radecki.
2013/7/12 Jeremy Webber jeremy.webber@al.com.au
Hi Rafal,
what kind of outages are visible for your NFS clients? Are you using the "hard" mount option?
Bye,
Alexander Griesser System-Administrator
ANEXIA Internetdienstleistungs GmbH
Telefon: +43-463-208501-320 Telefax: +43-463-208501-500
E-Mail: ag@anexia.atmailto:ag@anexia.at Web: http://www.anexia.at
Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 Klagenfurt Geschäftsführer: Alexander Windbichler Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601
Von: toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.net] Im Auftrag von Rafal Radecki Gesendet: Mittwoch, 29. Mai 2013 09:08 An: Toasters@teaparty.net Betreff: Netapp ONTAP 8.0.2 - NFS takeover/giveback - should it be visible to clients?
Hi All.
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.
Best regards, Rafal.
It has been my experience that the failover has an extremely minimal impact to NFS clients. The giveback typically will impact the NFS client for 30-50 seconds
Mike On May 29, 2013 4:27 AM, "Alexander Griesser" ag@anexia.at wrote:
Hi,
I used to not see any issue with nfs mounts during cf events. When we went to RHEL 6 with NFSv4 as the default, then unix hosts started having all sorts of stale mount issues during cf events. Anything still using NFSv3 (VMware, oracle) is still very forgiving.
---- Scott Eno s.eno@me.com
On May 29, 2013, at 3:07 AM, Rafał Radecki radecki.rafal@gmail.com wrote:
Hello Scott:
The key here is that you switched to NFSv4. Previously versions of NFS were connectionless. This was seen as a good thing because it meant that if the server had what you called "an event" or the network had a glitch, it wasn't visible to the client unless the server didn't come back.
NFSv4 works more like CIFS and uses a connection. That is why you are seeing all the issues. You might want to go back to version 3 unless you can use the new features of v4 such as parallel NFS. Most applications are not taking advantage of those new features.
--April
Sent from my iPad
On May 29, 2013, at 7:27 AM, Scott Eno s.eno@me.com wrote:
I understand the session issues and agree that we should not have abruptly gone to v4.
But our unix admins believe otherwise.
---- Scott Eno s.eno@me.com
On May 29, 2013, at 11:24 AM, April aprilogi@yahoo.com wrote:
-
Alexander Griesser -
April -
Bennett Todd -
Jeff Cleverley -
Jeremy Webber -
Jordan Slingerland -
Mike Gossett -
Rafał Radecki -
Scott Eno -
Sebastian Goetze