We implemented simple file lock monitoring on our 7mode filers: A script runs each 5 minutes retrieving output from lock status -n command from all vfilers. For example:
# ssh [...] vfiler run sngnas100703 lock status -n CIFS: 0 share locks, 0 byte locks [...] NFSV4: 29 share locks, 5 byte locks [...] Total Locks: 29 share locks, 5 byte locks [...]
We would like to implement equivalent solution for cDOT but there is no command returning lock status summary (all we need is to count share and byte locks per protocol: CIFS and NFSv4). cDOT documentation and NetApp support suggest using command:
vserver locks show
But:
Command warns that it may affect system performance and we will query clusters each couple of minutes. The script will have to retrieve huge output, parse it and calculate required totals.
What is the best and non-intrusive way to retrieve locks status? (other commands? API?)
Best regards,
Jacek Nogala
What are you doing with the lock statuses? What are you ultimately trying to do?
On Sun, Aug 5, 2018 at 11:01 PM Jacek janosldx@gazeta.pl wrote:
We implemented simple file lock monitoring on our 7mode filers: A script runs each 5 minutes retrieving output from lock status -n command from all vfilers. For example:
# ssh [...] vfiler run sngnas100703 lock status -n CIFS: 0 share locks, 0 byte locks [...] NFSV4: 29 share locks, 5 byte locks [...] Total Locks: 29 share locks, 5 byte locks [...]
We would like to implement equivalent solution for cDOT but there is no command returning lock status summary (all we need is to count share and byte locks per protocol: CIFS and NFSv4). cDOT documentation and NetApp support suggest using command:
vserver locks show
But:
Command warns that it may affect system performance and we will query clusters each couple of minutes. The script will have to retrieve huge output, parse it and calculate required totals.
What is the best and non-intrusive way to retrieve locks status? (other commands? API?)
Best regards,
Jacek Nogala _______________________________________________ Toasters mailing list Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters
On 2018-08-05 23:33, Basil wrote:
What are you doing with the lock statuses? What are you ultimately trying to do?
In a nutshell: The script queries filers frequently (~a couple of times per minute) and delivers metrics to time series DB. Data from DB are visualized in Grafana as a dashboard. Our storage ops teams use this tool for pro-active monitoring of locks on 7-mode filers to avoid outages. (We experienced such outages thus now deploying this tool in all regions.)
Our goal is to implement this tool for cDOT systems. It is no-brainer to create a script running vserver locks show, parse output and calculate required totals. But we are concerned about potential performance impact on monitored systems. 7-mode command delivers ready-to-use numbers and the impact of the tool seems to be negligible.
Best regards,
Jacek
On Sun, Aug 5, 2018 at 11:01 PM Jacek <janosldx@gazeta.pl mailto:janosldx@gazeta.pl> wrote:
We implemented simple file lock monitoring on our 7mode filers: A script runs each 5 minutes retrieving output from lock status -n command from all vfilers. For example: # ssh [...] vfiler run sngnas100703 lock status -n CIFS: 0 share locks, 0 byte locks [...] NFSV4: 29 share locks, 5 byte locks [...] Total Locks: 29 share locks, 5 byte locks [...] We would like to implement equivalent solution for cDOT but there is no command returning lock status summary (all we need is to count share and byte locks per protocol: CIFS and NFSv4). cDOT documentation and NetApp support suggest using command: vserver locks show But: Command warns that it may affect system performance and we will query clusters each couple of minutes. The script will have to retrieve huge output, parse it and calculate required totals. What is the best and non-intrusive way to retrieve locks status? (other commands? API?) Best regards, Jacek Nogala _______________________________________________ Toasters mailing list Toasters@teaparty.net <mailto:Toasters@teaparty.net> http://www.teaparty.net/mailman/listinfo/toasters