Subject: [nfsv4] Standardized NFSv4 statistics reporting

From: <[email-masked]>
Date: Tue, 1 Dec 2009 21:56:11 -0500

A few weeks ago a discussion in the FedFS working group about
troubleshoot tools led to a discussion about statistics reporting for
NFS file servers in general.

The basic observation is that every file server implementation maintains
statistics about its activity - operations/second, per operation stats,
error counters, etc. and anyone trying to troubleshoot or even just
understand what is going on a file server, or group of file servers, is
going to be interested in extracting the statistics from a server.
Today there is no standard or even just commonly agreed way to get stats
out of an NFS server.  Each vendor's implementation exposes the
statistics it maintains in a different way.    In a world where I have
file servers from only one vendor that is not so difficult to live with.
However, life is much harder for anyone wanting to develop an NFSv4
service health checking / monitoring tool that is supposed to work
against any NFSv4 file server.  Such a tool would have to implement a
separate statistics extraction mechanism for each different server
implementation.    This is aggravated by FedFS as it facilitates
multiple file servers from multiple vendors participating in providing
the access to one or more namespaces.

This leads to the observation that file service monitoring and
troubleshooting would be made much easier if there was a standardized,
or even just commonly agreed, way of extracting the statistics that each
file server implementation maintains from each file server rather than
each different implementation being different.

Although this discussion started in the federated file system context we
came to the conclusion that this applies to file services in general
(and beyond but that is as far as this working group's remit extends).
It was also noted that there had in the past been some discussion with
this group about the idea of exposing information via SNMP, but that
conversation had not gone anywhere.

SMI-S also comes to mind as a possible way to standardize the exposure
of statistics from a file server.   Unfortunately, I don't know enough
about the current state of the NAS SMI-S profile to be able to comment
on it.

Rather than diving straight into detailed proposals about what
statistics should be maintained and exactly how they might be exposed
(SNMP, SMI-S, new NFSv4 calls, etc.), I thought it worth seeing if the
group felt this was an area that we want to get involved with.   Do we?

If so, what is the most appropriate vehicle?  Options could include:

  * statistics maintenance and exposure with the NFSv4 protocol itself; 

  * defining an SNMP MIB that all NFSv4 implementations should implement
(I believe NetApp already have one that covers NFS - maybe we could use
that as a starting point);  

  * input into the NAS profile within SMI-S (I am hoping someone some
one can provide more insight into the state of that);

  * others?

Thoughts?

Thanks,

Chris

-- 
Chris Stacey - Senior Technologist, Unified Storage Engineering, EMC
Corporation (New Zealand).  Phone: +64 21 225 3747

---

From: "Yoder, Alan" <[email-masked]>
Date: Wed, 02 Dec 2009 01:21:56 -0800

There is a Filesystem Performance profile in SMI-S.  I'm not sure whether
any client-side implementations use it. FWIW, EMC drove the development of
the profile.  ;-)  Mike Thompson is the EMC contact.

Given this group's affiliation with IETF, however, it seems like the more
natural move would be a standard MIB.  I think I can speak for NetApp in
saying that starting with whatever's in our MIB will work for us.

Alan

Alan G. Yoder, MSEE, Ph.D.
Office of the CTO, NetApp
Chair, SNIA Technical Council
Secretary, SNIA Green Storage Initiative
[email-masked]
408 747 1419
650 814 6498

On 12/1/09 6:56 PM, "[email-masked]" <[email-masked]> wrote:

> A few weeks ago a discussion in the FedFS working group about troubleshoot
> tools led to a discussion about statistics reporting for NFS file servers in
> general.
>  
> statistics about its activity  operations/second, per operation stats, error
> counters, etc. and anyone trying to troubleshoot or even just understand what
> is going on a file server, or group of file servers, is going to be interested
> in extracting the statistics from a server.   Today there is no standard or
> even just commonly agreed way to get stats out of an NFS server.  Each
> vendor¹s implementation exposes the statistics it maintains in a different
> way.    In a world where I have file servers from only one vendor that is not
> so difficult to live with.  However, life is much harder for anyone wanting to
> develop an NFSv4 service health checking / monitoring tool that is supposed to
> work against any NFSv4 file server.  Such a tool would have to implement a
> implementation.   This is aggravated by FedFS as it facilitates multiple file
> servers from multiple vendors participating in providing the access to one or
> more namespaces.
>  
> This leads to the observation that file service monitoring and troubleshooting
> would be made much easier if there was a standardized, or even just commonly
> agreed, way of extracting the statistics that each file server implementation
> maintains from each file server rather than each different implementation
> being different.
>  
> Although this discussion started in the federated file system context we came
> to the conclusion that this applies to file services in general (and beyond
> but that is as far as this working group¹s remit extends).    It was also
> noted that there had in the past been some discussion with this group about
> the idea of exposing information via SNMP, but that conversation had not gone
> anywhere.
>  
> SMI-S also comes to mind as a possible way to standardize the exposure of
> statistics from a file server.   Unfortunately, I don¹t know enough about the
> current state of the NAS SMI-S profile to be able to comment on it.
>  
> Rather than diving straight into detailed proposals about what statistics
> should be maintained and exactly how they might be exposed (SNMP, SMI-S, new
> NFSv4 calls, etc.), I thought it worth seeing if the group felt this was an
> area that we want to get involved with.   Do we?
>  
>   * defining an SNMP MIB that all NFSv4 implementations should implement (I
> believe NetApp already have one that covers NFS  maybe we could use that as a
> starting point); 
>   * input into the NAS profile within SMI-S (I am hoping someone some one can
> provide more insight into the state of that);
>   * others?
>  
> Thoughts?
>  
> Thanks,
> Chris
>